From owner-ietf-openproxy@imc.org Sat Apr 6 03:52:07 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06263 for ; Sat, 6 Apr 2002 03:52:07 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g368q9412789; Sat, 6 Apr 2002 00:52:09 -0800 (PST) Date: Sat, 6 Apr 2002 00:52:09 -0800 (PST) Message-Id: <200204060852.g368q9412789@above.proper.com> To: opes-archive@ietf.org From: Majordomo@imc.org Subject: Welcome to ietf-openproxy Reply-To: Majordomo@imc.org -- Welcome to the ietf-openproxy mailing list! Please save this message for future reference. Thank you. If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe ietf-openproxy or from another account, besides opes-archive@ietf.org: unsubscribe ietf-openproxy opes-archive@ietf.org If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. Here's the general information for the list you've subscribed to, in case you don't already have it: The ietf-openproxy mailing list is for discussion of the issues delineated in http://www.ietf.org/internet-drafts/draft-tomlinson-epsfw-00.txt. That document introduces the problem and solution requirements for a standardized, open and extensible service environment on caching proxies which enables them to provide general services that mediate, modify, and monitor object requests and responses. To see what has gone on before you subscribed, please see the mailing list archive at http://www.imc.org/ietf-openproxy/ To unsubscribe from the ietf-openproxy mailing list, send a message to: ietf-openproxy-request@imc.org with the message: unsubscribe If you need to contact a human about this mailing list, please send a message to: phoffman@imc.org From Majordomo-Owner@imc.org Sat Apr 6 04:38:47 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06267 for ; Sat, 6 Apr 2002 03:52:07 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g368q9c12788; Sat, 6 Apr 2002 00:52:09 -0800 (PST) Date: Sat, 6 Apr 2002 00:52:09 -0800 (PST) Message-Id: <200204060852.g368q9c12788@above.proper.com> To: opes-archive@ietf.org From: Majordomo@imc.org Subject: Majordomo results: Subscribe archive address Reply-To: Majordomo@imc.org -- >>>> >>>> subscribe Succeeded (to list ietf-openproxy). >>>> From owner-ietf-openproxy@mail.imc.org Wed Apr 10 13:37:32 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26226 for ; Wed, 10 Apr 2002 13:37:31 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3AGuGB07302 for ietf-openproxy-bks; Wed, 10 Apr 2002 09:56:16 -0700 (PDT) Received: from flyingfox.snowshore.com (flyingfox.snowshore.com [216.57.133.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3AGuEm07291 for ; Wed, 10 Apr 2002 09:56:14 -0700 (PDT) Received: from eburger (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with SMTP id g3AGuGB02915 for ; Wed, 10 Apr 2002 12:56:16 -0400 (EDT) Reply-To: From: "Eric Burger" To: "IETF OPES" Subject: "IP layer addressing" (clarification on opes-model-01) Date: Wed, 10 Apr 2002 12:56:13 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Section 5.1.2 cryptically states that OPES intermediaries cannot be transparent. I would propose we explain the requirement, with the existing statement as the way of satisfying the requirement. How about something like: It is a goal to not require the OPES client to explicitly request the services of an OPES Intermediary. That is, most the operation of OPES Intermediaries are transparent to the OPES client. Even though, under normal use, the operation is transparent, the presence of OPES Intermediaries MUST NOT be hidden from the user or the client (i.e., a content consumer). For example, the OPES client may request an object from a given URI. The URI may resolve to an OPES Intermediary, rather than the content provider. Both the OPES client and content provider must be aware of the OPES Intermediary. In this regard, the client and the content provider MUST be able to explicitly address the OPES Intermediaries at the IP layer. Conversely, an OPES Intermediary MUST NOT share or proxy for the IP address of an OPES client or content provider. From owner-ietf-openproxy@mail.imc.org Wed Apr 10 13:37:33 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26225 for ; Wed, 10 Apr 2002 13:37:31 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g3AGuEH07289 for ietf-openproxy-bks; Wed, 10 Apr 2002 09:56:14 -0700 (PDT) Received: from flyingfox.snowshore.com (flyingfox.snowshore.com [216.57.133.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3AGuDm07284 for ; Wed, 10 Apr 2002 09:56:13 -0700 (PDT) Received: from eburger (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with SMTP id g3AGuEB02909 for ; Wed, 10 Apr 2002 12:56:14 -0400 (EDT) Reply-To: From: "Eric Burger" To: "IETF OPES" Subject: Comment on callout-requirements-00 Date: Wed, 10 Apr 2002 12:56:11 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Section 3.2.4, 4th (last) paragraph: "SHOULD" does not make sense here. How about, "If only one approach is supported by a callout protocol, the penalty for not using the optimal approach MUST be considered." From owner-ietf-openproxy@mail.imc.org Wed Apr 10 13:38:07 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26252 for ; Wed, 10 Apr 2002 13:37:55 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g3AGuHS07305 for ietf-openproxy-bks; Wed, 10 Apr 2002 09:56:17 -0700 (PDT) Received: from flyingfox.snowshore.com (flyingfox.snowshore.com [216.57.133.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3AGuFm07294 for ; Wed, 10 Apr 2002 09:56:15 -0700 (PDT) Received: from eburger (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with SMTP id g3AGuGB02921 for ; Wed, 10 Apr 2002 12:56:16 -0400 (EDT) Reply-To: From: "Eric Burger" To: "IETF OPES" Subject: Direct Communication between Client and Callout Server (comment on opes-spcs-01) Date: Wed, 10 Apr 2002 12:56:13 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit The OPES Engine redirecting the client to a call-out server is more than an artifact, it is a requirement. For real-time or high-density, low-latency, real-time transcoding services (e.g., transcoding a http chunked fetch of an mp3 to RTP delivery of GSM), it is incredibly inefficient and unrealistic to route all packets through the OPES Engine. One model for this sort of interaction is the IMAP CHANNEL mechanism. See draft-nerenberg-imap-channel-01.txt . The "connection" is already in Figure 1, the UPIF flow. However, UPIF is for something entirely different. I would propose a dotted connection between the User Agent and the other Call-out server, with text along the following lines: "The OPES Engine may redirect the User Agent to retrieve content directly from a call-out server. It can do this to satisfy requests which are more efficiently delivered via a direct connection. [we can insert the example I gave above]" P.S., should "User Agent" be "OPES Client"? From owner-ietf-openproxy@mail.imc.org Wed Apr 10 14:24:25 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26253 for ; Wed, 10 Apr 2002 13:37:55 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g3AGuH307306 for ietf-openproxy-bks; Wed, 10 Apr 2002 09:56:17 -0700 (PDT) Received: from flyingfox.snowshore.com (flyingfox.snowshore.com [216.57.133.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3AGuFm07293 for ; Wed, 10 Apr 2002 09:56:15 -0700 (PDT) Received: from eburger (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with SMTP id g3AGuGB02918 for ; Wed, 10 Apr 2002 12:56:16 -0400 (EDT) Reply-To: From: "Eric Burger" To: "IETF OPES" Subject: Content Selection (comment on opes-spcs-01) Date: Wed, 10 Apr 2002 12:56:13 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit With reference to Section 3.3, I don't think it is possible to not find an appropriate content variant. The reason is that, by definition, either the OPES Intermediary will be performing translation of the source content to a format appropriate for the OPES client or there is no way to translate the content. In the former case, the OPES Intermediary will choose a variant, translate it, and deliver it to the client. The latter case is identical to the case where there is no OPES Intermediary. Namely, the client will see something like 406 (Not Acceptable). Am I missing something here? From owner-ietf-openproxy@mail.imc.org Thu Apr 11 17:01:42 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14865 for ; Thu, 11 Apr 2002 17:01:41 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g3BKLj020461 for ietf-openproxy-bks; Thu, 11 Apr 2002 13:21:45 -0700 (PDT) Received: from mail.mnot.net (adsl-64-170-196-242.dsl.snfc21.pacbell.net [64.170.196.242]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3BKLhm20457 for ; Thu, 11 Apr 2002 13:21:43 -0700 (PDT) Received: from 1-130.mnot.net (1-130.mnot.net [192.168.1.130]) by mail.mnot.net (Postfix) with ESMTP id F13F5976D; Thu, 11 Apr 2002 13:21:45 -0700 (PDT) Date: Thu, 11 Apr 2002 13:21:45 -0700 Subject: no-transform & Warning Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: LMM@acm.org To: ietf-openproxy@imc.org From: Mark Nottingham Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.481) Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Just curious, Is anyone aware of an OPES, ICAP or other transcoding implementation that: a) honors Cache-Control: no-transform b) honors Warning: 214 Transformation applied in either requests or responses? -- Mark Nottingham http://www.mnot.net/ From owner-ietf-openproxy@mail.imc.org Thu Apr 11 17:39:22 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16028 for ; Thu, 11 Apr 2002 17:39:22 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3BKbqD20751 for ietf-openproxy-bks; Thu, 11 Apr 2002 13:37:52 -0700 (PDT) Received: from flyingfox.snowshore.com (flyingfox.snowshore.com [216.57.133.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3BKbpm20747 for ; Thu, 11 Apr 2002 13:37:51 -0700 (PDT) Received: from eburger (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with SMTP id g3BKbrB24477 for ; Thu, 11 Apr 2002 16:37:53 -0400 (EDT) Reply-To: From: "Eric Burger" To: "IETF OPES" Subject: Another way of looking at Network Topology (comment on opes-fsp-01) Date: Thu, 11 Apr 2002 16:37:49 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit In Section 3, bullet 3, the question is asked if the Network Topology is really a special case of Device Information. I would offer that what bullet 3 is trying to capture is the view of the provider from the client's perspective. That is, bullet 2 refers to how the provider "sees" the device, while bullet 3 refers to how the client "sees" the provider. It may look like these two issues are the same thing. However, I might keep the separate classification. The reason is that my device characteristics never change (well, for a given device, it does not change). However, my connectivity may change dramatically. For example, I could have a 48kb/s wireless channel one minute and later it drops back to 14.4kb/s. From owner-ietf-openproxy@mail.imc.org Thu Apr 11 17:53:29 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16350 for ; Thu, 11 Apr 2002 17:53:28 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3BKrct21478 for ietf-openproxy-bks; Thu, 11 Apr 2002 13:53:38 -0700 (PDT) Received: from flyingfox.snowshore.com (flyingfox.snowshore.com [216.57.133.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3BKrbm21472 for ; Thu, 11 Apr 2002 13:53:37 -0700 (PDT) Received: from eburger (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with SMTP id g3BKrdB24694 for ; Thu, 11 Apr 2002 16:53:39 -0400 (EDT) Reply-To: From: "Eric Burger" To: "IETF OPES" Subject: Where Personalization occurs and Comment on table in opes-fsp-01 Date: Thu, 11 Apr 2002 16:53:35 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit What are the axes of the diagram on page 11? There is no definition of Basic, Moderate, Advanced, or Total. "The precise level of service personalization ... depends on where in the network these personalization functions are deployed ..." Does it really matter? There may be an impact on security (where profiles can and cannot go). However, saying things are different may have an impact on protocol. Is it worth having multiple OPES protocols, depending on where the OPES server is? How would the network elements know where they are and whom they are talking to? I would propose that everything should be transparent. From owner-ietf-openproxy@mail.imc.org Thu Apr 11 22:06:03 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00479 for ; Thu, 11 Apr 2002 22:06:03 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g3C1NCE00681 for ietf-openproxy-bks; Thu, 11 Apr 2002 18:23:12 -0700 (PDT) Received: from mail.mnot.net (adsl-64-170-196-242.dsl.snfc21.pacbell.net [64.170.196.242]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3C1NAm00676 for ; Thu, 11 Apr 2002 18:23:10 -0700 (PDT) Received: from 1-130.mnot.net (1-130.mnot.net [192.168.1.130]) by mail.mnot.net (Postfix) with ESMTP id 6ED6D976D; Thu, 11 Apr 2002 18:23:13 -0700 (PDT) Date: Thu, 11 Apr 2002 18:23:12 -0700 Subject: Re: A proposal for delivery context Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: "PCI" , "IETF-OPES" To: From: Mark Nottingham In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit This looks very interesting, and a good direction to head in. I'd like to see more! On Thursday, March 28, 2002, at 12:16 AM, Ng Chan Wah wrote: > Hi, > > Since the OPES charter was decided that the personalization work is out > of > scope, personalization call-out server must now find a home. Paul is > working towards a BOF for Yokohama. In tandem to that, I would like to > propose a solution for the personalization call-out server and OPES (as > it > is now) intermediary to co-exist gracefully. > > The solution I propose is through the use of a sub-system known as the > "Delivery Context" sub-system. The idea here is to have the IRML engine > understands whatever personalization parameters that the PCS requires > of the > OPES. > > I hereby attach an initial draft of the proposal for people on the OPES > and > PCS mailing list to scrutinize. Please feel free to comment, and > contribute > suggestions. If the group deems there is enough substance to continue > this > work, I will also like to invite volunteers to co-author the draft. > > Thanks, > Chan Wah Ng. > > > > -- Mark Nottingham http://www.mnot.net/ From owner-ietf-openproxy@mail.imc.org Fri Apr 12 00:54:54 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20767 for ; Fri, 12 Apr 2002 00:54:53 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3C4EvV05251 for ietf-openproxy-bks; Thu, 11 Apr 2002 21:14:57 -0700 (PDT) Received: from zsc3s004.us.nortel.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3C4Eum05246 for ; Thu, 11 Apr 2002 21:14:56 -0700 (PDT) Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zsc3s004.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3C4Emn23230; Thu, 11 Apr 2002 21:14:48 -0700 (PDT) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2JXM9BGA>; Thu, 11 Apr 2002 21:14:41 -0700 Message-ID: <7B802811BE77D51189910002A55CFD2C01DFE590@zsc3c032.us.nortel.com> From: "Reinaldo Penno" To: eburger@snowshore.com, IETF OPES Subject: RE: Where Personalization occurs and Comment on table in opes-fsp -01 Date: Thu, 11 Apr 2002 21:14:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E1D8.97C10C22" 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_01C1E1D8.97C10C22 Content-Type: text/plain; charset="iso-8859-1" Hello Eric, this table is a very alpha version of our talks with some services providers. Some them said that in order to provide what they called "full personalization" you would need to know the 4 parameters on tha table. Based on this I drawed this table. There is no definition of exactly what basic, moderate, etc is. The easiest one is total, which, one way or the other, you know the 4 parameters. As for your second question, our thoughts when writing this is that the closest you get to the edge os the network, the better would be your, for instance, bandwidth, RTT and other estimates that could be fed into some eprsonalization system. regards, Reinaldo >-----Original Message----- >From: Eric Burger [mailto:eburger@snowshore.com] >Sent: Thursday, April 11, 2002 1:54 PM >To: IETF OPES >Subject: Where Personalization occurs and Comment on table in >opes-fsp-01 > > > >What are the axes of the diagram on page 11? There is no definition of >Basic, Moderate, Advanced, or Total. > > > >"The precise level of service personalization ... depends on >where in the >network these personalization functions are deployed ..." > >Does it really matter? There may be an impact on security >(where profiles >can and cannot go). However, saying things are different may >have an impact >on protocol. Is it worth having multiple OPES protocols, >depending on where >the OPES server is? How would the network elements know where >they are and >whom they are talking to? > >I would propose that everything should be transparent. > > ------_=_NextPart_001_01C1E1D8.97C10C22 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Where Personalization occurs and Comment on table in = opes-fsp-01

