From owner-ietf-openproxy@mail.imc.org Sun Mar 2 15:54: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 PAA18253 for ; Sun, 2 Mar 2003 15:54:40 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h22KVSk18955 for ietf-openproxy-bks; Sun, 2 Mar 2003 12:31:28 -0800 (PST) Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h22KVRY18951 for ; Sun, 2 Mar 2003 12:31:27 -0800 (PST) Received: from f04a-9-124.d1.club-internet.fr ([212.194.80.124] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 18pa7F-0002lY-00 for ietf-openproxy@imc.org; Sun, 02 Mar 2003 12:31:21 -0800 Message-Id: <5.2.0.9.0.20030302211302.02d3c630@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sun, 02 Mar 2003 21:19:44 +0100 To: OPES Group From: jfcm Subject: plug-out? In-Reply-To: References: <72992B39BBD9294BB636A960E89AE02E50C136@hermes.webwasher.com> <72992B39BBD9294BB636A960E89AE02E50C136@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: There seems to be some problems in trying to clearly conceptualize what is an OPES. And what is an ONES (open network extended service). I had a long private exchange on that (by my mistake in replying to the author only on Eudora, rather than sending to all). I had to explain what is an OPES to developers today, and I came with the formula, it is a "plug-out". That is the same as a plug-in function, but on the network side as in totality or in part it can be on the network. Would you agree with that? I do not know if is good English and very accurate. But people caught the concept immediately. jfc From owner-ietf-openproxy@mail.imc.org Mon Mar 3 04:48: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 EAA13976 for ; Mon, 3 Mar 2003 04:48:04 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h239IhG01749 for ietf-openproxy-bks; Mon, 3 Mar 2003 01:18:43 -0800 (PST) Received: from wwsmtp.webwasher.com ([217.146.159.49]) by above.proper.com (8.11.6/8.11.3) with SMTP id h239IeY01736 for ; Mon, 3 Mar 2003 01:18:41 -0800 (PST) Received: from hermes.webwasher.com [192.168.1.3] id LZOZQIS2; 03 Mar 2003 10:18:36 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: AW: too fast out-of-SENT-order messages X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 3 Mar 2003 10:15:29 +0100 Message-ID: <72992B39BBD9294BB636A960E89AE02E50C138@hermes.webwasher.com> Thread-Topic: AW: too fast out-of-SENT-order messages Thread-Index: AcLfajD7OaQMddQhRbu6qwOEQuCTFAB8sRsQ From: "Martin Stecher" To: "Alex Rousskov" , "OPES Group" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h239IgY01743 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > > It seems that I misunderstood the whole concept. > > I am glad you asked these questions, then! Clearly, predraft needs to > do a better job at defining OPES messages. No, sorry, it more seems that I didn't read version 01 of the predraft carefully enough. [...} > > I was thinking that OPES transactions might correspond to OPES > connections. That is why I did not introduce them into the draft yet, > waiting to hear more opinions on the connection management issues. It > is probably about time for me to make a specific proposal though. > Callout transactions and connections are not the same due to the requirements draft. This is the message hierachy as I see it today. Please correct if I am wrong: 1. Transport layer connection between OPES processor and callout server can have one or multiplex multiple (3.4 of opes-protocol-reqs) 2. Callout connections (3.4 of opes-protocol-reqs) consists out of multiple (3.4 of opes-protocol-reqs) 3. Callout transactions (3.3 of opes-protocol-reqs) consists out of one or multiple (t.b.d) 4. Application transactions (protocol predraft) consists out of multiple (protocol predraft) 5. Application messages (protocol predraft) The mapping between 3 and 4 is not yet determined. I suggest to go for a relationship where one callout transaction consists out of multiple application transactions. And then move the "services" parameter of the "xaction-start" message to the callout transaction init message. This way we can minimize the overhead of callout transaction specific meta data in application transactions. > > In your experience, what kind of metadata/state would be associated > with an OPES transaction (separate from the application transaction)? > Same service IDs? Dispatcher- and callout-server-specific > info? Anything else? If you look into ICAP's OPTIONS message we could move some or all of these parameters into the callout transaction init phase. Other meta data for a callout transaction would be "requested services", "processor identification", "callout service database version (see ISTAG header of ICAP)". Meta data of an application transaction would then be information about the requesting user for instance. Regards Martin From owner-ietf-openproxy@mail.imc.org Mon Mar 3 13:53:58 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 NAA07509 for ; Mon, 3 Mar 2003 13:53:57 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h23IPu308782 for ietf-openproxy-bks; Mon, 3 Mar 2003 10:25:56 -0800 (PST) Received: from NJFPSRVEXG2KCL.research.att.com (H-135-207-21-32.research.att.com [135.207.21.32]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h23IPtX08776 for ; Mon, 3 Mar 2003 10:25:56 -0800 (PST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: plug-out? Date: Mon, 3 Mar 2003 13:25:52 -0500 Message-ID: <8134935F33C6274CB21112BD6376E77D28E1D1@NJFPSRVEXG2KCL.research.att.com> Thread-Topic: plug-out? Thread-Index: AcLg/G5Jpr0Ak0l5Ry6fKvXlltuVrgAtKveA From: To: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h23IPuX08778 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit The notion of "plug-out" does not seem to convey the key OPES concept that an OPES entity operates on a data flow between a data provider and a data consumer. On the other hand, the concept (not sure about the English) perhaps applies well in explaining Web Services? Robin Chen AT&T Labs - Research chen@research.att.com -------------------------------------------------------- Room B259, 180 Park Avenue, Florham Park, NJ 07932-0971 phone:(973)-360-8653 http://www.research.att.com/~chen -----Original Message----- From: jfcm [mailto:info@utel.net] Sent: Sunday, March 02, 2003 3:20 PM To: OPES Group Subject: plug-out? There seems to be some problems in trying to clearly conceptualize what is an OPES. And what is an ONES (open network extended service). I had a long private exchange on that (by my mistake in replying to the author only on Eudora, rather than sending to all). I had to explain what is an OPES to developers today, and I came with the formula, it is a "plug-out". That is the same as a plug-in function, but on the network side as in totality or in part it can be on the network. Would you agree with that? I do not know if is good English and very accurate. But people caught the concept immediately. jfc From owner-ietf-openproxy@mail.imc.org Mon Mar 3 14:34:45 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 OAA09188 for ; Mon, 3 Mar 2003 14:34:44 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h23J6S211467 for ietf-openproxy-bks; Mon, 3 Mar 2003 11:06:28 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h23J6QX11462 for ; Mon, 3 Mar 2003 11:06:26 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.6/8.12.5) with ESMTP id h23J6SeM053647 for ; Mon, 3 Mar 2003 12:06:28 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.6/8.12.5/Submit) id h23J6Saa053646; Mon, 3 Mar 2003 12:06:28 -0700 (MST) (envelope-from rousskov) Date: Mon, 3 Mar 2003 12:06:28 -0700 (MST) From: Alex Rousskov To: OPES Group Subject: Re: plug-out? In-Reply-To: <5.2.0.9.0.20030302211302.02d3c630@mail.utel.net> Message-ID: References: <72992B39BBD9294BB636A960E89AE02E50C136@hermes.webwasher.com> <72992B39BBD9294BB636A960E89AE02E50C136@hermes.webwasher.com> <5.2.0.9.0.20030302211302.02d3c630@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, 2 Mar 2003, jfcm wrote: > I had to explain what is an OPES to developers today, and I came > with the formula, it is a "plug-out". That is the same as a plug-in > function, but on the network side as in totality or in part it can > be on the network. > > Would you agree with that? I do not know if is good English and very > accurate. But people caught the concept immediately. To me, an OPES callout server is a plugin into OPES processor. OPES, as a whole, is a proxy service, possibly a content modifying proxy service. It may be viewed as a plugin into an application protocol proxy, to a certain extent. Alex. From owner-ietf-openproxy@mail.imc.org Mon Mar 3 16:03:56 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 QAA12871 for ; Mon, 3 Mar 2003 16:03:56 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h23Kawk17680 for ietf-openproxy-bks; Mon, 3 Mar 2003 12:36:58 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h23KavX17676 for ; Mon, 3 Mar 2003 12:36:57 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.6/8.12.5) with ESMTP id h23KaxeM055845 for ; Mon, 3 Mar 2003 13:36:59 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.6/8.12.5/Submit) id h23KaxPL055844; Mon, 3 Mar 2003 13:36:59 -0700 (MST) (envelope-from rousskov) Date: Mon, 3 Mar 2003 13:36:59 -0700 (MST) From: Alex Rousskov To: OPES Group Subject: RE: AW: too fast out-of-SENT-order messages In-Reply-To: <72992B39BBD9294BB636A960E89AE02E50C138@hermes.webwasher.com> Message-ID: References: <72992B39BBD9294BB636A960E89AE02E50C138@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 Mon, 3 Mar 2003, Martin Stecher wrote: > > I was thinking that OPES transactions might correspond to OPES > > connections. That is why I did not introduce them into the draft yet, > > waiting to hear more opinions on the connection management issues. It > > is probably about time for me to make a specific proposal though. > > > > Callout transactions and connections are not the same due to the > requirements draft. True. I was not accurate enough. I meant to say that we could prohibit multiplexing OPES transactions over one OPES connection. We must support multiple OPES transactions over one OPES connection, but those transactions may be sequential unless I misread the requirements. > This is the message hierachy as I see it today. > Please correct if I am wrong: > > > 1. Transport layer connection between OPES processor and callout server > can have one or multiplex multiple (3.4 of opes-protocol-reqs) > > 2. Callout connections (3.4 of opes-protocol-reqs) > consists out of multiple (3.4 of opes-protocol-reqs) Yes. And we can even have one callout connection use multiple transport connections(?). > 3. Callout transactions (3.3 of opes-protocol-reqs) > consists out of one or multiple (t.b.d) consists out of one or multiple OPES messages 4. OPES message (protocol predraft) > 4. Application transactions (protocol predraft) > consists out of multiple (protocol predraft) > 5. Application messages (protocol predraft) Application transactions and application messages are application-protocol specific. They are not defined in the predraft, but one callout transaction must correspond to one application message (3.3 of opes-protocol-reqs and see below). > The mapping between 3 and 4 is not yet determined. I suggest to go > for a relationship where one callout transaction consists out of > multiple application transactions. And then move the "services" > parameter of the "xaction-start" message to the callout transaction > init message. This way we can minimize the overhead of callout > transaction specific meta data in application transactions. But draft-ietf-opes-protocol-reqs-03.txt says in 3.3 Callout Transactions: A callout transaction is defined as a message exchange between an OPES processor and a callout server consisting of a callout request and a callout response. [...] A callout request MUST always contain a partial or complete application message. A callout response MUST always indicate the result of the callout transaction. A callout response MAY contain a modified application message. The above seems to imply that there could be only one application message (or two, if you count original and modified separately) per callout transaction. That implication seems natural to me. That is why I was thinking that callout _connections_ should carry properties common to many callout transactions. A transport connection does not have to be terminated when a callout connection ends, I guess, so we are not going to loose efficiency here. > If you look into ICAP's OPTIONS message we could move some or all of > these parameters into the callout transaction init phase. Other meta > data for a callout transaction would be "requested services", > "processor identification", "callout service database version (see > ISTAG header of ICAP)". > > Meta data of an application transaction would then be information > about the requesting user for instance. Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Mon Mar 3 16:37:48 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 QAA13790 for ; Mon, 3 Mar 2003 16:37:47 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h23L5ZW18379 for ietf-openproxy-bks; Mon, 3 Mar 2003 13:05:35 -0800 (PST) Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h23L5YX18375 for ; Mon, 3 Mar 2003 13:05:34 -0800 (PST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h23L5Tx20137 for ; Mon, 3 Mar 2003 16:05:30 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Mar 2003 16:05:30 -0500 Message-ID: <87609AFB433BD5118D5E0002A52CD7540509AAD3@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: OPES Group Subject: RE: plug-out? Date: Mon, 3 Mar 2003 16:05:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E1C8.9EC30F0C" 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_01C2E1C8.9EC30F0C Content-Type: text/plain e-mail problems, resending abbie > -----Original Message----- > From: > Sent: Monday, March 03, 2003 2:36 PM > To: '=SMTP:rousskov@measurement-factory.com'; > '=SMTP:ietf-openproxy@imc.org' > Subject: RE: plug-out? > > > > Alex, > I do agree with what u said. > plus, I would like for us to stop mixing issues by refereing > to ONES. The work/place of is defined by the charter. > > To me OPES is a proxy on Viagra (that includes the callout server too) > > abbie > > > > > -----Original Message----- > > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > > Sent: Monday, March 03, 2003 2:06 PM > > To: OPES Group > > Subject: Re: plug-out? > > > > > > > > On Sun, 2 Mar 2003, jfcm wrote: > > > > > I had to explain what is an OPES to developers today, and I > > came with > > > the formula, it is a "plug-out". That is the same as a plug-in > > > function, but on the network side as in totality or in part > > it can be > > > on the network. > > > > > > Would you agree with that? I do not know if is good English > > and very > > > accurate. But people caught the concept immediately. > > > > To me, an OPES callout server is a plugin into OPES > > processor. OPES, as a whole, is a proxy service, possibly a > > content modifying proxy service. It may be viewed as a plugin > > into an application protocol proxy, to a certain extent. > > > > Alex. > > > ------_=_NextPart_001_01C2E1C8.9EC30F0C Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: plug-out?

e-mail problems,
resending
abbie

> -----Original Message-----
> From:
> Sent: Monday, March 03, 2003 2:36 PM
> To: '=3DSMTP:rousskov@measurement-factory.com'; =
> '=3DSMTP:ietf-openproxy@imc.org'
> Subject: RE: plug-out?
>
>
>
> Alex,
> I do agree with what u said.
> plus, I would like for us to stop mixing issues = by refereing
> to ONES. The work/place of is defined by the = charter.
>
> To me OPES is a proxy on Viagra (that includes = the callout server too)
>
> abbie
>
>
> 
> > -----Original Message-----
> > From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> > Sent: Monday, March 03, 2003 2:06 = PM
> > To: OPES Group
> > Subject: Re: plug-out?
> >
> >
> >
> > On Sun, 2 Mar 2003, jfcm wrote:
> >
> > > I had to explain what is an OPES to = developers today, and I
> > came with
> > > the formula, it is a = "plug-out". That is the same as a plug-in
> > > function, but on the network side as = in totality or in part
> > it can be
> > > on the network.
> > >
> > > Would you agree with that? I do not = know if is good English
> > and very
> > > accurate. But people caught the = concept immediately.
> >
> > To me, an OPES callout server is a plugin = into OPES
> > processor. OPES, as a whole, is a proxy = service, possibly a
> > content modifying proxy service. It may be = viewed as a plugin
> > into an application protocol proxy, to a = certain extent.
> >
> > Alex.
> >
>

------_=_NextPart_001_01C2E1C8.9EC30F0C-- From owner-ietf-openproxy@mail.imc.org Tue Mar 4 20:41: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 UAA18458 for ; Tue, 4 Mar 2003 20:41:30 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2519ji27639 for ietf-openproxy-bks; Tue, 4 Mar 2003 17:09:45 -0800 (PST) Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2519iX27632 for ; Tue, 4 Mar 2003 17:09:44 -0800 (PST) Received: from f11v-4-53.d1.club-internet.fr ([213.44.163.53] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 18qNPl-00019F-00 for ietf-openproxy@imc.org; Tue, 04 Mar 2003 17:09:46 -0800 Message-Id: <5.2.0.9.0.20030305011739.029762b0@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 05 Mar 2003 01:21:29 +0100 To: ietf-openproxy@imc.org From: jfcm Subject: is IDNA an OPES? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - 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 would like to know if you consider the IDNA process as an OPES or not. It changes data in the flow from the user's point of view. The reason why I ask is that the plug-in used to support IDNA may be used for other purposes as well (as a dispatcher), support OPES management and be a candidate for callout protocol - for example to support DNS like services. An example is the "go:" scheme ftp://ftp.rfc-editor.org/in-notes/rfc3368.txt jfc From owner-ietf-openproxy@mail.imc.org Tue Mar 4 20:43: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 UAA18481 for ; Tue, 4 Mar 2003 20:43:07 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2519kq27643 for ietf-openproxy-bks; Tue, 4 Mar 2003 17:09:46 -0800 (PST) Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2519jX27638 for ; Tue, 4 Mar 2003 17:09:45 -0800 (PST) Received: from f11v-4-53.d1.club-internet.fr ([213.44.163.53] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 18qNPn-00019F-00 for ietf-openproxy@imc.org; Tue, 04 Mar 2003 17:09:48 -0800 Message-Id: <5.2.0.9.0.20030305014943.02ce8400@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 05 Mar 2003 01:49:49 +0100 To: ietf-openproxy@imc.org From: jfcm Subject: RE: plug-out? 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:25 03/03/03, chen@research.att.com said: >The notion of "plug-out" does not seem to convey the key OPES concept >that an OPES entity operates on a data flow between a data provider and >a data consumer. > >On the other hand, the concept (not sure about the English) perhaps >applies well in explaining Web Services? Totally right (my Frenglish made me to thing in/out as location rather than the way they are used). I used your image in a Web Service presentation. It worked just fine. I followed you advice to and compared OPES to "converters", and detailed talking about filter and transformer for the dispatcher and callout server. Was immediately understood. Is that better and acceptable English/image? jfc From owner-ietf-openproxy@mail.imc.org Wed Mar 5 09:15: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 JAA00932 for ; Wed, 5 Mar 2003 09:15:38 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h25DjQM21932 for ietf-openproxy-bks; Wed, 5 Mar 2003 05:45:26 -0800 (PST) Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h25DjP321928 for ; Wed, 5 Mar 2003 05:45:26 -0800 (PST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h25DjGd19367; Wed, 5 Mar 2003 08:45:16 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Mar 2003 08:45:17 -0500 Message-ID: <87609AFB433BD5118D5E0002A52CD754050ED1D5@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: jfcm , ietf-openproxy@imc.org Subject: RE: is IDNA an OPES? Date: Wed, 5 Mar 2003 08:45:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E31D.745B175E" 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_01C2E31D.745B175E Content-Type: text/plain jfcm, I would like you to really have a definition of the IDNA and then compare it to see if it fits within our charter. We have a very focused charter and we have to stick with it. This is not to say that good ideas are not in IDNA. After we complete the first set of deliverable, the time will arrive when we need to recharter. These ideas can be used in that activity. thanks abbie > -----Original Message----- > From: jfcm [mailto:info@utel.net] > Sent: Tuesday, March 04, 2003 7:21 PM > To: ietf-openproxy@imc.org > Subject: is IDNA an OPES? > > > > I would like to know if you consider the IDNA process as an > OPES or not. It > changes data in the flow from the user's point of view. The > reason why I > ask is that the plug-in used to support IDNA may be used for > other purposes > as well (as a dispatcher), support OPES management and be a > candidate for > callout protocol - for example to support DNS like services. > An example is > the "go:" scheme ftp://ftp.rfc-editor.org/in-notes/rfc3368.txt > jfc > > ------_=_NextPart_001_01C2E31D.745B175E Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: is IDNA an OPES?

jfcm,

I would like you to really have a definition of the = IDNA and then compare it to see if it fits within our charter.

We have a very focused charter and we have to stick = with it.

This is not to say that good ideas are not in = IDNA.

After we complete the first set of deliverable, the = time will arrive when we need to recharter.
These ideas can be used in that activity.

thanks

abbie


> -----Original Message-----
> From: jfcm [mailto:info@utel.net]
> Sent: Tuesday, March 04, 2003 7:21 PM
> To: ietf-openproxy@imc.org
> Subject: is IDNA an OPES?
>
>
>
> I would like to know if you consider the IDNA = process as an
> OPES or not. It
> changes data in the flow from the user's point = of view. The
> reason why I
> ask is that the plug-in used to support IDNA = may be used for
> other purposes
> as well (as a dispatcher), support OPES = management and be a
> candidate for
> callout protocol - for example to support DNS = like services.
> An example is
> the "go:" scheme ftp://ftp.rfc-editor.org/in-notes/rfc3368.txt
> jfc
>
>

------_=_NextPart_001_01C2E31D.745B175E-- From owner-ietf-openproxy@mail.imc.org Wed Mar 5 13:30:27 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 NAA20373 for ; Wed, 5 Mar 2003 13:30:20 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h25HsNB04645 for ietf-openproxy-bks; Wed, 5 Mar 2003 09:54:23 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h25HsM304640 for ; Wed, 5 Mar 2003 09:54:22 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h25HsOnx019969 for ; Wed, 5 Mar 2003 10:54:24 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h25HsNvO019968; Wed, 5 Mar 2003 10:54:23 -0700 (MST) (envelope-from rousskov) Date: Wed, 5 Mar 2003 10:54:23 -0700 (MST) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: is IDNA an OPES? In-Reply-To: <5.2.0.9.0.20030305011739.029762b0@mail.utel.net> Message-ID: References: <5.2.0.9.0.20030305011739.029762b0@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, 5 Mar 2003, jfcm wrote: > I would like to know if you consider the IDNA process as an OPES or > not. It changes data in the flow from the user's point of view. I assume that by IDNA you mean draft-ietf-idn-idna-14.txt. I also assume that by "IDNA process" you mean ToASCII and ToUnicode conversions documented in the above draft. If so, then I think it is possible to have an OPES system that, for example, does ToASCII and ToUnicode conversions for HTTP Request-URIs and Host headers. However, I think that such a system would have to be tightly integrated with the application proxy itself, loosing primary advantages (and design goals) of OPES. I will try to explain below. From a [very] quick scan of the IDNA draft, it appears that the authors want user applications (not intermediaries) to do the conversion. The latter makes a lot of sense because unconverted names in protocol messages may produce illegal messages and illegal messages may be dropped before they reach OPES processor. In other words, OPES is designed to adapt valid application messages. Application messages with raw international domain names are likely to be invalid for many protocols (e.g., HTTP). Thus, while it is possible to design a specific OPES-based system for IDNA conversions in some environments, OPES and IDNA do not play well together in general. Disclaimer: I am by no means an expert on IDNA. I just looked through the draft! Please correct me if I am wrong. $0.02, Alex. From owner-ietf-openproxy@mail.imc.org Wed Mar 5 14:52:53 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 OAA25202 for ; Wed, 5 Mar 2003 14:52:52 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h25JOsm08966 for ietf-openproxy-bks; Wed, 5 Mar 2003 11:24:54 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h25JOr308962 for ; Wed, 5 Mar 2003 11:24:53 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h25JOtnx023099 for ; Wed, 5 Mar 2003 12:24:55 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h25JOt44023098; Wed, 5 Mar 2003 12:24:55 -0700 (MST) (envelope-from rousskov) Date: Wed, 5 Mar 2003 12:24:55 -0700 (MST) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: RE: is IDNA an OPES? In-Reply-To: <87609AFB433BD5118D5E0002A52CD754050ED7B2@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD754050ED7B2@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, 5 Mar 2003, Abbie Barbir wrote: > I really personally prefer to just used the term OPES as specified > by the charter. If IDNA can be a scenario, then it can be added. > However, I would like to avoid name confusion. Absolutely. I do not think jfc was proposing an OPES name change. I suspect the question was whether IDNA can be an OPES use case. Alex. From owner-ietf-openproxy@mail.imc.org Wed Mar 5 14:59: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 OAA25509 for ; Wed, 5 Mar 2003 14:59:14 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h25JI6p08696 for ietf-openproxy-bks; Wed, 5 Mar 2003 11:18:06 -0800 (PST) Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h25JI5308692 for ; Wed, 5 Mar 2003 11:18:05 -0800 (PST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h25JHsd19974; Wed, 5 Mar 2003 14:17:55 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Mar 2003 14:17:54 -0500 Message-ID: <87609AFB433BD5118D5E0002A52CD754050ED7B2@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Alex Rousskov , ietf-openproxy@imc.org Subject: RE: is IDNA an OPES? Date: Wed, 5 Mar 2003 14:17:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E34B.EBA26FBE" 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_01C2E34B.EBA26FBE Content-Type: text/plain Alex, good job. I really personally prefer to just used the term OPES as specified by the charter. If IDNA can be a scenario, then it can be added. However, I would like to avoid name confusion. abbie > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Wednesday, March 05, 2003 12:54 PM > To: ietf-openproxy@imc.org > Subject: Re: is IDNA an OPES? > > > > On Wed, 5 Mar 2003, jfcm wrote: > > > I would like to know if you consider the IDNA process as an OPES or > > not. It changes data in the flow from the user's point of view. > > I assume that by IDNA you mean draft-ietf-idn-idna-14.txt. I > also assume that by "IDNA process" you mean ToASCII and > ToUnicode conversions documented in the above draft. > > If so, then I think it is possible to have an OPES system > that, for example, does ToASCII and ToUnicode conversions for > HTTP Request-URIs and Host headers. However, I think that > such a system would have to be tightly integrated with the > application proxy itself, loosing primary advantages (and > design goals) of OPES. I will try to explain below. > > From a [very] quick scan of the IDNA draft, it appears that > the authors want user applications (not intermediaries) to do > the conversion. The latter makes a lot of sense because > unconverted names in protocol messages may produce illegal > messages and illegal messages may be dropped before they > reach OPES processor. > > In other words, OPES is designed to adapt valid application > messages. Application messages with raw international domain > names are likely to be invalid for many protocols (e.g., > HTTP). Thus, while it is possible to design a specific > OPES-based system for IDNA conversions in some environments, > OPES and IDNA do not play well together in general. > > Disclaimer: I am by no means an expert on IDNA. I just looked > through the draft! Please correct me if I am wrong. > > $0.02, > > Alex. > ------_=_NextPart_001_01C2E34B.EBA26FBE Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: is IDNA an OPES?

Alex,

good job.

I really personally prefer to just used the term OPES = as specified by the charter. If IDNA can be a scenario, then it can be = added. However, I would like to avoid name confusion.


abbie


> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Wednesday, March 05, 2003 12:54 PM
> To: ietf-openproxy@imc.org
> Subject: Re: is IDNA an OPES?
>
>
>
> On Wed, 5 Mar 2003, jfcm wrote:
>
> > I would like to know if you consider the = IDNA process as an OPES or
> > not. It changes data in the flow from the = user's point of view.
>
> I assume that by IDNA you mean = draft-ietf-idn-idna-14.txt. I
> also assume that by "IDNA process" = you mean ToASCII and
> ToUnicode conversions documented in the above = draft.
>
> If so, then I think it is possible to have an = OPES system
> that, for example, does ToASCII and ToUnicode = conversions for
> HTTP Request-URIs and Host headers. However, I = think that
> such a system would have to be tightly = integrated with the
> application proxy itself, loosing primary = advantages (and
> design goals) of OPES. I will try to explain = below.
>
> From a [very] quick scan of the IDNA draft, it = appears that
> the authors want user applications (not = intermediaries) to do
> the conversion. The latter makes a lot of sense = because
> unconverted names in protocol messages may = produce illegal
> messages and illegal messages may be dropped = before they
> reach OPES processor.
>
> In other words, OPES is designed to adapt valid = application
> messages. Application messages with raw = international domain
> names are likely to be invalid for many = protocols (e.g.,
> HTTP). Thus, while it is possible to design a = specific
> OPES-based system for IDNA conversions in some = environments,
> OPES and IDNA do not play well together in = general.
>
> Disclaimer: I am by no means an expert on IDNA. = I just looked
> through the draft! Please correct me if I am = wrong.
>
> $0.02,
>
> Alex.
>

------_=_NextPart_001_01C2E34B.EBA26FBE-- From owner-ietf-openproxy@mail.imc.org Wed Mar 5 17:29: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 RAA02971 for ; Wed, 5 Mar 2003 17:29:34 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h25Lpar18025 for ietf-openproxy-bks; Wed, 5 Mar 2003 13:51:36 -0800 (PST) Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h25LpZ318020 for ; Wed, 5 Mar 2003 13:51:35 -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 h25MSPnV004446; Wed, 5 Mar 2003 15:28:26 -0700 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h25Kdqc13487; Wed, 5 Mar 2003 13:39:52 -0700 Date: Wed, 5 Mar 2003 13:39:52 -0700 Message-Id: <200303052039.h25Kdqc13487@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: rousskov@measurement-factory.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage Subject: Re: is IDNA an OPES? Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I haven't read the IDNA draft either, but I'll accept your analysis and quibble a little with the characterization of OPES as acting only on "valid application messages". One value of proxies is the ability to deal with commonly malformed requests and responses - things that were not well described in the application specification and lead to unneccessary loss of interoperability. Being that this kind of fixup is a reasonable proxy function, it should also be a valid OPES function. So, I'd think IDNA may well be an OPES scenario. Hilarie From owner-ietf-openproxy@mail.imc.org Wed Mar 5 21:33: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 VAA10504 for ; Wed, 5 Mar 2003 21:33:13 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2622M325404 for ietf-openproxy-bks; Wed, 5 Mar 2003 18:02:22 -0800 (PST) Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2622L325400 for ; Wed, 5 Mar 2003 18:02:21 -0800 (PST) Received: from f05v-18-148.d1.club-internet.fr ([212.194.197.148] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 18qkiA-0006C6-00 for ietf-openproxy@imc.org; Wed, 05 Mar 2003 18:02:19 -0800 Message-Id: <5.2.0.9.0.20030305210955.03897920@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 06 Mar 2003 03:01:30 +0100 To: ietf-openproxy@imc.org From: jfcm Subject: Re: is IDNA an OPES? In-Reply-To: References: <5.2.0.9.0.20030305011739.029762b0@mail.utel.net> <5.2.0.9.0.20030305011739.029762b0@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 18:54 05/03/03, Alex Rousskov said: >On Wed, 5 Mar 2003, jfcm wrote: > > > I would like to know if you consider the IDNA process as an OPES or > > not. It changes data in the flow from the user's point of view. > >I assume that by IDNA you mean draft-ietf-idn-idna-14.txt. I also >assume that by "IDNA process" you mean ToASCII and ToUnicode >conversions documented in the above draft. It is now a Standard. >If so, then I think it is possible to have an OPES system that, for >example, does ToASCII and ToUnicode conversions for HTTP Request-URIs >and Host headers. This is the way it works today. >However, I think that such a system would have to be >tightly integrated with the application proxy itself, loosing primary >advantages (and design goals) of OPES. I will try to explain below. Not tighen. In close control. > >From a [very] quick scan of the IDNA draft, it appears that the >authors want user applications (not intermediaries) to do the >conversion. The latter makes a lot of sense because unconverted names >in protocol messages may produce illegal messages and illegal messages >may be dropped before they reach OPES processor. > >In other words, OPES is designed to adapt valid application messages. That is the whole question. As you may have noted IDNA only solves a small part of the IDN support. It does not solve all the numerous cases indicated in the document, it does not solves vernacular, it does not solve soundex etc., it does not solve multilingual TLDs. This can only be addressed by a value added controller, which is then the user application. That application is entered through the browser and triggered through the brother. So it is an OPES for the user, but logically it is a parallel process - what has not bee, though up-to-now? Other services can be proposed the same way, like abbreviated DN entry (for years I do not enter the http:// and the browser adds it, but I could not enter my favorite TLD and a parallel process add it)? This leads ton consider which piece of code will be supporting the callout protocol? The browser, the plug-in? jfc From owner-ietf-openproxy@mail.imc.org Wed Mar 5 22:18:07 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 WAA11247 for ; Wed, 5 Mar 2003 22:18:06 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h262quS26842 for ietf-openproxy-bks; Wed, 5 Mar 2003 18:52:56 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h262qt326838 for ; Wed, 5 Mar 2003 18:52:55 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h262qwnx033475 for ; Wed, 5 Mar 2003 19:52:58 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h262qwq5033474; Wed, 5 Mar 2003 19:52:58 -0700 (MST) (envelope-from rousskov) Date: Wed, 5 Mar 2003 19:52:58 -0700 (MST) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: is IDNA an OPES? In-Reply-To: <200303052039.h25Kdqc13487@localhost.localdomain> Message-ID: References: <200303052039.h25Kdqc13487@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, 5 Mar 2003, The Purple Streak, Hilarie Orman wrote: > I haven't read the IDNA draft either, but I'll accept your analysis > and quibble a little with the characterization of OPES as acting only > on "valid application messages". By "valid" I mean "parsable", essentially. Handling slightly malformed or semantically questionable messages is an [unfortunate] MUST for modern systems, of course. My understanding is that raw international addresses will not be parsable by most existing systems; that is why we may need IDNA. Alex. From owner-ietf-openproxy@mail.imc.org Wed Mar 5 22:21: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 WAA11295 for ; Wed, 5 Mar 2003 22:21:53 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h262wUK26932 for ietf-openproxy-bks; Wed, 5 Mar 2003 18:58:30 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h262wT326926 for ; Wed, 5 Mar 2003 18:58:29 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h262wXnx033592 for ; Wed, 5 Mar 2003 19:58:33 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h262wXYk033591; Wed, 5 Mar 2003 19:58:33 -0700 (MST) (envelope-from rousskov) Date: Wed, 5 Mar 2003 19:58:33 -0700 (MST) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: is IDNA an OPES? In-Reply-To: <5.2.0.9.0.20030305210955.03897920@mail.utel.net> Message-ID: References: <5.2.0.9.0.20030305011739.029762b0@mail.utel.net> <5.2.0.9.0.20030305011739.029762b0@mail.utel.net> <5.2.0.9.0.20030305210955.03897920@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: OPES protocol is not meant to be a general-purpose plugin interface. What you describe is a good application for a browser plugin, not for a proxy plugin (for the reasons I mentioned). OPES protocol is a proxy plugin interface. Again, it is _possible_ to use OPES framework in a browser, but it is probably not the best way to implement a browser plugin. Alex. On Thu, 6 Mar 2003, jfcm wrote: > > On 18:54 05/03/03, Alex Rousskov said: > >On Wed, 5 Mar 2003, jfcm wrote: > > > > > I would like to know if you consider the IDNA process as an OPES or > > > not. It changes data in the flow from the user's point of view. > > > >I assume that by IDNA you mean draft-ietf-idn-idna-14.txt. I also > >assume that by "IDNA process" you mean ToASCII and ToUnicode > >conversions documented in the above draft. > > It is now a Standard. > > >If so, then I think it is possible to have an OPES system that, for > >example, does ToASCII and ToUnicode conversions for HTTP Request-URIs > >and Host headers. > > This is the way it works today. > > >However, I think that such a system would have to be > >tightly integrated with the application proxy itself, loosing primary > >advantages (and design goals) of OPES. I will try to explain below. > > Not tighen. In close control. > > > >From a [very] quick scan of the IDNA draft, it appears that the > >authors want user applications (not intermediaries) to do the > >conversion. The latter makes a lot of sense because unconverted names > >in protocol messages may produce illegal messages and illegal messages > >may be dropped before they reach OPES processor. > > > >In other words, OPES is designed to adapt valid application messages. > > That is the whole question. As you may have noted IDNA only solves > a small part of the IDN support. It does not solve all the numerous > cases indicated in the document, it does not solves vernacular, it > does not solve soundex etc., it does not solve multilingual TLDs. > This can only be addressed by a value added controller, which is > then the user application. That application is entered through the > browser and triggered through the brother. So it is an OPES for > the user, but logically it is a parallel process - what has not bee, > though up-to-now? > > Other services can be proposed the same way, like abbreviated > DN entry (for years I do not enter the http:// and the browser adds it, > but I could not enter my favorite TLD and a parallel process add it)? > > This leads ton consider which piece of code will be supporting the > callout protocol? The browser, the plug-in? > > jfc > > From owner-ietf-openproxy@mail.imc.org Thu Mar 6 10:12: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 KAA19373 for ; Thu, 6 Mar 2003 10:12:43 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h26Eiqu22170 for ietf-openproxy-bks; Thu, 6 Mar 2003 06:44:52 -0800 (PST) Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h26Eip322166 for ; Thu, 6 Mar 2003 06:44:51 -0800 (PST) Received: from f16m-1-155.d1.club-internet.fr ([212.195.112.155] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 18qwc3-0000gn-00 for ietf-openproxy@imc.org; Thu, 06 Mar 2003 06:44:47 -0800 Message-Id: <5.2.0.9.0.20030306142430.03d1a050@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 06 Mar 2003 15:15:46 +0100 To: ietf-openproxy@imc.org From: jfcm Subject: Re: is IDNA an OPES? In-Reply-To: References: <5.2.0.9.0.20030305210955.03897920@mail.utel.net> <5.2.0.9.0.20030305011739.029762b0@mail.utel.net> <5.2.0.9.0.20030305011739.029762b0@mail.utel.net> <5.2.0.9.0.20030305210955.03897920@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 will not make a big point of this as it concerns real life and we will see how the users will behave in front of real life solutions. On 03:58 06/03/03, Alex Rousskov said: >OPES protocol is not meant to be a general-purpose plugin interface. I do not see how an OPES protocol (between dispatcher/server) can be an interface? You mean "plugin access protocol"? The callout protocol, if it is good; may be used between the user control system (see below) and its related servers. It may also copy from it if the user control system comes first. What may be/is is the case. >What you describe is a good application for a browser plugin, Again, the browser has NOTHING to do in here. You introduced it. I talked about IDNA and you decided IDNA was on the browser. I only say it is an application on the process which consistently manages the transcriptions of UTF-8 entries into ACE labels. for web, mail, ftp, etc Many IDNA may exist on a machine, only one can do it consistently and hopefully completely. I will chose to name the place where that process is triggered the "user control system" (because I observe on the market that it is what is proposed/under proposition). The user control system should by essence not be an application of the browser. The browser should be a peripheral of it, or it should run in parallel to the browser and use it as a screen. The reason why I asked about IDNA is that today the only service in use for what I name here the user control system is IDNA. But nothing prevents us to deploy and test others. >not for a proxy plugin (for the reasons I mentioned). OPES protocol is a proxy >plugin interface. Again, it is _possible_ to use OPES framework in a >browser, but it is probably not the best way to implement a browser >plugin. Please let forget your browser. The browser is only the screen. You may understand that the first thing a user control system need is a consistent interface with its environment and with the users. This means first an universal language. Up to now universal language was ASCII. With IDNA it becomes possibly ML (Multilingual). IDNA is a first step. It only partly solves the Right Hand Side (not the TLDs). Now is under discussion the LHS (on the left of the "@" in a mail address). But the real issue is the whole URL. You may accept that if there is a process which needs to get ML support of LHS, RHS and URL, it is likely it will act as a server for the other tools. That ML server can be though as an application of an "ucs" designed as a dispatcher or as a server called by that dispatcher. After talking with the user, the system must talk with the world. This means to utilize a resolver. If there are new services supported by the user control system, we may assume there are new needs to be supported. Hence the need to investigate DNS.2 (different use and architecture) and DNS+ (new services). The the next step is about the relation of the user control system with other applications; namely the web and the web services applications. This leads to the support of applications today already partly supported in the browser but not consistently open to all the application on the machine (like the ldap:, the go: etc. schemes). The last step is the relation of the user control system (dispatcher) with other dispatchers: OPES on the path of the flows or other user control systems, the user control system is in relation with. This may be on the fly. This may also be a lasting cooperation, with shared services. I call them ONES because they are open (to several users choosing them), networked, they extend the capacity of the relation, with its own processing assistance, into a computer assisted networked continuity of services. >Alex. > >On Thu, 6 Mar 2003, jfcm wrote: > > > > > On 18:54 05/03/03, Alex Rousskov said: > > >On Wed, 5 Mar 2003, jfcm wrote: > > > > > > > I would like to know if you consider the IDNA process as an OPES or > > > > not. It changes data in the flow from the user's point of view. > > > > > >I assume that by IDNA you mean draft-ietf-idn-idna-14.txt. I also > > >assume that by "IDNA process" you mean ToASCII and ToUnicode > > >conversions documented in the above draft. > > > > It is now a Standard. > > > > >If so, then I think it is possible to have an OPES system that, for > > >example, does ToASCII and ToUnicode conversions for HTTP Request-URIs > > >and Host headers. > > > > This is the way it works today. > > > > >However, I think that such a system would have to be > > >tightly integrated with the application proxy itself, loosing primary > > >advantages (and design goals) of OPES. I will try to explain below. > > > > Not tighen. In close control. > > > > > >From a [very] quick scan of the IDNA draft, it appears that the > > >authors want user applications (not intermediaries) to do the > > >conversion. The latter makes a lot of sense because unconverted names > > >in protocol messages may produce illegal messages and illegal messages > > >may be dropped before they reach OPES processor. > > > > > >In other words, OPES is designed to adapt valid application messages. > > > > That is the whole question. As you may have noted IDNA only solves > > a small part of the IDN support. It does not solve all the numerous > > cases indicated in the document, it does not solves vernacular, it > > does not solve soundex etc., it does not solve multilingual TLDs. > > This can only be addressed by a value added controller, which is > > then the user application. That application is entered through the > > browser and triggered through the brother. So it is an OPES for > > the user, but logically it is a parallel process - what has not bee, > > though up-to-now? > > > > Other services can be proposed the same way, like abbreviated > > DN entry (for years I do not enter the http:// and the browser adds it, > > but I could not enter my favorite TLD and a parallel process add it)? > > > > This leads ton consider which piece of code will be supporting the > > callout protocol? The browser, the plug-in? > > > > jfc > > > > > > > > >--- >Incoming mail is certified Virus Free. >Checked by AVG anti-virus system (http://www.grisoft.com). >Version: 6.0.454 / Virus Database: 253 - Release Date: 10/02/03 From owner-ietf-openproxy@mail.imc.org Thu Mar 6 21:01: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 VAA23994 for ; Thu, 6 Mar 2003 21:01:33 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h271Q0723773 for ietf-openproxy-bks; Thu, 6 Mar 2003 17:26:00 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h271Pw323769 for ; Thu, 6 Mar 2003 17:25:58 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h271Q1nx065877 for ; Thu, 6 Mar 2003 18:26:01 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h271Q1GW065876; Thu, 6 Mar 2003 18:26:01 -0700 (MST) (envelope-from rousskov) Date: Thu, 6 Mar 2003 18:26:01 -0700 (MST) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: is IDNA an OPES? In-Reply-To: <5.2.0.9.0.20030306142430.03d1a050@mail.utel.net> Message-ID: References: <5.2.0.9.0.20030305210955.03897920@mail.utel.net> <5.2.0.9.0.20030305011739.029762b0@mail.utel.net> <5.2.0.9.0.20030305011739.029762b0@mail.utel.net> <5.2.0.9.0.20030305210955.03897920@mail.utel.net> <5.2.0.9.0.20030306142430.03d1a050@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, 6 Mar 2003, jfcm wrote: > On 03:58 06/03/03, Alex Rousskov said: > > >OPES protocol is not meant to be a general-purpose plugin interface. > > I do not see how an OPES protocol (between dispatcher/server) can be > an interface? You mean "plugin access protocol"? Any protocol is an interface. In our case, the interface lets integrators plug a callout server into an OPES processor. In the IDNA case, there could be a browser plugin protocol/interface that lets users add IDNA conversion plugins to their browsers (without modifying browser software or the plugin, of course). > >What you describe is a good application for a browser plugin, > > Again, the browser has NOTHING to do in here. You introduced it. > I talked about IDNA and you decided IDNA was on the browser. I did not decide. I just suggested it as an example of where IDNA conversion would work well. According to IDNA draft, IDNA conversions are done in a user application. A browser is a well-known user application. It is just an example. > I only say it is an application on the process which consistently > manages the transcriptions of UTF-8 entries into ACE labels. > for web, mail, ftp, etc Many IDNA may exist on a machine, only > one can do it consistently and hopefully completely. I will chose > to name the place where that process is triggered the "user > control system" (because I observe on the market that it is > what is proposed/under proposition). > > The user control system should by essence not be an > application of the browser. The browser should be a peripheral > of it, or it should run in parallel to the browser and use it > as a screen. In your example, the IDNA conversion software is plugged into the "user system" and other system components (such as browser) may recognize and use it as necessary (probably via some kind of "plugin" service interface). That's a fine example, and I suspect that is how many new/patched systems could support IDNAs. Still, my reasoning remains valid, I think: One cannot do IDNA conversions outside of the user application (the application can, of course, use "user system" resources like in your example, but that does not change anything). This limitation puts IDNA out of OPES scope because "users" and their applications are out of OPES scope. Again, OPES is a proxy service. IDNA conversion (in both your and my examples) is not. I am just trying to answer your original question (see the Subject: line)... [ good stuff about user control systems snipped ] > The callout protocol, if it is good; may be used between the > user control system (see below) and its related servers. It > may also copy from it if the user control system comes first. > What may be/is is the case. ... > The last step is the relation of the user control system > (dispatcher) with other dispatchers: OPES on the path of the flows > or other user control systems, the user control system is in > relation with. This may be on the fly. This may also be a lasting > cooperation, with shared services. I call them ONES because they are > open (to several users choosing them), networked, they extend the > capacity of the relation, with its own processing assistance, into a > computer assisted networked continuity of services. It looks like you are investigating whether user control systems can benefit from talking to OPES agents and how such communication might change OPES. If that is your motivation, this group should certainly consider any new requirements that your use cases may mean to OPES. You have to drive this discussion though (e.g., by submitting OPES-specific use cases or requirements). Are you saying that IDNA conversion has some influence on OPES? If yes, what is that influence? If no, why are we talking about IDNA (should we talk about user control systems instead?)? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Fri Mar 7 12:19: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 MAA18040 for ; Fri, 7 Mar 2003 12:19:13 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h27Gpb604577 for ietf-openproxy-bks; Fri, 7 Mar 2003 08:51:37 -0800 (PST) Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h27Gpa304569 for ; Fri, 7 Mar 2003 08:51:36 -0800 (PST) Received: from f07v-2-186.d1.club-internet.fr ([212.194.133.186] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 18rL4H-0000kO-00 for ietf-openproxy@imc.org; Fri, 07 Mar 2003 08:51:34 -0800 Message-Id: <5.2.0.9.0.20030307170536.02502290@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 07 Mar 2003 17:25:44 +0100 To: ietf-openproxy@imc.org From: jfcm Subject: Re: is IDNA an OPES? In-Reply-To: References: <5.2.0.9.0.20030306142430.03d1a050@mail.utel.net> <5.2.0.9.0.20030305210955.03897920@mail.utel.net> <5.2.0.9.0.20030305011739.029762b0@mail.utel.net> <5.2.0.9.0.20030305011739.029762b0@mail.utel.net> <5.2.0.9.0.20030305210955.03897920@mail.utel.net> <5.2.0.9.0.20030306142430.03d1a050@mail.utel.net> Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-5930995; boundary="=======D9517F1=======" 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: --=======D9517F1======= Content-Type: text/plain; x-avg-checked=avg-ok-5930995; charset=us-ascii; format=flowed Content-Transfer-Encoding: 8bit At 02:26 07/03/03, Alex Rousskov wrote: >On Thu, 6 Mar 2003, jfcm wrote: > > On 03:58 06/03/03, Alex Rousskov said: > > >OPES protocol is not meant to be a general-purpose plugin interface. > > I do not see how an OPES protocol (between dispatcher/server) can be > > an interface? You mean "plugin access protocol"? > >Any protocol is an interface. In our case, the interface lets >integrators plug a callout server into an OPES processor. In the IDNA >case, there could be a browser plugin protocol/interface that lets >users add IDNA conversion plugins to their browsers (without modifying >browser software or the plugin, of course). Accepted. Unfortunately not the case. Hence my question. IDNA is an accepted universal need. The initial support of the IDNA and probably for still some time is through a plugin. That plugin is of no real interest if it is a browser oriented service, because was is really needed is resolver front-end, for all the local applications. However if the IDNA is accepted as an OPES service on the http and the smtp path, we may specify and see implemented callout protocol on the http/smtp output. Actually offering a hook for many other services hosted on the very machine of the user/provider. > > >What you describe is a good application for a browser plugin, > > > > Again, the browser has NOTHING to do in here. You introduced it. > > I talked about IDNA and you decided IDNA was on the browser. > >I did not decide. I just suggested it as an example of where IDNA >conversion would work well. According to IDNA draft, IDNA conversions >are done in a user application. A browser is a well-known user >application. It is just an example. > > > I only say it is an application on the process which consistently > > manages the transcriptions of UTF-8 entries into ACE labels. > > for web, mail, ftp, etc Many IDNA may exist on a machine, only > > one can do it consistently and hopefully completely. I will chose > > to name the place where that process is triggered the "user > > control system" (because I observe on the market that it is > > what is proposed/under proposition). > > > > The user control system should by essence not be an > > application of the browser. The browser should be a peripheral > > of it, or it should run in parallel to the browser and use it > > as a screen. > >In your example, the IDNA conversion software is plugged into the >"user system" and other system components (such as browser) may >recognize and use it as necessary (probably via some kind of "plugin" >service interface). That's a fine example, and I suspect that is how >many new/patched systems could support IDNAs. > >Still, my reasoning remains valid, I think: One cannot do IDNA >conversions outside of the user application (the application can, of >course, use "user system" resources like in your example, but that >does not change anything). This limitation puts IDNA out of OPES scope >because "users" and their applications are out of OPES scope. Again, >OPES is a proxy service. IDNA conversion (in both your and my >examples) is not. Your reasoning is valid as long as you decide that the IDNA application applies to the browser or to the mail agent. I say that the IDNA is far better located at the user control system because the IDNA is actually one small building block of the IRL (Internationalized URL) of which the other services will not be standardized before long, while they start being widely used. >I am just trying to answer your original question (see the Subject: >line)... I fully understand. I also consider that this may be the last chance to see the real IDNA being specified by the IETF before it comes out of control. >[ good stuff about user control systems snipped ] > > > The callout protocol, if it is good; may be used between the > > user control system (see below) and its related servers. It > > may also copy from it if the user control system comes first. > > What may be/is is the case. >... > > The last step is the relation of the user control system > > (dispatcher) with other dispatchers: OPES on the path of the flows > > or other user control systems, the user control system is in > > relation with. This may be on the fly. This may also be a lasting > > cooperation, with shared services. I call them ONES because they are > > open (to several users choosing them), networked, they extend the > > capacity of the relation, with its own processing assistance, into a > > computer assisted networked continuity of services. > >It looks like you are investigating whether user control systems can >benefit from talking to OPES agents and how such communication might >change OPES. If that is your motivation, this group should certainly >consider any new requirements that your use cases may mean to OPES. Yes. But the first question is: is the user control system as I define it an OPES dispatcher as it seems it may do a lot of things that OPES are not supposed to do: - change the URL (redirect) - be multilingual (IDNA++) - interact with the user - keep permanent user informations, etc. But at the same time it may relate with services in using the callout protocol, interact with other dispatchers, etc. >You have to drive this discussion though (e.g., by submitting >OPES-specific use cases or requirements). Are you saying that IDNA >conversion has some influence on OPES? If yes, what is that >influence? If no, why are we talking about IDNA (should we talk about >user control systems instead?)? You keep asking me to discuss cases. So I proposed a case. That case is also a very current issue. But certainly the universal multilingual standalone user control system is an issue of real interest. I think that its immediate interest could be to permit to define, implement and test the upper level of the callout protocol: I mean through local interactions withe services. jfc --=======D9517F1======= Content-Type: text/plain; charset=us-ascii; x-avg=cert; x-avg-checked=avg-ok-5930995 Content-Disposition: inline --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.459 / Virus Database: 258 - Release Date: 25/02/03 --=======D9517F1=======-- From owner-ietf-openproxy@mail.imc.org Fri Mar 7 13:40: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 NAA22025 for ; Fri, 7 Mar 2003 13:40:14 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h27IAj608677 for ietf-openproxy-bks; Fri, 7 Mar 2003 10:10:45 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h27IAh308671 for ; Fri, 7 Mar 2003 10:10:43 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h27IAinx089177 for ; Fri, 7 Mar 2003 11:10:44 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h27IAiqa089176; Fri, 7 Mar 2003 11:10:44 -0700 (MST) (envelope-from rousskov) Date: Fri, 7 Mar 2003 11:10:44 -0700 (MST) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: is IDNA an OPES? In-Reply-To: <5.2.0.9.0.20030307170536.02502290@mail.utel.net> Message-ID: References: <5.2.0.9.0.20030306142430.03d1a050@mail.utel.net> <5.2.0.9.0.20030305210955.03897920@mail.utel.net> <5.2.0.9.0.20030305011739.029762b0@mail.utel.net> <5.2.0.9.0.20030305011739.029762b0@mail.utel.net> <5.2.0.9.0.20030305210955.03897920@mail.utel.net> <5.2.0.9.0.20030306142430.03d1a050@mail.utel.net> <5.2.0.9.0.20030307170536.02502290@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, 7 Mar 2003, jfcm wrote: > However if the IDNA is accepted as an OPES service on the http and > the smtp path, we may specify and see implemented callout protocol > on the http/smtp output. Actually offering a hook for many other > services hosted on the very machine of the user/provider. My understanding is that IDNAs make HTTP messages malformed. Malformed messages cannot be transmitted reliably because non-IDNA-aware intermediaries may not forward them. Thus, one would have to change HTTP standard and/or HTTP applications to be able to use OPES for IDNA conversions within HTTP messages, under general assumptions. I suspect the same is true for SMTP, but I am not an SMTP expert. Inapplicability of the OPES approach to malformed messages is the only point I have been trying to make in this thread. If you want OPES to help with IDNA, how would you address the formatting (i.e., parsing) problem for protocols that do not allow raw IDNA addresses? Note that it is not an OPES problem, it is an application protocol problem. > Your reasoning is valid as long as you decide that the IDNA > application applies to the browser or to the mail agent. I say that > the IDNA is far better located at the user control system because > the IDNA is actually one small building block of the IRL > (Internationalized URL) of which the other services will not be > standardized before long, while they start being widely used. It does not matter were you place IDNA converter as long as it is outside of the application protocol path. For example, if your application protocol is HTTP, you cannot use IDNAs in HTTP requests, you must convert them before you get a valid HTTP request. Whether that conversion is done by a "system plugin" or "application plugin" is not important. IMO, you have two primary choices: - Perform IDNA conversions before you build messages for old/existing application protocols. You can invent a new protocol to do IDNA conversions. OPES will not apply to the old application protocol, but may help with the new/invented protocol (if any). - Change old/existing application protocols and their implementations so that messages containing IDNAs become valid. OPES will apply then. However, if all protocols and implementations are changed, then the need for IDNA conversion disappears. > But the first question is: is the user control system as I define it > an OPES dispatcher as it seems it may do a lot of things that OPES > are not supposed to do: > > - change the URL (redirect) possible (there is just no consensus whether OPES dispatcher or callout server can do that) > - be multilingual (IDNA++) irrelevant to OPES; it is the application protocol that must be multilingual, not OPES > - interact with the user possible to the extent the application protocol supports user interaction > - keep permanent user informations, etc. possible if the application protocol allows it > But at the same time it may relate with services in using the > callout protocol, interact with other dispatchers, etc. True. > >You have to drive this discussion though (e.g., by submitting > >OPES-specific use cases or requirements). Are you saying that IDNA > >conversion has some influence on OPES? If yes, what is that > >influence? If no, why are we talking about IDNA (should we talk about > >user control systems instead?)? > > You keep asking me to discuss cases. So I proposed a case. If your case is "IDNA conversions", I tried to evaluate it. If your case is "user control systems", you have to tell us what OPES-related requirements those systems have. > I think that its immediate interest could be to permit to define, > implement and test the upper level of the callout protocol: I mean > through local interactions withe services. Can you be more specific? Exactly what additional OPES functionality/features (beyond modification of application messages which is the current scope) do you want to support? Once we know your requirements, we can all discuss corresponding changes to the protocol. Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Fri Mar 7 13: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 NAA22077 for ; Fri, 7 Mar 2003 13:42:23 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h27IJsC09094 for ietf-openproxy-bks; Fri, 7 Mar 2003 10:19:54 -0800 (PST) Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h27IJr309090 for ; Fri, 7 Mar 2003 10:19:53 -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 h27IvGnT016888; Fri, 7 Mar 2003 11:57:16 -0700 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h27IKbA07832; Fri, 7 Mar 2003 11:20:37 -0700 Date: Fri, 7 Mar 2003 11:20:37 -0700 Message-Id: <200303071820.h27IKbA07832@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.20030307170536.02502290@mail.utel.net> Subject: Re: is IDNA an OPES? Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: A proxy can be co-located with an application, using the same protocol as if they were are different machines. However, this doesn't seem to be a preferred implementation method, probably due to the overhead involved. The more usual path is that someone defines an API that can be implemented through direct subroutine calls, and then extends this to work with RPC's for remotely located services. The advantage being, of course, that one can write the callout service once and have it run locally or remotely. I think most browsers are already extensible, in their own ways, and while it would be gratifying to have them switch to using a standard method that is compatible with OPES servces, I don't see much reason for that to happen. Our focus for the IETF is on services that benefit from running remotely - because the services are more efficient when amortized over many connections or some other engineering reason. Surely there are other kinds of services that could run either remotely or locally, or services that are best run locally, but these will have to grow and flourish without diverting the attention of this WG. It's fine to discuss such possibilities, but keep in mind that they cannot be the motivating examples for design decisions. Hilarie From owner-ietf-openproxy@mail.imc.org Fri Mar 7 14:10: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 OAA23663 for ; Fri, 7 Mar 2003 14:10:55 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h27IjQq09824 for ietf-openproxy-bks; Fri, 7 Mar 2003 10:45:26 -0800 (PST) Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h27IjP309820 for ; Fri, 7 Mar 2003 10:45:25 -0800 (PST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h27Ij8k09610; Fri, 7 Mar 2003 13:45:08 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Mar 2003 13:45:08 -0500 Message-ID: <87609AFB433BD5118D5E0002A52CD7540513FB08@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: "The Purple Streak, Hilarie Orman" , info@utel.net Cc: ietf-openproxy@imc.org Subject: RE: is IDNA an OPES? Date: Fri, 7 Mar 2003 13:45:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E4D9.ABF68A14" 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_01C2E4D9.ABF68A14 Content-Type: text/plain hi, +1 abbie > -----Original Message----- > From: The Purple Streak, Hilarie Orman [mailto:ho@alum.mit.edu] > Sent: Friday, March 07, 2003 1:21 PM > To: info@utel.net > Cc: ietf-openproxy@imc.org > Subject: Re: is IDNA an OPES? > > > > A proxy can be co-located with an application, using the same > protocol as if they were are different machines. However, > this doesn't seem to be a preferred implementation method, > probably due to the overhead involved. The more usual path > is that someone defines an API that can be implemented > through direct subroutine calls, and then extends this to > work with RPC's for remotely located services. The advantage > being, of course, that one can write the callout service once > and have it run locally or remotely. > > I think most browsers are already extensible, in their own > ways, and while it would be gratifying to have them switch to > using a standard method that is compatible with OPES servces, > I don't see much reason for that to happen. Our focus for > the IETF is on services that benefit from running remotely - > because the services are more efficient when amortized over > many connections or some other engineering reason. > > Surely there are other kinds of services that could run > either remotely or locally, or services that are best run > locally, but these will have to grow and flourish without > diverting the attention of this WG. It's fine to discuss > such possibilities, but keep in mind that they cannot be the > motivating examples for design decisions. > > Hilarie > > > ------_=_NextPart_001_01C2E4D9.ABF68A14 Content-Type: text/html RE: is IDNA an OPES?

hi,

+1

abbie

> -----Original Message-----
> From: The Purple Streak, Hilarie Orman [mailto:ho@alum.mit.edu]
> Sent: Friday, March 07, 2003 1:21 PM
> To: info@utel.net
> Cc: ietf-openproxy@imc.org
> Subject: Re: is IDNA an OPES?
>
>
>
> A proxy can be co-located with an application, using the same
> protocol as if they were are different machines.  However,
> this doesn't seem to be a preferred implementation method,
> probably due to the overhead involved.  The more usual path
> is that someone defines an API that can be implemented
> through direct subroutine calls, and then extends this to
> work with RPC's for remotely located services.  The advantage
> being, of course, that one can write the callout service once
> and have it run locally or remotely.
>
> I think most browsers are already extensible, in their own
> ways, and while it would be gratifying to have them switch to
> using a standard method that is compatible with OPES servces,
> I don't see much reason for that to happen.  Our focus for
> the IETF is on services that benefit from running remotely -
> because the services are more efficient when amortized over
> many connections or some other engineering reason. 
>
> Surely there are other kinds of services that could run
> either remotely or locally, or services that are best run
> locally, but these will have to grow and flourish without
> diverting the attention of this WG.  It's fine to discuss
> such possibilities, but keep in mind that they cannot be the
> motivating examples for design decisions.
>
> Hilarie
>
>
>

------_=_NextPart_001_01C2E4D9.ABF68A14-- From owner-ietf-openproxy@mail.imc.org Fri Mar 7 15:14:17 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 PAA27068 for ; Fri, 7 Mar 2003 15:14:16 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h27JliA13329 for ietf-openproxy-bks; Fri, 7 Mar 2003 11:47:44 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h27Jlg313324 for ; Fri, 7 Mar 2003 11:47:43 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h27Jljnx092462 for ; Fri, 7 Mar 2003 12:47:45 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h27JljaK092461; Fri, 7 Mar 2003 12:47:45 -0700 (MST) (envelope-from rousskov) Date: Fri, 7 Mar 2003 12:47:45 -0700 (MST) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: is IDNA an OPES? In-Reply-To: <200303071820.h27IKbA07832@localhost.localdomain> Message-ID: References: <200303071820.h27IKbA07832@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: Hilarie, I agree that WG primary focus should be on OPES services that are executed "remotely" rather than integrated into the proxy code. Such remote execution includes execution on the proxy box, of course. My understanding is that jfc wants to use remote OPES services as well. There seems to be no conflict here. As far as I can see, the problem is that we (well, myself, at least) are not sure what exactly jfc proposes as a potentially new use case or application area for OPES. It is clearly not just giving any single user application (e.g., a browser) an ability to talk OPES. The issue seems to be related to entire user-side systems communicating with OPES agents in yet unknown ways. I sense that we may be talking about a Universal Callout Interface for Web Services, but I do not have enough information to conclude that. Otherwise, I would already argue that the discussion should be terminated because no such interface can be built, not even by XML fans. Until we know exactly what jfc is after, I cannot say whether those new use cases can be "the motivating examples for design decisions" or not. I simply do not know what those new use cases are and what new requirements they bring (besides IDNA conversion that seems to be impossible in OPES framework). Perhaps others have a better understanding. Alex. On Fri, 7 Mar 2003, The Purple Streak, Hilarie Orman wrote: > > A proxy can be co-located with an application, using the same protocol > as if they were are different machines. However, this doesn't seem to > be a preferred implementation method, probably due to the overhead > involved. The more usual path is that someone defines an API that can > be implemented through direct subroutine calls, and then extends this > to work with RPC's for remotely located services. The advantage > being, of course, that one can write the callout service once and have > it run locally or remotely. > > I think most browsers are already extensible, in their own ways, and > while it would be gratifying to have them switch to using a standard > method that is compatible with OPES servces, I don't see much reason > for that to happen. Our focus for the IETF is on services that benefit > from running remotely - because the services are more efficient when > amortized over many connections or some other engineering reason. > > Surely there are other kinds of services that could run either > remotely or locally, or services that are best run locally, but these > will have to grow and flourish without diverting the attention of this > WG. It's fine to discuss such possibilities, but keep in mind that > they cannot be the motivating examples for design decisions. > > Hilarie From owner-ietf-openproxy@mail.imc.org Fri Mar 7 16:14: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 QAA04179 for ; Fri, 7 Mar 2003 16:14:05 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h27Kmbe18206 for ietf-openproxy-bks; Fri, 7 Mar 2003 12:48:37 -0800 (PST) Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h27Kma318201 for ; Fri, 7 Mar 2003 12:48:36 -0800 (PST) Received: from f16m-1-210.d1.club-internet.fr ([212.195.112.210] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 18rOlP-0000f7-00 for ietf-openproxy@imc.org; Fri, 07 Mar 2003 12:48:19 -0800 Message-Id: <5.2.0.9.0.20030307215011.0251d190@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 07 Mar 2003 21:55:01 +0100 To: ietf-openproxy@imc.org From: jfcm Subject: Re: is IDNA an OPES? Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-49F0375F; boundary="=======68DC2F3F=======" 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: --=======68DC2F3F======= Content-Type: text/plain; x-avg-checked=avg-ok-49F0375F; charset=us-ascii; format=flowed Content-Transfer-Encoding: 8bit Sorry was sent in reply to to Alex only. ------------------------------------------------------- OK. We can probably close the issue here in saying. 1. yes. A user control system can be an OPES dispatcher even if it is located on the same machine as the user. (for more discussion on the ucs cf. bottom) 2. yes. The IDNA may be considered as an OPES service, IF it is provided to several applications trough the dispatcher. 3. yes. The callout protocol may be used in that case. 4. no. the IDNA as such is NOT an OPES when it is only a part of an application 5. What should be investigated is the "user control system". cf. bottom. On 19:10 07/03/03, Alex Rousskov said: >On Fri, 7 Mar 2003, jfcm wrote: > > > However if the IDNA is accepted as an OPES service on the http and > > the smtp path, we may specify and see implemented callout protocol > > on the http/smtp output. Actually offering a hook for many other > > services hosted on the very machine of the user/provider. > >My understanding is that IDNAs make HTTP messages malformed. The IDNA has been designed so it does not do that. >It does not matter were you place IDNA converter as long as it is >outside of the application protocol path. For example, if your >application protocol is HTTP, you cannot use IDNAs in HTTP requests, >you must convert them before you get a valid HTTP request. Whether >that conversion is done by a "system plugin" or "application plugin" >is not important. IMO, you have two primary choices: > > - Perform IDNA conversions before you build messages > for old/existing application protocols. You can > invent a new protocol to do IDNA conversions. OPES will > not apply to the old application protocol, but may help > with the new/invented protocol (if any). We are in agreement (not on the technical understanding http/IDNA) > - Change old/existing application protocols and their > implementations so that messages containing IDNAs > become valid. OPES will apply then. However, if > all protocols and implementations are changed, > then the need for IDNA conversion disappears. The IDNA's purpose is not to change the protocols. That would be done in using UTF-8 all over the net. > > But the first question is: is the user control system as I define it > > an OPES dispatcher as it seems it may do a lot of things that OPES > > are not supposed to do: > > > > - change the URL (redirect) >possible (there is just no consensus whether OPES dispatcher or >callout server can do that) Yes. > > - be multilingual (IDNA++) >irrelevant to OPES; it is the application protocol that must be >multilingual, not OPES The point was that IDNA, as specified, is internationalizing. It does not provide all the Multilingualizing functions that the user expects (example: it does not support internationalized TLDs. Several propositions have been floated. They may use external files, data, web services, some we could qualify as OPES - but it is no worth discussing as them such since none has been worked out). > > - interact with the user >possible to the extent the application protocol supports user >interaction Remember it is local. The protocol here is the direct relation with the user. cf. bottom. > > - keep permanent user informations, etc. >possible if the application protocol allows it cf.above. > > But at the same time it may relate with services in using the > > callout protocol, interact with other dispatchers, etc. > >True. > > > >You have to drive this discussion though (e.g., by submitting > > >OPES-specific use cases or requirements). Are you saying that IDNA > > >conversion has some influence on OPES? If yes, what is that > > >influence? If no, why are we talking about IDNA (should we talk about > > >user control systems instead?)? > > > > You keep asking me to discuss cases. So I proposed a case. > >If your case is "IDNA conversions", I tried to evaluate it. If your >case is "user control systems", you have to tell us what OPES-related >requirements those systems have. cf. bottom. > > I think that its immediate interest could be to permit to define, > > implement and test the upper level of the callout protocol: I mean > > through local interactions withe services. > >Can you be more specific? Exactly what additional OPES >functionality/features (beyond modification of application messages >which is the current scope) do you want to support? Once we know your >requirements, we can all discuss corresponding changes to the >protocol. Well I cannot be too much specific for two reasons: - I really come to this because of IDNA support, trying to find proper solutions to the real user needs in that area. So I started with the demand for ML.ML (SLD and TLD multilingualized). - this is IP - at least for now. Mostly because we have not figured out they way we could best implement an open solution without hurting our own efforts. But I think we will do and I will then disclose. But I may also influence and impose our solution? I would prefer it stay open as much as possible ? But I can give some elements. - the management of a local Apache server - the management of the physical environment of the user - like rebooting for example. - the management of one's remote machine etc. where requests may be modified with informations corresponding to defaults, current situation, authorizations rights. A simple OPES service seems to be to aggregate simple cookie informations into user's requests. Another service (still in the IDNA line) is the translation of the messages sent, or of the presentation in an appropriate language of formatted messages (much like EDI). It is very convenient to imagine an EDIFACT translator as an OPES service, being sent EDI mails and presenting them in the language of each of the readers. (EDI makes commercial, customs, billing etc. document to result into codes and values, so a bill may be produced in German and read in Chinese). The filter (dispatcher) may be on my PC and the service may be remote. In that case: 1. as the PC owner I chose the service used (ONES) 2. as a mail reader I do not know/care that a service has been used (OPES). Is that OK with you for examples? Now, please remember the point is NOT to discuss this now. But to know first if these systems fall into OPES definition. To know if we must stop discussing them or not. Or if it may be of interest to consider them to more easily discuss and test the callout protocol. Thank you. jfc --=======68DC2F3F======= Content-Type: text/plain; charset=us-ascii; x-avg=cert; x-avg-checked=avg-ok-49F0375F Content-Disposition: inline --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.459 / Virus Database: 258 - Release Date: 25/02/03 --=======68DC2F3F=======-- From owner-ietf-openproxy@mail.imc.org Fri Mar 7 17:09: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 RAA08977 for ; Fri, 7 Mar 2003 17:09:43 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h27LlnL19923 for ietf-openproxy-bks; Fri, 7 Mar 2003 13:47:49 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h27Llm319918 for ; Fri, 7 Mar 2003 13:47:48 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h27Llonx095302 for ; Fri, 7 Mar 2003 14:47:50 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h27LloYI095301; Fri, 7 Mar 2003 14:47:50 -0700 (MST) (envelope-from rousskov) Date: Fri, 7 Mar 2003 14:47:50 -0700 (MST) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: is IDNA an OPES? 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: On Fri, 7 Mar 2003, jfcm wrote: > >My understanding is that IDNAs make HTTP messages malformed. > > The IDNA has been designed so it does not do that. Now I am confused: International domain names, as entered by users, would make HTTP messages malformed because HTTP addresses are ASCII-based, right? It is the proposed IDNA conversion that makes the addresses well-formed for old protocols. Since you asked whether OPES can be used to perform IDNA conversions, OPES would have to deal with raw IDNAs as input, right? Raw IDNAs make HTTP messages malformed. Malformed messages may not be able to reach OPES agents, even if those agents can handle them. Yet, you are saying that there is no problem. What am I missing? Alex. From owner-ietf-openproxy@mail.imc.org Fri Mar 7 17:40:58 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 RAA10929 for ; Fri, 7 Mar 2003 17:40:57 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h27MGMC20956 for ietf-openproxy-bks; Fri, 7 Mar 2003 14:16:22 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h27MGL320952 for ; Fri, 7 Mar 2003 14:16:21 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h27MGOnx096003 for ; Fri, 7 Mar 2003 15:16:24 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h27MGOTd096002; Fri, 7 Mar 2003 15:16:24 -0700 (MST) (envelope-from rousskov) Date: Fri, 7 Mar 2003 15:16:24 -0700 (MST) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: is IDNA an OPES? In-Reply-To: <5.2.0.9.0.20030307215011.0251d190@mail.utel.net> Message-ID: References: <5.2.0.9.0.20030307215011.0251d190@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, 7 Mar 2003, jfcm wrote: > 1. yes. A user control system can be an OPES dispatcher > even if it is located on the same machine as the user. > (for more discussion on the ucs cf. bottom) A user control system can be an OPES dispatcher if and only if that user control system is a part of some proxy for application-level protocols. I am not sure your user control system is a part of a proxy. OPES is about adaptation of application messages being proxied. > 2. yes. The IDNA may be considered as an OPES service, > IF it is provided to several applications trough the > dispatcher. The number of applications is irrelevant to OPES. Yes, OPES has to include a directly addressable processor, with a dispatcher. > 3. yes. The callout protocol may be used in that case. The callout protocol cannot leave outside of OPES. Or, more precisely, usage of the callout protocol outside of OPES is outside of this WG scope. If your user control system is a proxy, then we can talk how OPES and callout protocol apply. > 4. no. the IDNA as such is NOT an OPES when it is > only a part of an application > > 5. What should be investigated is the "user control system". > cf. bottom. OK. Let's forget about IDNA then and talk about "user control system". > - this is IP - at least for now. That's fine as long as you understand that we cannot productively discuss something we do not know about. > But I can give some elements. > - the management of a local Apache server > - the management of the physical environment of the user - like > rebooting for example. > - the management of one's remote machine etc. > where requests may be modified with informations corresponding to > defaults, current situation, authorizations rights. You need to mention application protocols. Recall that OPES is about modifying application messages. The above three "elements" do not imply any specific protocols or proxies so it is not clear why do you need OPES: - what is user/client that generates messages? - what is the destination of those messages? - are those messages proxied? where is the proxy? - what protocols are used for those messages? > A simple OPES service seems to be to aggregate simple cookie > informations into user's requests. If modifications and aggregation are happening on some proxy, then OPES is in scope and may help. > Another service (still in the IDNA line) is the translation of the > messages sent, or of the presentation in an appropriate language of > formatted messages (much like EDI). It is very convenient to imagine > an EDIFACT translator as an OPES service, being sent EDI mails and > presenting them in the language of each of the readers. (EDI makes > commercial, customs, billing etc. document to result into codes and > values, so a bill may be produced in German and read in Chinese). > The filter (dispatcher) may be on my PC and the service may be > remote. In-flow translation is within OPES scope, of course. > In that case: > 1. as the PC owner I chose the service used (ONES) > 2. as a mail reader I do not know/care that a service has > been used (OPES). I do not understand this distinction (why cannot one chose OPES proxy but can chose ONES?), but that is probably not important for now. > Is that OK with you for examples? Yes, except that I do not see a relation to the user control system. Should we ignore the UCS discussion from now on? > Now, please remember the point is NOT to discuss this now. But to > know first if these systems fall into OPES definition. If by "these systems" you mean "addition of cookie-like information by a proxy" and "translation by a proxy", then yes, those systems may be in OPES scope. If by "these systems" you mean something else, then I do not know what you mean. Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Fri Mar 7 17:47: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 RAA11220 for ; Fri, 7 Mar 2003 17:47:44 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h27MRAV21241 for ietf-openproxy-bks; Fri, 7 Mar 2003 14:27:10 -0800 (PST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h27MR9321237 for ; Fri, 7 Mar 2003 14:27:09 -0800 (PST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h27MREa12460 for ; Fri, 7 Mar 2003 16:27:14 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 7 Mar 2003 16:27:10 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 7 Mar 2003 14:26:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: is IDNA an OPES? Date: Fri, 7 Mar 2003 17:26:42 -0500 Message-ID: Thread-Topic: is IDNA an OPES? Thread-Index: AcLk9cBQj3nKoj/uSGic8gnCFS0jRwAAUHOg From: To: X-OriginalArrivalTime: 07 Mar 2003 22:26:42.0972 (UTC) FILETIME=[A1580DC0:01C2E4F8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h27MR9321238 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Alex, I was a little behind in reading the various threads in this group! I wanted to clarify some terminology with you. When you referred to OPES agents, you meant any OPES device, OPES processors or callout server, right? I agree with you that raw IDNA ML messages cannot be conveyed to even the OPES processor (or, the callout processor too) from the content producer, using HTTP! I too am curious as to how jfc says that OPES can be used for IDNA conversion if it has to deal with this problem! -Srini >-----Original Message----- >From: ext Alex Rousskov [mailto:rousskov@measurement-factory.com] >Sent: Friday, March 07, 2003 4:48 PM >To: ietf-openproxy@imc.org >Subject: Re: is IDNA an OPES? > > > >On Fri, 7 Mar 2003, jfcm wrote: > >> >My understanding is that IDNAs make HTTP messages malformed. >> >> The IDNA has been designed so it does not do that. > >Now I am confused: International domain names, as entered by users, >would make HTTP messages malformed because HTTP addresses are >ASCII-based, right? It is the proposed IDNA conversion that makes the >addresses well-formed for old protocols. Since you asked whether OPES >can be used to perform IDNA conversions, OPES would have to deal with >raw IDNAs as input, right? Raw IDNAs make HTTP messages malformed. >Malformed messages may not be able to reach OPES agents, even if those >agents can handle them. Yet, you are saying that there is no problem. > >What am I missing? > >Alex. > From owner-ietf-openproxy@mail.imc.org Fri Mar 7 21:32: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 VAA06250 for ; Fri, 7 Mar 2003 21:32:36 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2826QI29172 for ietf-openproxy-bks; Fri, 7 Mar 2003 18:06:26 -0800 (PST) Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2826O329168 for ; Fri, 7 Mar 2003 18:06:24 -0800 (PST) Received: from f05v-16-175.d1.club-internet.fr ([212.194.195.175] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 18rTjF-0004MO-00 for ietf-openproxy@imc.org; Fri, 07 Mar 2003 18:06:25 -0800 Message-Id: <5.2.0.9.0.20030308010012.0296f270@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sat, 08 Mar 2003 01:40:35 +0100 To: From: jfcm Subject: RE: is IDNA an OPES? In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-32F11D47; boundary="=======24EB52F=======" 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: --=======24EB52F======= Content-Type: text/plain; x-avg-checked=avg-ok-32F11D47; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8bit At 23:26 07/03/03, bindignavile.srinivas@nokia.com wrote: >Alex, >I was a little behind in reading the various threads in this group! I >wanted to clarify some terminology with you. When you referred to OPES >agents, you meant any OPES device, OPES processors or callout server, >right? I agree with you that raw IDNA ML messages cannot be conveyed to >even the OPES processor (or, the callout processor too) from the content >producer, using HTTP! I asked a question because I have very hard time understanding what is an OPES according to the IAB and this group's definitions I found sometimes contradicting. Just want a clear list. To try to have the debate to help, I picked another case where I have very hard time to understand what it is and where it fits which is IDNA. (I feel the standard does not match all the user needs, and because testings are under way). And I asked if IDNA was OPES to try to better understand from the responses. Responses have helped a lot to see that the situation is more confuse on both aspects. Let drop IDNA. Initially I understood the OPES was an HTTP oriented filter sitting on one side proxy and possibly calling on servers through a callout protocol to modify the transiting data. - I gave an example talking of SMTP. Some objected it iwas not HTT¨P, but most accepted SMTP. - there was then a debate over redirection: can an OPES redirect or not. Seems controverted too. - there was a debate on one way or two way? Two ways seems accepted? - there was a debate on the fact that an OPES server may not call the user for a direct confirmation: the response seems odd to me (through the application - I am not sure about hwt it means) - I generalized the concepts as ONES and tried to see the boarder between ONES and OPES, with some difficulty to understand where OPES end. A difference seem that the OPES is not chosen or even ignored by the user, while the ONES are organized/selected in cooperation by the user/producer. This generalized architecture of mine made me to analyze that the semantic could be clarified. That we had a more balanced end to end vision (and wording) of the system. Also that the protocol was an inter-dispatcher protocol with a possible command channel 0, triggering server applications. The discussion went on the need or not to swallow the data/processes related to a channel (a set of channels - from dispatcher to dispatcher being allocated to a transaction). Then the callout protocol was discussed and it style. Soap or not, inter-active on blunt stop, bandwidth consuming, etc. I tried to see where we could have good specifications and examples of that protocol; in total or in part. The IDNA discussion has identified that the browser could use it to interact with an IDNA server. Other examples (EDI, translations, airlines, visa etc) were investigated/alluded to. This means (to me) that we have a network of dispatchers with the following functions 1. entry in the dispatcher in http, smtp. 2. filtering a according rules 3. filtered objects are sent to the server 4. the objects come back from the server 5. they are sent in http or smtp or.... Your position says (1) does not use http or smtp or another IETF protocol, so the concerned system is not an OPES, so the (3)/(4) protocol is not a callout protocol. I question that and I say that what qualified the OPES is that the (2) filter may apply and that (5) is in an appropriate http/smtp format. jfc --=======24EB52F======= Content-Type: text/plain; charset=us-ascii; x-avg=cert; x-avg-checked=avg-ok-32F11D47 Content-Disposition: inline --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.459 / Virus Database: 258 - Release Date: 25/02/03 --=======24EB52F=======-- From owner-ietf-openproxy@mail.imc.org Sat Mar 8 00:50:42 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 AAA08445 for ; Sat, 8 Mar 2003 00:50:40 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2853nF03860 for ietf-openproxy-bks; Fri, 7 Mar 2003 21:03:49 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2853l303856 for ; Fri, 7 Mar 2003 21:03:47 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h2853pnx005511 for ; Fri, 7 Mar 2003 22:03:51 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h2853pAq005510; Fri, 7 Mar 2003 22:03:51 -0700 (MST) (envelope-from rousskov) Date: Fri, 7 Mar 2003 22:03:51 -0700 (MST) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: RE: is IDNA an OPES? 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 Fri, 7 Mar 2003 bindignavile.srinivas@nokia.com wrote: > I was a little behind in reading the various threads in this group! > I wanted to clarify some terminology with you. When you referred to > OPES agents, you meant any OPES device, OPES processors or callout > server, right? Yes. "Device" just sounds too hardware-oriented to me. > I agree with you that raw IDNA ML messages cannot be conveyed to > even the OPES processor (or, the callout processor too) from the > content producer, using HTTP! I too am curious as to how jfc says > that OPES can be used for IDNA conversion if it has to deal with > this problem! In an off-list message jfc clarified that IDNA conversion on the system in question happens before the application (e.g., HTTP) message is formed. To me, that means that there is another (new) application protocol that is being used for IDNA conversions and that may be subject to OPES transformations. I think jfc tried to clarify the rest on the mailing list. Alex. > >-----Original Message----- > >From: ext Alex Rousskov [mailto:rousskov@measurement-factory.com] > >Sent: Friday, March 07, 2003 4:48 PM > >To: ietf-openproxy@imc.org > >Subject: Re: is IDNA an OPES? > > > > > > > >On Fri, 7 Mar 2003, jfcm wrote: > > > >> >My understanding is that IDNAs make HTTP messages malformed. > >> > >> The IDNA has been designed so it does not do that. > > > >Now I am confused: International domain names, as entered by users, > >would make HTTP messages malformed because HTTP addresses are > >ASCII-based, right? It is the proposed IDNA conversion that makes the > >addresses well-formed for old protocols. Since you asked whether OPES > >can be used to perform IDNA conversions, OPES would have to deal with > >raw IDNAs as input, right? Raw IDNAs make HTTP messages malformed. > >Malformed messages may not be able to reach OPES agents, even if those > >agents can handle them. Yet, you are saying that there is no problem. > > > >What am I missing? > > > >Alex. > > > From owner-ietf-openproxy@mail.imc.org Sat Mar 8 01:18:07 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 BAA13470 for ; Sat, 8 Mar 2003 01:18:06 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h285b9v04428 for ietf-openproxy-bks; Fri, 7 Mar 2003 21:37:09 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h285b8304424 for ; Fri, 7 Mar 2003 21:37:08 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h285bCnx006315 for ; Fri, 7 Mar 2003 22:37:12 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h285bCEB006314; Fri, 7 Mar 2003 22:37:12 -0700 (MST) (envelope-from rousskov) Date: Fri, 7 Mar 2003 22:37:12 -0700 (MST) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: RE: is IDNA an OPES? In-Reply-To: <5.2.0.9.0.20030308010012.0296f270@mail.utel.net> Message-ID: References: <5.2.0.9.0.20030308010012.0296f270@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, 8 Mar 2003, jfcm wrote: > Initially I understood the OPES was an HTTP oriented filter sitting > on one side proxy and possibly calling on servers through a callout > protocol to modify the transiting data. Sounds accurate enough for a brief summary, except OPES is not HTTP-oriented or HTTP-specific. HTTP is just one of the protocols that OPES must support. OPES is application protocol agnostic. Does any of the drafts/RFCs say that OPES is HTTP-oriented? > - I gave an example talking of SMTP. Some objected it iwas not HTTP, but > most accepted SMTP. I may have missed that discussion, but I do not recall any recent objections to SMTP. Why object to one of the most popular applications on the Internet that can definitely benefit from OPES? > - there was then a debate over redirection: can an OPES redirect or > not. Seems controverted too. There was a discussion what OPES agents can redirect. I do not recall any opinions that OPES (as a whole) cannot redirect. In fact, since OPES can both generate application responses and use external services, it is clear that it can redirect (by superposition)! > - there was a debate on one way or two way? Two ways seems accepted? I do not think there was any real debate, just some wording confusion/improvements. OPES can support both uni- and bidirectional (and many-directional) application protocols. > - there was a debate on the fact that an OPES server may not call > the user for a direct confirmation: the response seems odd to me > (through the application - I am not sure about hwt it means) It simply means that the user cannot communicate with OPES agents using OPES protocols. If OPES agents can get confirmation using application protocols, then direct confirmation is possible (for those application protocols). This rule preserves OPES scope as an application proxy service. What is odd about it? > - I generalized the concepts as ONES and tried to see the boarder > between ONES and OPES, with some difficulty to understand where OPES > end. A difference seem that the OPES is not chosen or even ignored > by the user, while the ONES are organized/selected in cooperation by > the user/producer. OPES most certainly can be selected by the user (by selecting an appropriate protocol proxy). Moreover, OPES services may be affected by user preferences that are, for example, communicated over application protocols and/or stored at the proxy. > This generalized architecture of mine made me to analyze that the > semantic could be clarified. That we had a more balanced end to end > vision (and wording) of the system. Also that the protocol was an > inter-dispatcher protocol with a possible command channel 0, > triggering server applications. I assume the above paragraph is not about OPES, but ONES or something else, right? Not sure what it is, so I cannot say whether it is indeed "more balanced" (than OPES?). > The discussion went on the need or not to swallow the data/processes > related to a channel (a set of channels - from dispatcher to > dispatcher being allocated to a transaction). > Then the callout protocol was discussed and it style. Soap or not, > inter-active on blunt stop, bandwidth consuming, etc. I tried to see > where we could have good specifications and examples of that > protocol; in total or in part. OPES WG drafts contain architecture and protocol requirements. If you need an example of an OPES-like protocol, ICAP is a good candidate. There is even an ID that compares OPES and ICAP. The OPES predraft defines some parts of the OPES protocol. > The IDNA discussion has identified that the browser could use it to > interact with an IDNA server. Other examples (EDI, translations, > airlines, visa etc) were investigated/alluded to. > This means (to me) that we have a network of dispatchers with the > following functions > > 1. entry in the dispatcher in http, smtp. or other application protocols > 2. filtering a according rules > 3. filtered objects are sent to the server > 4. the objects come back from the server > 5. they are sent in http or smtp or.... Sounds about right for a brief summary. Note that the above 5 items do not include anything related to the "network of dispatchers" you mentioned above. All these items describe one OPES processor. There can be many OPES processors, and some might cooperate, but such cooperation is not covered by the above items. I am not sure whether it would in OPES scope beyond things like enforcing user preferences and tracing when several OPES processors modify a message. Also, IMO, the above items can be derived directly from the published OPES architecture. I am not sure how this long email thread is related to them. > Your position says (1) does not use http or smtp or another IETF > protocol, so the concerned system is not an OPES, so the (3)/(4) > protocol is not a callout protocol. What position are you talking about? OPES is application agnostic and, hence, is not limited to IETF protocols. HTTP and SMTP are just well-known examples. Alex. From owner-ietf-openproxy@mail.imc.org Mon Mar 10 07:25: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 HAA03800 for ; Mon, 10 Mar 2003 07:25:57 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2AC27h27479 for ietf-openproxy-bks; Mon, 10 Mar 2003 04:02:07 -0800 (PST) Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2AC25327470 for ; Mon, 10 Mar 2003 04:02:06 -0800 (PST) Received: from mhof.com ([135.104.20.73]) by mtaout02.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPA id <0HBJ00HBV83CZD@mtaout02.icomcast.net> for ietf-openproxy@imc.org; Mon, 10 Mar 2003 07:02:01 -0500 (EST) Date: Mon, 10 Mar 2003 07:02:00 -0500 From: Markus Hofmann Subject: Draft Agenda for IETF 56 To: OPES Group Message-id: <3E6C7EB8.3060609@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.3b) Gecko/20030210 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Hi, we want to continue the lively discussion on the mailing list at the IETF 56 meeting in San Francisco next week. We intend to spend a few minutes provding a quick update on the status of our five submitted WG documents, and then go immediatelly over to the OPES prototol work. Focus will be on resolving the higher-level issues, starting with a discussion of major decision points for protocol design and of the "protocol pre-draft" throughts. We will cover further topics under "general discussion". If you've topics to be dicussed under "general discussion" and would be interested to present in San Francisco, please send Marshall and myself a note ASAP. Thanks, Markus ----------------------------------------------------- Open Pluggable Edge Services WG (opes) ====================================== Monday, March 17, 1530-1730 CHAIR(S): Marshall Rose Markus Hofmann TECHNICAL ADVISOR(S): Allison Mankin Hilarie Orman AGENDA: - Introduction, minutes taker, blue sheets - Agenda bashing - Status of WG documents draft-ietf-opes-architecture-04 draft-ietf-opes-protocol-reqs-03 draft-ietf-opes-scenarios-01 draft-ietf-opes-authorization-02 draft-ietf-opes-threats-02 - Start on OPES protocol work - Introduction - Major decision points for protocol design - OPES protocol pre-draft thoughts - General discussion From owner-ietf-openproxy@mail.imc.org Mon Mar 10 12:47: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 MAA05345 for ; Mon, 10 Mar 2003 12:47:36 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2AHFj417528 for ietf-openproxy-bks; Mon, 10 Mar 2003 09:15:45 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2AHFi317521 for ; Mon, 10 Mar 2003 09:15:44 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h2AHFknx090935; Mon, 10 Mar 2003 10:15:46 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h2AHFk7N090934; Mon, 10 Mar 2003 10:15:46 -0700 (MST) (envelope-from rousskov) Date: Mon, 10 Mar 2003 10:15:45 -0700 (MST) From: Alex Rousskov To: OPES Group Subject: Re: Draft Agenda for IETF 56 In-Reply-To: <3E6C7EB8.3060609@mhof.com> Message-ID: References: <3E6C7EB8.3060609@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, 10 Mar 2003, Markus Hofmann wrote: > - Introduction, minutes taker, blue sheets > - Agenda bashing > - Status of WG documents > draft-ietf-opes-architecture-04 > draft-ietf-opes-protocol-reqs-03 > draft-ietf-opes-scenarios-01 > draft-ietf-opes-authorization-02 > draft-ietf-opes-threats-02 - OPES scope clarifications > - Start on OPES protocol work > - Introduction > - Major decision points for protocol design > - OPES protocol pre-draft thoughts > - General discussion I would like to propose to add another agenda item, "OPES scope clarifications", as shown above. We have good architecture and requirements drafts, but they appear to leave some scope questions unanswered (or there may be no consensus how to interpret the drafts). These questions seem to be one "level" higher than callout protocol work because they affect more than the callout protocol. Specifically, I would like to discuss the following, under the new agenda item: 1) Can OPES redirect application messages? That is, can OPES change the final destination of an application message? If yes, ~ What OPES agents can do that (dispatcher and/or callout server)? ~ What techniques are allowed (e.g., rewriting application message headers, responding with a "redirect" response if supported by the application protocol)? And if no, ~ Can generating a response without forwarding the request be considered a form of redirection? Is that kind of transaction termination allowed for application error messages only? What is an error? 2) Can OPES fan out messages (a single application message is forwarded as multiple messages)? Can OPES aggregate messages (multiple application messages are forwarded as a single application message)? 3) Can OPES provide protocol translation service? That is, can OPES switch flow from one application protocol to another (e.g., HTTP transaction with FTP URL to an FTP transaction)? 4) Can OPES agents communicate with providers and consumers using application protocols? For example, can an OPES-aware proxy do this: ~ suspend an HTTP request (do not forward it) ~ "respond" with a OPES-generated HTML page containing a
, asking for user password/preferences ~ receive the result of form submission ~ forward the original HTTP request, possibly adjusted based on user answers in the form ~ forward the response back to the client The above is a relatively common behavior supported by existing HTTP intermediaries (especially popular at ISPs). It opens the door for many "enhanced" services. Should OPES support this? Question 1-3 attempt to clarify scope of OPES services; what can be modified by OPES: just message content and affected headers; content, headers, and transport-level connections (destination/source); number of messages; protocol itself? The answer to question 4 will draw the line between OPES agents and providers/consumers: what kinds of communication are allowed? Are these real issues worth discussing? Or do they already have precise answers in WG drafts? Do they fit into existing agenda items? Any changes to the above list? Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Mon Mar 10 14:01: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 OAA08376 for ; Mon, 10 Mar 2003 14:01:41 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2AIVS820335 for ietf-openproxy-bks; Mon, 10 Mar 2003 10:31:28 -0800 (PST) Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2AIVR320331 for ; Mon, 10 Mar 2003 10:31:27 -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 h2AIVGC27494; Mon, 10 Mar 2003 13:31:16 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Mar 2003 13:31:16 -0500 Message-ID: <87609AFB433BD5118D5E0002A52CD754051A20B7@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Alex Rousskov , OPES Group Subject: RE: Draft Agenda for IETF 56 Date: Mon, 10 Mar 2003 13:31:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E733.3B46B274" 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_01C2E733.3B46B274 Content-Type: text/plain Alex, I do second your proposal. Abbie > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Monday, March 10, 2003 12:16 PM > To: OPES Group > Subject: Re: Draft Agenda for IETF 56 > > > > On Mon, 10 Mar 2003, Markus Hofmann wrote: > > > - Introduction, minutes taker, blue sheets > > - Agenda bashing > > - Status of WG documents > > draft-ietf-opes-architecture-04 > > draft-ietf-opes-protocol-reqs-03 > > draft-ietf-opes-scenarios-01 > > draft-ietf-opes-authorization-02 > > draft-ietf-opes-threats-02 > > - OPES scope clarifications > > > - Start on OPES protocol work > > - Introduction > > - Major decision points for protocol design > > - OPES protocol pre-draft thoughts > > - General discussion > > I would like to propose to add another agenda item, "OPES > scope clarifications", as shown above. We have good > architecture and requirements drafts, but they appear to > leave some scope questions unanswered (or there may be no > consensus how to interpret the drafts). These questions seem > to be one "level" higher than callout protocol work because > they affect more than the callout protocol. > > Specifically, I would like to discuss the following, under > the new agenda item: > > 1) Can OPES redirect application messages? That is, > can OPES change the final destination of an application > message? If yes, > ~ What OPES agents can do that (dispatcher and/or > callout server)? > ~ What techniques are allowed (e.g., rewriting > application message headers, responding with > a "redirect" response if supported by the > application protocol)? > > And if no, > ~ Can generating a response without forwarding > the request be considered a form of redirection? > Is that kind of transaction termination allowed > for application error messages only? What is an > error? > > 2) Can OPES fan out messages (a single application > message is forwarded as multiple messages)? Can OPES > aggregate messages (multiple application messages are > forwarded as a single application message)? > > 3) Can OPES provide protocol translation service? That is, > can OPES switch flow from one application protocol to > another (e.g., HTTP transaction with FTP URL to an FTP > transaction)? > > 4) Can OPES agents communicate with providers and consumers > using application protocols? For example, can an OPES-aware > proxy do this: > ~ suspend an HTTP request (do not forward it) > ~ "respond" with a OPES-generated HTML page > containing a , asking for user > password/preferences > ~ receive the result of form submission > ~ forward the original HTTP request, > possibly adjusted based on user answers in > the form > ~ forward the response back to the client > > The above is a relatively common behavior supported by > existing HTTP intermediaries (especially popular at > ISPs). It opens the door for many "enhanced" services. > Should OPES support this? > > > Question 1-3 attempt to clarify scope of OPES services; what > can be modified by OPES: just message content and affected > headers; content, headers, and transport-level connections > (destination/source); number of messages; protocol itself? > The answer to question 4 will draw the line between OPES > agents and providers/consumers: what kinds of communication > are allowed? > > > Are these real issues worth discussing? Or do they already > have precise answers in WG drafts? Do they fit into existing > agenda items? Any changes to the above list? > > Thank you, > > Alex. > > > ------_=_NextPart_001_01C2E733.3B46B274 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Draft Agenda for IETF 56

Alex,

I do second your proposal.


Abbie


> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Monday, March 10, 2003 12:16 PM
> To: OPES Group
> Subject: Re: Draft Agenda for IETF 56
>
>
>
> On Mon, 10 Mar 2003, Markus Hofmann = wrote:
>
> >     - Introduction, = minutes taker, blue sheets
> >     - Agenda = bashing
> >     - Status of WG = documents
> = >         = draft-ietf-opes-architecture-04
> = >         = draft-ietf-opes-protocol-reqs-03
> = >         = draft-ietf-opes-scenarios-01
> = >         = draft-ietf-opes-authorization-02
> = >         = draft-ietf-opes-threats-02
>
>       - OPES = scope clarifications
>
> >     - Start on OPES = protocol work
> >       - = Introduction
> >       - = Major decision points for protocol design
> >       - OPES = protocol pre-draft thoughts
> >       - = General discussion
>
> I would like to propose to add another agenda = item, "OPES
> scope clarifications", as shown = above.  We have good
> architecture and requirements drafts, but they = appear to
> leave some scope questions unanswered (or there = may be no
> consensus how to interpret the drafts). These = questions seem
> to be one "level" higher than callout = protocol work because
> they affect more than the callout = protocol.
>
> Specifically, I would like to discuss the = following, under
> the new agenda item:
>
>       1) Can OPES = redirect application messages? That is,
>         can OPES = change the final destination of an application
>         message? = If yes,
>       =         ~ What OPES agents can do = that (dispatcher and/or
>       =           callout = server)?
>       =         ~ What techniques are = allowed (e.g., rewriting
>       =           application message = headers, responding with
>       =           a = "redirect" response if supported by the
>       =           application = protocol)?
>
>         And if = no,
>       =         ~ Can generating a response = without forwarding
>       =           the request be = considered a form of redirection?
>       =           Is that kind of = transaction termination allowed
>       =           for application error = messages only? What is an
>       =           error?
>
>       2) Can OPES fan = out messages (a single application
>          = message is forwarded as multiple messages)? Can OPES
>          = aggregate messages (multiple application messages are
>          = forwarded as a single application message)?
>
>       3) Can OPES = provide protocol translation service? That is,
>         can OPES = switch flow from one application protocol to
>         another = (e.g., HTTP transaction with FTP URL to an FTP
>         = transaction)?
>
>       4) Can OPES = agents communicate with providers and consumers
>         using = application protocols? For example, can an OPES-aware
>         proxy do = this:
>       =         ~ suspend an HTTP request = (do not forward it)
>       =         ~ "respond" with a = OPES-generated HTML page
>       =           containing a = <form>, asking for user
>       =           = password/preferences
>       =         ~ receive the result of form = submission
>       =         ~ forward the original HTTP = request,
>       =           possibly adjusted = based on user answers in
>       =           the form
>       =         ~ forward the response back = to the client
>
>         The above = is a relatively common behavior supported by
>         existing = HTTP intermediaries (especially popular at
>         ISPs). It = opens the door for many "enhanced" services.
>         Should = OPES support this?
>
>
> Question 1-3 attempt to clarify scope of OPES = services; what
> can be modified by OPES: just message content = and affected
> headers; content, headers, and transport-level = connections
> (destination/source); number of messages; = protocol itself?
> The answer to question 4 will draw the line = between OPES
> agents and providers/consumers: what kinds of = communication
> are allowed?
>
>
> Are these real issues worth discussing? Or do = they already
> have precise answers in WG drafts? Do they fit = into existing
> agenda items? Any changes to the above = list?
>
> Thank you,
>
> Alex.
>
>
>

------_=_NextPart_001_01C2E733.3B46B274-- From owner-ietf-openproxy@mail.imc.org Tue Mar 11 00:27:50 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 AAA27902 for ; Tue, 11 Mar 2003 00:27:49 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2B50RG17542 for ietf-openproxy-bks; Mon, 10 Mar 2003 21:00:27 -0800 (PST) Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2B50L317538 for ; Mon, 10 Mar 2003 21:00:21 -0800 (PST) Received: from mhof.com ([135.104.20.81]) by mtaout07.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPA id <0HBK0055JJ8J6N@mtaout07.icomcast.net> for ietf-openproxy@imc.org; Tue, 11 Mar 2003 00:00:20 -0500 (EST) Date: Tue, 11 Mar 2003 00:00:19 -0500 From: Markus Hofmann Subject: Re: Draft Agenda for IETF 56 In-reply-to: <87609AFB433BD5118D5E0002A52CD754051A20B7@zcard0k6.ca.nortel.com> To: Abbie Barbir Cc: Alex Rousskov , OPES Group Message-id: <3E6D6D63.1010503@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.3b) Gecko/20030210 References: <87609AFB433BD5118D5E0002A52CD754051A20B7@zcard0k6.ca.nortel.com> Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Alex, agreed, good suggestion. Thought of covering that under the "Introduction to protocol work", but maybe a separate agenda item might be more appropriate. Abbie, could you cover that topic and lead the discussion on that one, since Alex will already present on other topics? Thanks, Markus Abbie Barbir wrote: > Alex, > > I do second your proposal. > > > Abbie > > > >>-----Original Message----- >>From: Alex Rousskov [mailto:rousskov@measurement-factory.com] >>Sent: Monday, March 10, 2003 12:16 PM >>To: OPES Group >>Subject: Re: Draft Agenda for IETF 56 >> >> >> >>On Mon, 10 Mar 2003, Markus Hofmann wrote: >> >> >>> - Introduction, minutes taker, blue sheets >>> - Agenda bashing >>> - Status of WG documents >>> draft-ietf-opes-architecture-04 >>> draft-ietf-opes-protocol-reqs-03 >>> draft-ietf-opes-scenarios-01 >>> draft-ietf-opes-authorization-02 >>> draft-ietf-opes-threats-02 >> >> - OPES scope clarifications >> >> >>> - Start on OPES protocol work >>> - Introduction >>> - Major decision points for protocol design >>> - OPES protocol pre-draft thoughts >>> - General discussion >> >>I would like to propose to add another agenda item, "OPES >>scope clarifications", as shown above. We have good >>architecture and requirements drafts, but they appear to >>leave some scope questions unanswered (or there may be no >>consensus how to interpret the drafts). These questions seem >>to be one "level" higher than callout protocol work because >>they affect more than the callout protocol. >> >>Specifically, I would like to discuss the following, under >>the new agenda item: >> >> 1) Can OPES redirect application messages? That is, >> can OPES change the final destination of an application >> message? If yes, >> ~ What OPES agents can do that (dispatcher and/or >> callout server)? >> ~ What techniques are allowed (e.g., rewriting >> application message headers, responding with >> a "redirect" response if supported by the >> application protocol)? >> >> And if no, >> ~ Can generating a response without forwarding >> the request be considered a form of redirection? >> Is that kind of transaction termination allowed >> for application error messages only? What is an >> error? >> >> 2) Can OPES fan out messages (a single application >> message is forwarded as multiple messages)? Can OPES >> aggregate messages (multiple application messages are >> forwarded as a single application message)? >> >> 3) Can OPES provide protocol translation service? That is, >> can OPES switch flow from one application protocol to >> another (e.g., HTTP transaction with FTP URL to an FTP >> transaction)? >> >> 4) Can OPES agents communicate with providers and consumers >> using application protocols? For example, can an OPES-aware >> proxy do this: >> ~ suspend an HTTP request (do not forward it) >> ~ "respond" with a OPES-generated HTML page >> containing a , asking for user >> password/preferences >> ~ receive the result of form submission >> ~ forward the original HTTP request, >> possibly adjusted based on user answers in >> the form >> ~ forward the response back to the client >> >> The above is a relatively common behavior supported by >> existing HTTP intermediaries (especially popular at >> ISPs). It opens the door for many "enhanced" services. >> Should OPES support this? >> >> >>Question 1-3 attempt to clarify scope of OPES services; what >>can be modified by OPES: just message content and affected >>headers; content, headers, and transport-level connections >>(destination/source); number of messages; protocol itself? >>The answer to question 4 will draw the line between OPES >>agents and providers/consumers: what kinds of communication >>are allowed? >> >> >>Are these real issues worth discussing? Or do they already >>have precise answers in WG drafts? Do they fit into existing >>agenda items? Any changes to the above list? >> >>Thank you, >> >>Alex. >> >> >> > > From owner-ietf-openproxy@mail.imc.org Tue Mar 11 00:39: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 AAA28117 for ; Tue, 11 Mar 2003 00:39:33 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2B5Blc17881 for ietf-openproxy-bks; Mon, 10 Mar 2003 21:11:47 -0800 (PST) Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2B5Bj317877 for ; Mon, 10 Mar 2003 21:11:45 -0800 (PST) Received: from mhof.com ([135.104.20.81]) by mtaout04.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPA id <0HBK0087FJRK1A@mtaout04.icomcast.net> for ietf-openproxy@imc.org; Tue, 11 Mar 2003 00:11:45 -0500 (EST) Date: Tue, 11 Mar 2003 00:11:44 -0500 From: Markus Hofmann Subject: Re: Draft Agenda for IETF 56 In-reply-to: <3E6C7EB8.3060609@mhof.com> To: Markus Hofmann Cc: OPES Group Message-id: <3E6D7010.2040003@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.3b) Gecko/20030210 References: <3E6C7EB8.3060609@mhof.com> Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Folks, based on various feedback, attached an updated draft agenda for our OPES meeting in San Franciso. Thanks, Markus ----------------------------------------------------- Open Pluggable Edge Services WG (opes) ====================================== Monday, March 17, 1530-1730 CHAIR(S): Marshall Rose Markus Hofmann TECHNICAL ADVISOR(S): Allison Mankin Hilarie Orman AGENDA: - Introduction, minutes taker, blue sheets [2 min] - Agenda bashing [3 min] - Status of WG documents [M. Hofmann, 10 min] draft-ietf-opes-architecture-04 draft-ietf-opes-protocol-reqs-03 draft-ietf-opes-scenarios-01 draft-ietf-opes-authorization-02 draft-ietf-opes-threats-02 - Start on OPES protocol work - Introduction to protocol work [M. Hofmann, 10 min] - Protocol layering and the OPES callout protocol [H. Orman, 15 min] - OPES scope clarifications [A. Barbier, ? min] - Major decision points for protocol design [A. Rousskov, ? min] - OPES protocol pre-draft thoughts [A. Rousskov, ? min] - General discussion [? min] From owner-ietf-openproxy@mail.imc.org Tue Mar 11 03:09:07 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 DAA12564 for ; Tue, 11 Mar 2003 03:09:06 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2B7gxm29090 for ietf-openproxy-bks; Mon, 10 Mar 2003 23:42:59 -0800 (PST) Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2B7gw329084 for ; Mon, 10 Mar 2003 23:42:58 -0800 (PST) Received: from f06a-12-117.d1.club-internet.fr ([212.194.131.117] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 18sePU-0004UD-00; Mon, 10 Mar 2003 23:42:53 -0800 Message-Id: <5.2.0.9.0.20030310155334.03484ec0@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 10 Mar 2003 16:14:22 +0100 To: Markus Hofmann , OPES Group From: jfcm Subject: Re: Draft Agenda for IETF 56 In-Reply-To: <3E6C7EB8.3060609@mhof.com> Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-6F0E1EF9; boundary="=======7DF765A=======" 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: --=======7DF765A======= Content-Type: text/plain; x-avg-checked=avg-ok-6F0E1EF9; charset=us-ascii; format=flowed Content-Transfer-Encoding: 8bit My main question is about the entry and the ending points of the OPES concept. If it is accepted that not only HTTP but any protocol is OK, and that alternatively both end points can be user/producer or that we may have a peer to peer support, it will mean that any entry/output protocol is OK, including a keyboard/user file/application etc, towards a screen, a file, etc. This means there is no pseudo-synchoronous (like in hhtp) obligation (or as options). This means that we have a general purpose concept of a filter/transformer system on a flow. Which will standardize everywhere. This means that, the filter/transformer relation (callout protocol) can be anything from realtime to soap. Am I correct? Because this means that we will have a good general framework for a protected/acked balanced protocol able to support one to many or even many to many relations. Then the next question will be: will it always be under TCP? jfc At 13:02 10/03/03, Markus Hofmann wrote: >we want to continue the lively discussion on the mailing list at the IETF >56 meeting in San Francisco next week. > >We intend to spend a few minutes provding a quick update on the status of >our five submitted WG documents, and then go immediatelly over to the OPES >prototol work. Focus will be on resolving the higher-level issues, >starting with a discussion of major decision points for protocol design >and of the "protocol pre-draft" throughts. We will cover further topics >under "general discussion". > >If you've topics to be dicussed under "general discussion" and would be >interested to present in San Francisco, please send Marshall and myself a >note ASAP. > >Thanks, > Markus > >----------------------------------------------------- > >Open Pluggable Edge Services WG (opes) >====================================== >Monday, March 17, 1530-1730 > >CHAIR(S): > Marshall Rose > Markus Hofmann > >TECHNICAL ADVISOR(S): > Allison Mankin > Hilarie Orman > >AGENDA: > - Introduction, minutes taker, blue sheets > - Agenda bashing > - Status of WG documents > draft-ietf-opes-architecture-04 > draft-ietf-opes-protocol-reqs-03 > draft-ietf-opes-scenarios-01 > draft-ietf-opes-authorization-02 > draft-ietf-opes-threats-02 > - Start on OPES protocol work > - Introduction > - Major decision points for protocol design > - OPES protocol pre-draft thoughts > - General discussion > > > > > > > > >--- >Incoming mail is certified Virus Free. >Checked by AVG anti-virus system (http://www.grisoft.com). >Version: 6.0.459 / Virus Database: 258 - Release Date: 25/02/03 --=======7DF765A======= Content-Type: text/plain; charset=us-ascii; x-avg=cert; x-avg-checked=avg-ok-6F0E1EF9 Content-Disposition: inline --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.459 / Virus Database: 258 - Release Date: 25/02/03 --=======7DF765A=======-- From owner-ietf-openproxy@mail.imc.org Tue Mar 11 10:48: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 KAA24425 for ; Tue, 11 Mar 2003 10:48:47 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BFDYs11509 for ietf-openproxy-bks; Tue, 11 Mar 2003 07:13:34 -0800 (PST) Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BFDT311497 for ; Tue, 11 Mar 2003 07:13:29 -0800 (PST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2BFDIA22393; Tue, 11 Mar 2003 10:13:18 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Mar 2003 10:13:18 -0500 Message-ID: <87609AFB433BD5118D5E0002A52CD754051A2749@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: jfcm , Markus Hofmann , OPES Group Subject: RE: Draft Agenda for IETF 56 Date: Tue, 11 Mar 2003 10:13:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E7E0.BC59DB72" 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_01C2E7E0.BC59DB72 Content-Type: text/plain Jfcm, good points. The discussion really affect the consideration if we should adopt SOAP or not. I do think that TCP is needed. TCP provides many faetures that we need (that is for the callout protocol). Abbie > -----Original Message----- > From: jfcm [mailto:info@utel.net] > Sent: Monday, March 10, 2003 10:14 AM > To: Markus Hofmann; OPES Group > Subject: Re: Draft Agenda for IETF 56 > > > My main question is about the entry and the ending points of the OPES > concept. If it is accepted that not only HTTP but any > protocol is OK, and > that alternatively both end points can be user/producer or > that we may have > a peer to peer support, it will mean that any entry/output > protocol is OK, > including a keyboard/user file/application etc, towards a > screen, a file, etc. > > This means there is no pseudo-synchoronous (like in hhtp) > obligation (or as > options). > This means that we have a general purpose concept of a > filter/transformer > system on a flow. > Which will standardize everywhere. > > This means that, the filter/transformer relation (callout > protocol) can be > anything from realtime to soap. Am I correct? Because this > means that we > will have a good general framework for a protected/acked > balanced protocol > able to support one to many or even many to many relations. > > Then the next question will be: will it always be under TCP? jfc > > > At 13:02 10/03/03, Markus Hofmann wrote: > >we want to continue the lively discussion on the mailing list at the > >IETF > >56 meeting in San Francisco next week. > > > >We intend to spend a few minutes provding a quick update on > the status > >of > >our five submitted WG documents, and then go immediatelly > over to the OPES > >prototol work. Focus will be on resolving the higher-level issues, > >starting with a discussion of major decision points for > protocol design > >and of the "protocol pre-draft" throughts. We will cover > further topics > >under "general discussion". > > > >If you've topics to be dicussed under "general discussion" > and would be > >interested to present in San Francisco, please send Marshall > and myself a > >note ASAP. > > > >Thanks, > > Markus > > > >----------------------------------------------------- > > > >Open Pluggable Edge Services WG (opes) > >====================================== > >Monday, March 17, 1530-1730 > > > >CHAIR(S): > > Marshall Rose > > Markus Hofmann > > > >TECHNICAL ADVISOR(S): > > Allison Mankin > > Hilarie Orman > > > >AGENDA: > > - Introduction, minutes taker, blue sheets > > - Agenda bashing > > - Status of WG documents > > draft-ietf-opes-architecture-04 > > draft-ietf-opes-protocol-reqs-03 > > draft-ietf-opes-scenarios-01 > > draft-ietf-opes-authorization-02 > > draft-ietf-opes-threats-02 > > - Start on OPES protocol work > > - Introduction > > - Major decision points for protocol design > > - OPES protocol pre-draft thoughts > > - General discussion > > > > > > > > > > > > > > > > > >--- > >Incoming mail is certified Virus Free. > >Checked by AVG anti-virus system (http://www.grisoft.com). > >Version: 6.0.459 / Virus Database: 258 - Release Date: 25/02/03 > ------_=_NextPart_001_01C2E7E0.BC59DB72 Content-Type: text/html RE: Draft Agenda for IETF 56

Jfcm,

good points. The discussion really affect the consideration if we should adopt SOAP or not.

I do think that TCP is needed. TCP provides many faetures that we need (that is for the callout protocol).


Abbie


> -----Original Message-----
> From: jfcm [mailto:info@utel.net]
> Sent: Monday, March 10, 2003 10:14 AM
> To: Markus Hofmann; OPES Group
> Subject: Re: Draft Agenda for IETF 56
>
>
> My main question is about the entry and the ending points of the OPES
> concept. If it is accepted that  not only HTTP but any
> protocol is OK, and
> that alternatively both end points can be user/producer or
> that we may have
> a peer to peer support, it will mean that any entry/output
> protocol is OK,
> including a keyboard/user file/application etc, towards a
> screen, a file, etc.
>
> This means there is no pseudo-synchoronous (like in hhtp)
> obligation (or as
> options).
> This means that we have a general purpose concept of a
> filter/transformer
> system on a flow.
> Which will standardize everywhere.
>
> This means that, the filter/transformer relation (callout
> protocol) can be
> anything from realtime to soap. Am I correct? Because this
> means that we
> will  have a good general framework for a protected/acked
> balanced protocol
> able to support one to many or even many to many relations.
>
> Then the next question will be: will it always be under TCP? jfc
>
>
> At 13:02 10/03/03, Markus Hofmann wrote:
> >we want to continue the lively discussion on the mailing list at the
> >IETF
> >56 meeting in San Francisco next week.
> >
> >We intend to spend a few minutes provding a quick update on
> the status
> >of
> >our five submitted WG documents, and then go immediatelly
> over to the OPES
> >prototol work. Focus will be on resolving the higher-level issues,
> >starting with a discussion of major decision points for
> protocol design
> >and of the "protocol pre-draft" throughts. We will cover
> further topics
> >under "general discussion".
> >
> >If you've topics to be dicussed under "general discussion"
> and would be
> >interested to present in San Francisco, please send Marshall
> and myself a
> >note ASAP.
> >
> >Thanks,
> >   Markus
> >
> >-----------------------------------------------------
> >
> >Open Pluggable Edge Services WG (opes)
> >======================================
> >Monday, March 17, 1530-1730
> >
> >CHAIR(S):
> >    Marshall Rose <mrose@dbc.mtview.ca.us>
> >    Markus Hofmann <hofmann@bell-labs.com>
> >
> >TECHNICAL ADVISOR(S):
> >    Allison Mankin <mankin@isi.edu>
> >    Hilarie Orman <ho@alum.mit.edu>
> >
> >AGENDA:
> >    - Introduction, minutes taker, blue sheets
> >    - Agenda bashing
> >    - Status of WG documents
> >        draft-ietf-opes-architecture-04
> >        draft-ietf-opes-protocol-reqs-03
> >        draft-ietf-opes-scenarios-01
> >        draft-ietf-opes-authorization-02
> >        draft-ietf-opes-threats-02
> >    - Start on OPES protocol work
> >      - Introduction
> >      - Major decision points for protocol design
> >      - OPES protocol pre-draft thoughts
> >      - General discussion
> >
> >
> >
> >
> >
> >
> >
> >
> >---
> >Incoming mail is certified Virus Free.
> >Checked by AVG anti-virus system (http://www.grisoft.com).
> >Version: 6.0.459 / Virus Database: 258 - Release Date: 25/02/03
>

------_=_NextPart_001_01C2E7E0.BC59DB72-- From owner-ietf-openproxy@mail.imc.org Tue Mar 11 12:37: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 MAA29079 for ; Tue, 11 Mar 2003 12:37:03 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BH6T021687 for ietf-openproxy-bks; Tue, 11 Mar 2003 09:06:29 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BH6S321681 for ; Tue, 11 Mar 2003 09:06:28 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h2BH6Tnx024819 for ; Tue, 11 Mar 2003 10:06:29 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h2BH6TgQ024818; Tue, 11 Mar 2003 10:06:29 -0700 (MST) (envelope-from rousskov) Date: Tue, 11 Mar 2003 10:06:29 -0700 (MST) From: Alex Rousskov To: OPES Group Subject: Re: Draft Agenda for IETF 56 In-Reply-To: <5.2.0.9.0.20030310155334.03484ec0@mail.utel.net> Message-ID: References: <5.2.0.9.0.20030310155334.03484ec0@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, 10 Mar 2003, jfcm wrote: > My main question is about the entry and the ending points of the > OPES concept. If it is accepted that not only HTTP but any protocol > is OK, and that alternatively both end points can be user/producer > or that we may have a peer to peer support, it will mean that any > entry/output protocol is OK, including a keyboard/user > file/application etc, towards a screen, a file, etc. > > This means there is no pseudo-synchoronous (like in hhtp) obligation > (or as options). This means that we have a general purpose concept > of a filter/transformer system on a flow. Which will standardize > everywhere. > > This means that, the filter/transformer relation (callout protocol) > can be anything from realtime to soap. Am I correct? I doubt we can design a good OPES system that can support adaptation of anything from highly optimized realtime protocols to structure-rich, super extensible XML protocols. There will be tradeoffs that we will have to resolve one way or the other. That is why it is important to agree on scope and use cases up-front. > Because this means that we will have a good general framework for a > protected/acked balanced protocol able to support one to many or > even many to many relations. We should strive for that, but IMO we will come short as things get more specific. > Then the next question will be: will it always be under TCP? Transport protocol binding wise, TCP is probably not the only option. We do need a reliable, order-preserving, congestion-aware protocol though (see protocol requirements draft for details). These features may already exclude certain realtime optimizations where losing packets is not only acceptable but desirable in the presence of unexpected delays or congestion. An important design question is whether the OPES protocol should allow multiple transport bindings/encodings or just one. Alex. From owner-ietf-openproxy@mail.imc.org Tue Mar 11 13:11: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 NAA00100 for ; Tue, 11 Mar 2003 13:10:57 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BHiKf25230 for ietf-openproxy-bks; Tue, 11 Mar 2003 09:44:20 -0800 (PST) Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BHiI325226 for ; Tue, 11 Mar 2003 09:44:18 -0800 (PST) Received: from f04v-1-17.d1.club-internet.fr ([212.194.60.17] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 18snnG-0004il-00; Tue, 11 Mar 2003 09:44:02 -0800 Message-Id: <5.2.0.9.0.20030311184713.042829a0@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 11 Mar 2003 18:50:13 +0100 To: "Abbie Barbir" , Markus Hofmann , OPES Group From: jfcm Subject: RE: Draft Agenda for IETF 56 In-Reply-To: <87609AFB433BD5118D5E0002A52CD754051A2749@zcard0k6.ca.norte l.com> Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-108732EC; boundary="=======261C1A2E=======" 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: --=======261C1A2E======= Content-Type: multipart/alternative; x-avg-checked=avg-ok-108732EC; boundary="=====================_4607807==.ALT" --=====================_4607807==.ALT Content-Type: text/plain; x-avg-checked=avg-ok-108732EC; charset=us-ascii; format=flowed Content-Transfer-Encoding: 8bit At 16:13 11/03/03, Abbie Barbir wrote: >Jfcm, >good points. The discussion really affect the consideration if we should >adopt SOAP or not. >I do think that TCP is needed. TCP provides many faetures that we need >(that is for the callout protocol). Certainly. What I mean is that dependng on the where, speed, security, interactivity, there may be many ways to implement the OPES protocl. I suppose that IP will be used in most of the cases - not sure as it would fit well under a qnet (QNX) system. So the envelopes could be very different while the relation process between dispatchers and servers could be the same. jfc > > -----Original Message----- > > From: jfcm [mailto:info@utel.net] > > Sent: Monday, March 10, 2003 10:14 AM > > To: Markus Hofmann; OPES Group > > Subject: Re: Draft Agenda for IETF 56 > > > > > > My main question is about the entry and the ending points of the OPES > > concept. If it is accepted that not only HTTP but any > > protocol is OK, and > > that alternatively both end points can be user/producer or > > that we may have > > a peer to peer support, it will mean that any entry/output > > protocol is OK, > > including a keyboard/user file/application etc, towards a > > screen, a file, etc. > > > > This means there is no pseudo-synchoronous (like in hhtp) > > obligation (or as > > options). > > This means that we have a general purpose concept of a > > filter/transformer > > system on a flow. > > Which will standardize everywhere. > > > > This means that, the filter/transformer relation (callout > > protocol) can be > > anything from realtime to soap. Am I correct? Because this > > means that we > > will have a good general framework for a protected/acked > > balanced protocol > > able to support one to many or even many to many relations. > > > > Then the next question will be: will it always be under TCP? jfc > > > > > > At 13:02 10/03/03, Markus Hofmann wrote: > > >we want to continue the lively discussion on the mailing list at the > > >IETF > > >56 meeting in San Francisco next week. > > > > > >We intend to spend a few minutes provding a quick update on > > the status > > >of > > >our five submitted WG documents, and then go immediatelly > > over to the OPES > > >prototol work. Focus will be on resolving the higher-level issues, > > >starting with a discussion of major decision points for > > protocol design > > >and of the "protocol pre-draft" throughts. We will cover > > further topics > > >under "general discussion". > > > > > >If you've topics to be dicussed under "general discussion" > > and would be > > >interested to present in San Francisco, please send Marshall > > and myself a > > >note ASAP. > > > > > >Thanks, > > > Markus > > > > > >----------------------------------------------------- > > > > > >Open Pluggable Edge Services WG (opes) > > >====================================== > > >Monday, March 17, 1530-1730 > > > > > >CHAIR(S): > > > Marshall Rose > > > Markus Hofmann > > > > > >TECHNICAL ADVISOR(S): > > > Allison Mankin > > > Hilarie Orman > > > > > >AGENDA: > > > - Introduction, minutes taker, blue sheets > > > - Agenda bashing > > > - Status of WG documents > > > draft-ietf-opes-architecture-04 > > > draft-ietf-opes-protocol-reqs-03 > > > draft-ietf-opes-scenarios-01 > > > draft-ietf-opes-authorization-02 > > > draft-ietf-opes-threats-02 > > > - Start on OPES protocol work > > > - Introduction > > > - Major decision points for protocol design > > > - OPES protocol pre-draft thoughts > > > - General discussion > > > > > > > > > > > > > > > > > > > > > > > > > > >--- > > >Incoming mail is certified Virus Free. > > >Checked by AVG anti-virus system > (http://www.grisoft.com). > > >Version: 6.0.459 / Virus Database: 258 - Release Date: 25/02/03 > > > >--- >Incoming mail is certified Virus Free. >Checked by AVG anti-virus system (http://www.grisoft.com). >Version: 6.0.459 / Virus Database: 258 - Release Date: 25/02/03 --=====================_4607807==.ALT Content-Type: text/html; x-avg-checked=avg-ok-108732EC; charset=us-ascii Content-Transfer-Encoding: 8bit At 16:13 11/03/03, Abbie Barbir wrote:
Jfcm,
good points. The discussion really affect the consideration if we should adopt SOAP or not.
I do think that TCP is needed. TCP provides many faetures that we need (that is for the callout protocol).

Certainly. What I mean is that dependng on the where, speed, security, interactivity, there may be many ways to implement the OPES protocl. I suppose that IP will be used in most of the cases - not sure  as it would fit well under a qnet (QNX) system. So the envelopes could be very different while the relation process between dispatchers and servers could be the same.
jfc




> -----Original Message-----
> From: jfcm [mailto:info@utel.net]
> Sent: Monday, March 10, 2003 10:14 AM
> To: Markus Hofmann; OPES Group
> Subject: Re: Draft Agenda for IETF 56
>
>
> My main question is about the entry and the ending points of the OPES
> concept. If it is accepted that  not only HTTP but any
> protocol is OK, and
> that alternatively both end points can be user/producer or
> that we may have
> a peer to peer support, it will mean that any entry/output
> protocol is OK,
> including a keyboard/user file/application etc, towards a
> screen, a file, etc.
>
> This means there is no pseudo-synchoronous (like in hhtp)
> obligation (or as
> options).
> This means that we have a general purpose concept of a
> filter/transformer
> system on a flow.
> Which will standardize everywhere.
>
> This means that, the filter/transformer relation (callout
> protocol) can be
> anything from realtime to soap. Am I correct? Because this
> means that we
> will  have a good general framework for a protected/acked
> balanced protocol
> able to support one to many or even many to many relations.
>
> Then the next question will be: will it always be under TCP? jfc
>
>
> At 13:02 10/03/03, Markus Hofmann wrote:
> >we want to continue the lively discussion on the mailing list at the
> >IETF
> >56 meeting in San Francisco next week.
> >
> >We intend to spend a few minutes provding a quick update on
> the status
> >of
> >our five submitted WG documents, and then go immediatelly
> over to the OPES
> >prototol work. Focus will be on resolving the higher-level issues,
> >starting with a discussion of major decision points for
> protocol design
> >and of the "protocol pre-draft" throughts. We will cover
> further topics
> >under "general discussion".
> >
> >If you've topics to be dicussed under "general discussion"
> and would be
> >interested to present in San Francisco, please send Marshall
> and myself a
> >note ASAP.
> >
> >Thanks,
> >   Markus
> >
> >-----------------------------------------------------
> >
> >Open Pluggable Edge Services WG (opes)
> >======================================
> >Monday, March 17, 1530-1730
> >
> >CHAIR(S):
> >    Marshall Rose <mrose@dbc.mtview.ca.us>
> >    Markus Hofmann <hofmann@bell-labs.com>
> >
> >TECHNICAL ADVISOR(S):
> >    Allison Mankin <mankin@isi.edu>
> >    Hilarie Orman <ho@alum.mit.edu>
> >
> >AGENDA:
> >    - Introduction, minutes taker, blue sheets
> >    - Agenda bashing
> >    - Status of WG documents
> >        draft-ietf-opes-architecture-04
> >        draft-ietf-opes-protocol-reqs-03
> >        draft-ietf-opes-scenarios-01
> >        draft-ietf-opes-authorization-02
> >        draft-ietf-opes-threats-02
> >    - Start on OPES protocol work
> >      - Introduction
> >      - Major decision points for protocol design
> >      - OPES protocol pre-draft thoughts
> >      - General discussion
> >
> >
> >
> >
> >
> >
> >
> >
> >---
> >Incoming mail is certified Virus Free.
> >Checked by AVG anti-virus system (http://www.grisoft.com).
> >Version: 6.0.459 / Virus Database: 258 - Release Date: 25/02/03
>

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.459 / Virus Database: 258 - Release Date: 25/02/03
--=====================_4607807==.ALT-- --=======261C1A2E======= Content-Type: text/plain; charset=us-ascii; x-avg=cert; x-avg-checked=avg-ok-108732EC Content-Disposition: inline --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.459 / Virus Database: 258 - Release Date: 25/02/03 --=======261C1A2E=======-- From owner-ietf-openproxy@mail.imc.org Tue Mar 11 13:54: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 NAA02233 for ; Tue, 11 Mar 2003 13:54:42 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BIMUV27247 for ietf-openproxy-bks; Tue, 11 Mar 2003 10:22:30 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BIMT327238 for ; Tue, 11 Mar 2003 10:22:29 -0800 (PST) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2BIMHa04123; Tue, 11 Mar 2003 12:22:18 -0600 (CST) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1LW2TWPM>; Tue, 11 Mar 2003 10:22:18 -0800 Message-ID: <0A11633F61BD9F40B43ABCC694004F93F18E19@zsc3c026.us.nortel.com> From: "Reinaldo Penno" To: "'Alex Rousskov'" , OPES Group Subject: RE: Draft Agenda for IETF 56 Date: Tue, 11 Mar 2003 10:22:16 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E7FB.25346FDA" 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_01C2E7FB.25346FDA Content-Type: text/plain If I remember correctly the decision reached some time ago during a conference call was that the callout transport protocol would be the same one used between user<----...OPES box....--->consumer Not sure if we updated the protocol requirements draft accordingly. Actually there was a section on transport negotiation that we took out because some believed it had too many borderline cases. Because there is no transport negotiation anymore we decided to go with the approach I described earlier. Regards, Reinaldo -----Original Message----- From: Alex Rousskov [mailto:rousskov@measurement-factory.com] Sent: Tuesday, March 11, 2003 12:06 PM To: OPES Group Subject: Re: Draft Agenda for IETF 56 On Mon, 10 Mar 2003, jfcm wrote: > My main question is about the entry and the ending points of the OPES > concept. If it is accepted that not only HTTP but any protocol is OK, > and that alternatively both end points can be user/producer or that we > may have a peer to peer support, it will mean that any entry/output > protocol is OK, including a keyboard/user file/application etc, > towards a screen, a file, etc. > > This means there is no pseudo-synchoronous (like in hhtp) obligation > (or as options). This means that we have a general purpose concept of > a filter/transformer system on a flow. Which will standardize > everywhere. > > This means that, the filter/transformer relation (callout protocol) > can be anything from realtime to soap. Am I correct? I doubt we can design a good OPES system that can support adaptation of anything from highly optimized realtime protocols to structure-rich, super extensible XML protocols. There will be tradeoffs that we will have to resolve one way or the other. That is why it is important to agree on scope and use cases up-front. > Because this means that we will have a good general framework for a > protected/acked balanced protocol able to support one to many or even > many to many relations. We should strive for that, but IMO we will come short as things get more specific. > Then the next question will be: will it always be under TCP? Transport protocol binding wise, TCP is probably not the only option. We do need a reliable, order-preserving, congestion-aware protocol though (see protocol requirements draft for details). These features may already exclude certain realtime optimizations where losing packets is not only acceptable but desirable in the presence of unexpected delays or congestion. An important design question is whether the OPES protocol should allow multiple transport bindings/encodings or just one. Alex. ------_=_NextPart_001_01C2E7FB.25346FDA Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Draft Agenda for IETF 56

If I remember correctly the decision reached some = time ago during a conference call was that the callout transport = protocol would be the same one used between user<----...OPES = box....--->consumer

Not sure if we updated the protocol requirements = draft accordingly. Actually there was a section on transport = negotiation that we took out because some believed it had too many = borderline cases. Because there is no transport negotiation anymore we = decided to go with the approach I described earlier.

Regards,

Reinaldo

-----Original Message-----
From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
Sent: Tuesday, March 11, 2003 12:06 PM
To: OPES Group
Subject: Re: Draft Agenda for IETF 56



On Mon, 10 Mar 2003, jfcm wrote:

> My main question is about the entry and the = ending points of the OPES
> concept. If it is accepted that not only HTTP = but any protocol is OK,
> and that alternatively both end points can be = user/producer or that we
> may have a peer to peer support, it will mean = that any entry/output
> protocol is OK, including a keyboard/user = file/application etc,
> towards a screen, a file, etc.
>
> This means there is no pseudo-synchoronous = (like in hhtp) obligation
> (or as options). This means that we have a = general purpose concept of
> a filter/transformer system on a flow. Which = will standardize
> everywhere.
>
> This means that, the filter/transformer = relation (callout protocol)
> can be anything from realtime to soap. Am I = correct?

I doubt we can design a good OPES system that can = support adaptation of anything from highly optimized realtime protocols = to structure-rich, super extensible XML protocols. There will be = tradeoffs that we will have to resolve one way or the other. That is = why it is important to agree on scope and use cases = up-front.

> Because this means that we will have a good = general framework for a
> protected/acked balanced protocol able to = support one to many or even
> many to many relations.

We should strive for that, but IMO we will come short = as things get more specific.

> Then the next question will be: will it always = be under TCP?

Transport protocol binding wise, TCP is probably not = the only option. We do need a reliable, order-preserving, = congestion-aware protocol though (see protocol requirements draft for = details). These features may already exclude certain realtime = optimizations where losing packets is not only acceptable but desirable = in the presence of unexpected delays or congestion.

An important design question is whether the OPES = protocol should allow multiple transport bindings/encodings or just = one.

Alex.

------_=_NextPart_001_01C2E7FB.25346FDA-- From owner-ietf-openproxy@mail.imc.org Tue Mar 11 14:04: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 OAA03433 for ; Tue, 11 Mar 2003 14:04:25 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BIVOP27630 for ietf-openproxy-bks; Tue, 11 Mar 2003 10:31:24 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BIVM327626 for ; Tue, 11 Mar 2003 10:31:22 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h2BIVOnx026854 for ; Tue, 11 Mar 2003 11:31:24 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h2BIVOZo026853; Tue, 11 Mar 2003 11:31:24 -0700 (MST) (envelope-from rousskov) Date: Tue, 11 Mar 2003 11:31:24 -0700 (MST) From: Alex Rousskov To: OPES Group Subject: RE: Draft Agenda for IETF 56 In-Reply-To: <0A11633F61BD9F40B43ABCC694004F93F18E19@zsc3c026.us.nortel.com> Message-ID: References: <0A11633F61BD9F40B43ABCC694004F93F18E19@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 Tue, 11 Mar 2003, Reinaldo Penno wrote: > If I remember correctly the decision reached some time ago during a > conference call was that the callout transport protocol would be the > same one used between user<----...OPES box....--->consumer Reinaldo, I am confused: Callout protocol is the one OPES dispatcher uses to talk to the callout server. Why do you have "user", "OPES box", and "consumer" in your picture if you are talking about the callout protocol? The callout protocol is used _inside_ the OPES box, not outside it, AFAIK. Did you mean application protocol instead? If so, would it be accurate to say that the conference call resulted in a decision to prohibit application protocol conversion by OPES (e.g., converting HTTP to FTP)? Please clarify or point to the relevant documents. BTW, were the conference call minutes posted on the list? Thank you, Alex. > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Tuesday, March 11, 2003 12:06 PM > To: OPES Group > Subject: Re: Draft Agenda for IETF 56 > > > > On Mon, 10 Mar 2003, jfcm wrote: > > > My main question is about the entry and the ending points of the OPES > > concept. If it is accepted that not only HTTP but any protocol is OK, > > and that alternatively both end points can be user/producer or that we > > may have a peer to peer support, it will mean that any entry/output > > protocol is OK, including a keyboard/user file/application etc, > > towards a screen, a file, etc. > > > > This means there is no pseudo-synchoronous (like in hhtp) obligation > > (or as options). This means that we have a general purpose concept of > > a filter/transformer system on a flow. Which will standardize > > everywhere. > > > > This means that, the filter/transformer relation (callout protocol) > > can be anything from realtime to soap. Am I correct? > > I doubt we can design a good OPES system that can support adaptation of > anything from highly optimized realtime protocols to structure-rich, super > extensible XML protocols. There will be tradeoffs that we will have to > resolve one way or the other. That is why it is important to agree on scope > and use cases up-front. > > > Because this means that we will have a good general framework for a > > protected/acked balanced protocol able to support one to many or even > > many to many relations. > > We should strive for that, but IMO we will come short as things get more > specific. > > > Then the next question will be: will it always be under TCP? > > Transport protocol binding wise, TCP is probably not the only option. We do > need a reliable, order-preserving, congestion-aware protocol though (see > protocol requirements draft for details). These features may already exclude > certain realtime optimizations where losing packets is not only acceptable > but desirable in the presence of unexpected delays or congestion. > > An important design question is whether the OPES protocol should allow > multiple transport bindings/encodings or just one. > > Alex. > From owner-ietf-openproxy@mail.imc.org Tue Mar 11 14:35: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 OAA06827 for ; Tue, 11 Mar 2003 14:35:13 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BJ1Zb29119 for ietf-openproxy-bks; Tue, 11 Mar 2003 11:01:35 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BJ1X329114 for ; Tue, 11 Mar 2003 11:01:34 -0800 (PST) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2BJ1Na09223; Tue, 11 Mar 2003 13:01:23 -0600 (CST) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1LW2T5P3>; Tue, 11 Mar 2003 11:01:24 -0800 Message-ID: <0A11633F61BD9F40B43ABCC694004F93F18E1C@zsc3c026.us.nortel.com> From: "Reinaldo Penno" To: "'Alex Rousskov'" , OPES Group Subject: RE: Draft Agenda for IETF 56 Date: Tue, 11 Mar 2003 11:01:22 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E800.9B427CA8" 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_01C2E800.9B427CA8 Content-Type: text/plain I guess an example is better... If you are running a media session with a friend, let's say RTP over UDP, and the opes dispatcher (between you two) decides that this media needs adaptaion because you are on a cell phone. In this case the callout protocol should (may?) run over UDP. This is a simple effort in order to guess the best transport protocol to use in the callout protocol for this specific session. Is this clearer? Ps: OPES box meant just a device running the dispatcher. The callout server is not included in the box. -----Original Message----- From: Alex Rousskov [mailto:rousskov@measurement-factory.com] Sent: Tuesday, March 11, 2003 1:31 PM To: OPES Group Subject: RE: Draft Agenda for IETF 56 On Tue, 11 Mar 2003, Reinaldo Penno wrote: > If I remember correctly the decision reached some time ago during a > conference call was that the callout transport protocol would be the > same one used between user<----...OPES box....--->consumer Reinaldo, I am confused: Callout protocol is the one OPES dispatcher uses to talk to the callout server. Why do you have "user", "OPES box", and "consumer" in your picture if you are talking about the callout protocol? The callout protocol is used _inside_ the OPES box, not outside it, AFAIK. Did you mean application protocol instead? If so, would it be accurate to say that the conference call resulted in a decision to prohibit application protocol conversion by OPES (e.g., converting HTTP to FTP)? Please clarify or point to the relevant documents. BTW, were the conference call minutes posted on the list? Thank you, Alex. > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Tuesday, March 11, 2003 12:06 PM > To: OPES Group > Subject: Re: Draft Agenda for IETF 56 > > > > On Mon, 10 Mar 2003, jfcm wrote: > > > My main question is about the entry and the ending points of the > > OPES concept. If it is accepted that not only HTTP but any protocol > > is OK, and that alternatively both end points can be user/producer > > or that we may have a peer to peer support, it will mean that any > > entry/output protocol is OK, including a keyboard/user > > file/application etc, towards a screen, a file, etc. > > > > This means there is no pseudo-synchoronous (like in hhtp) obligation > > (or as options). This means that we have a general purpose concept > > of a filter/transformer system on a flow. Which will standardize > > everywhere. > > > > This means that, the filter/transformer relation (callout protocol) > > can be anything from realtime to soap. Am I correct? > > I doubt we can design a good OPES system that can support adaptation > of anything from highly optimized realtime protocols to > structure-rich, super extensible XML protocols. There will be > tradeoffs that we will have to resolve one way or the other. That is > why it is important to agree on scope and use cases up-front. > > > Because this means that we will have a good general framework for a > > protected/acked balanced protocol able to support one to many or > > even many to many relations. > > We should strive for that, but IMO we will come short as things get > more specific. > > > Then the next question will be: will it always be under TCP? > > Transport protocol binding wise, TCP is probably not the only option. > We do need a reliable, order-preserving, congestion-aware protocol > though (see protocol requirements draft for details). These features > may already exclude certain realtime optimizations where losing > packets is not only acceptable but desirable in the presence of > unexpected delays or congestion. > > An important design question is whether the OPES protocol should allow > multiple transport bindings/encodings or just one. > > Alex. > ------_=_NextPart_001_01C2E800.9B427CA8 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Draft Agenda for IETF 56

I guess an example is better...

If you are running a media session with a friend, = let's say RTP over UDP, and the opes dispatcher (between you two) = decides that this media needs adaptaion because you are on a cell = phone.

In this case the callout protocol should (may?) run = over UDP. This is a simple effort in order to guess the best transport = protocol to use in the callout protocol for this specific session. =

Is this clearer?

Ps: OPES box meant just a device running the = dispatcher. The callout server is not included in the box.

-----Original Message-----
From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
Sent: Tuesday, March 11, 2003 1:31 PM
To: OPES Group
Subject: RE: Draft Agenda for IETF 56



On Tue, 11 Mar 2003, Reinaldo Penno wrote:

> If I remember correctly the decision reached = some time ago during a
> conference call was that the callout transport = protocol would be the
> same one used between user<----...OPES = box....--->consumer

Reinaldo,

        I am = confused: Callout protocol is the one OPES dispatcher uses to talk to = the callout server. Why do you have "user", "OPES = box", and "consumer" in your picture if you are talking = about the callout protocol? The callout protocol is used _inside_ the = OPES box, not outside it, AFAIK.

Did you mean application protocol instead? If so, = would it be accurate to say that the conference call resulted in a = decision to prohibit application protocol conversion by OPES (e.g., = converting HTTP to FTP)?

Please clarify or point to the relevant documents. = BTW, were the conference call minutes posted on the list?

Thank you,

Alex.


> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Tuesday, March 11, 2003 12:06 PM
> To: OPES Group
> Subject: Re: Draft Agenda for IETF 56
>
>
>
> On Mon, 10 Mar 2003, jfcm wrote:
>
> > My main question is about the entry and = the ending points of the
> > OPES concept. If it is accepted that not = only HTTP but any protocol
> > is OK, and that alternatively both end = points can be user/producer
> > or that we may have a peer to peer = support, it will mean that any
> > entry/output protocol is OK, including a = keyboard/user
> > file/application etc, towards a screen, a = file, etc.
> >
> > This means there is no pseudo-synchoronous = (like in hhtp) obligation
> > (or as options). This means that we have a = general purpose concept
> > of a filter/transformer system on a flow. = Which will standardize
> > everywhere.
> >
> > This means that, the filter/transformer = relation (callout protocol)
> > can be anything from realtime to soap. Am = I correct?
>
> I doubt we can design a good OPES system that = can support adaptation
> of anything from highly optimized realtime = protocols to
> structure-rich, super extensible XML protocols. = There will be
> tradeoffs that we will have to resolve one way = or the other. That is
> why it is important to agree on scope and use = cases up-front.
>
> > Because this means that we will have a = good general framework for a
> > protected/acked balanced protocol able to = support one to many or
> > even many to many relations.
>
> We should strive for that, but IMO we will come = short as things get
> more specific.
>
> > Then the next question will be: will it = always be under TCP?
>
> Transport protocol binding wise, TCP is = probably not the only option.
> We do need a reliable, order-preserving, = congestion-aware protocol
> though (see protocol requirements draft for = details). These features
> may already exclude certain realtime = optimizations where losing
> packets is not only acceptable but desirable in = the presence of
> unexpected delays or congestion.
>
> An important design question is whether the = OPES protocol should allow
> multiple transport bindings/encodings or just = one.
>
> Alex.
>

------_=_NextPart_001_01C2E800.9B427CA8-- From owner-ietf-openproxy@mail.imc.org Tue Mar 11 14:40: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 OAA07217 for ; Tue, 11 Mar 2003 14:40:18 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BJGBL29927 for ietf-openproxy-bks; Tue, 11 Mar 2003 11:16:11 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BJGA329923 for ; Tue, 11 Mar 2003 11:16:10 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h2BJGCnx028877 for ; Tue, 11 Mar 2003 12:16:12 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h2BJGCvh028876; Tue, 11 Mar 2003 12:16:12 -0700 (MST) (envelope-from rousskov) Date: Tue, 11 Mar 2003 12:16:12 -0700 (MST) From: Alex Rousskov To: OPES Group Subject: RE: Draft Agenda for IETF 56 In-Reply-To: <0A11633F61BD9F40B43ABCC694004F93F18E1C@zsc3c026.us.nortel.com> Message-ID: References: <0A11633F61BD9F40B43ABCC694004F93F18E1C@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 Tue, 11 Mar 2003, Reinaldo Penno wrote: > If you are running a media session with a friend, let's say RTP over > UDP, and the opes dispatcher (between you two) decides that this > media needs adaptaion because you are on a cell phone. > > In this case the callout protocol should (may?) run over UDP. This > is a simple effort in order to guess the best transport protocol to > use in the callout protocol for this specific session. > > Is this clearer? Yes, thank you! You are saying that both application protocol and callout protocol should (may?) use the same transport protocol, right? This means that either we cannot support application protocols that use UDP (and other lossy/etc protocols), or we will be violating current callout protocol requirements (that demand reliable congestion-aware transport): 3.1 Reliability The OPES callout protocol MUST be able to provide ordered reliability for the communication between OPES processor and callout server. Additionally, the callout protocol SHOULD be able to provide unordered reliability. In order to satisfy the reliability requirements, the callout protocol SHOULD specify that it must be used with a transport protocol which provides ordered/unordered reliability at the transport-layer, for example TCP [6] or SCTP [7]. 3.2 Congestion Avoidance The OPES callout protocol MUST ensure that congestion avoidance that matches the standard of RFC 2914 [4] is applied on all communication between OPES processor and callout server. For this purpose, the callout protocol SHOULD use a congestion-controlled transport-layer protocol, presumably either TCP [6] or SCTP [7]. IMO, callout protocol has sufficiently different purpose to deserve its own transport binding, which MAY be the same as application transport for some applications, but does not have to be. This approach would let us support adaptation of application protocols that do not satisfy OPES transport requirements. Thank you, Alex. > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Tuesday, March 11, 2003 1:31 PM > To: OPES Group > Subject: RE: Draft Agenda for IETF 56 > > > > On Tue, 11 Mar 2003, Reinaldo Penno wrote: > > > If I remember correctly the decision reached some time ago during a > > conference call was that the callout transport protocol would be the > > same one used between user<----...OPES box....--->consumer > > Reinaldo, > > I am confused: Callout protocol is the one OPES dispatcher uses to > talk to the callout server. Why do you have "user", "OPES box", and > "consumer" in your picture if you are talking about the callout protocol? > The callout protocol is used _inside_ the OPES box, not outside it, AFAIK. > > Did you mean application protocol instead? If so, would it be accurate to > say that the conference call resulted in a decision to prohibit application > protocol conversion by OPES (e.g., converting HTTP to FTP)? > > Please clarify or point to the relevant documents. BTW, were the conference > call minutes posted on the list? > > Thank you, > > Alex. > > > > -----Original Message----- > > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > > Sent: Tuesday, March 11, 2003 12:06 PM > > To: OPES Group > > Subject: Re: Draft Agenda for IETF 56 > > > > > > > > On Mon, 10 Mar 2003, jfcm wrote: > > > > > My main question is about the entry and the ending points of the > > > OPES concept. If it is accepted that not only HTTP but any protocol > > > is OK, and that alternatively both end points can be user/producer > > > or that we may have a peer to peer support, it will mean that any > > > entry/output protocol is OK, including a keyboard/user > > > file/application etc, towards a screen, a file, etc. > > > > > > This means there is no pseudo-synchoronous (like in hhtp) obligation > > > (or as options). This means that we have a general purpose concept > > > of a filter/transformer system on a flow. Which will standardize > > > everywhere. > > > > > > This means that, the filter/transformer relation (callout protocol) > > > can be anything from realtime to soap. Am I correct? > > > > I doubt we can design a good OPES system that can support adaptation > > of anything from highly optimized realtime protocols to > > structure-rich, super extensible XML protocols. There will be > > tradeoffs that we will have to resolve one way or the other. That is > > why it is important to agree on scope and use cases up-front. > > > > > Because this means that we will have a good general framework for a > > > protected/acked balanced protocol able to support one to many or > > > even many to many relations. > > > > We should strive for that, but IMO we will come short as things get > > more specific. > > > > > Then the next question will be: will it always be under TCP? > > > > Transport protocol binding wise, TCP is probably not the only option. > > We do need a reliable, order-preserving, congestion-aware protocol > > though (see protocol requirements draft for details). These features > > may already exclude certain realtime optimizations where losing > > packets is not only acceptable but desirable in the presence of > > unexpected delays or congestion. > > > > An important design question is whether the OPES protocol should allow > > multiple transport bindings/encodings or just one. > > > > Alex. > > > From owner-ietf-openproxy@mail.imc.org Tue Mar 11 15:10: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 PAA09396 for ; Tue, 11 Mar 2003 15:10:42 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BJlfE02744 for ietf-openproxy-bks; Tue, 11 Mar 2003 11:47:41 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BJle302740 for ; Tue, 11 Mar 2003 11:47:40 -0800 (PST) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2BJlYa16378; Tue, 11 Mar 2003 13:47:34 -0600 (CST) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1LW2T8ZQ>; Tue, 11 Mar 2003 11:47:35 -0800 Message-ID: <0A11633F61BD9F40B43ABCC694004F93F18E1F@zsc3c026.us.nortel.com> From: "Reinaldo Penno" To: "'Alex Rousskov'" , OPES Group Subject: RE: Draft Agenda for IETF 56 Date: Tue, 11 Mar 2003 11:47:32 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E807.0E6466D2" 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_01C2E807.0E6466D2 Content-Type: text/plain Yes, I understand the current requirements, but since HTTP is the protocol in-scope at the moment and there is a push in the IETF (the chairs/ADs can correct me if I'm wrong) to use congestion aware protocols, we thought using SCTP might be a good compromise for those that think TCP is not appropiate. We had the same debate in another WG that is chossing an transport protocol and although some people wanted UDP the AD said the protocol must be congestion aware. Anyway, we can revisit this issue if people think it does not cater to the needs of OPES deployments. Regards, Reinaldo -----Original Message----- From: Alex Rousskov [mailto:rousskov@measurement-factory.com] Sent: Tuesday, March 11, 2003 2:16 PM To: OPES Group Subject: RE: Draft Agenda for IETF 56 On Tue, 11 Mar 2003, Reinaldo Penno wrote: > If you are running a media session with a friend, let's say RTP over > UDP, and the opes dispatcher (between you two) decides that this media > needs adaptaion because you are on a cell phone. > > In this case the callout protocol should (may?) run over UDP. This is > a simple effort in order to guess the best transport protocol to use > in the callout protocol for this specific session. > > Is this clearer? Yes, thank you! You are saying that both application protocol and callout protocol should (may?) use the same transport protocol, right? This means that either we cannot support application protocols that use UDP (and other lossy/etc protocols), or we will be violating current callout protocol requirements (that demand reliable congestion-aware transport): 3.1 Reliability The OPES callout protocol MUST be able to provide ordered reliability for the communication between OPES processor and callout server. Additionally, the callout protocol SHOULD be able to provide unordered reliability. In order to satisfy the reliability requirements, the callout protocol SHOULD specify that it must be used with a transport protocol which provides ordered/unordered reliability at the transport-layer, for example TCP [6] or SCTP [7]. 3.2 Congestion Avoidance The OPES callout protocol MUST ensure that congestion avoidance that matches the standard of RFC 2914 [4] is applied on all communication between OPES processor and callout server. For this purpose, the callout protocol SHOULD use a congestion-controlled transport-layer protocol, presumably either TCP [6] or SCTP [7]. IMO, callout protocol has sufficiently different purpose to deserve its own transport binding, which MAY be the same as application transport for some applications, but does not have to be. This approach would let us support adaptation of application protocols that do not satisfy OPES transport requirements. Thank you, Alex. > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Tuesday, March 11, 2003 1:31 PM > To: OPES Group > Subject: RE: Draft Agenda for IETF 56 > > > > On Tue, 11 Mar 2003, Reinaldo Penno wrote: > > > If I remember correctly the decision reached some time ago during a > > conference call was that the callout transport protocol would be the > > same one used between user<----...OPES box....--->consumer > > Reinaldo, > > I am confused: Callout protocol is the one OPES dispatcher uses to > talk to the callout server. Why do you have "user", "OPES box", and > "consumer" in your picture if you are talking about the callout > protocol? The callout protocol is used _inside_ the OPES box, not > outside it, AFAIK. > > Did you mean application protocol instead? If so, would it be accurate > to say that the conference call resulted in a decision to prohibit > application protocol conversion by OPES (e.g., converting HTTP to > FTP)? > > Please clarify or point to the relevant documents. BTW, were the > conference call minutes posted on the list? > > Thank you, > > Alex. > > > > -----Original Message----- > > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > > Sent: Tuesday, March 11, 2003 12:06 PM > > To: OPES Group > > Subject: Re: Draft Agenda for IETF 56 > > > > > > > > On Mon, 10 Mar 2003, jfcm wrote: > > > > > My main question is about the entry and the ending points of the > > > OPES concept. If it is accepted that not only HTTP but any > > > protocol is OK, and that alternatively both end points can be > > > user/producer or that we may have a peer to peer support, it will > > > mean that any entry/output protocol is OK, including a > > > keyboard/user file/application etc, towards a screen, a file, etc. > > > > > > This means there is no pseudo-synchoronous (like in hhtp) > > > obligation (or as options). This means that we have a general > > > purpose concept of a filter/transformer system on a flow. Which > > > will standardize everywhere. > > > > > > This means that, the filter/transformer relation (callout > > > protocol) can be anything from realtime to soap. Am I correct? > > > > I doubt we can design a good OPES system that can support adaptation > > of anything from highly optimized realtime protocols to > > structure-rich, super extensible XML protocols. There will be > > tradeoffs that we will have to resolve one way or the other. That is > > why it is important to agree on scope and use cases up-front. > > > > > Because this means that we will have a good general framework for > > > a protected/acked balanced protocol able to support one to many or > > > even many to many relations. > > > > We should strive for that, but IMO we will come short as things get > > more specific. > > > > > Then the next question will be: will it always be under TCP? > > > > Transport protocol binding wise, TCP is probably not the only > > option. We do need a reliable, order-preserving, congestion-aware > > protocol though (see protocol requirements draft for details). These > > features may already exclude certain realtime optimizations where > > losing packets is not only acceptable but desirable in the presence > > of unexpected delays or congestion. > > > > An important design question is whether the OPES protocol should > > allow multiple transport bindings/encodings or just one. > > > > Alex. > > > ------_=_NextPart_001_01C2E807.0E6466D2 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Draft Agenda for IETF 56

Yes, I understand the current requirements, but since = HTTP is the protocol in-scope at the moment and there is a push in the = IETF (the chairs/ADs can correct me if I'm wrong) to use congestion = aware protocols, we thought using SCTP might be a good compromise for = those that think TCP is not appropiate.

We had the same debate in another WG that is chossing = an transport protocol and although some people wanted UDP the AD said = the protocol must be congestion aware. Anyway, we can revisit this = issue if people think it does not cater to the needs of OPES = deployments.

Regards,

Reinaldo

-----Original Message-----
From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
Sent: Tuesday, March 11, 2003 2:16 PM
To: OPES Group
Subject: RE: Draft Agenda for IETF 56



On Tue, 11 Mar 2003, Reinaldo Penno wrote:

> If you are running a media session with a = friend, let's say RTP over
> UDP, and the opes dispatcher (between you two) = decides that this media
> needs adaptaion because you are on a cell = phone.
>
> In this case the callout protocol should (may?) = run over UDP. This is
> a simple effort in order to guess the best = transport protocol to use
> in the callout protocol for this specific = session.
>
> Is this clearer?

Yes, thank you! You are saying that both application = protocol and callout protocol should (may?) use the same transport = protocol, right?

This means that either we cannot support application = protocols that use UDP (and other lossy/etc protocols), or we will be = violating current callout protocol requirements (that demand reliable = congestion-aware transport):

3.1 Reliability

   The OPES callout protocol MUST be able = to provide ordered reliability
   for the communication between OPES = processor and callout server.
   Additionally, the callout protocol = SHOULD be able to provide
   unordered reliability.

   In order to satisfy the reliability = requirements, the callout
   protocol SHOULD specify that it must be = used with a transport
   protocol which provides = ordered/unordered reliability at the
   transport-layer, for example TCP [6] or = SCTP [7].

3.2 Congestion Avoidance

   The OPES callout protocol MUST ensure = that congestion avoidance that
   matches the standard of RFC 2914 [4] is = applied on all communication
   between OPES processor and callout = server.  For this purpose, the
   callout protocol SHOULD use a = congestion-controlled transport-layer
   protocol, presumably either TCP [6] or = SCTP [7].


IMO, callout protocol has sufficiently different = purpose to deserve its own transport binding, which MAY be the same as = application transport for some applications, but does not have to be. = This approach would let us support adaptation of application protocols = that do not satisfy OPES transport requirements.

Thank you,

Alex.

> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Tuesday, March 11, 2003 1:31 PM
> To: OPES Group
> Subject: RE: Draft Agenda for IETF 56
>
>
>
> On Tue, 11 Mar 2003, Reinaldo Penno = wrote:
>
> > If I remember correctly the decision = reached some time ago during a
> > conference call was that the callout = transport protocol would be the
> > same one used between user<----...OPES = box....--->consumer
>
> Reinaldo,
>
>       I am confused: = Callout protocol is the one OPES dispatcher uses to
> talk to the callout server. Why do you have = "user", "OPES box", and
> "consumer" in your picture if you are = talking about the callout
> protocol? The callout protocol is used _inside_ = the OPES box, not
> outside it, AFAIK.
>
> Did you mean application protocol instead? If = so, would it be accurate
> to say that the conference call resulted in a = decision to prohibit
> application protocol conversion by OPES (e.g., = converting HTTP to
> FTP)?
>
> Please clarify or point to the relevant = documents. BTW, were the
> conference call minutes posted on the = list?
>
> Thank you,
>
> Alex.
>
>
> > -----Original Message-----
> > From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> > Sent: Tuesday, March 11, 2003 12:06 = PM
> > To: OPES Group
> > Subject: Re: Draft Agenda for IETF = 56
> >
> >
> >
> > On Mon, 10 Mar 2003, jfcm wrote:
> >
> > > My main question is about the entry = and the ending points of the
> > > OPES concept. If it is accepted that = not only HTTP but any
> > > protocol is OK, and that = alternatively both end points can be
> > > user/producer or that we may have a = peer to peer support, it will
> > > mean that any entry/output protocol = is OK, including a
> > > keyboard/user file/application etc, = towards a screen, a file, etc.
> > >
> > > This means there is no = pseudo-synchoronous (like in hhtp)
> > > obligation (or as options). This = means that we have a general
> > > purpose concept of a = filter/transformer system on a flow. Which
> > > will standardize everywhere.
> > >
> > > This means that, the = filter/transformer relation (callout
> > > protocol) can be anything from = realtime to soap. Am I correct?
> >
> > I doubt we can design a good OPES system = that can support adaptation
> > of anything from highly optimized realtime = protocols to
> > structure-rich, super extensible XML = protocols. There will be
> > tradeoffs that we will have to resolve one = way or the other. That is
> > why it is important to agree on scope and = use cases up-front.
> >
> > > Because this means that we will have = a good general framework for
> > > a protected/acked balanced protocol = able to support one to many or
> > > even many to many relations.
> >
> > We should strive for that, but IMO we will = come short as things get
> > more specific.
> >
> > > Then the next question will be: will = it always be under TCP?
> >
> > Transport protocol binding wise, TCP is = probably not the only
> > option. We do need a reliable, = order-preserving, congestion-aware
> > protocol though (see protocol requirements = draft for details). These
> > features may already exclude certain = realtime optimizations where
> > losing packets is not only acceptable but = desirable in the presence
> > of unexpected delays or congestion.
> >
> > An important design question is whether = the OPES protocol should
> > allow multiple transport = bindings/encodings or just one.
> >
> > Alex.
> >
>

------_=_NextPart_001_01C2E807.0E6466D2-- From owner-ietf-openproxy@mail.imc.org Tue Mar 11 15:14: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 PAA09983 for ; Tue, 11 Mar 2003 15:14:21 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BJkmK02723 for ietf-openproxy-bks; Tue, 11 Mar 2003 11:46:48 -0800 (PST) Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BJkl302719 for ; Tue, 11 Mar 2003 11:46:47 -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.8/8.12.8) with ESMTP id h2BJkkN5093486; Tue, 11 Mar 2003 14:46:47 -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 h2BJkeIL058244; Tue, 11 Mar 2003 14:46:40 -0500 (EST) Received: from bell-labs.com ([135.180.160.178]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id OAA09751; Tue, 11 Mar 2003 14:46:40 -0500 (EST) Message-ID: <3E6E3CE9.9060601@bell-labs.com> Date: Tue, 11 Mar 2003 14:45:45 -0500 From: Andre Beck User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Reinaldo Penno CC: "'Alex Rousskov'" , OPES Group Subject: Re: Draft Agenda for IETF 56 References: <0A11633F61BD9F40B43ABCC694004F93F18E1C@zsc3c026.us.nortel.com> In-Reply-To: <0A11633F61BD9F40B43ABCC694004F93F18E1C@zsc3c026.us.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 I believe the consensus at the conference call was that we do away with the transport protocol negotiation mechanism and instead suggest that the callout transport protocol be selected based on the application protocol used between data consumer and provider. This does not mean, however, that the callout protocol and application protocol have to use the same transport protocol. Section 3.12: "The callout protocol MUST NOT negotiate the transport protocol to be used for callout connections. The callout protocol MAY, however, specify that a certain application message protocol (e.g. HTTP [5], RTP [8]) requires the use of a certain transport protocol (e.g. TCP [6], SCTP [7])." Reinaldo Penno wrote: > I guess an example is better... > > If you are running a media session with a friend, let's say RTP over > UDP, and the opes dispatcher (between you two) decides that this media > needs adaptaion because you are on a cell phone. > > In this case the callout protocol should (may?) run over UDP. This is a > simple effort in order to guess the best transport protocol to use in > the callout protocol for this specific session. > > Is this clearer? > > Ps: OPES box meant just a device running the dispatcher. The callout > server is not included in the box. > > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Tuesday, March 11, 2003 1:31 PM > To: OPES Group > Subject: RE: Draft Agenda for IETF 56 > > > > On Tue, 11 Mar 2003, Reinaldo Penno wrote: > > > If I remember correctly the decision reached some time ago during a > > conference call was that the callout transport protocol would be the > > same one used between user<----...OPES box....--->consumer > > Reinaldo, > > I am confused: Callout protocol is the one OPES dispatcher uses > to talk to the callout server. Why do you have "user", "OPES box", and > "consumer" in your picture if you are talking about the callout > protocol? The callout protocol is used _inside_ the OPES box, not > outside it, AFAIK. > > Did you mean application protocol instead? If so, would it be accurate > to say that the conference call resulted in a decision to prohibit > application protocol conversion by OPES (e.g., converting HTTP to FTP)? > > Please clarify or point to the relevant documents. BTW, were the > conference call minutes posted on the list? > > Thank you, > > Alex. > > > > -----Original Message----- > > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > > Sent: Tuesday, March 11, 2003 12:06 PM > > To: OPES Group > > Subject: Re: Draft Agenda for IETF 56 > > > > > > > > On Mon, 10 Mar 2003, jfcm wrote: > > > > > My main question is about the entry and the ending points of the > > > OPES concept. If it is accepted that not only HTTP but any protocol > > > is OK, and that alternatively both end points can be user/producer > > > or that we may have a peer to peer support, it will mean that any > > > entry/output protocol is OK, including a keyboard/user > > > file/application etc, towards a screen, a file, etc. > > > > > > This means there is no pseudo-synchoronous (like in hhtp) obligation > > > (or as options). This means that we have a general purpose concept > > > of a filter/transformer system on a flow. Which will standardize > > > everywhere. > > > > > > This means that, the filter/transformer relation (callout protocol) > > > can be anything from realtime to soap. Am I correct? > > > > I doubt we can design a good OPES system that can support adaptation > > of anything from highly optimized realtime protocols to > > structure-rich, super extensible XML protocols. There will be > > tradeoffs that we will have to resolve one way or the other. That is > > why it is important to agree on scope and use cases up-front. > > > > > Because this means that we will have a good general framework for a > > > protected/acked balanced protocol able to support one to many or > > > even many to many relations. > > > > We should strive for that, but IMO we will come short as things get > > more specific. > > > > > Then the next question will be: will it always be under TCP? > > > > Transport protocol binding wise, TCP is probably not the only option. > > We do need a reliable, order-preserving, congestion-aware protocol > > though (see protocol requirements draft for details). These features > > may already exclude certain realtime optimizations where losing > > packets is not only acceptable but desirable in the presence of > > unexpected delays or congestion. > > > > An important design question is whether the OPES protocol should allow > > multiple transport bindings/encodings or just one. > > > > Alex. > > > From owner-ietf-openproxy@mail.imc.org Tue Mar 11 15:32: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 PAA11032 for ; Tue, 11 Mar 2003 15:32:13 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BK5Uk03769 for ietf-openproxy-bks; Tue, 11 Mar 2003 12:05:30 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BK5T303764 for ; Tue, 11 Mar 2003 12:05:29 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h2BK5Vnx029948 for ; Tue, 11 Mar 2003 13:05:31 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h2BK5VLL029947; Tue, 11 Mar 2003 13:05:31 -0700 (MST) (envelope-from rousskov) Date: Tue, 11 Mar 2003 13:05:31 -0700 (MST) From: Alex Rousskov To: OPES Group Subject: Re: Draft Agenda for IETF 56 In-Reply-To: <0A11633F61BD9F40B43ABCC694004F93F18E1F@zsc3c026.us.nortel.com> Message-ID: References: <0A11633F61BD9F40B43ABCC694004F93F18E1F@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 Tue, 11 Mar 2003, Andre Beck wrote: > I believe the consensus at the conference call was that we do away > with the transport protocol negotiation mechanism and instead > suggest that the callout transport protocol be selected based on the > application protocol used between data consumer and provider. Great! That's what I would vote for as well. > Section 3.12: > > "The callout protocol MUST NOT negotiate the transport protocol to be > used for callout connections. The callout protocol MAY, however, > specify that a certain application message protocol (e.g. HTTP [5], > RTP [8]) requires the use of a certain transport protocol (e.g. TCP > [6], SCTP [7])." Sorry for missing that paragraph. > On Tue, 11 Mar 2003, Reinaldo Penno wrote: > > Yes, I understand the current requirements, but since HTTP is the > protocol in-scope at the moment and there is a push in the IETF (the > chairs/ADs can correct me if I'm wrong) to use congestion aware > protocols, we thought using SCTP might be a good compromise for > those that think TCP is not appropiate. > > We had the same debate in another WG that is chossing an transport > protocol and although some people wanted UDP the AD said the > protocol must be congestion aware. Anyway, we can revisit this issue > if people think it does not cater to the needs of OPES deployments. I suspect that for many OPES applications it would be perfectly fine to use TCP for the callout protocol while the application protocol is using something like UDP. Most OPES transformations are per application message (e.g., a UDP packet) so we should be fine as long as the callout protocol includes appropriate per-application-message timeout mechanisms. The predraft documents already contains some wording in that direction. If Reinaldo agrees with Andre's recollection of the conference call, then there seems to be no conflict regarding support for non-TCP application transport. This mini-thread started when jfc asked whether OPES transport must be TCP, and I think my initial response remains valid. Alex. > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Tuesday, March 11, 2003 2:16 PM > To: OPES Group > Subject: RE: Draft Agenda for IETF 56 > > > > On Tue, 11 Mar 2003, Reinaldo Penno wrote: > > > If you are running a media session with a friend, let's say RTP over > > UDP, and the opes dispatcher (between you two) decides that this media > > needs adaptaion because you are on a cell phone. > > > > In this case the callout protocol should (may?) run over UDP. This is > > a simple effort in order to guess the best transport protocol to use > > in the callout protocol for this specific session. > > > > Is this clearer? > > Yes, thank you! You are saying that both application protocol and callout > protocol should (may?) use the same transport protocol, right? > > This means that either we cannot support application protocols that use UDP > (and other lossy/etc protocols), or we will be violating current callout > protocol requirements (that demand reliable congestion-aware transport): > > 3.1 Reliability > > The OPES callout protocol MUST be able to provide ordered reliability > for the communication between OPES processor and callout server. > Additionally, the callout protocol SHOULD be able to provide > unordered reliability. > > In order to satisfy the reliability requirements, the callout > protocol SHOULD specify that it must be used with a transport > protocol which provides ordered/unordered reliability at the > transport-layer, for example TCP [6] or SCTP [7]. > > 3.2 Congestion Avoidance > > The OPES callout protocol MUST ensure that congestion avoidance that > matches the standard of RFC 2914 [4] is applied on all communication > between OPES processor and callout server. For this purpose, the > callout protocol SHOULD use a congestion-controlled transport-layer > protocol, presumably either TCP [6] or SCTP [7]. > > > IMO, callout protocol has sufficiently different purpose to deserve its own > transport binding, which MAY be the same as application transport for some > applications, but does not have to be. This approach would let us support > adaptation of application protocols that do not satisfy OPES transport > requirements. > > Thank you, > > Alex. > > > -----Original Message----- > > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > > Sent: Tuesday, March 11, 2003 1:31 PM > > To: OPES Group > > Subject: RE: Draft Agenda for IETF 56 > > > > > > > > On Tue, 11 Mar 2003, Reinaldo Penno wrote: > > > > > If I remember correctly the decision reached some time ago during a > > > conference call was that the callout transport protocol would be the > > > same one used between user<----...OPES box....--->consumer > > > > Reinaldo, > > > > I am confused: Callout protocol is the one OPES dispatcher uses to > > talk to the callout server. Why do you have "user", "OPES box", and > > "consumer" in your picture if you are talking about the callout > > protocol? The callout protocol is used _inside_ the OPES box, not > > outside it, AFAIK. > > > > Did you mean application protocol instead? If so, would it be accurate > > to say that the conference call resulted in a decision to prohibit > > application protocol conversion by OPES (e.g., converting HTTP to > > FTP)? > > > > Please clarify or point to the relevant documents. BTW, were the > > conference call minutes posted on the list? > > > > Thank you, > > > > Alex. > > > > > > > -----Original Message----- > > > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > > > Sent: Tuesday, March 11, 2003 12:06 PM > > > To: OPES Group > > > Subject: Re: Draft Agenda for IETF 56 > > > > > > > > > > > > On Mon, 10 Mar 2003, jfcm wrote: > > > > > > > My main question is about the entry and the ending points of the > > > > OPES concept. If it is accepted that not only HTTP but any > > > > protocol is OK, and that alternatively both end points can be > > > > user/producer or that we may have a peer to peer support, it will > > > > mean that any entry/output protocol is OK, including a > > > > keyboard/user file/application etc, towards a screen, a file, etc. > > > > > > > > This means there is no pseudo-synchoronous (like in hhtp) > > > > obligation (or as options). This means that we have a general > > > > purpose concept of a filter/transformer system on a flow. Which > > > > will standardize everywhere. > > > > > > > > This means that, the filter/transformer relation (callout > > > > protocol) can be anything from realtime to soap. Am I correct? > > > > > > I doubt we can design a good OPES system that can support adaptation > > > of anything from highly optimized realtime protocols to > > > structure-rich, super extensible XML protocols. There will be > > > tradeoffs that we will have to resolve one way or the other. That is > > > why it is important to agree on scope and use cases up-front. > > > > > > > Because this means that we will have a good general framework for > > > > a protected/acked balanced protocol able to support one to many or > > > > even many to many relations. > > > > > > We should strive for that, but IMO we will come short as things get > > > more specific. > > > > > > > Then the next question will be: will it always be under TCP? > > > > > > Transport protocol binding wise, TCP is probably not the only > > > option. We do need a reliable, order-preserving, congestion-aware > > > protocol though (see protocol requirements draft for details). These > > > features may already exclude certain realtime optimizations where > > > losing packets is not only acceptable but desirable in the presence > > > of unexpected delays or congestion. > > > > > > An important design question is whether the OPES protocol should > > > allow multiple transport bindings/encodings or just one. > > > > > > Alex. > > > > > > From owner-ietf-openproxy@mail.imc.org Tue Mar 11 23:42: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 XAA25873 for ; Tue, 11 Mar 2003 23:42:42 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2C4MQ125212 for ietf-openproxy-bks; Tue, 11 Mar 2003 20:22:26 -0800 (PST) Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2C4MJ325206 for ; Tue, 11 Mar 2003 20:22:20 -0800 (PST) Received: from mhof.com ([135.104.20.69]) by mtaout07.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPA id <0HBM00H0OC54LA@mtaout07.icomcast.net> for ietf-openproxy@imc.org; Tue, 11 Mar 2003 23:22:18 -0500 (EST) Date: Tue, 11 Mar 2003 23:22:16 -0500 From: Markus Hofmann Subject: Re: Draft Agenda for IETF 56 In-reply-to: Cc: OPES Group Message-id: <3E6EB5F8.9010805@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.3b) Gecko/20030210 References: <0A11633F61BD9F40B43ABCC694004F93F18E1F@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: > If Reinaldo agrees with Andre's recollection of the conference call, > then there seems to be no conflict regarding support for non-TCP > application transport. This mini-thread started when jfc asked whether > OPES transport must be TCP, and I think my initial response remains > valid. I can fully second Andre's recollection. During a call of the "protocol requirements" sub-team, the author team agreed that (a) the callout protocol MUST NOT negotiate the transport protocol to be used for callout connections, (b) the callout protocol MAY, specify that a certain application message protocol (e.g. HTTP, RTP) requires the use of a certain transport protocol (e.g. TCP, SCTP). This is fully documented in Section 3.12 of the protocol requirements draft. Key point is that we do *not* have a transport protocol negotiation mechanism in the OPES protocol. However, we're also *not* restricted to a single transport protocol to be used for all purposes. Point (b) above specifies that the transport protocol to be used for the callout may depend on the application message protocol used between producer and consumer (e.g. HTTP). Note, however, that this is different from chosing the transport protocol for the callout based on the application itself... General question now is whethr we feel that coupling the transport protocol for the callout to the application message protocol is flexible enough, or whether we need more flexibility? For example, is it OK to assume that whenever the application message protocol is A, that the transport protocol for the callout is B. Or is there a case to make that for the same message protocol A, we sometimes need to use transport protocol B for the callout, and sometimes transport protocol C (substitute A, B, and C with your favorite protocols :) If so, how is this achieved without protocol negotiation? -Markus From owner-ietf-openproxy@mail.imc.org Wed Mar 12 00:06: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 AAA26378 for ; Wed, 12 Mar 2003 00:06:22 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2C4hl225670 for ietf-openproxy-bks; Tue, 11 Mar 2003 20:43:47 -0800 (PST) Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2C4hj325666 for ; Tue, 11 Mar 2003 20:43:46 -0800 (PST) Received: from mhof.com ([135.104.20.69]) by mtaout03.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPA id <0HBM001FUD4WRA@mtaout03.icomcast.net> for ietf-openproxy@imc.org; Tue, 11 Mar 2003 23:43:44 -0500 (EST) Date: Tue, 11 Mar 2003 23:43:44 -0500 From: Markus Hofmann Subject: Agenda for OPES at IETF 56 To: OPES Group Message-id: <3E6EBB00.7090902@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.3b) Gecko/20030210 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Folks, attached the agenda for our OPES meeting in San Franciso. Should be pretty stable by now. Cheers, Markus ----------------------------------------------------- Open Pluggable Edge Services WG (opes) ====================================== Monday, March 17, 1530-1730 CHAIR(S): Marshall Rose Markus Hofmann TECHNICAL ADVISOR(S): Allison Mankin Hilarie Orman AGENDA: - Introduction, minutes taker, blue sheets [2 min] - Agenda bashing [3 min] - Status of WG documents [M. Hofmann, 10 min] draft-ietf-opes-architecture-04 draft-ietf-opes-protocol-reqs-03 draft-ietf-opes-scenarios-01 draft-ietf-opes-authorization-02 draft-ietf-opes-threats-02 - Start on OPES protocol work - Introduction to protocol work [M. Hofmann, 10 min] - Protocol layering and the OPES callout protocol [H. Orman, 15 min] - OPES scope clarifications [A. Barbier, 20 min] - Major decision points for protocol design [A. Rousskov, 15 min] - OPES protocol pre-draft thoughts [A. Rousskov, 30 min] - General discussion - Thoughts on using SOAP/XML [A. Barbier, 10 min] From owner-ietf-openproxy@mail.imc.org Wed Mar 12 00:49: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 AAA27286 for ; Wed, 12 Mar 2003 00:49:38 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2C5NoP26668 for ietf-openproxy-bks; Tue, 11 Mar 2003 21:23:50 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2C5Nm326662 for ; Tue, 11 Mar 2003 21:23:48 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h2C5Nqnx042859 for ; Tue, 11 Mar 2003 22:23:52 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h2C5NqfR042858; Tue, 11 Mar 2003 22:23:52 -0700 (MST) (envelope-from rousskov) Date: Tue, 11 Mar 2003 22:23:52 -0700 (MST) From: Alex Rousskov To: OPES Group Subject: Re: Draft Agenda for IETF 56 In-Reply-To: <3E6EB5F8.9010805@mhof.com> Message-ID: References: <0A11633F61BD9F40B43ABCC694004F93F18E1F@zsc3c026.us.nortel.com> <3E6EB5F8.9010805@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, 11 Mar 2003, Markus Hofmann wrote: > General question now is whethr we feel that coupling the transport > protocol for the callout to the application message protocol is > flexible enough, or whether we need more flexibility? > > For example, is it OK to assume that whenever the application > message protocol is A, that the transport protocol for the callout > is B. Or is there a case to make that for the same message protocol > A, we sometimes need to use transport protocol B for the callout, > and sometimes transport protocol C (substitute A, B, and C with your > favorite protocols :) If so, how is this achieved without protocol > negotiation? I was not on that conference call so I may be missing some important caveats. Said that, it seems to me that we should not care about the ways transport protocols are selected as long as we do not have to support true negotiations. In most cases, protocol selection can be handled by static configurations (with rules if needed), and should be out of our current scope. No need to limit the selection/matching rules; just prohibit in-protocol negotiations. Let implementations decide what is the right protocol selection method is. $0.02, Alex. From owner-ietf-openproxy@mail.imc.org Wed Mar 12 06:20: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 GAA00091 for ; Wed, 12 Mar 2003 06:20:14 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CAs5p29263 for ietf-openproxy-bks; Wed, 12 Mar 2003 02:54:05 -0800 (PST) Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CAs4329257 for ; Wed, 12 Mar 2003 02:54:04 -0800 (PST) Received: from f04v-1-17.d1.club-internet.fr ([212.194.60.17] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 18t3s0-0005b9-00 for ietf-openproxy@imc.org; Wed, 12 Mar 2003 02:54:01 -0800 Message-Id: <5.2.0.9.0.20030312113807.03480c70@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 12 Mar 2003 11:39:46 +0100 To: OPES Group From: jfcm Subject: Re: Draft Agenda for IETF 56 In-Reply-To: References: <3E6EB5F8.9010805@mhof.com> <0A11633F61BD9F40B43ABCC694004F93F18E1F@zsc3c026.us.nortel.com> <3E6EB5F8.9010805@mhof.com> Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-74CD57CC; boundary="=======1B496501=======" 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: --=======1B496501======= Content-Type: text/plain; x-avg-checked=avg-ok-74CD57CC; charset=us-ascii; format=flowed Content-Transfer-Encoding: 8bit Is there a site dedicated to a good SCTP comprehensive presentation/tutorial to learn it quick? thx.jfc --=======1B496501======= Content-Type: text/plain; charset=us-ascii; x-avg=cert; x-avg-checked=avg-ok-74CD57CC Content-Disposition: inline --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.459 / Virus Database: 258 - Release Date: 25/02/03 --=======1B496501=======-- From owner-ietf-openproxy@mail.imc.org Wed Mar 12 07: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 HAA01107 for ; Wed, 12 Mar 2003 07:02:49 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CBe7w04002 for ietf-openproxy-bks; Wed, 12 Mar 2003 03:40:07 -0800 (PST) Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CBe6303998 for ; Wed, 12 Mar 2003 03:40:06 -0800 (PST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CBdrO14214; Wed, 12 Mar 2003 06:39:53 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Mar 2003 06:39:53 -0500 Message-ID: <87609AFB433BD5118D5E0002A52CD754051EC587@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Alex Rousskov , OPES Group Subject: RE: Draft Agenda for IETF 56 Date: Wed, 12 Mar 2003 06:39:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E88C.182DA90A" 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_01C2E88C.182DA90A Content-Type: text/plain Hi all, This discussions are really getting interesting. However, it seems to be that we should fundemantely agree on the deployment (where, what and for what) of OPES in the services area. The discussions give me the feeling that we are trying to design a (very flexible) system that is looking for a place in the field. I could see the benefits to have various bindings for the callout protocol. It gives felexibility. But at what expense? I really have problems developing an architecture/protocols that can go all over the field. The architecture document states that the example protocol is HTTP. I know that we should be open minded in the design of the callout protocol. However, I would like to start with HTTP and then come up with a callout protocol that can work with it. After that, I would like to see how we address all of the IAB issues regarding OPES. We can then move the excerise to RTP (SRTP etc..), and use that knowledge to ensure that we have a flexible protocol. At this point, the issues of notification/tracing have not been brought up (yet?). Abbie > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Wednesday, March 12, 2003 12:24 AM > To: OPES Group > Subject: Re: Draft Agenda for IETF 56 > > > > > On Tue, 11 Mar 2003, Markus Hofmann wrote: > > > General question now is whethr we feel that coupling the transport > > protocol for the callout to the application message protocol is > > flexible enough, or whether we need more flexibility? > > > > For example, is it OK to assume that whenever the > application message > > protocol is A, that the transport protocol for the callout > is B. Or is > > there a case to make that for the same message protocol A, we > > sometimes need to use transport protocol B for the callout, and > > sometimes transport protocol C (substitute A, B, and C with your > > favorite protocols :) If so, how is this achieved without protocol > > negotiation? > > I was not on that conference call so I may be missing some > important caveats. Said that, it seems to me that we should > not care about the ways transport protocols are selected as > long as we do not have to support true negotiations. In most > cases, protocol selection can be handled by static > configurations (with rules if needed), and should be out of > our current scope. > > No need to limit the selection/matching rules; just prohibit > in-protocol negotiations. Let implementations decide what is > the right protocol selection method is. > > $0.02, > > Alex. > ------_=_NextPart_001_01C2E88C.182DA90A Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Draft Agenda for IETF 56

Hi all,

This discussions are really getting = interesting.

However, it seems to be that we should fundemantely = agree on the deployment (where, what and for what) of OPES in the = services area.

The discussions give me the feeling that we are = trying to design a (very flexible) system that is looking for a place = in the field.

I could see the benefits to have various bindings for = the callout protocol. It gives felexibility. But at what expense? I = really have problems developing an architecture/protocols that can go = all over the field.

The architecture document states that the example = protocol is HTTP. I know that we should be open minded in the design of = the callout protocol.

However, I would like to start with HTTP and then = come up with a callout protocol that can work with it. After that, I = would like to see how we address all of the IAB issues regarding OPES. = We can then move the excerise to RTP (SRTP etc..), and use that = knowledge to ensure that we have a flexible protocol.

At this point, the issues of notification/tracing = have not been brought up (yet?).


Abbie

> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Wednesday, March 12, 2003 12:24 AM
> To: OPES Group
> Subject: Re: Draft Agenda for IETF 56
>
>
>
>
> On Tue, 11 Mar 2003, Markus Hofmann = wrote:
>
> > General question now is whethr we feel = that coupling the transport
> > protocol for the callout to the = application message protocol is
> > flexible enough, or whether we need more = flexibility?
> >
> > For example, is it OK to assume that = whenever the
> application message
> > protocol is A, that the transport protocol = for the callout
> is B. Or is
> > there a case to make that for the same = message protocol A, we
> > sometimes need to use transport protocol B = for the callout, and
> > sometimes transport protocol C (substitute = A, B, and C with your
> > favorite protocols :) If so, how is this = achieved without protocol
> > negotiation?
>
> I was not on that conference call so I may be = missing some
> important caveats. Said that, it seems to me = that we should
> not care about the ways transport protocols are = selected as
> long as we do not have to support true = negotiations. In most
> cases, protocol selection can be handled by = static
> configurations (with rules if needed), and = should be out of
> our current scope.
>
> No need to limit the selection/matching rules; = just prohibit
> in-protocol negotiations. Let implementations = decide what is
> the right protocol selection method is.
>
> $0.02,
>
> Alex.
>

------_=_NextPart_001_01C2E88C.182DA90A-- From owner-ietf-openproxy@mail.imc.org Wed Mar 12 08:51: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 IAA03471 for ; Wed, 12 Mar 2003 08:51:23 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CDIn410478 for ietf-openproxy-bks; Wed, 12 Mar 2003 05:18:49 -0800 (PST) Received: from mail.mailsnare.net (mail.mailsnare.net [207.44.136.42]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CDIm310471 for ; Wed, 12 Mar 2003 05:18:48 -0800 (PST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by dummy.domain.name (Postfix) with SMTP id CB140464054 for ; Wed, 12 Mar 2003 13:18:43 +0000 (UTC) Received: from mhof.com (unknown [135.104.20.68]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.mailsnare.net (Postfix) with ESMTP id 2E96346404E for ; Wed, 12 Mar 2003 13:18:43 +0000 (UTC) Message-ID: <3E6F33B1.8070707@mhof.com> Date: Wed, 12 Mar 2003 08:18:41 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us MIME-Version: 1.0 To: OPES Group Subject: Re: Draft Agenda for IETF 56 References: <0A11633F61BD9F40B43ABCC694004F93F18E1F@zsc3c026.us.nortel.com> <3E6EB5F8.9010805@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 was not on that conference call so I may be missing some important > caveats. Said that, it seems to me that we should not care about the > ways transport protocols are selected as long as we do not have to > support true negotiations. In most cases, protocol selection can be > handled by static configurations (with rules if needed), and should be > out of our current scope. > > No need to limit the selection/matching rules; just prohibit > in-protocol negotiations. Let implementations decide what is the right > protocol selection method is. Yup, feeling was that dynamic transport protocol negotiation adds too much complexity and might complicate interoperability. Now, whatever method is chosen for transport protocol mapping, it still must ensure interoperability, of course. -Markus From owner-ietf-openproxy@mail.imc.org Wed Mar 12 08:53: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 IAA03504 for ; Wed, 12 Mar 2003 08:53:27 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CDSUm11317 for ietf-openproxy-bks; Wed, 12 Mar 2003 05:28:30 -0800 (PST) Received: from mail.mailsnare.net (mail.mailsnare.net [207.44.136.42]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CDST311311 for ; Wed, 12 Mar 2003 05:28:29 -0800 (PST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by dummy.domain.name (Postfix) with SMTP id 7C8C0464062 for ; Wed, 12 Mar 2003 13:28:25 +0000 (UTC) Received: from mhof.com (unknown [135.104.20.68]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.mailsnare.net (Postfix) with ESMTP id 0F765464054 for ; Wed, 12 Mar 2003 13:28:25 +0000 (UTC) Message-ID: <3E6F35F8.2080206@mhof.com> Date: Wed, 12 Mar 2003 08:28:24 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us MIME-Version: 1.0 To: OPES Group Subject: Re: Draft Agenda for IETF 56 References: <87609AFB433BD5118D5E0002A52CD754051EC587@zcard0k6.ca.nortel.com> In-Reply-To: <87609AFB433BD5118D5E0002A52CD754051EC587@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: > At this point, the issues of notification/tracing have not been brought up > (yet?). Absolutley correct and an important point!! Is there anything me must consider in the callout protocl design for tracing and notification? I would assume so... Any thoughts? While probably separate from the callout protocol design, we also need to discuss possible impact on the application message protocol, for example for an "OPES bypass" mechanism. This refers to the requirement that a user must be able to signal an OPES processor that (s)he wants to bypass any OPES service (one of the IAB requirements) - as briefly discussed some time earlier, using (user-defined?) HTTP headers might be an option.... So we also need to consider possible impact/extensions on the application message protocol. Anyone some thoughts on this one? -Markus From owner-ietf-openproxy@mail.imc.org Wed Mar 12 09:20: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 JAA04089 for ; Wed, 12 Mar 2003 09:20:35 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CDsaS15223 for ietf-openproxy-bks; Wed, 12 Mar 2003 05:54:36 -0800 (PST) Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CDsZ315217 for ; Wed, 12 Mar 2003 05:54:35 -0800 (PST) Received: from f04v-1-17.d1.club-internet.fr ([212.194.60.17] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 18t6gj-0001eG-00 for ietf-openproxy@imc.org; Wed, 12 Mar 2003 05:54:34 -0800 Message-Id: <5.2.0.9.0.20030312145033.024d9ec0@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 12 Mar 2003 15:01:11 +0100 To: ietf-openproxy@imc.org From: jfcm Subject: RE: Draft Agenda for IETF 56 In-Reply-To: <87609AFB433BD5118D5E0002A52CD754051EC587@zcard0k6.ca.norte l.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_77237041==.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: --=====================_77237041==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed This was my initial point. We are asked to build a bicycle. We see that we can also build a car. Let avoid building an Harley Davidson everyone will enjoy but no one will use. 1. let build the bicycle 2. in keeping in mind what could be reused from a car production later on, so we keep consistent. This is why I think we should do as you say: http. The real project I would propose would be a redirect system upon decision of a server (I have a real need :-). I suppose that if a few ones could have in mind a similar application, we could confront with real life examples. Then we could list every time there is a decision how it would work with other entry systems and other callout protocol transport solution. Choosing the simplest transport solution to implement (may be local interaction?) for that part, so we can test quickly and exchange code? Then may be we could check SMTP to be sure it works well in a different model? jfc On 12:39 12/03/03, Abbie Barbir said: >Hi all, > >This discussions are really getting interesting. > >However, it seems to be that we should fundemantely agree on the >deployment (where, what and for what) of OPES in the services area. > >The discussions give me the feeling that we are trying to design a (very >flexible) system that is looking for a place in the field. > >I could see the benefits to have various bindings for the callout >protocol. It gives felexibility. But at what expense? I really have >problems developing an architecture/protocols that can go all over the field. > >The architecture document states that the example protocol is HTTP. I know >that we should be open minded in the design of the callout protocol. > >However, I would like to start with HTTP and then come up with a callout >protocol that can work with it. After that, I would like to see how we >address all of the IAB issues regarding OPES. We can then move the >excerise to RTP (SRTP etc..), and use that knowledge to ensure that we >have a flexible protocol. > >At this point, the issues of notification/tracing have not been brought up >(yet?). > >Abbie > > > -----Original Message----- > > From: Alex Rousskov > [mailto:rousskov@measurement-factory.com] > > > Sent: Wednesday, March 12, 2003 12:24 AM > > To: OPES Group > > Subject: Re: Draft Agenda for IETF 56 > > > > > > > > > > On Tue, 11 Mar 2003, Markus Hofmann wrote: > > > > > General question now is whethr we feel that coupling the transport > > > protocol for the callout to the application message protocol is > > > flexible enough, or whether we need more flexibility? > > > > > > For example, is it OK to assume that whenever the > > application message > > > protocol is A, that the transport protocol for the callout > > is B. Or is > > > there a case to make that for the same message protocol A, we > > > sometimes need to use transport protocol B for the callout, and > > > sometimes transport protocol C (substitute A, B, and C with your > > > favorite protocols :) If so, how is this achieved without protocol > > > negotiation? > > > > I was not on that conference call so I may be missing some > > important caveats. Said that, it seems to me that we should > > not care about the ways transport protocols are selected as > > long as we do not have to support true negotiations. In most > > cases, protocol selection can be handled by static > > configurations (with rules if needed), and should be out of > > our current scope. > > > > No need to limit the selection/matching rules; just prohibit > > in-protocol negotiations. Let implementations decide what is > > the right protocol selection method is. > > > > $0.02, > > > > Alex. > > > >--- >Incoming mail is certified Virus Free. >Checked by AVG anti-virus system (http://www.grisoft.com). >Version: 6.0.459 / Virus Database: 258 - Release Date: 25/02/03 --=====================_77237041==.ALT Content-Type: text/html; charset="us-ascii" This was my initial point. We are asked to build a bicycle. We see that we can also build a car. Let avoid building an Harley Davidson everyone will enjoy but no one will use.

1. let build the bicycle
2. in keeping in mind what could be reused from a car production later on, so we keep consistent.

This is why I think we should do as you say: http. The real project I would propose would be a redirect system upon decision of a server (I have a real need :-). I suppose that if a few ones could have in mind a similar application, we could confront with real life examples.

Then we could list every time there is a decision how it would work with other entry systems and other callout protocol transport solution. Choosing the simplest transport solution to implement (may be local interaction?) for that part, so we can test quickly and exchange code?

Then may be we could check SMTP to be sure it works well in a different model?
jfc





On 12:39 12/03/03, Abbie Barbir said:

Hi all,

This discussions are really getting interesting.

However, it seems to be that we should fundemantely agree on the deployment (where, what and for what) of OPES in the services area.

The discussions give me the feeling that we are trying to design a (very flexible) system that is looking for a place in the field.

I could see the benefits to have various bindings for the callout protocol. It gives felexibility. But at what expense? I really have problems developing an architecture/protocols that can go all over the field.

The architecture document states that the example protocol is HTTP. I know that we should be open minded in the design of the callout protocol.

However, I would like to start with HTTP and then come up with a callout protocol that can work with it. After that, I would like to see how we address all of the IAB issues regarding OPES. We can then move the excerise to RTP (SRTP etc..), and use that knowledge to ensure that we have a flexible protocol.

At this point, the issues of notification/tracing have not been brought up (yet?).

Abbie

> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measurement-factory.com]
> Sent: Wednesday, March 12, 2003 12:24 AM
> To: OPES Group
> Subject: Re: Draft Agenda for IETF 56
>
>
>
>
> On Tue, 11 Mar 2003, Markus Hofmann wrote:
>
> > General question now is whethr we feel that coupling the transport
> > protocol for the callout to the application message protocol is
> > flexible enough, or whether we need more flexibility?
> >
> > For example, is it OK to assume that whenever the
> application message
> > protocol is A, that the transport protocol for the callout
> is B. Or is
> > there a case to make that for the same message protocol A, we
> > sometimes need to use transport protocol B for the callout, and
> > sometimes transport protocol C (substitute A, B, and C with your
> > favorite protocols :) If so, how is this achieved without protocol
> > negotiation?
>
> I was not on that conference call so I may be missing some
> important caveats. Said that, it seems to me that we should
> not care about the ways transport protocols are selected as
> long as we do not have to support true negotiations. In most
> cases, protocol selection can be handled by static
> configurations (with rules if needed), and should be out of
> our current scope.
>
> No need to limit the selection/matching rules; just prohibit
> in-protocol negotiations. Let implementations decide what is
> the right protocol selection method is.
>
> $0.02,
>
> Alex.
>

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.459 / Virus Database: 258 - Release Date: 25/02/03
--=====================_77237041==.ALT-- From owner-ietf-openproxy@mail.imc.org Wed Mar 12 09:29: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 JAA04316 for ; Wed, 12 Mar 2003 09:29:21 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CE6c915604 for ietf-openproxy-bks; Wed, 12 Mar 2003 06:06:38 -0800 (PST) Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CE6c315600 for ; Wed, 12 Mar 2003 06:06:38 -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 h2CE6Qv17221; Wed, 12 Mar 2003 09:06:27 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Mar 2003 09:06:27 -0500 Message-ID: <87609AFB433BD5118D5E0002A52CD754051EC669@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: jfcm , ietf-openproxy@imc.org Subject: RE: Draft Agenda for IETF 56 Date: Wed, 12 Mar 2003 09:06:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E8A0.923FA090" 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_01C2E8A0.923FA090 Content-Type: text/plain hi, it sounds like a plan. abbie -----Original Message----- From: jfcm [mailto:info@utel.net] Sent: Wednesday, March 12, 2003 9:01 AM To: ietf-openproxy@imc.org Subject: RE: Draft Agenda for IETF 56 This was my initial point. We are asked to build a bicycle. We see that we can also build a car. Let avoid building an Harley Davidson everyone will enjoy but no one will use. 1. let build the bicycle 2. in keeping in mind what could be reused from a car production later on, so we keep consistent. This is why I think we should do as you say: http. The real project I would propose would be a redirect system upon decision of a server (I have a real need :-). I suppose that if a few ones could have in mind a similar application, we could confront with real life examples. Then we could list every time there is a decision how it would work with other entry systems and other callout protocol transport solution. Choosing the simplest transport solution to implement (may be local interaction?) for that part, so we can test quickly and exchange code? Then may be we could check SMTP to be sure it works well in a different model? jfc On 12:39 12/03/03, Abbie Barbir said: Hi all, This discussions are really getting interesting. However, it seems to be that we should fundemantely agree on the deployment (where, what and for what) of OPES in the services area. The discussions give me the feeling that we are trying to design a (very flexible) system that is looking for a place in the field. I could see the benefits to have various bindings for the callout protocol. It gives felexibility. But at what expense? I really have problems developing an architecture/protocols that can go all over the field. The architecture document states that the example protocol is HTTP. I know that we should be open minded in the design of the callout protocol. However, I would like to start with HTTP and then come up with a callout protocol that can work with it. After that, I would like to see how we address all of the IAB issues regarding OPES. We can then move the excerise to RTP (SRTP etc..), and use that knowledge to ensure that we have a flexible protocol. At this point, the issues of notification/tracing have not been brought up (yet?). Abbie > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com ] > Sent: Wednesday, March 12, 2003 12:24 AM > To: OPES Group > Subject: Re: Draft Agenda for IETF 56 > > > > > On Tue, 11 Mar 2003, Markus Hofmann wrote: > > > General question now is whethr we feel that coupling the transport > > protocol for the callout to the application message protocol is > > flexible enough, or whether we need more flexibility? > > > > For example, is it OK to assume that whenever the > application message > > protocol is A, that the transport protocol for the callout > is B. Or is > > there a case to make that for the same message protocol A, we > > sometimes need to use transport protocol B for the callout, and > > sometimes transport protocol C (substitute A, B, and C with your > > favorite protocols :) If so, how is this achieved without protocol > > negotiation? > > I was not on that conference call so I may be missing some > important caveats. Said that, it seems to me that we should > not care about the ways transport protocols are selected as > long as we do not have to support true negotiations. In most > cases, protocol selection can be handled by static > configurations (with rules if needed), and should be out of > our current scope. > > No need to limit the selection/matching rules; just prohibit > in-protocol negotiations. Let implementations decide what is > the right protocol selection method is. > > $0.02, > > Alex. > --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com ). Version: 6.0.459 / Virus Database: 258 - Release Date: 25/02/03 ------_=_NextPart_001_01C2E8A0.923FA090 Content-Type: text/html Message
hi,
 
it sounds like a plan.
 
abbie
 
-----Original Message-----
From: jfcm [mailto:info@utel.net]
Sent: Wednesday, March 12, 2003 9:01 AM
To: ietf-openproxy@imc.org
Subject: RE: Draft Agenda for IETF 56

This was my initial point. We are asked to build a bicycle. We see that we can also build a car. Let avoid building an Harley Davidson everyone will enjoy but no one will use.

1. let build the bicycle
2. in keeping in mind what could be reused from a car production later on, so we keep consistent.

This is why I think we should do as you say: http. The real project I would propose would be a redirect system upon decision of a server (I have a real need :-). I suppose that if a few ones could have in mind a similar application, we could confront with real life examples.

Then we could list every time there is a decision how it would work with other entry systems and other callout protocol transport solution. Choosing the simplest transport solution to implement (may be local interaction?) for that part, so we can test quickly and exchange code?

Then may be we could check SMTP to be sure it works well in a different model?
jfc





On 12:39 12/03/03, Abbie Barbir said:

Hi all,

This discussions are really getting interesting.

However, it seems to be that we should fundemantely agree on the deployment (where, what and for what) of OPES in the services area.

The discussions give me the feeling that we are trying to design a (very flexible) system that is looking for a place in the field.

I could see the benefits to have various bindings for the callout protocol. It gives felexibility. But at what expense? I really have problems developing an architecture/protocols that can go all over the field.

The architecture document states that the example protocol is HTTP. I know that we should be open minded in the design of the callout protocol.

However, I would like to start with HTTP and then come up with a callout protocol that can work with it. After that, I would like to see how we address all of the IAB issues regarding OPES. We can then move the excerise to RTP (SRTP etc..), and use that knowledge to ensure that we have a flexible protocol.

At this point, the issues of notification/tracing have not been brought up (yet?).

Abbie

> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measurement-factory.com]
> Sent: Wednesday, March 12, 2003 12:24 AM
> To: OPES Group
> Subject: Re: Draft Agenda for IETF 56
>
>
>
>
> On Tue, 11 Mar 2003, Markus Hofmann wrote:
>
> > General question now is whethr we feel that coupling the transport
> > protocol for the callout to the application message protocol is
> > flexible enough, or whether we need more flexibility?
> >
> > For example, is it OK to assume that whenever the
> application message
> > protocol is A, that the transport protocol for the callout
> is B. Or is
> > there a case to make that for the same message protocol A, we
> > sometimes need to use transport protocol B for the callout, and
> > sometimes transport protocol C (substitute A, B, and C with your
> > favorite protocols :) If so, how is this achieved without protocol
> > negotiation?
>
> I was not on that conference call so I may be missing some
> important caveats. Said that, it seems to me that we should
> not care about the ways transport protocols are selected as
> long as we do not have to support true negotiations. In most
> cases, protocol selection can be handled by static
> configurations (with rules if needed), and should be out of
> our current scope.
>
> No need to limit the selection/matching rules; just prohibit
> in-protocol negotiations. Let implementations decide what is
> the right protocol selection method is.
>
> $0.02,
>
> Alex.
>

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.459 / Virus Database: 258 - Release Date: 25/02/03
------_=_NextPart_001_01C2E8A0.923FA090-- From owner-ietf-openproxy@mail.imc.org Wed Mar 12 09:30: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 JAA04351 for ; Wed, 12 Mar 2003 09:30:43 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CE5j815589 for ietf-openproxy-bks; Wed, 12 Mar 2003 06:05:45 -0800 (PST) Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CE5i315585 for ; Wed, 12 Mar 2003 06:05:44 -0800 (PST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CE5ZO26063; Wed, 12 Mar 2003 09:05:36 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Mar 2003 09:05:34 -0500 Message-ID: <87609AFB433BD5118D5E0002A52CD754051EC666@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Markus Hofmann , OPES Group Subject: RE: Draft Agenda for IETF 56 Date: Wed, 12 Mar 2003 09:05:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E8A0.72E8D78E" 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_01C2E8A0.72E8D78E Content-Type: text/plain Markus, it all do with HTTP extension etc. I will detail later, abbie > -----Original Message----- > From: Markus Hofmann [mailto:markus@mhof.com] > Sent: Wednesday, March 12, 2003 8:28 AM > To: OPES Group > Subject: Re: Draft Agenda for IETF 56 > > > > Abbie Barbir wrote: > > > At this point, the issues of notification/tracing have not been > > brought up (yet?). > > Absolutley correct and an important point!! Is there anything me must > consider in the callout protocl design for tracing and > notification? I > would assume so... Any thoughts? > > While probably separate from the callout protocol design, we > also need > to discuss possible impact on the application message protocol, for > example for an "OPES bypass" mechanism. This refers to the > requirement > that a user must be able to signal an OPES processor that (s)he wants > to bypass any OPES service (one of the IAB requirements) - > as briefly > discussed some time earlier, using (user-defined?) HTTP headers might > be an option.... So we also need to consider possible > impact/extensions on the application message protocol. Anyone some > thoughts on this one? > > -Markus > > > ------_=_NextPart_001_01C2E8A0.72E8D78E Content-Type: text/html RE: Draft Agenda for IETF 56

Markus,

it all do with HTTP extension etc.
I will detail later,

abbie


> -----Original Message-----
> From: Markus Hofmann [mailto:markus@mhof.com]
> Sent: Wednesday, March 12, 2003 8:28 AM
> To: OPES Group
> Subject: Re: Draft Agenda for IETF 56
>
>
>
> Abbie Barbir wrote:
>
> > At this point, the issues of notification/tracing have not been
> > brought up (yet?).
>
> Absolutley correct and an important point!! Is there anything me must
> consider in the callout protocl design for tracing and
> notification? I
> would assume so... Any thoughts?
>
> While probably separate from the callout protocol design, we
> also need
> to discuss possible impact on the application message protocol, for
> example for an "OPES bypass" mechanism. This refers to the
> requirement
> that a user must be able to signal an OPES processor that (s)he wants
> to bypass any OPES service (one of the IAB requirements)  -
> as briefly
> discussed some time earlier, using (user-defined?) HTTP headers might
> be an option.... So we also need to consider possible
> impact/extensions on the application message protocol. Anyone some
> thoughts on this one?
>
> -Markus
>
>
>

------_=_NextPart_001_01C2E8A0.72E8D78E-- From owner-ietf-openproxy@mail.imc.org Wed Mar 12 10:49:58 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 KAA08881 for ; Wed, 12 Mar 2003 10:49:56 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CFJKZ18440 for ietf-openproxy-bks; Wed, 12 Mar 2003 07:19:20 -0800 (PST) Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CFJJ318436 for ; Wed, 12 Mar 2003 07:19:19 -0800 (PST) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CFJCP28819; Wed, 12 Mar 2003 07:19:12 -0800 (PST) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1LW2VKXP>; Wed, 12 Mar 2003 07:18:57 -0800 Message-ID: <0A11633F61BD9F40B43ABCC694004F93F18E26@zsc3c026.us.nortel.com> From: "Reinaldo Penno" To: "Abbie Barbir" , Markus Hofmann , OPES Group Subject: RE: Draft Agenda for IETF 56 Date: Wed, 12 Mar 2003 07:18:56 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E8AA.B2AAEECA" 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_01C2E8AA.B2AAEECA Content-Type: text/plain Hello Abbie, I guess there are two approaches here: 1) Making extensions for every single application protocol that might use OPES. ...Although some people that in realitly we will have maybe 4 (HTTP, RTP, SMTP, FTP). 2) Developing an out of band protocol to signal such preferences. That's why I said in the past looking at NSIS could be interesting if we feel the list in 1) is already big/complicated enough or might grow. There is also the practical uses of either approaches. Certainly, negotiating with the OPES processor what will/not receive treatment every single HTTP session could add a lot of overhead. Although HTTP could be used to negotiate, I guess we should have provisions to say "bypass OPES for all HTTP sessions, until I say otherwise", or vice-versa. Regards, Reinaldo -----Original Message----- From: Barbir, Abbie [CAR:1A00:EXCH] Sent: Wednesday, March 12, 2003 9:06 AM To: Markus Hofmann; OPES Group Subject: RE: Draft Agenda for IETF 56 Markus, it all do with HTTP extension etc. I will detail later, abbie > -----Original Message----- > From: Markus Hofmann [mailto:markus@mhof.com] > Sent: Wednesday, March 12, 2003 8:28 AM > To: OPES Group > Subject: Re: Draft Agenda for IETF 56 > > > > Abbie Barbir wrote: > > > At this point, the issues of notification/tracing have not been > > brought up (yet?). > > Absolutley correct and an important point!! Is there anything me must > consider in the callout protocl design for tracing and > notification? I > would assume so... Any thoughts? > > While probably separate from the callout protocol design, we > also need > to discuss possible impact on the application message protocol, for > example for an "OPES bypass" mechanism. This refers to the > requirement > that a user must be able to signal an OPES processor that (s)he wants > to bypass any OPES service (one of the IAB requirements) - > as briefly > discussed some time earlier, using (user-defined?) HTTP headers might > be an option.... So we also need to consider possible > impact/extensions on the application message protocol. Anyone some > thoughts on this one? > > -Markus > > > ------_=_NextPart_001_01C2E8AA.B2AAEECA Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Draft Agenda for IETF 56

Hello Abbie,

I guess there are two approaches here:

1) Making extensions for every single application = protocol that might use OPES.
  ...Although some people that in realitly we = will have maybe 4 (HTTP, RTP, SMTP, FTP).

2) Developing an out of band protocol to signal such = preferences. That's why I said in the past looking at NSIS could be = interesting if we feel the list in 1) is already big/complicated enough = or might grow.

There is also the practical uses of either = approaches. Certainly, negotiating with the OPES processor what = will/not receive treatment every single HTTP session could add a lot of = overhead. Although HTTP could be used to negotiate, I guess we should = have provisions to say "bypass OPES for all HTTP sessions, until I = say otherwise", or vice-versa.

Regards,

Reinaldo


-----Original Message-----
From: Barbir, Abbie [CAR:1A00:EXCH]
Sent: Wednesday, March 12, 2003 9:06 AM
To: Markus Hofmann; OPES Group
Subject: RE: Draft Agenda for IETF 56


Markus,
it all do with HTTP extension etc.
I will detail later,
abbie


> -----Original Message-----
> From: Markus Hofmann [mailto:markus@mhof.com]
> Sent: Wednesday, March 12, 2003 8:28 AM
> To: OPES Group
> Subject: Re: Draft Agenda for IETF 56
>
>
>
> Abbie Barbir wrote:
>
> > At this point, the issues of = notification/tracing have not been
> > brought up (yet?).
>
> Absolutley correct and an important point!! Is = there anything me must
> consider in the callout protocl design for = tracing and
> notification? I
> would assume so... Any thoughts?
>
> While probably separate from the callout = protocol design, we
> also need
> to discuss possible impact on the application = message protocol, for
> example for an "OPES bypass" = mechanism. This refers to the
> requirement
> that a user must be able to signal an OPES = processor that (s)he wants
> to bypass any OPES service (one of the IAB = requirements)  -
> as briefly
> discussed some time earlier, using = (user-defined?) HTTP headers might
> be an option.... So we also need to consider = possible
> impact/extensions on the application message = protocol. Anyone some
> thoughts on this one?
>
> -Markus
>
>
>

------_=_NextPart_001_01C2E8AA.B2AAEECA-- From owner-ietf-openproxy@mail.imc.org Wed Mar 12 11:41: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 LAA10526 for ; Wed, 12 Mar 2003 11:41:29 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CGAlJ19819 for ietf-openproxy-bks; Wed, 12 Mar 2003 08:10:47 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CGAj319812 for ; Wed, 12 Mar 2003 08:10:45 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h2CGAknx057977 for ; Wed, 12 Mar 2003 09:10:46 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h2CGAkG1057976; Wed, 12 Mar 2003 09:10:46 -0700 (MST) (envelope-from rousskov) Date: Wed, 12 Mar 2003 09:10:46 -0700 (MST) From: Alex Rousskov To: OPES Group Subject: RE: Draft Agenda for IETF 56 In-Reply-To: <87609AFB433BD5118D5E0002A52CD754051EC587@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD754051EC587@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, 12 Mar 2003, Abbie Barbir wrote: > The discussions give me the feeling that we are trying to design a > (very flexible) system that is looking for a place in the field. I do not think the situation is that bad. We are trying to design a flexible system with a few _known_ places in the field. We have a use cases draft. We have every existing ICAP system as a "place". We have a few other very specific examples discussed on the mailing list. There were some very vague discussions/examples as well. Perhaps they create an impression that we are designing a general-purpose no-place system. The primary reason vague examples and requirements should be discussed is to make them specific; at that point they can be included in or excluded from OPES scope. > I could see the benefits to have various bindings for the callout > protocol. It gives felexibility. But at what expense? I really have > problems developing an architecture/protocols that can go all over > the field. I agree that it is easier to design with one binding in mind. However, I am in favor of a slightly different "lazy binding" approach: design without specific bindings until specific bindings become necessary to proceed. Most of the issues that have been discussed and solved so far are binding-independent. I would suggest to postpone any binding decision until it actually becomes necessary. There is some overhead in this approach, but I think it is small. On the other hand, it is much more expensive (and often nearly impossible) to add bindings to a single-binding protocol. > The architecture document states that the example protocol is HTTP. > I know that we should be open minded in the design of the callout > protocol. I try to keep the following list of protocols in mind: Application protocols it would be nice to support: - HTTP - SMTP - RTSP - instant messaging protocols Transport protocols we may want to support: - raw TCP - BEEP over TCP - HTTP over TCP - SOAP over the above I still need to learn more about SCTP, but it should be added to the above transport list. With application protocols, we want to support as many as possible. With transport protocols, we want to have just the necessary binding(s). But, again, I prefer to make decisions when they become necessary. > However, I would like to start with HTTP and then come up with a > callout protocol that can work with it. After that, I would like to > see how we address all of the IAB issues regarding OPES. We can then > move the excerise to RTP (SRTP etc..), and use that knowledge to > ensure that we have a flexible protocol. I disagree with the ordering, but I think we can still work together while preserving the differences in approaches: you can assume HTTP in all future discussions (while keeping the end goal in mind), and I will assume a group of protocols. There should be no significant design conflicts until we actually have to make the decision of what application protocols to support. I think adding support for very different application protocols on top of a nearly finished OPES design will lead to kludges and inferior results. > At this point, the issues of notification/tracing have not been > brought up (yet?). I am finishing up the next version of the predraft protocol. The biggest new additions are cleaner message hierarchy and connection management functions, based on the discussions on this list. I plan to address tracing and user preferences next, unless somebody beats me to it. Alex. From owner-ietf-openproxy@mail.imc.org Wed Mar 12 11:43: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 LAA10561 for ; Wed, 12 Mar 2003 11:43:53 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CGKjg20153 for ietf-openproxy-bks; Wed, 12 Mar 2003 08:20:45 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CGKi320142 for ; Wed, 12 Mar 2003 08:20:44 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h2CGKjnx058211 for ; Wed, 12 Mar 2003 09:20:45 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h2CGKjqv058210; Wed, 12 Mar 2003 09:20:45 -0700 (MST) (envelope-from rousskov) Date: Wed, 12 Mar 2003 09:20:45 -0700 (MST) From: Alex Rousskov To: OPES Group Subject: Re: Draft Agenda for IETF 56 In-Reply-To: <3E6F35F8.2080206@mhof.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD754051EC587@zcard0k6.ca.nortel.com> <3E6F35F8.2080206@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 Wed, 12 Mar 2003, Markus Hofmann wrote: > While probably separate from the callout protocol design, we also > need to discuss possible impact on the application message protocol, > for example for an "OPES bypass" mechanism. This refers to the > requirement that a user must be able to signal an OPES processor > that (s)he wants to bypass any OPES service (one of the IAB > requirements) - as briefly discussed some time earlier, using > (user-defined?) HTTP headers might be an option.... So we also need > to consider possible impact/extensions on the application message > protocol. Anyone some thoughts on this one? You are right that this is pretty much unrelated to the callout protocol: calls should no go out if OPES is being bypassed. The only related aspect is that the callout protocol may have to pass user bypass instructions/preferences _if_ we want to support selective bypass (e.g., "bypass only this OPES/service"). I am not sure we need that kind of selectivity at this point. For each supported application protocol, we would need to define ways to pass OPES preferences and tracing information. It should be fairly easy for any application protocol that supports extensions (e.g., HTTP and SMTP). The first thing to decide is probably OPES identification/addressing system that will be shared by both tracing and bypass OPES features. What do we want to identify and/or address? - just OPES processors - OPES processors and callout servers - OPES processors, callout servers, and services - other? Alex. From owner-ietf-openproxy@mail.imc.org Wed Mar 12 12:01: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 MAA11103 for ; Wed, 12 Mar 2003 12:01:19 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CGans20716 for ietf-openproxy-bks; Wed, 12 Mar 2003 08:36:49 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CGam320712 for ; Wed, 12 Mar 2003 08:36:48 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h2CGannx058658 for ; Wed, 12 Mar 2003 09:36:49 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h2CGanqj058657; Wed, 12 Mar 2003 09:36:49 -0700 (MST) (envelope-from rousskov) Date: Wed, 12 Mar 2003 09:36:49 -0700 (MST) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: RE: Draft Agenda for IETF 56 In-Reply-To: <5.2.0.9.0.20030312145033.024d9ec0@mail.utel.net> Message-ID: References: <5.2.0.9.0.20030312145033.024d9ec0@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, 12 Mar 2003, jfcm wrote: > This was my initial point. We are asked to build a bicycle. We see > that we can also build a car. Let avoid building an Harley Davidson > everyone will enjoy but no one will use. > > 1. let build the bicycle > 2. in keeping in mind what could be reused from a car production later on, > so we keep consistent. Bicycle is pretty much useless if you want to end up with a car. If you want a car, you would have to get rid of the bicycle and start from scratch. OPES architecture draft explicitly says that OPES is application agnostic. Do you have any specific objections to keeping it this way? 0. we are asked to build at least a Geo Metro 1. let's build a Honda Civic because it is not that much harder 2. later, when/if we have time/need/desire, we can build a Porsche and a Ford truck. But these analogies are pretty useless because nobody can define a bicycle or a car well enough. We need more specific objections/arguments to change the architecture draft and protocol development process. > This is why I think we should do as you say: http. The real project > I would propose would be a redirect system upon decision of a server > (I have a real need :-). I suppose that if a few ones could have in > mind a similar application, we could confront with real life > examples. Redirection discussion is already on the meeting agenda, so we are moving forward. I do not see any reason to keep redirection HTTP-specific at this time. Do you? > Then may be we could check SMTP to be sure it works well in a > different model? And if it does not? Start from scratch? Also, when is "then"? I think "then" should be now. Again, if you prefer to think of just one specific protocol and use case, that's fine, but why prohibit others from supporting more when possible? Alex. From owner-ietf-openproxy@mail.imc.org Wed Mar 12 12:05: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 MAA11300 for ; Wed, 12 Mar 2003 12:05:14 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CGWv120574 for ietf-openproxy-bks; Wed, 12 Mar 2003 08:32:57 -0800 (PST) Received: from mail.mailsnare.net (mail.mailsnare.net [207.44.136.42]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CGWu320570 for ; Wed, 12 Mar 2003 08:32:56 -0800 (PST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by dummy.domain.name (Postfix) with SMTP id A0D25464062 for ; Wed, 12 Mar 2003 16:32:52 +0000 (UTC) Received: from mhof.com (unknown [135.104.20.68]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.mailsnare.net (Postfix) with ESMTP id 2D1B5464090 for ; Wed, 12 Mar 2003 16:32:52 +0000 (UTC) Message-ID: <3E6F6133.8020302@mhof.com> Date: Wed, 12 Mar 2003 11:32:51 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us MIME-Version: 1.0 To: OPES Group Subject: Re: Draft Agenda for IETF 56 References: <0A11633F61BD9F40B43ABCC694004F93F18E26@zsc3c026.us.nortel.com> In-Reply-To: <0A11633F61BD9F40B43ABCC694004F93F18E26@zsc3c026.us.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 Reinaldo Penno wrote: > I guess there are two approaches here: > > 1) Making extensions for every single application protocol that might use > OPES. > ...Although some people that in realitly we will have maybe 4 (HTTP, RTP, > SMTP, FTP). Just a reminder - although we've a SHOULD requirement that states that our solutions should be protocol agnostic (and I think we all agree on that), our charter is focused on HTTP (and RTP, although we agreed the main focus being on HTTP). > 2) Developing an out of band protocol to signal such preferences. That's why > I said in the past looking at NSIS could be interesting if we feel the list > in 1) is already big/complicated enough or might grow. > > There is also the practical uses of either approaches. Certainly, > negotiating with the OPES processor what will/not receive treatment every > single HTTP session could add a lot of overhead. Although HTTP could be used > to negotiate, I guess we should have provisions to say "bypass OPES for all > HTTP sessions, until I say otherwise", or vice-versa. I'd suggest we go down a similar path as we currently do with the callout protocol, namely discussing required functionality and general design issues, first (rather than starting to discuss how and in which specific form to do it). I.e. what exactly do we need to signal (one example is the "OPES bypass"), what are the interaction schemes, what needs to be signaled, etc. Then we can discuss what's the best way to do this (e.g. "in-band" vs. "out-of-band") etc. [Note: Just to avoid confustion - this is *not* about the callout protocol, this is about the application protocl path). Maybe Abbie and Reinaldo you want to take a first shot, since you seem to look at this from slightly different perspectives. Of course, anyone else should feel free to take a first step as well... -Markus From owner-ietf-openproxy@mail.imc.org Wed Mar 12 12:25:53 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 MAA12289 for ; Wed, 12 Mar 2003 12:25:51 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CGqui21138 for ietf-openproxy-bks; Wed, 12 Mar 2003 08:52:56 -0800 (PST) Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CGqt321134 for ; Wed, 12 Mar 2003 08:52:55 -0800 (PST) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CGqnP00373; Wed, 12 Mar 2003 08:52:49 -0800 (PST) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1LW2V4NV>; Wed, 12 Mar 2003 08:52:34 -0800 Message-ID: <0A11633F61BD9F40B43ABCC694004F93F18E28@zsc3c026.us.nortel.com> From: "Reinaldo Penno" To: "'Markus Hofmann'" , OPES Group Subject: RE: Draft Agenda for IETF 56 Date: Wed, 12 Mar 2003 08:52:33 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E8B7.C6DB2EAC" 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_01C2E8B7.C6DB2EAC Content-Type: text/plain > -----Original Message----- > From: Markus Hofmann [mailto:markus@mhof.com] > Sent: Wednesday, March 12, 2003 11:33 AM > To: OPES Group > Subject: Re: Draft Agenda for IETF 56 > > > > Reinaldo Penno wrote: > > > I guess there are two approaches here: > > > > 1) Making extensions for every single application protocol > that might > > use OPES. > > ...Although some people that in realitly we will have > maybe 4 (HTTP, > > RTP, SMTP, FTP). > > Just a reminder - although we've a SHOULD requirement that > states that > our solutions should be protocol agnostic (and I think we all > agree on > that), our charter is focused on HTTP (and RTP, although we > agreed the > main focus being on HTTP). Yes, I was pointing out some issues that could influence the protocol choice (in vs out of band). Although we can make HTTP work, it *might* be waste of cycles if we foresee the use of other protocols in the future and using/designing a general out of band protocol is not that much extra effort. This is the kind of tradeoffs we should discuss before actually making a choice of in vs out of band. And I agree we should discuss functionality/requirements wihthout a specific solution in mind. > > > 2) Developing an out of band protocol to signal such preferences. > > That's why I said in the past looking at NSIS could be > interesting if > > we feel the list in 1) is already big/complicated enough or might > > grow. > > > > There is also the practical uses of either approaches. Certainly, > > negotiating with the OPES processor what will/not receive treatment > > every single HTTP session could add a lot of overhead. > Although HTTP > > could be used to negotiate, I guess we should have > provisions to say > > "bypass OPES for all HTTP sessions, until I say otherwise", or > > vice-versa. > > I'd suggest we go down a similar path as we currently do with the > callout protocol, namely discussing required functionality > and general > design issues, first (rather than starting to discuss how and > in which > specific form to do it). I.e. what exactly do we need to signal (one > example is the "OPES bypass"), what are the interaction schemes, what > needs to be signaled, etc. Then we can discuss what's the best way to > do this (e.g. "in-band" vs. "out-of-band") etc. [Note: Just to avoid > confustion - this is *not* about the callout protocol, this is about > the application protocl path). > > Maybe Abbie and Reinaldo you want to take a first shot, since > you seem > to look at this from slightly different perspectives. Of course, > anyone else should feel free to take a first step as well... Okay. Abbie and I will take a first shot on this... > > -Markus > > > ------_=_NextPart_001_01C2E8B7.C6DB2EAC Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Draft Agenda for IETF 56

> -----Original Message-----
> From: Markus Hofmann [mailto:markus@mhof.com]
> Sent: Wednesday, March 12, 2003 11:33 AM
> To: OPES Group
> Subject: Re: Draft Agenda for IETF 56
>
>
>
> Reinaldo Penno wrote:
>
> > I guess there are two approaches = here:
> >
> > 1) Making extensions for every single = application protocol
> that might
> > use OPES.
> >   ...Although some people that = in realitly we will have
> maybe 4 (HTTP,
> > RTP, SMTP, FTP).
>
> Just a reminder - although we've a SHOULD = requirement that
> states that
> our solutions should be protocol agnostic (and = I think we all
> agree on
> that), our charter is focused on HTTP (and RTP, = although we
> agreed the
> main focus being on HTTP).

Yes, I was pointing out some issues that could = influence the protocol choice (in vs out of band). Although we can make = HTTP work, it *might* be waste of cycles if we foresee the use of other = protocols in the future and using/designing a general out of band = protocol is not that much extra effort.

This is the kind of tradeoffs we should discuss = before actually making a choice of in vs out of band. And I agree we = should discuss functionality/requirements wihthout a specific solution = in mind.

>
> > 2) Developing an out of band protocol to = signal such preferences.
> > That's why I said in the past looking at = NSIS could be
> interesting if
> > we feel the list in 1) is already = big/complicated enough or might
> > grow.
> >
> > There is also the practical uses of either = approaches. Certainly,
> > negotiating with the OPES processor what = will/not receive treatment
> > every single HTTP session could add a lot = of overhead.
> Although HTTP
> > could be used to negotiate, I guess we = should have
> provisions to say
> > "bypass OPES for all HTTP sessions, = until I say otherwise", or
> > vice-versa.
>
> I'd suggest we go down a similar path as we = currently do with the
> callout protocol, namely discussing required = functionality
> and general
> design issues, first (rather than starting to = discuss how and
> in which
> specific form to do it). I.e. what exactly do = we need to signal (one
> example is the "OPES bypass"), what = are the interaction schemes, what
> needs to be signaled, etc. Then we can discuss = what's the best way to
> do this (e.g. "in-band" vs. = "out-of-band") etc. [Note: Just to avoid
> confustion - this is *not* about the callout = protocol, this is about
> the application protocl path).
>
> Maybe Abbie and Reinaldo you want to take a = first shot, since
> you seem
> to look at this from slightly different = perspectives. Of course,
> anyone else should feel free to take a first = step as well...

Okay. Abbie and I will take a first shot on = this...

>
> -Markus
>
>
>

------_=_NextPart_001_01C2E8B7.C6DB2EAC-- From owner-ietf-openproxy@mail.imc.org Wed Mar 12 12:29: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 MAA12367 for ; Wed, 12 Mar 2003 12:29:18 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CGqXD21118 for ietf-openproxy-bks; Wed, 12 Mar 2003 08:52:33 -0800 (PST) Received: from mail.mailsnare.net (mail.mailsnare.net [207.44.136.42]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CGqW321110 for ; Wed, 12 Mar 2003 08:52:32 -0800 (PST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by dummy.domain.name (Postfix) with SMTP id BF9A94640A6 for ; Wed, 12 Mar 2003 16:52:28 +0000 (UTC) Received: from mhof.com (unknown [135.104.20.68]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.mailsnare.net (Postfix) with ESMTP id 238874640A7 for ; Wed, 12 Mar 2003 16:52:28 +0000 (UTC) Message-ID: <3E6F65CB.6070303@mhof.com> Date: Wed, 12 Mar 2003 11:52:27 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us MIME-Version: 1.0 To: OPES Group Subject: Re: Draft Agenda for IETF 56 References: <87609AFB433BD5118D5E0002A52CD754051EC587@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 agree that it is easier to design with one binding in mind. > However, I am in favor of a slightly different "lazy binding" > approach: design without specific bindings until specific bindings > become necessary to proceed. Most of the issues that have been > discussed and solved so far are binding-independent. I would > suggest to postpone any binding decision until it actually becomes > necessary. This is the approach we had in mind with the "SHOULD be protocol agnostic" requirement. We start the design without assuming a specific application protocol, and only when it turns out that we need to the bind it to a specific application protocol, we'll do so - and we'll bind to HTTP in that case. Now, the need for such binding may arise if the "protocol-agnostic" approach should turn out to add too much complexity - meaning we need to strive for a good balance between generality and complexity of the callout protocol. > I think adding support for very different application protocols on > top of a nearly finished OPES design will lead to kludges and > inferior results. Yes! -Markus From owner-ietf-openproxy@mail.imc.org Wed Mar 12 12:32: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 MAA12469 for ; Wed, 12 Mar 2003 12:32:55 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CH7Kd22325 for ietf-openproxy-bks; Wed, 12 Mar 2003 09:07:20 -0800 (PST) Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CH7I322319 for ; Wed, 12 Mar 2003 09:07:19 -0800 (PST) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CH78P00684; Wed, 12 Mar 2003 09:07:08 -0800 (PST) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1LW2VVZQ>; Wed, 12 Mar 2003 09:06:53 -0800 Message-ID: <0A11633F61BD9F40B43ABCC694004F93F18E2A@zsc3c026.us.nortel.com> From: "Reinaldo Penno" To: "'Alex Rousskov'" , ietf-openproxy@imc.org Subject: RE: Draft Agenda for IETF 56 Date: Wed, 12 Mar 2003 09:06:52 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E8B9.C6AC7F24" 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_01C2E8B9.C6AC7F24 Content-Type: text/plain > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Wednesday, March 12, 2003 11:37 AM > To: ietf-openproxy@imc.org > Subject: RE: Draft Agenda for IETF 56 > > > > On Wed, 12 Mar 2003, jfcm wrote: > > > This was my initial point. We are asked to build a bicycle. We see > > that we can also build a car. Let avoid building an Harley Davidson > > everyone will enjoy but no one will use. > > > > 1. let build the bicycle > > 2. in keeping in mind what could be reused from a car > production later > > on, so we keep consistent. > > Bicycle is pretty much useless if you want to end up with a > car. If you want a car, you would have to get rid of the > bicycle and start from scratch. OPES architecture draft > explicitly says that OPES is application agnostic. Do you > have any specific objections to keeping it this way? My understading is that OPES is going to work for HTTP as the *application* protocol in phase 0. That does not mean the callout protocol is HTTP or will only work for HTTP. If the OCP is protocol agnostic, supporting RTP or something else in a later phase should be a matter of new specific messages/meta-data. I pushed a lot for OCP to be protocol agnostic so that we do not need to redo it again for every single application protocol, the intelligence remain on the end points (OCP is basically an intelligent data mover) and interoperability could be made easier. [], I just saw Markus' email and seems we are going down the protocol agnostic approach in good shape. Your pre-draft speaks for itself. > > 0. we are asked to build at least a Geo Metro > 1. let's build a Honda Civic because it is not that much > harder 2. later, when/if we have time/need/desire, we can > build a Porsche > and a Ford truck. > > But these analogies are pretty useless because nobody can > define a bicycle or a car well enough. We need more specific > objections/arguments to change the architecture draft and > protocol development process. > > > This is why I think we should do as you say: http. The real > project I > > would propose would be a redirect system upon decision of a > server (I > > have a real need :-). I suppose that if a few ones could > have in mind > > a similar application, we could confront with real life examples. > > Redirection discussion is already on the meeting agenda, so > we are moving forward. I do not see any reason to keep > redirection HTTP-specific at this time. Do you? > > > Then may be we could check SMTP to be sure it works well in a > > different model? > > And if it does not? Start from scratch? Also, when is "then"? > I think "then" should be now. > > > Again, if you prefer to think of just one specific protocol > and use case, that's fine, but why prohibit others from > supporting more when possible? > > Alex. > ------_=_NextPart_001_01C2E8B9.C6AC7F24 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Draft Agenda for IETF 56

> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Wednesday, March 12, 2003 11:37 AM
> To: ietf-openproxy@imc.org
> Subject: RE: Draft Agenda for IETF 56
>
>
>
> On Wed, 12 Mar 2003, jfcm wrote:
>
> > This was my initial point. We are asked to = build a bicycle. We see
> > that we can also build a car. Let avoid = building an Harley Davidson
> > everyone will enjoy but no one will = use.
> >
> > 1. let build the bicycle
> > 2. in keeping in mind what could be reused = from a car
> production later
> > on, so we keep consistent.
>
> Bicycle is pretty much useless if you want to = end up with a
> car. If you want a car, you would have to get = rid of the
> bicycle and start from scratch. OPES = architecture draft
> explicitly says that OPES is application = agnostic. Do you
> have any specific objections to keeping it this = way?

My understading is that OPES is going to work for = HTTP as the *application* protocol in phase 0. That does not mean the = callout protocol is HTTP or will only work for HTTP.

If the OCP is protocol agnostic, supporting RTP or = something else in a later phase should be a matter of new specific = messages/meta-data. I pushed a lot for OCP to be protocol agnostic so = that we do not need to redo it again for every single application = protocol, the intelligence remain on the end points (OCP is basically = an intelligent data mover) and interoperability could be made = easier.

[],

I just saw Markus' email and seems we are going down = the protocol agnostic approach in good shape. Your pre-draft speaks for = itself.



>
> 0. we are asked to build at least a Geo = Metro
> 1. let's build a Honda Civic because it is not = that much
> harder 2. later, when/if we have = time/need/desire, we can
> build a Porsche
>    and a Ford truck.
>
> But these analogies are pretty useless because = nobody can
> define a bicycle or a car well enough. We need = more specific
> objections/arguments to change the architecture = draft and
> protocol development process.
>
> > This is why I think we should do as you = say: http. The real
> project I
> > would propose would be a redirect system = upon decision of a
> server (I
> > have a real need :-). I suppose that if a = few ones could
> have in mind
> > a similar application, we could confront = with real life examples.
>
> Redirection discussion is already on the = meeting agenda, so
> we are moving forward. I do not see any reason = to keep
> redirection HTTP-specific at this time. Do = you?
>
> > Then may be we could check SMTP to be sure = it works well in a
> > different model?
>
> And if it does not? Start from scratch? Also, = when is "then"?
> I think "then" should be now.
>
>
> Again, if you prefer to think of just one = specific protocol
> and use case, that's fine, but why prohibit = others from
> supporting more when possible?
>
> Alex.
>

------_=_NextPart_001_01C2E8B9.C6AC7F24-- From owner-ietf-openproxy@mail.imc.org Wed Mar 12 12:40:42 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 MAA12704 for ; Wed, 12 Mar 2003 12:40:40 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CHBhs22976 for ietf-openproxy-bks; Wed, 12 Mar 2003 09:11:43 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CHBf322970 for ; Wed, 12 Mar 2003 09:11:42 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h2CHBhnx059479 for ; Wed, 12 Mar 2003 10:11:43 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h2CHBhdS059478; Wed, 12 Mar 2003 10:11:43 -0700 (MST) (envelope-from rousskov) Date: Wed, 12 Mar 2003 10:11:43 -0700 (MST) From: Alex Rousskov To: OPES Group Subject: RE: Draft Agenda for IETF 56 In-Reply-To: <0A11633F61BD9F40B43ABCC694004F93F18E26@zsc3c026.us.nortel.com> Message-ID: References: <0A11633F61BD9F40B43ABCC694004F93F18E26@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: I would like to suggest that we need general framework(s) for tracing and user preferences processing before we go into designing specific protocols, especially if we want to add extensions to [many] existing protocols. We must document what needs to be passed around and what the reaction on that information should be. Given such a framework, implementation in any specific protocol (new or old) would be a mundane task: - what is addressable? - what is traceable? - can tracing info be aggregated/modified? - do we need information authentication? - can end-point affect the extent of tracing? - what is the default behavior? - etc. All of the above has little dependency on the application protocols and, IMO, should be decided/documented first. The existings drafts do not cover these decisions well enough. Specific remarks are below. On Wed, 12 Mar 2003, Reinaldo Penno wrote: > I guess there are two approaches here: > > 1) Making extensions for every single application protocol that > might use OPES. ...Although some people that in realitly we will > have maybe 4 (HTTP, RTP, SMTP, FTP). That seems like the right way to proceed given that many protocols use similar extension mechanism (e.g. MIME or XML). One does not need to start from scratch for every new application protocol, just for every new extension scheme. > 2) Developing an out of band protocol to signal such preferences. > That's why I said in the past looking at NSIS could be interesting > if we feel the list in 1) is already big/complicated enough or might > grow. Synchronization issues with out-of-band and application protocol may prohibit you from supporting (2) efficiently. Also, it is usually easier in practice to add support for an extension than for a new protocol. > There is also the practical uses of either approaches. Certainly, > negotiating with the OPES processor what will/not receive treatment > every single HTTP session could add a lot of overhead. Although HTTP > could be used to negotiate, I guess we should have provisions to say > "bypass OPES for all HTTP sessions, until I say otherwise", or > vice-versa. This is debatable and probably protocol-specific. For example, it is usually _more_ overhead to supply state in HTTP because HTTP is stateless and can be proxied. Parsing a couple of simple extension headers with every transaction is much simpler and robust approach with HTTP, without noticeable performance penalties. Are there any application protocols that natively support "state management" on the intermediaries, across isolated transactions? Alex. > -----Original Message----- > From: Barbir, Abbie [CAR:1A00:EXCH] > Sent: Wednesday, March 12, 2003 9:06 AM > To: Markus Hofmann; OPES Group > Subject: RE: Draft Agenda for IETF 56 > > > Markus, > it all do with HTTP extension etc. > I will detail later, > abbie > > > > -----Original Message----- > > From: Markus Hofmann [mailto:markus@mhof.com] > > Sent: Wednesday, March 12, 2003 8:28 AM > > To: OPES Group > > Subject: Re: Draft Agenda for IETF 56 > > > > > > > > Abbie Barbir wrote: > > > > > At this point, the issues of notification/tracing have not been > > > brought up (yet?). > > > > Absolutley correct and an important point!! Is there anything me must > > consider in the callout protocl design for tracing and > > notification? I > > would assume so... Any thoughts? > > > > While probably separate from the callout protocol design, we > > also need > > to discuss possible impact on the application message protocol, for > > example for an "OPES bypass" mechanism. This refers to the > > requirement > > that a user must be able to signal an OPES processor that (s)he wants > > to bypass any OPES service (one of the IAB requirements) - > > as briefly > > discussed some time earlier, using (user-defined?) HTTP headers might > > be an option.... So we also need to consider possible > > impact/extensions on the application message protocol. Anyone some > > thoughts on this one? > > > > -Markus > > > > > > > From owner-ietf-openproxy@mail.imc.org Wed Mar 12 12:47: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 MAA13256 for ; Wed, 12 Mar 2003 12:47:30 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CHFCL23495 for ietf-openproxy-bks; Wed, 12 Mar 2003 09:15:12 -0800 (PST) Received: from mail.mailsnare.net (mail.mailsnare.net [207.44.136.42]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CHFB323486 for ; Wed, 12 Mar 2003 09:15:11 -0800 (PST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by dummy.domain.name (Postfix) with SMTP id 121B04640A0 for ; Wed, 12 Mar 2003 17:15:08 +0000 (UTC) Received: from mhof.com (unknown [135.104.20.68]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.mailsnare.net (Postfix) with ESMTP id 7C257464090 for ; Wed, 12 Mar 2003 17:15:07 +0000 (UTC) Message-ID: <3E6F6B1A.6060000@mhof.com> Date: Wed, 12 Mar 2003 12:15:06 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us MIME-Version: 1.0 To: OPES Group Subject: Re: Draft Agenda for IETF 56 References: <87609AFB433BD5118D5E0002A52CD754051EC587@zcard0k6.ca.nortel.com> <3E6F35F8.2080206@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: > You are right that this is pretty much unrelated to the callout > protocol: calls should no go out if OPES is being bypassed. The only > related aspect is that the callout protocol may have to pass user > bypass instructions/preferences _if_ we want to support selective > bypass (e.g., "bypass only this OPES/service"). I am not sure we need > that kind of selectivity at this point. Isn't this kind of selectivity provided by the OPES rules? If a user wants to use OPES services, in general, but wants to bypass specific services, this should be reflected in the user's rules rather than "in-band" in application messages... With respect to the callout protocol possibly having to pass user bypass instructions/preferences... I assume the OPES processor includes explicite instructions on which services to execute in the callout protocol messages. As such, not including a specific service implies that it won't be executed, implicitely implementing a "bypass". Think we're in agreement... > The first thing to decide is probably OPES identification/addressing > system that will be shared by both tracing and bypass OPES features. > What do we want to identify and/or address? > - just OPES processors > - OPES processors and callout servers > - OPES processors, callout servers, and services > - other? For tracing it seems we need to identify all three, meaning OPES processors, callout servers, and the services, implying we need an identification/adressing cheme for all three of them. This should also cover the bypass and debugging feature. -Markus From owner-ietf-openproxy@mail.imc.org Wed Mar 12 12:51: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 MAA13490 for ; Wed, 12 Mar 2003 12:51:26 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CHLvC23734 for ietf-openproxy-bks; Wed, 12 Mar 2003 09:21:57 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CHLt323729 for ; Wed, 12 Mar 2003 09:21:56 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h2CHLvnx059725 for ; Wed, 12 Mar 2003 10:21:57 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h2CHLvdW059724; Wed, 12 Mar 2003 10:21:57 -0700 (MST) (envelope-from rousskov) Date: Wed, 12 Mar 2003 10:21:57 -0700 (MST) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: RE: Draft Agenda for IETF 56 In-Reply-To: <0A11633F61BD9F40B43ABCC694004F93F18E2A@zsc3c026.us.nortel.com> Message-ID: References: <0A11633F61BD9F40B43ABCC694004F93F18E2A@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, 12 Mar 2003, Reinaldo Penno wrote: > My understading is that OPES is going to work for HTTP as the > *application* protocol in phase 0. That does not mean the callout > protocol is HTTP or will only work for HTTP. I agree. > If the OCP is protocol agnostic, supporting RTP or something else in > a later phase should be a matter of new specific messages/meta-data. Exactly! But it does not happen automagically, just because we have a SHOULD in the requirements draft. If we forget about that SHOULD now, and only think about HTTP, then I am positive that we will violate that SHOULD soon and, more importantly, would have to redo a lot of work to satisfy it again. That is why I am suggesting that we are not prohibited from making the callout protocol general enough to support more than just HTTP. Now. > I pushed a lot for OCP to be protocol agnostic so that we do not > need to redo it again for every single application protocol, the > intelligence remain on the end points (OCP is basically an > intelligent data mover) and interoperability could be made easier. I fully agree that OCP SHOULD be protocol agnostic. Now we need to do the legwork to make it that way. Alex. From owner-ietf-openproxy@mail.imc.org Wed Mar 12 13:00: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 NAA13947 for ; Wed, 12 Mar 2003 13:00:29 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CHWgQ24040 for ietf-openproxy-bks; Wed, 12 Mar 2003 09:32:42 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CHWe324036 for ; Wed, 12 Mar 2003 09:32:41 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h2CHWgnx059969 for ; Wed, 12 Mar 2003 10:32:42 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h2CHWgV3059968; Wed, 12 Mar 2003 10:32:42 -0700 (MST) (envelope-from rousskov) Date: Wed, 12 Mar 2003 10:32:42 -0700 (MST) From: Alex Rousskov To: OPES Group Subject: Re: Draft Agenda for IETF 56 In-Reply-To: <3E6F6133.8020302@mhof.com> Message-ID: References: <0A11633F61BD9F40B43ABCC694004F93F18E26@zsc3c026.us.nortel.com> <3E6F6133.8020302@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 Wed, 12 Mar 2003, Markus Hofmann wrote: > Just a reminder - although we've a SHOULD requirement that states > that our solutions should be protocol agnostic (and I think we all > agree on that), our charter is focused on HTTP (and RTP, although we > agreed the main focus being on HTTP). What it means to me is that: - we MUST support HTTP as an application protocol - we SHOULD support more than just HTTP - in case of a specific design conflict, HTTP-arguments MAY have higher priority than arguments for other application protocols The above is different from - we MUST support HTTP as an application protocol - we MUST NOT consider other application protocols until HTTP is supported - we SHOULD check other application protocols after HTTP is supported > I'd suggest we go down a similar path as we currently do with the > callout protocol, namely discussing required functionality and > general design issues, first (rather than starting to discuss how > and in which specific form to do it). I.e. what exactly do we need > to signal (one example is the "OPES bypass"), what are the > interaction schemes, what needs to be signaled, etc. Then we can > discuss what's the best way to do this (e.g. "in-band" vs. > "out-of-band") etc. I, obviously, agree. > [Note: Just to avoid confustion - this is *not* about the callout > protocol, this is about the application protocl path). There is some interaction between the two though. For example, we need to decide whether the callout server or OPES dispatcher/processor is responsible for tracing (could be both too!). If callout server is responsible, then the callout protocol may have to provide appropriate support, especially if we decide to use out-of-bound (#2) approach. Hmm... The latter actually demonstrates another weakness of the out-of-bound approach: it makes it difficult for callout servers to participate in tracing and similar activities because the "end" is not talking to them but to the proxy. On the other hand, maybe this is a sign that callout servers must not participate? Alex. From owner-ietf-openproxy@mail.imc.org Wed Mar 12 13:27: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 NAA14850 for ; Wed, 12 Mar 2003 13:27:45 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CHs9324689 for ietf-openproxy-bks; Wed, 12 Mar 2003 09:54:09 -0800 (PST) Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CHs8324684 for ; Wed, 12 Mar 2003 09:54:08 -0800 (PST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CHrvO27530; Wed, 12 Mar 2003 12:53:57 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Mar 2003 12:53:58 -0500 Message-ID: <87609AFB433BD5118D5E0002A52CD754051EC9CE@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Alex Rousskov , OPES Group Subject: RE: Draft Agenda for IETF 56 Date: Wed, 12 Mar 2003 12:53:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E8C0.5A67D316" 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_01C2E8C0.5A67D316 Content-Type: text/plain Hi, sorry, sick today, just came back from doctor. good thread, however, the good thing here is the start of the work by alex on determining the traceability/notification requirements. My opinion at this stage, is that let us get it right starting with HTTP and then determine how it relates to the other protocols. thanks abbie > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Wednesday, March 12, 2003 12:33 PM > To: OPES Group > Subject: Re: Draft Agenda for IETF 56 > > > > On Wed, 12 Mar 2003, Markus Hofmann wrote: > > > Just a reminder - although we've a SHOULD requirement that > states that > > our solutions should be protocol agnostic (and I think we > all agree on > > that), our charter is focused on HTTP (and RTP, although we > agreed the > > main focus being on HTTP). > > What it means to me is that: > - we MUST support HTTP as an application protocol > - we SHOULD support more than just HTTP > - in case of a specific design conflict, HTTP-arguments MAY > have higher priority than arguments for other application > protocols > > The above is different from > - we MUST support HTTP as an application protocol > - we MUST NOT consider other application protocols > until HTTP is supported > - we SHOULD check other application protocols > after HTTP is supported > > > I'd suggest we go down a similar path as we currently do with the > > callout protocol, namely discussing required functionality > and general > > design issues, first (rather than starting to discuss how > and in which > > specific form to do it). I.e. what exactly do we need to > signal (one > > example is the "OPES bypass"), what are the interaction > schemes, what > > needs to be signaled, etc. Then we can discuss what's the > best way to > > do this (e.g. "in-band" vs. > > "out-of-band") etc. > > I, obviously, agree. > > > [Note: Just to avoid confustion - this is *not* about the callout > > protocol, this is about the application protocl path). > > There is some interaction between the two though. For > example, we need to decide whether the callout server or OPES > dispatcher/processor is responsible for tracing (could be > both too!). If callout server is responsible, then the > callout protocol may have to provide appropriate support, > especially if we decide to use out-of-bound (#2) approach. > > Hmm... The latter actually demonstrates another weakness of > the out-of-bound approach: it makes it difficult for callout > servers to participate in tracing and similar activities > because the "end" is not talking to them but to the proxy. On > the other hand, maybe this is a sign that callout servers > must not participate? > > Alex. > > ------_=_NextPart_001_01C2E8C0.5A67D316 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Draft Agenda for IETF 56

Hi,

sorry, sick today, just came back from doctor.

good thread, however, the good thing here is the = start of the work by alex on determining the traceability/notification = requirements.

My opinion at this stage, is that let us get it right = starting with HTTP and then determine how it relates to the other = protocols.

thanks

abbie


> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Wednesday, March 12, 2003 12:33 PM
> To: OPES Group
> Subject: Re: Draft Agenda for IETF 56
>
>
>
> On Wed, 12 Mar 2003, Markus Hofmann = wrote:
>
> > Just a reminder - although we've a SHOULD = requirement that
> states that
> > our solutions should be protocol agnostic = (and I think we
> all agree on
> > that), our charter is focused on HTTP (and = RTP, although we
> agreed the
> > main focus being on HTTP).
>
> What it means to me is that:
>       - we MUST = support HTTP as an application protocol
>       - we SHOULD = support more than just HTTP
>       - in case of a = specific design conflict, HTTP-arguments MAY
>         have = higher priority than arguments for other application
>         = protocols
>
> The above is different from
>       - we MUST = support HTTP as an application protocol
>       - we MUST NOT = consider other application protocols
>         until = HTTP is supported
>       - we SHOULD = check other application protocols
>         after = HTTP is supported
>
> > I'd suggest we go down a similar path as = we currently do with the
> > callout protocol, namely discussing = required functionality
> and general
> > design issues, first (rather than starting = to discuss how
> and in which
> > specific form to do it). I.e. what exactly = do we need to
> signal (one
> > example is the "OPES bypass"), = what are the interaction
> schemes, what
> > needs to be signaled, etc. Then we can = discuss what's the
> best way to
> > do this (e.g. "in-band" = vs.
> > "out-of-band") etc.
>
> I, obviously, agree.
>
> > [Note: Just to avoid confustion - this is = *not* about the callout
> > protocol, this is about the application = protocl path).
>
> There is some interaction between the two = though. For
> example, we need to decide whether the callout = server or OPES
> dispatcher/processor is responsible for tracing = (could be
> both too!). If callout server is responsible, = then the
> callout protocol may have to provide = appropriate support,
> especially if we decide to use out-of-bound = (#2) approach.
>
> Hmm... The latter actually demonstrates another = weakness of
> the out-of-bound approach: it makes it = difficult for callout
> servers to participate in tracing and similar = activities
> because the "end" is not talking to = them but to the proxy. On
> the other hand, maybe this is a sign that = callout servers
> must not participate?
>
> Alex.
>
>

------_=_NextPart_001_01C2E8C0.5A67D316-- From owner-ietf-openproxy@mail.imc.org Wed Mar 12 13:29:53 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 NAA14967 for ; Wed, 12 Mar 2003 13:29:48 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CHu0o24753 for ietf-openproxy-bks; Wed, 12 Mar 2003 09:56:00 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CHtw324748 for ; Wed, 12 Mar 2003 09:55:58 -0800 (PST) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CHtlg21226; Wed, 12 Mar 2003 11:55:47 -0600 (CST) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1LW2VZDP>; Wed, 12 Mar 2003 09:55:47 -0800 Message-ID: <0A11633F61BD9F40B43ABCC694004F93F18E2C@zsc3c026.us.nortel.com> From: "Reinaldo Penno" To: "'Alex Rousskov'" , OPES Group Subject: RE: Draft Agenda for IETF 56 Date: Wed, 12 Mar 2003 09:55:46 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E8C0.9BDB1E8E" 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_01C2E8C0.9BDB1E8E Content-Type: text/plain > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Wednesday, March 12, 2003 12:33 PM > To: OPES Group > Subject: Re: Draft Agenda for IETF 56 > > > > On Wed, 12 Mar 2003, Markus Hofmann wrote: > > > Just a reminder - although we've a SHOULD requirement that > states that > > our solutions should be protocol agnostic (and I think we > all agree on > > that), our charter is focused on HTTP (and RTP, although we > agreed the > > main focus being on HTTP). > > What it means to me is that: > - we MUST support HTTP as an application protocol > - we SHOULD support more than just HTTP > - in case of a specific design conflict, HTTP-arguments MAY > have higher priority than arguments for other application > protocols > > The above is different from > - we MUST support HTTP as an application protocol > - we MUST NOT consider other application protocols > until HTTP is supported > - we SHOULD check other application protocols > after HTTP is supported > > > I'd suggest we go down a similar path as we currently do with the > > callout protocol, namely discussing required functionality > and general > > design issues, first (rather than starting to discuss how > and in which > > specific form to do it). I.e. what exactly do we need to > signal (one > > example is the "OPES bypass"), what are the interaction > schemes, what > > needs to be signaled, etc. Then we can discuss what's the > best way to > > do this (e.g. "in-band" vs. > > "out-of-band") etc. > > I, obviously, agree. > > > [Note: Just to avoid confustion - this is *not* about the callout > > protocol, this is about the application protocl path). > > There is some interaction between the two though. For > example, we need to decide whether the callout server or OPES > dispatcher/processor is responsible for tracing (could be > both too!). If callout server is responsible, then the > callout protocol may have to provide appropriate support, > especially if we decide to use out-of-bound (#2) approach. > > Hmm... The latter actually demonstrates another weakness of > the out-of-bound approach: it makes it difficult for callout > servers to participate in tracing and similar activities > because the "end" is not talking to them but to the proxy. On > the other hand, maybe this is a sign that callout servers > must not participate? Independent of in vs out of band, IMO the end points always talk to the OPES processor. The OPES processor will use whatever means necessary to perform the requested services, including use of a callout server. You might even use a callout server for a certain service only if your CPU is above a certain watermark, so there is no pre-established behaviour of what the OPES processor will do to honor the request. Whatever tracing messages the callout might include on the message, the OPES processor can easily relay them to the end points with its own tracing. [], > > Alex. > > ------_=_NextPart_001_01C2E8C0.9BDB1E8E Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Draft Agenda for IETF 56

> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Wednesday, March 12, 2003 12:33 PM
> To: OPES Group
> Subject: Re: Draft Agenda for IETF 56
>
>
>
> On Wed, 12 Mar 2003, Markus Hofmann = wrote:
>
> > Just a reminder - although we've a SHOULD = requirement that
> states that
> > our solutions should be protocol agnostic = (and I think we
> all agree on
> > that), our charter is focused on HTTP (and = RTP, although we
> agreed the
> > main focus being on HTTP).
>
> What it means to me is that:
>       - we MUST = support HTTP as an application protocol
>       - we SHOULD = support more than just HTTP
>       - in case of a = specific design conflict, HTTP-arguments MAY
>         have = higher priority than arguments for other application
>         = protocols
>
> The above is different from
>       - we MUST = support HTTP as an application protocol
>       - we MUST NOT = consider other application protocols
>         until = HTTP is supported
>       - we SHOULD = check other application protocols
>         after = HTTP is supported
>
> > I'd suggest we go down a similar path as = we currently do with the
> > callout protocol, namely discussing = required functionality
> and general
> > design issues, first (rather than starting = to discuss how
> and in which
> > specific form to do it). I.e. what exactly = do we need to
> signal (one
> > example is the "OPES bypass"), = what are the interaction
> schemes, what
> > needs to be signaled, etc. Then we can = discuss what's the
> best way to
> > do this (e.g. "in-band" = vs.
> > "out-of-band") etc.
>
> I, obviously, agree.
>
> > [Note: Just to avoid confustion - this is = *not* about the callout
> > protocol, this is about the application = protocl path).
>
> There is some interaction between the two = though. For
> example, we need to decide whether the callout = server or OPES
> dispatcher/processor is responsible for tracing = (could be
> both too!). If callout server is responsible, = then the
> callout protocol may have to provide = appropriate support,
> especially if we decide to use out-of-bound = (#2) approach.
>
> Hmm... The latter actually demonstrates another = weakness of
> the out-of-bound approach: it makes it = difficult for callout
> servers to participate in tracing and similar = activities
> because the "end" is not talking to = them but to the proxy. On
> the other hand, maybe this is a sign that = callout servers
> must not participate?

Independent of in vs out of band, IMO the end points = always talk to the OPES processor. The OPES processor will use whatever = means necessary to perform the requested services, including use of a = callout server. You might even use a callout server for a certain = service only if your CPU is above a certain watermark, so there is no = pre-established behaviour of what the OPES processor will do to honor = the request.

Whatever tracing messages the callout might include = on the message, the OPES processor can easily relay them to the end = points with its own tracing.

[],

>
> Alex.
>
>

------_=_NextPart_001_01C2E8C0.9BDB1E8E-- From owner-ietf-openproxy@mail.imc.org Wed Mar 12 13:43: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 NAA15837 for ; Wed, 12 Mar 2003 13:43:58 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CIIgU27627 for ietf-openproxy-bks; Wed, 12 Mar 2003 10:18:42 -0800 (PST) Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CIIf327622 for ; Wed, 12 Mar 2003 10:18:42 -0800 (PST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CIIUO00084; Wed, 12 Mar 2003 13:18:31 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Mar 2003 13:18:30 -0500 Message-ID: <87609AFB433BD5118D5E0002A52CD754051ECA40@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: "Reinaldo Penno" , "'Alex Rousskov'" , OPES Group Subject: RE: Draft Agenda for IETF 56 Date: Wed, 12 Mar 2003 13:18:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E8C3.C8EC11FA" 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_01C2E8C3.C8EC11FA Content-Type: text/plain -----Original Message----- From: Penno, Reinaldo [BL60:0430:EXCH] Sent: Wednesday, March 12, 2003 12:56 PM To: 'Alex Rousskov'; OPES Group Subject: RE: Draft Agenda for IETF 56 SNIP Independent of in vs out of band, IMO the end points always talk to the OPES processor. The OPES processor will use whatever means necessary to perform the requested services, including use of a callout server. You might even use a callout server for a certain service only if your CPU is above a certain watermark, so there is no pre-established behaviour of what the OPES processor will do to honor the request. Whatever tracing messages the callout might include on the message, the OPES processor can easily relay them to the end points with its own tracing. SNIP I fully agree. Abbie ------_=_NextPart_001_01C2E8C3.C8EC11FA Content-Type: text/html Message
 
-----Original Message-----
From: Penno, Reinaldo [BL60:0430:EXCH]
Sent: Wednesday, March 12, 2003 12:56 PM
To: 'Alex Rousskov'; OPES Group
Subject: RE: Draft Agenda for IETF 56


 SNIP 

Independent of in vs out of band, IMO the end points always talk to the OPES processor. The OPES processor will use whatever means necessary to perform the requested services, including use of a callout server. You might even use a callout server for a certain service only if your CPU is above a certain watermark, so there is no pre-established behaviour of what the OPES processor will do to honor the request.

Whatever tracing messages the callout might include on the message, the OPES processor can easily relay them to the end points with its own tracing.

 SNIP 

 

I fully agree.

Abbie

 

------_=_NextPart_001_01C2E8C3.C8EC11FA-- From owner-ietf-openproxy@mail.imc.org Wed Mar 12 13:44: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 NAA15851 for ; Wed, 12 Mar 2003 13:44:04 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CIC9526605 for ietf-openproxy-bks; Wed, 12 Mar 2003 10:12:09 -0800 (PST) Received: from mail.mailsnare.net (mail.mailsnare.net [207.44.136.42]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CIC7326599 for ; Wed, 12 Mar 2003 10:12:07 -0800 (PST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by dummy.domain.name (Postfix) with SMTP id 683434640A7 for ; Wed, 12 Mar 2003 18:12:04 +0000 (UTC) Received: from mhof.com (unknown [135.104.20.68]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.mailsnare.net (Postfix) with ESMTP id C8C9A464076 for ; Wed, 12 Mar 2003 18:12:03 +0000 (UTC) Message-ID: <3E6F7872.8060402@mhof.com> Date: Wed, 12 Mar 2003 13:12:02 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us MIME-Version: 1.0 To: OPES Group Subject: Re: Draft Agenda for IETF 56 References: <0A11633F61BD9F40B43ABCC694004F93F18E26@zsc3c026.us.nortel.com> <3E6F6133.8020302@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: > What it means to me is that: > - we MUST support HTTP as an application protocol > - we SHOULD support more than just HTTP > - in case of a specific design conflict, HTTP-arguments MAY > have higher priority than arguments for other application > protocols Concur! We start designing an application-agnostic approach, and only if there's a conflict or if it would become far too complex, we would limit the approach to a specific application protocol(s) and would put highest priority on HTTP. But for now, I'd say we're good for moving forward with a protocol-agnostic design approach. >>[Note: Just to avoid confustion - this is *not* about the callout >>protocol, this is about the application protocl path). > > There is some interaction between the two though. For example, we need > to decide whether the callout server or OPES dispatcher/processor is > responsible for tracing (could be both too!). If callout server is > responsible, then the callout protocol may have to provide appropriate > support, especially if we decide to use out-of-bound (#2) approach. If you talk about tracing, I completely agree thatthere's interaction (and I tend to say both OPES precesor and callout server need to be involved). But for a general OPES bypass, I don't see that interaction between the application protocol and the OPES callout protocol would be required. If the user signals "no OPES, please", the callout protocol is not involved at all. > Hmm... The latter actually demonstrates another weakness of the > out-of-bound approach: it makes it difficult for callout servers to > participate in tracing and similar activities because the "end" is not > talking to them but to the proxy. On the other hand, maybe this is a > sign that callout servers must not participate? Hm... I tend to believe the callout servers must participate in tracing, since the user doesn't really know on which specific server a requested service will be executed (i.e. we assume late service binding for now). If the user now suspects that something goes wrong, (s)he better want to know what specific servers have been involved. Hm, however, this information is probably readily available on the OPES processor and the OPES processor might insert the approriate tracing info... Would that be enough? -Markus From owner-ietf-openproxy@mail.imc.org Wed Mar 12 13:46: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 NAA15900 for ; Wed, 12 Mar 2003 13:46:08 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CIFSw27176 for ietf-openproxy-bks; Wed, 12 Mar 2003 10:15:28 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CIFQ327169 for ; Wed, 12 Mar 2003 10:15:26 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h2CIFSnx060962 for ; Wed, 12 Mar 2003 11:15:28 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h2CIFSxk060961; Wed, 12 Mar 2003 11:15:28 -0700 (MST) (envelope-from rousskov) Date: Wed, 12 Mar 2003 11:15:28 -0700 (MST) From: Alex Rousskov To: OPES Group Subject: Re: Draft Agenda for IETF 56 In-Reply-To: <3E6F6B1A.6060000@mhof.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD754051EC587@zcard0k6.ca.nortel.com> <3E6F35F8.2080206@mhof.com> <3E6F6B1A.6060000@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 Wed, 12 Mar 2003, Markus Hofmann wrote: > Alex Rousskov wrote: > > You are right that this is pretty much unrelated to the callout > > protocol: calls should no go out if OPES is being bypassed. The only > > related aspect is that the callout protocol may have to pass user > > bypass instructions/preferences _if_ we want to support selective > > bypass (e.g., "bypass only this OPES/service"). I am not sure we need > > that kind of selectivity at this point. > > Isn't this kind of selectivity provided by the OPES rules? If a user > wants to use OPES services, in general, but wants to bypass specific > services, this should be reflected in the user's rules rather than > "in-band" in application messages... > > With respect to the callout protocol possibly having to pass user > bypass instructions/preferences... I assume the OPES processor > includes explicite instructions on which services to execute in the > callout protocol messages. As such, not including a specific service > implies that it won't be executed, implicitely implementing a "bypass". What I am worried about is the ability of a callout server to delegate processing to other servers (I think processing delegation is allowed in the architecture draft). Depending on how selective our rules are, it is possible that the bypass rules did not match on the original OPES dispatcher but would have matched on some remote callout server two OPES hops away. Will that server have enough information to activate bypass mode? Another way to look at this is the services granularity. Here is an example: User (or rules) say: bypass any opes:filtering/porn service for responses OPES dispatcher is configured to forward all responses to an opes:filtering/cisco-defaults service. The names do not match, so the response is forwarded to the callout server. The opes:filtering/cisco-defaults service forwards the response to opes:filtering/virus and opes:filtering/porn callout servers/services. Will the opes:filtering/porn service know to bypass? Can the answer be derived from current drafts? If not, future OPES identification/addressing work should answer this question. Alex. From owner-ietf-openproxy@mail.imc.org Wed Mar 12 14:14: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 OAA16730 for ; Wed, 12 Mar 2003 14:14:30 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CIo4A00731 for ietf-openproxy-bks; Wed, 12 Mar 2003 10:50:04 -0800 (PST) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CIo0300727 for ; Wed, 12 Mar 2003 10:50:00 -0800 (PST) Received: from oskar3 (h00a0c5e5337d.ne.client2.attbi.com[24.218.184.133]) by rwcrmhc51.attbi.com (rwcrmhc51) with SMTP id <2003031218495505100ira88e>; Wed, 12 Mar 2003 18:49:57 +0000 From: "Oskar Batuner" To: "Alex Rousskov" , "OPES Group" Subject: RE: Draft Agenda for IETF 56 Date: Wed, 12 Mar 2003 13:50:34 -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: 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 As per architecture: "The OPES architecture requires that tracing be feasible on the OPES flow per OPES processor using in-band annotation. " This requirements is essential, it provides participants with the ability to detect OPES in the course of normal interaction. It is necessary to satisfy IAB. Without in-band tracing one should undertake special query to find out if there was something done to the data. This may be not feasible - how do you know where to look without tracing info? Out-of-band component may be used to get more detailed info, but as in-band tracing is a must it has to be protocol-specific. For the tracing purposes callout server role is not that important, the essential thing is if there are changes made. OPES architecture provides for OPES service implementation on the OPES computer, and placement the application functionality on one computer or another are details that should be isolated from the other OPES-flow participants. If my application (end-user or content provider application) somehow interacts with OPES it should not depend on such details. For that matter I'd suggest that callout processor should not be able to communicate with OPES participant directly, only through OPES server. This will provide the required level of isolation. OPES processor may use callout protocol to communicate certain requests to callout processor and send responses back to the user/server. If user requests are coming in-band OPES communication with callout processor provides better reliability and simplifies synchronization, but this may depend on actual tracing specification. Oskar > -----Original Message----- > From: owner-ietf-openproxy@mail.imc.org > [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of Alex Rousskov > Sent: Wednesday, March 12, 2003 12:33 PM > To: OPES Group > Subject: Re: Draft Agenda for IETF 56 > > > > On Wed, 12 Mar 2003, Markus Hofmann wrote: > > > Just a reminder - although we've a SHOULD requirement that states > > that our solutions should be protocol agnostic (and I think we all > > agree on that), our charter is focused on HTTP (and RTP, although we > > agreed the main focus being on HTTP). > > What it means to me is that: > - we MUST support HTTP as an application protocol > - we SHOULD support more than just HTTP > - in case of a specific design conflict, HTTP-arguments MAY > have higher priority than arguments for other application > protocols > > The above is different from > - we MUST support HTTP as an application protocol > - we MUST NOT consider other application protocols > until HTTP is supported > - we SHOULD check other application protocols > after HTTP is supported > > > I'd suggest we go down a similar path as we currently do with the > > callout protocol, namely discussing required functionality and > > general design issues, first (rather than starting to discuss how > > and in which specific form to do it). I.e. what exactly do we need > > to signal (one example is the "OPES bypass"), what are the > > interaction schemes, what needs to be signaled, etc. Then we can > > discuss what's the best way to do this (e.g. "in-band" vs. > > "out-of-band") etc. > > I, obviously, agree. > > > [Note: Just to avoid confustion - this is *not* about the callout > > protocol, this is about the application protocl path). > > There is some interaction between the two though. For example, we need > to decide whether the callout server or OPES dispatcher/processor is > responsible for tracing (could be both too!). If callout server is > responsible, then the callout protocol may have to provide appropriate > support, especially if we decide to use out-of-bound (#2) approach. > > Hmm... The latter actually demonstrates another weakness of the > out-of-bound approach: it makes it difficult for callout servers to > participate in tracing and similar activities because the "end" is not > talking to them but to the proxy. On the other hand, maybe this is a > sign that callout servers must not participate? > > Alex. > > From owner-ietf-openproxy@mail.imc.org Wed Mar 12 14:32: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 OAA17546 for ; Wed, 12 Mar 2003 14:32:17 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CJ6MO01176 for ietf-openproxy-bks; Wed, 12 Mar 2003 11:06:22 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CJ6L301171 for ; Wed, 12 Mar 2003 11:06:21 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h2CJ6Nnx063216 for ; Wed, 12 Mar 2003 12:06:23 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h2CJ6N0Y063215; Wed, 12 Mar 2003 12:06:23 -0700 (MST) (envelope-from rousskov) Date: Wed, 12 Mar 2003 12:06:23 -0700 (MST) From: Alex Rousskov To: OPES Group Subject: Re: Draft Agenda for IETF 56 In-Reply-To: <3E6F7872.8060402@mhof.com> Message-ID: References: <0A11633F61BD9F40B43ABCC694004F93F18E26@zsc3c026.us.nortel.com> <3E6F6133.8020302@mhof.com> <3E6F7872.8060402@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 Wed, 12 Mar 2003, Markus Hofmann wrote: > But for a general OPES bypass, I don't see that interaction between > the application protocol and the OPES callout protocol would be > required. If the user signals "no OPES, please", the callout > protocol is not involved at all. Please see my opes:filtering/cisco-defaults example with processing delegation and related changes of the service ID. I am not sure if that is legal OPES, but it does seem to require callout server involvement. > Hm... I tend to believe the callout servers must participate in > tracing, since the user doesn't really know on which specific server > a requested service will be executed (i.e. we assume late service > binding for now). If the user now suspects that something goes > wrong, (s)he better want to know what specific servers have been > involved. Hm, however, this information is probably readily > available on the OPES processor and the OPES processor might insert > the approriate tracing info... Would that be enough? I think the answer depends on how "late" your binding is: can a callout server delegate processing to another callout server? If yes, the original OPES dispatcher/processor does not have enough information and the callout server should pass that along to the next OPES "hop". Alex. From owner-ietf-openproxy@mail.imc.org Wed Mar 12 14:42: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 OAA17953 for ; Wed, 12 Mar 2003 14:42:01 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CJI9f01517 for ietf-openproxy-bks; Wed, 12 Mar 2003 11:18:09 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CJI8301513 for ; Wed, 12 Mar 2003 11:18:08 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h2CJIAnx063460 for ; Wed, 12 Mar 2003 12:18:10 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h2CJIAvi063459; Wed, 12 Mar 2003 12:18:10 -0700 (MST) (envelope-from rousskov) Date: Wed, 12 Mar 2003 12:18:10 -0700 (MST) From: Alex Rousskov To: OPES Group Subject: RE: Draft Agenda for IETF 56 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, 12 Mar 2003, Oskar Batuner wrote: > As per architecture: > > "The OPES architecture requires that tracing be feasible > on the OPES flow per OPES processor using in-band annotation. " > > This requirements is essential, it provides participants with the > ability to detect OPES in the course of normal interaction. It is > necessary to satisfy IAB. Without in-band tracing one should undertake > special query to find out if there was something done to the data. > This may be not feasible - how do you know where to look without > tracing info? Good catch! It looks like we have an answer as far as tracing is concerned unless we want to add per-service tracing. However, we do not have an answer for communicating user preferences (e.g., bypass). You cannot make the same argument there because if a user [agent] wants to communicate OPES preferences, it has to support something new, possibly a new out-of-band protocol. > For that matter I'd suggest that callout processor should not be > able to communicate with OPES participant directly, only through > OPES server. This will provide the required level of isolation. OPES > processor may use callout protocol to communicate certain requests > to callout processor and send responses back to the user/server. On the other hand, callout servers already communicate with ends, by modifying application messages (which is their primary purpose)! Alex. From owner-ietf-openproxy@mail.imc.org Wed Mar 12 15:37: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 PAA21142 for ; Wed, 12 Mar 2003 15:37:02 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CKB9Z03078 for ietf-openproxy-bks; Wed, 12 Mar 2003 12:11:09 -0800 (PST) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CKB7303074 for ; Wed, 12 Mar 2003 12:11:08 -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.8/8.12.8) with ESMTP id h2CKB9N5005027 for ; Wed, 12 Mar 2003 15:11:09 -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 h2CKB3IL001884 for ; Wed, 12 Mar 2003 15:11:03 -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 PAA21955 for ; Wed, 12 Mar 2003 15:11:02 -0500 (EST) Message-ID: <3E6F947E.7030901@mhof.com> Date: Wed, 12 Mar 2003 15:11:42 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: Draft Agenda for IETF 56 References: <0A11633F61BD9F40B43ABCC694004F93F18E26@zsc3c026.us.nortel.com> <3E6F6133.8020302@mhof.com> <3E6F7872.8060402@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: > Please see my opes:filtering/cisco-defaults example with processing > delegation and related changes of the service ID. I am not sure if > that is legal OPES, but it does seem to require callout server > involvement. I was refering to a general "no OPES, please" signal, triggering the OPES processor to not do *any* callouts or service invokations at all, but letting the application message pass through as it would do in a non-OPES environment. In this particular case, I don't see any interaction with the OPES callout protocol. Your example is different, and I agree with your statement that this would probably require some interaction. > I think the answer depends on how "late" your binding is: can a > callout server delegate processing to another callout server? If yes, > the original OPES dispatcher/processor does not have enough > information and the callout server should pass that along to the next > OPES "hop". Agreed. -Markus From owner-ietf-openproxy@mail.imc.org Wed Mar 12 16:00: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 QAA22405 for ; Wed, 12 Mar 2003 16:00:43 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CKamt04229 for ietf-openproxy-bks; Wed, 12 Mar 2003 12:36:48 -0800 (PST) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CKai304224 for ; Wed, 12 Mar 2003 12:36:44 -0800 (PST) Received: from oskar3 (h00a0c5e5337d.ne.client2.attbi.com[24.218.184.133]) by rwcrmhc52.attbi.com (rwcrmhc52) with SMTP id <2003031220364205200rui92e>; Wed, 12 Mar 2003 20:36:42 +0000 From: "Oskar Batuner" To: "OPES Group" Subject: RE: Draft Agenda for IETF 56 Date: Wed, 12 Mar 2003 15:37:20 -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: 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 Alex Rousskov > Sent: Wednesday, March 12, 2003 2:18 PM > To: OPES Group > Subject: RE: Draft Agenda for IETF 56 > > > > On Wed, 12 Mar 2003, Oskar Batuner wrote: > > > As per architecture: > > > > "The OPES architecture requires that tracing be feasible > > on the OPES flow per OPES processor using in-band annotation. " > > > > This requirements is essential, it provides participants with the > > ability to detect OPES in the course of normal interaction. It is > > necessary to satisfy IAB. Without in-band tracing one should undertake > > special query to find out if there was something done to the data. > > This may be not feasible - how do you know where to look without > > tracing info? > > Good catch! It looks like we have an answer as far as tracing is > concerned unless we want to add per-service tracing. > > However, we do not have an answer for communicating user preferences > (e.g., bypass). You cannot make the same argument there because if a > user [agent] wants to communicate OPES preferences, it has to support > something new, possibly a new out-of-band protocol. > > > For that matter I'd suggest that callout processor should not be > > able to communicate with OPES participant directly, only through > > OPES server. This will provide the required level of isolation. OPES > > processor may use callout protocol to communicate certain requests > > to callout processor and send responses back to the user/server. > > On the other hand, callout servers already communicate with ends, by > modifying application messages (which is their primary purpose)! And they send these messages ONLY through the OPES processor. My point is that as OPES processor is the principal point of contact between OPES flow ends and the OPES application it should be the only point exposed to the end user/server. In your previous example about preferences end user does not know the OPES application composition (what functions are performed at what point), and preferences relate to the OPES application as a whole. Distribution of OPES application functions between components may even change dynamically as adaptation to the load conditions. Let's say until your OPES box is underloaded application functions are performed there, if load is too high - callout processor is invoked, if load is too high for callout processor a new one is added - either by the OPES processor or by callout processor. Certain things may break - I've already notified OPES server and one callout processor that I don't want adult contents, but now load balancer switched me to the new callout processor that does not know my preferences! If you have a single user contact point this may scale pretty well, otherwise the user has to be involved in the process in which he/she is not interested at all - function distribution between OPES components. As soon as the user is aware of OPES existence and knows the contact point (this information MUST be provided in-band) further communications may be ether in-band or out-of-band, depending on the particular protocol and application. Oskar From owner-ietf-openproxy@mail.imc.org Wed Mar 12 16:44: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 QAA24489 for ; Wed, 12 Mar 2003 16:44:18 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CLKfo06699 for ietf-openproxy-bks; Wed, 12 Mar 2003 13:20:41 -0800 (PST) Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CLKe306694 for ; Wed, 12 Mar 2003 13:20:40 -0800 (PST) Received: from f02m-11-104.d1.club-internet.fr ([212.194.22.104] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 18tDeN-0000qN-00 for ietf-openproxy@imc.org; Wed, 12 Mar 2003 13:20:36 -0800 Message-Id: <5.2.0.9.0.20030312212308.02f5c150@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 12 Mar 2003 22:01:55 +0100 To: "OPES Group" From: jfcm Subject: RE: Draft Agenda for IETF 56 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: Dear Folks, when I suggest we build a bicycle first, in keeping in mind that we want to build a car further on and to reuse parts, I probably mean the same thing as Alex except that I wish to start on something real and responding to the IAB request for a bicycle. I just did that by my own and I was immediately confronted with the need to understand what I was doing, not yet in term of protocol, but in term of architecture. 1. to have a clear model and that model to be open 2. to have a clear wording of each component from that model 3. to understand what the protocol(s) relate(s) and how the servers will work Otherwise we will have a perfect protocol we will try to patch to a model and applications. Don't you think that there are already too many protocols around? To me the main interest of the callout protocol is that it is probably to address a large number of different needs, so it should be a good candidate to replace and simplify some other protocols (plural) rather than to add/copy one and to add in complexity by superseding many others. jfc At 19:50 12/03/03, Oskar Batuner wrote: >As per architecture: > >"The OPES architecture requires that tracing be feasible > on the OPES flow per OPES processor using in-band annotation. " > >This requirements is essential, it provides participants with the >ability to detect OPES in the course of normal interaction. It is >necessary to satisfy IAB. Without in-band tracing one should undertake >special query to find out if there was something done to the data. >This may be not feasible - how do you know where to look without >tracing info? > >Out-of-band component may be used to get more detailed info, but as >in-band tracing is a must it has to be protocol-specific. For the >tracing purposes callout server role is not that important, the >essential thing is if there are changes made. OPES architecture >provides for OPES service implementation on the OPES computer, >and placement the application functionality on one computer or >another are details that should be isolated from the other >OPES-flow participants. If my application (end-user or content >provider application) somehow interacts with OPES it should not >depend on such details. > >For that matter I'd suggest that callout processor should >not be able to communicate with OPES participant directly, >only through OPES server. This >will provide the required level of isolation. OPES processor >may use callout protocol to communicate certain requests to callout >processor and send responses back to the user/server. If user >requests are coming in-band OPES communication with callout >processor provides better reliability and simplifies synchronization, >but this may depend on actual tracing specification. > >Oskar > > > > -----Original Message----- > > From: owner-ietf-openproxy@mail.imc.org > > [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of Alex Rousskov > > Sent: Wednesday, March 12, 2003 12:33 PM > > To: OPES Group > > Subject: Re: Draft Agenda for IETF 56 > > > > > > > > On Wed, 12 Mar 2003, Markus Hofmann wrote: > > > > > Just a reminder - although we've a SHOULD requirement that states > > > that our solutions should be protocol agnostic (and I think we all > > > agree on that), our charter is focused on HTTP (and RTP, although we > > > agreed the main focus being on HTTP). > > > > What it means to me is that: > > - we MUST support HTTP as an application protocol > > - we SHOULD support more than just HTTP > > - in case of a specific design conflict, HTTP-arguments MAY > > have higher priority than arguments for other application > > protocols > > > > The above is different from > > - we MUST support HTTP as an application protocol > > - we MUST NOT consider other application protocols > > until HTTP is supported > > - we SHOULD check other application protocols > > after HTTP is supported > > > > > I'd suggest we go down a similar path as we currently do with the > > > callout protocol, namely discussing required functionality and > > > general design issues, first (rather than starting to discuss how > > > and in which specific form to do it). I.e. what exactly do we need > > > to signal (one example is the "OPES bypass"), what are the > > > interaction schemes, what needs to be signaled, etc. Then we can > > > discuss what's the best way to do this (e.g. "in-band" vs. > > > "out-of-band") etc. > > > > I, obviously, agree. > > > > > [Note: Just to avoid confustion - this is *not* about the callout > > > protocol, this is about the application protocl path). > > > > There is some interaction between the two though. For example, we need > > to decide whether the callout server or OPES dispatcher/processor is > > responsible for tracing (could be both too!). If callout server is > > responsible, then the callout protocol may have to provide appropriate > > support, especially if we decide to use out-of-bound (#2) approach. > > > > Hmm... The latter actually demonstrates another weakness of the > > out-of-bound approach: it makes it difficult for callout servers to > > participate in tracing and similar activities because the "end" is not > > talking to them but to the proxy. On the other hand, maybe this is a > > sign that callout servers must not participate? > > > > Alex. > > > > > > > > >--- >Incoming mail is certified Virus Free. >Checked by AVG anti-virus system (http://www.grisoft.com). >Version: 6.0.459 / Virus Database: 258 - Release Date: 25/02/03 From owner-ietf-openproxy@mail.imc.org Wed Mar 12 17:33: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 RAA25994 for ; Wed, 12 Mar 2003 17:33:36 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CM9bq09121 for ietf-openproxy-bks; Wed, 12 Mar 2003 14:09:37 -0800 (PST) Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CM9a309115 for ; Wed, 12 Mar 2003 14:09:36 -0800 (PST) Received: from f02m-11-104.d1.club-internet.fr ([212.194.22.104] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 18tEPm-0006rc-00 for ietf-openproxy@imc.org; Wed, 12 Mar 2003 14:09:35 -0800 Message-Id: <5.2.0.9.0.20030312223131.02852b50@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 12 Mar 2003 23:05:00 +0100 To: "OPES Group" From: jfcm Subject: RE: Draft Agenda for IETF 56 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: On 21:37 12/03/03, Oskar Batuner said: >And they send these messages ONLY through the OPES processor. My point >is that as OPES processor is the principal point of contact between >OPES flow ends and the OPES application it should be the only >point exposed to the end user/server. In your previous example >about preferences end user does not know the OPES application >composition (what functions are performed at what point), and >preferences relate to the OPES application as a whole. SOS! I am lost (low IQ, old brain). I am not sure I fully grasp some of the word, and most of all their different shades. - OPES processor. - OPES application. - OPES flow ends. - OPES box - a callout processor. - one or several servers proposing OPES (services) - OPES components Sorry for the questions. I don't need examples to understand but I need logic and exact words which leads to simplicity, even to robust rusticity. At this time I understand - there is a data flow between a user and a content provider. - the user and the provider may switch roles, - they usually want to talk HTTP - between the user and the provider there is a converter made of - a filter (dispatcher) - transformers (OPES servers). - there is a protocol from the dispatcher towards the servers, however it is not clear to me if the protocol is between dispatchers acting as front end for servers or between dispatchers and servers. At some stage I understood that a property of OPES was that the user did not know they exist and that he could not relate with them. Now it appears that the HTTP flow should be transport (how?) an indication of the OPES presence, that the OPES could be opposed at the user decision? That the dispatcher could relate with the user, but not the OPES (service). Am I reading this correctly in simple layman words? If this is the case we are not anymore in the OPES field as it is not an "edge service" but a "both ends" service. IMHO the very nature of the OPES is to add a service to one end. The other end may be interoperated as part of the service, but should not decide of the service itself. If the other end co-decides, it becomes a cooperator of the OPES, and many other ends in a relation many to many may also be cooperating: we enter another model I call ONES. >Distribution of OPES application functions between components may >even change dynamically as adaptation to the load conditions. Let's say >until your OPES box is underloaded application functions are performed >there, if load is too high - callout processor is invoked, if load is >too high for callout processor a new one is added - either by the OPES >processor or by callout processor. Certain things may break - I've >already notified OPES server and one callout processor that I don't >want adult contents, but now load balancer switched me to the new >callout processor that does not know my preferences! All these things are only operation management not architecture? >If you have a single user contact point this may scale pretty well, >otherwise the user has to be involved in the process in which he/she >is not interested at all - function distribution between OPES components. > >As soon as the user is aware of OPES existence and knows the contact >point (this information MUST be provided in-band) How? >further communications >may be ether in-band or out-of-band, depending on the particular protocol >and application. True. But is that still OPES? jfc PS. Please relax: I am out for 3 days :-) From owner-ietf-openproxy@mail.imc.org Wed Mar 12 17:45: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 RAA26733 for ; Wed, 12 Mar 2003 17:45:37 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CMIHB10307 for ietf-openproxy-bks; Wed, 12 Mar 2003 14:18:17 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CMIG310301 for ; Wed, 12 Mar 2003 14:18:16 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h2CMIJnx067664 for ; Wed, 12 Mar 2003 15:18:19 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h2CMIJDa067663; Wed, 12 Mar 2003 15:18:19 -0700 (MST) (envelope-from rousskov) Date: Wed, 12 Mar 2003 15:18:18 -0700 (MST) From: Alex Rousskov To: OPES Group Subject: RE: Draft Agenda for IETF 56 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, 12 Mar 2003, Oskar Batuner wrote: > > > For that matter I'd suggest that callout processor should not be > > > able to communicate with OPES participant directly, only through > > > OPES server. This will provide the required level of isolation. OPES > > > processor may use callout protocol to communicate certain requests > > > to callout processor and send responses back to the user/server. > > > > On the other hand, callout servers already communicate with ends, by > > modifying application messages (which is their primary purpose)! > > And they send these messages ONLY through the OPES processor. My point > is that as OPES processor is the principal point of contact between > OPES flow ends and the OPES application it should be the only > point exposed to the end user/server. Two problems: - It looks like Markus (and others?) want callout servers and even services be traceable and, hence, exposed to the ends to a certain degree. We will need to get some consensus here. What is exposed to ends? If something is exposed, does it communicate with ends? If it does, what "band" is used? - If callout servers communicate with ends via application protocol (by modifying application messages), then "communication through OPES processor" does not mean that the OPES processor actually understands what is going on. The OPES processor, in this case, may be a dumb relay. I think that contradicts your intention to have "required level of isolation". Dumb relay is a poor "isolator". If we do want to make OPES processor the only point of contact and truly remove callout servers from the end-visible picture, we need to do the following, at least: ~ adjust processor->callout server interface from current "do whatever you want with this message, I will just forward the result; and please obey OPES rules (e.g., add tracing)" to "do whatever you want, tell me what you did, I may apply more processor-specific modifications based on what you did (e.g., add tracing), and I will build and forward the final result" ~ prohibit delegation of callout services from callout servers; support such delegation from OPES processor only (the callout server would have to tell OPES processor to delegate) Is that something you are after? Do you want to limit callout server role to message adaptation only and have _all_ OPES-related features to be enforced by the OPES processor? > Distribution of OPES application functions between components may > even change dynamically as adaptation to the load conditions. Yes, of course. > If you have a single user contact point this may scale pretty well, > otherwise the user has to be involved in the process in which he/she > is not interested at all - function distribution between OPES > components. The user does not have to be involved in the process if her preferences remain constant. It is the role of the OPES system to correctly react to dynamic changes within the OPES system. Are you implying that the user may have different preferences depending on the actual OPES system in use? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Wed Mar 12 18:27: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 SAA29656 for ; Wed, 12 Mar 2003 18:27:34 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CMxwf13620 for ietf-openproxy-bks; Wed, 12 Mar 2003 14:59:58 -0800 (PST) Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CMxs313615 for ; Wed, 12 Mar 2003 14:59:54 -0800 (PST) Received: from oskar3 (h00a0c5e5337d.ne.client2.attbi.com[24.218.184.133]) by rwcrmhc53.attbi.com (rwcrmhc53) with SMTP id <20030312225951053001urlme>; Wed, 12 Mar 2003 22:59:52 +0000 From: "Oskar Batuner" To: "jfcm" , "OPES Group" Subject: RE: Draft Agenda for IETF 56 Date: Wed, 12 Mar 2003 18:00:30 -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: <5.2.0.9.0.20030312223131.02852b50@mail.utel.net> 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 Please read this: http://www.ietf.org/internet-drafts/draft-ietf-opes-architecture-04.txt Most of the terms are illustrated in Figure 3: Interaction of OPES Entities, (page 8). Oskar > -----Original Message----- > From: owner-ietf-openproxy@mail.imc.org > [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of jfcm > Sent: Wednesday, March 12, 2003 5:05 PM > To: OPES Group > Subject: RE: Draft Agenda for IETF 56 > > > > On 21:37 12/03/03, Oskar Batuner said: > >And they send these messages ONLY through the OPES processor. My point > >is that as OPES processor is the principal point of contact between > >OPES flow ends and the OPES application it should be the only > >point exposed to the end user/server. In your previous example > >about preferences end user does not know the OPES application > >composition (what functions are performed at what point), and > >preferences relate to the OPES application as a whole. > > SOS! I am lost (low IQ, old brain). I am not sure I fully grasp > some of the word, and most of all their different shades. > - OPES processor. > - OPES application. > - OPES flow ends. > - OPES box > - a callout processor. > - one or several servers proposing OPES (services) > - OPES components > Sorry for the questions. I don't need examples to understand > but I need logic and exact words which leads to simplicity, > even to robust rusticity. > > At this time I understand > - there is a data flow between a user and a content provider. > - the user and the provider may switch roles, > - they usually want to talk HTTP > - between the user and the provider there is a converter > made of > - a filter (dispatcher) > - transformers (OPES servers). > - there is a protocol from the dispatcher towards the servers, > however it is not clear to me if the protocol is between > dispatchers acting as front end for servers or between > dispatchers and servers. > > At some stage I understood that a property of OPES > was that the user did not know they exist and that he > could not relate with them. Now it appears that the HTTP > flow should be transport (how?) an indication of the > OPES presence, that the OPES could be opposed at > the user decision? That the dispatcher could relate with > the user, but not the OPES (service). > > Am I reading this correctly in simple layman words? > > If this is the case we are not anymore in the OPES field > as it is not an "edge service" but a "both ends" service. > IMHO the very nature of the OPES is to add a service to > one end. The other end may be interoperated as part > of the service, but should not decide of the service itself. > > If the other end co-decides, it becomes a cooperator > of the OPES, and many other ends in a relation many > to many may also be cooperating: we enter another > model I call ONES. > > > >Distribution of OPES application functions between components may > >even change dynamically as adaptation to the load conditions. Let's say > >until your OPES box is underloaded application functions are performed > >there, if load is too high - callout processor is invoked, if load is > >too high for callout processor a new one is added - either by the OPES > >processor or by callout processor. Certain things may break - I've > >already notified OPES server and one callout processor that I don't > >want adult contents, but now load balancer switched me to the new > >callout processor that does not know my preferences! > > All these things are only operation management not architecture? > > >If you have a single user contact point this may scale pretty well, > >otherwise the user has to be involved in the process in which he/she > >is not interested at all - function distribution between OPES components. > > > >As soon as the user is aware of OPES existence and knows the contact > >point (this information MUST be provided in-band) > > How? > > >further communications > >may be ether in-band or out-of-band, depending on the particular protocol > >and application. > > True. But is that still OPES? > jfc > > PS. Please relax: I am out for 3 days :-) > From owner-ietf-openproxy@mail.imc.org Wed Mar 12 20:58: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 UAA03643 for ; Wed, 12 Mar 2003 20:58:37 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2D1aD220112 for ietf-openproxy-bks; Wed, 12 Mar 2003 17:36:13 -0800 (PST) Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2D1aB320106 for ; Wed, 12 Mar 2003 17:36:11 -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 h2D2F9io019801 for ; Wed, 12 Mar 2003 19:15:10 -0700 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h2D1aW309362; Wed, 12 Mar 2003 18:36:32 -0700 Date: Wed, 12 Mar 2003 18:36:32 -0700 Message-Id: <200303130136.h2D1aW309362@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: ietf-openproxy@imc.org In-reply-to: Yourmessage <3E6EBB00.7090902@mhof.com> Subject: security requirements for the OPES callout protocol Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I just noticed an error in the draft-ietf-opes-protocol-reqs-03.txt; in section 5.2 "hop-by-hop confidentiality", the text refers to "end-to-end encryption." It should refer to "hop-by-hop encryption", because you cannot use OPES boxes with end-to-end (consumer-provider) encryption. Hilarie From owner-ietf-openproxy@mail.imc.org Thu Mar 13 00:03:58 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 AAA08432 for ; Thu, 13 Mar 2003 00:03:56 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2D4fXp23548 for ietf-openproxy-bks; Wed, 12 Mar 2003 20:41:33 -0800 (PST) Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2D4fT323544 for ; Wed, 12 Mar 2003 20:41:29 -0800 (PST) Received: from oskar3 (h00a0c5e5337d.ne.client2.attbi.com[24.218.184.133]) by rwcrmhc53.attbi.com (rwcrmhc53) with SMTP id <2003031304412705300fgjbce>; Thu, 13 Mar 2003 04:41:27 +0000 From: "Oskar Batuner" To: "OPES Group" Subject: RE: Draft Agenda for IETF 56 Date: Wed, 12 Mar 2003 23:42:06 -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: 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 See inside. > -----Original Message----- > From: owner-ietf-openproxy@mail.imc.org > [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of Alex Rousskov > Sent: Wednesday, March 12, 2003 5:18 PM > To: OPES Group > Subject: RE: Draft Agenda for IETF 56 > > > > On Wed, 12 Mar 2003, Oskar Batuner wrote: > > > > > For that matter I'd suggest that callout processor should not be > > > > able to communicate with OPES participant directly, only through > > > > OPES server. This will provide the required level of isolation. OPES > > > > processor may use callout protocol to communicate certain requests > > > > to callout processor and send responses back to the user/server. > > > > > > On the other hand, callout servers already communicate with ends, by > > > modifying application messages (which is their primary purpose)! > > > > And they send these messages ONLY through the OPES processor. My point > > is that as OPES processor is the principal point of contact between > > OPES flow ends and the OPES application it should be the only > > point exposed to the end user/server. > > Two problems: > > - It looks like Markus (and others?) want callout servers and > even services be traceable and, hence, exposed to the ends to a > certain degree. We will need to get some consensus here. What > is exposed to ends? If something is exposed, does it communicate > with ends? If it does, what "band" is used? As far as I understand we have two-layered architecture: one layer is present in the OPES flow, another supports all out-of-band functionality prescribed by the OPES spec but specifically excluded from the OPES flow (like rules distribution). For the OPES flow (in-band is just another name for that) the only point exposed is OPES server IP (that MUST be exposed by the IAB requirements). The only way to communicate at that level is the application protocol (original or extended). In the second layer any point may be exposed, e.g. privacy policy server. It may even be unreachable to the OPES server by callout protocol: OPES entities are not required to use the callout protocol as the only method of communication. And if something is exposed - it is exposed exactly to enable the ends to communicate with it. Method of communication is determined by the role of the exposed component and the method of exposure. Does this make sense? > > - If callout servers communicate with ends via application > protocol (by modifying application messages), then > "communication through OPES processor" does not mean that the > OPES processor actually understands what is going on. The OPES > processor, in this case, may be a dumb relay. I think that > contradicts your intention to have "required level of > isolation". Dumb relay is a poor "isolator". > Let me disagree. To some degree a medical office receptionist arranging an urgent visit to any available doctor may be a good example: he/she acts as a dumb relay (does not attempt to evaluate patient's medical problem details) but still pretty well isolates patient from dealing with multiple doctors' schedules and doctors from interruptions from all the patients trying to arrange a visit. Even a dumb relay MUST understand what is going on: it MUST know that specific callout server supports all OPES requirements and just passing messages through will not result in violation of these requirements. Depending on the OPES application architecture OPES processor may or may not perform certain checks and insert certain information. But as a policy enforcement point it is responsible for implementing the policy - in cooperation with callout servers. > If we do want to make OPES processor the only point of contact > and truly remove callout servers from the end-visible picture, > we need to do the following, at least: > > ~ adjust processor->callout server interface from current > "do whatever you want with this message, I will just > forward the result; and please obey OPES rules > (e.g., add tracing)" > to > "do whatever you want, tell me what > you did, I may apply more processor-specific modifications > based on what you did (e.g., add tracing), and I will > build and forward the final result" I'm not sure we have well defined notion of what the current interface is. Here you are looking at another dimension of the problem: should the distribution of functions between OPES processor and callout server be completely deterministic (predefined for a particular application) or we provide greater flexibility by allowing some level of negotiation, as in your second option. I think it can be both ways. If function distribution is deterministic no additional support is need at the callout protocol level. Each component knows what functions it has to perform and what functions will be performed by another component. For example some tracing information can be added by any of them, component just should know in advance that it is his function, while some tracing information may be available only at the point where the transformation is actually performed. To implement your second option callout protocol should provide some support for negotiations. These additional functions may be grouped together and specified as a different level of protocol implementation. > > ~ prohibit delegation of callout services from > callout servers; support such delegation from OPES processor > only (the callout server would have to tell OPES processor > to delegate) I don't see the reason for such limitation. OPES processor is not interested in callout server architecture - is this one box, farm, grid, or hierarchy connected by callout protocol. As long as all OPES requirements are met any internal delegation is irrelevant. I think when we abandoned special requirements for cascading we in fact accepted this "black box" approach. > > Is that something you are after? Do you want to limit > callout server role to message adaptation only and have > _all_ OPES-related features to be enforced by the OPES > processor? Again, my approach is that specific distribution of functions may be left to the specific application implementation. The only important thing is to guarantee that all OPES requirements are met. Is this guarantee achieved by deterministic function distribution, what specific distribution is used in each particular case or a reliable negotiation protocol is used to establish such distribution dynamically - is irrelevant. > > > Distribution of OPES application functions between components may > > even change dynamically as adaptation to the load conditions. > > Yes, of course. > > > If you have a single user contact point this may scale pretty well, > > otherwise the user has to be involved in the process in which he/she > > is not interested at all - function distribution between OPES > > components. > > The user does not have to be involved in the process if her > preferences remain constant. It is the role of the OPES system to > correctly react to dynamic changes within the OPES system. Are you > implying that the user may have different preferences depending > on the actual OPES system in use? I imply exactly the opposite - user should have a guarantee that as soon as his/her preferences are made known to OPES they will remain in force even if system makes dynamic configuration changes. And the best way to guarantee this is to provide the user with the single communication point. In fact there may multiple communication points, but for each function there should be exactly one. If a callout processor is exposed as such point no dynamic reconfiguration is possible unless this processor is able to distribute information communicated by the user to all new system participants. Add to this redundancy and (transparent) fallback requirements and you'll see the picture behind my reasoning. Oskar From owner-ietf-openproxy@mail.imc.org Thu Mar 13 00:36: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 AAA09078 for ; Thu, 13 Mar 2003 00:36:22 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2D5Fs124030 for ietf-openproxy-bks; Wed, 12 Mar 2003 21:15:54 -0800 (PST) Received: from mail.mailsnare.net (mail.mailsnare.net [216.127.80.39]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2D5Fr324026 for ; Wed, 12 Mar 2003 21:15:53 -0800 (PST) Received: from 127.0.0.1 (localhost.localdomain [127.0.0.1]) by dummy.domain.name (Postfix) with SMTP id 72B9D690C6A for ; Thu, 13 Mar 2003 05:15:52 +0000 (UCT) Received: from mhof.com (unknown [135.104.20.67]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.mailsnare.net (Postfix) with ESMTP id F22AD690BD1 for ; Thu, 13 Mar 2003 05:15:51 +0000 (UCT) Message-ID: <3E701406.9020308@mhof.com> Date: Thu, 13 Mar 2003 00:15:50 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us MIME-Version: 1.0 To: OPES Group Subject: Re: Draft Agenda for IETF 56 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: > - It looks like Markus (and others?) want callout servers and > even services be traceable and, hence, exposed to the ends to a > certain degree. Amongst others, this came from IAB considerations 3.1 and 3.2 in RFC3238, which require that the ends can detect OPES actions. In particular, a user/end must be able to respond to OPES actions that "are deemed inappropriate" by herself - as such, all OPES actions need to be exposed to the end/user. > We will need to get some consensus here. What > is exposed to ends? I would assume that all services that have been executed on a message are identified and exposed - or that a reference is given at which the end-user can query which services have been executed. > If something is exposed, does it communicate > with ends? If it does, what "band" is used? Could be a combination of in-band and out-of band. For example, in-band annotations could be used to expose a reference to the end user (e.g. a URL), at which the end-user can retrieve additional information about the services (and servers?) that have been executed on the message using a separate (out-of-band) mechanism. Might remind of email: Email uses in-band annotations (i.e. the Received: headers) to let the user know which mail servers have been involved in handling an email. The user can then use out-of-band mechanisms to contact the postmaster of any mail server for further info... -Markus From owner-ietf-openproxy@mail.imc.org Thu Mar 13 00:52: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 AAA09634 for ; Thu, 13 Mar 2003 00:52:53 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2D5VM424348 for ietf-openproxy-bks; Wed, 12 Mar 2003 21:31:22 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2D5VK324344 for ; Wed, 12 Mar 2003 21:31:20 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h2D5VOnx077666 for ; Wed, 12 Mar 2003 22:31:24 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h2D5VOIO077665; Wed, 12 Mar 2003 22:31:24 -0700 (MST) (envelope-from rousskov) Date: Wed, 12 Mar 2003 22:31:24 -0700 (MST) From: Alex Rousskov To: OPES Group Subject: RE: Draft Agenda for IETF 56 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 we are in agreement here. Perhaps the original wording that caused this thread was not precise enough, or I misinterpreted some implications. I agree with your key points, in their current rendering. When we work on OPES documents detailing tracing and bypass, we need to be especially clear what is exposed to the ends. We know that OPES processor IP must be exposed and addressable. We also may want to be able to trace what services have been applied. The latter would make service IDs exposed, but not directly addressable for the ends. We need to carefully document these destinctions. Alex. On Wed, 12 Mar 2003, Oskar Batuner wrote: > > On Wed, 12 Mar 2003, Oskar Batuner wrote: > > > > > > > For that matter I'd suggest that callout processor should not be > > > > > able to communicate with OPES participant directly, only through > > > > > OPES server. This will provide the required level of isolation. OPES > > > > > processor may use callout protocol to communicate certain requests > > > > > to callout processor and send responses back to the user/server. > > > > > > > > On the other hand, callout servers already communicate with ends, by > > > > modifying application messages (which is their primary purpose)! > > > > > > And they send these messages ONLY through the OPES processor. My point > > > is that as OPES processor is the principal point of contact between > > > OPES flow ends and the OPES application it should be the only > > > point exposed to the end user/server. > > > > Two problems: > > > > - It looks like Markus (and others?) want callout servers and > > even services be traceable and, hence, exposed to the ends to a > > certain degree. We will need to get some consensus here. What > > is exposed to ends? If something is exposed, does it communicate > > with ends? If it does, what "band" is used? > > As far as I understand we have two-layered architecture: one layer is > present in the OPES flow, another supports all out-of-band functionality > prescribed by the OPES spec but specifically excluded from the OPES > flow (like rules distribution). > > For the OPES flow (in-band is just another name for that) the only point > exposed is OPES server IP (that MUST be exposed by the IAB requirements). > The only way to communicate at that level is the application protocol > (original or extended). In the second layer any point may be exposed, > e.g. privacy policy server. It may even be unreachable to the OPES > server by callout protocol: OPES entities are not required to use > the callout protocol as the only method of communication. > > And if something is exposed - it is exposed exactly to enable the ends to > communicate with it. Method of communication is determined by the role of > the exposed component and the method of exposure. > > Does this make sense? > > > > > - If callout servers communicate with ends via application > > protocol (by modifying application messages), then > > "communication through OPES processor" does not mean that the > > OPES processor actually understands what is going on. The OPES > > processor, in this case, may be a dumb relay. I think that > > contradicts your intention to have "required level of > > isolation". Dumb relay is a poor "isolator". > > > > Let me disagree. To some degree a medical office receptionist arranging > an urgent visit to any available doctor may be a good example: he/she > acts as a dumb relay (does not attempt to evaluate patient's medical > problem details) but still pretty well isolates patient from dealing > with multiple doctors' schedules and doctors from interruptions from > all the patients trying to arrange a visit. > > Even a dumb relay MUST understand what is going on: it MUST know that > specific callout server supports all OPES requirements and just passing > messages through will not result in violation of these requirements. > > Depending on the OPES application architecture OPES processor may > or may not perform certain checks and insert certain information. > But as a policy enforcement point it is responsible for implementing > the policy - in cooperation with callout servers. > > > If we do want to make OPES processor the only point of contact > > and truly remove callout servers from the end-visible picture, > > we need to do the following, at least: > > > > ~ adjust processor->callout server interface from current > > "do whatever you want with this message, I will just > > forward the result; and please obey OPES rules > > (e.g., add tracing)" > > to > > "do whatever you want, tell me what > > you did, I may apply more processor-specific modifications > > based on what you did (e.g., add tracing), and I will > > build and forward the final result" > > I'm not sure we have well defined notion of what the current interface is. > Here you are looking at another dimension of the problem: should the > distribution of functions between OPES processor and callout server > be completely deterministic (predefined for a particular application) > or we provide greater flexibility by allowing some level of > negotiation, as in your second option. > > I think it can be both ways. If function distribution is deterministic > no additional support is need at the callout protocol level. Each > component knows what functions it has to perform and what functions > will be performed by another component. For example some tracing > information can be added by any of them, component just > should know in advance that it is his function, while some > tracing information may be available only at the point where > the transformation is actually performed. > > To implement your second option callout protocol should provide > some support for negotiations. These additional functions may be > grouped together and specified as a different level of protocol > implementation. > > > > > ~ prohibit delegation of callout services from > > callout servers; support such delegation from OPES processor > > only (the callout server would have to tell OPES processor > > to delegate) > > I don't see the reason for such limitation. OPES processor is not > interested in callout server architecture - is this one box, farm, > grid, or hierarchy connected by callout protocol. As long as all > OPES requirements are met any internal delegation is irrelevant. > I think when we abandoned special requirements for cascading > we in fact accepted this "black box" approach. > > > > > Is that something you are after? Do you want to limit > > callout server role to message adaptation only and have > > _all_ OPES-related features to be enforced by the OPES > > processor? > > Again, my approach is that specific distribution of functions may be > left to the specific application implementation. The only important > thing is to guarantee that all OPES requirements are met. Is this > guarantee achieved by deterministic function distribution, what > specific distribution is used in each particular case or a > reliable negotiation protocol is used to establish such > distribution dynamically - is irrelevant. > > > > > > Distribution of OPES application functions between components may > > > even change dynamically as adaptation to the load conditions. > > > > Yes, of course. > > > > > If you have a single user contact point this may scale pretty well, > > > otherwise the user has to be involved in the process in which he/she > > > is not interested at all - function distribution between OPES > > > components. > > > > The user does not have to be involved in the process if her > > preferences remain constant. It is the role of the OPES system to > > correctly react to dynamic changes within the OPES system. Are you > > implying that the user may have different preferences depending > > on the actual OPES system in use? > > I imply exactly the opposite - user should have a guarantee that as > soon as his/her preferences are made known to OPES they will remain > in force even if system makes dynamic configuration changes. And the > best way to guarantee this is to provide the user with the single > communication point. In fact there may multiple communication points, > but for each function there should be exactly one. If a callout > processor is exposed as such point no dynamic reconfiguration is > possible unless this processor is able to distribute information > communicated by the user to all new system participants. Add to this > redundancy and (transparent) fallback requirements and you'll see the > picture behind my reasoning. > > Oskar > > From owner-ietf-openproxy@mail.imc.org Thu Mar 13 01:06: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 BAA09813 for ; Thu, 13 Mar 2003 01:06:27 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2D5lJ724646 for ietf-openproxy-bks; Wed, 12 Mar 2003 21:47:19 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2D5lI324642 for ; Wed, 12 Mar 2003 21:47:18 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h2D5lMnx078034 for ; Wed, 12 Mar 2003 22:47:22 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h2D5lMPv078033; Wed, 12 Mar 2003 22:47:22 -0700 (MST) (envelope-from rousskov) Date: Wed, 12 Mar 2003 22:47:22 -0700 (MST) From: Alex Rousskov To: OPES Group Subject: Re: Draft Agenda for IETF 56 In-Reply-To: <000b01c2e90b$b74bb7a0$b9348c2f@desktop> Message-ID: References: <000b01c2e90b$b74bb7a0$b9348c2f@desktop> 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, 12 Mar 2003, Reinaldo wrote: > 1 - Is there anybody here that thinks the end points should talk to > the callout server directly? Or know of its existence (apart from > tracing/events)....I didn't hear anybody expressing this opinion. It > seems the the consensus is that the end points only talk to the OPES > processor. I think the main problem is with things like bypass, not tracing, but please read on. > I still hold that the opes processor do whatever it needs to > honor a service request. If it use a callout server, does the > processing itself, use the callout server for Bob, but not for Jane, > does not matter, as long as you get the proper tracing messages if > you want to/something goes wrong. It's just a black box from the end > point perspective. I sense a terminology conflict here. If something is a black box, it can be only bypassed as a whole, and there can be only one trace entry (black box #7) per black box. OPES users may need more granularity, up to the services level. Markus suggested that services should be traceable and provides good arguments in support of that requirement. I noted that once services are traceable (hence known) some users may want to bypass one service but not another (e.g., filter viruses but not porn). Overall this makes the black box analogy inappropriate. What we seem to be dealing with is a "semi-transparent" OPES box. The ends are able to see/address the OPES processor and are also able to see (but not address directly) OPES services. Do you agree that users may have service-specific (not just OPES box-specific) preferences? Or do we provide tracing without any OPES-specific way to use the information? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Thu Mar 13 06:37: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 GAA27129 for ; Thu, 13 Mar 2003 06:37:26 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2DBDo901902 for ietf-openproxy-bks; Thu, 13 Mar 2003 03:13:50 -0800 (PST) Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DBDn301895 for ; Thu, 13 Mar 2003 03:13:49 -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 h2DBDOh25438; Thu, 13 Mar 2003 06:13:24 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Mar 2003 06:13:24 -0500 Message-ID: <87609AFB433BD5118D5E0002A52CD754051ECE69@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Alex Rousskov , OPES Group Subject: RE: Draft Agenda for IETF 56 Date: Thu, 13 Mar 2003 06:13:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E951.90079416" 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_01C2E951.90079416 Content-Type: text/plain hi, see inline, Abbie > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Thursday, March 13, 2003 12:47 AM > To: OPES Group > Subject: Re: Draft Agenda for IETF 56 > > SNIP > Do you agree that users may have service-specific (not just OPES > box-specific) preferences? Or do we provide tracing without > any OPES-specific way to use the information? > > Thanks, > > Alex. > Alex, I agree that users may have service-specific preferences. How these will be indicated. (Are we going to have the concept of a session, are the OPES rules static per session (for a user), can we have dynamic rules, etc..). If OPES is used as a personalization engine (please see http://www.ietf.org/internet-drafts/draft-barbir-opes-fsp-03.txt, http://www.ietf.org/internet-drafts/draft-barbir-opes-spcs-03.txt) dynamic rules will be needed. Dynamic can mean that a subset of the overall rules can be assigned to a given OPES Flow at a given time (per user basically). In some scenarios the OPES providers can provide the service as a package, then the user may only have access to the package as a whole. Abbie ------_=_NextPart_001_01C2E951.90079416 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Draft Agenda for IETF 56

hi,
see inline,

Abbie


> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Thursday, March 13, 2003 12:47 AM
> To: OPES Group
> Subject: Re: Draft Agenda for IETF 56
>
>

SNIP

> Do you agree that users may have = service-specific (not just OPES
> box-specific) preferences? Or do we provide = tracing without
> any OPES-specific way to use the = information?
>
> Thanks,
>
> Alex.
>

Alex,

I agree that users may have service-specific = preferences. How these will be indicated. (Are we going to have the = concept of a session, are the OPES rules static per session (for a = user), can we have dynamic rules, etc..). If OPES is used as a = personalization engine (please see http://www.ietf.org/internet-drafts/draft-barbir-opes-= fsp-03.txt, http://www.ietf.org/internet-drafts/draft-barbir-opes-= spcs-03.txt) dynamic rules will be needed. Dynamic can mean that a = subset of the overall rules can be assigned to a given OPES Flow at a = given time (per user basically).

In some scenarios the OPES providers can provide the = service as a package, then the user may only have access to the package = as a whole.

Abbie
















------_=_NextPart_001_01C2E951.90079416-- From owner-ietf-openproxy@mail.imc.org Thu Mar 13 08:55: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 IAA00528 for ; Thu, 13 Mar 2003 08:55:53 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2DDSIR10526 for ietf-openproxy-bks; Thu, 13 Mar 2003 05:28:18 -0800 (PST) Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DDSG310521 for ; Thu, 13 Mar 2003 05:28:17 -0800 (PST) Received: from f14v-7-132.d1.club-internet.fr ([212.195.190.132] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 18tSkp-0001jt-00; Thu, 13 Mar 2003 05:28:15 -0800 Message-Id: <5.2.0.9.0.20030313141738.04231b20@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 13 Mar 2003 14:19:44 +0100 To: "Oskar Batuner" , "OPES Group" From: jfcm Subject: RE: Draft Agenda for IETF 56 In-Reply-To: References: <5.2.0.9.0.20030312223131.02852b50@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 00:00 13/03/03, Oskar Batuner wrote: >Most of the terms are illustrated in Figure 3: Interaction of OPES Entities, >(page 8). Dear Oskar, my point is here: - "most": I would like we could say "all" - "illustrated" I would like we could say "defined" - "draft" I would like to say we have a consensus As long as there is no consensus - on the building blocks - on what they are supposed to do we wind up with interesting but unclear debate. We had a look now at the whole thing. Time IMO has come to work, step by step. jfc From owner-ietf-openproxy@mail.imc.org Thu Mar 13 12:01: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 MAA08808 for ; Thu, 13 Mar 2003 12:01:36 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2DGTMv21805 for ietf-openproxy-bks; Thu, 13 Mar 2003 08:29:22 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DGTK321801 for ; Thu, 13 Mar 2003 08:29:20 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h2DGTMnx093029 for ; Thu, 13 Mar 2003 09:29:22 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h2DGTMSK093028; Thu, 13 Mar 2003 09:29:22 -0700 (MST) (envelope-from rousskov) Date: Thu, 13 Mar 2003 09:29:21 -0700 (MST) From: Alex Rousskov To: OPES Group Subject: Re: Draft Agenda for IETF 56 In-Reply-To: <007a01c2e930$d43f85b0$b9348c2f@desktop> Message-ID: References: <000b01c2e90b$b74bb7a0$b9348c2f@desktop> <007a01c2e930$d43f85b0$b9348c2f@desktop> 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, 13 Mar 2003, Reinaldo wrote: > it's a black box in regards of the services it provides, not the > tracing/events. Everytime you access a web page you do not get a > list of all the routers in your path. Actually, I do from HTTP point of view! I get a list of all proxies in the Via: header. > But you can use a traceroute or maybe get an ICMP type/code back to > let you know of some error. That does not count for many reasons. For example, the traceroute output may have nothing to do with how my HTTP transaction was routed. This is not only out-of-band, but is also out-of-sync. But this is just a minor terminology disagreement. This thread has clarified that we do expect individual services to be traceable and that we may want ends to be able to bypass them. The latter is not required for a fully functional OPES system though. Alex. From owner-ietf-openproxy@mail.imc.org Thu Mar 13 12:29: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 MAA09615 for ; Thu, 13 Mar 2003 12:29:03 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2DGu8J22621 for ietf-openproxy-bks; Thu, 13 Mar 2003 08:56:08 -0800 (PST) Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DGu6322616 for ; Thu, 13 Mar 2003 08:56:06 -0800 (PST) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2DGttq26374; Thu, 13 Mar 2003 08:55:55 -0800 (PST) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1LW2X5N5>; Thu, 13 Mar 2003 08:55:55 -0800 Message-ID: <0A11633F61BD9F40B43ABCC694004F93F18E31@zsc3c026.us.nortel.com> From: "Reinaldo Penno" To: "'Alex Rousskov'" , OPES Group Subject: RE: Draft Agenda for IETF 56 Date: Thu, 13 Mar 2003 08:55:54 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E981.6940E9B0" 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_01C2E981.6940E9B0 Content-Type: text/plain > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Thursday, March 13, 2003 11:29 AM > To: OPES Group > Subject: Re: Draft Agenda for IETF 56 > > > > On Thu, 13 Mar 2003, Reinaldo wrote: > > > it's a black box in regards of the services it provides, not the > > tracing/events. Everytime you access a web page you do not > get a list > > of all the routers in your path. > > Actually, I do from HTTP point of view! I get a list of all > proxies in the Via: header. Only if you are addressing it directly, and that's the point of the discussion. > > > But you can use a traceroute or maybe get an ICMP type/code back to > > let you know of some error. > > That does not count for many reasons. For example, the > traceroute output may have nothing to do with how my HTTP > transaction was routed. This is not only out-of-band, but is > also out-of-sync. > > > But this is just a minor terminology disagreement. This > thread has clarified that we do expect individual services to > be traceable and that we may want ends to be able to bypass > them. The latter is not required for a fully functional OPES > system though. > > Alex. > > ------_=_NextPart_001_01C2E981.6940E9B0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Draft Agenda for IETF 56

> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Thursday, March 13, 2003 11:29 AM
> To: OPES Group
> Subject: Re: Draft Agenda for IETF 56
>
>
>
> On Thu, 13 Mar 2003, Reinaldo wrote:
>
> > it's a black box in regards of the = services it provides, not the
> > tracing/events. Everytime you access a web = page you do not
> get a list
> > of all the routers in your path.
>
> Actually, I do from HTTP point of view! I get a = list of all
> proxies in the Via: header.

Only if you are addressing it directly, and that's = the point of the discussion.

>
> > But you can use a traceroute or maybe get = an ICMP type/code back to
> > let you know of some error.
>
> That does not count for many reasons. For = example, the
> traceroute output may have nothing to do with = how my HTTP
> transaction was routed. This is not only = out-of-band, but is
> also out-of-sync.
>
>
> But this is just a minor terminology = disagreement. This
> thread has clarified that we do expect = individual services to
> be traceable and that we may want ends to be = able to bypass
> them. The latter is not required for a fully = functional OPES
> system though.
>
> Alex.
>
>

------_=_NextPart_001_01C2E981.6940E9B0-- From owner-ietf-openproxy@mail.imc.org Fri Mar 14 10:31: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 KAA29289 for ; Fri, 14 Mar 2003 10:31:34 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2EF6h815466 for ietf-openproxy-bks; Fri, 14 Mar 2003 07:06:43 -0800 (PST) Received: from zoe.office.snowshore.com (goalie.snowshore.com [216.57.133.4]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2EF6gg15458 for ; Fri, 14 Mar 2003 07:06:42 -0800 (PST) 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: Example of SMTP Fan-Out Date: Fri, 14 Mar 2003 10:08:48 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D2488E0@zoe.office.snowshore.com> Thread-Topic: Example of SMTP Fan-Out Thread-Index: AcLp0aEmP1hgyLq1TOq0EMjAwdWsLg== From: "Eric Burger" To: "IETF OPES (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h2EF6gg15461 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Here is a proposal from the FAX work group. It may be relevant to the question of what SMTP fan-out looks like. In addition, it shows a protocol that allows the definition of the function (translate) to be different from the function parameters. draft-fax-esmtp-conneg-06.txt From owner-ietf-openproxy@mail.imc.org Mon Mar 17 01:57:27 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 BAA23118 for ; Mon, 17 Mar 2003 01:57:25 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2H6Ybf14468 for ietf-openproxy-bks; Sun, 16 Mar 2003 22:34:37 -0800 (PST) Received: from server2.fastmail.fm (ny2.fastmail.fm [66.111.4.3]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2H6Yag14464 for ; Sun, 16 Mar 2003 22:34:36 -0800 (PST) Received: from www.fastmail.fm (server1.internal [10.202.2.132]) by fastmail.fm (Postfix) with ESMTP id A8C0441B69; Mon, 17 Mar 2003 01:34:39 -0500 (EST) Received: from 127.0.0.1 ([127.0.0.1] helo=www.fastmail.fm) by fastmail.fm with SMTP; Mon, 17 Mar 2003 01:34:39 -0500 X-Mail-from: markus@mhof.com X-Spam-score: 0 X-Epoch: 1047882879 X-Sasl-enc: O7Q2qZTPolUNdpIIxBL/SA Received: from mhof.com (unknown [130.129.129.178]) by www.fastmail.fm (Postfix) with ESMTP id D9C78380C; Mon, 17 Mar 2003 01:34:38 -0500 (EST) Message-ID: <3E754A6A.5090302@mhof.com> Date: Sun, 16 Mar 2003 23:09:14 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openproxy@imc.org Subject: Re: OPES protocol, pre-draft References: <72992B39BBD9294BB636A960E89AE02E50C120@hermes.webwasher.com> In-Reply-To: <72992B39BBD9294BB636A960E89AE02E50C120@hermes.webwasher.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Please apologize my late reply, but this just came to mind when catching-up with all the emails after coming back from vacation and reading through them for a second time on the plane... Martin Stecher wrote: > Example 2: > Callout server analyzes beginning of application message and detects > that it is not interested in this app. message: > > A. Traditional approach, ICAP/1.0 like with multiple preview > 0. C: Start of app. message 1 > 1. C: Here is preview chunk 1 > 2. S: Need another preview chunk > 3. C: Here is preview chunk 2 > 4. S: Not interested (204 resp.) > 5. C: Start of app. message 2 > > B. Proposed OPES protocol > 0. C: Start of app. message 1 > 1. C: Chunk 1 of data S: Start of app. message 1 > 2. C: Chunk 2 of data > 3. C: Chunk 3 of data S: Not interested > 4. C: Chunk 4 of data > 5. C: Start of app. message 2 > > In this case B sent more data and data chunks 3 and 4 will be ignored > by the callout server. This might be obvious, but please allow me to add the following for clarification only... Chunks 3 and 4 can only be ignored (i.e. discarded) by the callout server if the OPES processor has sent them with the [copied] flag set in the respective message(s). If the [copied] flag was not set, the callout server must not ignore chunk 3 and 4, but simply copy/send them back to the OPES processor. Obviously, this can be done without further processing (i.e. servicing), but they still need to be sent back, since the OPES processor might no longer have a copy of these chunks. Note, that this is true even if chunks 1 and 2 were sent with the [copied] flag set. Thanks, Markus From owner-ietf-openproxy@mail.imc.org Mon Mar 17 08:11: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 IAA12619 for ; Mon, 17 Mar 2003 08:11:47 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2HCnOW28513 for ietf-openproxy-bks; Mon, 17 Mar 2003 04:49:24 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2HCnNg28507 for ; Mon, 17 Mar 2003 04:49:23 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h2HCnNnx027733 for ; Mon, 17 Mar 2003 05:49:23 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h2HCnNsY027732; Mon, 17 Mar 2003 05:49:23 -0700 (MST) (envelope-from rousskov) Date: Mon, 17 Mar 2003 05:49:23 -0700 (MST) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: OPES protocol, pre-draft In-Reply-To: <3E754A6A.5090302@mhof.com> Message-ID: References: <72992B39BBD9294BB636A960E89AE02E50C120@hermes.webwasher.com> <3E754A6A.5090302@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: Markus, We probably need a "sticky" [copied] flag meaning "I am going to have a copy of every byte from now on, until further notice". This way the callout server can remove itself from the loop earlier. Thanks, Alex. On Sun, 16 Mar 2003, Markus Hofmann wrote: > > Please apologize my late reply, but this just came to mind when > catching-up with all the emails after coming back from vacation and > reading through them for a second time on the plane... > > > Martin Stecher wrote: > > Example 2: > > Callout server analyzes beginning of application message and detects > > that it is not interested in this app. message: > > > > A. Traditional approach, ICAP/1.0 like with multiple preview > > 0. C: Start of app. message 1 > > 1. C: Here is preview chunk 1 > > 2. S: Need another preview chunk > > 3. C: Here is preview chunk 2 > > 4. S: Not interested (204 resp.) > > 5. C: Start of app. message 2 > > > > B. Proposed OPES protocol > > 0. C: Start of app. message 1 > > 1. C: Chunk 1 of data S: Start of app. message 1 > > 2. C: Chunk 2 of data > > 3. C: Chunk 3 of data S: Not interested > > 4. C: Chunk 4 of data > > 5. C: Start of app. message 2 > > > > In this case B sent more data and data chunks 3 and 4 will be ignored > > by the callout server. > > This might be obvious, but please allow me to add the following for > clarification only... Chunks 3 and 4 can only be ignored (i.e. > discarded) by the callout server if the OPES processor has sent them > with the [copied] flag set in the respective size [copied]> message(s). If the [copied] flag was not set, the > callout server must not ignore chunk 3 and 4, but simply copy/send > them back to the OPES processor. Obviously, this can be done without > further processing (i.e. servicing), but they still need to be sent > back, since the OPES processor might no longer have a copy of these > chunks. Note, that this is true even if chunks 1 and 2 were sent with > the [copied] flag set. > > Thanks, > Markus > > > From owner-ietf-openproxy@mail.imc.org Mon Mar 17 11: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 LAA19236 for ; Mon, 17 Mar 2003 11:32:15 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2HG7iR14597 for ietf-openproxy-bks; Mon, 17 Mar 2003 08:07:44 -0800 (PST) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2HG7eg14585 for ; Mon, 17 Mar 2003 08:07:40 -0800 (PST) Received: from oskar3 (h00a0c5e5337d.ne.client2.attbi.com[24.218.184.133]) by sccrmhc03.attbi.com (sccrmhc03) with SMTP id <2003031716073600300l1d4te>; Mon, 17 Mar 2003 16:07:37 +0000 From: "Oskar Batuner" To: "Alex Rousskov" , Subject: RE: OPES protocol, pre-draft Date: Mon, 17 Mar 2003 11:08:17 -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: 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 Let me propose a simplification of the protocol: remove [copied] flag and make this behavior compulsory. Reasons: 1. The main goal of chunks is to reduce network traffic. OPES server implementation that discards message chunk by chunk as soon as one is send to callout server does not look a good idea. Even if call starts before the complete message is received by the OPES processor it should be able to assemble the complete message anyway. In asynchronous system OPES processor can not rely on ability of the callout processor to keep pace with the speed of incoming traffic. 2.Reliability. If the original message is discarded by OPES processor before transaction with the callout processor is completed callout processor failure (including connection outage) forces OPES processor to fail on this message, while preserved copy provides multiple ways for recovery - default action on callout server unavailable, repeat request to a different callout server. And the message was already there, savings from premature discarding are very small. 3. catch 22: if message processing is simple and anticipated processing time is small - so are the savings from message discarding. If anticipated processing time is significant - savings may be bigger but so are the risks related to failure and needs for reliable recovery. Same thing with the message size - for small messages savings are negligible, for large messages savings from ability to continue without returning message body (e.g. in virus checking) out weight savings from message discarding. 4. For streaming data policy may be different but still predefined: for live streaming data should me discarded (or alternative action taken) if delay is too long, for preload situation is the same as with large message. All of this shows that benefits of controlled discarding are too small to justify complications in the protocol and system implementation. My .10 Oskar > -----Original Message----- > From: owner-ietf-openproxy@mail.imc.org > [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of Alex Rousskov > Sent: Monday, March 17, 2003 7:49 AM > To: ietf-openproxy@imc.org > Subject: Re: OPES protocol, pre-draft > > > > Markus, > > We probably need a "sticky" [copied] flag meaning "I am going > to have a copy of every byte from now on, until further notice". This > way the callout server can remove itself from the loop earlier. > > Thanks, > > Alex. > > > On Sun, 16 Mar 2003, Markus Hofmann wrote: > > > > > Please apologize my late reply, but this just came to mind when > > catching-up with all the emails after coming back from vacation and > > reading through them for a second time on the plane... > > > > > > Martin Stecher wrote: > > > Example 2: > > > Callout server analyzes beginning of application message and detects > > > that it is not interested in this app. message: > > > > > > A. Traditional approach, ICAP/1.0 like with multiple preview > > > 0. C: Start of app. message 1 > > > 1. C: Here is preview chunk 1 > > > 2. S: Need another preview chunk > > > 3. C: Here is preview chunk 2 > > > 4. S: Not interested (204 resp.) > > > 5. C: Start of app. message 2 > > > > > > B. Proposed OPES protocol > > > 0. C: Start of app. message 1 > > > 1. C: Chunk 1 of data S: Start of app. message 1 > > > 2. C: Chunk 2 of data > > > 3. C: Chunk 3 of data S: Not interested > > > 4. C: Chunk 4 of data > > > 5. C: Start of app. message 2 > > > > > > In this case B sent more data and data chunks 3 and 4 will be ignored > > > by the callout server. > > > > This might be obvious, but please allow me to add the following for > > clarification only... Chunks 3 and 4 can only be ignored (i.e. > > discarded) by the callout server if the OPES processor has sent them > > with the [copied] flag set in the respective > size [copied]> message(s). If the [copied] flag was not set, the > > callout server must not ignore chunk 3 and 4, but simply copy/send > > them back to the OPES processor. Obviously, this can be done without > > further processing (i.e. servicing), but they still need to be sent > > back, since the OPES processor might no longer have a copy of these > > chunks. Note, that this is true even if chunks 1 and 2 were sent with > > the [copied] flag set. > > > > Thanks, > > Markus > > > > > > > From owner-ietf-openproxy@mail.imc.org Mon Mar 17 13:12:13 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 NAA23199 for ; Mon, 17 Mar 2003 13:12:12 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2HHkS420793 for ietf-openproxy-bks; Mon, 17 Mar 2003 09:46:28 -0800 (PST) Received: from server2.fastmail.fm (ny2.fastmail.fm [66.111.4.3]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2HHkRg20789 for ; Mon, 17 Mar 2003 09:46:27 -0800 (PST) Received: from www.fastmail.fm (server1.internal [10.202.2.132]) by fastmail.fm (Postfix) with ESMTP id 302386D1F for ; Mon, 17 Mar 2003 12:46:27 -0500 (EST) Received: from 127.0.0.1 ([127.0.0.1] helo=www.fastmail.fm) by fastmail.fm with SMTP; Mon, 17 Mar 2003 12:46:27 -0500 X-Epoch: 1047923187 X-Sasl-enc: pmO0p/eZRN0vwQLXWwxD8Q Received: from mhof.com (unknown [135.104.20.74]) by www.fastmail.fm (Postfix) with ESMTP id 9B3562233D for ; Mon, 17 Mar 2003 12:46:25 -0500 (EST) Message-ID: <3E760A36.3010007@mhof.com> Date: Mon, 17 Mar 2003 12:47:34 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openproxy@imc.org Subject: Re: OPES protocol, pre-draft References: <72992B39BBD9294BB636A960E89AE02E50C120@hermes.webwasher.com> <3E754A6A.5090302@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, > We probably need a "sticky" [copied] flag meaning "I am going > to have a copy of every byte from now on, until further notice". This > way the callout server can remove itself from the loop earlier. The same can be achieved by simply setting the [copied] flag in any outgoing message from now on, couldn't it? This way we wouldn't need yet another flag, and also we wouldn't need a way to overwrite a "sticky" flag that was previously set (see your "until further notice" remark above"). Thanks, Markus From owner-ietf-openproxy@mail.imc.org Mon Mar 17 13:26: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 NAA23701 for ; Mon, 17 Mar 2003 13:26:39 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2HI1Oc21629 for ietf-openproxy-bks; Mon, 17 Mar 2003 10:01:24 -0800 (PST) Received: from server2.fastmail.fm (ny2.fastmail.fm [66.111.4.3]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2HI1Ng21624 for ; Mon, 17 Mar 2003 10:01:23 -0800 (PST) Received: from www.fastmail.fm (server1.internal [10.202.2.132]) by fastmail.fm (Postfix) with ESMTP id 5715E2275 for ; Mon, 17 Mar 2003 13:01:23 -0500 (EST) Received: from 127.0.0.1 ([127.0.0.1] helo=www.fastmail.fm) by fastmail.fm with SMTP; Mon, 17 Mar 2003 13:01:23 -0500 X-Epoch: 1047924083 X-Sasl-enc: x6vbUuZItXmR68ulRmY0Fg Received: from mhof.com (unknown [135.104.20.74]) by www.fastmail.fm (Postfix) with ESMTP id 8945D16F7F for ; Mon, 17 Mar 2003 13:01:22 -0500 (EST) Message-ID: <3E760DB7.2040603@mhof.com> Date: Mon, 17 Mar 2003 13:02:31 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openproxy@imc.org Subject: Re: OPES protocol, pre-draft 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, > Let me propose a simplification of the protocol: remove > [copied] flag and make this behavior compulsory. > > Reasons: > > 1. The main goal of chunks is to reduce network traffic. OPES server You probably mean "OPES processor". Let's try to stick to the terminology we've in the existing documents, might help avoiding misunderstandings. > implementation that discards message chunk by chunk as soon as one > is send to callout server does not look a good idea. Even if call > starts before the complete message is received by the OPES processor > it should be able to assemble the complete message anyway. This might require the OPES processor to possibly buffer huge amounts of data, which might impact scalability of the approach. Imagine a large number of users simultaneously downloading large files via HTTP, and the OPES processor does a callout for virus scanning for each of these files (in parallel). Since virus scanning involves long delays in processing, quite some data would accumulate at the OPES processor for temporary buffering... > 2.Reliability. If the original message is discarded by OPES processor > before transaction with the callout processor is completed callout > processor failure (including connection outage) forces OPES processor > to fail on this message, while preserved copy provides multiple > ways for recovery - default action on callout server unavailable, > repeat request to a different callout server. And the message > was already there, savings from premature discarding are very > small. Absolutely right, and that's why our architecture and protocol should allow an OPES processor to buffer the data. Then it's up to the OPES processor to decide whether to do that or not. > 3. catch 22: if message processing is simple and anticipated > processing time is small - so are the savings from message discarding. > If anticipated processing time is significant - savings may be > bigger but so are the risks related to failure and needs for > reliable recovery. Yup, see my comments above. Also, for some transactions it might be OK to fail when the callout server fails. Example: If a user requests mandatory virus scanning for file download, it might be perfectly fine to reply with an error messge when the callout server running the virus scanning fails, rather then sending back a non-scanned version from the buffer of the OPES processor. Thanks, Markus From owner-ietf-openproxy@mail.imc.org Tue Mar 18 10:03: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 KAA12025 for ; Tue, 18 Mar 2003 10:03:03 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2IEeJC14994 for ietf-openproxy-bks; Tue, 18 Mar 2003 06:40:19 -0800 (PST) Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2IEeHg14987 for ; Tue, 18 Mar 2003 06:40:18 -0800 (PST) Received: from f03v-1-197.d1.club-internet.fr ([212.194.36.197] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 18vIGE-0004y9-00; Tue, 18 Mar 2003 06:40:15 -0800 Message-Id: <5.2.0.9.0.20030318105441.00a382b0@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 18 Mar 2003 11:16:50 +0100 To: Markus Hofmann , ietf-openproxy@imc.org From: jfcm Subject: Re: OPES protocol, pre-draft In-Reply-To: <3E760DB7.2040603@mhof.com> 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: Dear Markus and all, please let not confuse everything in sticking to two terminolgies corresponding to twe different and quite opposed thinkings. This will help identfying these thinkings and to benefit from them both. Or we will wind up with something no one will be happy with. At 19:02 17/03/03, Markus Hofmann wrote: >You probably mean "OPES processor". Let's try to stick to the terminology >we've in the existing documents, might help avoiding misunderstandings. Notwidthstanding the document I do not understand yet what is an OPES and what is an OPES processor - and it seems that I am not alone. But I fully understand what is a dispatcher and what is a server. I may be wrong, but for me a processor is a CPU, and a server an identified virtual system running on one or serveral CPU. I may be wrong, but I think in the case the server uses several cpus the callout protocol could/should be use to permit such cpu to interoperate? Also I have difficulties in understanding if an OPES is the end-service as provided or the service as provuided to the end-user. Meaning, if the dispatcher is part of the OPES or not. Meaning, if the dispatcher user side interfaces are parts of the OPES. >>implementation that discards message chunk by chunk as soon as one is >>send to callout server does not look a good idea. Even if call starts >>before the complete message is received by the OPES processor it should >>be able to assemble the complete message anyway. > >This might require the OPES processor to possibly buffer huge amounts of >data, which might impact scalability of the approach. For examplen that remark makes sense if the "OPES processor" is a single machine (otherwise "buffer" is to be defined). But an OPES service can be permformed on several machines (this is to be considered (?) or operated(?) by the callout protocol), either successively (the service processing calls on several machines) or in parallel (several mechines offer the same service and must coordinate). >Imagine a large number of users simultaneously downloading large files via >HTTP, and the OPES processor so, here you then mean dispatcher. >does a callout for virus scanning for each of these files (in parallel). >Since virus scanning involves long delays in processing, quite some data >would accumulate at the OPES processor for temporary buffering... This is true for any inputs (HTTP or not). This means that the callout protocol should not be dependent on the fact that the input is HTTP, but to support different levels of service that an HTTP flow may chose from, the same for an SMTP, or an FTP flow. What I mean is that we have to be clear about the different layers, and not to patch through layer violations. Inputs come through a dispatcher. Dispatchers relate with other dispatchers (and servers? I personallythink that dispatchers should be server front-ends, much simpler) using the callout protocol. Nothing in the callout protocol is to be directly related to what happens before the dispatcher. Alex, shown well that towards the user (the user is to relate with the OPES through the application). This is also true the other way: the server is to relate with traffic flow through the dispatcher. jfc From owner-ietf-openproxy@mail.imc.org Tue Mar 18 10:27: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 KAA13792 for ; Tue, 18 Mar 2003 10:27:09 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2IF3uN16569 for ietf-openproxy-bks; Tue, 18 Mar 2003 07:03:56 -0800 (PST) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2IF3qg16564 for ; Tue, 18 Mar 2003 07:03:52 -0800 (PST) Received: from oskar3 (h00a0c5e5337d.ne.client2.attbi.com[24.218.184.133]) by sccrmhc02.attbi.com (sccrmhc02) with SMTP id <2003031815034700200rpgdfe>; Tue, 18 Mar 2003 15:03:48 +0000 From: "Oskar Batuner" To: "Markus Hofmann" , Subject: RE: OPES protocol, pre-draft Date: Tue, 18 Mar 2003 10:04:28 -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) Importance: Normal In-Reply-To: <3E760DB7.2040603@mhof.com> 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, I think we may have a different implementations in mind. I am looking at web proxy server (surrogate, I just do not like this word) extended by OPES capabilities. For this model storing all incoming data is not a problem - disks are large and cheap, and storing data is very natural behavior for the system build around cache engine. Correct me if I'm wrong, but it looks like you have in mind something like layer 7 switch. Such devise may have better throughput but very limited storage capabilities. Main differentiator is ability to keep data on disk. Hybrid devices are also possible, e.g. solid state cache. More interesting hybrid is L7 based OPES processor combined with cache farm. I suppose that buffering policy will depend mostly on the device type. OPES processor with disk will store all intermediate data and use it's caching capabilities to enhance overall performance. L7 switch based device will tend to be very conservative on storage use and may need to exploit protocol capabilities for copy control. To support all these needs we may do several things: 1. Dynamic (per-message) control, like in current proposal. 2. Stateful protocol with storage policy negotiated at handshake. 3. Different level of protocol implementation with device capabilities announced (but not negotiated) at handshake. I thing protocol should support all 3 policies. This may significantly simplify implementation of cache-based OPES processors. BTW, hybrid system with L7 switch based OPES processor and cache farm points to an interesting twist: why not to consider the attached web cache as a special case of callout server? This may be just another OPES scenario with OPES rules used to create and dynamically control caching policy. To support this scenario callout protocol should accommodate queries - transactions where message body is present only in response, and caching requests - message body only in request, and rules support persistence (if request was not in cache send storage request on response) and splitting (send content server response to end user without waiting for storage request to finish). > -----Original Message----- > From: owner-ietf-openproxy@mail.imc.org > [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of Markus Hofmann > Sent: Monday, March 17, 2003 1:03 PM > To: ietf-openproxy@imc.org > Subject: Re: OPES protocol, pre-draft > > > > implementation that discards message chunk by chunk as soon as one > > is send to callout server does not look a good idea. Even if call > > starts before the complete message is received by the OPES processor > > it should be able to assemble the complete message anyway. > > This might require the OPES processor to possibly buffer huge amounts > of data, which might impact scalability of the approach. > > Imagine a large number of users simultaneously downloading large files > via HTTP, and the OPES processor does a callout for virus scanning for > each of these files (in parallel). Since virus scanning involves long > delays in processing, quite some data would accumulate at the OPES > processor for temporary buffering... Yes, but: - virus scanning was used as an example of scenario where storage on OPES processor is most beneficial - virus scanner may give results after processing small part of the message eliminating most of the traffic; - with the spiky nature of web tarffic you can not rely on scanner ability to keep pace with the traffic. > > > 2.Reliability. If the original message is discarded by OPES processor > > before transaction with the callout processor is completed callout > > processor failure (including connection outage) forces OPES processor > > to fail on this message, while preserved copy provides multiple > > ways for recovery - default action on callout server unavailable, > > repeat request to a different callout server. And the message > > was already there, savings from premature discarding are very > > small. > > Absolutely right, and that's why our architecture and protocol should > allow an OPES processor to buffer the data. Then it's up to the OPES > processor to decide whether to do that or not. > > > 3. catch 22: if message processing is simple and anticipated > > processing time is small - so are the savings from message discarding. > > If anticipated processing time is significant - savings may be > > bigger but so are the risks related to failure and needs for > > reliable recovery. > > Yup, see my comments above. > > Also, for some transactions it might be OK to fail when the callout > server fails. Example: If a user requests mandatory virus scanning for > file download, it might be perfectly fine to reply with an error > messge when the callout server running the virus scanning fails, > rather then sending back a non-scanned version from the buffer of the > OPES processor. Yes, but stored message provides OPES processor with ability to recover after callout server failure (by sending the same request to another server) transparantly to other OPES flow participans. Oskar From owner-ietf-openproxy@mail.imc.org Tue Mar 18 11:26: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 LAA16285 for ; Tue, 18 Mar 2003 11:26:10 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2IFv9618240 for ietf-openproxy-bks; Tue, 18 Mar 2003 07:57:09 -0800 (PST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2IFv9g18236 for ; Tue, 18 Mar 2003 07:57:09 -0800 (PST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2IFv8826620 for ; Tue, 18 Mar 2003 09:57:08 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 18 Mar 2003 09:57:08 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 18 Mar 2003 07:56:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: OPES protocol, pre-draft Date: Tue, 18 Mar 2003 10:56:25 -0500 Message-ID: Thread-Topic: OPES protocol, pre-draft Thread-Index: AcLtYhd/TLCkqQirQHS/15CRGy6gHwAA2ebQ From: To: X-OriginalArrivalTime: 18 Mar 2003 15:56:26.0831 (UTC) FILETIME=[EEC7BDF0:01C2ED66] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h2IFv9g18237 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi, I always thought of the OPES processor as an L7 switch (as in Markus's view) with limited storage capability. That limits all the storage capacity to the ends of the network. A web proxy server might be considered as a Content Provider (one of the ends of the OPES connection as in architecture draft) rather than as a OPES processor. As a first attempt, I vote that the protocol that this WG comes out with considers the OPES processor as a bare-bones L7 switch, without much storage capability! -Srini >-----Original Message----- >From: ext Oskar Batuner [mailto:batuner@attbi.com] >Sent: Tuesday, March 18, 2003 10:04 AM >To: Markus Hofmann; ietf-openproxy@imc.org >Subject: RE: OPES protocol, pre-draft > > > >Markus, > >I think we may have a different implementations in mind. I am >looking at web proxy server (surrogate, I just do not like >this word) extended by OPES capabilities. For this model >storing all incoming data is not a problem - disks are >large and cheap, and storing data is very natural behavior >for the system build around cache engine. > >Correct me if I'm wrong, but it looks like you have >in mind something like layer 7 switch. Such devise may have >better throughput but very limited storage capabilities. >Main differentiator is ability to keep data on disk. Hybrid >devices are also possible, e.g. solid state cache. More interesting >hybrid is L7 based OPES processor combined with cache farm. > >I suppose that buffering policy will depend mostly on the device >type. OPES processor with disk will store all intermediate data >and use it's caching capabilities to enhance overall performance. >L7 switch based device will tend to be very conservative on >storage use and may need to exploit protocol capabilities for >copy control. > >To support all these needs we may do several things: > >1. Dynamic (per-message) control, like in current proposal. >2. Stateful protocol with storage policy negotiated at handshake. >3. Different level of protocol implementation with device capabilities >announced (but not negotiated) at handshake. > >I thing protocol should support all 3 policies. This may significantly >simplify implementation of cache-based OPES processors. > >BTW, hybrid system with L7 switch based OPES processor and cache farm >points to an interesting twist: why not to consider the attached web >cache as a special case of callout server? This may be just another >OPES scenario with OPES rules used to create and dynamically >control caching policy. To support this scenario callout protocol >should accommodate queries - transactions where message body >is present >only in response, and caching requests - message body only in request, >and rules support persistence (if request was not in cache send >storage request on response) and splitting (send content server >response to end user without waiting for storage request to finish). > >> -----Original Message----- >> From: owner-ietf-openproxy@mail.imc.org >> [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of Markus Hofmann >> Sent: Monday, March 17, 2003 1:03 PM >> To: ietf-openproxy@imc.org >> Subject: Re: OPES protocol, pre-draft >> >> >> > implementation that discards message chunk by chunk as soon as one >> > is send to callout server does not look a good idea. Even if call >> > starts before the complete message is received by the OPES >processor >> > it should be able to assemble the complete message anyway. >> >> This might require the OPES processor to possibly buffer >huge amounts >> of data, which might impact scalability of the approach. >> >> Imagine a large number of users simultaneously downloading >large files >> via HTTP, and the OPES processor does a callout for virus >scanning for >> each of these files (in parallel). Since virus scanning >involves long >> delays in processing, quite some data would accumulate at the OPES >> processor for temporary buffering... > >Yes, but: > >- virus scanning was used as an example of scenario where storage on >OPES processor is most beneficial - virus scanner may give results >after processing small part of the message eliminating most of >the traffic; > >- with the spiky nature of web tarffic you can not rely on >scanner ability >to keep pace with the traffic. > >> >> > 2.Reliability. If the original message is discarded by >OPES processor >> > before transaction with the callout processor is completed callout >> > processor failure (including connection outage) forces >OPES processor >> > to fail on this message, while preserved copy provides multiple >> > ways for recovery - default action on callout server unavailable, >> > repeat request to a different callout server. And the message >> > was already there, savings from premature discarding are very >> > small. >> >> Absolutely right, and that's why our architecture and >protocol should >> allow an OPES processor to buffer the data. Then it's up to the OPES >> processor to decide whether to do that or not. >> >> > 3. catch 22: if message processing is simple and anticipated >> > processing time is small - so are the savings from message >discarding. >> > If anticipated processing time is significant - savings may be >> > bigger but so are the risks related to failure and needs for >> > reliable recovery. >> >> Yup, see my comments above. >> >> Also, for some transactions it might be OK to fail when the callout >> server fails. Example: If a user requests mandatory virus >scanning for >> file download, it might be perfectly fine to reply with an error >> messge when the callout server running the virus scanning fails, >> rather then sending back a non-scanned version from the >buffer of the >> OPES processor. > >Yes, but stored message provides OPES processor with ability >to recover >after callout server failure (by sending the same request to another >server) transparantly to other OPES flow participans. > >Oskar > From owner-ietf-openproxy@mail.imc.org Tue Mar 18 12:31: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 MAA19556 for ; Tue, 18 Mar 2003 12:31:33 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2IH4ND21547 for ietf-openproxy-bks; Tue, 18 Mar 2003 09:04:23 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2IH4Lg21543 for ; Tue, 18 Mar 2003 09:04:21 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h2IH4Mnx068264 for ; Tue, 18 Mar 2003 10:04:22 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h2IH4MNm068263; Tue, 18 Mar 2003 10:04:22 -0700 (MST) (envelope-from rousskov) Date: Tue, 18 Mar 2003 10:04:22 -0700 (MST) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: RE: OPES protocol, pre-draft 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, 17 Mar 2003, Oskar Batuner wrote: > Let me propose a simplification of the protocol: remove [copied] > flag and make this behavior compulsory. After reading the follow-ups to this proposal, I would like to start by emphasizing that Oskar is essentially proposing changing the default behavior from "move" to "copy". I think it is clear by now (correct me if you have doubts!), that some systems have to use "move" and some systems have to use "copy", often for OPES-unrelated application/location-specific reasons. Thus, if we yank [copied] out, we have to add [moved] and vice versa. This is not a simplification of a protocol, just a change of the default settings. I think using "move" default and [copied] flag is better because "move" is a simpler, basic operation; OPES "copy" operation is, essentially, "store" + "move". That is why, IMO, "move" should stay as the default and [copied] should be used to overwrite that default. A possible alternative is to have the default dependent on the application protocol binding. I think many OCP defaults are best determined by the application protocol, but I am worried that having many application defaults would make the protocol difficult to analyze without referring to a specific application binding. Opinions? Thank you, Alex. P.S. I assume that an overhead of passing a [copied] or [moved] flag to the other side is negligible, regardless of what OCP encoding we select. Thus, the question of the default is of minor importance. We can even have "mode=copied|move" option and have it mandatory to avoid deciding on the defaults. Again, I vote for "move" mode as the default because "move" is a basic operation and "copy" is not. From owner-ietf-openproxy@mail.imc.org Tue Mar 18 12:45: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 MAA20071 for ; Tue, 18 Mar 2003 12:45:42 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2IHHOr22045 for ietf-openproxy-bks; Tue, 18 Mar 2003 09:17:24 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2IHHMg22039 for ; Tue, 18 Mar 2003 09:17:22 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h2IHHLnx068616 for ; Tue, 18 Mar 2003 10:17:21 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h2IHHLV3068615; Tue, 18 Mar 2003 10:17:21 -0700 (MST) (envelope-from rousskov) Date: Tue, 18 Mar 2003 10:17:21 -0700 (MST) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: RE: OPES protocol, pre-draft 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, 18 Mar 2003 bindignavile.srinivas@nokia.com wrote: > I always thought of the OPES processor as an L7 switch (as in > Markus's view) with limited storage capability. That limits all the > storage capacity to the ends of the network. A web proxy server > might be considered as a Content Provider (one of the ends of the > OPES connection as in architecture draft) rather than as a OPES > processor. OPES architecture draft defines two possible locations for an OPES system (including the OPES dispatcher): a content producer side (e.g., a surrogate in front of an origin server) and a content consumer side (e.g., a forward proxy at the company firewall). I think we should support both placements. > As a first attempt, I vote that the protocol that this WG comes out > with considers the OPES processor as a bare-bones L7 switch, without > much storage capability! This assumption is not going to simplify the protocol by much. Essentially, you would be able to remove all features related to [copied] flag. There are not that many (yet?). On the other hand, "copy" mode is a very powerful optimization in many environments; it would be sad to see it go. Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Tue Mar 18 12:57: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 MAA20702 for ; Tue, 18 Mar 2003 12:57:48 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2IHUbN22440 for ietf-openproxy-bks; Tue, 18 Mar 2003 09:30:37 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2IHUZg22436 for ; Tue, 18 Mar 2003 09:30:35 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h2IHUbnx068856 for ; Tue, 18 Mar 2003 10:30:37 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h2IHUbkx068855; Tue, 18 Mar 2003 10:30:37 -0700 (MST) (envelope-from rousskov) Date: Tue, 18 Mar 2003 10:30:37 -0700 (MST) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: OPES protocol, pre-draft In-Reply-To: Message-ID: References: <72992B39BBD9294BB636A960E89AE02E50C120@hermes.webwasher.com> <3E754A6A.5090302@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, 17 Mar 2003, Alex Rousskov wrote: > We probably need a "sticky" [copied] flag meaning "I am going > to have a copy of every byte from now on, until further notice". > This way the callout server can remove itself from the loop earlier. The "until further notice" part is a stupid idea, of course. Since the callout server cannot see messages still in the [TCP] pipe, it would never not be possible for the server to remove itself from the loop -- the server cannot guarantee that one of the still-unprocessed data-have messages was not sent with the "notice: now I am not copying!" flag. Once declared, the copying commitment has to be persistent for the life of the data stream. What we need to support loop cuts is a [copying-all] flag/state. Once that application message flag is sent, all further data messages MUST have a [copied] flag. Sorry for not thinking this through well enough on the first try. Hopefully there are no bugs in the revised version above. Alex. > On Sun, 16 Mar 2003, Markus Hofmann wrote: > > > > > Please apologize my late reply, but this just came to mind when > > catching-up with all the emails after coming back from vacation and > > reading through them for a second time on the plane... > > > > > > Martin Stecher wrote: > > > Example 2: > > > Callout server analyzes beginning of application message and detects > > > that it is not interested in this app. message: > > > > > > A. Traditional approach, ICAP/1.0 like with multiple preview > > > 0. C: Start of app. message 1 > > > 1. C: Here is preview chunk 1 > > > 2. S: Need another preview chunk > > > 3. C: Here is preview chunk 2 > > > 4. S: Not interested (204 resp.) > > > 5. C: Start of app. message 2 > > > > > > B. Proposed OPES protocol > > > 0. C: Start of app. message 1 > > > 1. C: Chunk 1 of data S: Start of app. message 1 > > > 2. C: Chunk 2 of data > > > 3. C: Chunk 3 of data S: Not interested > > > 4. C: Chunk 4 of data > > > 5. C: Start of app. message 2 > > > > > > In this case B sent more data and data chunks 3 and 4 will be ignored > > > by the callout server. > > > > This might be obvious, but please allow me to add the following for > > clarification only... Chunks 3 and 4 can only be ignored (i.e. > > discarded) by the callout server if the OPES processor has sent them > > with the [copied] flag set in the respective > size [copied]> message(s). If the [copied] flag was not set, the > > callout server must not ignore chunk 3 and 4, but simply copy/send > > them back to the OPES processor. Obviously, this can be done without > > further processing (i.e. servicing), but they still need to be sent > > back, since the OPES processor might no longer have a copy of these > > chunks. Note, that this is true even if chunks 1 and 2 were sent with > > the [copied] flag set. > > > > Thanks, > > Markus > > > > > > > From owner-ietf-openproxy@mail.imc.org Tue Mar 18 12:58: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 MAA20745 for ; Tue, 18 Mar 2003 12:58:14 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2IHa6X22619 for ietf-openproxy-bks; Tue, 18 Mar 2003 09:36:06 -0800 (PST) Received: from smtp.us2.messagingengine.com (ny2.fastmail.fm [66.111.4.3]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2IHa4g22615 for ; Tue, 18 Mar 2003 09:36:04 -0800 (PST) Received: from www.fastmail.fm (server1.internal [10.202.2.132]) by fastmail.fm (Postfix) with ESMTP id BD84A4798B for ; Tue, 18 Mar 2003 12:36:04 -0500 (EST) Received: from 127.0.0.1 ([127.0.0.1] helo=www.fastmail.fm) by fastmail.fm with SMTP; Tue, 18 Mar 2003 12:36:04 -0500 X-Epoch: 1048008964 X-Sasl-enc: IOy47dlx/MbzjWh/lhLGtA Received: from mhof.com (unknown [135.104.20.66]) by www.fastmail.fm (Postfix) with ESMTP id 206E123127 for ; Tue, 18 Mar 2003 12:36:04 -0500 (EST) Message-ID: <3E775946.8010307@mhof.com> Date: Tue, 18 Mar 2003 12:37:10 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openproxy@imc.org Subject: Re: OPES protocol, pre-draft 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 bindignavile.srinivas@nokia.com wrote: > Hi, I always thought of the OPES processor as an L7 switch (as in > Markus's view) with limited storage capability. I do *not* assume that this is always the case, that's only one specific implementation form. An OPES processor can also be implemented on a Web cache or Web proxy. Point is that our protocol should be designed so that it can support these different forms of implementations - the L7-style form with limited buffer capacity, as well as a WEb cache based approach with more storage capacity. It seems that the current proposal covers these different forms reasonable well. > As a first attempt, I vote that the protocol that this WG comes out > with considers the OPES processor as a bare-bones L7 switch, > without much storage capability! We should not limit ourselves to one or the other specific implementation form, our protocol should work in either case. Thanks, Markus From owner-ietf-openproxy@mail.imc.org Tue Mar 18 12:58: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 MAA20776 for ; Tue, 18 Mar 2003 12:58:42 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2IHVCG22464 for ietf-openproxy-bks; Tue, 18 Mar 2003 09:31:12 -0800 (PST) Received: from smtp.us2.messagingengine.com (ny2.fastmail.fm [66.111.4.3]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2IHVAg22460 for ; Tue, 18 Mar 2003 09:31:10 -0800 (PST) Received: from www.fastmail.fm (server1.internal [10.202.2.132]) by fastmail.fm (Postfix) with ESMTP id 3B6015050A for ; Tue, 18 Mar 2003 12:31:07 -0500 (EST) Received: from 127.0.0.1 ([127.0.0.1] helo=www.fastmail.fm) by fastmail.fm with SMTP; Tue, 18 Mar 2003 12:31:07 -0500 X-Epoch: 1048008667 X-Sasl-enc: Ba9lUn7ANzfluTF5GNf9CQ Received: from mhof.com (unknown [135.104.20.66]) by www.fastmail.fm (Postfix) with ESMTP id C890F2C418 for ; Tue, 18 Mar 2003 12:31:05 -0500 (EST) Message-ID: <3E775818.2080000@mhof.com> Date: Tue, 18 Mar 2003 12:32:08 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openproxy@imc.org Subject: Re: OPES protocol, pre-draft 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, > I think we may have a different implementations in mind. I am > looking at web proxy server (surrogate, I just do not like > this word) extended by OPES capabilities. For this model > storing all incoming data is not a problem - disks are > large and cheap, and storing data is very natural behavior > for the system build around cache engine. Even in this case you cannot assume to always being able to buffer the entire object - even the largest caches run out of disk space at some point and need to do some sort of cache replacement and conserve disk space. Even more, in case of streaming caches you might end up doing prefix caching, i.e. not having stored the entire object, but only the prefix of an object. The point is that we must not require a specific implementation, but that our protocol should support various forms of implementations. I agree that buffering capacity is of less importance in the model you've described above, but the protocol should also support other forms, and as such I still see value in allowing the OPES processor to not buffer the entire object (meaning there seems to be value to having the [copied] flag. > Correct me if I'm wrong, but it looks like you have > in mind something like layer 7 switch. Such devise may have > better throughput but very limited storage capabilities. > Main differentiator is ability to keep data on disk. Hybrid > devices are also possible, e.g. solid state cache. More interesting > hybrid is L7 based OPES processor combined with cache farm. Yup, that's one possible implementation form our protocol should support. > I suppose that buffering policy will depend mostly on the device > type. OPES processor with disk will store all intermediate data > and use it's caching capabilities to enhance overall performance. > L7 switch based device will tend to be very conservative on > storage use and may need to exploit protocol capabilities for > copy control. Yup, and that's why I believe the callout protocol should *not* require the OPES processor to always store the entire object. > To support all these needs we may do several things: > > 1. Dynamic (per-message) control, like in current proposal. > 2. Stateful protocol with storage policy negotiated at handshake. > 3. Different level of protocol implementation with device capabilities > announced (but not negotiated) at handshake. > > I thing protocol should support all 3 policies. This may significantly > simplify implementation of cache-based OPES processors. I agree that the protocol should support different forms of implementations, but I'm not yet convinced that policies need to be negotiated "at handshake". With the current proposal, the OPES processor can dynamically decide what to buffer and what not, indicating this to the callout server via the [copied] flag. This seems pretty flexible. Is there a specific scenario that cannot be solved with that approach? -Markus From owner-ietf-openproxy@mail.imc.org Tue Mar 18 13:30: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 NAA22668 for ; Tue, 18 Mar 2003 13:30:56 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2IHrVV24090 for ietf-openproxy-bks; Tue, 18 Mar 2003 09:53:31 -0800 (PST) Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2IHrUg24084 for ; Tue, 18 Mar 2003 09:53:30 -0800 (PST) Received: from f07a-1-159.d1.club-internet.fr ([212.194.144.159] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 18vLHD-00032q-00; Tue, 18 Mar 2003 09:53:27 -0800 Message-Id: <5.2.0.9.0.20030318185344.029c9210@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 18 Mar 2003 18:58:21 +0100 To: , From: jfcm Subject: RE: OPES protocol, pre-draft In-Reply-To: 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 16:56 18/03/03, bindignavile.srinivas@nokia.com wrote: >As a first attempt, I vote that the protocol that this WG comes out with >considers the OPES processor as a bare-bones L7 switch, without much >storage capability! This seems very reasonable. This permits all the configurations, local to the same cpu or to a local net or remote on the net. Unless including/or making it dependent from transport, the protocol should be transparent to the actual configuration. It is also to be considered situations such a debuging, test, back-up, overload etc. which may call for temporary/special configurations. From owner-ietf-openproxy@mail.imc.org Tue Mar 18 13:34: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 NAA22820 for ; Tue, 18 Mar 2003 13:34:46 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2II9Jl25307 for ietf-openproxy-bks; Tue, 18 Mar 2003 10:09:19 -0800 (PST) Received: from smtp.us2.messagingengine.com (ny2.fastmail.fm [66.111.4.3]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2II9Hg25303 for ; Tue, 18 Mar 2003 10:09:17 -0800 (PST) Received: from www.fastmail.fm (server1.internal [10.202.2.132]) by fastmail.fm (Postfix) with ESMTP id 9248722AF for ; Tue, 18 Mar 2003 13:09:17 -0500 (EST) Received: from 127.0.0.1 ([127.0.0.1] helo=www.fastmail.fm) by fastmail.fm with SMTP; Tue, 18 Mar 2003 13:09:17 -0500 X-Epoch: 1048010957 X-Sasl-enc: 0V3YocRJrKPeXtNDP8XSIQ Received: from mhof.com (unknown [135.104.20.66]) by www.fastmail.fm (Postfix) with ESMTP id E347F1EC05 for ; Tue, 18 Mar 2003 13:09:16 -0500 (EST) Message-ID: <3E776112.5090606@mhof.com> Date: Tue, 18 Mar 2003 13:10:26 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openproxy@imc.org Subject: Re: OPES protocol, pre-draft 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: > A possible alternative is to have the default dependent on the > application protocol binding. I think many OCP defaults are best > determined by the application protocol, but I am worried that having > many application defaults would make the protocol difficult to analyze > without referring to a specific application binding. Opinions? Please let's avoid having too many different application defaults and options - options always complicate the protocol and if there's no really strong, strong reason for them, let's try to avoid them. In this specific case, I'd assume it's perfectly fine to defne a general default. Thanks, MArkus From owner-ietf-openproxy@mail.imc.org Tue Mar 18 13:58: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 NAA24057 for ; Tue, 18 Mar 2003 13:58:40 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2IIPE625856 for ietf-openproxy-bks; Tue, 18 Mar 2003 10:25:14 -0800 (PST) Received: from smtp.us2.messagingengine.com (ny2.fastmail.fm [66.111.4.3]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2IIPCg25852 for ; Tue, 18 Mar 2003 10:25:12 -0800 (PST) Received: from www.fastmail.fm (server1.internal [10.202.2.132]) by fastmail.fm (Postfix) with ESMTP id C9EF846FFD for ; Tue, 18 Mar 2003 13:25:12 -0500 (EST) Received: from 127.0.0.1 ([127.0.0.1] helo=www.fastmail.fm) by fastmail.fm with SMTP; Tue, 18 Mar 2003 13:25:12 -0500 X-Epoch: 1048011912 X-Sasl-enc: 6CPWiEfuWWmVvY0YAwgw7w Received: from mhof.com (unknown [135.104.20.66]) by www.fastmail.fm (Postfix) with ESMTP id 5B40725D5E for ; Tue, 18 Mar 2003 13:25:11 -0500 (EST) Message-ID: <3E7764C7.5090803@mhof.com> Date: Tue, 18 Mar 2003 13:26:15 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openproxy@imc.org Subject: Re: OPES protocol, pre-draft References: <5.2.0.9.0.20030318105441.00a382b0@mail.utel.net> In-Reply-To: <5.2.0.9.0.20030318105441.00a382b0@mail.utel.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit jfcm wrote: > Notwidthstanding the document I do not understand yet what is an OPES > and what is an OPES processor - and it seems that I am not alone. But I > fully understand what is a dispatcher and what is a server. The "data dispatcher" is part of the OPES processor (see Figure 1 and corresponding text in the architecture draft). You might think of the OPES processor as a physical box/network element, and about the data dispatcher being a specific software component on this box. Note that "OPES processor" does not refer to a "processor" in the sense of a processor chip, but rather to the entire "box". A little bit simplified, you might think of having two different types of boxes in the OPES architecture - the "OPES processor" and the "callout server". The OPES processor includes a data dispatcher (that's simply a functional component), which decides what services have to be executed on what messages. Hope that helps. -Markus From owner-ietf-openproxy@mail.imc.org Tue Mar 18 14:57: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 OAA26852 for ; Tue, 18 Mar 2003 14:57:17 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2IJU1v02259 for ietf-openproxy-bks; Tue, 18 Mar 2003 11:30:01 -0800 (PST) Received: from shego.dbc.mtview.ca.us (wl-140-253.wireless.ietf56.ietf.org [130.129.140.253]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2IJTxg02251 for ; Tue, 18 Mar 2003 11:30:00 -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 h2IJTxNP009205; Tue, 18 Mar 2003 11:30:00 -0800 (PST) Date: Tue, 18 Mar 2003 11:29:59 -0800 From: Marshall Rose To: ietf-openproxy@imc.org Subject: *draft* minutes for OPES meeting Message-Id: <20030318112959.3777de56.mrose@dbc.mtview.ca.us> In-Reply-To: <3E6EBB00.7090902@mhof.com> References: <3E6EBB00.7090902@mhof.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: multipart/mixed; boundary="Multipart_Tue__18_Mar_2003_11:29:59_-0800_083da200" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. --Multipart_Tue__18_Mar_2003_11:29:59_-0800_083da200 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit please comment, etc. /mtr --Multipart_Tue__18_Mar_2003_11:29:59_-0800_083da200 Content-Type: text/plain; name="opes-minutes.txt" Content-Disposition: attachment; filename="opes-minutes.txt" Content-Transfer-Encoding: 7bit [ opes-minutes.txt - Tue Mar 18 11:24:33 2003 - 56th IETF - /mtr ] WG: Open Pluggable Edge Services (opes) Chairs: Markus Hofmann Marshall T. Rose Monday, March 17th, 2003 15:30-17:30 US/Pacific Minutes by: Marshall T. Rose Markus: Agenda Introduction: Status of WG documents Start on OPES protocol work - Introduction to protocol Protocol work - Protocol layer and the OPES callout protocol - OPES scope clarifications - Major decision points for protocol design - OPES protocol pre-draft thoughts General Discussion - Thoughts on SOAP/XML Open Discussion Markus: Any changes to the agenda? none. Markus: Status of WG documents OPES architecture: approved for publication as informational OPES protocol requirements: approved for publication as informational OPES policy and authorization: being reviewed by the IESG OPES threats and risks: being reviewed by the IESG OPES use and scenarios: being reviewed by the IESG in conjunction with threats/risks document (but ID-tracker is out-of-date) Markus: Start on OPES protocol work What needs to be done: work on two-related items! - OPES callout protocol - Relationship to application message protocols To date, good progress on fundamental design issues, but we need to work more on: - relationship to application message protocol - tracing/debugging considerations - security considerations Start with a discussion of major decision points that affect the core protocol design, e.g., - what type of interactions need to be supported (e.g., strict request/reply or one request with multiple replies or ... - what type of data is exchanged Then we can design the fundamental protocol mechanisms/messages in a generic format. Then we can talk about specific protocol bindings/mappings The callout protocol SHOULD be application-agnostic, but MUST do HTTP. Things to keep in mind: - we are working within the OPES architecture - any deviations must be conscious and within the charter - be specific on new "requirements" and why? - stick to the terminology in the existing wg documents - always keep in mind the IAB considerations Abbie: OPES Scope Clarifications (or open questions) Can OPES change the final destination of an application message? - If yes: what opes agents can do that and what techniques are allowed? - If no: can generating a response w/o forwarding the request be considered a form of redirection? Can OPES agents communicate with data provider/consumer using application protocols? Can OPES fan-out messages? Can OPES aggregate messages? Can OPES provide protocol translation service? Questions: Alex: how do we answer these questions? Ned: first, get concensus that you want to do things like these, and also look at your charter. Make sure there's demand for it... Alex: is a specific use case enough to justify going forward with something? Ned: if there's clear buyin from the working group, yes? Alex: but isn't there a conflict in terms of concensus for optional things? Ned: keep in mind that implementors need to provide a general implementation... Ned: i'll check with Allison and Sally about some of these issues. Hilarie: Protocol Layering and the OPES callout protocol One way to look at the architecture: Application Extension OPES Callout Protocol Application ] proxy Appication Transport ] Network The challenge is to provide a seemless application extension. Keith: why is this desirable? it's hard to make do protocol semantics. it's too hard to build a generic extensible proxy. Hilarie: there is experience showing how to do this. [ note: hilarie has some very nice diagrams that i can't render here... ] Summarizing, this architecture let's us understand where various capabilities fit in. Questions: Keith: perhaps you can generalize payload transformations, but what is very difficult to do is take protocol-specific things like email headers, http response codes, and try to build generic protocol transformations for those. Hilarie: the next speaker will address how to specify content modifications Ned: even mapping just content types is hard, e.g., when you have to go one-to-many or many-to-one. Alex: can an OPES cloud server generate a response? Hilarie: yes, because proxies can have colocated services like caches, so they can answer directly Alex: but isn't that redirection? Hilarie: no, not really. Alex: if you let an OPES server generate a response, then it can pretty much do whatever it wants. Hilarie: allowing the OPES processor unlimited communications violates the privacy considerations. Ned: the big issue deals with enforcement, we need to be able to deflect abuse by limiting the way things can be configured. this reinforces hilarie's point with respect to limiting the scope. Abbie: can we trust the rule-writer to write rules that won't break the rules Alex: Major decision points for protocol design Current decision points will be discussed today. Future decision points (that we won't discuss): - transport binding - message binding - application protocol binding - error handling What can talk first? - OPES dispatcher is a client, so should always talk first - specific roles simplify protocol - however: - callout server may next extra info - keep-alive violates simple roles - feature negotaiton may violate simple roles Keith: Trying to generalize a single layer that can handle handle generic application transformations is not possible. Are responses required, optional, or not allowed? - require responses only if they carry important info - add optional ACKs for debugging? - send an ACK when draining a buffer Keith: you'll always need an ACK indicating success or failure Granularity: addressable data parts - "entire message" is simple but inefficient - "sequential bytes" don't let us skip stuff - "sequential bytes with gaps" assume serialized application - arbitrary bytes" is flexible but may be inneficient - we support the most flexible scheme, but implementations use application-specific scheme Copy or move data to the other side? - Move is simpler and uses less storage on dispatcher, but copy allows the callout server get out of the loop, and the dispather may need copy anyway. - make optional, and requires servers to declare Can OPES mesages be given a handling priority? - not required - perhaps an optional optimization Consult the pre-draft document for a discussion of protocol operation Abbie: Thoughts on Soap/XML Why consider SOAP? - can still design an efficient callout protocol using soap (e.g., with a fixed parse tree) - can have access to any published service - facilities for security, privacy, policy exchange - why do we need another service-oriented protocol? Keith: it's too early to ask the question, also, is rpc a good mechanism for callouts? Alex: but does SOAP address/interact with IAB considerations? Abbie: i don't think this is an issue Keith: are there really many useful services around that would be helpful to OPES? Markus: adjourn. --Multipart_Tue__18_Mar_2003_11:29:59_-0800_083da200-- From owner-ietf-openproxy@mail.imc.org Tue Mar 18 15:16: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 PAA28558 for ; Tue, 18 Mar 2003 15:16:50 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2IJqBI02973 for ietf-openproxy-bks; Tue, 18 Mar 2003 11:52:11 -0800 (PST) Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2IJq7g02969 for ; Tue, 18 Mar 2003 11:52:07 -0800 (PST) Received: from oskar3 (h00a0c5e5337d.ne.client2.attbi.com[24.218.184.133]) by rwcrmhc53.attbi.com (rwcrmhc53) with SMTP id <20030318195147053009kfa3e>; Tue, 18 Mar 2003 19:51:48 +0000 From: "Oskar Batuner" To: "Markus Hofmann" , Subject: RE: OPES protocol, pre-draft Date: Tue, 18 Mar 2003 14:52:28 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 5 (Lowest) X-MSMail-Priority: Low 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: <3E775818.2080000@mhof.com> Importance: Low Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Martin, looking at your and other people reaction I agree that we should keep protocol flexible. The main change that can give a serious advantage is a well defined implementation level with fixed "copy always" policy. OPES processor based on web cache is a very real possibility, and at handshake it may be just a notification. I agree that from the protocol point view the same effect may be achieved by utilizing these generic framework - just always ask/notify about keeping the copy. But the possibility to implement a device that does not support that flexibility may very helpful, and such possibility requires notification at handshake: one should know partner capabilities in advance. This approach may also benefit L7 type devices - callout server will know about OPES processor limitations and adopt accordingly. Oskar > -----Original Message----- > From: owner-ietf-openproxy@mail.imc.org > [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of Markus Hofmann > Sent: Tuesday, March 18, 2003 12:32 PM > To: ietf-openproxy@imc.org > Subject: Re: OPES protocol, pre-draft > > > > Oskar, > > > I think we may have a different implementations in mind. I am > > looking at web proxy server (surrogate, I just do not like > > this word) extended by OPES capabilities. For this model > > storing all incoming data is not a problem - disks are > > large and cheap, and storing data is very natural behavior > > for the system build around cache engine. > > Even in this case you cannot assume to always being able to buffer the > entire object - even the largest caches run out of disk space at some > point and need to do some sort of cache replacement and conserve disk > space. Even more, in case of streaming caches you might end up doing > prefix caching, i.e. not having stored the entire object, but only the > prefix of an object. > > The point is that we must not require a specific implementation, but > that our protocol should support various forms of implementations. I > agree that buffering capacity is of less importance in the model > you've described above, but the protocol should also support other > forms, and as such I still see value in allowing the OPES processor to > not buffer the entire object (meaning there seems to be value to > having the [copied] flag. > > > Correct me if I'm wrong, but it looks like you have > > in mind something like layer 7 switch. Such devise may have > > better throughput but very limited storage capabilities. > > Main differentiator is ability to keep data on disk. Hybrid > > devices are also possible, e.g. solid state cache. More interesting > > hybrid is L7 based OPES processor combined with cache farm. > > Yup, that's one possible implementation form our protocol should support. > > > I suppose that buffering policy will depend mostly on the device > > type. OPES processor with disk will store all intermediate data > > and use it's caching capabilities to enhance overall performance. > > L7 switch based device will tend to be very conservative on > > storage use and may need to exploit protocol capabilities for > > copy control. > > Yup, and that's why I believe the callout protocol should *not* > require the OPES processor to always store the entire object. > > > To support all these needs we may do several things: > > > > 1. Dynamic (per-message) control, like in current proposal. > > 2. Stateful protocol with storage policy negotiated at handshake. > > 3. Different level of protocol implementation with device capabilities > > announced (but not negotiated) at handshake. > > > > I thing protocol should support all 3 policies. This may significantly > > simplify implementation of cache-based OPES processors. > > I agree that the protocol should support different forms of > implementations, but I'm not yet convinced that policies need to be > negotiated "at handshake". With the current proposal, the OPES > processor can dynamically decide what to buffer and what not, > indicating this to the callout server via the [copied] flag. This > seems pretty flexible. Is there a specific scenario that cannot be > solved with that approach? > > -Markus > From owner-ietf-openproxy@mail.imc.org Tue Mar 18 16:21: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 QAA00537 for ; Tue, 18 Mar 2003 16:21:09 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2IKwM305373 for ietf-openproxy-bks; Tue, 18 Mar 2003 12:58:22 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2IKwLg05367 for ; Tue, 18 Mar 2003 12:58:21 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h2IKwNnx074874 for ; Tue, 18 Mar 2003 13:58:23 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h2IKwNIe074873; Tue, 18 Mar 2003 13:58:23 -0700 (MST) (envelope-from rousskov) Date: Tue, 18 Mar 2003 13:58:23 -0700 (MST) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: RE: OPES protocol, pre-draft 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, 18 Mar 2003, Oskar Batuner wrote: > I agree that from the protocol point view the same effect may be > achieved by utilizing these generic framework - just always > ask/notify about keeping the copy. But the possibility to implement > a device that does not support that flexibility may very helpful, > and such possibility requires notification at handshake: one should > know partner capabilities in advance. Yes, may be very helpful. No, does not _require_. The current [copied] scheme supports devices that never copy, that always copy, and that copy depending on some conditions. > This approach may also benefit L7 type devices - callout server will > know about OPES processor limitations and adopt accordingly. I cannot think of any good example where "I will always copy" declaration can be made without a reference to a specific application message or transaction. It seems almost impossible to be that certain in a general environment. Do you think it is worth supporting? Note that we will support that kind of declaration in an application message context. The opposite declaration ("I will never copy") is, of course, applicable to many devices. Do you think it is worth supporting? Finally, do you think we need _negotiation_ capabilities here? "I may copy if you want to, do you?", "yes please copy" or "no, do not copy". I would like to see a complete set of copying-related features that we want to support in order to propose a specific protocol solution. Thanks, Alex. > > -----Original Message----- > > From: owner-ietf-openproxy@mail.imc.org > > [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of Markus Hofmann > > Sent: Tuesday, March 18, 2003 12:32 PM > > To: ietf-openproxy@imc.org > > Subject: Re: OPES protocol, pre-draft > > > > > > > > Oskar, > > > > > I think we may have a different implementations in mind. I am > > > looking at web proxy server (surrogate, I just do not like > > > this word) extended by OPES capabilities. For this model > > > storing all incoming data is not a problem - disks are > > > large and cheap, and storing data is very natural behavior > > > for the system build around cache engine. > > > > Even in this case you cannot assume to always being able to buffer the > > entire object - even the largest caches run out of disk space at some > > point and need to do some sort of cache replacement and conserve disk > > space. Even more, in case of streaming caches you might end up doing > > prefix caching, i.e. not having stored the entire object, but only the > > prefix of an object. > > > > The point is that we must not require a specific implementation, but > > that our protocol should support various forms of implementations. I > > agree that buffering capacity is of less importance in the model > > you've described above, but the protocol should also support other > > forms, and as such I still see value in allowing the OPES processor to > > not buffer the entire object (meaning there seems to be value to > > having the [copied] flag. > > > > > Correct me if I'm wrong, but it looks like you have > > > in mind something like layer 7 switch. Such devise may have > > > better throughput but very limited storage capabilities. > > > Main differentiator is ability to keep data on disk. Hybrid > > > devices are also possible, e.g. solid state cache. More interesting > > > hybrid is L7 based OPES processor combined with cache farm. > > > > Yup, that's one possible implementation form our protocol should support. > > > > > I suppose that buffering policy will depend mostly on the device > > > type. OPES processor with disk will store all intermediate data > > > and use it's caching capabilities to enhance overall performance. > > > L7 switch based device will tend to be very conservative on > > > storage use and may need to exploit protocol capabilities for > > > copy control. > > > > Yup, and that's why I believe the callout protocol should *not* > > require the OPES processor to always store the entire object. > > > > > To support all these needs we may do several things: > > > > > > 1. Dynamic (per-message) control, like in current proposal. > > > 2. Stateful protocol with storage policy negotiated at handshake. > > > 3. Different level of protocol implementation with device capabilities > > > announced (but not negotiated) at handshake. > > > > > > I thing protocol should support all 3 policies. This may significantly > > > simplify implementation of cache-based OPES processors. > > > > I agree that the protocol should support different forms of > > implementations, but I'm not yet convinced that policies need to be > > negotiated "at handshake". With the current proposal, the OPES > > processor can dynamically decide what to buffer and what not, > > indicating this to the callout server via the [copied] flag. This > > seems pretty flexible. Is there a specific scenario that cannot be > > solved with that approach? > > > > -Markus > > > > From owner-ietf-openproxy@mail.imc.org Tue Mar 18 18:36: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 SAA06118 for ; Tue, 18 Mar 2003 18:36:05 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2INFZE15201 for ietf-openproxy-bks; Tue, 18 Mar 2003 15:15:35 -0800 (PST) Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2INFYg15194 for ; Tue, 18 Mar 2003 15:15:34 -0800 (PST) Received: from f15v-8-249.d1.club-internet.fr ([212.195.199.249] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 18vQIx-0006v6-00 for ietf-openproxy@imc.org; Tue, 18 Mar 2003 15:15:35 -0800 Message-Id: <5.2.0.9.0.20030318235226.00ac86e0@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 19 Mar 2003 00:11:07 +0100 To: ietf-openproxy@imc.org From: jfcm Subject: Re: OPES protocol, pre-draft In-Reply-To: <3E7764C7.5090803@mhof.com> References: <5.2.0.9.0.20030318105441.00a382b0@mail.utel.net> <5.2.0.9.0.20030318105441.00a382b0@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 19:26 18/03/03, Markus Hofmann said: >jfcm wrote: >>Notwidthstanding the document I do not understand yet what is an OPES and >>what is an OPES processor - and it seems that I am not alone. But I fully >>understand what is a dispatcher and what is a server. Dear Markus, I thank you for your response. It is my reading of the document. If the words probably render the thinking at a given time, I think they are inapropriate now. What they mean is that the OPES are not located on the "OPES processor" but one of the "callout server". Also the OPES processor only supports the dispatcher and the i/o. >The "data dispatcher" is part of the OPES processor (see Figure 1 and >corresponding text in the architecture draft). You might think of the OPES >processor as a physical box/network element, and about the data dispatcher >being a specific software component on this box. Note that "OPES >processor" does not refer to a "processor" in the sense of a processor >chip, but rather to the entire "box". I do not see the dispatcher as a CPU, nor as a machine, but as a diagram corresponding to a set of filtering rules. With I/O the in being the input data, the O being the output to the user or to the servers or to other dispatchers. This can be implemented in different ways. >A little bit simplified, you might think of having two different types of >boxes in the OPES architecture - the "OPES processor" and the "callout >server". The OPES processor includes a data dispatcher (that's simply a >functional component), which decides what services have to be executed on >what messages. Taking advantage of this, you do understand. - has the callout server a dispatcher as a front end (the callout protocol performing between disptchers) or not (the callout protocol performing beteween a dispatcher and a remote server). In the first case I understand how the sytem can be smart, in the later case I don't. - what does the dispatcher do with the part of the traffic it does not send to the server and it received? You see I do not feel at ease with the focus on the protocol before having a clear, terse and comon understanding of what it relates, under which constraints and with which mission. jfc From owner-ietf-openproxy@mail.imc.org Tue Mar 18 20:36: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 UAA11193 for ; Tue, 18 Mar 2003 20:36:54 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2J1HIq19897 for ietf-openproxy-bks; Tue, 18 Mar 2003 17:17:18 -0800 (PST) Received: from web41306.mail.yahoo.com (web41306.mail.yahoo.com [66.218.93.55]) by above.proper.com (8.11.6/8.11.6) with SMTP id h2J1HHg19891 for ; Tue, 18 Mar 2003 17:17:17 -0800 (PST) Message-ID: <20030319011710.78759.qmail@web41306.mail.yahoo.com> Received: from [128.107.150.132] by web41306.mail.yahoo.com via HTTP; Tue, 18 Mar 2003 17:17:10 PST Date: Tue, 18 Mar 2003 17:17:10 -0800 (PST) From: Yimin Chen Subject: ICAP header questions To: ietf-openproxy@imc.org 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: Hi, I am studying the ICAP protocol spec (Dec 2002 version), and have some questions on section 4.3.2 to 4.3.4, which talk about the ICAP request and response headers. I would really appreciate if someone could shed light on them. Original text in specification: ---------------------------------------------------------------- A response-specific header is allowed in ICAP requests, following the same semantics as the corresponding HTTP response headers (Section 6.2 of [4]). This is: Server (see Section 14.38 of [4]) In addition to HTTP-like headers, there is also a request header unique to ICAP defined: ISTag (see Section 4.7) ------------------------------------------------------------------ Question: 1) Is it a typo and it is supposed to be "A response-specific header is allowed in ICAP *responses*"? 2) Is "Server" the only HTTP-like ICAP response header in ICAP protocol besides the ICAP-specific "Encapsulated"? 3) If 2) is true, then what header is ICAP server supposed to use if an ICAP client sends a request with "Authorization" ICAP header? I don't see a corresponding response header for that in the specification. Since Original text in specification: ------------------------------------------------------------------- A number of request-specific headers are allowed in ICAP requests, following the same semantics as the corresponding HTTP *request headers* (Section 5.3 of [4]). These are: Authorization Allow (see Section 4.6) From (see Section 14.22 of [4]) Host (REQUIRED in ICAP as it is in HTTP/1.1) Referer (see Section 14.36 of [4]) User-Agent In addition to HTTP-like headers, there are also request headers unique to ICAP defined: Preview (see Section 4.5) -------------------------------------------------------------------- Question: 1) So these are all the ICAP request headers? Section 4.4 mentioned that "Proxy-Authenticate and Proxy-Authorization headers must be forwarded to the ICAP server in the ICAP header section (not encapsulated message). What ICAP header should be used? I can't find a match in the listed headers in the original text cited. 2) Allow is not a request-specific header, but a entity-header. I would appreciate it if any of you could clarify for me. Thanks! Yimin __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com From owner-ietf-openproxy@mail.imc.org Tue Mar 18 20:56: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 UAA11699 for ; Tue, 18 Mar 2003 20:56:37 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2J1W2R20517 for ietf-openproxy-bks; Tue, 18 Mar 2003 17:32:02 -0800 (PST) Received: from smtp.us2.messagingengine.com (ny2.fastmail.fm [66.111.4.3]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2J1W0g20512 for ; Tue, 18 Mar 2003 17:32:01 -0800 (PST) Received: from www.fastmail.fm (server1.internal [10.202.2.132]) by fastmail.fm (Postfix) with ESMTP id 27D384D8FA for ; Tue, 18 Mar 2003 20:32:01 -0500 (EST) Received: from 127.0.0.1 ([127.0.0.1] helo=www.fastmail.fm) by fastmail.fm with SMTP; Tue, 18 Mar 2003 20:32:00 -0500 X-Epoch: 1048037520 X-Sasl-enc: 2870QuTMyVRPp8nedfa4wA Received: from mhof.com (unknown [135.104.20.81]) by www.fastmail.fm (Postfix) with ESMTP id CE34C21DAA for ; Tue, 18 Mar 2003 20:31:59 -0500 (EST) Message-ID: <3E77C8CF.6060308@mhof.com> Date: Tue, 18 Mar 2003 20:33:03 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: ietf-openproxy@imc.org Subject: Re: OPES protocol, pre-draft References: <5.2.0.9.0.20030318105441.00a382b0@mail.utel.net> <5.2.0.9.0.20030318105441.00a382b0@mail.utel.net> <5.2.0.9.0.20030318235226.00ac86e0@mail.utel.net> In-Reply-To: <5.2.0.9.0.20030318235226.00ac86e0@mail.utel.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit jfcm wrote: > - has the callout server a dispatcher as a front end (the callout > protocol performing between disptchers) or not (the callout protocol > performing beteween a dispatcher and a remote server). The callout protocol is used between an OPES processor (which includes a data dispatcher) and a callout server. > - what does the dispatcher do with the part of the traffic it does not > send to the server and it received? Messages not being vecored out to a callout server are forwarded to their respective destinations. For example, an HTTP request would be forwarded towards the content provider (i.e. Web server), an HTTP response would be forwarded towards the content consumer (i.e. Web client) -Markus From owner-ietf-openproxy@mail.imc.org Tue Mar 18 22:14: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 WAA13691 for ; Tue, 18 Mar 2003 22:14:30 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2J2spD23934 for ietf-openproxy-bks; Tue, 18 Mar 2003 18:54:51 -0800 (PST) Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2J2sng23929 for ; Tue, 18 Mar 2003 18:54:49 -0800 (PST) Received: from f07v-3-230.d1.club-internet.fr ([212.194.134.230] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 18vTj9-0003rW-00 for ietf-openproxy@imc.org; Tue, 18 Mar 2003 18:54:51 -0800 Message-Id: <5.2.0.9.0.20030319035110.024b9490@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 19 Mar 2003 04:01:25 +0100 To: ietf-openproxy@imc.org From: jfcm Subject: Re: OPES protocol, pre-draft In-Reply-To: <3E77C8CF.6060308@mhof.com> References: <5.2.0.9.0.20030318235226.00ac86e0@mail.utel.net> <5.2.0.9.0.20030318105441.00a382b0@mail.utel.net> <5.2.0.9.0.20030318105441.00a382b0@mail.utel.net> <5.2.0.9.0.20030318235226.00ac86e0@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 02:33 19/03/03, Markus Hofmann said: >jfcm wrote: >>- has the callout server a dispatcher as a front end (the callout >>protocol performing between disptchers) or not (the callout protocol >>performing beteween a dispatcher and a remote server). > >The callout protocol is used between an OPES processor (which includes a >data dispatcher) and a callout server. Dear Markus, I do not ask what the present paper says (IMHO in a confusing way as something "which includes a data dispatcher" is not a precise definition). I defined a dispatcher as a box in a scheme and I question the way it should work. The same to discuss the callout server as a server called by the OPES processor is confusing since it does not defines the architecture of the server system. To discuss the protocol without defining precisely which functional block it relates seems premature? Looks like what we all do: starting with "int main (..." instead of buidling a diagram of what we want to develop. >>- what does the dispatcher do with the part of the traffic it does not >>send to the server and it received? > >Messages not being vecored out to a callout server are forwarded to their >respective destinations. For example, an HTTP request would be forwarded >towards the content provider (i.e. Web server), an HTTP response would be >forwarded towards the content consumer (i.e. Web client) Sorry for the Franglish. I meant "while it wait for the response" of the callout something for the following part. As a policy does it buffer the data, to wich extent, request hem to be resent? jfc From owner-ietf-openproxy@mail.imc.org Wed Mar 19 01:19: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 BAA17925 for ; Wed, 19 Mar 2003 01:19:20 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2J5wOB00504 for ietf-openproxy-bks; Tue, 18 Mar 2003 21:58:24 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2J5wMg00500 for ; Tue, 18 Mar 2003 21:58:22 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h2J5wQnx087491 for ; Tue, 18 Mar 2003 22:58:26 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h2J5wQQr087490; Tue, 18 Mar 2003 22:58:26 -0700 (MST) (envelope-from rousskov) Date: Tue, 18 Mar 2003 22:58:26 -0700 (MST) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: copying commitment and deadlock 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: If we are to support copying (per data chunk or per message), we need to decide when the copying commitment expires. In other words, when the OPES dispatcher can release data previously sent with the "copied" flag set. If the callout server uses "data-have-as-is" message that matches the entire data block sent by the dispatcher, then the dispatcher can probably free the data (we do not have to support duplication of data, I guess; if a byte range has been sent, it is unlikely to be sent again). However, what happens if there is a partial match? Should the dispatcher keep the leftovers until the end of the message? Until copied data with higher offset is reused? Until wont-need message is received? A combination of these? There is also a potential deadlock situation here. If the amount of dispatcher buffer is limited, the dispatcher may stop sending more data to the callout server, and the callout server may need more data to respond (and let OPES dispatcher clear some of the copied chunks). We may want to address this explicitly instead of relying on timeouts. Copying data introduces state and blocking (due to buffer limitations). We need to find a simple way to support copying in many environments while keeping the protocol simple enough. I am seeking suggestions on what to support or where to draw a line. My current intention is to support "getting out of the loop" for OPES processor and nothing else, to optimize for the most common case. Comments? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Fri Mar 21 10:35: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 KAA17085 for ; Fri, 21 Mar 2003 10:35:46 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2LFAFw28419 for ietf-openproxy-bks; Fri, 21 Mar 2003 07:10:15 -0800 (PST) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2LFADg28415 for ; Fri, 21 Mar 2003 07:10:13 -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.8/8.12.8) with ESMTP id h2LFADkH059161 for ; Fri, 21 Mar 2003 10:10:14 -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.8/8.12.8) with ESMTP id h2LFA7Qu017046 for ; Fri, 21 Mar 2003 10:10:07 -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 KAA26739 for ; Fri, 21 Mar 2003 10:10:06 -0500 (EST) Message-ID: <3E7B2B78.4040206@mhof.com> Date: Fri, 21 Mar 2003 10:10:48 -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: copying commitment and deadlock 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: > If the callout server uses "data-have-as-is" message that matches the > entire data block sent by the dispatcher, then the dispatcher can > probably free the data (we do not have to support duplication of data, > I guess; if a byte range has been sent, it is unlikely to be sent > again). Yup, I would think so. When the callout server replies with a , the OPES processor starts forwarding the refered to, copied data segments and frees the respective buffer as the data is forwarded. > However, what happens if there is a partial match? Should the > dispatcher keep the leftovers until the end of the message? Until > copied data with higher offset is reused? Until wont-need message is > received? A combination of these? Hm... I would assume until either data with higher offset is reused or the end of the message is reached. In the first case, it's probably safe to assume that data with a lower offset has already been handled properly (since we require ordered and reliable delivery of callout protocol messages). In the later case, the callout transaction is finished and the associated buffers can be release (after possibly forwarding copied data). Even if the callout server sends a message, the OPES processor might prefer to keep a copy, for example to recover from a potential failure of the callout server. > There is also a potential deadlock situation here. If the amount of > dispatcher buffer is limited, the dispatcher may stop sending more > data to the callout server, and the callout server may need more data > to respond (and let OPES dispatcher clear some of the copied chunks). > We may want to address this explicitly instead of relying on > timeouts. Now, this doesn't solve the problem, but I'm just wondering why would the OPES processor stop sending more data when its buffer is limited or filled up? The OPES processor would still receive data from the direction of the content produce/consumer, right? In this case, if the OPES processor runs out of buffer, the data would be lost anyway so the OPES processor can also keep forwarding it to the callout server... Thanks, Markus From owner-ietf-openproxy@mail.imc.org Fri Mar 21 10:45: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 KAA17250 for ; Fri, 21 Mar 2003 10:45:00 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2LFMAr29138 for ietf-openproxy-bks; Fri, 21 Mar 2003 07:22:10 -0800 (PST) Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2LFM8g29133 for ; Fri, 21 Mar 2003 07:22:08 -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.8/8.12.8) with ESMTP id h2LFM9kH059266 for ; Fri, 21 Mar 2003 10:22:09 -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.8/8.12.8) with ESMTP id h2LFM3Qu018031 for ; Fri, 21 Mar 2003 10:22:03 -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 KAA27223 for ; Fri, 21 Mar 2003 10:22:03 -0500 (EST) Message-ID: <3E7B2E45.5080008@mhof.com> Date: Fri, 21 Mar 2003 10:22:45 -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: Protocol next steps 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 Hi, just a quick summary on how we want to proceed the next few days. Alex agreed to put the pre-draft ideas into the form of an Internet Draft. Once this is done, he'll send it out to the OPES mailing list, and the WG has to decide whether we want to adopt this as WG document right away, or what would have to be done to adopt this as WG document (in which case the draft might be published as individual submission, first, and WG document later). Based on this draft, the WG wil lthen decide on the protocol bindings. Abbie agreed to take a lead on the work item on "relationship to application message protocol", basically looking at mechanisms (e.g. HTTP header extensions) required for tracing, debugging, and OPES bypass. For all the work items, we'll haevily rely on feedback from the WG, and on working with the WG through the mailing list. So, please keep posting your comments and questions, we want to keep up the momentum we gained during the last few weeks!! Thanks to everyone's (past and future) contributions! Thanks, Markus From owner-ietf-openproxy@mail.imc.org Fri Mar 21 12:16: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 MAA19293 for ; Fri, 21 Mar 2003 12:16:38 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2LGoBS02397 for ietf-openproxy-bks; Fri, 21 Mar 2003 08:50:11 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2LGo8g02392 for ; Fri, 21 Mar 2003 08:50:09 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h2LGo8nx072096 for ; Fri, 21 Mar 2003 09:50:09 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h2LGo82C072095; Fri, 21 Mar 2003 09:50:08 -0700 (MST) (envelope-from rousskov) Date: Fri, 21 Mar 2003 09:50:08 -0700 (MST) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: copying commitment and deadlock In-Reply-To: <3E7B2B78.4040206@mhof.com> Message-ID: References: <3E7B2B78.4040206@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 Fri, 21 Mar 2003, Markus Hofmann wrote: > > However, what happens if there is a partial match? Should the > > dispatcher keep the leftovers until the end of the message? Until > > copied data with higher offset is reused? Until wont-need message is > > received? A combination of these? > > Hm... I would assume until either data with higher offset is reused > or the end of the message is reached. > > In the first case, it's probably safe to assume that data with a > lower offset has already been handled properly (since we require > ordered and reliable delivery of callout protocol messages). It is not safe in general because there are examples where callout server might want to reorder message content (e.g., change the parts order of a multipart e-mail message or move an ad banner to the end of an HTML page). To make it safe, we would have to explicitly document this assumption (and, hence, prevent copying optimization in those rare(?) cases where callout server needs to change the order of message parts). > In the later case, the callout transaction is finished and the > associated buffers can be release (after possibly forwarding copied > data). Yes. > Even if the callout server sends a message, the OPES > processor might prefer to keep a copy, for example to recover from a > potential failure of the callout server. Sure. This kind of copying is out of OCP scope. > > There is also a potential deadlock situation here. If the amount > > of dispatcher buffer is limited, the dispatcher may stop sending > > more data to the callout server, and the callout server may need > > more data to respond (and let OPES dispatcher clear some of the > > copied chunks). We may want to address this explicitly instead of > > relying on timeouts. > > Now, this doesn't solve the problem, but I'm just wondering why would > the OPES processor stop sending more data when its buffer is limited > or filled up? The OPES processor would still receive data from the > direction of the content produce/consumer, right? In this case, if the > OPES processor runs out of buffer, the data would be lost anyway so > the OPES processor can also keep forwarding it to the callout server... The OPES processor will stop reading incoming data when its buffers are full. That's how most proxies (and servers) I know work today. One can always control its input, relying on transport protocol to slow down the producer (TCP) or to drop packets (UDP). When deadlock occurs, the OPES processor is not reading incoming data because its buffers are full, and the callout server is not sending any data back because it waits for more incoming data to make a decision. Note that we can make the callout server aware of the deadlock by sending a message to it (possibly two messages, the last one in response to message from the callout server). However, "being aware" does not solve the problem. We need either a mechanism to break the deadlock or protocol changes to avoid it. Relying on timeouts is bad in this case because it is not an abnormal situation. Suggestions? Alex. From owner-ietf-openproxy@mail.imc.org Mon Mar 24 14:37: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 OAA00178 for ; Mon, 24 Mar 2003 14:37:14 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2OJDBW23298 for ietf-openproxy-bks; Mon, 24 Mar 2003 11:13:11 -0800 (PST) Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2OJD9g23292 for ; Mon, 24 Mar 2003 11:13:10 -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.8/8.12.8) with ESMTP id h2OJDBkH088278 for ; Mon, 24 Mar 2003 14:13:11 -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 h2OJD4jt016604 for ; Mon, 24 Mar 2003 14:13:05 -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 OAA13806 for ; Mon, 24 Mar 2003 14:13:02 -0500 (EST) Message-ID: <3E7F58E9.2090002@mhof.com> Date: Mon, 24 Mar 2003 14:13:45 -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: copying commitment and deadlock References: <3E7B2B78.4040206@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: > It is not safe in general because there are examples where callout > server might want to reorder message content (e.g., change the > parts order of a multipart e-mail message or move an ad banner to > the end of an HTML page). To make it safe, we would have to > explicitly document this assumption (and, hence, prevent copying > optimization in those rare(?) cases where callout server needs to > change the order of message parts). Yup, see your point, agreed. Question is whether added complexity to deal with such rare(?) cases is justified, or whether we believe that it might be OK to keep it less complex. Anyone any thoughts on that? > The OPES processor will stop reading incoming data when its buffers > are full. That's how most proxies (and servers) I know work today. > One can always control its input, relying on transport protocol to > slow down the producer (TCP) or to drop packets (UDP). > > When deadlock occurs, the OPES processor is not reading incoming > data because its buffers are full, and the callout server is not > sending any data back because it waits for more incoming data to > make a decision. There are buffers at different levels, and I was *not* refering to TCP buffers or so, but rather to the buffers that temporarily store the application message, assuming the OPES processor would still be able to receive TCP/UDP packets, but just no longer be able to temporarily store the appliction message (or parts of it). In that case, wouldn't the current protocol design already include everything that's needed? Example: The OPES processor starts receiving an application message (e.g. from a Web server). Since it still has buffer available, it copies the application message and indicates this to the callout server by setting the [copied] flag. If the buffer at the OPES processor now fills to, let's say, 90%, the OPES processor keeps forwarding the received application messages to the callout server, but no longer stores them in its local buffer. This is indicated to the callout server by *not* setting the copied flag in subsequent callout messages. As such, no deadlock occurs. What's missing? Thanks, -Markus From owner-ietf-openproxy@mail.imc.org Mon Mar 24 15:34: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 PAA02889 for ; Mon, 24 Mar 2003 15:34:30 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2OKD2D29034 for ietf-openproxy-bks; Mon, 24 Mar 2003 12:13:02 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2OKD0g29030 for ; Mon, 24 Mar 2003 12:13:00 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h2OKD2nx082657 for ; Mon, 24 Mar 2003 13:13:02 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h2OKD2b3082656; Mon, 24 Mar 2003 13:13:02 -0700 (MST) (envelope-from rousskov) Date: Mon, 24 Mar 2003 13:13:02 -0700 (MST) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: copying commitment and deadlock In-Reply-To: <3E7F58E9.2090002@mhof.com> Message-ID: References: <3E7B2B78.4040206@mhof.com> <3E7F58E9.2090002@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, 24 Mar 2003, Markus Hofmann wrote: > > It is not safe in general because there are examples where callout > > server might want to reorder message content (e.g., change the > > parts order of a multipart e-mail message or move an ad banner to > > the end of an HTML page). To make it safe, we would have to > > explicitly document this assumption (and, hence, prevent copying > > optimization in those rare(?) cases where callout server needs to > > change the order of message parts). > > Yup, see your point, agreed. > > Question is whether added complexity to deal with such rare(?) cases > is justified, or whether we believe that it might be OK to keep it > less complex. Anyone any thoughts on that? I suggest that we keep it simple unless somebody argues that reordering message parts is common/important enough to be optimized for. > > The OPES processor will stop reading incoming data when its > > buffers are full. That's how most proxies (and servers) I know > > work today. One can always control its input, relying on transport > > protocol to slow down the producer (TCP) or to drop packets (UDP). > > > > When deadlock occurs, the OPES processor is not reading incoming > > data because its buffers are full, and the callout server is not > > sending any data back because it waits for more incoming data to > > make a decision. > > There are buffers at different levels, and I was *not* refering to TCP > buffers or so, but rather to the buffers that temporarily store the > application message, assuming the OPES processor would still be able > to receive TCP/UDP packets, but just no longer be able to temporarily > store the appliction message (or parts of it). In that case, wouldn't > the current protocol design already include everything that's needed? I was referring to the same case. And yes, the deadlock problem does exist if we want to support "copying commitment" and, hence, support callout server ability to get out of the loop in its own. > Example: The OPES processor starts receiving an application message > (e.g. from a Web server). Since it still has buffer available, it > copies the application message and indicates this to the callout > server by setting the [copied] flag. If a per-OPES-message [copied] flag is used, then there is no problem (and no possibility for "getting out of the loop" optimization). [Copied] flag creates no problems because it applies to the current OPES data message. That data is either copied or not. There is no commitment that applies to future data chunks. Copying _commitment_ (i.e, "I will copy from now on" flag) allows for "getting out of the loop" optimization but is also subject to deadlock. > If the buffer at the OPES processor now fills to, let's say, 90%, > the OPES processor keeps forwarding the received application > messages to the callout server, but no longer stores them in its > local buffer. This is indicated to the callout server by *not* > setting the copied flag in subsequent callout messages. As such, no > deadlock occurs. What's missing? Nothing. You give an example of how [copied] flag works. Your example is correct, and there is no deadlock problem. Note that the callout server in your example cannot get out of the loop because at no point in time it has a guarantee that no data is lost if it does. Here is a summary: - [copied] flag is a simple per-message optimization. We need to decide when the processor can get rid of the copied data. Other than that, there are no significant problems or complications I am aware of. The [copied] flag alone does not, however, let callout servers to get out of the processing loop. - [will-always-copy] commitment allows the callout server to get out of the loop. This optimization is needed for efficient processing of large messages (or streams) that turn out to be not interesting to the callout server. This optimization may cause a deadlock if used "as is". One way to avoid the deadlock is to support the following confirmation/dialog: server: I want to get out of the loop! processor: OK, you can get out of the loop after processing first N bytes of this application message (N could be zero). I will stop sending you more data as of now. server: here is the data you asked for (could be several data messages) server: I am out of the loop Unfortunately, supporting this kind of dialog efficiently requires dedicated/priority connection: The primary data connection may be clogged by (yet unprocessed) data messages to the callout server, preventing the "OK" response from reaching the server fast. If the "OK" response is slow, there may be little gain from the optimization because a lot of data messages would be processed by then. Alex. From owner-ietf-openproxy@mail.imc.org Mon Mar 24 19:09:13 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 TAA10618 for ; Mon, 24 Mar 2003 19:09:11 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2ONkWK09872 for ietf-openproxy-bks; Mon, 24 Mar 2003 15:46:32 -0800 (PST) Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2ONkVg09868 for ; Mon, 24 Mar 2003 15:46:31 -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.8/8.12.8) with ESMTP id h2ONkYN5034105 for ; Mon, 24 Mar 2003 18:46:34 -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.8/8.12.8) with ESMTP id h2ONkKQu091613 for ; Mon, 24 Mar 2003 18:46:21 -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 SAA23658 for ; Mon, 24 Mar 2003 18:46:20 -0500 (EST) Message-ID: <3E7F98F7.6010706@mhof.com> Date: Mon, 24 Mar 2003 18:47:03 -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: copying commitment and deadlock References: <3E7B2B78.4040206@mhof.com> <3E7F58E9.2090002@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 suggest that we keep it simple unless somebody argues that > reordering message parts is common/important enough to be optimized > for. Agreed! Anyone else, if there are good reasons not to do so, now is the time to speak up! > [...] Copying _commitment_ (i.e, "I will copy from now on" flag) > allows for "getting out of the loop" optimization but is also > subject to deadlock. Got it, I somehow missed that you were talking about the copying *commitment*. > [...] One way to avoid the deadlock is to support the following > confirmation/dialog: > > server: I want to get out of the loop! > processor: OK, you can get out of the loop after > processing first N bytes of this application > message (N could be zero). I will stop > sending you more data as of now. > server: here is the data you asked for (could be > several data messages) > server: I am out of the loop > > Unfortunately, supporting this kind of dialog efficiently requires > dedicated/priority connection: The primary data connection may be > clogged by (yet unprocessed) data messages to the callout server, > preventing the "OK" response from reaching the server fast. If the > "OK" response is slow, there may be little gain from the > optimization because a lot of data messages would be processed by > then. OK, let me see whether I understood the scenario correctly: The callout server has decided that it has seen enough and wants to get out of the loop as quickly as possible. This is signaled to the OPES processor and happens at "Time A". After receiving the signal from the callout server, the OPES processor sets a specific "end" flag in the next outgoing message, indicating to the callout processor the end of the specific transaction. This message is received by the callout server at "Time B". Between "Time A" and "Time B", the callout server can discard any message it receives for this transaction and that has the [copied] flag set (doesn't seem to be too much overhed). Messages without the [copied] flag set have to be sent back to the OPES processor (which has to be done anyway...). Or are you more concerned about messages that might be stuck in the local queues at the OPES processor? But this seems to be more of a local implementation issue... Thanks, Markus From owner-ietf-openproxy@mail.imc.org Mon Mar 24 19:38: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 TAA11393 for ; Mon, 24 Mar 2003 19:38:31 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2P0LC812059 for ietf-openproxy-bks; Mon, 24 Mar 2003 16:21:12 -0800 (PST) Received: from shego.dbc.mtview.ca.us ([65.125.189.56]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2P0LBg12054 for ; Mon, 24 Mar 2003 16:21:11 -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 h2P0Kui3001310; Mon, 24 Mar 2003 16:20:56 -0800 (PST) Date: Mon, 24 Mar 2003 16:20:56 -0800 From: Marshall Rose To: ietf-openproxy@imc.org Subject: Re: *draft* minutes for OPES meeting Message-Id: <20030324162056.691c7717.mrose@dbc.mtview.ca.us> In-Reply-To: <20030318112959.3777de56.mrose@dbc.mtview.ca.us> References: <3E6EBB00.7090902@mhof.com> <20030318112959.3777de56.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 folks - the deadline for comments on the open minutes is thursday, march 27th, 1700 hours, us/pacific. thanks! /mtr From owner-ietf-openproxy@mail.imc.org Mon Mar 24 20:21: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 UAA12397 for ; Mon, 24 Mar 2003 20:21:43 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2P0x2a12902 for ietf-openproxy-bks; Mon, 24 Mar 2003 16:59:02 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2P0x0g12898 for ; Mon, 24 Mar 2003 16:59:00 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h2P0x4nx089261 for ; Mon, 24 Mar 2003 17:59:04 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h2P0x4v3089260; Mon, 24 Mar 2003 17:59:04 -0700 (MST) (envelope-from rousskov) Date: Mon, 24 Mar 2003 17:59:04 -0700 (MST) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: copying commitment and deadlock In-Reply-To: <3E7F98F7.6010706@mhof.com> Message-ID: References: <3E7B2B78.4040206@mhof.com> <3E7F58E9.2090002@mhof.com> <3E7F98F7.6010706@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, 24 Mar 2003, Markus Hofmann wrote: > > [...] One way to avoid the deadlock is to support the following > > confirmation/dialog: > > > > server: I want to get out of the loop! > > processor: OK, you can get out of the loop after > > processing first N bytes of this application > > message (N could be zero). I will stop > > sending you more data as of now. > > server: here is the data you asked for (could be > > several data messages) > > server: I am out of the loop > > > > Unfortunately, supporting this kind of dialog efficiently > > requires dedicated/priority connection: The primary data > > connection may be clogged by (yet unprocessed) data messages to > > the callout server, preventing the "OK" response from reaching > > the server fast. If the "OK" response is slow, there may be > > little gain from the optimization because a lot of data messages > > would be processed by then. > > OK, let me see whether I understood the scenario correctly: The > callout server has decided that it has seen enough and wants to get > out of the loop as quickly as possible. This is signaled to the OPES > processor and happens at "Time A". After receiving the signal from the > callout server, the OPES processor sets a specific "end" flag in the > next outgoing message, indicating to the callout processor the end of > the specific transaction. Yes. This message can be sent on a "high priority" connection, but in that case, it has to tell the callout server if there are any (possibly queued) data messages _without_ the [copied] flag. The protocol needs to make sure that no data is lost when the callout server "disconnects". If that message is not sent on a "high priority" connection, no special steps are needed. However, the delay between A and B can be significant in that case. The longer the delay, the smaller is the benefit of getting the callout server out of the loop... > This message is received by the callout server at "Time B". Between > "Time A" and "Time B", the callout server can discard any message it > receives for this transaction and that has the [copied] flag set > (doesn't seem to be too much overhed). Not exactly. The callout server must send either or messages until Time B (at least). The server is still in the loop. Recall that there is no commitment -- some of the [still queued] data messages from the OPES processor may not have a [copied] flag; we need to make sure the loop does not break until there are no such messages. Only the OPES processor knows whether such messages exist (because it has already sent them). The callout server does not know (because it has not receive them yet). Also, "Time B" is not the time when "OK, disconnect" message is received by the callout server. It is the time when the last uncopied data is forwarded back to the processor. The information about still unforwarded data will be present in the "OK, disconnect" message. If there is no such data (at the time the OK message has been received), the callout server may disconnect without processing any further messages. > Messages without the [copied] flag set have to be sent back to the > OPES processor (which has to be done anyway...). Yes. We could say that messages are not required in the above case, but it complicates the protocol (essentially creates multiple sources of data) without much benefit. messages as small. To keep things simple, both and messages need to be sent, as usual. > Or are you more concerned about messages that might be stuck in the > local queues at the OPES processor? But this seems to be more of a > local implementation issue... I am concerned about messages without the [copied] flag that were "sent" but has not been "processed" by the callout server yet. These messages can be in TCP or application buffers on either side. The above scheme avoids [I-will-always-copy] commitment to prevent deadlocks. As a side effect, we can never be sure that all unprocessed messages have [copied] flag. The scheme lets OPES processor inform the server when it is safe to ignore unprocessed messages (if any). Again, the processor knows whether there are any data chunks that were sent to the server without copying and were not sent back. I am not saying the above scheme is the best solution. It is just an example that may inspire better schemes. Here is a simplified version that is almost as "fast": server-to-processor: processor stops sending more data processor waits for all pending data up to the last uncopied chunk to be forwarded via or messages from the server processor-to-server: There is only one new message needed () as long as message can be sent on a "high-priority" connection (the latter will be done only when there is no pending uncopied data, of course). This scheme is simpler because the OPES processor does not have to tell the server about the last uncopied chunk. On the other hand, this scheme is slower because the server cannot disconnect until it receives that message. The first scheme allowed the server to disconnect immediately after sending the last uncopied chunk. The delay difference is one "round trip" time. Summary: 0) no [copied] flag does not allow for any optimizations but is very simple A) plain [copied] flag alone does not allow for the callout server to get out of the loop (scheme A) B) copying commitment is the most efficient optimization but has deadlocks (scheme B) C) scheme with details about the last uncopied chunk exchanged is more complex than copying commitment (scheme C) D) scheme without details about the last uncopied chunk exchanged is simpler but slower than scheme C Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Mon Mar 24 21:58: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 VAA15087 for ; Mon, 24 Mar 2003 21:58:05 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2P2cdG17449 for ietf-openproxy-bks; Mon, 24 Mar 2003 18:38:39 -0800 (PST) Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2P2ccg17443 for ; Mon, 24 Mar 2003 18:38:38 -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 h2P3LFMv011827; Mon, 24 Mar 2003 20:21:15 -0700 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h2P2cgs25978; Mon, 24 Mar 2003 19:38:42 -0700 Date: Mon, 24 Mar 2003 19:38:42 -0700 Message-Id: <200303250238.h2P2cgs25978@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: rousskov@measurement-factory.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage Subject: Re: copying commitment and deadlock Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I started trying to read this thread and I find that I need a summary of how we got here and what we are trying to accomplish. I can follow the details, but cannot tell why we are discussing what seems a fairly complicated interaction. I'm uncomfortable about messages that implied that we are trying to support a layer 7 switch architecture. If that's at the heart of this, I'm dismayed. If not, I don't know what's going on. I have a lot of trouble understanding the value of this if there's anything other than "this is a copied stream" and "this is not a copied stream". Could someone provide a succinct description of the problem? Hilarie From owner-ietf-openproxy@mail.imc.org Mon Mar 24 22:52: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 WAA16698 for ; Mon, 24 Mar 2003 22:52:36 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2P3S9x20585 for ietf-openproxy-bks; Mon, 24 Mar 2003 19:28:09 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2P3S7g20580 for ; Mon, 24 Mar 2003 19:28:07 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h2P3SBnx092717 for ; Mon, 24 Mar 2003 20:28:11 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h2P3SBhf092716; Mon, 24 Mar 2003 20:28:11 -0700 (MST) (envelope-from rousskov) Date: Mon, 24 Mar 2003 20:28:11 -0700 (MST) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: copying commitment and deadlock In-Reply-To: <200303250238.h2P2cgs25978@localhost.localdomain> Message-ID: References: <200303250238.h2P2cgs25978@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, 24 Mar 2003, The Purple Streak, Hilarie Orman wrote: > I started trying to read this thread and I find that I need a > summary of how we got here and what we are trying to accomplish. I > can follow the details, but cannot tell why we are discussing what > seems a fairly complicated interaction. We are discussing this for two reasons (see the first message on this thread for details): - we need to decide when an OPES processor can get rid of the data that was previously marked with a [copied] flag (the semantics of the flag does not imply an efficient end-of-life moment for copies) - we need to decide how we can let callout server to get out of the loop without losing any uncopied data (commitment-based schemes are simple and fast but lead to deadlocks, other schemes are more complex and slower) Both decisions must be documented in the callout protocol specs if copying-related features are to be supported. > I'm uncomfortable about messages that implied that we are trying to > support a layer 7 switch architecture. If that's at the heart of > this, I'm dismayed. If not, I don't know what's going on. IIRC, the only suggestion relevant to L7 switching was that no copying is necessary at all -- we could say that [the initial version of] the callout protocol supports "move" and does not support "copy" operations. L7 switch is just an example of an application-level proxy that may not support "copy" operations. I have argued that "copy" optimization is too valuable to get rid of. > I have a lot of trouble understanding the value of this if there's > anything other than "this is a copied stream" and "this is not a > copied stream". This discussion exists because some of us consider copying optimizations valuable (worth discussing and implementing) but those optimizations raise questions that protocol needs to address. > Could someone provide a succinct description of the problem? The first message on this thread describes both problems. The above is a short summary. However, since I wrote both, it would be great if somebody else can re-describe the problem for Hilarie in better words. If there are no volunteers, we can just wait for the protocol draft to be released this week; hopefully, it will clarify the problems. Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Tue Mar 25 03:20: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 DAA03399 for ; Tue, 25 Mar 2003 03:20:27 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2P80A707127 for ietf-openproxy-bks; Tue, 25 Mar 2003 00:00:10 -0800 (PST) Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2P808g07119 for ; Tue, 25 Mar 2003 00:00:08 -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 h2P8gjMv021227; Tue, 25 Mar 2003 01:42:45 -0700 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h2P807h08712; Tue, 25 Mar 2003 01:00:07 -0700 Date: Tue, 25 Mar 2003 01:00:07 -0700 Message-Id: <200303250800.h2P807h08712@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: rousskov@measurement-factory.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage Subject: Re: copying commitment and deadlock Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: What's the compelling reason for message by message copy directives? Hilarie From owner-ietf-openproxy@mail.imc.org Tue Mar 25 09:47:58 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 JAA14572 for ; Tue, 25 Mar 2003 09:47:57 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2PERIM16238 for ietf-openproxy-bks; Tue, 25 Mar 2003 06:27:18 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2PERGg16231 for ; Tue, 25 Mar 2003 06:27:16 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h2PERHnx008126 for ; Tue, 25 Mar 2003 07:27:17 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h2PERHOq008125; Tue, 25 Mar 2003 07:27:17 -0700 (MST) (envelope-from rousskov) Date: Tue, 25 Mar 2003 07:27:17 -0700 (MST) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: copying commitment and deadlock In-Reply-To: <200303250800.h2P807h08712@localhost.localdomain> Message-ID: References: <200303250800.h2P807h08712@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, 25 Mar 2003, The Purple Streak, Hilarie Orman wrote: > What's the compelling reason for message by message copy directives? The reason for per-message [copied] flag is to optimize for the common case where callout server does not modify the data. OPES processor will often keep a copy anyway, for many reasons. There is no need to send the same data back and forth; one direction is enough in this case. The reasons for copying commitment or a similar mechanism is to optimize for the common case where the callout server wants to get out of the loop because it does not expect any/further modifications. Alex. From owner-ietf-openproxy@mail.imc.org Tue Mar 25 10:27: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 KAA17826 for ; Tue, 25 Mar 2003 10:27:14 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2PF4Lp19107 for ietf-openproxy-bks; Tue, 25 Mar 2003 07:04:21 -0800 (PST) Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2PF4Kg19103 for ; Tue, 25 Mar 2003 07:04:20 -0800 (PST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2PF44V11650; Tue, 25 Mar 2003 10:04:04 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Mar 2003 10:04:04 -0500 Message-ID: <87609AFB433BD5118D5E0002A52CD754053D65FB@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Alex Rousskov , ietf-openproxy@imc.org Subject: RE: copying commitment and deadlock Date: Tue, 25 Mar 2003 10:04:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F2DF.C6D1CDE4" 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_01C2F2DF.C6D1CDE4 Content-Type: text/plain Alex, I see the points, Can u please provide a scenario abbie > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Tuesday, March 25, 2003 9:27 AM > To: ietf-openproxy@imc.org > Subject: Re: copying commitment and deadlock > > > > > On Tue, 25 Mar 2003, The Purple Streak, Hilarie Orman wrote: > > > What's the compelling reason for message by message copy directives? > > The reason for per-message [copied] flag is to optimize for > the common case where callout server does not modify the > data. OPES processor will often keep a copy anyway, for many > reasons. There is no need to send the same data back and > forth; one direction is enough in this case. > > The reasons for copying commitment or a similar mechanism is > to optimize for the common case where the callout server > wants to get out of the loop because it does not expect > any/further modifications. > > Alex. > > ------_=_NextPart_001_01C2F2DF.C6D1CDE4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: copying commitment and deadlock

Alex,

I see the points,
Can u please provide a scenario

abbie

> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Tuesday, March 25, 2003 9:27 AM
> To: ietf-openproxy@imc.org
> Subject: Re: copying commitment and = deadlock
>
>
>
>
> On Tue, 25 Mar 2003, The Purple Streak, Hilarie = Orman wrote:
>
> > What's the compelling reason for message = by message copy directives?
>
> The reason for per-message [copied] flag is to = optimize for
> the common case where callout server does not = modify the
> data. OPES processor will often keep a copy = anyway, for many
> reasons. There is no need to send the same data = back and
> forth; one direction is enough in this = case.
>
> The reasons for copying commitment or a similar = mechanism is
> to optimize for the common case where the = callout server
> wants to get out of the loop because it does = not expect
> any/further modifications.
>
> Alex.
>
>

------_=_NextPart_001_01C2F2DF.C6D1CDE4-- From owner-ietf-openproxy@mail.imc.org Tue Mar 25 11:24: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 LAA20169 for ; Tue, 25 Mar 2003 11:24:23 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2PFxYl22717 for ietf-openproxy-bks; Tue, 25 Mar 2003 07:59:34 -0800 (PST) Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2PFxWg22710 for ; Tue, 25 Mar 2003 07:59:32 -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.8/8.12.8) with ESMTP id h2PFxXN5040506 for ; Tue, 25 Mar 2003 10:59:33 -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.8/8.12.8) with ESMTP id h2PFxRQu051067 for ; Tue, 25 Mar 2003 10:59:27 -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 KAA14307 for ; Tue, 25 Mar 2003 10:59:26 -0500 (EST) Message-ID: <3E807D0A.7050207@mhof.com> Date: Tue, 25 Mar 2003 11:00:10 -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: copying commitment and deadlock References: <3E7B2B78.4040206@mhof.com> <3E7F58E9.2090002@mhof.com> <3E7F98F7.6010706@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: > Not exactly. The callout server must send either or > messages until Time B (at least). The server is still in > the loop. Recall that there is no commitment -- some of the [still > queued] data messages from the OPES processor may not have a [copied] > flag; we need to make sure the loop does not break until there are no > such messages. You're right, I ignored that the callout server has to send rather than just discarding the messages. I somehow assumed the OPES processor would implicitly interpret "gaps" in the returned message stream as (since we've reliable and ordered transport). Probably not a good idea... > Also, "Time B" is not the time when "OK, disconnect" message is > received by the callout server. It is the time when the last uncopied > data is forwarded back to the processor. The information about still > unforwarded data will be present in the "OK, disconnect" message. If > there is no such data (at the time the OK message has been received), > the callout server may disconnect without processing any further > messages. Sure, if you assume the "disconnect" signal can be send on a "high priority" connection, I assumed it would be send with the same priority as the other transaction messages (which might give a smaller benefit, as you sated correctly). > We could say that messages are not required in the above > case, but it complicates the protocol (essentially creates multiple > sources of data) without much benefit. messages as small. > To keep things simple, both and messages need > to be sent, as usual. That's sort of what I had in mind, but I now agree that the overhead of messages is small and that it would probably not justify added complexity. > Here is a simplified version that is almost as "fast": > > server-to-processor: > processor stops sending more data > processor waits for all pending data up to the last > uncopied chunk to be forwarded via > or messages from > the server > processor-to-server: > > There is only one new message needed () as > long as message can be sent on a "high-priority" > connection (the latter will be done only when there is no pending > uncopied data, of course). > > This scheme is simpler because the OPES processor does not have to > tell the server about the last uncopied chunk. On the other hand, this > scheme is slower because the server cannot disconnect until it > receives that message. The first scheme allowed the > server to disconnect immediately after sending the last uncopied > chunk. The delay difference is one "round trip" time. Yup, agreed. I'm somehow leaning towards the second, simplified alternative - simply for simplicity :) But these are just my 2 cents. > Summary: > > 0) no [copied] flag does not allow for any optimizations > but is very simple I consider the [copied] flag useful enough to keep it! > A) plain [copied] flag alone does not allow for the > callout server to get out of the loop (scheme A) > > B) copying commitment is the most efficient optimization > but has deadlocks (scheme B) > > C) scheme with details about > the last uncopied chunk exchanged is more complex > than copying commitment (scheme C) > > D) scheme without details about > the last uncopied chunk exchanged is simpler but > slower than scheme C Option (D) seems to be reasonable tradeoff between complexity and efficieny... -Markus From owner-ietf-openproxy@mail.imc.org Tue Mar 25 12:33:42 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 MAA22489 for ; Tue, 25 Mar 2003 12:33:41 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2PH0GH24343 for ietf-openproxy-bks; Tue, 25 Mar 2003 09:00:16 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2PH0Fg24339 for ; Tue, 25 Mar 2003 09:00:15 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h2PH0Gnx011653 for ; Tue, 25 Mar 2003 10:00:16 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h2PH0Guj011652; Tue, 25 Mar 2003 10:00:16 -0700 (MST) (envelope-from rousskov) Date: Tue, 25 Mar 2003 10:00:16 -0700 (MST) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: RE: copying commitment and deadlock In-Reply-To: <87609AFB433BD5118D5E0002A52CD754053D65FB@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD754053D65FB@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, 25 Mar 2003, Abbie Barbir wrote: > Can u please provide a scenario Scenario where [copied] flag is useful is handling of any application message that is not modified by the callout server. For example, virus scanning (most messages are probably virus-free and, hence, require no modifications). Another, more complex example is application header manipulation for, say, anonymization purposes: only a small portion of the application message is affected; the rest can be sent as is. A third example is appending "company signatures" to outgoing SMTP messages: only the tail of the message is affected. The first example is a scenario where "getting out of the loop" is very beneficial provided the virus scanner can make a "no virus" decision without seeing the entire application message. The second example is also a scenario where "getting out of the loop" is very beneficial. Getting out of the loop in the third example is not possible. HTH, Alex. From owner-ietf-openproxy@mail.imc.org Tue Mar 25 13:10:58 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 NAA23491 for ; Tue, 25 Mar 2003 13:10:57 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2PHW6F25343 for ietf-openproxy-bks; Tue, 25 Mar 2003 09:32:06 -0800 (PST) Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2PHW5g25339 for ; Tue, 25 Mar 2003 09:32:05 -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 h2PIElMv005382; Tue, 25 Mar 2003 11:14:51 -0700 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h2PHW1M03363; Tue, 25 Mar 2003 10:32:01 -0700 Date: Tue, 25 Mar 2003 10:32:01 -0700 Message-Id: <200303251732.h2PHW1M03363@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: rousskov@measurement-factory.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage Subject: Re: copying commitment and deadlock Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Then the condition is that a stream is opened in copy mode by the OPES processor and the callout server needs to signal "copy mode on this stream will cease." If the underlying transport is reliable, like TCP, there's no problem if you adopt the rule that acked data on a copied stream MUST be copied by the callout server and un-acked data cannot be deleted by the OPES processor. If the underlying transport is not reliable, then I submit that the decision has already been made that it is OK to lose some data. In that case, there's no need to have strong commitments - some data might be lost in a transition, but that's OK. We need to be careful not to reinvent things already solved at the transport layer. Hilarie On Tue, 25 Mar 2003 at 07:27:17 -0700 (MST) Alex Rousskov sent this missive: > > What's the compelling reason for message by message copy directives? > The reason for per-message [copied] flag is to optimize for the common > case where callout server does not modify the data. OPES processor > will often keep a copy anyway, for many reasons. There is no need to > send the same data back and forth; one direction is enough in this > case. > The reasons for copying commitment or a similar mechanism is to > optimize for the common case where the callout server wants to get out > of the loop because it does not expect any/further modifications. > Alex. From owner-ietf-openproxy@mail.imc.org Tue Mar 25 13:32: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 NAA24489 for ; Tue, 25 Mar 2003 13:32:31 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2PHx6Q28180 for ietf-openproxy-bks; Tue, 25 Mar 2003 09:59:06 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2PHx5g28175 for ; Tue, 25 Mar 2003 09:59:05 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h2PHwxnx013031; Tue, 25 Mar 2003 10:58:59 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h2PHwx33013030; Tue, 25 Mar 2003 10:58:59 -0700 (MST) (envelope-from rousskov) Date: Tue, 25 Mar 2003 10:58:59 -0700 (MST) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: copying commitment and deadlock In-Reply-To: <200303251732.h2PHW1M03363@localhost.localdomain> Message-ID: References: <200303251732.h2PHW1M03363@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, 25 Mar 2003, The Purple Streak, Hilarie Orman wrote: > Then the condition is that a stream is opened in copy mode by the > OPES processor and the callout server needs to signal "copy mode on > this stream will cease." Yes, but this simple scheme may lead to a deadlock (which is the subject of this thread, see below for more info). > If the underlying transport is reliable, like TCP, there's no problem > if you adopt the rule that acked data on a copied stream MUST be > copied by the callout server and un-acked data cannot be deleted by the > OPES processor. I am not sure I understand exactly what you are saying (what is acked data?), but transport protocol does not solve the higher-level problems we are discussing here. There are two different problems: The first problem is about OPES processor deleting its copy of the data (previously marked with a [copied] OCP flag). Here are some of the related issues: - When a copy of the data can be deleted (explicit notification by callout server, implicit order-based guess, other)? We have to keep in mind that the callout server does not care about processor buffering problems so there is a "conflict of interests" here. - Do we want to support reordering of copied data by the callout processor? - Granularity of messages (can callout server refer to something other than the exact same data chunk sent by the OPES processor? Do we want to support partial as-is messages?) The second problem is that a "stream opened in copy mode" may lead to a deadlock when the OPES processor is waiting for more buffer space and, hence, is not sending more data to the callout server, and the callout server is waiting for more data from the OPES processor to make a modification decision and, hence, is not returning any messages back, keeping processor buffers full. Again, transport protocol (reliable or not) does not solve this deadlock. It is a higher-level problem that is related to OPES processor buffers for copied messages, not transport. Hope this clarifies, Alex. > On Tue, 25 Mar 2003 at 07:27:17 -0700 (MST) Alex Rousskov sent this missive: > > > What's the compelling reason for message by message copy directives? > > > The reason for per-message [copied] flag is to optimize for the common > > case where callout server does not modify the data. OPES processor > > will often keep a copy anyway, for many reasons. There is no need to > > send the same data back and forth; one direction is enough in this > > case. > > > The reasons for copying commitment or a similar mechanism is to > > optimize for the common case where the callout server wants to get out > > of the loop because it does not expect any/further modifications. > > > Alex. > From owner-ietf-openproxy@mail.imc.org Tue Mar 25 13:39: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 NAA24720 for ; Tue, 25 Mar 2003 13:39:28 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2PIARE28740 for ietf-openproxy-bks; Tue, 25 Mar 2003 10:10:27 -0800 (PST) Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2PIAQg28736 for ; Tue, 25 Mar 2003 10:10: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 h2PIrAMv006992; Tue, 25 Mar 2003 11:53:11 -0700 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h2PIAI305490; Tue, 25 Mar 2003 11:10:18 -0700 Date: Tue, 25 Mar 2003 11:10:18 -0700 Message-Id: <200303251810.h2PIAI305490@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: rousskov@measurement-factory.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage <87609AFB433BD5118D5E0002A52CD754053D65FB@zcard0k6.ca.nortel.com> Subject: RE: copying commitment and deadlock Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In my previous note I left out the rule that makes the stream restartable ... if stream A is "copy" and the callout server signals "no further copy", the easiest way to proceed with "no copy" mode is for the OPES processor to open a new stream, B, with the directive "this is the no-copy continuation of stream A". Anything un-acked on stream A is now sent on stream B. This does mean that "copy" streams cannot be multiplexed on a single reliable connection unless the callout server promises not to switch to "no-copy" mode. I'm still wondering how useful this will be; I'd always assumed that the intelligence about which parts to forward would reside with the OPES processor, or that the directives would be at a higher semantic level. Hilarie From owner-ietf-openproxy@mail.imc.org Tue Mar 25 14:16: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 OAA26319 for ; Tue, 25 Mar 2003 14:16:53 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2PIpi300917 for ietf-openproxy-bks; Tue, 25 Mar 2003 10:51:44 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2PIphg00909 for ; Tue, 25 Mar 2003 10:51:43 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h2PIphnx014329; Tue, 25 Mar 2003 11:51:43 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h2PIphHL014328; Tue, 25 Mar 2003 11:51:43 -0700 (MST) (envelope-from rousskov) Date: Tue, 25 Mar 2003 11:51:43 -0700 (MST) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: RE: copying commitment and deadlock In-Reply-To: <200303251810.h2PIAI305490@localhost.localdomain> Message-ID: References: <200303251810.h2PIAI305490@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, 25 Mar 2003, The Purple Streak, Hilarie Orman wrote: > In my previous note I left out the rule that makes the stream > restartable ... if stream A is "copy" and the callout server > signals "no further copy", the easiest way to proceed with "no copy" > mode is for the OPES processor to open a new stream, B, with the > directive "this is the no-copy continuation of stream A". Anything > un-acked on stream A is now sent on stream B. > > This does mean that "copy" streams cannot be multiplexed on a single > reliable connection unless the callout server promises not to switch > to "no-copy" mode. You seem to be solving a very different problem. Could you please give an example or a use case? It seems to me that you are trying to introduce some negotiation here (callout server tells the processor to copy/move, and the processor may copy/move in response). That could be a useful feature _on top_ of the basic mechanisms we are trying to finalize in this thread. > I'm still wondering how useful this will be; I'd always assumed that > the intelligence about which parts to forward would reside with the > OPES processor, or that the directives would be at a higher semantic > level. We may be talking about different use cases here. See my earlier response to Abbie Barbir with specific examples I have in mind. The callout server may modify the message. Thus, the resulting data stream from the callout server to the OPES processor consists, in general, of new and old data chunks. The copy mode is meant to reduce the number of old data chunks, nothing else. Alex. From owner-ietf-openproxy@mail.imc.org Wed Mar 26 06:54: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 GAA22226 for ; Wed, 26 Mar 2003 06:54:51 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2QBRMH03236 for ietf-openproxy-bks; Wed, 26 Mar 2003 03:27:22 -0800 (PST) Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2QBRLg03232 for ; Wed, 26 Mar 2003 03:27:21 -0800 (PST) Received: from f08v-12-31.d1.club-internet.fr ([212.194.167.31] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 18y93a-0007Ke-00; Wed, 26 Mar 2003 03:26:59 -0800 Message-Id: <5.2.0.9.0.20030326121905.00a3bbd0@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 26 Mar 2003 12:32:49 +0100 To: Alex Rousskov , ietf-openproxy@imc.org From: jfcm Subject: RE: copying commitment and deadlock In-Reply-To: References: <200303251810.h2PIAI305490@localhost.localdomain> <200303251810.h2PIAI305490@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: Sorry, to say it again, but you are talking here of a protocol between X and Y without having modelized X and Y. The callout protocol, X and Y modelization must be an harmonious interative process. At 19:51 25/03/03, Alex Rousskov wrote: >On Tue, 25 Mar 2003, The Purple Streak, Hilarie Orman wrote: > > In my previous note I left out the rule that makes the stream > > restartable ... if stream A is "copy" and the callout server > > signals "no further copy", the easiest way to proceed with "no copy" > > mode is for the OPES processor to open a new stream, B, with the > > directive "this is the no-copy continuation of stream A". Anything > > un-acked on stream A is now sent on stream B. > > > > This does mean that "copy" streams cannot be multiplexed on a single > > reliable connection unless the callout server promises not to switch > > to "no-copy" mode. > >You seem to be solving a very different problem. modelize what you are talking about. >Could you please give an example or a use case? examples are too specific and involving to many aspects. The must be used to build and check a model. Not to replace it. >It seems to me that you are trying to >introduce some negotiation here (callout server tells the processor to >copy/move, and the processor may copy/move in response). That could be >a useful feature _on top_ of the basic mechanisms we are trying to >finalize in this thread. Sure he is. But what are you both really calling a "processor"? > > I'm still wondering how useful this will be; I'd always assumed that > > the intelligence about which parts to forward would reside with the > > OPES processor, or that the directives would be at a higher semantic > > level. > >We may be talking about different use cases here. See my earlier >response to Abbie Barbir with specific examples I have in mind. > >The callout server may modify the message. what do you call the message? If it received only a part of the stream, do you call message the chunk it receives or a set of copied and non copied data chuncks. Dispatchers rules may say that (A+B ) calls for B only to be modified into B', and that (A+B' ) calls for A to be modified too, or in conjunction with B'. >Thus, the resulting data >stream from the callout server to the OPES processor consists, in >general, of new and old data chunks. The copy mode is meant to reduce >the number of old data chunks, nothing else. Copying seems hazardous anyway because if several services are called in conditional succession, how will a service know the nature of what is in the buffer. Are they original or already modified data. jfc From owner-ietf-openproxy@mail.imc.org Wed Mar 26 11:20:42 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 LAA02501 for ; Wed, 26 Mar 2003 11:20:41 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2QFswL21922 for ietf-openproxy-bks; Wed, 26 Mar 2003 07:54:58 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2QFsvg21915 for ; Wed, 26 Mar 2003 07:54:57 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h2QFt3nx044538; Wed, 26 Mar 2003 08:55:03 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h2QFt2Sl044537; Wed, 26 Mar 2003 08:55:02 -0700 (MST) (envelope-from rousskov) Date: Wed, 26 Mar 2003 08:55:02 -0700 (MST) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: RE: copying commitment and deadlock In-Reply-To: <5.2.0.9.0.20030326121905.00a3bbd0@mail.utel.net> Message-ID: References: <200303251810.h2PIAI305490@localhost.localdomain> <200303251810.h2PIAI305490@localhost.localdomain> <5.2.0.9.0.20030326121905.00a3bbd0@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, 26 Mar 2003, jfcm wrote: > Sorry, to say it again, but you are talking here of a protocol > between X and Y without having modelized X and Y. The callout > protocol, X and Y modelization must be an harmonious interative > process. jfc, Please understand that such comments are not constructive enough to cause any action. There are working group documents that describe architecture and protocol requirements. Obviously, people who wrote them and who are now working on the protocol think that they have "modelized X and Y"! Sure, some models can be improved and some scope questions need to be answered, but those improvements and answers are unlikely to affect the subject of this thread IMO. It is perfectly fine to disagree with the published documents, but please be constructive! Tell the group what exactly is wrong with the current models. Suggest specific improvements if possible. It is the only way we all can understand and address your concerns. "You have not modelized" is not something others can address given the fact that some models do exist in the working group documents. > modelize what you are talking about. Please see architecture and protocol requirements documents. They are my models. > But what are you both really calling a "processor"? Whatever receives raw application messages and talks to the callout server for the purpose of adapting those application messages. That's enough detail/modelization for the subject of this thread, I think. This thread does not really care what the processor or dispatcher is beyond what is currently defined in the architecture and requirements documents. Why do you ask? > >The callout server may modify the message. > > what do you call the message? Whatever that application protocol calls a message. I should have said "may modify the application message", to be precise. > If it received only a part of the stream, do you call message the > chunk it receives or a set of copied and non copied data chuncks. [Copied] flag applies to an application data chunk. Copying commitment, if any, applies to several chunks (possibly the entire application message). > Dispatchers rules may say that (A+B ) calls for B only to be > modified into B', and that (A+B' ) calls for A to be modified too, > or in conjunction with B'. Sorry, I do not follow. I do not understand what "(A+B) calls for B" means. > Copying seems hazardous anyway because if several services are > called in conditional succession, how will a service know the nature > of what is in the buffer. Are they original or already modified > data. Original data may have a [copied] flag. Modified data must not have a [copied] flag unless the dispatcher made a copy of the modified data before calling the next service. Apart from that distinction, coordination between individual OPES services is outside of this thread scope, I guess. Alex. From owner-ietf-openproxy@mail.imc.org Wed Mar 26 14:02: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 OAA07602 for ; Wed, 26 Mar 2003 14:02:43 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2QIO6r27864 for ietf-openproxy-bks; Wed, 26 Mar 2003 10:24:06 -0800 (PST) Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2QIO5g27860 for ; Wed, 26 Mar 2003 10:24:05 -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 h2QINVMv020828; Wed, 26 Mar 2003 11:23:31 -0700 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h2QIO4905754; Wed, 26 Mar 2003 11:24:04 -0700 Date: Wed, 26 Mar 2003 11:24:04 -0700 Message-Id: <200303261824.h2QIO4905754@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: rousskov@measurement-factory.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage Subject: RE: copying commitment and deadlock Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I think that the comment below refers to applying dispatch rules to the result of a dispatch. I.e., assume the content is two parts, {A,B}. That content triggers a modification to part B, resulting in {A,B'}. The dispatch rules applied to {A,B'} trigger a modifiction to A, resulting in {A',B'}. What might happen in an implementation is that the first condition would trigger a callout, causing the OPES processor to start sending B to the callout server; the callout server would have logic asking the OPES server if A existed, and if so, to send it also, so that it can generate A' as a function of B'. I can see this happening, but I'm not sure how it affects the current discussion about copying commitment. I think we need to be selecting the absolutely minimal set of mechanisms to support transport of content to and from callout servers. We should lean heavily towards mechanism reuse over mechanism extension. Hilarie On Wed, 26 Mar 2003 at 08:55:02 -0700 (MST) Alex Rousskov said: > [Copied] flag applies to an application data chunk. Copying commitment, > if any, applies to several chunks (possibly the entire application > message). > > Dispatchers rules may say that (A+B ) calls for B only to be > > modified into B', and that (A+B' ) calls for A to be modified too, > > or in conjunction with B'. > Sorry, I do not follow. I do not understand what "(A+B) calls for B" > means. From owner-ietf-openproxy@mail.imc.org Wed Mar 26 14:40: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 OAA09176 for ; Wed, 26 Mar 2003 14:40:56 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2QIq1L01027 for ietf-openproxy-bks; Wed, 26 Mar 2003 10:52:01 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2QIpxg01018 for ; Wed, 26 Mar 2003 10:51:59 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h2QIpsnx048733; Wed, 26 Mar 2003 11:51:54 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h2QIpsV3048732; Wed, 26 Mar 2003 11:51:54 -0700 (MST) (envelope-from rousskov) Date: Wed, 26 Mar 2003 11:51:54 -0700 (MST) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: RE: copying commitment and deadlock In-Reply-To: <200303261824.h2QIO4905754@localhost.localdomain> Message-ID: References: <200303261824.h2QIO4905754@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, 26 Mar 2003, The Purple Streak, Hilarie Orman wrote: > I think that the comment below refers to applying dispatch rules to > the result of a dispatch. I.e., assume the content is two parts, > {A,B}. That content triggers a modification to part B, resulting in > {A,B'}. The dispatch rules applied to {A,B'} trigger a modifiction to > A, resulting in {A',B'}. OK. This seems to have nothing to do with OCP. This is about rule processing, right? > What might happen in an implementation is that the first condition > would trigger a callout, causing the OPES processor to start sending > B to the callout server; the callout server would have logic asking > the OPES server if A existed, and if so, to send it also, so that it > can generate A' as a function of B'. We need to decide whether OCP should support partial message exchange. So far, I have assume a simple model when entire messages are exchanged and there is no "give me part X" dialog. After the IETF meeting, I tend to stay away from application specific parts (would prefer to limit the language to byte ranges). However, without application-specific parts, it becomes difficult to describe "part X" unless the entire message is known (the callout server would not know where X starts and where it ends). Added this topic to the todo list. > I can see this happening, but I'm not sure how it affects the current > discussion about copying commitment. Neither am I. > I think we need to be selecting the absolutely minimal set of > mechanisms to support transport of content to and from callout > servers. We should lean heavily towards mechanism reuse over > mechanism extension. Yes, of course. The difficulty is in defining the "absolute minimum", as usual. Thanks, Alex. > On Wed, 26 Mar 2003 at 08:55:02 -0700 (MST) Alex Rousskov said: > > > [Copied] flag applies to an application data chunk. Copying commitment, > > if any, applies to several chunks (possibly the entire application > > message). > > > > Dispatchers rules may say that (A+B ) calls for B only to be > > > modified into B', and that (A+B' ) calls for A to be modified too, > > > or in conjunction with B'. > > > Sorry, I do not follow. I do not understand what "(A+B) calls for B" > > means. > > From owner-ietf-openproxy@mail.imc.org Wed Mar 26 15:26: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 PAA12687 for ; Wed, 26 Mar 2003 15:26:17 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2QK1x605473 for ietf-openproxy-bks; Wed, 26 Mar 2003 12:01:59 -0800 (PST) Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2QK1vg05466 for ; Wed, 26 Mar 2003 12:01: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.8/8.12.8) with ESMTP id h2QK24N5055163 for ; Wed, 26 Mar 2003 15:02:04 -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 h2QK1wjt025810 for ; Wed, 26 Mar 2003 15:01:58 -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 PAA03873 for ; Wed, 26 Mar 2003 15:01:57 -0500 (EST) Message-ID: <3E820760.7020101@mhof.com> Date: Wed, 26 Mar 2003 15:02:40 -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: copying commitment and deadlock References: <200303261824.h2QIO4905754@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: > We need to decide whether OCP should support partial message exchange. > So far, I have assume a simple model when entire messages are > exchanged and there is no "give me part X" dialog. After the IETF > meeting, I tend to stay away from application specific parts (would > prefer to limit the language to byte ranges). I can only second this view! -Markus From owner-ietf-openproxy@mail.imc.org Wed Mar 26 17:08: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 RAA17727 for ; Wed, 26 Mar 2003 17:08:50 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2QLlbC10729 for ietf-openproxy-bks; Wed, 26 Mar 2003 13:47:37 -0800 (PST) Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2QLlag10723 for ; Wed, 26 Mar 2003 13:47:36 -0800 (PST) Received: from f03m-7-114.d1.club-internet.fr ([212.194.54.114] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 18yIkH-0005oK-00 for ietf-openproxy@imc.org; Wed, 26 Mar 2003 13:47:42 -0800 Message-Id: <5.2.0.9.0.20030326222034.029e86c0@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 26 Mar 2003 22:54:43 +0100 To: ietf-openproxy@imc.org From: jfcm Subject: RE: copying commitment and deadlock In-Reply-To: References: <200303261824.h2QIO4905754@localhost.localdomain> <200303261824.h2QIO4905754@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 19:51 26/03/03, Alex Rousskov said: > > I think that the comment below refers to applying dispatch rules to > > the result of a dispatch. I.e., assume the content is two parts, > > {A,B}. That content triggers a modification to part B, resulting in > > {A,B'}. The dispatch rules applied to {A,B'} trigger a modifiction to > > A, resulting in {A',B'}. > >OK. This seems to have nothing to do with OCP. This is about rule >processing, right? No. the question was about a message definition and copying. I say you have two chuncks A and B. What may make or not one single message. (In between you responded that the message definition was application dependent - what I have to digest as not my own thinking). The first dispatch rule leaves A untouched, so A can be sent. Now the second rule says that A is to be modified. I did not say where the second dispatch rule is applied. It can be on a cascading dispatcher or a loop back into the first dispatcher before sending. Depends on the modelization. Where am I to find A depending on the cases? - it may have been sent - if there are considered as 2 messages - it may have been copied to a server and not returned since unchanged - it may have been copied back - it may not have been copied to the precedeing service I do not think it is complex but it needs to be made clear. Because we may certainly find cases where it is complex. jfc From owner-ietf-openproxy@mail.imc.org Wed Mar 26 18:30: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 SAA22349 for ; Wed, 26 Mar 2003 18:30:29 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2QN98m15043 for ietf-openproxy-bks; Wed, 26 Mar 2003 15:09:08 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2QN96g15039 for ; Wed, 26 Mar 2003 15:09:07 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h2QN9Enx055587; Wed, 26 Mar 2003 16:09:14 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h2QN9E0h055586; Wed, 26 Mar 2003 16:09:14 -0700 (MST) (envelope-from rousskov) Date: Wed, 26 Mar 2003 16:09:14 -0700 (MST) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: RE: copying commitment and deadlock In-Reply-To: <5.2.0.9.0.20030326222034.029e86c0@mail.utel.net> Message-ID: References: <200303261824.h2QIO4905754@localhost.localdomain> <200303261824.h2QIO4905754@localhost.localdomain> <5.2.0.9.0.20030326222034.029e86c0@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, 26 Mar 2003, jfcm wrote: > On 19:51 26/03/03, Alex Rousskov said: > > > > I think that the comment below refers to applying dispatch rules to > > > the result of a dispatch. I.e., assume the content is two parts, > > > {A,B}. That content triggers a modification to part B, resulting in > > > {A,B'}. The dispatch rules applied to {A,B'} trigger a modifiction to > > > A, resulting in {A',B'}. > > > >OK. This seems to have nothing to do with OCP. This is about rule > >processing, right? > > No. the question was about a message definition and copying. .. and copying is pretty much unrelated to an application message definition! OCP dispatcher copies bytes (opaque message chunks), not application messages. > I say you have two chuncks A and B. What may make or not one single > message. OK. A single application message may be received and handled by OCP in chunks. Each chunk belongs to one and only one application message. > (In between you responded that the message definition was > application dependent - what I have to digest as not my own > thinking). Since [copied] flag applies to data chunks (not entire application messages), the definition of a message seems to be irrelevant. Application message definition is application dependent, by its very nature (by definition if you will). I am not sure how you can have it any other way. Care to explain? For example, RFC 2616 defines what an HTTP/1.1 message is. No other spec defines that. However, OPES and OCP are application agnostic. Whatever the message is, OCP treats it as a bunch of opaque bytes. We just need to know the message boundaries, nothing else. > The first dispatch rule leaves A untouched, so A can be sent. > Now the second rule says that A is to be modified. You said above that "A" is a chunk. I think that rules should not be applied to chunks, only messages, but it probably does not matter for this discussion. > I did not say where the second dispatch rule is applied. It can be > on a cascading dispatcher or a loop back into the first dispatcher > before sending. Depends on the modelization. IMO, OCP takes place when a single rule is applied to a single application message. It does not really matter (from OCP point of view) what happens before or after that. There might be 10 more rules, but OCP does not know that and does not care. Why are you talking about multiple rules in an OCP copying context? What is the relation of rules to copying? > Where am I to find A depending on the cases? > - it may have been sent - if there are considered as 2 messages > - it may have been copied to a server and not returned since unchanged > - it may have been copied back > - it may not have been copied to the precedeing service > > I do not think it is complex but it needs to be made clear. > Because we may certainly find cases where it is complex. I do not know what you mean by "finding A". If "A" is a message, then it may not have a single "location" because it is comprised of opaque chunks, and each chunk may be at a different processing stage/location. Recall that we are trying to use a pipeline model here; each chunk will be at some processing point of the pipeline. Moreover, until the pipe ends, it may be impossible to reassemble A from "current" chunks because each chunk may be at a different processing stage. Only when all processing stages are complete, you can have a complete application message again. Furthermore, since the application message chunks may be sent out as they "arrive" from the pipe, there can be no single point in time where an OPES system sees a complete application message. Finding message "A" is not possible, in general! This is true for HTTP non-caching proxies, for example. Alex. From owner-ietf-openproxy@mail.imc.org Thu Mar 27 08:16: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 IAA27979 for ; Thu, 27 Mar 2003 08:16:53 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2RCsUT12553 for ietf-openproxy-bks; Thu, 27 Mar 2003 04:54:30 -0800 (PST) Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2RCsSg12546 for ; Thu, 27 Mar 2003 04:54:29 -0800 (PST) Received: from f05v-1-206.d1.club-internet.fr ([212.194.84.206] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 18yWtl-0004Jq-00; Thu, 27 Mar 2003 04:54:25 -0800 Message-Id: <5.2.0.9.0.20030327135322.030a8c40@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 27 Mar 2003 14:01:08 +0100 To: Alex Rousskov , ietf-openproxy@imc.org From: jfcm Subject: RE: copying commitment and deadlock In-Reply-To: References: <5.2.0.9.0.20030326222034.029e86c0@mail.utel.net> <200303261824.h2QIO4905754@localhost.localdomain> <200303261824.h2QIO4905754@localhost.localdomain> <5.2.0.9.0.20030326222034.029e86c0@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: hmmm... you will excuse me, but this response seems contradictory to me (you seem to both question and document my questions). I will then drop the debate here. I will continue to listen and to look for what I may use in pratical, real life development specifications and tests. jfc At 00:09 27/03/03, Alex Rousskov wrote: >On Wed, 26 Mar 2003, jfcm wrote: > > > On 19:51 26/03/03, Alex Rousskov said: > > > > > > I think that the comment below refers to applying dispatch rules to > > > > the result of a dispatch. I.e., assume the content is two parts, > > > > {A,B}. That content triggers a modification to part B, resulting in > > > > {A,B'}. The dispatch rules applied to {A,B'} trigger a modifiction to > > > > A, resulting in {A',B'}. > > > > > >OK. This seems to have nothing to do with OCP. This is about rule > > >processing, right? > > > > No. the question was about a message definition and copying. > >.. and copying is pretty much unrelated to an application message >definition! OCP dispatcher copies bytes (opaque message chunks), not >application messages. > > > I say you have two chuncks A and B. What may make or not one single > > message. > >OK. A single application message may be received and handled by OCP in >chunks. Each chunk belongs to one and only one application message. > > > (In between you responded that the message definition was > > application dependent - what I have to digest as not my own > > thinking). > >Since [copied] flag applies to data chunks (not entire application >messages), the definition of a message seems to be irrelevant. > >Application message definition is application dependent, by its very >nature (by definition if you will). I am not sure how you can have it >any other way. Care to explain? For example, RFC 2616 defines what an >HTTP/1.1 message is. No other spec defines that. However, OPES and OCP >are application agnostic. Whatever the message is, OCP treats it as a >bunch of opaque bytes. We just need to know the message boundaries, >nothing else. > > > The first dispatch rule leaves A untouched, so A can be sent. > > Now the second rule says that A is to be modified. > >You said above that "A" is a chunk. I think that rules should not be >applied to chunks, only messages, but it probably does not matter for >this discussion. > > > I did not say where the second dispatch rule is applied. It can be > > on a cascading dispatcher or a loop back into the first dispatcher > > before sending. Depends on the modelization. > >IMO, OCP takes place when a single rule is applied to a single >application message. It does not really matter (from OCP point of >view) what happens before or after that. There might be 10 more rules, >but OCP does not know that and does not care. Why are you talking >about multiple rules in an OCP copying context? What is the relation >of rules to copying? > > > Where am I to find A depending on the cases? > > - it may have been sent - if there are considered as 2 messages > > - it may have been copied to a server and not returned since unchanged > > - it may have been copied back > > - it may not have been copied to the precedeing service > > > > I do not think it is complex but it needs to be made clear. > > Because we may certainly find cases where it is complex. > >I do not know what you mean by "finding A". If "A" is a message, then >it may not have a single "location" because it is comprised of opaque >chunks, and each chunk may be at a different processing >stage/location. Recall that we are trying to use a pipeline model >here; each chunk will be at some processing point of the pipeline. > >Moreover, until the pipe ends, it may be impossible to reassemble A >from "current" chunks because each chunk may be at a different >processing stage. Only when all processing stages are complete, you >can have a complete application message again. Furthermore, since the >application message chunks may be sent out as they "arrive" from the >pipe, there can be no single point in time where an OPES system sees a >complete application message. Finding message "A" is not possible, in >general! This is true for HTTP non-caching proxies, for example. > >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 Fri Mar 28 13:05: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 NAA10284 for ; Fri, 28 Mar 2003 13:05:32 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2SHNGS08300 for ietf-openproxy-bks; Fri, 28 Mar 2003 09:23:16 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2SHNEg08294 for ; Fri, 28 Mar 2003 09:23:14 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h2SHNGnx015350 for ; Fri, 28 Mar 2003 10:23:16 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h2SHNFf5015349; Fri, 28 Mar 2003 10:23:15 -0700 (MST) (envelope-from rousskov) Date: Fri, 28 Mar 2003 10:23:15 -0700 (MST) From: Alex Rousskov To: OPES Group Subject: Re: Protocol next steps In-Reply-To: <3E7B2E45.5080008@mhof.com> Message-ID: References: <3E7B2E45.5080008@mhof.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-466690894-1048872076=:12867" Content-ID: Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-466690894-1048872076=:12867 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: -- re-sending: the original posting probably exceeded list's posting size limit On Fri, 21 Mar 2003, Markus Hofmann wrote: > Alex agreed to put the pre-draft ideas into the form of an Internet > Draft. Once this is done, he'll send it out to the OPES mailing > list, and the WG has to decide whether we want to adopt this as WG > document right away, or what would have to be done to adopt this as > WG document (in which case the draft might be published as > individual submission, first, and WG document later). Based on this > draft, the WG wil lthen decide on the protocol bindings. Attached is a plain text version of the OCP draft(*). The document is currently formated as an individual submission. As Markus has explained above, the working group has to decide how to move forward with it. There are obviously many XXXs, missing and ugly parts in the draft, but the overall shape of the protocol should be visible. I think it is time to make this a reference point before we proceed with bindings and with solving specific protocol issues. The predraft document I have been working on is no longer good enough because external reviewers/helpers do not know about it and because it is time to document consensus. Since this draft is not yet a product of the working group, nothing it currently contains implies consensus. Everything is subject to a discussion and change. I just documented what we have discussed on the list and made several subjective decisions where some decisions were needed to build a coherent protocol spec. Again, we now need to decide whether the draft should be submitted as a working group draft. If there are some modifications that must happen first, please let me know, but let's not argue too much about specifics until the draft is published (so that we have a clear reference point). Thank you, Alex. (*) If you prefer HTML rendering of the same draft, it is temporary available at http://www.measurement-factory.com/tmp/opes/ --0-466690894-1048872076=:12867 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="draft-rousskov-opes-ocp-00.txt" Content-ID: Content-Description: draft-rousskov-opes-ocp-00.txt Content-Disposition: ATTACHMENT; FILENAME="draft-rousskov-opes-ocp-00.txt" Content-Transfer-Encoding: BASE64 DQoNCk9wZW4gUGx1Z2dhYmxlIEVkZ2UgU2VydmljZXMgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBBLiBSb3Vzc2tvdg0KSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRoZSBNZWFz dXJlbWVudCBGYWN0b3J5DQpFeHBpcmVzOiBTZXB0ZW1iZXIgMjksIDIwMDMg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTWFyY2ggMzEsIDIwMDMN Cg0KDQogICAgICAgICAgICAgICAgICAgICAgT1BFUyBDYWxsb3V0IFByb3Rv Y29sIChPQ1ApDQogICAgICAgICAgICAgICAgICAgICAgIGRyYWZ0LXJvdXNz a292LW9wZXMtb2NwLTAwDQoNClN0YXR1cyBvZiB0aGlzIE1lbW8NCg0KICAg VGhpcyBkb2N1bWVudCBpcyBhbiBJbnRlcm5ldC1EcmFmdCBhbmQgaXMgaW4g ZnVsbCBjb25mb3JtYW5jZSB3aXRoDQogICBhbGwgcHJvdmlzaW9ucyBvZiBT ZWN0aW9uIDEwIG9mIFJGQzIwMjYuDQoNCiAgIEludGVybmV0LURyYWZ0cyBh cmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVy aW5nDQogICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRz IHdvcmtpbmcgZ3JvdXBzLiBOb3RlIHRoYXQgb3RoZXINCiAgIGdyb3VwcyBt YXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVy bmV0LURyYWZ0cy4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBk b2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzDQog ICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQg Ynkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQ0KICAgdGltZS4gSXQgaXMgaW5h cHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5j ZQ0KICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMg IndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQogICBUaGUgbGlzdCBvZiBjdXJyZW50 IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQgaHR0cDovLw0K ICAgd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQuDQoNCiAg IFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3Rvcmll cyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcv c2hhZG93Lmh0bWwuDQoNCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBl eHBpcmUgb24gU2VwdGVtYmVyIDI5LCAyMDAzLg0KDQpDb3B5cmlnaHQgTm90 aWNlDQoNCiAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkg KDIwMDMpLiBBbGwgUmlnaHRzIFJlc2VydmVkLg0KDQpBYnN0cmFjdA0KDQog ICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBPcGVuIFBsdWdnYWJsZSBFZGdl IFNlcnZpY2VzIChPUEVTKSBjYWxsb3V0DQogICBwcm90b2NvbCAoT0NQKS4g T0NQIHN1cHBvcnRzIHRoZSByZW1vdGUgZXhlY3V0aW9uIG9mIE9QRVMgc2Vy dmljZXMuDQogICBUaGlzIE9DUCBzcGVjaWZpY2F0aW9uIGlzIGluY29tcGxl dGUgYW5kIGNhbm5vdCBiZSB1c2VkIGZvcg0KICAgaW1wbGVtZW50aW5nIHRo ZSBwcm90b2NvbCB5ZXQuIE1ham9yIG1pc3NpbmcgcGllY2VzIGFyZSB0cmFu c3BvcnQNCiAgIGJpbmRpbmcocykgYW5kIG1lc3NhZ2UgZW5jb2Rpbmcocyku DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUm91c3Nrb3YgICAgICAgICAgICAg ICBFeHBpcmVzIFNlcHRlbWJlciAyOSwgMjAwMyAgICAgICAgICAgICAgIFtQ YWdlIDFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgT1BFUyBDYWxsb3V0 IFByb3RvY29sIChPQ1ApICAgICAgICAgICAgIE1hcmNoIDIwMDMNCg0KDQpU YWJsZSBvZiBDb250ZW50cw0KDQogICAxLiAgIEludHJvZHVjdGlvbiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg IDMNCiAgIDEuMSAgVGVybWlub2xvZ3kgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMw0KICAgMS4yICBPdmVy YWxsIE9wZXJhdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gICA0DQogICAxLjMgIFByb3RvY29sIERldmVsb3BtZW50 IFN0YXR1cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQN CiAgIDIuICAgTWVzc2FnZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNg0KICAgMy4gICBUcmFuc2Fj dGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gICA3DQogICA0LiAgIENvbm5lY3Rpb25zICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDgNCiAg IDUuICAgTWVzc2FnZSBQYXJhbWV0ZXIgRGVmaW5pdGlvbnMgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgOQ0KICAgNi4gICBNZXNzYWdlIERl ZmluaXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gIDExDQogICA2LjEgIGNvbm5lY3Rpb24tc3RhcnQgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTENCiAgIDYu MiAgY29ubmVjdGlvbi1lbmQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAxMg0KICAgNi4zICBjb25uZWN0aW9uLXBy aW9yaXR5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDEyDQogICA2LjQgIGNvbm5lY3Rpb24tc2VydmljZSAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTINCiAgIDYuNSAg eGFjdGlvbi1zdGFydCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAxMg0KICAgNi42ICB4YWN0aW9uLWVuZCAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDEyDQogICA2LjcgIGFwcC1tZXNzYWdlLXN0YXJ0ICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTMNCiAgIDYuOCAgYXBw LW1lc3NhZ2UtZW5kICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAxMw0KICAgNi45ICBkYXRhLWhhdmUgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEz DQogICA2LjEwIGRhdGEtYXMtaXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTQNCiAgIDYuMTEgZGF0YS1w YXVzZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAxNA0KICAgNi4xMiBkYXRhLWVuZCAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE1DQog ICA2LjEzIGRhdGEtbmVlZCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTUNCiAgIDYuMTQgZGF0YS1hY2sg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAxNQ0KICAgNi4xNSBpLWFtLWhlcmUgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE2DQogICA2 LjE2IGFyZS15b3UtdGhlcmUgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgMTYNCiAgIDYuMTcgZG8teW91LXN1cHBv cnQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAxNw0KICAgNi4xOCBpLWRvLXN1cHBvcnQgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE3DQogICA2LjE5 IGktZG9udC1zdXBwb3J0IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgMTcNCiAgIDYuMjAgcGxlYXNlLXVzZSAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAxNw0KICAgNi4yMSBpLXdpbGwtdXNlIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE3DQogICA2LjIyIGkt d29udC11c2UgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgMTcNCiAgIDcuICAgQXBwbGljYXRpb24gUHJvdG9j b2wgUmVxdWlyZW1lbnRzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAx OA0KICAgOC4gICBJQUIgQ29uY2VybnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE5DQogICA5LiAgIFNlY3Vy aXR5IENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgMjANCiAgIDEwLiAgQ29tcGxpYW5jZSAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyMQ0K ICAgMTEuICBUby1kbyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDIyDQogICAgICAgIE5vcm1hdGl2 ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgMjQNCiAgICAgICAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyNQ0KICAg ICAgICBBdXRob3IncyBBZGRyZXNzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDI1DQogICAgICAgIEludGVsbGVjdHVh bCBQcm9wZXJ0eSBhbmQgQ29weXJpZ2h0IFN0YXRlbWVudHMgLiAuIC4gLiAu IC4gLiAgMjYNCg0KDQoNCg0KDQoNCg0KDQoNClJvdXNza292ICAgICAgICAg ICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjksIDIwMDMgICAgICAgICAgICAg ICBbUGFnZSAyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgIE9QRVMgQ2Fs bG91dCBQcm90b2NvbCAoT0NQKSAgICAgICAgICAgICBNYXJjaCAyMDAzDQoN Cg0KMS4gSW50cm9kdWN0aW9uDQoNCiAgIFRoZSBPcGVuIFBsdWdnYWJsZSBF ZGdlIFNlcnZpY2VzIChPUEVTKSBhcmNoaXRlY3R1cmUNCiAgIFtJLUQuaWV0 Zi1vcGVzLWFyY2hpdGVjdHVyZV0sIGVuYWJsZXMgY29vcGVyYXRpdmUgYXBw bGljYXRpb24NCiAgIHNlcnZpY2VzIChPUEVTIHNlcnZpY2VzKSBiZXR3ZWVu IGEgZGF0YSBwcm92aWRlciwgYSBkYXRhIGNvbnN1bWVyLA0KICAgYW5kIHpl cm8gb3IgbW9yZSBPUEVTIHByb2Nlc3NvcnMuICBUaGUgYXBwbGljYXRpb24g c2VydmljZXMgdW5kZXINCiAgIGNvbnNpZGVyYXRpb24gYW5hbHl6ZSBhbmQg cG9zc2libHkgdHJhbnNmb3JtIGFwcGxpY2F0aW9uLWxldmVsDQogICBtZXNz YWdlcyBleGNoYW5nZWQgYmV0d2VlbiB0aGUgZGF0YSBwcm92aWRlciBhbmQg dGhlIGRhdGEgY29uc3VtZXIuDQoNCiAgIFRoZSBleGVjdXRpb24gb2Ygc3Vj aCBzZXJ2aWNlcyBpcyBnb3Zlcm5lZCBieSBhIHNldCBvZiBydWxlcw0KICAg aW5zdGFsbGVkIG9uIHRoZSBPUEVTIHByb2Nlc3Nvci4gIFRoZSBydWxlcyBl bmZvcmNlbWVudCBjYW4gdHJpZ2dlcg0KICAgdGhlIGV4ZWN1dGlvbiBvZiBz ZXJ2aWNlIGFwcGxpY2F0aW9ucyBsb2NhbCB0byB0aGUgT1BFUyBwcm9jZXNz b3IuDQogICBBbHRlcm5hdGl2ZWx5LCB0aGUgT1BFUyBwcm9jZXNzb3IgY2Fu IGRpc3RyaWJ1dGUgdGhlIHJlc3BvbnNpYmlsaXR5DQogICBvZiBzZXJ2aWNl IGV4ZWN1dGlvbiBieSBjb21tdW5pY2F0aW5nIGFuZCBjb2xsYWJvcmF0aW5n IHdpdGggb25lIG9yDQogICBtb3JlIHJlbW90ZSBjYWxsb3V0IHNlcnZlcnMu IEFzIGRlc2NyaWJlZCBpbg0KICAgW0ktRC5pZXRmLW9wZXMtcHJvdG9jb2wt cmVxc10sIGFuIE9QRVMgcHJvY2Vzc29yIGNvbW11bmljYXRlcyB3aXRoDQog ICBhbmQgaW52b2tlcyBzZXJ2aWNlcyBvbiBhIGNhbGxvdXQgc2VydmVyIGJ5 IHVzaW5nIGEgY2FsbG91dCBwcm90b2NvbC4NCiAgIFRoaXMgZG9jdW1lbnQg c3BlY2lmaWVzIHN1Y2ggYSBwcm90b2NvbC4NCg0KMS4xIFRlcm1pbm9sb2d5 DQoNCiAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVR VUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwNCiAgICJTSE9VTEQiLCAi U0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElP TkFMIiBpbiB0aGlzDQogICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0 ZWQgYXMgZGVzY3JpYmVkIGluIFtSRkMyMTE5XS4NCg0KICAgT0NQIHdvcmtz IG9uIG1lc3NhZ2VzIGZyb20gYXBwbGljYXRpb24gcHJvdG9jb2xzLiBQcm90 b2NvbCBlbGVtZW50cw0KICAgbGlrZSAibWVzc2FnZSIsICJjb25uZWN0aW9u Iiwgb3IgInRyYW5zYWN0aW9uIiBleGlzdCBpbiBPQ1AgYW5kDQogICBhcHBs aWNhdGlvbiBwcm90b2NvbHMuICBJbiB0aGlzIHNwZWNpZmljYXRpb24sIGFs bCByZWZlcmVuY2VzIHRvDQogICBlbGVtZW50cyBmcm9tIGFwcGxpY2F0aW9u IHByb3RvY29scyBhcmUgdXNlZCB3aXRoIGFuIGV4cGxpY2l0DQogICAiYXBw bGljYXRpb24iIHF1YW50aWZpZXIuIFJlZmVyZW5jZXMgd2l0aG91dCB0aGUg ImFwcGxpY2F0aW9uIg0KICAgcXVhbnRpZmllciwgcmVmZXIgdG8gT0NQIGVs ZW1lbnRzLiAoWFhYOiBTb21lIE9DUCBlbGVtZW50cyBhcmUgY2FsbGVkDQog ICAiY2FsbG91dCIgZWxlbWVudHMgaW4gdGhlIE9DUCByZXF1aXJlbWVudHMg ZG9jdW1lbnQuIFdlIGFzc3VtZSB0aGF0DQogICBPQ1AgaXMgZXF1aXZhbGVu dCB0byAiY2FsbG91dCIgaW4gdGhpcyBjb250ZXh0LiBGb3IgZXhhbXBsZSwg T0NQDQogICBjb25uZWN0aW9uIGlzIHRoZSBzYW1lIGFzIGNhbGxvdXQgY29u bmVjdGlvbi4gU2hvdWxkIHdlIGJlIG1vcmUNCiAgIGNvbnNpc3RlbnQ/KQ0K DQogICBhcHBsaWNhdGlvbiBtZXNzYWdlOiBBIHNlcXVlbmNlIG9mIG9jdGV0 cyB0aGF0IE9QRVMgcHJvY2Vzc29yDQogICAgICBkZXNpZ25hdGVzIGZvciBj YWxsb3V0IHNlcnZpY2UgcHJvY2Vzc2luZy4gIFVzdWFsbHksIGFuDQogICAg ICBhcHBsaWNhdGlvbiBtZXNzYWdlIGlzIHRoZSBiYXNpYyB1bml0IG9mIGFw cGxpY2F0aW9uIHByb3RvY29sDQogICAgICBjb21tdW5pY2F0aW9uLCBhcyBk ZWZpbmVkIGJ5IHRoYXQgYXBwbGljYXRpb24gcHJvdG9jb2wgKGUuZy4sDQog ICAgICBIVFRQLzEuMSBtZXNzYWdlKS4gIEJlZm9yZSBPQ1AgaXMgYXBwbGll ZCwgT1BFUyBwcm9jZXNzb3IgbWF5DQogICAgICBwcmUtcHJvY2VzcyByYXcg YXBwbGljYXRpb24gbWVzc2FnZXMgdG8gZXh0cmFjdCBhbmQgbWFuaXB1bGF0 ZQ0KICAgICAgd2VsbC1rbm93biBwYXJ0cyAoZS5nLiwgSFRUUCBtZXNzYWdl IGhlYWRlcnMgb3IgU01UUCBtZXNzYWdlIGJvZHkpDQogICAgICBpbiBvcmRl ciB0byBzdWJqZWN0IGp1c3QgdGhvc2UgcGFydHMgdG8gY2FsbG91dCBzZXJ2 aWNlcy4gRm9yIHRoZQ0KICAgICAgcHVycG9zZSBvZiBPQ1AsIHRoZSByZXN1 bHQgb2Ygc3VjaCBwcmVwcm9jZXNzaW5nIGlzIGFuIGFwcGxpY2F0aW9uDQog ICAgICBtZXNzYWdlLiBOYXR1cmFsbHksIE9QRVMgcHJvY2Vzc29yIGFuZCBj YWxsb3V0IHNlcnZpY2VzIGl0IGlzDQogICAgICBjb25maWd1cmVkIHRvIHVz ZSBtdXN0IGFncmVlIG9uIHdoYXQgYXBwbGljYXRpb24gbWVzc2FnZXMgYXJl DQogICAgICBhY2NlcHRhYmxlLiBFc3RhYmxpc2hpbmcgc3VjaCBhbiBhZ3Jl ZW1lbnQgaXMgYmV5b25kIE9DUCBzY29wZS4NCg0KDQoNClJvdXNza292ICAg ICAgICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjksIDIwMDMgICAgICAg ICAgICAgICBbUGFnZSAzXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgIE9Q RVMgQ2FsbG91dCBQcm90b2NvbCAoT0NQKSAgICAgICAgICAgICBNYXJjaCAy MDAzDQoNCg0KICAgYXBwbGljYXRpb24gZGF0YTogT3BhcXVlIGFwcGxpY2F0 aW9uIG1lc3NhZ2Ugb2N0ZXRzLg0KDQogICBkYXRhOiBTYW1lIGFzIGFwcGxp Y2F0aW9uIGRhdGEuDQoNCiAgIENMSUVOVDogT1BFUyBwcm9jZXNzb3IgKFhY WDogb3IgT1BFUyBkaXNwYXRjaGVyPykuDQoNCiAgIFNFUlZFUjogT1BFUyBj YWxsb3V0IHNlcnZlci4NCg0KICAgKFhYWDogd2Ugc2hvdWxkIHJlcGxhY2Ug Q0xJRU5UIGFuZCBTRVJWRVIgcGxhY2Vob2xkZXJzIGluIHRoZSB0ZXh0DQog ICB3aXRoIHRoZWlyIGRlZmluaXRpb25zIG9uY2UgdGhlIENMSUVOVCBkZWZp bml0aW9uIGJlY29tZXMgc3RhYmxlKQ0KDQoxLjIgT3ZlcmFsbCBPcGVyYXRp b24NCg0KICAgT1BFUyBwcm9jZXNzb3IgZXN0YWJsaXNoZXMgT1BFUyBjb25u ZWN0aW9ucyB3aXRoIGNhbGxvdXQgc2VydmVycyBmb3INCiAgIHRoZSBwdXJw b3NlIG9mIGZvcndhcmRpbmcgYXBwbGljYXRpb24gbWVzc2FnZXMgYW5kIG1l dGEtaW5mb3JtYXRpb24NCiAgIHRvIHRoZSBjYWxsb3V0IHNlcnZlcihzKS4g QSBjYWxsb3V0IHNlcnZlciBtYXkgc2VuZCB0aGlzIGRhdGEgYmFjayB0bw0K ICAgdGhlIE9QRVMgcHJvY2Vzc29yLCB3aXRoIG9yIHdpdGhvdXQgbW9kaWZp Y2F0aW9ucy4gVW5kZXIgY2VydGFpbg0KICAgY29uZGl0aW9ucywgYSBjYWxs b3V0IHNlcnZlciBtYXkgcmVtb3ZlIGl0c2VsZiBmcm9tIHRoZSBhcHBsaWNh dGlvbg0KICAgbWVzc2FnZSBwcm9jZXNzaW5nIGxvb3AuIE9QRVMgcHJvY2Vz c29yIGFuZCBjYWxsb3V0IHNlcnZlciBtYXkNCiAgIGV4Y2hhbmdlIE9DUCBt ZXNzYWdlcyByZWxhdGVkIHRvIHRoZWlyIGNvbmZpZ3VyYXRpb24gYW5kIHN0 YXRlIGJ1dA0KICAgdW5yZWxhdGVkIHRvIHNwZWNpZmljIGFwcGxpY2F0aW9u IG1lc3NhZ2VzLiBBIHNpbmdsZSBPUEVTIHByb2Nlc3Nvcg0KICAgY2FuIGNv bW11bmljYXRlIHdpdGggbWFueSBjYWxsb3V0IHNlcnZlcnMgYW5kIHZpY2Ug dmVyc2EuICBUaGUgT1BFUw0KICAgYXJjaGl0ZWN0dXJlIGRvY3VtZW50IFtJ LUQuaWV0Zi1vcGVzLWFyY2hpdGVjdHVyZV0gZGVzY3JpYmVzIG92ZXJhbGwN CiAgIG9wZXJhdGlvbiBpbiBkZXRhaWwuDQoNCiAgIFRoZSBwcmltYXJ5IHB1 cnBvc2Ugb2YgT0NQIGNvbW11bmljYXRpb25zIGlzIG1vZGlmaWNhdGlvbiBv Zg0KICAgYXBwbGljYXRpb24gbWVzc2FnZSBwYXlsb2Fkcy4gTW9kaWZpY2F0 aW9uIG9mIGFwcGxpY2F0aW9uIG1lc3NhZ2UNCiAgIGhlYWRlcnMgaXMgYWxz byBwb3NzaWJsZSBhbmQgb2Z0ZW4gcmVxdWlyZWQgdG8ga2VlcCB0aGUgaGVh ZGVycyBpbg0KICAgc3luYyB3aXRoIG1vZGlmaWVkIGFwcGxpY2F0aW9uIHBh eWxvYWQuIEZ1cnRoZXJtb3JlLCBPQ1AgY2FuIGJlIHVzZWQNCiAgIHRvIGNo YW5nZSB0aGUgYXBwbGljYXRpb24gaW5mb3JtYXRpb24gYmV5b25kIHdoYXQg bWF5IG5vdCBiZQ0KICAgZXhwbGljaXRseSBlbmNvZGVkIGluIGFuIGFwcGxp Y2F0aW9uIG1lc3NhZ2Ugc3VjaCBhcyBzb3VyY2Ugb3INCiAgIGRlc3RpbmF0 aW9uIGFkZHJlc3Nlcy4NCg0KICAgT0NQIGlzIGFwcGxpY2F0aW9uIGFnbm9z dGljIGFuZCBzaG91bGQgYXBwbHkgd2VsbCB0byBkaWZmZXJlbnQNCiAgIGFw cGxpY2F0aW9uIHByb3RvY29scyBzdWNoIGFzIEhUVFAsIFNNVFAsIGFuZCBS VFNQLiBOYXR1cmFsbHksIG5vdA0KICAgZXZlcnkgYXBwbGljYXRpb24gcHJv dG9jb2wgY2FuIGJlIHVzZWQgd2l0aCBPQ1AuIFRoaXMgc3BlY2lmaWNhdGlv bg0KICAgZG9jdW1lbnRzIGtub3duIGFwcGxpY2F0aW9uIHNjb3BlIGxpbWl0 YXRpb25zIGluIHRoZSAiQXBwbGljYXRpb24NCiAgIFByb3RvY29sIFJlcXVp cmVtZW50cyIgU2VjdGlvbiBbWFhYXS4NCg0KMS4zIFByb3RvY29sIERldmVs b3BtZW50IFN0YXR1cw0KDQogICBTZXZlcmFsIGltcG9ydGFudCBPQ1AgZGV0 YWlscyBhcmUgc3RpbGwgdW5rbm93bi4gT0NQIHRyYW5zcG9ydA0KICAgcHJv dG9jb2wocykgaGF2ZSBub3QgYmVlbiBzZWxlY3RlZC4gRW5jb2Rpbmcgb2Yg T0NQIG1lc3NhZ2VzIGlzIG5vdA0KICAgeWV0IGRvY3VtZW50ZWQuIFRoaXMg c3BlY2lmaWNhdGlvbiBpcyBub3QgeWV0IHN1aXRhYmxlIGZvciB3cml0aW5n DQogICBPQ1AgaW1wbGVtZW50YXRpb25zLg0KDQogICBUaGUgcGxhbiBpcyB0 byBhZGQgbmVjZXNzYXJ5IGRldGFpbHMgYW5kIGJpbmRpbmdzIHRvIHRoZSBm dXR1cmUNCiAgIHZlcnNpb25zIG9mIHRoaXMgZG9jdW1lbnQgdW50aWwgdGhl IHNwZWNpZmljYXRpb24gaXMgY29tcGxldGUuIFRoZQ0KDQoNCg0KUm91c3Nr b3YgICAgICAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAyOSwgMjAwMyAg ICAgICAgICAgICAgIFtQYWdlIDRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg ICAgT1BFUyBDYWxsb3V0IFByb3RvY29sIChPQ1ApICAgICAgICAgICAgIE1h cmNoIDIwMDMNCg0KDQogICBUby1kbyBTZWN0aW9uIFtYWFhdIGNvbnRhaW5z IGEgbGlzdCBvZiB0by1iZS1pbXBsZW1lbnRlZCBpdGVtcy4NCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQpSb3Vzc2tvdiAgICAgICAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDI5 LCAyMDAzICAgICAgICAgICAgICAgW1BhZ2UgNV0NCgwNCkludGVybmV0LURy YWZ0ICAgICAgICBPUEVTIENhbGxvdXQgUHJvdG9jb2wgKE9DUCkgICAgICAg ICAgICAgTWFyY2ggMjAwMw0KDQoNCjIuIE1lc3NhZ2VzDQoNCiAgIE9DUCBt ZXNzYWdlIGlzIGEgYmFzaWMgdW5pdCBvZiBjb21tdW5pY2F0aW9uIGJldHdl ZW4gYSBDTElFTlQgYW5kIGENCiAgIFNFUlZFUi4gTWVzc2FnZSBpcyBhIHNl cXVlbmNlIG9mIG9jdGV0cyBmb3JtYXR0ZWQgYWNjb3JkaW5nIHRvIHN5bnRh eA0KICAgcnVsZXMgZGVmaW5lZCBpbiBTZWN0aW9uIFhYWC4gTWVzc2FnZSBz ZW1hbnRpY3MgaXMgZGVmaW5lZCBpbiBTZWN0aW9uDQogICBYWFguIE1lc3Nh Z2VzIGFyZSB0cmFuc21pdHRlZCBvdmVyIE9DUCBjb25uZWN0aW9ucy4NCg0K ICAgT0NQIG1lc3NhZ2VzIGRlYWwgd2l0aCBjb25uZWN0aW9uIGFuZCB0cmFu c2FjdGlvbiBtYW5hZ2VtZW50IGFzIHdlbGwNCiAgIGFzIGFwcGxpY2F0aW9u IGRhdGEgZXhjaGFuZ2UgYmV0d2VlbiBhIHNpbmdsZSBDTElFTlQgYW5kIGEg c2luZ2xlDQogICBTRVJWRVIuIFNvbWUgbWVzc2FnZXMgY2FuIG9ubHkgYmUg ZW1pdHRlZCBieSBhIENMSUVOVDsgc29tZSBvbmx5IGJ5IGENCiAgIFNFUlZF Ujsgc29tZSBjYW4gYmUgZW1pdHRlZCBieSBib3RoIENMSUVOVCBhbmQgU0VS VkVSLiBTb21lIG1lc3NhZ2VzDQogICByZXF1aXJlIHJlc3BvbnNlcyAob25l IGNvdWxkIGNhbGwgc3VjaCBtZXNzYWdlcyAicmVxdWVzdHMiKTsgc29tZSBj YW4NCiAgIG9ubHkgYmUgdXNlZCBpbiByZXNwb25zZSB0byBvdGhlciBtZXNz YWdlcyAoInJlc3BvbnNlcyIpOyBzb21lIG1heSBiZQ0KICAgc2VudCB3aXRo b3V0IHNvbGljaXRhdGlvbiBhbmQvb3IgbWF5IG5vdCByZXF1aXJlIGEgcmVz cG9uc2UuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClJvdXNza292 ICAgICAgICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjksIDIwMDMgICAg ICAgICAgICAgICBbUGFnZSA2XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAg IE9QRVMgQ2FsbG91dCBQcm90b2NvbCAoT0NQKSAgICAgICAgICAgICBNYXJj aCAyMDAzDQoNCg0KMy4gVHJhbnNhY3Rpb25zDQoNCiAgIE9DUCB0cmFuc2Fj dGlvbiBpcyBhIGxvZ2ljYWwgc2VxdWVuY2Ugb2YgT0NQIG1lc3NhZ2VzIHBy b2Nlc3NpbmcgYQ0KICAgc2luZ2xlIG9yaWdpbmFsIGFwcGxpY2F0aW9uIG1l c3NhZ2UuIFRoZSByZXN1bHQgb2YgdGhlIHByb2Nlc3NpbmcgbWF5DQogICBi ZSB6ZXJvIG9yIG1vcmUgYXBwbGljYXRpb24gbWVzc2FnZXMsIGFkYXB0ZWQg ZnJvbSB0aGUgb3JpZ2luYWwuIEENCiAgIHR5cGljYWwgdHJhbnNhY3Rpb24g Y29uc2lzdHMgb2YgdHdvIG1lc3NhZ2UgZmxvd3M6IGEgZmxvdyBmcm9tIHRo ZQ0KICAgQ0xJRU5UIHRvIHRoZSBTRVJWRVIgKHNlbmRpbmcgb3JpZ2luYWwg YXBwbGljYXRpb24gbWVzc2FnZSkgYW5kIGENCiAgIGZsb3cgZnJvbSB0aGUg U0VSVkVSIHRvIHRoZSBDTElFTlQgKHNlbmRpbmcgYWRhcHRlZCBhcHBsaWNh dGlvbg0KICAgbWVzc2FnZXMpLiBUaGUgbnVtYmVyIG9mIGFwcGxpY2F0aW9u IG1lc3NhZ2VzIHByb2R1Y2VkIGJ5IHRoZSBTRVJWRVINCiAgIGFuZCB3aGV0 aGVyIHRoZSBTRVJWRVIgYWN0dWFsbHkgbW9kaWZpZXMgb3JpZ2luYWwgYXBw bGljYXRpb24gbWVzc2FnZQ0KICAgZGVwZW5kcyBvbiB0aGUgcmVxdWVzdGVk IGNhbGxvdXQgc2VydmljZS4gVGhlIENMSUVOVCBvciB0aGUgU0VSVkVSDQog ICBjYW4gdGVybWluYXRlIHRoZSB0cmFuc2FjdGlvbiBieSBzZW5kaW5nIGEg Y29ycmVzcG9uZGluZyBtZXNzYWdlIHRvDQogICB0aGUgb3RoZXIgc2lkZS4N Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpSb3Vzc2tvdiAgICAg ICAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDI5LCAyMDAzICAgICAgICAg ICAgICAgW1BhZ2UgN10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICBPUEVT IENhbGxvdXQgUHJvdG9jb2wgKE9DUCkgICAgICAgICAgICAgTWFyY2ggMjAw Mw0KDQoNCjQuIENvbm5lY3Rpb25zDQoNCiAgIE9DUCBjb25uZWN0aW9uIGlz IGEgbG9naWNhbCBhYnN0cmFjdGlvbiByZXByZXNlbnRpbmcgYSBzdHJlYW0g b2YNCiAgIHBvc3NpYmx5IGludGVybGVhdmVkIE9DUCB0cmFuc2FjdGlvbnMg YW5kIHRyYW5zYWN0aW9uLWluZGVwZW5kZW50DQogICBtZXNzYWdlcy4gQ29u bmVjdGlvbnMgYWxsb3cgZm9yIGVmZmljaWVudCBoYW5kbGluZyBvZiBzdGF0 ZSBjb21tb24gdG8NCiAgIHNldmVyYWwgT0NQIHRyYW5zYWN0aW9ucywgaW5j bHVkaW5nIHByb2Nlc3NpbmcgcHJpb3JpdGl6YXRpb24uDQoNCiAgIChYWFg6 IE9DUCB0cmFuc3BvcnQgYmluZGluZyhzKSB3aWxsIGRldGVybWluZSBob3cg Y2FsbG91dCBjb25uZWN0aW9ucw0KICAgYXJlIG1hcHBlZCB0byB0cmFuc3Bv cnQgY29ubmVjdGlvbnMuIEZvciBleGFtcGxlLCBpZiByYXcgVENQIGlzIHRo ZQ0KICAgdHJhbnNwb3J0LCB0aGFuIGEgVENQIGNvbm5lY3Rpb24gd2lsbCBj b3JyZXNwb25kIHRvIGEgY2FsbG91dA0KICAgY29ubmVjdGlvbi4gSWYgQkVF UCBvdmVyIFRDUCBpcyB1c2VkLCB0aGFuIGEgQkVFUCBjaGFubmVsIHdpbGwN CiAgIGNvcnJlc3BvbmQgdG8gYSBjYWxsb3V0IGNvbm5lY3Rpb24sIGFsbG93 aW5nIGNhbGxvdXQgY29ubmVjdGlvbg0KICAgbXVsdGlwbGV4aW5nIG92ZXIg YSBzaW5nbGUgVENQIGNvbm5lY3Rpb24uKQ0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNClJvdXNza292ICAgICAgICAgICAgICAgRXhwaXJlcyBT ZXB0ZW1iZXIgMjksIDIwMDMgICAgICAgICAgICAgICBbUGFnZSA4XQ0KDA0K SW50ZXJuZXQtRHJhZnQgICAgICAgIE9QRVMgQ2FsbG91dCBQcm90b2NvbCAo T0NQKSAgICAgICAgICAgICBNYXJjaCAyMDAzDQoNCg0KNS4gTWVzc2FnZSBQ YXJhbWV0ZXIgRGVmaW5pdGlvbnMNCg0KICAgY2xpZW50OiBBIENMSUVOVCBk ZXNjcmlwdGlvbi4gIFRoZSBkZXNjcmlwdGlvbiBNQVkgYmUgdXNlZCBieSBT RVJWRVINCiAgICAgIGZvciBsb2dnaW5nIGFuZCBzaW1pbGFyIGluZm9ybWF0 aW9uYWwgcHVycG9zZXMuDQoNCiAgIHByaW9yaXR5OiBPQ1AgY29ubmVjdGlv biBwcmlvcml0eSwgYXMgYSBzaWduZWQgaW50ZWdlciB2YWx1ZS4gRGVmYXVs dA0KICAgICAgcHJpb3JpdHkgaXMgemVyby4gSGlnaGVyIHZhbHVlcyBjb3Jy ZXNwb25kIHRvIG1vcmUgImltcG9ydGFudCINCiAgICAgIGNvbm5lY3Rpb25z IHRoYXQgTUFZIGJlIGNoZWNrZWQgYW5kIHByb2Nlc3NlZCBtb3JlIG9mdGVu LiBTdXBwb3J0DQogICAgICBmb3IgY29ubmVjdGlvbiBwcmlvcml0aWVzIGlz IE9QVElPTkFMLiBIb3dldmVyLCBTRVJWRVINCiAgICAgIGltcGxlbWVudGF0 aW9ucyBTSE9VTEQgTk9UIGtub3dpbmdseSB2aW9sYXRlIHByaW9yaXR5IHNl dHRpbmdzLA0KICAgICAgaW5jbHVkaW5nIHRoZSBkZWZhdWx0IHZhbHVlIG9m IHplcm8gKHdoZXJlIHZpb2xhdGlvbiBpcyBkZWZpbmVkIGFzDQogICAgICB0 cmVhdGluZyBsb3dlciBwcmlvcml0eSBjb25uZWN0aW9uIGFzIG1vcmUgaW1w b3J0YW50IHRoYW4gYSBoaWdoZXINCiAgICAgIHByaW9yaXR5IGNvbm5lY3Rp b24pLg0KDQogICB4aWQ6IE9DUCB0cmFuc2FjdGlvbiBpZGVudGlmaWVyLiAg VW5pcXVlbHkgaWRlbnRpZmllcyBhbiBPQ1ANCiAgICAgIHRyYW5zYWN0aW9u IG9yaWdpbmF0ZWQgYnkgYSBnaXZlbiBDTElFTlQuIFNpbmNlIGVhY2ggdHJh bnNhY3Rpb24NCiAgICAgIGRlYWxzIHdpdGggYSBzaW5nbGUgYXBwbGljYXRp b24gbWVzc2FnZSwgInhpZCIgYWxzbyBpZGVudGlmaWVzDQogICAgICB0aGF0 IGFwcGxpY2F0aW9uIG1lc3NhZ2UuDQoNCiAgIHJpZDogT0NQIHJlcXVlc3Qg aWRlbnRpZmllci4gIFVuaXF1ZWx5IGlkZW50aWZpZXMgYW4gT0NQIHJlcXVl c3QNCiAgICAgIG1lc3NhZ2Ugd2l0aGluIGFuIE9DUCBjb25uZWN0aW9uLiBS ZXF1ZXN0IGlkZW50aWZpZXJzIGFyZSB1c2VkIHRvDQogICAgICBtYXRjaCBj ZXJ0YWluIHJlcXVlc3RzIGFuZCByZXNwb25zZXMuDQoNCiAgIHNlcnZpY2U6 IE9QRVMgc2VydmljZSBpZGVudGlmaWVyIGFuZCBvcHRpb25hbCBzZXJ2aWNl IHBhcmFtZXRlcnMuDQoNCiAgIGFtLWlkOiBBcHBsaWNhdGlvbiBtZXNzYWdl IGlkZW50aWZpZXIuICBVbmlxdWVseSBpZGVudGlmaWVzIGFuDQogICAgICBh cHBsaWNhdGlvbiBtZXNzYWdlIHdpdGhpbiBhbiBPQ1AgdHJhbnNhY3Rpb24u DQoNCiAgIGFtLXByb3RvOiBBcHBsaWNhdGlvbiBtZXNzYWdlIHByb3RvY29s LiAgRm9yIGV4YW1wbGUsIEhUVFAgb3IgU01UUC4NCg0KICAgYW0ta2luZDog QXBwbGljYXRpb24gbWVzc2FnZSBraW5kLiBGb3IgZXhhbXBsZSwgcmVxdWVz dCBvciByZXNwb25zZS4NCg0KICAgYW0tc291cmNlOiBJbmZvcm1hdGlvbiBh Ym91dCB0aGUgc291cmNlIG9mIGFuIGFwcGxpY2F0aW9uIG1lc3NhZ2UuDQog ICAgICBGb3IgZXhhbXBsZSwgSFRUUCBjbGllbnQgb3Igb3JpZ2luIHNlcnZl ciBJUCBhZGRyZXNzIGFuZCBUQ1ANCiAgICAgIGNvbm5lY3Rpb24gSUQuDQoN CiAgIGFtLWRlc3RpbmF0aW9uOiBJbmZvcm1hdGlvbiBhYm91dCB0aGUgZGVz dGluYXRpb24gb2YgYW4gYXBwbGljYXRpb24NCiAgICAgIG1lc3NhZ2UuIEZv ciBleGFtcGxlLCBIVFRQIGNsaWVudCBvciBvcmlnaW4gc2VydmVyIGFkZHJl c3MuDQoNCiAgIGFtLWRlc3RpbmF0aW9uczogQSBjb2xsZWN0aW9uIG9mIGFt LWRlc3RpbmF0aW9uIHBhcmFtZXRlcnMuDQoNCiAgIHNpemU6IEFwcGxpY2F0 aW9uIGRhdGEgc2l6ZSBpbiBvY3RldHMuIFRoZSB2YWx1ZSBlaXRoZXIgYXBw bGllcyB0bw0KICAgICAgdGhlIGRhdGEgYXR0YWNoZWQgdG8gYW4gT0NQIG1l c3NhZ2Ugb3Igc3VnZ2VzdHMgZGF0YSBzaXplIHRvIGJlDQogICAgICBzZW50 IGluIHJlc3BvbnNlIHRvIGFuIE9DUCBtZXNzYWdlLg0KDQogICBvZmZzZXQ6 IEFwcGxpY2F0aW9uIGRhdGEgb2Zmc2V0LiBUaGUgb2Zmc2V0IG9mIHRoZSBm aXJzdCBhcHBsaWNhdGlvbg0KICAgICAgYnl0ZSBoYXMgYSB2YWx1ZSBvZiB6 ZXJvLiBUaGUgb2Zmc2V0IGlzIG5ldmVyIG5lZ2F0aXZlLiBUaGUgdmFsdWUN CiAgICAgIGFwcGxpZXMgdG8gdGhlIGRhdGEgYXR0YWNoZWQgdG8gYW4gT0NQ IG1lc3NhZ2UuDQoNCg0KDQpSb3Vzc2tvdiAgICAgICAgICAgICAgIEV4cGly ZXMgU2VwdGVtYmVyIDI5LCAyMDAzICAgICAgICAgICAgICAgW1BhZ2UgOV0N CgwNCkludGVybmV0LURyYWZ0ICAgICAgICBPUEVTIENhbGxvdXQgUHJvdG9j b2wgKE9DUCkgICAgICAgICAgICAgTWFyY2ggMjAwMw0KDQoNCiAgIG1vZGlm aWVkOiBBIGJvb2xlYW4gcGFyYW1ldGVyIGluZGljYXRpbmcgdGhhdCB0aGUg YXR0YWNoZWQNCiAgICAgIGFwcGxpY2F0aW9uIGRhdGEgaGFzIGJlZW4gbW9k aWZpZWQgYnkgaGUgU0VSVkVSLiAgT25seSBTRVJWRVIgbWF5DQogICAgICBz ZW5kIHRoaXMgZmxhZy4gVGhpcyBwYXJhbWV0ZXIgY2FuIGJlIHVzZWQgd2l0 aCBhbnkgT0NQIG1lc3NhZ2UNCiAgICAgIHRoYXQgaGFzIGFtLWlkIHBhcmFt ZXRlci4NCg0KICAgY29waWVkOiBBIGZsYWcgaW5kaWNhdGluZyB0aGF0IGEg Y29weSBvZiB0aGUgYXR0YWNoZWQgYXBwbGljYXRpb24NCiAgICAgIGRhdGEg aXMgYmVpbmcga2VwdCBhdCB0aGUgQ0xJRU5ULiBPbmx5IHRoZSBDTElFTlQg bWF5IHNlbmQgdGhpcw0KICAgICAgZmxhZy4gVGhpcyBwYXJhbWV0ZXIgY2Fu IGJlIHVzZWQgd2l0aCBhbnkgT0NQIG1lc3NhZ2UgdGhhdCBtYXkNCiAgICAg IGNhcnJ5IGFwcGxpY2F0aW9uIG1lc3NhZ2UgZGF0YS4gKFhYWDogaXQgaXMg eWV0IHVuY2xlYXIgd2hlbg0KICAgICAgQ0xJRU5UIGNvbW1pdG1lbnQgdG8g cHJlc2VydmUgdGhlIGRhdGEgbWF5IGVuZC4pDQoNCiAgIHNpemVwOiBSZW1h aW5pbmcgYXBwbGljYXRpb24gZGF0YSBzaXplIHByZWRpY3Rpb24gaW4gb2N0 ZXRzLiBUaGUNCiAgICAgIHZhbHVlIGV4Y2x1ZGVzIGRhdGEgaW4gdGhlIGN1 cnJlbnQgT0NQIG1lc3NhZ2UsIGlmIGFueS4gVGhlDQogICAgICBwcmVkaWN0 aW9uIGFwcGxpZXMgdG8gYSBzaW5nbGUgYXBwbGljYXRpb24gbWVzc2FnZS4g VGhpcyBwYXJhbWV0ZXINCiAgICAgIGNhbiBiZSB1c2VkIHdpdGggYW55IE9D UCBtZXNzYWdlIHRoYXQgaGFzIGFtLWlkIHBhcmFtZXRlci4NCg0KICAgbW9k cDogRnV0dXJlIGRhdGEgbW9kaWZpY2F0aW9uIHByZWRpY3Rpb24gaW4gcGVy Y2VudHMuIEEgbW9kcCB2YWx1ZQ0KICAgICAgb2YgMCAoemVybykgbWVhbnMg dGhlIHNlbmRlciBwcmVkaWN0cyB0aGF0IHRoZXJlIHdpbGwgYmUgbm8gZGF0 YQ0KICAgICAgbW9kaWZpY2F0aW9ucy4gQSB2YWx1ZSBvZiAxMDAgbWVhbnMg dGhlIHNlbmRlciBpcyBwcmVkaWN0cyB0aGF0DQogICAgICB0aGVyZSB3aWxs IGJlIGRhdGEgbW9kaWZpY2F0aW9ucy4gIFRoZSB2YWx1ZSBleGNsdWRlcyBk YXRhIGluIHRoZQ0KICAgICAgY3VycmVudCBPQ1AgbWVzc2FnZSwgaWYgYW55 LiAgVGhlIHByZWRpY3Rpb24gYXBwbGllcyB0byBhIHNpbmdsZQ0KICAgICAg YXBwbGljYXRpb24gbWVzc2FnZS4gVGhpcyBwYXJhbWV0ZXIgY2FuIGJlIHVz ZWQgd2l0aCBhbnkgT0NQDQogICAgICBtZXNzYWdlIHRoYXQgaGFzIGFtLWlk IHBhcmFtZXRlci4NCg0KICAgcmVzdWx0OiBPQ1AgcHJvY2Vzc2luZyByZXN1 bHQuIE1heSBpbmNsdWRlIGludGVnZXIgc3RhdHVzIGNvZGUgYW5kDQogICAg ICB0ZXh0dWFsIGluZm9ybWF0aW9uLg0KDQogICBlcnJvcjogQSBmbGFnIGlu ZGljYXRpbmcgYWJub3JtYWwgY29uZGl0aW9ucyBhdCB0aGUgc2VuZGVyIHRo YXQNCiAgICAgIGNhbm5vdCBiZSBleHByZXNzZWQgdmlhIHJlc3VsdCBwYXJh bWV0ZXIuIEl0IGlzIFJFQ09NTUVOREVEIHRoYXQNCiAgICAgIHRoZSByZWNp cGllbnQgZGVsZXRlcyBhbGwgc3RhdGUgYXNzb2NpYXRlZCB3aXRoIHRoZSBj b3JyZXNwb25kaW5nDQogICAgICBPQ1AgbWVzc2FnZS4gRm9yIGV4YW1wbGUs IGlmIHRoZSBtZXNzYWdlIGlzICdhcHAtbWVzc2FnZS1lbmQnIGFuZA0KICAg ICAgdGhlIGFwcGxpY2F0aW9uIG1lc3NhZ2UgY29udGFpbmVkIHVzZXIgY3Jl ZGVudGlhbHMsIHN1Y2gNCiAgICAgIGNyZWRlbnRpYWxzIHNob3VsZCBiZSBk ZWxldGVkLg0KDQogICBmZWF0dXJlOiBBIE9DUCBmZWF0dXJlIGlkZW50aWZp ZXIgd2l0aCBvcHRpb25hbCBmZWF0dXJlIHBhcmFtZXRlcnMuDQogICAgICBV c2VkIHRvIGRlY2xhcmUgc3VwcG9ydCBhbmQgbmVnb3RpYXRlIHVzZSBvZiBP Q1Agb3B0aW9uYWwgZmVhdHVyZXMNCiAgICAgIChlLmcuLCBjb3B5aW5nIG9m IGRhdGEgY2h1bmtzIGF0IHRoZSBDTElFTlQpLg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNClJvdXNza292ICAgICAgICAgICAgICAgRXhwaXJlcyBT ZXB0ZW1iZXIgMjksIDIwMDMgICAgICAgICAgICAgIFtQYWdlIDEwXQ0KDA0K SW50ZXJuZXQtRHJhZnQgICAgICAgIE9QRVMgQ2FsbG91dCBQcm90b2NvbCAo T0NQKSAgICAgICAgICAgICBNYXJjaCAyMDAzDQoNCg0KNi4gTWVzc2FnZSBE ZWZpbml0aW9ucw0KDQogICBTZW5kZXJzIE1VU1QgdXNlIG1lc3NhZ2UgZm9y bWF0IHNwZWNpZmllZCBpbiB0aGlzIHNlY3Rpb24uIChYWFggbm90ZQ0KICAg dGhhdCBhdCB0aGlzIHRpbWUsIHRoZSBvbmx5ICJmb3JtYXQiIHNwZWNpZmll ZCBpcyB0aGUgc2V0IG9mIG1lc3NhZ2UNCiAgIHBhcmFtZXRlcnMsIGJ1dCB0 aGlzIHdpbGwgY2hhbmdlIGFzIHdlIGFkZCB0cmFuc3BvcnQgYmluZGluZ3Mg YW5kDQogICBlbmNvZGluZ3MpLg0KDQogICBSZWNpcGllbnRzIE1VU1QgYmUg YWJsZSB0byBwYXJzZSBtZXNzYWdlcyBpbiB0aGUgc3BlY2lmaWVkIGZvcm1h dC4NCiAgIElmIGEgbWFsZm9ybWVkIG1lc3NhZ2UgaXMgcmVjZWl2ZWQsIHRo ZSByZWNpcGllbnQgTVVTVCB0ZXJtaW5hdGUNCiAgIHByb2Nlc3Npbmcgb2Yg dGhlIGNvcnJlc3BvbmRpbmcgT0NQIGNvbm5lY3Rpb24gdXNpbmcgJ2Nvbm5l Y3Rpb24tZW5kJw0KICAgbWVzc2FnZSB3aXRoIGFuIGVycm9yIGZsYWcuIElm IGFuIHVua25vd24gbWVzc2FnZSBvciBtZXNzYWdlDQogICBwYXJhbWV0ZXIg aXMgcmVjZWl2ZWQsIHRoZSByZWNpcGllbnQgTVVTVCBpZ25vcmUgaXQsIGJ1 dCBNQVkgcmVwb3J0DQogICAoZS5nLiwgbG9nKSBpdC4NCg0KICAgRXhjZXB0 IGZvciBtZXNzYWdlcyB0aGF0IGludHJvZHVjZSBuZXcgaWRlbnRpZmllcnMs IGFsbCBzZW50DQogICBpZGVudGlmaWVycyBNVVNUIGJlIGtub3duIChpLmUu LCBpbnRyb2R1Y2VkIGFuZCBub3QgZW5kZWQgYnkgcHJldmlvdXMNCiAgIG1l c3NhZ2VzKS4gIEV4Y2VwdCBmb3IgbWVzc2FnZXMgdGhhdCBpbnRyb2R1Y2Ug bmV3IGlkZW50aWZpZXJzLCB0aGUNCiAgIHJlY2lwaWVudCBNVVNUIGlnbm9y ZSBhbnkgbWVzc2FnZSB3aXRoIGFuIHVua25vd24gaWRlbnRpZmllci4gRm9y DQogICBleGFtcGxlLCByZWNpcGllbnQgbXVzdCBpZ25vcmUgYSBkYXRhLWhh dmUgbWVzc2FnZSBpZiB0aGUgeGlkDQogICBwYXJhbWV0ZXIgcmVmZXJzIHRv IGFuIHVua25vd24gdHJhbnNhY3Rpb24uIE1lc3NhZ2UgZGVmaW5pdGlvbnMg YmVsb3cNCiAgIGNsZWFybHkgc3RhdGUgcmFyZSBleGNlcHRpb25zIHRvIHRo ZSBhYm92ZSBydWxlcy4NCg0KICAgKFhYWCBjYW4gd2UgZGVmaW5lICJpZ25v cmUiPykgKFhYWCBtb3ZlIHRoZXNlIHJ1bGVzIGVsc2V3aGVyZT8pDQoNCiAg IChYWFggTWVzc2FnZSBwYXJhbWV0ZXJzIGluIFtzcXVhcmUgYnJhY2tldHNd IGFyZSBPUFRJT05BTC4gT3RoZXINCiAgIHBhcmFtZXRlcnMgYXJlIFJFUVVJ UkVELikNCg0KNi4xIGNvbm5lY3Rpb24tc3RhcnQNCg0KICAgY29ubmVjdGlv bi1zdGFydCBbY2xpZW50XSBbcHJpb3JpdHldDQoNCiAgIEluZGljYXRlcyB0 aGUgc3RhcnQgb2YgYW4gT0NQIGNvbm5lY3Rpb24gZnJvbSB0aGUgQ0xJRU5U LiBBIFNFUlZFUg0KICAgTVVTVCBOT1Qgc2VuZCB0aGlzIG1lc3NhZ2UuIFVw b24gcmVjZWl2aW5nIG9mIHRoaXMgbWVzc2FnZSwgdGhlDQogICBTRVJWRVIg TVVTVCBlaXRoZXIgc3RhcnQgbWFpbnRhaW5pbmcgY29ubmVjdGlvbiBzdGF0 ZSBvciByZWZ1c2UNCiAgIGZ1cnRoZXIgcHJvY2Vzc2luZyBieSByZXNwb25k aW5nIHdpdGggYSAnY29ubmVjdGlvbi1lbmQnIG1lc3NhZ2UuIEENCiAgIFNF UlZFUiBNVVNUIG1haW50YWluIHRoZSBzdGF0ZSB1bnRpbCBpdCByZWNlaXZl cyBhIG1lc3NhZ2UgaW5kaWNhdGluZw0KICAgdGhlIGVuZCBvZiB0aGUgY29u bmVjdGlvbiBvciB1bnRpbCBpdCB0ZXJtaW5hdGVzIHRoZSBjb25uZWN0aW9u DQogICBpdHNlbGYuDQoNCiAgIFRoZSAnY29ubmVjdGlvbi1zdGFydCcgbWVz c2FnZSBNVVNUIGJlIHRoZSBmaXJzdCBtZXNzYWdlIG9uIGFuIE9DUA0KICAg Y29ubmVjdGlvbi4gSWYgT0NQIHRyYW5zcG9ydCBjb25uZWN0aW9uIGRlbGl2 ZXJzIGEgbWVzc2FnZSBvdXRzaWRlIG9mDQogICB0aGUgKCdjb25uZWN0aW9u LXN0YXJ0JywgJ2Nvbm5lY3Rpb24tZW5kJykgYm91bmRhcmllcywgc3VjaCBh IG1lc3NhZ2UNCiAgIE1VU1QgYmUgaWdub3JlZCwgYW5kIHRoZSByZWNpcGll bnQgTVVTVCBjbG9zZSB0aGUgY29ycmVzcG9uZGluZw0KICAgdHJhbnNwb3J0 IGNvbm5lY3Rpb24uDQoNCiAgIFRoZXJlIGFyZSBubyBPQ1AgY29ubmVjdGlv biBpZGVudGlmaWVycyBiZWNhdXNlIGNvbm5lY3Rpb25zIGFyZSBub3QNCiAg IG11bHRpcGxleGVkIG9uIGEgbG9naWNhbCBsZXZlbC4gT0NQIHRyYW5zcG9y dCBwcm90b2NvbCBiaW5kaW5nIE1VU1QNCiAgIGRpc3Rpbmd1aXNoIE9DUCBj b25uZWN0aW9ucyBvbiBhIHRyYW5zcG9ydCBsZXZlbC4gIEZvciBleGFtcGxl LCBhDQoNCg0KDQpSb3Vzc2tvdiAgICAgICAgICAgICAgIEV4cGlyZXMgU2Vw dGVtYmVyIDI5LCAyMDAzICAgICAgICAgICAgICBbUGFnZSAxMV0NCgwNCklu dGVybmV0LURyYWZ0ICAgICAgICBPUEVTIENhbGxvdXQgUHJvdG9jb2wgKE9D UCkgICAgICAgICAgICAgTWFyY2ggMjAwMw0KDQoNCiAgIHNpbmdsZSBCRUVQ IFtSRkMzMDgwXSBjaGFubmVsIG1heSBiZSBkZXNpZ25hdGVkIHRvIGFuIE9D UCBjb25uZWN0aW9uLg0KDQo2LjIgY29ubmVjdGlvbi1lbmQNCg0KICAgY29u bmVjdGlvbi1lbmQNCg0KICAgSW5kaWNhdGVzIGFuIGVuZCBvZiBhbiBPQ1Ag Y29ubmVjdGlvbi4gVGhlIHJlY2lwaWVudCBNVVNUIGZyZWUNCiAgIGFzc29j aWF0ZWQgc3RhdGUuIFRoZSBkZXN0cnVjdGlvbiBvZiB0aGUgc3RhdGUgZW5z dXJlcyB0aGF0IG1lc3NhZ2VzDQogICBvdXRzaWRlIG9mIE9DUCBjb25uZWN0 aW9uIGFyZSBpZ25vcmVkLg0KDQogICBBICdjb25uZWN0aW9uLWVuZCcgbWVz c2FnZSBpbXBsaWVzICd4YWN0aW9uLWVuZCcgbWVzc2FnZXMgZm9yIGFsbA0K ICAgdHJhbnNhY3Rpb25zIG9wZW5lZCBvbiB0aGlzIGNvbm5lY3Rpb24uDQoN CjYuMyBjb25uZWN0aW9uLXByaW9yaXR5DQoNCiAgIGNvbm5lY3Rpb24tcHJp b3JpdHkgcHJpb3JpdHkNCg0KICAgU2V0cyBjb25uZWN0aW9uIHByaW9yaXR5 LCBvdmVyd3JpdGluZyB0aGUgcHJldmlvdXMgdmFsdWUuDQoNCjYuNCBjb25u ZWN0aW9uLXNlcnZpY2UNCg0KICAgY29ubmVjdGlvbi1zZXJ2aWNlIHNlcnZp Y2UNCg0KICAgU2V0cyBkZWZhdWx0IHNlcnZpY2UgZm9yIHRoZSBjb25uZWN0 aW9uLCBvdmVyd3JpdGluZyB0aGUgcHJldmlvdXMNCiAgIHZhbHVlLg0KDQo2 LjUgeGFjdGlvbi1zdGFydA0KDQogICB4YWN0aW9uLXN0YXJ0IHhpZCBbc2Vy dmljZV0NCg0KICAgSW5kaWNhdGVzIHRoZSBzdGFydCBvZiBhbiBPQ1AgdHJh bnNhY3Rpb24uIEEgU0VSVkVSIE1VU1QgTk9UIHNlbmQNCiAgIHRoaXMgbWVz c2FnZS4gVXBvbiByZWNlaXZpbmcgb2YgdGhpcyBtZXNzYWdlLCB0aGUgU0VS VkVSIE1VU1QgZWl0aGVyDQogICBzdGFydCBtYWludGFpbmluZyB0cmFuc2Fj dGlvbiBzdGF0ZSBvciByZWZ1c2UgZnVydGhlciBwcm9jZXNzaW5nIGJ5DQog ICByZXNwb25kaW5nIHdpdGggYSAneGFjdGlvbi1lbmQnIG1lc3NhZ2UuIEEg U0VSVkVSIE1VU1QgbWFpbnRhaW4gdGhlDQogICBzdGF0ZSB1bnRpbCBpdCBy ZWNlaXZlcyBhIG1lc3NhZ2UgaW5kaWNhdGluZyB0aGUgZW5kIG9mIHRoZQ0K ICAgdHJhbnNhY3Rpb24gb3IgdW50aWwgaXQgdGVybWluYXRlcyB0aGUgdHJh bnNhY3Rpb24gaXRzZWxmLg0KDQogICBUaGUgT1BUSU9OQUwgInNlcnZpY2Ui IHBhcmFtZXRlciBhcHBsaWVzIHRvIHRoZSBvcmlnaW5hbCBhcHBsaWNhdGlv bg0KICAgbWVzc2FnZSBwcm9jZXNzZWQgd2l0aGluIHRoaXMgT0NQIHRyYW5z YWN0aW9uIGJvdW5kYXJpZXMuIElmDQogICAic2VydmljZSIgaXMgbm90IHNw ZWNpZmllZCwgdGhlICJzZXJ2aWNlIiBwYXJhbWV0ZXIgZnJvbSB0aGUNCiAg IGNvbm5lY3Rpb24gc3RhdGUgTVVTVCBiZSB1c2VkLiBJZiB0aGUgbGF0dGVy IGlzIG5vdCBzcGVjaWZpZWQgZWl0aGVyLA0KICAgdGhlIHRyYW5zYWN0aW9u IGlzIGludmFsaWQgYW5kIE1VU1QgYmUgYWJvcnRlZCBieSB0aGUgcmVjaXBp ZW50Lg0KDQogICBUaGlzIG1lc3NhZ2UgaW50cm9kdWNlcyB0cmFuc2FjdGlv biBpZGVudGlmaWVyICh4aWQpLg0KDQo2LjYgeGFjdGlvbi1lbmQNCg0KICAg eGFjdGlvbi1lbmQgeGlkIFtlcnJvcl0gcmVzdWx0DQoNCg0KDQpSb3Vzc2tv diAgICAgICAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDI5LCAyMDAzICAg ICAgICAgICAgICBbUGFnZSAxMl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAg ICBPUEVTIENhbGxvdXQgUHJvdG9jb2wgKE9DUCkgICAgICAgICAgICAgTWFy Y2ggMjAwMw0KDQoNCiAgIEluZGljYXRlcyB0aGUgZW5kIG9mIHRoZSBPQ1Ag dHJhbnNhY3Rpb24uIFRoZSByZWNpcGllbnQgTVVTVCBmcmVlDQogICBhc3Nv Y2lhdGVkIHN0YXRlLiBUaGUgZGVzdHJ1Y3Rpb24gb2YgdGhlIHN0YXRlIGVu c3VyZXMgdGhhdCBmdXR1cmUNCiAgIG1lc3NhZ2VzIHJlZmVycmluZyB0byB0 aGUgc2FtZSB0cmFuc2FjdGlvbiwgaWYgYW55LCB3aWxsIGJlIGlnbm9yZWQu DQoNCiAgIFRoaXMgbWVzc2FnZSB0ZXJtaW5hdGVzIHRoZSBsaWZlIG9mIHRo ZSB0cmFuc2FjdGlvbiBpZGVudGlmaWVyICh4aWQpLg0KDQogICBBICd4YWN0 aW9uLWVuZCcgbWVzc2FnZSBpbXBsaWVzICdhcHAtbWVzc2FnZS1lbmQnIG1l c3NhZ2VzIGZvciBhbGwNCiAgIGFzc29jaWF0ZWQgYXBwbGljYXRpb24gbWVz c2FnZXMgKFhYWDogcmVwaHJhc2UgdGhpcyBhbmQgc2ltaWxhciBpbnRvDQog ICBhIE1VU1Q/KS4NCg0KNi43IGFwcC1tZXNzYWdlLXN0YXJ0DQoNCiAgIGFw cC1tZXNzYWdlLXN0YXJ0IHhpZCBhbS1pZCBhbS1wcm90byBhbS1raW5kIHNv dXJjZSBkZXN0aW5hdGlvbnMgLi4uDQoNCiAgIEluZGljYXRlcyB0aGUgc3Rh cnQgb2YgcHJvY2Vzc2luZyBvZiBhbiBhcHBsaWNhdGlvbiBtZXNzYWdlLiAg VGhlDQogICByZWNpcGllbnQgTVVTVCBlaXRoZXIgc3RhcnQgcHJvY2Vzc2lu ZyB0aGUgYXBwbGljYXRpb24gbWVzc2FnZSAoYW5kDQogICBtYWludGFpbiBp dHMgc3RhdGUpIG9yIHJlZnVzZSBmdXJ0aGVyIHByb2Nlc3Npbmcgd2l0aCBh bg0KICAgJ2FwcC1tZXNzYWdlLWVuZCcgbWVzc2FnZS4gVGhlIHJlY2lwaWVu dCBNVVNUIG1haW50YWluIHRoZSBzdGF0ZQ0KICAgdW50aWwgaXQgcmVjZWl2 ZXMgYSBtZXNzYWdlIGluZGljYXRpbmcgdGhlIGVuZCBvZiBhcHBsaWNhdGlv biBtZXNzYWdlDQogICBwcm9jZXNzaW5nIG9yIHVudGlsIGl0IHRlcm1pbmF0 ZXMgdGhlIHByb2Nlc3NpbmcgaXRzZWxmLg0KDQogICBXaGVuICdhcHAtbWVz c2FnZS1zdGFydCcgbWVzc2FnZSBpcyBzZW50IHRvIHRoZSBTRVJWRVIsIHRo ZSBTRVJWRVINCiAgIHVzdWFsbHkgc2VuZHMgYW4gYXBwLW1lc3NhZ2Utc3Rh cnQgbWVzc2FnZSBiYWNrLCBhbm5vdW5jaW5nIHRoZQ0KICAgY3JlYXRpb24g b2YgYW4gYWRhcHRlZCB2ZXJzaW9uIG9mIHRoZSBvcmlnaW5hbCBhcHBsaWNh dGlvbiBtZXNzYWdlLg0KICAgU3VjaCByZXNwb25zZSBtYXkgYmUgZGVsYXll ZC4gRm9yIGV4YW1wbGUsIHRoZSBTRVJWRVIgbWF5IHdhaXQgZm9yDQogICBt b3JlIGluZm9ybWF0aW9uIHRvIGNvbWUgZnJvbSB0aGUgQ0xJRU5ULg0KDQog ICBUaGlzIG1lc3NhZ2UgaW50cm9kdWNlcyBhcHBsaWNhdGlvbiBtZXNzYWdl IGlkZW50aWZpZXIgKGFtLWlkKS4NCg0KNi44IGFwcC1tZXNzYWdlLWVuZA0K DQogICBhcHAtbWVzc2FnZS1lbmQgeGlkIGFtLWlkIFtlcnJvcl0gcmVzdWx0 IC4uLg0KDQogICBJbmRpY2F0ZXMgdGhlIGVuZCBvZiBhcHBsaWNhdGlvbiBt ZXNzYWdlIHByb2Nlc3NpbmcuICBUaGUgcmVjaXBpZW50DQogICBNVVNUIGZy ZWUgYXNzb2NpYXRlZCBzdGF0ZS4gVGhlIGRlc3RydWN0aW9uIG9mIHRoZSBz dGF0ZSBlbnN1cmVzIHRoYXQNCiAgIGZ1dHVyZSBtZXNzYWdlcyByZWZlcnJp bmcgdG8gdGhlIHNhbWUgYXBwbGljYXRpb24gbWVzc2FnZSwgaWYgYW55LA0K ICAgd2lsbCBiZSBpZ25vcmVkLg0KDQogICBUaGlzIG1lc3NhZ2UgdGVybWlu YXRlcyB0aGUgbGlmZSBvZiB0aGUgYXBwbGljYXRpb24gbWVzc2FnZQ0KICAg aWRlbnRpZmllciAoYW0taWQpLg0KDQogICBBICdhcHAtbWVzc2FnZS1lbmQn IG1lc3NhZ2UgaW1wbGllcyAnZGF0YS1lbmQnIG1lc3NhZ2UgZm9yIHRoZQ0K ICAgYXNzb2NpYXRlZCBhcHBsaWNhdGlvbiBtZXNzYWdlLg0KDQo2LjkgZGF0 YS1oYXZlDQoNCiAgIGRhdGEtaGF2ZSB4aWQgYW0taWQgb2Zmc2V0IHNpemUg bW9kaWZpZWQgW2NvcGllZF0gW3NpemVwXSBbbW9kcF0NCiAgIFthY2tdDQoN Cg0KDQpSb3Vzc2tvdiAgICAgICAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVy IDI5LCAyMDAzICAgICAgICAgICAgICBbUGFnZSAxM10NCgwNCkludGVybmV0 LURyYWZ0ICAgICAgICBPUEVTIENhbGxvdXQgUHJvdG9jb2wgKE9DUCkgICAg ICAgICAgICAgTWFyY2ggMjAwMw0KDQoNCiAgIFRoaXMgaXMgdGhlIG9ubHkg T0NQIG1lc3NhZ2UgdGhhdCBtYXkgY2FycnkgYXBwbGljYXRpb24gZGF0YS4g VGhlcmUNCiAgIE1VU1QgTk9UIGJlIGFueSBnYXBzIGluIGRhdGEgc3VwcGxp ZWQgYnkgZGF0YS1oYXZlIGFuZCBkYXRhLWFzLWlzDQogICBtZXNzYWdlcyAo aS5lLiwgdGhlIG9mZnNldCBvZiB0aGUgbmV4dCBkYXRhIG1lc3NhZ2UgbXVz dCBiZSBlcXVhbCB0bw0KICAgdGhlIG9mZnNldCtzaXplIG9mIHRoZSBwcmV2 aW91cyBkYXRhIG1lc3NhZ2UpIChYWFg6IHdlIGRvIG5vdCBuZWVkDQogICBv ZmZzZXQgdGhlbjsgc2hvdWxkIHdlIGtlZXAgaXQgYXMgYSB2YWxpZGF0aW9u IG1lY2hhbmlzbT8pIChYWFg6DQogICBkb2N1bWVudCB3aGF0IHRvIGRvIHdo ZW4gdGhpcyBNVVNUIGlzIHZpb2xhdGVkKS4gIFplcm8gc2l6ZSBpcw0KICAg cGVybWl0dGVkIGFuZCBpcyB1c2VmdWwgZm9yIGNvbW11bmljYXRpbmcgcHJl ZGljdGlvbnMgd2l0aG91dCBzZW5kaW5nDQogICBkYXRhLg0KDQogICBXaGVu IGEgQ0xJRU5UIHNlbmRzIGEgImNvcGllZCIgZmxhZywgdGhlIENMSUVOVCBN VVNUIGtlZXAgYSBjb3B5IG9mDQogICB0aGUgY29ycmVzcG9uZGluZyBkYXRh ICh0aGUgcHJlc2VydmF0aW9uIGNvbW1pdG1lbnQgc3RhcnRzKS4NCg0KICAg V2hlbiBhbiAiYWNrIiBmbGFnIGlzIHByZXNlbnQsIHRoZSByZWNpcGllbnQg TVVTVCByZXNwb25kIHdpdGggYQ0KICAgJ2RhdGEtYWNrJyBtZXNzYWdlLg0K DQo2LjEwIGRhdGEtYXMtaXMNCg0KICAgZGF0YS1hcy1pcyB4aWQgYW0taWQg b2Zmc2V0IHNpemUgY29weS1hbS1pZCBjb3B5LWFtLW9mZnNldA0KDQogICBU ZWxscyB0aGUgQ0xJRU5UIHRvIHVzZSAic2l6ZSIgYnl0ZXMgb2YgZGF0YSBh dCBjb3B5LWFtLW9mZnNldCBvZiB0aGUNCiAgIGNvcHktYW0taWQgYXBwbGlj YXRpb24gbWVzc2FnZSwgYXMgaWYgdGhhdCBkYXRhIGNhbWUgZnJvbSB0aGUg U0VSVkVSDQogICBpbiBhICdkYXRhLWhhdmUgYW0taWQgb2Zmc2V0IHNpemU+ IG1lc3NhZ2UuIFRoZSBkYXRhIGNodW5rIE1VU1QgYmUNCiAgIHVuZGVyIHRo ZSBwcmVzZXJ2YXRpb24gY29tbWl0bWVudC4gSWYgdGhlIENMSUVOVCByZWNl aXZlcyBhDQogICAnZGF0YS1hcy1pcz4gbWVzc2FnZSBmb3IgZGF0YSBub3Qg dW5kZXIgcHJlc2VydmF0aW9uIGNvbW1pdG1lbnQsIHRoZQ0KICAgbWVzc2Fn ZSBpcyBpbnZhbGlkLiBCb3RoICJhbS1pZCIgYW5kICJjb3B5LWFtLWlkIiBh cHBsaWNhdGlvbiBtZXNzYWdlDQogICBpZGVudGlmaWVycyBNVVNUIGJlbG9u ZyB0byB0aGUgc2FtZSBPQ1AgdHJhbnNhY3Rpb24uIElmIHRoZXkgZG8gbm90 LA0KICAgdGhlIG1lc3NhZ2UgaXMgaW52YWxpZC4NCg0KICAgSWYgdGhlIGRh dGEtYXMtaXMgbWVzc2FnZSBpcyBpbnZhbGlkLCB0aGUgQ0xJRU5UIE1VU1Qg YWJvcnQgYW0taWQNCiAgIG1lc3NhZ2UgcHJvY2Vzc2luZyAoWFhYOiBkb2N1 bWVudCBob3cgcHJvY2Vzc2luZyBzaG91bGQgYmUgYWJvcnRlZCkuDQoNCjYu MTEgZGF0YS1wYXVzZQ0KDQogICBkYXRhLXBhdXNlIHhpZCBhbS1pZA0KDQog ICBXaGVuIHNlbmQgYnkgYSBDTElFTlQsIHRoZSBkYXRhLXBhdXNlIG1lc3Nh Z2UgaW5mb3JtcyB0aGUgU0VSVkVSIHRoYXQNCiAgIHRoZXJlIHdpbGwgYmUg bm8gbW9yZSBkYXRhIGZvciB0aGUgc3BlY2lmaWVkIGFwcGxpY2F0aW9uIG1l c3NhZ2UNCiAgIHVudGlsIHRoZSBTRVJWRVIgZXhwbGljaXRseSBhc2tzIGZv ciBkYXRhIHVzaW5nIGEgZGF0YS1uZWVkIG1lc3NhZ2UuDQogICBUaGUgQ0xJ RU5UIE1VU1Qgc3RvcCBzZW5kaW5nIGFwcGxpY2F0aW9uIG1lc3NhZ2UgZGF0 YSB0byB0aGUgU0VSVkVSDQogICBhZnRlciBzZW5kaW5nIGEgZGF0YS1wYXVz ZSBtZXNzYWdlLg0KDQogICBXaGVuIHNlbmQgYnkgYSBTRVJWRVIsIHRoZSBk YXRhLXBhdXNlIG1lc3NhZ2UgaW5mb3JtcyB0aGUgQ0xJRU5UIHRoYXQNCiAg IGl0IHNob3VsZCBzdG9wIHNlbmRpbmcgZGF0YSB0byB0aGUgU0VSVkVSIHVu dGlsIHRoZSBTRVJWRVIgZXhwbGljaXRseQ0KICAgYXNrcyBmb3IgZGF0YSB1 c2luZyBhIGRhdGEtbmVlZCBtZXNzYWdlLiBUaGUgQ0xJRU5UIE1VU1Qgc3Rv cCBzZW5kaW5nDQogICBhcHBsaWNhdGlvbiBtZXNzYWdlIGRhdGEgdG8gdGhl IFNFUlZFUiB1cG9uIHJlY2VpdmluZyBhIGRhdGEtcGF1c2UNCiAgIG1lc3Nh Z2UuDQoNCiAgIEluIGJvdGggY2FzZXMsIHByb2Nlc3Npbmcgb2YgdGhlIGNv cnJlc3BvbmRpbmcgYXBwbGljYXRpb24gbWVzc2FnZSBpcw0KDQoNCg0KUm91 c3Nrb3YgICAgICAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAyOSwgMjAw MyAgICAgICAgICAgICAgW1BhZ2UgMTRdDQoMDQpJbnRlcm5ldC1EcmFmdCAg ICAgICAgT1BFUyBDYWxsb3V0IFByb3RvY29sIChPQ1ApICAgICAgICAgICAg IE1hcmNoIDIwMDMNCg0KDQogICBzYWlkIHRvIGJlICJwYXVzZWQiLiBJZiB0 aGUgU0VSVkVSIHJlY2VpdmVzIHVuZXhwZWN0ZWQgZGF0YSBmb3IgYQ0KICAg cGF1c2VkIG1lc3NhZ2UgKGEgdmlvbGF0aW9uIG9mIHRoZSBhYm92ZSBNVVNU cyksIHRoZSBTRVJWRVIgTUFZIGFib3J0DQogICBhcHBsaWNhdGlvbiBtZXNz YWdlIHByb2Nlc3NpbmcuDQoNCjYuMTIgZGF0YS1lbmQNCg0KICAgZGF0YS1l bmQgeGlkIGFtLWlkIFtlcnJvcl0gcmVzdWx0DQoNCiAgIEluZm9ybXMgdGhl IHJlY2lwaWVudCB0aGF0IHRoZXJlIHdpbGwgYmUgbm8gbW9yZSBkYXRhIGZv ciB0aGUNCiAgIGNvcnJlc3BvbmRpbmcgYXBwbGljYXRpb24gbWVzc2FnZS4g SWYgdGhlIHJlY2lwaWVudCByZWNlaXZlcyBtb3JlDQogICBkYXRhIGFmdGVy IHRoZSBkYXRhLWVuZCBtZXNzYWdlLCBpdCBNVVNUIGFib3J0IGFwcGxpY2F0 aW9uIG1lc3NhZ2UNCiAgIHByb2Nlc3NpbmcuDQoNCiAgIEEgZGF0YS1lbmQg bWVzc2FnZSBlbmRzIGFueSBkYXRhIHByZXNlcnZhdGlvbiBjb21taXRtZW50 cyBhc3NvY2lhdGVkDQogICB3aXRoIHRoZSBjb3JyZXNwb25kaW5nIGFwcGxp Y2F0aW9uIG1lc3NhZ2UuDQoNCjYuMTMgZGF0YS1uZWVkDQoNCiAgIGRhdGEt bmVlZCB4aWQgYW0taWQgb2Zmc2V0IFtzaXplXQ0KDQogICBJbmZvcm1zIHRo ZSBDTElFTlQgdGhhdCB0aGUgU0VSVkVSIG5lZWRzIG1vcmUgYXBwbGljYXRp b24gbWVzc2FnZQ0KICAgZGF0YS4gVGhlICJvZmZzZXQiIHBhcmFtZXRlciBp bmRpY2F0ZXMgdGhlIGFtb3VudCBvZiBkYXRhIGFscmVhZHkNCiAgIHJlY2Vp dmVkLiBUaGUgQ0xJRU5UIE1VU1QgaWdub3JlIGEgZGF0YS1uZWVkIG1lc3Nh Z2UgaWYgdGhlIENMSUVOVA0KICAgYWxyZWFkeSBzZW50IGRhdGEgd2l0aCBo aWdoZXIgb2Zmc2V0cy4NCg0KICAgSWYgYSAic2l6ZSIgcGFyYW1ldGVyIGlz IHByZXNlbnQsIGl0cyB2YWx1ZSBpcyB0aGUgc3VnZ2VzdGVkIGRhdGENCiAg IHNpemUsIGFuZCBpdCBNQVkgYmUgaWdub3JlZCBieSB0aGUgQ0xJRU5ULiBB biBhYnNlbnQgInNpemUiIHBhcmFtZXRlcg0KICAgaW1wbGllcyAiYW55IHNp emUiLiBUaGlzIG1lc3NhZ2UgY2xlYXJzIHRoZSAicGF1c2VkIiBzdGF0ZSBv ZiB0aGUNCiAgIGFwcGxpY2F0aW9uIG1lc3NhZ2UgcHJvY2Vzc2luZy4NCg0K ICAgQSBDTElFTlQgTVVTVCBOT1Qgc2VuZCBkYXRhLW5lZWQgbWVzc2FnZXMg KFhYWDogc2hvdWxkIHdlIGdpdmUgYQ0KICAgQ0xJRU5UIHRoZSBzYW1lIGFi aWxpdGllcyB0byBwYXVzZS9yZXN1bWUgbWVzc2FnZSBwcm9jZXNzaW5nIHRo YXQgYQ0KICAgU0VSVkVSIGhhcz8pDQoNCjYuMTQgZGF0YS1hY2sNCg0KICAg ZGF0YS1hY2sgeGlkIGFtLWlkIG9mZnNldCBzaXplIFt3b250LWZvcndhcmRd DQoNCiAgIEluZm9ybXMgdGhlIENMSUVOVCB0aGF0IHRoZSBjb3JyZXNwb25k aW5nIGRhdGEgY2h1bmsgaGFzIGJlZW4NCiAgIHJlY2VpdmVkIGJ5IHRoZSBT RVJWRVIuDQoNCiAgIEFuIG9wdGlvbmFsICJ3b250LWZvcndhcmQiIGZsYWcg dGVybWluYXRlcyBwcmVzZXJ2YXRpb24gY29tbWl0bWVudA0KICAgZm9yIHRo ZSBjb3JyZXNwb25kaW5nIGRhdGEsIGlmIGFueS4gVGhlIGZsYWcgaXMgZGVm aW5lZCBmb3IgU0VSVkVSDQogICAnZGF0YS1hY2snIG1lc3NhZ2VzIG9ubHku DQoNCiAgIFJlc3BvbmRpbmcgd2l0aCAnZGF0YS1hY2snIG1lc3NhZ2VzIHRv ICdkYXRhLWhhdmUnIG1lc3NhZ2VzIHdpdGggYQ0KICAgInBsZWFzZS1hY2si IGZsYWcgaXMgUkVRVUlSRUQuIFJlc3BvbmRpbmcgd2l0aCAnZGF0YS1hY2sn IG1lc3NhZ2VzIHRvDQogICAnZGF0YS1oYXZlJyBtZXNzYWdlcyB3aXRob3V0 IGFuICJhY2siIGZsYWcgaXMgT1BUSU9OQUwuDQoNCg0KDQpSb3Vzc2tvdiAg ICAgICAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDI5LCAyMDAzICAgICAg ICAgICAgICBbUGFnZSAxNV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICBP UEVTIENhbGxvdXQgUHJvdG9jb2wgKE9DUCkgICAgICAgICAgICAgTWFyY2gg MjAwMw0KDQoNCiAgIEltcGxlbWVudGF0aW9ucyBTSE9VTEQgYmUgYWJsZSB0 byBzdXBwb3J0IGRlYnVnZ2luZyBtb2RlIHdoZXJlIGV2ZXJ5DQogICAnZGF0 YS1oYXZlJyBtZXNzYWdlIGlzIGFja2VkLiAoWFhYOiBzaG91bGQgd2UgcmVx dWlyZSByZXNwb25zZXMgZm9yDQogICAnZGF0YS1hcy1pcz4gbWVzc2FnZXMg YXMgd2VsbD8pDQoNCiAgIEEgJ2RhdGEtYWNrJyByZXNwb25zZSBTSE9VTEQg YmUgc2VudCBhcyBzb29uIGFzIHBvc3NpYmxlLiAgSWYgdGhlDQogICBTRVJW RVIgZG9lcyBub3Qga25vdyBpbW1lZGlhdGVseSB3aGV0aGVyIGl0IHdpbGwg Zm9yd2FyZCB0aGUgZGF0YSwgaXQNCiAgIE1VU1QgcmVzcG9uZCB3aXRob3V0 IGEgIndvbnQtZm9yd2FyZCIgZmxhZy4gSWYsIGF0IGFueSB0aW1lLCB0aGUN CiAgIFNFUlZFUiBkZWNpZGVzIHRoYXQgaXQgd2lsbCBub3QgZm9yd2FyZCB0 aGUgZGF0YSwgaXQgU0hPVUxEIHNlbmQgYQ0KICAgJ2RhdGEtYWNrJyBtZXNz YWdlIHdpdGggYSAid29udC1mb3J3YXJkIiBmbGFnLiAgVGh1cywgbXVsdGlw bGUNCiAgICdkYXRhLWFjaycgbWVzc2FnZXMgYW5kIHVuc29saWNpdGVkICdk YXRhLWFjaycgbWVzc2FnZXMgYXJlIGFsbG93ZWQuDQoNCiAgIFNlbmRpbmcg b2YgYSAnZGF0YS1hY2snIG1lc3NhZ2UgbWVhbnMgdGhhdCBhIGNvbXBsZXRl ICdkYXRhLWhhdmUnDQogICBtZXNzYWdlIGhhcyBiZWVuIHJlY2VpdmVkLCBi dXQgZG9lcyBub3QgaW1wbHkgdGhhdCB0aGUgZGF0YSBoYXMgYmVlbg0KICAg cHJvY2Vzc2VkLg0KDQo2LjE1IGktYW0taGVyZQ0KDQogICBpLWFtLWhlcmUg W3JpZF0gW3hpZCBbYW0taWRdXQ0KDQogICBQYXJhbWV0ZXJsZXNzIGZvcm0g aW5mb3JtcyB0aGUgcmVjaXBpZW50IHRoYXQgdGhlIHNlbmRlciBpcyBzdGls bA0KICAgbWFpbnRhaW5pbmcgdGhlIE9DUCBjb25uZWN0aW9uLiBJZiAieGlk IiBvciAiYW0taWQiIGlkZW50aWZpZXIocykgYXJlDQogICB1c2VkLCB0aGUg bWVzc2FnZSBpbmZvcm1zIHRoZSByZWNpcGllbnQgdGhhdCB0aGUgc2VuZGVy IGlzIHN0aWxsDQogICBwcm9jZXNzaW5nIHRoZSBjb3JyZXNwb25kaW5nIHRy YW5zYWN0aW9uIG9yIGFuIGFwcGxpY2F0aW9uIG1lc3NhZ2UuDQoNCiAgIEFu ICdpLWFtLWhlcmUnIG1lc3NhZ2UgTUFZIGJlIHNlbnQgd2l0aG91dCBzb2xp Y2l0YXRpb24uIEluIHN1Y2gNCiAgIGNhc2UsIGl0IE1VU1QgTk9UIGhhdmUg YSAicmlkIiBwYXJhbWV0ZXIuDQoNCiAgIEFuICdpLWFtLWhlcmUnIG1lc3Nh Z2UgTVVTVCBiZSBzZW50IGluIHJlc3BvbnNlIHRvIGFuICdhcmUteW91LXRo ZXJlJw0KICAgcmVxdWVzdC4gVGhlICJyaWQiIHZhbHVlIGluIHRoZSByZXNw b25zZSBNVVNUIGJlIHNldCB0byAicmlkIiB2YWx1ZQ0KICAgb2YgdGhlIHJl cXVlc3QuIFRoZSByZXNwb25zZSBNVVNUIGhhdmUgdGhlIHNhbWUgc2V0IG9m ICJ4aWQiIGFuZA0KICAgImFtLWlkIiBwYXJhbWV0ZXJzIGlmIHRob3NlIGlk ZW50aWZpZXJzIGFyZSBzdGlsbCB2YWxpZC4gVGhlIHJlc3BvbnNlDQogICBN VVNUIE5PVCB1c2UgaW52YWxpZCBpZGVudGlmaWVycy4NCg0KNi4xNiBhcmUt eW91LXRoZXJlDQoNCiAgIGFyZS15b3UtdGhlcmUgcmlkIFt4aWQgW2FtLWlk XV0NCg0KICAgU29saWNpdHMgYW4gaW1tZWRpYXRlICdpLWFtLWhlcmUnIHJl c3BvbnNlLiBJZiB0aGUgcmVzcG9uc2UgZG9lcyBub3QNCiAgIHVzZSB0aGUg c2FtZSBzZXQgb2YgInhpZCIgYW5kICJhbS1pZCIgcGFyYW1ldGVycywgdGhl IHJlY2lwaWVudCBNQVkNCiAgIGFzc3VtZSB0aGF0IG1pc3NpbmcgaWRlbnRp ZmllcihzKSBjb3JyZXNwb25kIHRvIE9DUCB0cmFuc2FjdGlvbiBvcg0KICAg YXBwbGljYXRpb24gbWVzc2FnZSB0aGF0IHdhcyBub3QgbWFpbnRhaW5lZCBh dCB0aGUgdGltZSB0aGUgcmVzcG9uc2UNCiAgIHdhcyBnZW5lcmF0ZWQuDQoN CiAgIFRoZSByZWNpcGllbnQgTVVTVCBoYW5kbGUgYW4gJ2FyZS15b3UtdGhl cmUnIHJlcXVlc3QgZXZlbiBpZg0KICAgdHJhbnNhY3Rpb24gb3IgYXBwbGlj YXRpb24gbWVzc2FnZSBpZGVudGlmaWVycyBhcmUgaW52YWxpZCBmcm9tIHRo ZQ0KICAgcmVjaXBpZW50IHBvaW50IG9mIHZpZXcuIE5vcm1hbGx5LCBtZXNz YWdlcyB3aXRoIGludmFsaWQgaWRlbnRpZmllcnMNCiAgIGFyZSBpZ25vcmVk Lg0KDQoNCg0KDQpSb3Vzc2tvdiAgICAgICAgICAgICAgIEV4cGlyZXMgU2Vw dGVtYmVyIDI5LCAyMDAzICAgICAgICAgICAgICBbUGFnZSAxNl0NCgwNCklu dGVybmV0LURyYWZ0ICAgICAgICBPUEVTIENhbGxvdXQgUHJvdG9jb2wgKE9D UCkgICAgICAgICAgICAgTWFyY2ggMjAwMw0KDQoNCjYuMTcgZG8teW91LXN1 cHBvcnQNCg0KICAgZG8teW91LXN1cHBvcnQgZmVhdHVyZQ0KDQo2LjE4IGkt ZG8tc3VwcG9ydA0KDQogICBpLWRvLXN1cHBvcnQgZmVhdHVyZQ0KDQo2LjE5 IGktZG9udC1zdXBwb3J0DQoNCiAgIGktZG9udC1zdXBwb3J0IGZlYXR1cmUN Cg0KNi4yMCBwbGVhc2UtdXNlDQoNCiAgIHBsZWFzZS11c2UgZmVhdHVyZQ0K DQo2LjIxIGktd2lsbC11c2UNCg0KICAgaS13aWxsLXVzZSBmZWF0dXJlDQoN CjYuMjIgaS13b250LXVzZQ0KDQogICBpLXdvbnQtdXNlIGZlYXR1cmUNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KUm91c3Nrb3YgICAgICAgICAgICAgICBFeHBpcmVzIFNlcHRl bWJlciAyOSwgMjAwMyAgICAgICAgICAgICAgW1BhZ2UgMTddDQoMDQpJbnRl cm5ldC1EcmFmdCAgICAgICAgT1BFUyBDYWxsb3V0IFByb3RvY29sIChPQ1Ap ICAgICAgICAgICAgIE1hcmNoIDIwMDMNCg0KDQo3LiBBcHBsaWNhdGlvbiBQ cm90b2NvbCBSZXF1aXJlbWVudHMNCg0KICAgTm90IGFsbCBhcHBsaWNhdGlv biBwcm90b2NvbHMgY2FuIGJlIGFkYXB0ZWQgd2l0aCBPQ1AuICBDb21waWxp bmcgYQ0KICAgY29tcGxldGUgbGlzdCBvZiBrbm93biBsaW1pdGF0aW9ucyBp cyBpbXBvc3NpYmxlIHNpbmNlICJhcHBsaWNhdGlvbg0KICAgcHJvdG9jb2wi IGlzIG5vdCBhIHdlbGwgZGVmaW5lZCB0ZXJtLiAgSG93ZXZlciwgbGlzdGlu ZyBrbm93bg0KICAgbGltaXRhdGlvbnMgY2FuIGhlbHAgaXQgZGV0ZXJtaW5p bmcgT0NQIGFwcGxpY2FiaWxpdHkuIFRoaXMgc2VjdGlvbg0KICAgaXMgbm90 IGEgbm9ybWF0aXZlIHBhcnQgb2YgdGhlIE9DUCBzcGVjaWZpY2F0aW9uLg0K DQogICAgICBBcHBsaWNhdGlvbiBwcm90b2NvbCBtZXNzYWdlcyBtdXN0IGhh dmUgYnl0ZSBib3VuZGFyaWVzLiBPQ1AgY2FuDQogICAgICBvbmx5IGhhbmRs ZSBhcHBsaWNhdGlvbiBtZXNzYWdlcyB3aXRoIHRoZSBudW1iZXIgb2YgYml0 cyBkaXZpc2libGUNCiAgICAgIGJ5IDguDQoNCiAgIFhYWA0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNClJvdXNza292ICAgICAgICAgICAgICAg RXhwaXJlcyBTZXB0ZW1iZXIgMjksIDIwMDMgICAgICAgICAgICAgIFtQYWdl IDE4XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgIE9QRVMgQ2FsbG91dCBQ cm90b2NvbCAoT0NQKSAgICAgICAgICAgICBNYXJjaCAyMDAzDQoNCg0KOC4g SUFCIENvbmNlcm5zDQoNCiAgIERvY3VtZW50IGhvdyBPQ1AgYWRkcmVzc2Vz IGFwcGxpY2FibGUgSUFCIGNvbmNlcm5zLiBYWFguDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpSb3Vzc2tv diAgICAgICAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDI5LCAyMDAzICAg ICAgICAgICAgICBbUGFnZSAxOV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAg ICBPUEVTIENhbGxvdXQgUHJvdG9jb2wgKE9DUCkgICAgICAgICAgICAgTWFy Y2ggMjAwMw0KDQoNCjkuIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQoNCiAg IERvY3VtZW50LiBYWFguDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpSb3Vzc2tvdiAgICAgICAgICAgICAg IEV4cGlyZXMgU2VwdGVtYmVyIDI5LCAyMDAzICAgICAgICAgICAgICBbUGFn ZSAyMF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICBPUEVTIENhbGxvdXQg UHJvdG9jb2wgKE9DUCkgICAgICAgICAgICAgTWFyY2ggMjAwMw0KDQoNCjEw LiBDb21wbGlhbmNlDQoNCiAgIE9ubHkgbm9ybWF0aXZlIHBhcnRzIG9mIHRo aXMgc3BlY2lmaWNhdGlvbiBhZmZlY3QgaW1wbGVtZW50YXRpb24NCiAgIGNv bXBsaWFuY2UuIE5vcm1hdGl2ZSBwYXJ0cyBhcmUgZWl0aGVyIGV4cGxpY2l0 bHkgbWFya2VkIGFzIHN1Y2gNCiAgIHVzaW5nIHRoZSB3b3JkICJub3JtYXRp dmUiIG9yIGFyZSBwaHJhc2VzIGNvbnRhaW5pbmcgY2FwaXRhbGl6ZWQNCiAg IGtleXdvcmRzIGZyb20gW1JGQzIxMTldLg0KDQogICBBbiBpbXBsZW1lbnRh dGlvbiBpcyBub3QgY29tcGxpYW50IGlmIGl0IGZhaWxzIHRvIHNhdGlzZnkg b25lIG9yIG1vcmUNCiAgIG9mIHRoZSBNVVNUIG9yIFJFUVVJUkVEIGxldmVs IHJlcXVpcmVtZW50cyBmb3IgdGhlIHByb3RvY29scyBpdA0KICAgaW1wbGVt ZW50cy4gQW4gaW1wbGVtZW50YXRpb24gdGhhdCBzYXRpc2ZpZXMgYWxsIHRo ZSBNVVNUIG9yIFJFUVVJUkVEDQogICBsZXZlbCBhbmQgYWxsIHRoZSBTSE9V TEQgbGV2ZWwgcmVxdWlyZW1lbnRzIGZvciBpdHMgcHJvdG9jb2xzIGlzIHNh aWQNCiAgIHRvIGJlICJ1bmNvbmRpdGlvbmFsbHkgY29tcGxpYW50Ijsgb25l IHRoYXQgc2F0aXNmaWVzIGFsbCB0aGUgTVVTVA0KICAgbGV2ZWwgcmVxdWly ZW1lbnRzIGJ1dCBub3QgYWxsIHRoZSBTSE9VTEQgbGV2ZWwgcmVxdWlyZW1l bnRzIGZvciBpdHMNCiAgIHByb3RvY29scyBpcyBzYWlkIHRvIGJlICJjb25k aXRpb25hbGx5IGNvbXBsaWFudCIuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNClJvdXNza292ICAgICAgICAgICAgICAgRXhwaXJlcyBTZXB0ZW1i ZXIgMjksIDIwMDMgICAgICAgICAgICAgIFtQYWdlIDIxXQ0KDA0KSW50ZXJu ZXQtRHJhZnQgICAgICAgIE9QRVMgQ2FsbG91dCBQcm90b2NvbCAoT0NQKSAg ICAgICAgICAgICBNYXJjaCAyMDAzDQoNCg0KMTEuIFRvLWRvDQoNCiAgIGNv bXBsaWFuY2U6IERvIHdlIHJlYWxseSBuZWVkIHR3byBsZXZlbHMgb2YgY29t cGxpYW5jZSAoY29uZGl0aW9uYWwNCiAgICAgIGFuZCB1bmNvbmRpdGlvbmFs KT8NCg0KICAgdGltZW91dHM6IGRvY3VtZW50IHdoYXQgbWVzc2FnZXMgY2F1 c2Ugd2hhdCB0aW1lcnMgdG8gYmUgW3JlXXNldC4NCg0KICAgbW9kaWZpZWQ6 IHNob3VsZCB0aGlzIHBhcmFtZXRlciBiZSByZXF1aXJlZD8gIElzIGl0IHBv c3NpYmxlIHRoYXQgdGhlDQogICAgICBTRVJWRVIgZG9lcyBub3Qga25vdyB3 aGV0aGVyIHRoZSBkYXRhIGdvdCBtb2RpZmllZCAoY29uc2lkZXINCiAgICAg IHNlcnZpY2Ugb3V0c291cmNpbmcgc2NlbmFyaW8sIGZvciBleGFtcGxlKS4N Cg0KICAgY29waWVkOiB3aGVuIGEgQ0xJRU5UIGNhbiBkZXN0cm95IGEgY29w eT8NCg0KICAgYXNpczogQ2FuIGEgU0VSVkVSIHJlZmVyIHRvIHBhcnRzIG9m IFtjb3BpZWRdIGRhdGEgbWVzc2FnZXMgZnJvbSB0aGUNCiAgICAgIENMSUVO VD8gSWYgeWVzLCBkbyB3ZSBuZWVkIHRvIHdvcnJ5IGFib3V0IGZyYWdtZW50 YXRpb24gaWYgeWVzPyBJZg0KICAgICAgbm8sIHdpbGwgdGhpcyByZXN0cmlj dGlvbiBraWxsIHRoZSBvcHRpbWl6YXRpb24gZm9yIG1pZC1zaXplDQogICAg ICBhcHBsaWNhdGlvbiBtZXNzYWdlcyAodGhlIGNvbW1vbiBjYXNlPykgdGhh dCBhcmUgbGlrZWx5IHRvIGJlDQogICAgICBwYXNzZWQgdG8gdGhlIFNFUlZF UiBpbiBqdXN0IG9uZSBvciB0d28gY2h1bmtzPw0KDQogICBwYXJ0aWFsOiBT aG91bGQgd2Ugc3VwcG9ydCBwYXJ0aWFsIGFwcGxpY2F0aW9uIG1lc3NhZ2Ug ZXhjaGFuZ2UNCiAgICAgIChleGNoYW5nZSBvbmx5IGEgcGFydCBvZiB0aGUg YXBwbGljYXRpb24gbWVzc2FnZSk/IFdobyBkZWNpZGVzDQogICAgICB3aGF0 IHBhcnRzIHRvIGV4Y2hhbmdlPyBTaG91bGQgdGhlIGNhbGxvdXQgc2VydmVy IGJlIGFibGUgdG8gYXNrDQogICAgICB3aGljaCBwYXJ0IGl0IHdhbnRzPyBI b3cgd2lsbCBpdCBkZXNjcmliZSB0aGUgcGFydCBpZiBpdCBoYXMgbm90DQog ICAgICBzZWVuIHRoZSBlbnRpcmUgbWVzc2FnZT8NCg0KICAgYnJlYWs6IGFs bG93IGEgU0VSVkVSIHRvIGdldCBvdXQgb2YgdGhlIHByb2Nlc3NpbmcgbG9v cCB3aXRob3V0DQogICAgICBsb3NpbmcgdGhlIGRhdGEuDQoNCiAgIGZhc3Qg dHJhY2s6IERvY3VtZW50IG1lc3NhZ2VzIHRoYXQgbWF5IGJlIHNlbnQgb24g YWx0ZXJuYXRpdmUNCiAgICAgIGNvbm5lY3Rpb25zLiBSZXF1aXJlIG90aGVy LWNvbm5lY3Rpb25zIG1lc3NhZ2VzIHRvIGJlIGR1cGxpY2F0ZWQNCiAgICAg IG9uIHRoZSBwcmltYXJ5IGNvbm5lY3Rpb24uDQoNCiAgIG1vZHA6IE1pbiBh bmQgbWF4IHZhbHVlcyAoMCBhbmQgMTAwKSBzaG91bGQgYmUgImNvbW1pdG1l bnRzIiByYXRoZXINCiAgICAgIHRoYW4gInByb2JhYmlsaXRpZXMiLg0KDQog ICB0cmFuc2FjdGlvbnMtZW5kOiBEZWNpZGUgd2hldGhlciB3ZSBuZWVkIGEg J3RyYW5zYWN0aW9ucy1lbmQnIG1lc3NhZ2UNCiAgICAgIHRvIHRlcm1pbmF0 ZSBtdWx0aXBsZSB0cmFuc2FjdGlvbnMgZWZmaWNpZW50bHkuIElzIHRlcm1p bmF0aW5nIGENCiAgICAgIGNvbm5lY3Rpb24gZ29vZCBlbm91Z2g/DQoNCiAg IGFib3J0IG5lZ290aWF0aW9uOiBTaG91bGQgd2UgbGV0IHRoZSBvdGhlciBz aWRlIGFmZmVjdCB0aGUgYWJvcnQNCiAgICAgIGRlY2lzaW9uIG9uIE9QRVMg bGV2ZWw/IFBlcmhhcHMgdGhlIGNhbGxvdXQgc2VydmVyIGlzIGRvaW5nIHNv bWUNCiAgICAgIGxvZ2dpbmcgb3IgYWNjb3VudGluZyBhbmQgTVVTVCBzZWUg ZXZlcnkgYnl0ZSByZWNlaXZlZCBieSB0aGUgT1BFUw0KICAgICAgcHJvY2Vz c29yLCBldmVuIGlmIHRoZSBhcHBsaWNhdGlvbiBtZXNzYWdlIGlzIGFib3J0 ZWQgYnkgdGhlDQogICAgICBwcm9jZXNzb3IuIFNob3VsZCB3ZSBhZGQgc29t ZSBraW5kIG9mICd4YWN0aW9uLW5lZWQtYWxsJyBtZXNzYWdlPw0KICAgICAg T3Igc2hvdWxkIHdlIGFzc3VtZSB0aGF0IHRoZSBkaXNwYXRjaGVyIGFsd2F5 cyBrbm93cyBjYWxsb3V0DQogICAgICBzZXJ2ZXIgbmVlZHMgYW5kIHZpY2Ug dmVyc2E/DQoNCg0KDQoNCg0KUm91c3Nrb3YgICAgICAgICAgICAgICBFeHBp cmVzIFNlcHRlbWJlciAyOSwgMjAwMyAgICAgICAgICAgICAgW1BhZ2UgMjJd DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgT1BFUyBDYWxsb3V0IFByb3Rv Y29sIChPQ1ApICAgICAgICAgICAgIE1hcmNoIDIwMDMNCg0KDQogICBwcm94 eWluZyBDYW4gT0NQIGJlIHByb3hpZWQgYWJvdmUgdHJhbnNwb3J0IGxheWVy PyBQZXJoYXBzIHRvDQogICAgICBpbXBsZW1lbnQgcGFydHMgb2YgYSBnaXZl biBzZXJ2aWNlLCB0cmFuc3BhcmVudGx5IHRvIHRoZSBPUEVTDQogICAgICBw cm9jZXNzb3I/DQoNCiAgIG5vcm1hdGl2ZSBJRHM6IFRvIGJlIG5vcm1hdGl2 ZSwgT1BFUyBJbnRlcm5ldC1EcmFmdHMgbXVzdCBiZSByZXBsYWNlZA0KICAg ICAgd2l0aCBjb3JyZXNwb25kaW5nIFJGQ3Mgd2hlbiB0aGUgbGF0dGVyIGFy ZSBwdWJsaXNoZWQuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQpSb3Vzc2tvdiAgICAgICAgICAgICAgIEV4cGlyZXMg U2VwdGVtYmVyIDI5LCAyMDAzICAgICAgICAgICAgICBbUGFnZSAyM10NCgwN CkludGVybmV0LURyYWZ0ICAgICAgICBPUEVTIENhbGxvdXQgUHJvdG9jb2wg KE9DUCkgICAgICAgICAgICAgTWFyY2ggMjAwMw0KDQoNCk5vcm1hdGl2ZSBS ZWZlcmVuY2VzDQoNCiAgIFtSRkMyMTE5XSAgQnJhZG5lciwgUy4sICJLZXkg d29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlDQogICAgICAgICAg ICAgIFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTksIE1h cmNoIDE5OTcuDQoNCiAgIFtJLUQuaWV0Zi1vcGVzLWFyY2hpdGVjdHVyZV0N CiAgICAgICAgICAgICAgQmFyYmlyLCBBLiwgIkFuIEFyY2hpdGVjdHVyZSBm b3IgT3BlbiBQbHVnZ2FibGUgRWRnZQ0KICAgICAgICAgICAgICBTZXJ2aWNl cyAoT1BFUykiLCBkcmFmdC1pZXRmLW9wZXMtYXJjaGl0ZWN0dXJlLTA0ICh3 b3JrIGluDQogICAgICAgICAgICAgIHByb2dyZXNzKSwgRGVjZW1iZXIgMjAw Mi4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClJv dXNza292ICAgICAgICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjksIDIw MDMgICAgICAgICAgICAgIFtQYWdlIDI0XQ0KDA0KSW50ZXJuZXQtRHJhZnQg ICAgICAgIE9QRVMgQ2FsbG91dCBQcm90b2NvbCAoT0NQKSAgICAgICAgICAg ICBNYXJjaCAyMDAzDQoNCg0KSW5mb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQog ICBbSS1ELmlldGYtb3Blcy1wcm90b2NvbC1yZXFzXQ0KICAgICAgICAgICAg ICBCZWNrLCBBLiwgIlJlcXVpcmVtZW50cyBmb3IgT1BFUyBDYWxsb3V0IFBy b3RvY29scyIsDQogICAgICAgICAgICAgIGRyYWZ0LWlldGYtb3Blcy1wcm90 b2NvbC1yZXFzLTAzICh3b3JrIGluIHByb2dyZXNzKSwNCiAgICAgICAgICAg ICAgRGVjZW1iZXIgMjAwMi4NCg0KICAgW0ktRC5pZXRmLW9wZXMtc2NlbmFy aW9zXQ0KICAgICAgICAgICAgICBCYXJiaXIsIEEuLCAiT1BFUyBVc2UgQ2Fz ZXMgYW5kIERlcGxveW1lbnQgU2NlbmFyaW9zIiwNCiAgICAgICAgICAgICAg ZHJhZnQtaWV0Zi1vcGVzLXNjZW5hcmlvcy0wMSAod29yayBpbiBwcm9ncmVz cyksIEF1Z3VzdA0KICAgICAgICAgICAgICAyMDAyLg0KDQogICBbUkZDMzA4 MF0gIFJvc2UsIE0uLCAiVGhlIEJsb2NrcyBFeHRlbnNpYmxlIEV4Y2hhbmdl IFByb3RvY29sIENvcmUiLA0KICAgICAgICAgICAgICBSRkMgMzA4MCwgTWFy Y2ggMjAwMS4NCg0KDQpBdXRob3IncyBBZGRyZXNzDQoNCiAgIEFsZXggUm91 c3Nrb3YNCiAgIFRoZSBNZWFzdXJlbWVudCBGYWN0b3J5DQogICAxMjAwIFBl YXJsIFN0cmVldCwgU3VpdGUgNzANCiAgIEJvdWxkZXIsIENPDQogICBVUw0K DQogICBFTWFpbDogcm91c3Nrb3ZAbWVhc3VyZW1lbnQtZmFjdG9yeS5jb20N CiAgIFVSSTogICBodHRwOi8vd3d3Lm1lYXN1cmVtZW50LWZhY3RvcnkuY29t Lw0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQpSb3Vzc2tvdiAgICAgICAgICAgICAgIEV4cGlyZXMgU2VwdGVt YmVyIDI5LCAyMDAzICAgICAgICAgICAgICBbUGFnZSAyNV0NCgwNCkludGVy bmV0LURyYWZ0ICAgICAgICBPUEVTIENhbGxvdXQgUHJvdG9jb2wgKE9DUCkg ICAgICAgICAgICAgTWFyY2ggMjAwMw0KDQoNCkludGVsbGVjdHVhbCBQcm9w ZXJ0eSBTdGF0ZW1lbnQNCg0KICAgVGhlIElFVEYgdGFrZXMgbm8gcG9zaXRp b24gcmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBvciBzY29wZSBvZiBhbnkNCiAg IGludGVsbGVjdHVhbCBwcm9wZXJ0eSBvciBvdGhlciByaWdodHMgdGhhdCBt aWdodCBiZSBjbGFpbWVkIHRvDQogICBwZXJ0YWluIHRvIHRoZSBpbXBsZW1l bnRhdGlvbiBvciB1c2Ugb2YgdGhlIHRlY2hub2xvZ3kgZGVzY3JpYmVkIGlu DQogICB0aGlzIGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8gd2hpY2ggYW55 IGxpY2Vuc2UgdW5kZXIgc3VjaCByaWdodHMNCiAgIG1pZ2h0IG9yIG1pZ2h0 IG5vdCBiZSBhdmFpbGFibGU7IG5laXRoZXIgZG9lcyBpdCByZXByZXNlbnQg dGhhdCBpdA0KICAgaGFzIG1hZGUgYW55IGVmZm9ydCB0byBpZGVudGlmeSBh bnkgc3VjaCByaWdodHMuIEluZm9ybWF0aW9uIG9uIHRoZQ0KICAgSUVURidz IHByb2NlZHVyZXMgd2l0aCByZXNwZWN0IHRvIHJpZ2h0cyBpbiBzdGFuZGFy ZHMtdHJhY2sgYW5kDQogICBzdGFuZGFyZHMtcmVsYXRlZCBkb2N1bWVudGF0 aW9uIGNhbiBiZSBmb3VuZCBpbiBCQ1AtMTEuIENvcGllcyBvZg0KICAgY2xh aW1zIG9mIHJpZ2h0cyBtYWRlIGF2YWlsYWJsZSBmb3IgcHVibGljYXRpb24g YW5kIGFueSBhc3N1cmFuY2VzIG9mDQogICBsaWNlbnNlcyB0byBiZSBtYWRl IGF2YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBhbiBhdHRlbXB0IG1hZGUg dG8NCiAgIG9idGFpbiBhIGdlbmVyYWwgbGljZW5zZSBvciBwZXJtaXNzaW9u IGZvciB0aGUgdXNlIG9mIHN1Y2gNCiAgIHByb3ByaWV0YXJ5IHJpZ2h0cyBi eSBpbXBsZW1lbnRvcnMgb3IgdXNlcnMgb2YgdGhpcyBzcGVjaWZpY2F0aW9u IGNhbg0KICAgYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBTZWNyZXRhcmlh dC4NCg0KICAgVGhlIElFVEYgaW52aXRlcyBhbnkgaW50ZXJlc3RlZCBwYXJ0 eSB0byBicmluZyB0byBpdHMgYXR0ZW50aW9uIGFueQ0KICAgY29weXJpZ2h0 cywgcGF0ZW50cyBvciBwYXRlbnQgYXBwbGljYXRpb25zLCBvciBvdGhlciBw cm9wcmlldGFyeQ0KICAgcmlnaHRzIHdoaWNoIG1heSBjb3ZlciB0ZWNobm9s b2d5IHRoYXQgbWF5IGJlIHJlcXVpcmVkIHRvIHByYWN0aWNlDQogICB0aGlz IHN0YW5kYXJkLiBQbGVhc2UgYWRkcmVzcyB0aGUgaW5mb3JtYXRpb24gdG8g dGhlIElFVEYgRXhlY3V0aXZlDQogICBEaXJlY3Rvci4NCg0KDQpGdWxsIENv cHlyaWdodCBTdGF0ZW1lbnQNCg0KICAgQ29weXJpZ2h0IChDKSBUaGUgSW50 ZXJuZXQgU29jaWV0eSAoMjAwMykuIEFsbCBSaWdodHMgUmVzZXJ2ZWQuDQoN CiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRyYW5zbGF0aW9ucyBvZiBpdCBtYXkg YmUgY29waWVkIGFuZCBmdXJuaXNoZWQgdG8NCiAgIG90aGVycywgYW5kIGRl cml2YXRpdmUgd29ya3MgdGhhdCBjb21tZW50IG9uIG9yIG90aGVyd2lzZSBl eHBsYWluIGl0DQogICBvciBhc3Npc3QgaW4gaXRzIGltcGxlbWVudGF0aW9u IG1heSBiZSBwcmVwYXJlZCwgY29waWVkLCBwdWJsaXNoZWQNCiAgIGFuZCBk aXN0cmlidXRlZCwgaW4gd2hvbGUgb3IgaW4gcGFydCwgd2l0aG91dCByZXN0 cmljdGlvbiBvZiBhbnkNCiAgIGtpbmQsIHByb3ZpZGVkIHRoYXQgdGhlIGFi b3ZlIGNvcHlyaWdodCBub3RpY2UgYW5kIHRoaXMgcGFyYWdyYXBoIGFyZQ0K ICAgaW5jbHVkZWQgb24gYWxsIHN1Y2ggY29waWVzIGFuZCBkZXJpdmF0aXZl IHdvcmtzLiBIb3dldmVyLCB0aGlzDQogICBkb2N1bWVudCBpdHNlbGYgbWF5 IG5vdCBiZSBtb2RpZmllZCBpbiBhbnkgd2F5LCBzdWNoIGFzIGJ5IHJlbW92 aW5nDQogICB0aGUgY29weXJpZ2h0IG5vdGljZSBvciByZWZlcmVuY2VzIHRv IHRoZSBJbnRlcm5ldCBTb2NpZXR5IG9yIG90aGVyDQogICBJbnRlcm5ldCBv cmdhbml6YXRpb25zLCBleGNlcHQgYXMgbmVlZGVkIGZvciB0aGUgcHVycG9z ZSBvZg0KICAgZGV2ZWxvcGluZyBJbnRlcm5ldCBzdGFuZGFyZHMgaW4gd2hp Y2ggY2FzZSB0aGUgcHJvY2VkdXJlcyBmb3INCiAgIGNvcHlyaWdodHMgZGVm aW5lZCBpbiB0aGUgSW50ZXJuZXQgU3RhbmRhcmRzIHByb2Nlc3MgbXVzdCBi ZQ0KICAgZm9sbG93ZWQsIG9yIGFzIHJlcXVpcmVkIHRvIHRyYW5zbGF0ZSBp dCBpbnRvIGxhbmd1YWdlcyBvdGhlciB0aGFuDQogICBFbmdsaXNoLg0KDQog ICBUaGUgbGltaXRlZCBwZXJtaXNzaW9ucyBncmFudGVkIGFib3ZlIGFyZSBw ZXJwZXR1YWwgYW5kIHdpbGwgbm90IGJlDQogICByZXZva2VkIGJ5IHRoZSBJ bnRlcm5ldCBTb2NpZXR5IG9yIGl0cyBzdWNjZXNzb3JzIG9yIGFzc2lnbmVl cy4NCg0KICAgVGhpcyBkb2N1bWVudCBhbmQgdGhlIGluZm9ybWF0aW9uIGNv bnRhaW5lZCBoZXJlaW4gaXMgcHJvdmlkZWQgb24gYW4NCiAgICJBUyBJUyIg YmFzaXMgYW5kIFRIRSBJTlRFUk5FVCBTT0NJRVRZIEFORCBUSEUgSU5URVJO RVQgRU5HSU5FRVJJTkcNCiAgIFRBU0sgRk9SQ0UgRElTQ0xBSU1TIEFMTCBX QVJSQU5USUVTLCBFWFBSRVNTIE9SIElNUExJRUQsIElOQ0xVRElORw0KICAg QlVUIE5PVCBMSU1JVEVEIFRPIEFOWSBXQVJSQU5UWSBUSEFUIFRIRSBVU0Ug T0YgVEhFIElORk9STUFUSU9ODQoNCg0KDQpSb3Vzc2tvdiAgICAgICAgICAg ICAgIEV4cGlyZXMgU2VwdGVtYmVyIDI5LCAyMDAzICAgICAgICAgICAgICBb UGFnZSAyNl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICBPUEVTIENhbGxv dXQgUHJvdG9jb2wgKE9DUCkgICAgICAgICAgICAgTWFyY2ggMjAwMw0KDQoN CiAgIEhFUkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBBTlkgUklHSFRTIE9SIEFO WSBJTVBMSUVEIFdBUlJBTlRJRVMgT0YNCiAgIE1FUkNIQU5UQUJJTElUWSBP UiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4NCg0KDQpBY2tu b3dsZWRnZW1lbnQNCg0KICAgRnVuZGluZyBmb3IgdGhlIFJGQyBFZGl0b3Ig ZnVuY3Rpb24gaXMgY3VycmVudGx5IHByb3ZpZGVkIGJ5IHRoZQ0KICAgSW50 ZXJuZXQgU29jaWV0eS4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KUm91c3Nrb3YgICAgICAgICAgICAgICBFeHBpcmVzIFNl cHRlbWJlciAyOSwgMjAwMyAgICAgICAgICAgICAgW1BhZ2UgMjddDQoMDQo= --0-466690894-1048872076=:12867-- From owner-ietf-openproxy@mail.imc.org Fri Mar 28 14:23: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 OAA13263 for ; Fri, 28 Mar 2003 14:23:24 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2SIxEC11183 for ietf-openproxy-bks; Fri, 28 Mar 2003 10:59:14 -0800 (PST) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2SIxCg11179 for ; Fri, 28 Mar 2003 10:59:13 -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.8/8.12.8) with ESMTP id h2SIxDN5076097 for ; Fri, 28 Mar 2003 13:59:13 -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.8/8.12.8) with ESMTP id h2SIx7Qu079915 for ; Fri, 28 Mar 2003 13:59:07 -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 NAA21471 for ; Fri, 28 Mar 2003 13:59:06 -0500 (EST) Message-ID: <3E849BA6.1090308@mhof.com> Date: Fri, 28 Mar 2003 13:59:50 -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: Protocol next steps References: <3E7B2E45.5080008@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: > Again, we now need to decide whether the draft should be submitted as > a working group draft. If there are some modifications that must > happen first, please let me know, but let's not argue too much about > specifics until the draft is published (so that we have a clear > reference point). As Alex mentioned, this draft tries to summarize the dicussions we had on the mailing list on the protocol issue. As such, I would assume it reflects the current thinking of the WG reasonably well, and it might be worthwhile to publish this as a WG document. Obviously, the document will change with input from others in the WG and additional authors might get added, but it seems like a good starting point for our WG document. Please spend some time to carefully review the document and provide any feedback you have to the mailing list. Thanks, Markus From owner-ietf-openproxy@mail.imc.org Fri Mar 28 14: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 OAA13602 for ; Fri, 28 Mar 2003 14:31:47 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2SJ9bW12026 for ietf-openproxy-bks; Fri, 28 Mar 2003 11:09:37 -0800 (PST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2SJ9ag12020 for ; Fri, 28 Mar 2003 11:09:36 -0800 (PST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2SJ9Ys00636 for ; Fri, 28 Mar 2003 13:09:38 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 28 Mar 2003 13:09:34 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 28 Mar 2003 11:09:34 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Protocol next steps Date: Fri, 28 Mar 2003 14:09:33 -0500 Message-ID: Thread-Topic: Protocol next steps Thread-Index: AcL1U4lG8Gwn3ArTTNqQAKgiVutPvgACYviw From: To: , X-OriginalArrivalTime: 28 Mar 2003 19:09:34.0096 (UTC) FILETIME=[91759100:01C2F55D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h2SJ9ag12022 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi Alex, Just a small comment re. your OCP draft! Didn't you need to use "qualifier" rather than "quantifier" in the introductory part of the draft! -Srini >-----Original Message----- >From: ext Alex Rousskov [mailto:rousskov@measurement-factory.com] >Sent: Friday, March 28, 2003 12:23 PM >To: OPES Group >Subject: Re: Protocol next steps > > > >Attached is a plain text version of the OCP draft(*). The document is >currently formated as an individual submission. As Markus has >explained above, the working group has to decide how to move forward >with it. > >There are obviously many XXXs, missing and ugly parts in the draft, >but the overall shape of the protocol should be visible. I think it is >time to make this a reference point before we proceed with bindings >and with solving specific protocol issues. The predraft document I >have been working on is no longer good enough because external >reviewers/helpers do not know about it and because it is time to >document consensus. > >Since this draft is not yet a product of the working group, nothing it >currently contains implies consensus. Everything is subject to a >discussion and change. I just documented what we have discussed on the >list and made several subjective decisions where some decisions were >needed to build a coherent protocol spec. > >Again, we now need to decide whether the draft should be submitted as >a working group draft. If there are some modifications that must >happen first, please let me know, but let's not argue too much about >specifics until the draft is published (so that we have a clear >reference point). > >Thank you, > >Alex. From owner-ietf-openproxy@mail.imc.org Fri Mar 28 16:45: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 QAA20721 for ; Fri, 28 Mar 2003 16:45:36 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2SKsWs20381 for ietf-openproxy-bks; Fri, 28 Mar 2003 12:54:32 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2SKsUg20372 for ; Fri, 28 Mar 2003 12:54:31 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h2SKsVnx021161; Fri, 28 Mar 2003 13:54:31 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h2SKsVUd021160; Fri, 28 Mar 2003 13:54:31 -0700 (MST) (envelope-from rousskov) Date: Fri, 28 Mar 2003 13:54:31 -0700 (MST) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: RE: Protocol next steps 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 Fri, 28 Mar 2003 bindignavile.srinivas@nokia.com wrote: > Didn't you need to use "qualifier" rather than "quantifier" in the > introductory part of the draft! Yes, of course. Now fixed. Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Fri Mar 28 19:19: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 TAA26589 for ; Fri, 28 Mar 2003 19:19:42 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2T02C328762 for ietf-openproxy-bks; Fri, 28 Mar 2003 16:02:12 -0800 (PST) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2T02Bg28758 for ; Fri, 28 Mar 2003 16:02:11 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.8/8.12.5) with ESMTP id h2T02Enx025571; Fri, 28 Mar 2003 17:02:14 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.8/8.12.5/Submit) id h2T02EFm025570; Fri, 28 Mar 2003 17:02:14 -0700 (MST) (envelope-from rousskov) Date: Fri, 28 Mar 2003 17:02:14 -0700 (MST) From: Alex Rousskov To: "IETF OPES (E-mail)" Subject: Re: Example of SMTP Fan-Out In-Reply-To: <4A3384433CE2AB46A63468CB207E209D2488E0@zoe.office.snowshore.com> Message-ID: References: <4A3384433CE2AB46A63468CB207E209D2488E0@zoe.office.snowshore.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, 14 Mar 2003, Eric Burger wrote: > Here is a proposal from the FAX work group. It may be relevant to > the question of what SMTP fan-out looks like. In addition, it shows > a protocol that allows the definition of the function (translate) to > be different from the function parameters. > > draft-fax-esmtp-conneg-06.txt What an excellent example! We should definitely keep this draft in mind when building OCP/OPES. It looks like an OPES intermediary should be able to do the kinds of transformations the draft describes. Do you know of any real-world support for the SMTP extensions described in the draft? Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Sat Mar 29 14:25: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 OAA27570 for ; Sat, 29 Mar 2003 14:25:51 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2TJ4Vg09766 for ietf-openproxy-bks; Sat, 29 Mar 2003 11:04:31 -0800 (PST) Received: from smtp.comcast.net (smtp-out.comcast.net [24.153.64.109]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2TJ4Pg09762 for ; Sat, 29 Mar 2003 11:04:25 -0800 (PST) Received: from mhof.com (bgp570928bgs.eatntn01.nj.comcast.net [68.39.0.215]) by mtaout11.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HCI00BENYBA3V@mtaout11.icomcast.net> for ietf-openproxy@imc.org; Sat, 29 Mar 2003 14:04:22 -0500 (EST) Date: Sat, 29 Mar 2003 14:04:21 -0500 From: Markus Hofmann Subject: Need to look at tracing and debuggig To: OPES Group Message-id: <3E85EE35.2090905@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 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Hi, with a first draft on the fundamental design of the OPES callout protocol being distributed, allow me to remind the WG of the importance of the tracing and debugging functionality (also given by the IAB considerations for OPES). We've to take this very seriously! We have to look at tracing and debugging *now* and must not assume that it can easily be tagged onto the protocol at some later point. I would like to see some discussion on how we actually do the tracing and debugging, based on which the (possible) impact on the callout protocol can be determined. Only than, we can advance with the callout protocol! In particular, one might ask - what has to be identified by the tracing capabilities? The OPES processors, the callout servers, the services themselves? All entities/services on the path between content consumer and content provider, or only the those in the direct trust domain? - how are the entities identified, what's the name space? In particular, we need to keep in mind that the IP address of an entitiy might not work out, since it might be a non-routable one (e.g. a callout server behind a NAT/firewall) - how exactly is thetracing information conveyed to the end points? In-band in the application message protocol (e.h. in HTTP extensions?) - what does the endpoint do with the tracing information, i.e. how can it contact possible faulty OPES service providers etc. - can the tracing and debugging feature be enforced? How? - are there implications on the callout protocol with respect to tracing and debugging? If no, are we suree about this? If yes, what do we have to build into the callout protocol to make it work (and possibly to enforce it? These are just a few questions to start with. I'm sure more will pop up and will have to be answered. Would anyone be interested in taking a lead on the discussion of tracing and debugging, possibly by putting together some thoughts in text form (maybe giving a specific example on how tracing/debugging will work)? This is *very* important for advancing our protocol work. Thanks, Markus From owner-ietf-openproxy@mail.imc.org Mon Mar 31 19:45: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 TAA04675 for ; Mon, 31 Mar 2003 19:45: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 h310UMJM021252 for ; Mon, 31 Mar 2003 16:30:22 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h310UMnq021251 for ietf-openproxy-bks; Mon, 31 Mar 2003 16:30:22 -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 h310UKJM021247 for ; Mon, 31 Mar 2003 16:30: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 h310UNvj033306; Mon, 31 Mar 2003 17:30:23 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h310UNvR033305; Mon, 31 Mar 2003 17:30:23 -0700 (MST) (envelope-from rousskov) Date: Mon, 31 Mar 2003 17:30:22 -0700 (MST) From: Alex Rousskov To: OPES Group Subject: Re: Protocol next steps In-Reply-To: <3E849BA6.1090308@mhof.com> Message-ID: References: <3E7B2E45.5080008@mhof.com> <3E849BA6.1090308@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 Fri, 28 Mar 2003, Markus Hofmann wrote: > Please spend some time to carefully review the document and provide > any feedback you have to the mailing list. I would like to propose the following timeline to make sure the draft does not get stuck in its current "unknown state" for long. - If anybody opposes to the publication of the draft as a WG document, please say so by April 4th. - If there are any additions or modifications that MUST be made before publishing the draft as a WG document, please say so before April 4th. - If there are no objections, the draft will be submitted for publication as a WG document when all required additions and modifications are implemented (probably by April 9th). - If there are objections, the draft may still be published as an individual submission, to document the current state (including the objections). If you do not like the above plan, please propose something better. We do need a published/documented reference point to move on faster. Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Mon Mar 31 20:22: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 UAA05791 for ; Mon, 31 Mar 2003 20:22:08 -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 h311BsJM024388 for ; Mon, 31 Mar 2003 17:11:54 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h311BsEh024387 for ietf-openproxy-bks; Mon, 31 Mar 2003 17:11:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from smtp.comcast.net (smtp-out.comcast.net [24.153.64.109]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h311BmJM024365 for ; Mon, 31 Mar 2003 17:11:48 -0800 (PST) Received: from mhof.com (bgp570928bgs.eatntn01.nj.comcast.net [68.39.0.215]) by mtaout11.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HCN00J8I48EQI@mtaout11.icomcast.net> for ietf-openproxy@imc.org; Mon, 31 Mar 2003 20:03:08 -0500 (EST) Date: Mon, 31 Mar 2003 20:02:35 -0500 From: Markus Hofmann Subject: Re: Protocol next steps In-reply-to: To: OPES Group Message-id: <3E88E52B.30404@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: <3E7B2E45.5080008@mhof.com> <3E849BA6.1090308@mhof.com> Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Alex Rousskov wrote: > I would like to propose the following timeline to make sure the draft > does not get stuck in its current "unknown state" for long. > > - If anybody opposes to the publication of the draft > as a WG document, please say so by April 4th. > > - If there are any additions or modifications that > MUST be made before publishing the draft as a > WG document, please say so before April 4th. > > - If there are no objections, the draft will be > submitted for publication as a WG document > when all required additions and modifications > are implemented (probably by April 9th). > > - If there are objections, the draft may > still be published as an individual submission, to > document the current state (including the > objections). > > If you do not like the above plan, please propose something better. We > do need a published/documented reference point to move on faster. Sounds perfectly fine to me, let's execute on this plan! As such, if anyone has objections to publishing this as WG draft, please speak up *before April 4th* on this mailing list. Obviously, the draft will be worked on after publication of the initial release, based on input and with contrinutions from the WG. The deadline is only for objections to declaring this a WG draft! -Markus From owner-ietf-openproxy@mail.imc.org Mon Mar 31 20:22: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 UAA05792 for ; Mon, 31 Mar 2003 20:22:09 -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 h311BtJM024397 for ; Mon, 31 Mar 2003 17:11:55 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h311Btib024396 for ietf-openproxy-bks; Mon, 31 Mar 2003 17:11:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from smtp.comcast.net (smtp-out.comcast.net [24.153.64.109]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h311BmJO024365 for ; Mon, 31 Mar 2003 17:11:54 -0800 (PST) Received: from mhof.com (bgp570928bgs.eatntn01.nj.comcast.net [68.39.0.215]) by mtaout11.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HCN00JLQ4I3KM@mtaout11.icomcast.net> for ietf-openproxy@imc.org; Mon, 31 Mar 2003 20:08:27 -0500 (EST) Date: Mon, 31 Mar 2003 20:08:23 -0500 From: Markus Hofmann Subject: [Fwd: Need to look at tracing and debuggig] To: OPES Group Message-id: <3E88E687.3010004@mhof.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_sdrsBdbLvAN8tvTPel0DfQ)" X-Accept-Language: en-us User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. --Boundary_(ID_sdrsBdbLvAN8tvTPel0DfQ) Content-type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7BIT Folks, please take attached matter *very* seriously - lack of appropriate tracing/debugging will be a roadblock for the protocol! Abbie agreed to summarize the thoughts and issues around tracing and debugging some time next week. So, please, make sure that Abbie will have plenty of material to talk about and post your thoughts to the mailing list (hard to believe that no one has any opinion about what to do here and how...). Thanks, Markus --Boundary_(ID_sdrsBdbLvAN8tvTPel0DfQ) Content-type: message/rfc822; name="Need to look at tracing and debuggig" Return-path: Received: from server3.fastmail.fm (server3.internal [10.202.2.134]) by server2.fastmail.fm (Cyrus v2.1.9) with LMTP; Sat, 29 Mar 2003 14:22:25 -0500 Received: from smtp.us.messagingengine.com (server3.internal [10.202.2.134]) by server3.fastmail.fm (Cyrus v2.1.9) with LMTP; Sat, 29 Mar 2003 14:22:26 -0500 Received: from smtp.us.messagingengine.com (localhost [127.0.0.1]) by fastmail.fm (Postfix) with ESMTP id 6B01C49374 for ; Sat, 29 Mar 2003 14:22:25 -0500 (EST) Received: from 127.0.0.1 ([127.0.0.1] helo=smtp.us.messagingengine.com) by messagingengine.com with SMTP; Sat, 29 Mar 2003 14:22:25 -0500 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by smtp.us.messagingengine.com (Postfix) with ESMTP id F1F8845DE8 for ; Sat, 29 Mar 2003 14:22:24 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2TJ4Vg09766 for ietf-openproxy-bks; Sat, 29 Mar 2003 11:04:31 -0800 (PST) Received: from smtp.comcast.net (smtp-out.comcast.net [24.153.64.109]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2TJ4Pg09762 for ; Sat, 29 Mar 2003 11:04:25 -0800 (PST) Received: from mhof.com (bgp570928bgs.eatntn01.nj.comcast.net [68.39.0.215]) by mtaout11.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HCI00BENYBA3V@mtaout11.icomcast.net> for ietf-openproxy@imc.org; Sat, 29 Mar 2003 14:04:22 -0500 (EST) Date: Sat, 29 Mar 2003 14:04:21 -0500 From: Markus Hofmann Subject: Need to look at tracing and debuggig Sender: owner-ietf-openproxy@mail.imc.org To: OPES Group Message-id: <3E85EE35.2090905@mhof.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed X-Accept-Language: en-us Precedence: bulk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Sieve: CMU Sieve 2.2 X-Mail-from: owner-ietf-openproxy@mail.imc.org X-Delivered-to: X-Spam-score: 0 List-Unsubscribe: List-Archive: List-Id: Content-Transfer-Encoding: 7BIT Hi, with a first draft on the fundamental design of the OPES callout protocol being distributed, allow me to remind the WG of the importance of the tracing and debugging functionality (also given by the IAB considerations for OPES). We've to take this very seriously! We have to look at tracing and debugging *now* and must not assume that it can easily be tagged onto the protocol at some later point. I would like to see some discussion on how we actually do the tracing and debugging, based on which the (possible) impact on the callout protocol can be determined. Only than, we can advance with the callout protocol! In particular, one might ask - what has to be identified by the tracing capabilities? The OPES processors, the callout servers, the services themselves? All entities/services on the path between content consumer and content provider, or only the those in the direct trust domain? - how are the entities identified, what's the name space? In particular, we need to keep in mind that the IP address of an entitiy might not work out, since it might be a non-routable one (e.g. a callout server behind a NAT/firewall) - how exactly is thetracing information conveyed to the end points? In-band in the application message protocol (e.h. in HTTP extensions?) - what does the endpoint do with the tracing information, i.e. how can it contact possible faulty OPES service providers etc. - can the tracing and debugging feature be enforced? How? - are there implications on the callout protocol with respect to tracing and debugging? If no, are we suree about this? If yes, what do we have to build into the callout protocol to make it work (and possibly to enforce it? These are just a few questions to start with. I'm sure more will pop up and will have to be answered. Would anyone be interested in taking a lead on the discussion of tracing and debugging, possibly by putting together some thoughts in text form (maybe giving a specific example on how tracing/debugging will work)? This is *very* important for advancing our protocol work. Thanks, Markus --Boundary_(ID_sdrsBdbLvAN8tvTPel0DfQ)-- From owner-ietf-openproxy@mail.imc.org Mon Mar 31 20:25: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 UAA05915 for ; Mon, 31 Mar 2003 20:25: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 h311GIJM024781 for ; Mon, 31 Mar 2003 17:16:18 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h311GIHs024780 for ietf-openproxy-bks; Mon, 31 Mar 2003 17:16:18 -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 h311GGJM024772 for ; Mon, 31 Mar 2003 17:16:17 -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 h311FeKq008142; Mon, 31 Mar 2003 18:15:40 -0700 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h311GJo24047; Mon, 31 Mar 2003 18:16:19 -0700 Date: Mon, 31 Mar 2003 18:16:19 -0700 Message-Id: <200304010116.h311GJo24047@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: The timeline you suggest is not one I can meet. I suggest extending this to the end of April. Hilarie From owner-ietf-openproxy@mail.imc.org Mon Mar 31 20:43: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 UAA06514 for ; Mon, 31 Mar 2003 20:43: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 h311WSJM025521 for ; Mon, 31 Mar 2003 17:32:28 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h311WSMj025520 for ietf-openproxy-bks; Mon, 31 Mar 2003 17:32:28 -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 h311WQJM025515 for ; Mon, 31 Mar 2003 17:32:26 -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 h311W5oG001542; Mon, 31 Mar 2003 17:32:06 -0800 (PST) Date: Mon, 31 Mar 2003 17:32:05 -0800 From: Marshall Rose To: "The Purple Streak, Hilarie Orman" Cc: rousskov@measurement-factory.com, ietf-openproxy@imc.org Subject: Re: Protocol next steps Message-Id: <20030331173205.397720d3.mrose@dbc.mtview.ca.us> In-Reply-To: <200304010116.h311GJo24047@localhost.localdomain> References: <200304010116.h311GJo24047@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 > 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 From owner-ietf-openproxy@mail.imc.org Mon Mar 31 21:13: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 VAA07120 for ; Mon, 31 Mar 2003 21:13:57 -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 h3122MJM026135 for ; Mon, 31 Mar 2003 18:02:22 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3122MGs026134 for ietf-openproxy-bks; Mon, 31 Mar 2003 18:02:22 -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 h3122IJM026129 for ; Mon, 31 Mar 2003 18:02:18 -0800 (PST) Received: from oskar3 (h00a0c5e5337d.ne.client2.attbi.com[24.218.184.133]) by rwcrmhc52.attbi.com (rwcrmhc52) with SMTP id <2003040102021405200j7brde>; Tue, 1 Apr 2003 02:02:16 +0000 From: "Oskar Batuner" To: "Markus Hofmann" , "OPES Group" Subject: RE: Need to look at tracing and debuggig Date: Mon, 31 Mar 2003 21:02:14 -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: <3E85EE35.2090905@mhof.com> Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Some initial thoughts: 1. Tracing information has to be provided in-band, I see no other way to satisfy current architecture requirements. The OPES architecture states that: "The OPES architecture requires that tracing be feasible on the OPES flow per OPES processor using in-band annotation. " This requirements is essential, it provides participants with the ability to detect OPES in the course of normal interaction. It is necessary to satisfy IAB. Without in-band tracing one should undertake special query to find out if there was something done to the data. This may be not feasible - how do you know where to look without tracing info? 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. 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. 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). 3. > - what has to be identified by the tracing capabilities? The > OPES processors, the callout servers, the services themselves? > All entities/services on the path between content consumer and > content provider, or only the those in the direct trust domain? 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. 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. For security reasons we may require explicit identification included in tracing information and signed. This will prevent man-in-the-middle attacks and help to enforce OPES security and tracing requirements. 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. 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. 4. Tracing information may be used by end-points to discover OPES services and verify and/or set service properties and aslo by another OPES servises in the flow to negotiate/adopt actions (regional ads/weather already inserted, virus checking done and signed by trusted entity, etc.). 5. > - are there implications on the callout protocol with respect to > tracing and debugging? If no, are we sure about this? If yes, > what do we have to build into the callout protocol to make it work > (and possibly to enforce it? As for callout servers - from the OPES flow participant view they do not exist as an independent OPES entity. They may be exposed in-band, but in-band exposure should not identify them as callout servers, in-band they should identify themselves as services. This method (described above) is well suited for service participants that are not visible by network traffic and base application protocol. Of cause there may be situation when callout server is exposed as an explicit reference point for one of the reasons described above, but this type of exposure is only indirectly determined by their role in the message processing, this decision has more to do with the center of authority and policy enforcement point. Callout protocol should be able to support OPES processor actions, as it is the OPES processor who is finally responsible for the policy enforcement. OPES processor should be able to request information required by the OPES security and privacy model. OPES processor may request/negotiate tracing info insertion and should be able to verify the presence and correctness of such information. 6. > - can the tracing and debugging feature be enforced? How? An absolute enforcement is very difficult - unless all application protocol messages are digitally signed. For now any intercepting proxy can do anything it wants - undetected. This is further complicated by the arcitecture requirement that "the presence of an OPES processor in the data request/ response flow SHALL NOT interfere with the operations of non-OPES aware clients and servers". What we can do - we can make OPES an all-or-nothing thing. Nothing means that device that is acting as an OPES processor whould do but that does not expose itself, puts no info in messages, violates all or any OPES rules - in fact does not belong to the OPES realm. Mandatory requirements for tracing mean that OPES flow participants are given certain means of compliance control. Enforcement remains responsibility of the OPES processor. Debugging features may be part of the protocol requirements but I'd not use the word "enforcement" related to debugging. Tracing features that are used to support interaction of independent OPES entities may be subject of interoperability testing. Just some random thoughts. - Oskar > -----Original Message----- > From: owner-ietf-openproxy@mail.imc.org > [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of Markus Hofmann > Sent: Saturday, March 29, 2003 2:04 PM > To: OPES Group > Subject: Need to look at tracing and debuggig > > > > Hi, > > with a first draft on the fundamental design of the OPES callout > protocol being distributed, allow me to remind the WG of the > importance of the tracing and debugging functionality (also given by > the IAB considerations for OPES). We've to take this very seriously! > > We have to look at tracing and debugging *now* and must not assume > that it can easily be tagged onto the protocol at some later point. I > would like to see some discussion on how we actually do the tracing > and debugging, based on which the (possible) impact on the callout > protocol can be determined. Only than, we can advance with the callout > protocol! > > In particular, one might ask > > - what has to be identified by the tracing capabilities? The > OPES processors, the callout servers, the services themselves? > All entities/services on the path between content consumer and > content provider, or only the those in the direct trust domain? > - how are the entities identified, what's the name space? In > particular, we need to keep in mind that the IP address of an > entitiy might not work out, since it might be a non-routable one > (e.g. a callout server behind a NAT/firewall) > - how exactly is thetracing information conveyed to the end points? > In-band in the application message protocol (e.h. in HTTP > extensions?) > - what does the endpoint do with the tracing information, i.e. how > can it contact possible faulty OPES service providers etc. > - can the tracing and debugging feature be enforced? How? > - are there implications on the callout protocol with respect to > tracing and debugging? If no, are we suree about this? If yes, > what do we have to build into the callout protocol to make it work > (and possibly to enforce it? > > These are just a few questions to start with. I'm sure more will pop > up and will have to be answered. > > Would anyone be interested in taking a lead on the discussion of > tracing and debugging, possibly by putting together some thoughts in > text form (maybe giving a specific example on how tracing/debugging > will work)? This is *very* important for advancing our protocol work. > > Thanks, > Markus >