Hello Eric,

this table is a very alpha version of our talks with = some services providers. Some them said that in order to provide what = they called "full personalization" you would need to know the = 4 parameters on tha table.

Based on this I drawed this table. There is no = definition of exactly what basic, moderate, etc is. The easiest one is = total, which, one way or the other, you know the 4 = parameters.

As for your second question, our thoughts when = writing this is that the closest you get to the edge os the network, = the better would be your, for instance, bandwidth, RTT and other = estimates that could be fed into some eprsonalization = system.

regards,

Reinaldo

>-----Original Message-----
>From: Eric Burger [mailto:eburger@snowshore.com]<= /FONT>
>Sent: Thursday, April 11, 2002 1:54 PM
>To: IETF OPES
>Subject: Where Personalization occurs and = Comment on table in
>opes-fsp-01
>
>
>
>What are the axes of the diagram on page = 11?  There is no definition of
>Basic, Moderate, Advanced, or Total.
>
>
>
>"The precise level of service = personalization ... depends on
>where in the
>network these personalization functions are = deployed ..."
>
>Does it really matter?  There may be an = impact on security
>(where profiles
>can and cannot go).  However, saying things = are different may
>have an impact
>on protocol.  Is it worth having multiple = OPES protocols,
>depending on where
>the OPES server is?  How would the network = elements know where
>they are and
>whom they are talking to?
>
>I would propose that everything should be = transparent.
>
>

------_=_NextPart_001_01C1E1D8.97C10C22-- From owner-ietf-openproxy@mail.imc.org Fri Apr 12 01:05:58 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21965 for ; Fri, 12 Apr 2002 01:05:57 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3C4SxK05494 for ietf-openproxy-bks; Thu, 11 Apr 2002 21:28:59 -0700 (PDT) Received: from zsc3s004.us.nortel.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3C4Sum05487 for ; Thu, 11 Apr 2002 21:28:56 -0700 (PDT) Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zsc3s004.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3C4Snn23330; Thu, 11 Apr 2002 21:28:49 -0700 (PDT) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2JXM9BGT>; Thu, 11 Apr 2002 21:28:42 -0700 Message-ID: <7B802811BE77D51189910002A55CFD2C01DFE593@zsc3c032.us.nortel.com> From: "Reinaldo Penno" To: eburger@snowshore.com, IETF OPES Subject: RE: Direct Communication between Client and Callout Server (comme nt on opes-spcs-01) Date: Thu, 11 Apr 2002 21:28:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E1DA.8B12C8CE" 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_01C1E1DA.8B12C8CE Content-Type: text/plain; charset="iso-8859-1" >-----Original Message----- >From: Eric Burger [mailto:eburger@snowshore.com] >Sent: Wednesday, April 10, 2002 9:56 AM >To: IETF OPES >Subject: Direct Communication between Client and Callout >Server (comment >on opes-spcs-01) > > > >The OPES Engine redirecting the client to a call-out server is >more than an >artifact, it is a requirement. > >For real-time or high-density, low-latency, real-time >transcoding services >(e.g., transcoding a http chunked fetch of an mp3 to RTP >delivery of GSM), >it is incredibly inefficient and unrealistic to route all >packets through >the OPES Engine. yes, you are right. There was some discussion on this list some weeks ago about the reasons for using a callout server. WE found out that scalability, flexibility and segmentation covered up pretty much all the reasons. > >One model for this sort of interaction is the IMAP CHANNEL >mechanism. See >draft-nerenberg-imap-channel-01.txt . > >The "connection" is already in Figure 1, the UPIF flow. >However, UPIF is >for something entirely different. I would propose a dotted connection >between the User Agent and the other Call-out server, with >text along the >following lines: > >"The OPES Engine may redirect the User Agent to retrieve >content directly >from a call-out server. It can do this to satisfy requests >which are more >efficiently delivered via a direct connection. [we can insert >the example I >gave above]" I will add your suggestion. > > > >P.S., should "User Agent" be "OPES Client"? > > ------_=_NextPart_001_01C1E1DA.8B12C8CE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Direct Communication between Client and Callout Server = (comment on opes-spcs-01)

>-----Original Message-----
>From: Eric Burger [mailto:eburger@snowshore.com]<= /FONT>
>Sent: Wednesday, April 10, 2002 9:56 AM
>To: IETF OPES
>Subject: Direct Communication between Client and = Callout
>Server (comment
>on opes-spcs-01)
>
>
>
>The OPES Engine redirecting the client to a = call-out server is
>more than an
>artifact, it is a requirement.
>
>For real-time or high-density, low-latency, = real-time
>transcoding services
>(e.g., transcoding a http chunked fetch of an = mp3 to RTP
>delivery of GSM),
>it is incredibly inefficient and unrealistic to = route all
>packets through
>the OPES Engine.

yes, you are right. There was some discussion on this = list some weeks ago about the reasons for using a callout server. WE = found out that scalability, flexibility and segmentation covered up = pretty much all the reasons.

>
>One model for this sort of interaction is the = IMAP CHANNEL
>mechanism.  See
>draft-nerenberg-imap-channel-01.txt .
>
>The "connection" is already in Figure = 1, the UPIF flow. 
>However, UPIF is
>for something entirely different.  I would = propose a dotted connection
>between the User Agent and the other Call-out = server, with
>text along the
>following lines:
>
>"The OPES Engine may redirect the User = Agent to retrieve
>content directly
>from a call-out server.  It can do this to = satisfy requests
>which are more
>efficiently delivered via a direct = connection.  [we can insert
>the example I
>gave above]"

I will add your suggestion.

>
>
>
>P.S., should "User Agent" be = "OPES Client"?
>
>

------_=_NextPart_001_01C1E1DA.8B12C8CE-- From owner-ietf-openproxy@mail.imc.org Mon Apr 15 17:33:49 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07243 for ; Mon, 15 Apr 2002 17:33:49 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3FKfVH03634 for ietf-openproxy-bks; Mon, 15 Apr 2002 13:41:31 -0700 (PDT) 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.3) with SMTP id g3FKfTm03629 for ; Mon, 15 Apr 2002 13:41:30 -0700 (PDT) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Mon Apr 15 16:41:46 EDT 2002 Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g3FKfGo40397; Mon, 15 Apr 2002 16:41:16 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id QAA26524; Mon, 15 Apr 2002 16:41:09 -0400 (EDT) Message-ID: <3CBB3AE5.8010204@mhof.com> Date: Mon, 15 Apr 2002 16:41:09 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Nottingham CC: ietf-openproxy@imc.org, LMM@acm.org Subject: Re: no-transform & Warning References: 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 Mark, would you consider this part of an OPES/iCAP protocol implementation or rather the responsibility of the rule author (i.e. the rule author has to specify the appropriate rules, such as "if 'Cache-Control: no-transform', do NOT do...") or maybe even of the application service developer. I would expect that most implementations let you specify such rules, thus allowing the system to honor such controls. -Markus Mark Nottingham wrote: > > Just curious, > > Is anyone aware of an OPES, ICAP or other transcoding implementation that: > > a) honors Cache-Control: no-transform > b) honors Warning: 214 Transformation applied > > in either requests or responses From owner-ietf-openproxy@mail.imc.org Mon Apr 15 18:03:30 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07672 for ; Mon, 15 Apr 2002 18:03:29 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3FLFwR04434 for ietf-openproxy-bks; Mon, 15 Apr 2002 14:15:58 -0700 (PDT) Received: from mail.mnot.net (adsl-64-170-196-242.dsl.snfc21.pacbell.net [64.170.196.242]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3FLFvm04430 for ; Mon, 15 Apr 2002 14:15:57 -0700 (PDT) Received: from 1-130.mnot.net (1-130.mnot.net [192.168.1.130]) by mail.mnot.net (Postfix) with ESMTP id 1943C976D; Mon, 15 Apr 2002 14:16:00 -0700 (PDT) Date: Mon, 15 Apr 2002 14:15:59 -0700 Subject: Re: no-transform & Warning Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: ietf-openproxy@imc.org, LMM@acm.org To: Markus Hofmann From: Mark Nottingham In-Reply-To: <3CBB3AE5.8010204@mhof.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit These mechanisms are required in order to be HTTP-compliant; therefore, I'd say they should be part of the ICAP server's HTTP stack. On Monday, April 15, 2002, at 01:41 PM, Markus Hofmann wrote: > Mark, > > would you consider this part of an OPES/iCAP protocol implementation or > rather the responsibility of the rule author (i.e. the rule author has > to specify the appropriate rules, such as "if 'Cache-Control: > no-transform', do NOT do...") or maybe even of the application service > developer. I would expect that most implementations let you specify > such rules, thus allowing the system to honor such controls. > > -Markus > > > Mark Nottingham wrote: >> Just curious, >> Is anyone aware of an OPES, ICAP or other transcoding implementation >> that: >> a) honors Cache-Control: no-transform >> b) honors Warning: 214 Transformation applied >> in either requests or responses > > -- Mark Nottingham http://www.mnot.net/ From owner-ietf-openproxy@mail.imc.org Tue Apr 16 11:27:36 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08139 for ; Tue, 16 Apr 2002 11:27:35 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3GEhYO28554 for ietf-openproxy-bks; Tue, 16 Apr 2002 07:43:34 -0700 (PDT) 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.3) with SMTP id g3GEhWm28545 for ; Tue, 16 Apr 2002 07:43:32 -0700 (PDT) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Tue Apr 16 10:43:34 EDT 2002 Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g3GEh4k27929; Tue, 16 Apr 2002 10:43:04 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA17532; Tue, 16 Apr 2002 10:43:03 -0400 (EDT) Message-ID: <3CBC3877.9090903@mhof.com> Date: Tue, 16 Apr 2002 10:43:03 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Nottingham CC: ietf-openproxy@imc.org, LMM@acm.org Subject: Re: no-transform & Warning References: 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 Mark Nottingham wrote: > These mechanisms are required in order to be HTTP-compliant; therefore, > I'd say they should be part of the ICAP server's HTTP stack. Hm, this assumes that the payload (i.e. the content-path protocol) is NOT transparent to the OPES/Callout protocol, i.e. the OPES/Callout protocol needs to have knowledge about the sematics of the encapsulated application protocol (HTTP in this case). Do we want to make this assumption? Comments? -Markus From owner-ietf-openproxy@mail.imc.org Tue Apr 16 13:04:50 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20079 for ; Tue, 16 Apr 2002 13:04:50 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g3GGEoj04326 for ietf-openproxy-bks; Tue, 16 Apr 2002 09:14:50 -0700 (PDT) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3GGEmm04322 for ; Tue, 16 Apr 2002 09:14:48 -0700 (PDT) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.39 2002/04/15 17:47:23 root Exp $) with ESMTP id g3GGEAh07832 for ; Tue, 16 Apr 2002 16:14:10 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.16 2002/04/15 17:47:00 root Exp $) with SMTP id g3GGDLt07892 for ; Tue, 16 Apr 2002 16:13:21 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002041609185118761 ; Tue, 16 Apr 2002 09:18:51 -0700 Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id <2LKB6V1Q>; Tue, 16 Apr 2002 09:14:48 -0700 Message-ID: From: "Yang, Lily L" To: "'Markus Hofmann'" , Mark Nottingham Cc: ietf-openproxy@imc.org, LMM@acm.org Subject: RE: no-transform & Warning Date: Tue, 16 Apr 2002 09:14:43 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > -----Original Message----- > From: Markus Hofmann [mailto:markus@mhof.com] > Sent: Tuesday, April 16, 2002 7:43 AM > To: Mark Nottingham > Cc: ietf-openproxy@imc.org; LMM@acm.org > Subject: Re: no-transform & Warning > > > > Mark Nottingham wrote: > > > These mechanisms are required in order to be > HTTP-compliant; therefore, > > I'd say they should be part of the ICAP server's HTTP stack. > > Hm, this assumes that the payload (i.e. the content-path protocol) is > NOT transparent to the OPES/Callout protocol, i.e. the OPES/Callout > protocol needs to have knowledge about the sematics of the > encapsulated application protocol (HTTP in this case). I thought this has been the case. The callout protocol is going to transport and transform the encapsulated application protocol data stream, and hence has to understand the interaction with that application protocol. > > Do we want to make this assumption? Comments? > > -Markus > From owner-ietf-openproxy@mail.imc.org Tue Apr 16 14:22:49 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29285 for ; Tue, 16 Apr 2002 14:22:49 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3GHYTx10908 for ietf-openproxy-bks; Tue, 16 Apr 2002 10:34:29 -0700 (PDT) Received: from zsc3s004.us.nortel.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3GHYSm10903 for ; Tue, 16 Apr 2002 10:34:28 -0700 (PDT) Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zsc3s004.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3GHYI720962; Tue, 16 Apr 2002 10:34:18 -0700 (PDT) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2JXM01JY>; Tue, 16 Apr 2002 10:34:09 -0700 Message-ID: <7B802811BE77D51189910002A55CFD2C01EFC852@zsc3c032.us.nortel.com> From: "Reinaldo Penno" To: "Yang, Lily L" , "'Markus Hofmann'" , Mark Nottingham Cc: ietf-openproxy@imc.org, LMM@acm.org Subject: RE: no-transform & Warning Date: Tue, 16 Apr 2002 10:34:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E56C.E92CD946" 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_01C1E56C.E92CD946 Content-Type: text/plain; charset="iso-8859-1" You need to understand HTTP 1.1. Sometimes you just want to send the host: header (request URL filtering). Sometimes the entire payload. Sometimes you want (for web mail virus scanning), send only part of a payload. regards, Reinaldo >-----Original Message----- >From: Yang, Lily L [mailto:lily.l.yang@intel.com] >Sent: Tuesday, April 16, 2002 9:15 AM >To: 'Markus Hofmann'; Mark Nottingham >Cc: ietf-openproxy@imc.org; LMM@acm.org >Subject: RE: no-transform & Warning > > > > > >> -----Original Message----- >> From: Markus Hofmann [mailto:markus@mhof.com] >> Sent: Tuesday, April 16, 2002 7:43 AM >> To: Mark Nottingham >> Cc: ietf-openproxy@imc.org; LMM@acm.org >> Subject: Re: no-transform & Warning >> >> >> >> Mark Nottingham wrote: >> >> > These mechanisms are required in order to be >> HTTP-compliant; therefore, >> > I'd say they should be part of the ICAP server's HTTP stack. >> >> Hm, this assumes that the payload (i.e. the content-path >protocol) is >> NOT transparent to the OPES/Callout protocol, i.e. the OPES/Callout >> protocol needs to have knowledge about the sematics of the >> encapsulated application protocol (HTTP in this case). > >I thought this has been the case. The callout protocol is >going to transport >and transform the encapsulated application protocol data >stream, and hence >has to understand the interaction with that application protocol. > >> >> Do we want to make this assumption? Comments? >> >> -Markus >> > ------_=_NextPart_001_01C1E56C.E92CD946 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: no-transform & Warning

You need to understand HTTP 1.1. Sometimes you just = want to send the host: header (request URL filtering). Sometimes the = entire payload. Sometimes you want (for web mail virus scanning), send = only part of a payload.

regards,

Reinaldo

>-----Original Message-----
>From: Yang, Lily L [mailto:lily.l.yang@intel.com]<= /FONT>
>Sent: Tuesday, April 16, 2002 9:15 AM
>To: 'Markus Hofmann'; Mark Nottingham
>Cc: ietf-openproxy@imc.org; LMM@acm.org
>Subject: RE: no-transform & Warning
>
>
>
>
>
>> -----Original Message-----
>> From: Markus Hofmann [mailto:markus@mhof.com]
>> Sent: Tuesday, April 16, 2002 7:43 = AM
>> To: Mark Nottingham
>> Cc: ietf-openproxy@imc.org; = LMM@acm.org
>> Subject: Re: no-transform & = Warning
>>
>>
>>
>> Mark Nottingham wrote:
>>
>> > These mechanisms are required in order = to be
>> HTTP-compliant; therefore,
>> > I'd say they should be part of the = ICAP server's HTTP stack.
>>
>> Hm, this assumes that the payload (i.e. the = content-path
>protocol) is
>> NOT transparent to the OPES/Callout = protocol, i.e. the OPES/Callout
>> protocol needs to have knowledge about the = sematics of the
>> encapsulated application protocol (HTTP in = this case).
>
>I thought this has been the case. The callout = protocol is
>going to transport
>and transform the encapsulated application = protocol data
>stream, and hence
>has to understand the interaction with that = application protocol.
>
>>
>> Do we want to make this assumption? = Comments?
>>
>> -Markus
>>
>

------_=_NextPart_001_01C1E56C.E92CD946-- From owner-ietf-openproxy@mail.imc.org Tue Apr 16 14:37:31 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00846 for ; Tue, 16 Apr 2002 14:37:30 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g3GHnXQ11488 for ietf-openproxy-bks; Tue, 16 Apr 2002 10:49:33 -0700 (PDT) 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.3) with SMTP id g3GHnVm11484 for ; Tue, 16 Apr 2002 10:49:31 -0700 (PDT) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Tue Apr 16 13:49:57 EDT 2002 Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g3GHnSk47058; Tue, 16 Apr 2002 13:49:28 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id NAA26638; Tue, 16 Apr 2002 13:49:27 -0400 (EDT) Message-ID: <3CBC6427.5090602@mhof.com> Date: Tue, 16 Apr 2002 13:49:27 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Yang, Lily L" CC: Mark Nottingham , ietf-openproxy@imc.org, LMM@acm.org Subject: Re: no-transform & Warning References: 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 Yang, Lily L wrote: > I thought this has been the case. The callout protocol is going to transport > and transform the encapsulated application protocol data stream, and hence > has to understand the interaction with that application protocol. The callout protocol does transport the application messages, but the callout protocol itself does *not* transform them. As such, it is not required to understand the application protocol - indeed, protocol layering rather suggests that the (underlying) callout protocol does not make any assumptions about the (above) application protocol (just as it is assumed that TCP does not understand the higher-layer payload it transports). There might be good reasons for us to consider characteristics of the encapsulated application protocol, I'm just wondering where to draw the line... -Markus From owner-ietf-openproxy@mail.imc.org Tue Apr 16 14:39:25 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01124 for ; Tue, 16 Apr 2002 14:39:24 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3GHpXG11559 for ietf-openproxy-bks; Tue, 16 Apr 2002 10:51:33 -0700 (PDT) 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.3) with SMTP id g3GHpVm11555 for ; Tue, 16 Apr 2002 10:51:31 -0700 (PDT) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Tue Apr 16 13:51:44 EDT 2002 Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g3GHpEk47186; Tue, 16 Apr 2002 13:51:14 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id NAA26729; Tue, 16 Apr 2002 13:51:13 -0400 (EDT) Message-ID: <3CBC6491.5080505@mhof.com> Date: Tue, 16 Apr 2002 13:51:13 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Reinaldo Penno CC: "Yang, Lily L" , Mark Nottingham , ietf-openproxy@imc.org, LMM@acm.org Subject: Re: no-transform & Warning References: <7B802811BE77D51189910002A55CFD2C01EFC852@zsc3c032.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: > You need to understand HTTP 1.1. Sometimes you just want to send the > host: header (request URL filtering). Sometimes the entire payload. > Sometimes you want (for web mail virus scanning), send only part of a > payload. The question is whether the callout protocol itself needs "to understand HTTP", or whether the application logic can be build around a generic callout protocol. -Markus From owner-ietf-openproxy@mail.imc.org Tue Apr 16 14:57:33 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03706 for ; Tue, 16 Apr 2002 14:57:32 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3GI8oG12225 for ietf-openproxy-bks; Tue, 16 Apr 2002 11:08:50 -0700 (PDT) Received: from zsc3s004.us.nortel.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3GI8mm12221 for ; Tue, 16 Apr 2002 11:08:49 -0700 (PDT) Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zsc3s004.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3GI8c723417; Tue, 16 Apr 2002 11:08:38 -0700 (PDT) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2JXM0F18>; Tue, 16 Apr 2002 11:08:29 -0700 Message-ID: <7B802811BE77D51189910002A55CFD2C01EFC8D1@zsc3c032.us.nortel.com> From: "Reinaldo Penno" To: Markus Hofmann Cc: "Yang, Lily L" , Mark Nottingham , ietf-openproxy@imc.org, LMM@acm.org Subject: RE: no-transform & Warning Date: Tue, 16 Apr 2002 11:08:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E571.B7952B9A" 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_01C1E571.B7952B9A Content-Type: text/plain; charset="iso-8859-1" sorry.. so the callout protocol should be application agnostic. Otherwise we will need patch it up for every new protocol (RTSP, SMTP and others) or its updates. And yes, I believe we can make it application agnostic. regards, Reinaldo >-----Original Message----- >From: Markus Hofmann [mailto:markus@mhof.com] >Sent: Tuesday, April 16, 2002 10:51 AM >To: Penno, Reinaldo [SC9:T327:EXCH] >Cc: Yang, Lily L; Mark Nottingham; ietf-openproxy@imc.org; LMM@acm.org >Subject: Re: no-transform & Warning > > >Reinaldo Penno wrote: > >> You need to understand HTTP 1.1. Sometimes you just want to send the >> host: header (request URL filtering). Sometimes the entire payload. >> Sometimes you want (for web mail virus scanning), send only >part of a >> payload. > >The question is whether the callout protocol itself needs "to >understand HTTP", or whether the application logic can be build around >a generic callout protocol. > >-Markus > > ------_=_NextPart_001_01C1E571.B7952B9A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: no-transform & Warning

sorry..

so the callout protocol should be application = agnostic. Otherwise we will need patch it up for every new protocol = (RTSP, SMTP and others) or its updates. And yes, I believe we can make = it application agnostic.

regards,

Reinaldo

>-----Original Message-----
>From: Markus Hofmann [mailto:markus@mhof.com]
>Sent: Tuesday, April 16, 2002 10:51 AM
>To: Penno, Reinaldo [SC9:T327:EXCH]
>Cc: Yang, Lily L; Mark Nottingham; = ietf-openproxy@imc.org; LMM@acm.org
>Subject: Re: no-transform & Warning
>
>
>Reinaldo Penno wrote:
>
>> You need to understand HTTP 1.1. Sometimes = you just want to send the
>> host: header (request URL filtering). = Sometimes the entire payload.
>> Sometimes you want (for web mail virus = scanning), send only
>part of a
>> payload.
>
>The question is whether the callout protocol = itself needs "to
>understand HTTP", or whether the = application logic can be build around
>a generic callout protocol.
>
>-Markus
>
>

------_=_NextPart_001_01C1E571.B7952B9A-- From owner-ietf-openproxy@mail.imc.org Tue Apr 16 14:58:34 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03946 for ; Tue, 16 Apr 2002 14:58:33 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3GIGIP12587 for ietf-openproxy-bks; Tue, 16 Apr 2002 11:16:18 -0700 (PDT) Received: from mail.mnot.net (adsl-64-170-196-242.dsl.snfc21.pacbell.net [64.170.196.242]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3GIGHm12583 for ; Tue, 16 Apr 2002 11:16:17 -0700 (PDT) Received: from 1-130.mnot.net (1-130.mnot.net [192.168.1.130]) by mail.mnot.net (Postfix) with ESMTP id 9F983976D; Tue, 16 Apr 2002 11:16:19 -0700 (PDT) Date: Tue, 16 Apr 2002 11:16:19 -0700 Subject: Re: no-transform & Warning Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: ietf-openproxy@imc.org, LMM@acm.org To: Markus Hofmann From: Mark Nottingham In-Reply-To: <3CBC3877.9090903@mhof.com> Message-Id: <0C9D5C8E-5166-11D6-8080-000A27836A68@mnot.net> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I was talking about placing a requirement on the OPES server implmentation, not the callout protocol itself. I.e., the protocol can be agnostic, but the thing that stuffs HTTP messages into it had better understand the semantics of HTTP. On Tuesday, April 16, 2002, at 07:43 AM, Markus Hofmann wrote: > Mark Nottingham wrote: > >> These mechanisms are required in order to be HTTP-compliant; >> therefore, I'd say they should be part of the ICAP server's HTTP stack. > > Hm, this assumes that the payload (i.e. the content-path protocol) is > NOT transparent to the OPES/Callout protocol, i.e. the OPES/Callout > protocol needs to have knowledge about the sematics of the encapsulated > application protocol (HTTP in this case). > > Do we want to make this assumption? Comments? > > -Markus > > -- Mark Nottingham http://www.mnot.net/ From owner-ietf-openproxy@mail.imc.org Tue Apr 16 15:02:32 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04525 for ; Tue, 16 Apr 2002 15:02:32 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3GIFdi12542 for ietf-openproxy-bks; Tue, 16 Apr 2002 11:15:39 -0700 (PDT) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3GIFam12537 for ; Tue, 16 Apr 2002 11:15:36 -0700 (PDT) Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.39 2002/04/15 17:47:23 root Exp $) with ESMTP id g3GIGf120320 for ; Tue, 16 Apr 2002 18:16:41 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by talaria.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.16 2002/04/15 17:47:00 root Exp $) with SMTP id g3GIHKP15530 for ; Tue, 16 Apr 2002 18:17:20 GMT Received: from FMSMSX018.fm.intel.com ([132.233.42.197]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002041611193229411 ; Tue, 16 Apr 2002 11:19:32 -0700 Received: by fmsmsx018.fm.intel.com with Internet Mail Service (5.5.2653.19) id <2WWR878L>; Tue, 16 Apr 2002 11:15:30 -0700 Message-ID: From: "Yang, Lily L" To: "'Reinaldo Penno'" , Markus Hofmann Cc: "Yang, Lily L" , Mark Nottingham, ietf-openproxy@imc.org, LMM@acm.org Subject: RE: no-transform & Warning Date: Tue, 16 Apr 2002 11:15:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E572.AE17EAC0" 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_01C1E572.AE17EAC0 Content-Type: text/plain; charset="iso-8859-1" It certainly would be nice if we can do that ...sounds like a good requirement to have. Lily -----Original Message----- From: Reinaldo Penno [mailto:reinaldo_penno@nortelnetworks.com] Sent: Tuesday, April 16, 2002 11:09 AM To: Markus Hofmann Cc: Yang, Lily L; Mark Nottingham; ietf-openproxy@imc.org; LMM@acm.org Subject: RE: no-transform & Warning sorry.. so the callout protocol should be application agnostic. Otherwise we will need patch it up for every new protocol (RTSP, SMTP and others) or its updates. And yes, I believe we can make it application agnostic. regards, Reinaldo >-----Original Message----- >From: Markus Hofmann [ mailto:markus@mhof.com ] >Sent: Tuesday, April 16, 2002 10:51 AM >To: Penno, Reinaldo [SC9:T327:EXCH] >Cc: Yang, Lily L; Mark Nottingham; ietf-openproxy@imc.org; LMM@acm.org >Subject: Re: no-transform & Warning > > >Reinaldo Penno wrote: > >> You need to understand HTTP 1.1. Sometimes you just want to send the >> host: header (request URL filtering). Sometimes the entire payload. >> Sometimes you want (for web mail virus scanning), send only >part of a >> payload. > >The question is whether the callout protocol itself needs "to >understand HTTP", or whether the application logic can be build around >a generic callout protocol. > >-Markus > > ------_=_NextPart_001_01C1E572.AE17EAC0 Content-Type: text/html; charset="iso-8859-1" RE: no-transform & Warning
It certainly would be nice if we can do that ...sounds like a good requirement to have.
Lily
-----Original Message-----
From: Reinaldo Penno [mailto:reinaldo_penno@nortelnetworks.com]
Sent: Tuesday, April 16, 2002 11:09 AM
To: Markus Hofmann
Cc: Yang, Lily L; Mark Nottingham; ietf-openproxy@imc.org; LMM@acm.org
Subject: RE: no-transform & Warning

sorry..

so the callout protocol should be application agnostic. Otherwise we will need patch it up for every new protocol (RTSP, SMTP and others) or its updates. And yes, I believe we can make it application agnostic.

regards,

Reinaldo

>-----Original Message-----
>From: Markus Hofmann [mailto:markus@mhof.com]
>Sent: Tuesday, April 16, 2002 10:51 AM
>To: Penno, Reinaldo [SC9:T327:EXCH]
>Cc: Yang, Lily L; Mark Nottingham; ietf-openproxy@imc.org; LMM@acm.org
>Subject: Re: no-transform & Warning
>
>
>Reinaldo Penno wrote:
>
>> You need to understand HTTP 1.1. Sometimes you just want to send the
>> host: header (request URL filtering). Sometimes the entire payload.
>> Sometimes you want (for web mail virus scanning), send only
>part of a
>> payload.
>
>The question is whether the callout protocol itself needs "to
>understand HTTP", or whether the application logic can be build around
>a generic callout protocol.
>
>-Markus
>
>

------_=_NextPart_001_01C1E572.AE17EAC0-- From owner-ietf-openproxy@mail.imc.org Tue Apr 16 15:21:37 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06989 for ; Tue, 16 Apr 2002 15:21:37 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g3GIYRJ13475 for ietf-openproxy-bks; Tue, 16 Apr 2002 11:34:27 -0700 (PDT) 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.3) with SMTP id g3GIYPm13470 for ; Tue, 16 Apr 2002 11:34:25 -0700 (PDT) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by crufty; Tue Apr 16 14:33:56 EDT 2002 Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g3GIYJk50983; Tue, 16 Apr 2002 14:34:19 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id OAA28672; Tue, 16 Apr 2002 14:34:19 -0400 (EDT) Message-ID: <3CBC6EAB.3080402@mhof.com> Date: Tue, 16 Apr 2002 14:34:19 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Nottingham CC: ietf-openproxy@imc.org, LMM@acm.org Subject: Re: no-transform & Warning References: <0C9D5C8E-5166-11D6-8080-000A27836A68@mnot.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 Mark Nottingham wrote: > I was talking about placing a requirement on the OPES server > implmentation, not the callout protocol itself. I.e., the protocol can > be agnostic, but the thing that stuffs HTTP messages into it had better > understand the semantics of HTTP. Yup, this I agree with, building the application semantic around a generic protocol, rather than building it into the protocol itself. It was not clear to me whether people thought of making the callout protocol itself aware of the encapsulated application protocol. -Markus From owner-ietf-openproxy@mail.imc.org Tue Apr 16 17:25:28 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21862 for ; Tue, 16 Apr 2002 17:25:28 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3GKXMn22696 for ietf-openproxy-bks; Tue, 16 Apr 2002 13:33:22 -0700 (PDT) Received: from zsc3s004.us.nortel.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3GKXLm22691 for ; Tue, 16 Apr 2002 13:33:21 -0700 (PDT) Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zsc3s004.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3GKX9703035; Tue, 16 Apr 2002 13:33:09 -0700 (PDT) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2JXM0H81>; Tue, 16 Apr 2002 13:33:00 -0700 Message-ID: <7B802811BE77D51189910002A55CFD2C01EFCB1E@zsc3c032.us.nortel.com> From: "Reinaldo Penno" To: Mark Nottingham , Markus Hofmann Cc: ietf-openproxy@imc.org, LMM@acm.org Subject: call protocol requirements questions Date: Tue, 16 Apr 2002 13:32:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E585.E5B41A22" 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_01C1E585.E5B41A22 Content-Type: text/plain; charset="iso-8859-1" This is my current list of call protocol requirements questions. Any opinions? *Should it be reliable? Would the transport layer provide this service? *Should it be congestion aware? Would the transport layer provide this service? *Should it support keepalives? Would the transport layer provide this service (SCTP, for instance)? *Should the protocol reuse current encryption methods? We assume yes. *What about Failover requirements? *Should it support capability negotiation? For instance you just tell the intermediary that there are some callout server available and it figures out by itself which services each one provides, extensions, etc. *Should it be NAT friendly? *Should it work through firewalls? Maybe in some situations the intermediary is also a middlebox. *Should it be application agnostic? regards, Reinaldo ------_=_NextPart_001_01C1E585.E5B41A22 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable call protocol requirements questions

This is my current list of call protocol requirements = questions. Any opinions?

*Should it be reliable?
 Would the transport layer provide this = service?
*Should it be congestion aware?
 Would the transport layer provide this = service?
*Should it support keepalives?
 Would the transport layer provide this service = (SCTP, for instance)?
*Should the protocol reuse current encryption = methods? We assume yes.
*What about Failover requirements?
*Should it support capability negotiation?
 For instance you just tell the intermediary = that there are some callout server available and it figures out by = itself which 

 services each one provides, extensions, etc. =
*Should it be NAT friendly?
*Should it work through firewalls?
 Maybe in some situations the intermediary is = also a middlebox.
*Should it be application agnostic?

regards,

Reinaldo

------_=_NextPart_001_01C1E585.E5B41A22-- From owner-ietf-openproxy@mail.imc.org Wed Apr 17 01:36:26 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02460 for ; Wed, 17 Apr 2002 01:36:25 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3H4onM09457 for ietf-openproxy-bks; Tue, 16 Apr 2002 21:50:49 -0700 (PDT) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3H4onm09453 for ; Tue, 16 Apr 2002 21:50:49 -0700 (PDT) Received: from fakir.india.hp.com (fakir.india.hp.com [15.10.40.3]) by palrel10.hp.com (Postfix) with ESMTP id DBBB4C0068B; Tue, 16 Apr 2002 21:50:40 -0700 (PDT) Received: from india.hp.com (nt44210.india.hp.com [15.10.44.210]) by fakir.india.hp.com with ESMTP (8.8.6 (PHNE_17135)/8.8.6 SMKit7.02) id KAA14560; Wed, 17 Apr 2002 10:21:50 +0530 (IST) Message-ID: <3CBCFFE5.63A13657@india.hp.com> Date: Wed, 17 Apr 2002 10:23:58 +0530 From: Geetha Manjunath X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Markus Hofmann Cc: Mark Nottingham , ietf-openproxy@imc.org, LMM@acm.org Subject: Re: no-transform & Warning References: <3CBC3877.9090903@mhof.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I would say, this is a requirement on the HTTP proxy servers rather than the OPES/Callout protocol. (a) Cache-Control: An implementation of the icap client module in the HTTP proxy server (say squid) would have to just check for the Cache-Control header before sending it to the ICAP server for a transformation (reqmod/respmod). - Section 14.9.5 of RFC 2616 HTTP 1.1 (b) Warning 214: Along the same lines, the Warning header is required to be inserted by the HTTP 1.1 complaint proxy server. ( as per section 14.46 of RFC 2616) Did I miss something? regards, Geetha Markus Hofmann wrote: > Masms are required in order to be HTTP-compliant; therefore, > > I'd say they should be part of the ICAP server's HTTP stack. > > Hm, this assumes that the payload (irk Nottingham wrote: > > > These mechani.e. the content-path protocol) is > NOT transparent to the OPES/Callout protocol, i.e. the OPES/Callout > protocol needs to have knowledge about the sematics of the > encapsulated application protocol (HTTP in this case). > > Do we want to make this assumption? Comments? > > -Markus > Subject: no-transform & Warning > > Date:Thu, 11 Apr 2002 13:21:45 -0700 > From: Mark Nottingham > > Just curious, > > Is anyone aware of an OPES, ICAP or other transcoding implementation > that: > > a) honors Cache-Control: no-transform > b) honors Warning: 214 Transformation applied > > in either requests or responses? > > -- > Mark Nottingham > http://www.mnot.net/ > > > From owner-ietf-openproxy@mail.imc.org Wed Apr 17 18:18:12 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09404 for ; Wed, 17 Apr 2002 18:18:12 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3HLThK05224 for ietf-openproxy-bks; Wed, 17 Apr 2002 14:29:43 -0700 (PDT) Received: from hermes.webwasher.com (mail.webwasher.com [195.162.240.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3HLTfm05219 for ; Wed, 17 Apr 2002 14:29:42 -0700 (PDT) Received: from frank2 ([149.225.2.70]) by hermes.webwasher.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 17 Apr 2002 23:28:25 +0200 From: "Frank Berzau" To: Subject: RE: no-transform & Warning Date: Wed, 17 Apr 2002 23:28:03 +0200 Organization: webwasher.com Message-ID: <000901c1e656$e78566e0$0241a8c0@frank2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3CBCFFE5.63A13657@india.hp.com> X-OriginalArrivalTime: 17 Apr 2002 21:28:25.0406 (UTC) FILETIME=[CECAD5E0:01C1E656] Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Technically the callout protocol itself does not need to be aware of the encapsulated payload and it's specific syntax or requirements. Question is whether the callout client and/or server need to be. As far as the client is concerned, it depends. The client could be implemented in a switch, not a http proxy (to pick just one example). As such it is unlikely that the client understands the protocol fully, it would just forward all traffic sent to port 80 to a callout server. If we require the client to understand those issues, it will make it far more complex than needed. As far as the callout server is concerned, the answer can only be Yes. The callout server is operating on the payload (headers or body, or both or part of either, whatever), so it does need to understand the protocol, and comply to all it's rules. Other examples would be callout server that work on SMTP, NNTP or any other protocol. Each one of those would need to understand the respective protocol it's dealing with. There may be cases, where putting "intelligence" into the client would make sense. For example the no-transform HTTP header would make it unnecessary to send a request to a callout server. In those very specific and rare cases I'd still leave it up to the callout server to handle it. Still a vendor could build that checking into the client in order to improve performance by eliminating un-needed requests. That, however, would be implementation specific. There is no need to require it if we assume it's already handled at the server. Thanks, Frank > -----Original Message----- > From: owner-ietf-openproxy@mail.imc.org > [mailto:owner-ietf-openproxy@mail.imc.org] On Behalf Of > Geetha Manjunath > Sent: Mittwoch, 17. April 2002 06:54 > To: Markus Hofmann > Cc: Mark Nottingham; ietf-openproxy@imc.org; LMM@acm.org > Subject: Re: no-transform & Warning > > > > I would say, this is a requirement on the HTTP proxy servers > rather than the > OPES/Callout protocol. > > (a) Cache-Control: An implementation of the icap client > module in the HTTP > proxy server (say squid) would have to just check for the > Cache-Control > header before sending it to the ICAP server for a transformation > (reqmod/respmod). - Section 14.9.5 of RFC 2616 HTTP 1.1 > (b) Warning 214: Along the same lines, the Warning header is > required to be > inserted by the HTTP 1.1 complaint proxy server. ( as per > section 14.46 of > RFC 2616) > > Did I miss something? > > regards, > Geetha > > Markus Hofmann wrote: > > > Masms are required in order to be HTTP-compliant; therefore, > > > I'd say they should be part of the ICAP server's HTTP stack. > > > > Hm, this assumes that the payload (irk Nottingham wrote: > > > > > These mechani.e. the content-path protocol) is > > NOT transparent to the OPES/Callout protocol, i.e. the OPES/Callout > > protocol needs to have knowledge about the sematics of the > > encapsulated application protocol (HTTP in this case). > > > > Do we want to make this assumption? Comments? > > > > -Markus > > > Subject: no-transform & Warning > > > > Date:Thu, 11 Apr 2002 13:21:45 -0700 > > From: Mark Nottingham > > > > Just curious, > > > > Is anyone aware of an OPES, ICAP or other transcoding implementation > > that: > > > > a) honors Cache-Control: no-transform > > b) honors Warning: 214 Transformation applied > > > > in either requests or responses? > > > > -- > > Mark Nottingham > > http://www.mnot.net/ > > > > > > > From owner-ietf-openproxy@mail.imc.org Wed Apr 17 19:55:06 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11355 for ; Wed, 17 Apr 2002 19:55:05 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3HN4oB07580 for ietf-openproxy-bks; Wed, 17 Apr 2002 16:04:50 -0700 (PDT) Received: from adsl-64-174-134-222.dsl.sntc01.pacbell.net (adsl-64-174-134-222.dsl.sntc01.pacbell.net [64.174.134.222]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3HN4mm07576 for ; Wed, 17 Apr 2002 16:04:48 -0700 (PDT) Received: from adsl-64-174-134-222.dsl.sntc01.pacbell.net (localhost [127.0.0.1]) by adsl-64-174-134-222.dsl.sntc01.pacbell.net (Postfix) with ESMTP id AFF4C17A169; Wed, 17 Apr 2002 16:04:49 -0700 (PDT) Date: Wed, 17 Apr 2002 16:04:48 -0700 From: Ian Cooper To: ietf-openproxy@imc.org Cc: Frank Berzau Subject: RE: no-transform & Warning Message-ID: <476063.1019059487@adsl-64-174-134-222.dsl.sntc01.pacbell.net> In-Reply-To: <000901c1e656$e78566e0$0241a8c0@frank2> References: <000901c1e656$e78566e0$0241a8c0@frank2> X-Mailer: Mulberry/2.2.0b4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On Wednesday, April 17, 2002 23:28 +0200 Frank Berzau wrote: > > Technically the callout protocol itself does not need to be aware of the > encapsulated payload and it's specific syntax or requirements. Question > is whether the callout client and/or server need to be. As far as the > client is concerned, it depends. The client could be implemented in a > switch, not a http proxy (to pick just one example). As such it is > unlikely that the client understands the protocol fully, it would just > forward all traffic sent to port 80 to a callout server. If we require > the client to understand those issues, it will make it far more complex > than needed. I was under the impression that the non-application layer intermediaries (e.g. things other than "proxies" or "surrogates") were out of scope for the work being considered by this WG. Traffic interception/redirection operating at the layer you suggest above is widely agreed to be a Very Bad Thing in terms of the end-to-end architecture. > As far as the callout server is concerned, the answer can > only be Yes. The callout server is operating on the payload (headers or > body, or both or part of either, whatever), so it does need to > understand the protocol, and comply to all it's rules. Other examples > would be callout server that work on SMTP, NNTP or any other protocol. > Each one of those would need to understand the respective protocol it's > dealing with. > > There may be cases, where putting "intelligence" into the client would > make sense. For example the no-transform HTTP header would make it > unnecessary to send a request to a callout server. In those very > specific and rare cases I'd still leave it up to the callout server to > handle it. Still a vendor could build that checking into the client in > order to improve performance by eliminating un-needed requests. That, > however, would be implementation specific. There is no need to require > it if we assume it's already handled at the server. Er, but seeing as the application intermediary must, by definition, understand the protocol that it might be operating modifications on (with the help of the callout system) it should already have the appropriate code to operate on those directives that it needs to honour. E.g. in this case if there's a Cache-control: no-transform the HTTP intermediary should already have a code path to stop it being vectored AT ALL. Similarly, the HTTP intermediary is the one entity in the relationship that likely has the best knowledge as to whether a Warning: 214 should be added to the outbound response headers. [And I think I just echoed Geetha there.] > > Thanks, Frank > > >> -----Original Message----- >> From: owner-ietf-openproxy@mail.imc.org >> [mailto:owner-ietf-openproxy@mail.imc.org] On Behalf Of >> Geetha Manjunath >> Sent: Mittwoch, 17. April 2002 06:54 >> To: Markus Hofmann >> Cc: Mark Nottingham; ietf-openproxy@imc.org; LMM@acm.org >> Subject: Re: no-transform & Warning >> >> >> >> I would say, this is a requirement on the HTTP proxy servers >> rather than the >> OPES/Callout protocol. >> >> (a) Cache-Control: An implementation of the icap client >> module in the HTTP >> proxy server (say squid) would have to just check for the >> Cache-Control >> header before sending it to the ICAP server for a transformation >> (reqmod/respmod). - Section 14.9.5 of RFC 2616 HTTP 1.1 >> (b) Warning 214: Along the same lines, the Warning header is >> required to be >> inserted by the HTTP 1.1 complaint proxy server. ( as per >> section 14.46 of >> RFC 2616) >> >> Did I miss something? >> >> regards, >> Geetha >> >> Markus Hofmann wrote: >> >> > Masms are required in order to be HTTP-compliant; therefore, >> > > I'd say they should be part of the ICAP server's HTTP stack. >> > >> > Hm, this assumes that the payload (irk Nottingham wrote: >> > >> > > These mechani.e. the content-path protocol) is >> > NOT transparent to the OPES/Callout protocol, i.e. the OPES/Callout >> > protocol needs to have knowledge about the sematics of the >> > encapsulated application protocol (HTTP in this case). >> > >> > Do we want to make this assumption? Comments? >> > >> > -Markus >> >> > Subject: no-transform & Warning >> > >> > Date:Thu, 11 Apr 2002 13:21:45 -0700 >> > From: Mark Nottingham >> > >> > Just curious, >> > >> > Is anyone aware of an OPES, ICAP or other transcoding implementation >> > that: >> > >> > a) honors Cache-Control: no-transform >> > b) honors Warning: 214 Transformation applied >> > >> > in either requests or responses? >> > >> > -- >> > Mark Nottingham >> > http://www.mnot.net/ >> > >> > >> > >> > From owner-ietf-openproxy@mail.imc.org Fri Apr 19 18:01:59 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09385 for ; Fri, 19 Apr 2002 18:01:59 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g3JL8Jv19336 for ietf-openproxy-bks; Fri, 19 Apr 2002 14:08:19 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3JL8Ib19331 for ; Fri, 19 Apr 2002 14:08:18 -0700 (PDT) Received: from oskar3 ([65.96.167.167]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020419210816.MOHA1143.rwcrmhc51.attbi.com@oskar3>; Fri, 19 Apr 2002 21:08:16 +0000 From: "Oskar Batuner" To: "Markus Hofmann" , "Mark Nottingham" Cc: , Subject: RE: no-transform & Warning Date: Fri, 19 Apr 2002 17:08:16 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3CBC6EAB.3080402@mhof.com> Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I think Cache-Control headers and related response codes should be applied exactly to the subject they claim - cache control. The extended use of HTTP as a base protocol results in temptation to overload semantics of existing headers. Mark Nottingham pointed one example of such overload about a year ago (forgive me if I'm wrong with dates). Mark has posted a document explaining why use of cache control headers is bad in origin-surrogate context: semantic roles of HTTP client and server are different from the surrogate-origin server case - they have a special trust relationship, and cache control part of HTTP should better be preserved to manage downstream caches. The same approach should be taken for the callout protocol. The proxy that is running OPES rules serves as a callout gateway. According to the OPES intentions and IAB guidelines it has an explicit permission to perform certain actions - that is, special relationship with either origin server or the end user. Cache control directives should be preserved for caches that may occur between OPES gateway and end user - otherwise there is no mechanism left for content producer to control intimidate cache behavior. Callout participants and callout protocol SHOULD NOT try to interpret such directives. One additional implication is that in some scenarios OPES server (and implicitly OPES gateway) may act as an authorized surrogate content producer. In this scenario cache control directives MAY by altered to reflect the changed content semantics. The way to handle them was very well described in Mark's document mentioned above. I do not remember what happened to it, I'm afraid it just expired as a draft. Again, sorry if I'm wrong. Mark MAY shed more light on the fate of this document. - Oskar > -----Original Message----- > From: owner-ietf-openproxy@mail.imc.org > [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of Markus Hofmann > Sent: Tuesday, April 16, 2002 2:34 PM > To: Mark Nottingham > Cc: ietf-openproxy@imc.org; LMM@acm.org > Subject: Re: no-transform & Warning > > > > Mark Nottingham wrote: > > > I was talking about placing a requirement on the OPES server > > implmentation, not the callout protocol itself. I.e., the protocol can > > be agnostic, but the thing that stuffs HTTP messages into it had better > > understand the semantics of HTTP. > > Yup, this I agree with, building the application semantic around a > generic protocol, rather than building it into the protocol itself. It > was not clear to me whether people thought of making the callout > protocol itself aware of the encapsulated application protocol. > > -Markus > From owner-ietf-openproxy@mail.imc.org Fri Apr 19 19:52:03 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20672 for ; Fri, 19 Apr 2002 19:52:02 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3JN45Q23266 for ietf-openproxy-bks; Fri, 19 Apr 2002 16:04:05 -0700 (PDT) Received: from mail.mnot.net (adsl-64-170-196-242.dsl.snfc21.pacbell.net [64.170.196.242]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3JN43b23262 for ; Fri, 19 Apr 2002 16:04:03 -0700 (PDT) Received: from 1-130.mnot.net (1-130.mnot.net [192.168.1.130]) by mail.mnot.net (Postfix) with ESMTP id 833FA976D; Fri, 19 Apr 2002 16:04:05 -0700 (PDT) Date: Fri, 19 Apr 2002 16:04:04 -0700 Subject: Re: no-transform & Warning Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: "Markus Hofmann" , , To: "Oskar Batuner" From: Mark Nottingham In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I think Oskar is referring to [1]. I agree that in a surrogate (gateway) scenario, where there is an out-of band contract regarding message handling between the origin and the intermediary, Cache-Control: no-transform in a request, as well as the generation of transform-related Warnings, can be safely ignored (if both parties desire that behavior, of course). However, a proxy is a different kettle of fish; to be HTTP compliant, proxies encountering no-transform "MUST NOT change any aspect of the entity-body that is specified by these headers, including the value of the entity-body itself." [2] I'd argue that even a proxy with an OPES ruleset from whoever's driving the User-Agent can't ignore this requirement; it places too much trust in what is often a heuristic - the ruleset - at the expense of directly associated, declared information to the contrary. Looking at the IAB "considerations" for OPES [3], it seems that no-transform and Warning make significant inroads into the requirement to be non-blocking, as well as that for notification. I can think of no better way to allow clients to specify that a message should not be transformed, as well as notify them that an entity has been changed; using an already-specified mechanism assures that at least theoretically, OPES-ignorant HTTP implementations can still interoperate with OPES intermediaries. Regarding the scope of "Cache-Control", "cache" isn't used with great precision in this part (and perhaps some others) of 2616; the language [2] clearly scopes no-transform as applying to caches *and* proxies, not just cache implementations. 1. http://www.terena.nl/conf/wcw/Proceedings/S4/S4-3.pdf 2. http://rfc2616.x42.com/ - Section 14.9.5 3. http://rfc3238.x42.com/ On Friday, April 19, 2002, at 02:08 PM, Oskar Batuner wrote: > I think Cache-Control headers and related response codes should be > applied > exactly to the subject they claim - cache control. The extended use of > HTTP > as a base protocol results in temptation to overload semantics of > existing > headers. Mark Nottingham pointed one example of such overload about a > year > ago (forgive me if I'm wrong with dates). Mark has posted a document > explaining why use of cache control headers is bad in origin-surrogate > context: semantic roles of HTTP client and server are different from the > surrogate-origin server case - they have a special trust relationship, > and > cache control part of HTTP should better be preserved to manage > downstream > caches. > > The same approach should be taken for the callout protocol. The proxy > that > is running OPES rules serves as a callout gateway. According to the OPES > intentions and IAB guidelines it has an explicit permission to perform > certain actions - that is, special relationship with either origin > server or > the end user. Cache control directives should be preserved for caches > that > may occur between OPES gateway and end user - otherwise there is no > mechanism left for content producer to control intimidate cache > behavior. > Callout participants and callout protocol SHOULD NOT try to interpret > such > directives. > > One additional implication is that in some scenarios OPES server (and > implicitly OPES gateway) may act as an authorized surrogate content > producer. In this scenario cache control directives MAY by altered to > reflect the changed content semantics. The way to handle them was very > well > described in Mark's document mentioned above. I do not remember what > happened to it, I'm afraid it just expired as a draft. Again, sorry if > I'm > wrong. Mark MAY shed more light on the fate of this document. > > - Oskar > >> -----Original Message----- >> From: owner-ietf-openproxy@mail.imc.org >> [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of Markus Hofmann >> Sent: Tuesday, April 16, 2002 2:34 PM >> To: Mark Nottingham >> Cc: ietf-openproxy@imc.org; LMM@acm.org >> Subject: Re: no-transform & Warning >> >> >> >> Mark Nottingham wrote: >> >>> I was talking about placing a requirement on the OPES server >>> implmentation, not the callout protocol itself. I.e., the protocol can >>> be agnostic, but the thing that stuffs HTTP messages into it had >>> better >>> understand the semantics of HTTP. >> >> Yup, this I agree with, building the application semantic around a >> generic protocol, rather than building it into the protocol itself. It >> was not clear to me whether people thought of making the callout >> protocol itself aware of the encapsulated application protocol. >> >> -Markus >> > > -- Mark Nottingham http://www.mnot.net/ From owner-ietf-openproxy@mail.imc.org Fri Apr 19 21:15:04 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29099 for ; Fri, 19 Apr 2002 21:15:04 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3K0Pg626649 for ietf-openproxy-bks; Fri, 19 Apr 2002 17:25:42 -0700 (PDT) Received: from mgr1.xmission.com (mgr1.xmission.com [198.60.22.201]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3K0Pfb26645 for ; Fri, 19 Apr 2002 17:25:41 -0700 (PDT) Received: from [198.60.22.22] (helo=mail.xmission.com) by mgr1.xmission.com with esmtp (Exim 3.22 #1) id 16yih4-0000eg-00; Fri, 19 Apr 2002 18:25:34 -0600 Received: from [166.70.13.6] (helo=alum.mit.edu) by mail.xmission.com with esmtp (Exim 3.22 #1) id 16yih3-00079H-00; Fri, 19 Apr 2002 18:25:33 -0600 Message-ID: <3CC0B041.8030307@alum.mit.edu> Date: Fri, 19 Apr 2002 18:03:13 -0600 From: "The Purple Streak (Hilarie Orman)" User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Mark Nottingham CC: Oskar Batuner , Markus Hofmann , ietf-openproxy@imc.org, LMM@acm.org Subject: Re: no-transform & Warning References: 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 don't see why a ruleset is less reliable than an implicit contract. Hilarie Mark Nottingham wrote: > > > I think Oskar is referring to [1]. > > I agree that in a surrogate (gateway) scenario, where there is an out-of > band contract regarding message handling between the origin and the > intermediary, Cache-Control: no-transform in a request, as well as the > generation of transform-related Warnings, can be safely ignored (if both > parties desire that behavior, of course). > > However, a proxy is a different kettle of fish; to be HTTP compliant, > proxies encountering no-transform "MUST NOT change any aspect of the > entity-body that is specified by these headers, including the value of > the entity-body itself." [2] I'd argue that even a proxy with an OPES > ruleset from whoever's driving the User-Agent can't ignore this > requirement; it places too much trust in what is often a heuristic - the > ruleset - at the expense of directly associated, declared information to > the contrary. > > Looking at the IAB "considerations" for OPES [3], it seems that > no-transform and Warning make significant inroads into the requirement > to be non-blocking, as well as that for notification. I can think of no > better way to allow clients to specify that a message should not be > transformed, as well as notify them that an entity has been changed; > using an already-specified mechanism assures that at least > theoretically, OPES-ignorant HTTP implementations can still interoperate > with OPES intermediaries. > > Regarding the scope of "Cache-Control", "cache" isn't used with great > precision in this part (and perhaps some others) of 2616; the language > [2] clearly scopes no-transform as applying to caches *and* proxies, not > just cache implementations. > > > 1. http://www.terena.nl/conf/wcw/Proceedings/S4/S4-3.pdf > 2. http://rfc2616.x42.com/ - Section 14.9.5 > 3. http://rfc3238.x42.com/ > > > On Friday, April 19, 2002, at 02:08 PM, Oskar Batuner wrote: > >> I think Cache-Control headers and related response codes should be >> applied >> exactly to the subject they claim - cache control. The extended use of >> HTTP >> as a base protocol results in temptation to overload semantics of >> existing >> headers. Mark Nottingham pointed one example of such overload about a >> year >> ago (forgive me if I'm wrong with dates). Mark has posted a document >> explaining why use of cache control headers is bad in origin-surrogate >> context: semantic roles of HTTP client and server are different from the >> surrogate-origin server case - they have a special trust relationship, >> and >> cache control part of HTTP should better be preserved to manage >> downstream >> caches. >> >> The same approach should be taken for the callout protocol. The proxy >> that >> is running OPES rules serves as a callout gateway. According to the OPES >> intentions and IAB guidelines it has an explicit permission to perform >> certain actions - that is, special relationship with either origin >> server or >> the end user. Cache control directives should be preserved for caches >> that >> may occur between OPES gateway and end user - otherwise there is no >> mechanism left for content producer to control intimidate cache behavior. >> Callout participants and callout protocol SHOULD NOT try to interpret >> such >> directives. >> >> One additional implication is that in some scenarios OPES server (and >> implicitly OPES gateway) may act as an authorized surrogate content >> producer. In this scenario cache control directives MAY by altered to >> reflect the changed content semantics. The way to handle them was very >> well >> described in Mark's document mentioned above. I do not remember what >> happened to it, I'm afraid it just expired as a draft. Again, sorry if >> I'm >> wrong. Mark MAY shed more light on the fate of this document. >> >> - Oskar >> >>> -----Original Message----- >>> From: owner-ietf-openproxy@mail.imc.org >>> [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of Markus Hofmann >>> Sent: Tuesday, April 16, 2002 2:34 PM >>> To: Mark Nottingham >>> Cc: ietf-openproxy@imc.org; LMM@acm.org >>> Subject: Re: no-transform & Warning >>> >>> >>> >>> Mark Nottingham wrote: >>> >>>> I was talking about placing a requirement on the OPES server >>>> implmentation, not the callout protocol itself. I.e., the protocol can >>>> be agnostic, but the thing that stuffs HTTP messages into it had better >>>> understand the semantics of HTTP. >>> >>> >>> Yup, this I agree with, building the application semantic around a >>> generic protocol, rather than building it into the protocol itself. It >>> was not clear to me whether people thought of making the callout >>> protocol itself aware of the encapsulated application protocol. >>> >>> -Markus >>> >> >> > -- > Mark Nottingham > http://www.mnot.net/ > > > From owner-ietf-openproxy@mail.imc.org Fri Apr 19 22:27:28 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07992 for ; Fri, 19 Apr 2002 22:27:28 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3K1kFj28242 for ietf-openproxy-bks; Fri, 19 Apr 2002 18:46:15 -0700 (PDT) Received: from mail.mnot.net (adsl-64-170-196-242.dsl.snfc21.pacbell.net [64.170.196.242]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3K1kDb28238 for ; Fri, 19 Apr 2002 18:46:13 -0700 (PDT) Received: from 1-130.mnot.net (1-130.mnot.net [192.168.1.130]) by mail.mnot.net (Postfix) with ESMTP id B083C976D; Fri, 19 Apr 2002 18:46:16 -0700 (PDT) Date: Fri, 19 Apr 2002 18:46:16 -0700 Subject: Re: no-transform & Warning Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: Oskar Batuner , Markus Hofmann , ietf-openproxy@imc.org, LMM@acm.org To: "The Purple Streak (Hilarie Orman)" From: Mark Nottingham In-Reply-To: <3CC0B041.8030307@alum.mit.edu> Message-Id: <674B6E43-5400-11D6-A8C1-000A27836A68@mnot.net> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I'd characterise CC: no-transform as an explicit directive, not as an implicit contract. Or are you saying that HTTP itself is an implicit contract? On Friday, April 19, 2002, at 05:03 PM, The Purple Streak (Hilarie Orman) wrote: > > I don't see why a ruleset is less reliable than an implicit contract. > > Hilarie > > Mark Nottingham wrote: > >> I think Oskar is referring to [1]. >> I agree that in a surrogate (gateway) scenario, where there is an >> out-of band contract regarding message handling between the origin and >> the intermediary, Cache-Control: no-transform in a request, as well as >> the generation of transform-related Warnings, can be safely ignored >> (if both parties desire that behavior, of course). >> However, a proxy is a different kettle of fish; to be HTTP compliant, >> proxies encountering no-transform "MUST NOT change any aspect of the >> entity-body that is specified by these headers, including the value of >> the entity-body itself." [2] I'd argue that even a proxy with an OPES >> ruleset from whoever's driving the User-Agent can't ignore this >> requirement; it places too much trust in what is often a heuristic - >> the ruleset - at the expense of directly associated, declared >> information to the contrary. >> Looking at the IAB "considerations" for OPES [3], it seems that >> no-transform and Warning make significant inroads into the requirement >> to be non-blocking, as well as that for notification. I can think of >> no better way to allow clients to specify that a message should not be >> transformed, as well as notify them that an entity has been changed; >> using an already-specified mechanism assures that at least >> theoretically, OPES-ignorant HTTP implementations can still >> interoperate with OPES intermediaries. >> Regarding the scope of "Cache-Control", "cache" isn't used with great >> precision in this part (and perhaps some others) of 2616; the language >> [2] clearly scopes no-transform as applying to caches *and* proxies, >> not just cache implementations. >> 1. http://www.terena.nl/conf/wcw/Proceedings/S4/S4-3.pdf >> 2. http://rfc2616.x42.com/ - Section 14.9.5 >> 3. http://rfc3238.x42.com/ >> On Friday, April 19, 2002, at 02:08 PM, Oskar Batuner wrote: >>> I think Cache-Control headers and related response codes should be >>> applied >>> exactly to the subject they claim - cache control. The extended use >>> of HTTP >>> as a base protocol results in temptation to overload semantics of >>> existing >>> headers. Mark Nottingham pointed one example of such overload about a >>> year >>> ago (forgive me if I'm wrong with dates). Mark has posted a document >>> explaining why use of cache control headers is bad in origin-surrogate >>> context: semantic roles of HTTP client and server are different from >>> the >>> surrogate-origin server case - they have a special trust >>> relationship, and >>> cache control part of HTTP should better be preserved to manage >>> downstream >>> caches. >>> >>> The same approach should be taken for the callout protocol. The proxy >>> that >>> is running OPES rules serves as a callout gateway. According to the >>> OPES >>> intentions and IAB guidelines it has an explicit permission to perform >>> certain actions - that is, special relationship with either origin >>> server or >>> the end user. Cache control directives should be preserved for caches >>> that >>> may occur between OPES gateway and end user - otherwise there is no >>> mechanism left for content producer to control intimidate cache >>> behavior. >>> Callout participants and callout protocol SHOULD NOT try to interpret >>> such >>> directives. >>> >>> One additional implication is that in some scenarios OPES server (and >>> implicitly OPES gateway) may act as an authorized surrogate content >>> producer. In this scenario cache control directives MAY by altered to >>> reflect the changed content semantics. The way to handle them was >>> very well >>> described in Mark's document mentioned above. I do not remember what >>> happened to it, I'm afraid it just expired as a draft. Again, sorry >>> if I'm >>> wrong. Mark MAY shed more light on the fate of this document. >>> >>> - Oskar >>> >>>> -----Original Message----- >>>> From: owner-ietf-openproxy@mail.imc.org >>>> [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of Markus Hofmann >>>> Sent: Tuesday, April 16, 2002 2:34 PM >>>> To: Mark Nottingham >>>> Cc: ietf-openproxy@imc.org; LMM@acm.org >>>> Subject: Re: no-transform & Warning >>>> >>>> >>>> >>>> Mark Nottingham wrote: >>>> >>>>> I was talking about placing a requirement on the OPES server >>>>> implmentation, not the callout protocol itself. I.e., the protocol >>>>> can >>>>> be agnostic, but the thing that stuffs HTTP messages into it had >>>>> better >>>>> understand the semantics of HTTP. >>>> >>>> >>>> Yup, this I agree with, building the application semantic around a >>>> generic protocol, rather than building it into the protocol itself. >>>> It >>>> was not clear to me whether people thought of making the callout >>>> protocol itself aware of the encapsulated application protocol. >>>> >>>> -Markus >>>> >>> >>> >> -- Mark Nottingham >> http://www.mnot.net/ > > > -- Mark Nottingham http://www.mnot.net/ From owner-ietf-openproxy@mail.imc.org Sat Apr 20 15:14:14 2002 Received: from above.proper.com (back.imc.org [208.184.76.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06212 for ; Sat, 20 Apr 2002 15:14:13 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3KIJb801532 for ietf-openproxy-bks; Sat, 20 Apr 2002 11:19:37 -0700 (PDT) Received: from mgr1.xmission.com (mgr1.xmission.com [198.60.22.201]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3KIJa301528 for ; Sat, 20 Apr 2002 11:19:36 -0700 (PDT) Received: from [198.60.22.22] (helo=mail.xmission.com) by mgr1.xmission.com with esmtp (Exim 3.22 #1) id 16yzSO-000549-00 for ietf-openproxy@imc.org; Sat, 20 Apr 2002 12:19:32 -0600 Received: from [166.70.13.6] (helo=alum.mit.edu) by mail.xmission.com with esmtp (Exim 3.22 #1) id 16yzSM-0003T2-00 for ietf-openproxy@imc.org; Sat, 20 Apr 2002 12:19:31 -0600 Message-ID: <3CC1AB0E.60105@alum.mit.edu> Date: Sat, 20 Apr 2002 11:53:18 -0600 From: "The Purple Streak (Hilarie Orman)" User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: ietf-openproxy@imc.org Subject: Re: no-transform & Warning References: <674B6E43-5400-11D6-A8C1-000A27836A68@mnot.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 The message thread states that no-transform can be safely ignored is there is an "implicit contract", but it cannot be ignored safely if there is a ruleset explicitly stating that it can be ignored. That's what I was taking issue with. Hilarie Mark Nottingham wrote: > > I'd characterise CC: no-transform as an explicit directive, not as an > implicit contract. Or are you saying that HTTP itself is an implicit > contract? > > > On Friday, April 19, 2002, at 05:03 PM, The Purple Streak (Hilarie > Orman) wrote: > >> >> I don't see why a ruleset is less reliable than an implicit contract. >> >> Hilarie >> >> Mark Nottingham wrote: >> >>> I think Oskar is referring to [1]. >>> I agree that in a surrogate (gateway) scenario, where there is an >>> out-of band contract regarding message handling between the origin >>> and the intermediary, Cache-Control: no-transform in a request, as >>> well as the generation of transform-related Warnings, can be safely >>> ignored (if both parties desire that behavior, of course). >>> However, a proxy is a different kettle of fish; to be HTTP compliant, >>> proxies encountering no-transform "MUST NOT change any aspect of the >>> entity-body that is specified by these headers, including the value >>> of the entity-body itself." [2] I'd argue that even a proxy with an >>> OPES ruleset from whoever's driving the User-Agent can't ignore this >>> requirement; it places too much trust in what is often a heuristic - >>> the ruleset - at the expense of directly associated, declared >>> information to the contrary. >>> Looking at the IAB "considerations" for OPES [3], it seems that >>> no-transform and Warning make significant inroads into the >>> requirement to be non-blocking, as well as that for notification. I >>> can think of no better way to allow clients to specify that a message >>> should not be transformed, as well as notify them that an entity has >>> been changed; using an already-specified mechanism assures that at >>> least theoretically, OPES-ignorant HTTP implementations can still >>> interoperate with OPES intermediaries. >>> Regarding the scope of "Cache-Control", "cache" isn't used with great >>> precision in this part (and perhaps some others) of 2616; the >>> language [2] clearly scopes no-transform as applying to caches *and* >>> proxies, not just cache implementations. >>> 1. http://www.terena.nl/conf/wcw/Proceedings/S4/S4-3.pdf >>> 2. http://rfc2616.x42.com/ - Section 14.9.5 >>> 3. http://rfc3238.x42.com/ >>> On Friday, April 19, 2002, at 02:08 PM, Oskar Batuner wrote: >>> >>>> I think Cache-Control headers and related response codes should be >>>> applied >>>> exactly to the subject they claim - cache control. The extended use >>>> of HTTP >>>> as a base protocol results in temptation to overload semantics of >>>> existing >>>> headers. Mark Nottingham pointed one example of such overload about >>>> a year >>>> ago (forgive me if I'm wrong with dates). Mark has posted a document >>>> explaining why use of cache control headers is bad in origin-surrogate >>>> context: semantic roles of HTTP client and server are different from >>>> the >>>> surrogate-origin server case - they have a special trust >>>> relationship, and >>>> cache control part of HTTP should better be preserved to manage >>>> downstream >>>> caches. >>>> >>>> The same approach should be taken for the callout protocol. The >>>> proxy that >>>> is running OPES rules serves as a callout gateway. According to the >>>> OPES >>>> intentions and IAB guidelines it has an explicit permission to perform >>>> certain actions - that is, special relationship with either origin >>>> server or >>>> the end user. Cache control directives should be preserved for >>>> caches that >>>> may occur between OPES gateway and end user - otherwise there is no >>>> mechanism left for content producer to control intimidate cache >>>> behavior. >>>> Callout participants and callout protocol SHOULD NOT try to >>>> interpret such >>>> directives. >>>> >>>> One additional implication is that in some scenarios OPES server (and >>>> implicitly OPES gateway) may act as an authorized surrogate content >>>> producer. In this scenario cache control directives MAY by altered to >>>> reflect the changed content semantics. The way to handle them was >>>> very well >>>> described in Mark's document mentioned above. I do not remember what >>>> happened to it, I'm afraid it just expired as a draft. Again, sorry >>>> if I'm >>>> wrong. Mark MAY shed more light on the fate of this document. >>>> >>>> - Oskar >>>> >>>>> -----Original Message----- >>>>> From: owner-ietf-openproxy@mail.imc.org >>>>> [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of Markus Hofmann >>>>> Sent: Tuesday, April 16, 2002 2:34 PM >>>>> To: Mark Nottingham >>>>> Cc: ietf-openproxy@imc.org; LMM@acm.org >>>>> Subject: Re: no-transform & Warning >>>>> >>>>> >>>>> >>>>> Mark Nottingham wrote: >>>>> >>>>>> I was talking about placing a requirement on the OPES server >>>>>> implmentation, not the callout protocol itself. I.e., the protocol >>>>>> can >>>>>> be agnostic, but the thing that stuffs HTTP messages into it had >>>>>> better >>>>>> understand the semantics of HTTP. >>>>> >>>>> >>>>> >>>>> Yup, this I agree with, building the application semantic around a >>>>> generic protocol, rather than building it into the protocol itself. It >>>>> was not clear to me whether people thought of making the callout >>>>> protocol itself aware of the encapsulated application protocol. >>>>> >>>>> -Markus >>>>> >>>> >>>> >>> -- Mark Nottingham >>> http://www.mnot.net/ >> >> >> >> > -- > Mark Nottingham > http://www.mnot.net/ > > > From owner-ietf-openproxy@mail.imc.org Mon Apr 22 12:20:58 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01139 for ; Mon, 22 Apr 2002 12:20:57 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3MFjNi18337 for ietf-openproxy-bks; Mon, 22 Apr 2002 08:45:23 -0700 (PDT) Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3MFjMa18333 for ; Mon, 22 Apr 2002 08:45:22 -0700 (PDT) Received: from oskar3 ([65.96.167.167]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020422154519.XRAB12144.rwcrmhc53.attbi.com@oskar3>; Mon, 22 Apr 2002 15:45:19 +0000 From: "Oskar Batuner" To: "Mark Nottingham" , "The Purple Streak \(Hilarie Orman\)" Cc: "Markus Hofmann" , , Subject: RE: no-transform & Warning Date: Mon, 22 Apr 2002 11:45:18 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <674B6E43-5400-11D6-A8C1-000A27836A68@mnot.net> Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Again, for me this comes to the semantic overload: CC is an explicit Cache Control directive. As such it has nothing to do with OPES gateway behavior. I agree that it may me useful to have a directive(s) for explicit per-message control of OPES gateway, but we should not try to use existing HTTP headers - this is a semantics overload (in the sense of C++ class member operators overload). For this particular operation (non-transform) our discussion looks like pure academic - I am not aware of wide (or in fact any) use of this header or 214 response. This leads to the temptation to use the existing directive instead of introducing a new one. But a)this is not a good practice (IMHO); b) consider future development. If I understand correctly here we are not looking at callout protocol itself - this kind of directive should be interpreted by the application protocol gateway, not callout server. We may need other directives to control gateway behavior. Adding additional fields to Cache-Control header does not look a good idea for extensions. For OPES gateway control we need an additional header (x-opes-control). Use of CC just for one purpose creates a "legacy branch" in a brand new protocol. To summarize the issues: 1. Problems related to the application protocol interaction with gateways should be considered separately from callout protocol used by gateway to tunnel the request to the callout server. 2. We may need a set of directives to control a gateway included in the application protocol. These directives are especially useful to control per-message gateway behavior. 3. As a separate issue - while transport features of callout protocol may be application-protocol agnostic, semantics of callout protocol and server may need application protocol awareness. HTTP has some headers (like Accept-Encoding, Accept-Language, Content-Language, Content-Encoding, Content-Type, etc.) that define message properties essential for some types of server processing. - Oskar > -----Original Message----- > From: owner-ietf-openproxy@mail.imc.org > [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of Mark Nottingham > Sent: Friday, April 19, 2002 9:46 PM > To: The Purple Streak (Hilarie Orman) > Cc: Oskar Batuner; Markus Hofmann; ietf-openproxy@imc.org; LMM@acm.org > Subject: Re: no-transform & Warning > > > > > I'd characterise CC: no-transform as an explicit directive, not as an > implicit contract. Or are you saying that HTTP itself is an implicit > contract? > > > On Friday, April 19, 2002, at 05:03 PM, The Purple Streak (Hilarie > Orman) wrote: > > > > > I don't see why a ruleset is less reliable than an implicit contract. > > > > Hilarie > > > > Mark Nottingham wrote: > > > >> I think Oskar is referring to [1]. > >> I agree that in a surrogate (gateway) scenario, where there is an > >> out-of band contract regarding message handling between the origin and > >> the intermediary, Cache-Control: no-transform in a request, as well as > >> the generation of transform-related Warnings, can be safely ignored > >> (if both parties desire that behavior, of course). > >> However, a proxy is a different kettle of fish; to be HTTP compliant, > >> proxies encountering no-transform "MUST NOT change any aspect of the > >> entity-body that is specified by these headers, including the value of > >> the entity-body itself." [2] I'd argue that even a proxy with an OPES > >> ruleset from whoever's driving the User-Agent can't ignore this > >> requirement; it places too much trust in what is often a heuristic - > >> the ruleset - at the expense of directly associated, declared > >> information to the contrary. > >> Looking at the IAB "considerations" for OPES [3], it seems that > >> no-transform and Warning make significant inroads into the requirement > >> to be non-blocking, as well as that for notification. I can think of > >> no better way to allow clients to specify that a message should not be > >> transformed, as well as notify them that an entity has been changed; > >> using an already-specified mechanism assures that at least > >> theoretically, OPES-ignorant HTTP implementations can still > >> interoperate with OPES intermediaries. > >> Regarding the scope of "Cache-Control", "cache" isn't used with great > >> precision in this part (and perhaps some others) of 2616; the language > >> [2] clearly scopes no-transform as applying to caches *and* proxies, > >> not just cache implementations. > >> 1. http://www.terena.nl/conf/wcw/Proceedings/S4/S4-3.pdf > >> 2. http://rfc2616.x42.com/ - Section 14.9.5 > >> 3. http://rfc3238.x42.com/ > >> On Friday, April 19, 2002, at 02:08 PM, Oskar Batuner wrote: > >>> I think Cache-Control headers and related response codes should be > >>> applied > >>> exactly to the subject they claim - cache control. The extended use > >>> of HTTP > >>> as a base protocol results in temptation to overload semantics of > >>> existing > >>> headers. Mark Nottingham pointed one example of such overload about a > >>> year > >>> ago (forgive me if I'm wrong with dates). Mark has posted a document > >>> explaining why use of cache control headers is bad in origin-surrogate > >>> context: semantic roles of HTTP client and server are different from > >>> the > >>> surrogate-origin server case - they have a special trust > >>> relationship, and > >>> cache control part of HTTP should better be preserved to manage > >>> downstream > >>> caches. > >>> > >>> The same approach should be taken for the callout protocol. The proxy > >>> that > >>> is running OPES rules serves as a callout gateway. According to the > >>> OPES > >>> intentions and IAB guidelines it has an explicit permission to perform > >>> certain actions - that is, special relationship with either origin > >>> server or > >>> the end user. Cache control directives should be preserved for caches > >>> that > >>> may occur between OPES gateway and end user - otherwise there is no > >>> mechanism left for content producer to control intimidate cache > >>> behavior. > >>> Callout participants and callout protocol SHOULD NOT try to interpret > >>> such > >>> directives. > >>> > >>> One additional implication is that in some scenarios OPES server (and > >>> implicitly OPES gateway) may act as an authorized surrogate content > >>> producer. In this scenario cache control directives MAY by altered to > >>> reflect the changed content semantics. The way to handle them was > >>> very well > >>> described in Mark's document mentioned above. I do not remember what > >>> happened to it, I'm afraid it just expired as a draft. Again, sorry > >>> if I'm > >>> wrong. Mark MAY shed more light on the fate of this document. > >>> > >>> - Oskar > >>> > >>>> -----Original Message----- > >>>> From: owner-ietf-openproxy@mail.imc.org > >>>> [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of Markus Hofmann > >>>> Sent: Tuesday, April 16, 2002 2:34 PM > >>>> To: Mark Nottingham > >>>> Cc: ietf-openproxy@imc.org; LMM@acm.org > >>>> Subject: Re: no-transform & Warning > >>>> > >>>> > >>>> > >>>> Mark Nottingham wrote: > >>>> > >>>>> I was talking about placing a requirement on the OPES server > >>>>> implmentation, not the callout protocol itself. I.e., the protocol > >>>>> can > >>>>> be agnostic, but the thing that stuffs HTTP messages into it had > >>>>> better > >>>>> understand the semantics of HTTP. > >>>> > >>>> > >>>> Yup, this I agree with, building the application semantic around a > >>>> generic protocol, rather than building it into the protocol itself. > >>>> It > >>>> was not clear to me whether people thought of making the callout > >>>> protocol itself aware of the encapsulated application protocol. > >>>> > >>>> -Markus > >>>> > >>> > >>> > >> -- Mark Nottingham > >> http://www.mnot.net/ > > > > > > > -- > Mark Nottingham > http://www.mnot.net/ >