From owner-ietf-openproxy@mail.imc.org Tue Jul 1 03:09:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00608 for ; Tue, 1 Jul 2003 03:09:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XFDO-0000JP-00 for opes-archive@ietf.org; Tue, 01 Jul 2003 03:06:10 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19XFD8-0000Iw-00 for opes-archive@ietf.org; Tue, 01 Jul 2003 03:05:54 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h616q9FK009010 for ; Mon, 30 Jun 2003 23:52:09 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h616q9cV009009 for ietf-openproxy-bks; Mon, 30 Jun 2003 23:52:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from wwsmtp.webwasher.com ([217.146.159.49]) by above.proper.com (8.12.9/8.12.8) with SMTP id h616q6FK008970 for ; Mon, 30 Jun 2003 23:52:07 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] id 0R05NNL5; 01 Jul 2003 08:52:02 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: The power of OCP Date: Tue, 1 Jul 2003 08:52:00 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D054F74@mail.webwasher.com> Thread-Topic: The power of OCP Thread-Index: AcM/ThEXhFspTS5nQQiHdBIU0QZl2wATmQVw From: "Martin Stecher" To: "OPES WG (E-Mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h616q8FK009000 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > > I do not think right now that exchanging this data or even > > negotiating on this will really change something. A processor may or > > may not have limitation for its data preservation capabilities. > > Preferences of the callout server will probably not change anything > > here. Callout servers may like to make intensive use from preserved > > data but be definition need to be prepared that the processor stops > > to preserve more data; it has to handle that anyway. No need for a > > special announcement I guess; it won't change the algorithm I guess. > > > > Am I missing something? Do you know of examples where exhanging of > > that information will make a difference? > > A translation service will not use any of the data. An ad banner > stripping service will use all but the prefix data. The virus filter > service will use all the data. Ideally, the processor should not keep > 5MB file to be translated but should keep the 5MB file being filtered. > How does the processor distinguish among these cases? Should the > processor assume that most data will be re-requested and preserve > aggressively until it receives a Wont-Use message? > Both examples will handle data chunk wise, the processor will already receive some response before having sent the majority of data. With Wont-Use and modp we have already mechanism in place to inform the processor that further data preservation may not be needed. But I think a processor should start to preserve data as good as it can before it receives a response. If you want to make a processor extra smart you may want to learn from transaction responses; if none uses the preserved data, it could stop copying it. Does this sound good enough for you or do you (still) think we need to negotiate preservation preferences before the first transaction starts? Martin From owner-ietf-openproxy@mail.imc.org Tue Jul 1 05:59:40 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04811 for ; Tue, 1 Jul 2003 05:59:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XHvI-0001jM-00 for opes-archive@ietf.org; Tue, 01 Jul 2003 05:59:41 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19XHv3-0001is-00 for opes-archive@ietf.org; Tue, 01 Jul 2003 05:59:25 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h619jGFK033742 for ; Tue, 1 Jul 2003 02:45:16 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h619jGlV033741 for ietf-openproxy-bks; Tue, 1 Jul 2003 02:45:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from wwsmtp.webwasher.com ([217.146.159.49]) by above.proper.com (8.12.9/8.12.8) with SMTP id h619jDFK033732 for ; Tue, 1 Jul 2003 02:45:14 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] id XLNE7IXP; 01 Jul 2003 11:39:50 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: NO messages Date: Tue, 1 Jul 2003 11:39:48 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D054F77@mail.webwasher.com> Thread-Topic: NO messages Thread-Index: AcM/T9J0ts3uEUmDTlKml6QUS83LCQAUj+UQ From: "Martin Stecher" To: "OPES WG (E-Mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h619jFFK033737 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > > > A possible solution would be to have a single HTTP profile > > > (that defines what HTTP message parts _can_ be exchanged) and > > > separately negotiate what services need what parts. Often a > > > service ID would define the list of parts and no extra negotiation > > > would be required. Would that work better from your point of view? > > > > That could work. Can you make a suggestion how this separate > > negotiation will look like? > > It could be the same as service "negotiation" now. For services that > imply a particular set of parts, the service ID is sufficient. For > other services, the part names will be listed as service parameters, > just like they are listed as profile parameters now. > > OCP does not have a mechanism to negotiate services, but one can > reject a Transaction Start (TS) or Create Service Group (SGC) message > by closing the transaction or connection. > I am confused. This seems that the processor has knowledge about the services' needs. I knows that some services imply a particular set of parts and that other services take those parts as parameters (maybe not accepting these by closing transaction or connection). If the processor knows already the details about needed parts it definitely knows also the profile that the service prefers. What sense do NO/NR message negotiation for profiles have then? I think that the OPES processor only has the service IDs that it shall apply at a given execution point. The technical negotatiation what and how data will be exchanged with the callout server for that service should be done within OCP. I think that NO/NR negotiation for profiles plus wanted meta data is good for that but it needs to be done per service. All what we need is an optional service parameter for NO messages. Martin From owner-ietf-openproxy@mail.imc.org Tue Jul 1 11:37:25 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04753 for ; Tue, 1 Jul 2003 11:37:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XNCB-0005kT-00 for opes-archive@ietf.org; Tue, 01 Jul 2003 11:37:27 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19XNBv-0005kG-00 for opes-archive@ietf.org; Tue, 01 Jul 2003 11:37:11 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61FNoFK060066 for ; Tue, 1 Jul 2003 08:23:50 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61FNnRa060065 for ietf-openproxy-bks; Tue, 1 Jul 2003 08:23:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61FNlFK060060 for ; Tue, 1 Jul 2003 08:23:48 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h61FNmDs028258; Tue, 1 Jul 2003 09:23:48 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h61FNmeS028257; Tue, 1 Jul 2003 09:23:48 -0600 (MDT) (envelope-from rousskov) Date: Tue, 1 Jul 2003 09:23:48 -0600 (MDT) From: Alex Rousskov To: "OPES WG (E-Mail)" Subject: RE: The power of OCP In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D054F74@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D054F74@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 1 Jul 2003, Martin Stecher wrote: > > > I do not think right now that exchanging this data or even > > > negotiating on this will really change something. A processor > > > may or may not have limitation for its data preservation > > > capabilities. Preferences of the callout server will probably > > > not change anything here. Callout servers may like to make > > > intensive use from preserved data but be definition need to be > > > prepared that the processor stops to preserve more data; it has > > > to handle that anyway. No need for a special announcement I > > > guess; it won't change the algorithm I guess. > > > > > > Am I missing something? Do you know of examples where exhanging > > > of that information will make a difference? > > > > A translation service will not use any of the data. An ad banner > > stripping service will use all but the prefix data. The virus > > filter service will use all the data. Ideally, the processor > > should not keep 5MB file to be translated but should keep the 5MB > > file being filtered. How does the processor distinguish among > > these cases? Should the processor assume that most data will be > > re-requested and preserve aggressively until it receives a > > Wont-Use message? > > > > Both examples will handle data chunk wise, the processor will > already receive some response before having sent the majority of > data. With Wont-Use and modp we have already mechanism in place to > inform the processor that further data preservation may not be > needed. But I think a processor should start to preserve data as > good as it can before it receives a response. If you want to make a > processor extra smart you may want to learn from transaction > responses; if none uses the preserved data, it could stop copying > it. > > Does this sound good enough for you or do you (still) think we need > to negotiate preservation preferences before the first transaction > starts? I did no mean to suggest that preservation preferences must be negotiated, I only meant to question whether they should be. You asked for an example where it may make a difference, and I tried to come up with one. My feeling is that implementations would want to negotiate preservation in some environments, especially when both the processor and the server are controlled/developed by the same entity. Clearly, one can optimize processor resources if there is a way for the server to tell the processor what exactly needs to be preserved. On the other hand, there may not be a simple generic way to do that. We can leave the issue unaddressed and hope that popular extensions (if any) would be documented/standardized. No changes are required until somebody insists on them. Alex. From owner-ietf-openproxy@mail.imc.org Tue Jul 1 12:04:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05700 for ; Tue, 1 Jul 2003 12:04:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XNbz-00060L-00 for opes-archive@ietf.org; Tue, 01 Jul 2003 12:04:07 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19XNbi-000607-00 for opes-archive@ietf.org; Tue, 01 Jul 2003 12:03:51 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61FqQFK065708 for ; Tue, 1 Jul 2003 08:52:26 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61FqQwn065707 for ietf-openproxy-bks; Tue, 1 Jul 2003 08:52:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61FqOFK065702 for ; Tue, 1 Jul 2003 08:52:24 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h61FqPDs028990; Tue, 1 Jul 2003 09:52:25 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h61FqP3B028989; Tue, 1 Jul 2003 09:52:25 -0600 (MDT) (envelope-from rousskov) Date: Tue, 1 Jul 2003 09:52:25 -0600 (MDT) From: Alex Rousskov To: "OPES WG (E-Mail)" Subject: RE: NO messages In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D054F77@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D054F77@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 1 Jul 2003, Martin Stecher wrote: > > > > A possible solution would be to have a single HTTP > > > > profile (that defines what HTTP message parts _can_ be > > > > exchanged) and separately negotiate what services need what > > > > parts. Often a service ID would define the list of parts and > > > > no extra negotiation would be required. Would that work better > > > > from your point of view? > > > > > > That could work. Can you make a suggestion how this separate > > > negotiation will look like? > > > > It could be the same as service "negotiation" now. For services > > that imply a particular set of parts, the service ID is > > sufficient. For other services, the part names will be listed as > > service parameters, just like they are listed as profile > > parameters now. > > > > OCP does not have a mechanism to negotiate services, but one can > > reject a Transaction Start (TS) or Create Service Group (SGC) > > message by closing the transaction or connection. > > > > I am confused. > > This seems that the processor has knowledge about the services' > needs. I knows that some services imply a particular set of parts > and that other services take those parts as parameters (maybe not > accepting these by closing transaction or connection). > > If the processor knows already the details about needed parts it > definitely knows also the profile that the service prefers. Yes. Parts are defined in the profile. One cannot know what parts are without the profile. The reverse is not necessarily true: it is possible to have a profile that does not define the exact set of required parts, only the set of possible parts, leaving the final choice up to the services/agents. > What sense do NO/NR message negotiation for profiles have then? Indeed. If X is known a priory, there is no need to negotiate X! The primary reason to have profile negotiation is to accommodate situations when the processor or the callout server support more than one profile. In that case, they have to agree on one profile to use. For example, a processor may support HTTP and MIME profiles while the server supports only MIME. They have to negotiate to find out. The secondary reason for negotiation is to confirm assumptions. For example, the processor may be configured to use HTTP profile and may be told (also via a configuration file) that the callout server supports HTTP profile. It may make sense to negotiate HTTP profile anyway just to make sure that configuration [still] works before exchanging any messages. This is simply to ease maintenance and debugging. My "services that imply a particular set of parts" phrase is misleading because while a service may imply parts, the processor may not be aware of that implication and may have to negotiate it. Like you say below, the processor may only be given an opaque service ID. > I think that the OPES processor only has the service IDs that it > shall apply at a given execution point. The technical negotatiation > what and how data will be exchanged with the callout server for that > service should be done within OCP. This is a typical scenario, yes. > I think that NO/NR negotiation for profiles plus wanted meta data is > good for that but it needs to be done per service. All what we need > is an optional service parameter for NO messages. Let's assume that "application profile" defines OCP extensions, including a set of valid message parts and data encodings. Are you saying that an application profile (e.g., HTTP) should be per-service rather than per-connection? If so, it would be difficult to introduce profile-specific OCP messages outside of the OCP transaction boundary (because outside of a transaction, the "current" service is not known). Which combination of options do you prefer: 1) Application profile is negotiated for connection 2) Application profile is negotiated for transaction x a) Exchanged message parts are negotiated for connection b) Exchanged message parts are negotiated for transaction Transaction above is synonymous with "service" or "service group". If we select (1b) or (2b), we would need to adjust the specs so that negotiations can be tied to a transaction/service. (1a) does not allow for service-dependent parts (2a) is not a valid combination (1b) is my preference (2b) makes OCP extensions that do not depend on a service difficult Do you prefer (1b)? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Wed Jul 2 05:41:36 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29832 for ; Wed, 2 Jul 2003 05:41:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xe7M-00002j-00 for opes-archive@ietf.org; Wed, 02 Jul 2003 05:41:36 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19Xe7L-00002f-00 for opes-archive@ietf.org; Wed, 02 Jul 2003 05:41:36 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h629RbFK039367 for ; Wed, 2 Jul 2003 02:27:37 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h629Rbbf039366 for ietf-openproxy-bks; Wed, 2 Jul 2003 02:27:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from debian3-smtp ([217.146.159.49]) by above.proper.com (8.12.9/8.12.8) with SMTP id h629RVFK039320 for ; Wed, 2 Jul 2003 02:27:34 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] id 9IA7SZX1; 02 Jul 2003 13:30:18 +0200 Subject: RE: NO messages Date: Wed, 2 Jul 2003 11:23:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <75F7E67FC45F6744A7D328D41E35376D054F8A@mail.webwasher.com> content-class: urn:content-classes:message x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: NO messages Thread-Index: AcNAdEJ9i6dgZ/LASCyKoITldqJtCwAAdZqw From: "Martin Stecher" To: "OPES WG (E-Mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h629RaFK039356 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Which combination of options do you prefer: > > 1) Application profile is negotiated for connection > 2) Application profile is negotiated for transaction > x > a) Exchanged message parts are negotiated for connection > b) Exchanged message parts are negotiated for transaction > > Transaction above is synonymous with "service" or "service group". If > we select (1b) or (2b), we would need to adjust the specs so that > negotiations can be tied to a transaction/service. > > (1a) does not allow for service-dependent parts > (2a) is not a valid combination > (1b) is my preference > (2b) makes OCP extensions that do not depend on a service difficult > > Do you prefer (1b)? > (1b) makes much sense in many scenarios. Let me describe a scenario that might be typical. But I also have an example where it does not work. It will not be the normal case, so please have a look whether support of that example is important. 0. My previous example of an earlier message was not so good. An OPES processor will usually not offer HTTP/reqzest and HTTP/response profile at the same time. Makes not much sense on a certain decision point. 1. A typical example would be a callout server with two services that work on HTTP-responses. Service-1 needs the original HTTP request as meta data, Service-2 does not. Selecting HTTP profile for the connection and needed message parts for the transaction (combination 1b) works well here. 2. A not-so-typical example would be a callout server that works as a wrapping engine and home for other 3rd party service plugins. That means that the services are very different and support different OCP extensions (profiles). Without knowing which service(s) will be selected within a connection, the server cannot select the correct profile for the connection. If example 2 is not important, we can choose combination (1b). Else we may need to change something and I would start here: > Transaction above is synonymous with "service" or "service group" Actually service groups are created and destroyed outside of transactions and a single service ID can exist at any time. Currently, playing a NO/NR dialog implies that the selected profile in the NR message is selected and available featuer set switches (from OCP core to selected OCP extension). If we change this in a way that the agents negotiate the profile for a service or service group (outside of a transaction) without switching to that profile at the same time? For example: P: NO ({profile1},{profile1 featureX},{profile2}) Service: serviceA; S: NR {profile2}; P: NO ({profile1},{profile1 featureX},{profile2}) Service: serviceB; S: NR {profile1 featureX}; P: NO ({profile1},{profile1 featureX},{profile2}) Service-Group: 42; S: NR {profile1 featureX}; P: SwitchProfile {profile1 featureX}; P: TS 1 42; // start with transaction for service group 42 How do you think about that? Martin From owner-ietf-openproxy@mail.imc.org Wed Jul 2 10:51:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25728 for ; Wed, 2 Jul 2003 10:51:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xixh-0001VR-00 for opes-archive@ietf.org; Wed, 02 Jul 2003 10:51:57 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19Xixg-0001VO-00 for opes-archive@ietf.org; Wed, 02 Jul 2003 10:51:56 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62EfsFK061004 for ; Wed, 2 Jul 2003 07:41:54 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h62Efss0061003 for ietf-openproxy-bks; Wed, 2 Jul 2003 07:41:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62EfqFK060998 for ; Wed, 2 Jul 2003 07:41:53 -0700 (PDT) (envelope-from markus@mhof.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h62Efq9Y081493 for ; Wed, 2 Jul 2003 10:41:53 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h62Efk1u032285 for ; Wed, 2 Jul 2003 10:41:46 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h62EfjQ4015438 for ; Wed, 2 Jul 2003 10:41:46 -0400 (EDT) Message-ID: <3F02EF70.2020107@mhof.com> Date: Wed, 02 Jul 2003 10:42:56 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Agenda for OPES WG Meeting in Vienna Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi, below the current agenda for our WG meeting in Vienna. -Markus ------------------------------------------------------------------- Open Pluggable Edge Services WG (opes) ====================================== Tuesday, July 15, 0900-1130 CHAIR(S): Marshall Rose Markus Hofmann TECHNICAL ADVISOR(S): Allison Mankin Hilarie Orman AGENDA: - Introduction, minutes taker, blue sheets [5 min] - Agenda bashing [5 min] - Work on "Tracing/Bypass" document [A. Barbier, 20 min]] draft-ietf-opes-end-comm-00.txt - Work on callout protocol - Protocol Core [M. Stecher, 40 min] draft-ietf-opes-ocp-core-00.txt - HTTP adaptation with OPES [M. Stecher, 10 min] http://www.measurement-factory.com/ tmp/opes/snapshots/latest/http.html - Implementation effort [M. Stecher, 10 min] - Work on "IAB considerations" document [A. Barbier, 20 min] draft-ietf-opes-iab-00.txt From owner-ietf-openproxy@mail.imc.org Wed Jul 2 11:59:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28576 for ; Wed, 2 Jul 2003 11:59:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xk1Y-0002xJ-00 for opes-archive@ietf.org; Wed, 02 Jul 2003 12:00:01 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19Xk1Y-0002xC-00 for opes-archive@ietf.org; Wed, 02 Jul 2003 12:00:00 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62FdXFK066017 for ; Wed, 2 Jul 2003 08:39:33 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h62FdXZr066015 for ietf-openproxy-bks; Wed, 2 Jul 2003 08:39:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62FdVFK066006 for ; Wed, 2 Jul 2003 08:39:31 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h62FdWDs065086; Wed, 2 Jul 2003 09:39:32 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h62FdWAa065085; Wed, 2 Jul 2003 09:39:32 -0600 (MDT) (envelope-from rousskov) Date: Wed, 2 Jul 2003 09:39:31 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: RE: NO messages In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D054F8A@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D054F8A@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 2 Jul 2003, Martin Stecher wrote: > > 1) Application profile is negotiated for connection > > 2) Application profile is negotiated for transaction > > x > > a) Exchanged message parts are negotiated for connection > > b) Exchanged message parts are negotiated for transaction > > (1b) makes much sense in many scenarios. > Let me describe a scenario that might be typical. But I also have an > example where it does not work. It will not be the normal case, so > please have a look whether support of that example is important. > > 0. My previous example of an earlier message was not so good. An > OPES processor will usually not offer HTTP/reqzest and HTTP/response > profile at the same time. Makes not much sense on a certain decision > point. OK. This probably depends on the processor implementation and how it is integrated with the proxy. > 1. A typical example would be a callout server with two services > that work on HTTP-responses. Service-1 needs the original HTTP > request as meta data, Service-2 does not. Selecting HTTP profile for > the connection and needed message parts for the transaction > (combination 1b) works well here. > > 2. A not-so-typical example would be a callout server that works as > a wrapping engine and home for other 3rd party service plugins. That > means that the services are very different and support different OCP > extensions (profiles). Without knowing which service(s) will be > selected within a connection, the server cannot select the correct > profile for the connection. > > If example 2 is not important, we can choose combination (1b). Example #2 is how some web services work today, I guess. So it may be wise to support it. OPES adaptation is, by some definitions, a web service. > Else we may need to change something and I would start here: > > Transaction above is synonymous with "service" or "service group" > > Actually service groups are created and destroyed outside of > transactions and a single service ID can exist at any time. I know, that is why I mentioned that some modifications to the current negotiation and scoping mechanism would be required to tie profiles and services. > Currently, playing a NO/NR dialog implies that the selected profile > in the NR message is selected and available featuer set switches > (from OCP core to selected OCP extension). If we change this in a > way that the agents negotiate the profile for a service or service > group (outside of a transaction) without switching to that profile > at the same time? > > For example: > P: NO ({profile1},{profile1 featureX},{profile2}) > Service: serviceA; > S: NR {profile2}; > P: NO ({profile1},{profile1 featureX},{profile2}) > Service: serviceB; > S: NR {profile1 featureX}; > P: NO ({profile1},{profile1 featureX},{profile2}) > Service-Group: 42; > S: NR {profile1 featureX}; > P: SwitchProfile {profile1 featureX}; > P: TS 1 42; // start with transaction for service group 42 > > How do you think about that? There are two ways to support what you want: better profile scope management (your proposal above) and profile variables (similar to current service group variables). The scope approach means that you cannot have two concurrent transactions on the same connection using different profiles (or, at least, it would look awkward if SwitchProfile applies to the immediate TS only). The variable approach allows for concurrent transactions with different profiles at the increased risk of leaking variables and creating a DoS (allocating and not destroying "a lot of" variables as a result of a bug or on purpose). I suggest that we use the "variable" approach: P: NO ( service-feature1, service-feature2, ... ); S: NR service-feature2; P: TS 1 service-group-id2; Where "service-feature" is the following structure: { service-group-id service profile } Where "service-group-id" is an "sg-id:" UNI that can be used in TS messages if negotiation is successful. "Service" and "profile" are structures describing callout service and profile information (they are already defined in OCP). If you accept the above, I would also suggest that sg-id parameter of the Transaction Start (TS) message is made mandatory. This will allow agents to negotiate acceptable services before they are used in any transaction. As you can see, both proposals are similar. The only big difference is that the variable approach lacks the SwitchProfile message. Note that the variable approach does not allow to select a particular profile outside of the transaction scope. However, since OCP Core requires that unknown messages are ignored, it is still possible to customize exchange outside of transaction boundaries without losing interoperability. Will this approach work well, in your opinion? Alex. From owner-ietf-openproxy@mail.imc.org Wed Jul 2 15:11:25 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07396 for ; Wed, 2 Jul 2003 15:11:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xn0o-0005xw-00 for opes-archive@ietf.org; Wed, 02 Jul 2003 15:11:26 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19Xn0n-0005xp-00 for opes-archive@ietf.org; Wed, 02 Jul 2003 15:11:25 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62IwTFK078263 for ; Wed, 2 Jul 2003 11:58:29 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h62IwTLL078262 for ietf-openproxy-bks; Wed, 2 Jul 2003 11:58:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from debian3-smtp ([217.146.159.49]) by above.proper.com (8.12.9/8.12.8) with SMTP id h62IwQFK078253 for ; Wed, 2 Jul 2003 11:58:27 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] id YVE6N6DN; 02 Jul 2003 23:05:18 +0200 content-class: urn:content-classes:message Subject: RE: NO messages MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 2 Jul 2003 20:58:16 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D013F78@mail.webwasher.com> Thread-Topic: NO messages Thread-Index: AcNAsCQY/l07o9ZWRciONttx+wn7VAAGR2PA From: "Martin Stecher" To: "OPES WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h62IwSFK078258 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > There are two ways to support what you want: better profile scope > management (your proposal above) and profile variables (similar to > current service group variables). The scope approach means that you > cannot have two concurrent transactions on the same connection using > different profiles (or, at least, it would look awkward if > SwitchProfile applies to the immediate TS only). The variable approach > allows for concurrent transactions with different profiles at the > increased risk of leaking variables and creating a DoS (allocating and > not destroying "a lot of" variables as a result of a bug or on > purpose). > > I suggest that we use the "variable" approach: > > P: NO ( service-feature1, service-feature2, ... ); > S: NR service-feature2; > P: TS 1 service-group-id2; > > Where "service-feature" is the following structure: > > { service-group-id service profile } > > Where "service-group-id" is an "sg-id:" UNI that can be used in TS > messages if negotiation is successful. "Service" and "profile" are > structures describing callout service and profile information (they > are already defined in OCP). Service-Group-ID defines a list of services. What is then the extra service - the second element in the "service-feature" structure. BTW: When introducing this, we have the first incident of a nesting level > 1 - list of structures of structures > > If you accept the above, I would also suggest that sg-id parameter of > the Transaction Start (TS) message is made mandatory. This will allow > agents to negotiate acceptable services before they are used in any > transaction. I like the idea of binding a profile to a service group and binding it to a transaction. I also like that we make service groups mandantory and so remove the single profile parameter. It's good to have only one clear way to go, always create and use a service group even if you only have a single service to use. Let's make it so, if the objection below does not break the concept ;-) > > As you can see, both proposals are similar. The only big difference is > that the variable approach lacks the SwitchProfile message. > > Note that the variable approach does not allow to select a particular > profile outside of the transaction scope. However, since OCP Core > requires that unknown messages are ignored, it is still possible to > customize exchange outside of transaction boundaries without losing > interoperability. That may be insufficent. If an OCP extension defines new methods that are to be used in a new form of a dialog, one agent may send a request and waits for a response. If it is unclear whether that extension is supported, the agent does not know whether the other peer is still handling that request or ignored it. How long to wait for a response? Using a SwitchProfile message which is defined in the core will result in a connection end with error message if the selected profile is not supported. Maybe we can get around that extra message if the service-feature structure can also describe the global, connection-wide, non-service-bound case? As said above, I do not fully understand the proposed structure yet. Martin From owner-ietf-openproxy@mail.imc.org Wed Jul 2 15:51:26 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09896 for ; Wed, 2 Jul 2003 15:51:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XndX-0006XA-00 for opes-archive@ietf.org; Wed, 02 Jul 2003 15:51:27 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19XndW-0006X6-00 for opes-archive@ietf.org; Wed, 02 Jul 2003 15:51:26 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62JcqFK080600 for ; Wed, 2 Jul 2003 12:38:52 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h62Jcqcu080599 for ietf-openproxy-bks; Wed, 2 Jul 2003 12:38:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62JcnFK080588 for ; Wed, 2 Jul 2003 12:38:50 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h62Jco8d071768; Wed, 2 Jul 2003 13:38:50 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h62Jcoja071767; Wed, 2 Jul 2003 13:38:50 -0600 (MDT) (envelope-from rousskov) Date: Wed, 2 Jul 2003 13:38:50 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: RE: NO messages In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D013F78@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D013F78@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 2 Jul 2003, Martin Stecher wrote: > > I suggest that we use the "variable" approach: > > > > P: NO ( service-feature1, service-feature2, ... ); > > S: NR service-feature2; > > P: TS 1 service-group-id2; > > > > Where "service-feature" is the following structure: > > > > { service-group-id service profile } > > > > Where "service-group-id" is an "sg-id:" UNI that can be used in TS > > messages if negotiation is successful. "Service" and "profile" are > > structures describing callout service and profile information (they > > are already defined in OCP). > > Service-Group-ID defines a list of services. What is then the extra > service - the second element in the "service-feature" structure. Service-Group-ID is just a variable name. Alone, it does not define anything; it plays the same role as the current sg-id does, but it has to be a URI so that the receiver of NR message knows what is being negotiated (services, and not, say, transport encryption). Recall that negotiated features must be structures that start with a "feature ID" field. The "service" structure defines the service ID and service parameters, just like in the current spec. Same for the profile structure. The "service-feature" structure simply ties a feature and profile together and assigns them an ID (variable name). It is an assignment operator that may raise exceptions (failed negotiation), if you will. Does this clarify? One problem to fix would be the fact that the NR sender does not have a way of finding out whether the recipient (NO sender) is going to use the ID and for how long. It is not clear when an ID/variable can be discarded. I believe this problem can be easily solved though. > BTW: When introducing this, we have the first incident of a nesting > level > 1 - list of structures of structures I am not sure it is the first, but you may be right. As you know, I do not see that as a big deal from implementation point of view. In fact, enforcing any limit is extra work for the implementation (or, at least, for an implementations I can imagine). > I like the idea of binding a profile to a service group and binding > it to a transaction. I also like that we make service groups > mandantory and so remove the single profile parameter. It's good to > have only one clear way to go, always create and use a service group > even if you only have a single service to use. Let's make it so, if > the objection below does not break the concept ;-) > > Note that the variable approach does not allow to select a > > particular profile outside of the transaction scope. However, > > since OCP Core requires that unknown messages are ignored, it is > > still possible to customize exchange outside of transaction > > boundaries without losing interoperability. > > That may be insufficent. If an OCP extension defines new methods > that are to be used in a new form of a dialog, one agent may send a > request and waits for a response. If it is unclear whether that > extension is supported, the agent does not know whether the other > peer is still handling that request or ignored it. How long to wait > for a response? > > Using a SwitchProfile message which is defined in the core will > result in a connection end with error message if the selected > profile is not supported. > > Maybe we can get around that extra message if the service-feature > structure can also describe the global, connection-wide, > non-service-bound case? As said above, I do not fully understand the > proposed structure yet. Note that old-style feature negotiations still can be used. Not all negotiations have to be in the above form. Old-style negotiations still have connection scope (by default). For example, it is possible to do this: NO ( profileA ); NR profileA; ... profileA is active ... NO ( service-feature1, service-feature2, ...); NR service-feature2; ... profileA is active, profile2 available for xactions ... TS 1 service-feature-id2; ... profileA and profile2 are active ... TE 1; ... profileA is active, profile2 available for xactions ... Does this address your concerns? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Wed Jul 2 18:06:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22655 for ; Wed, 2 Jul 2003 18:05:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xpjl-0002XK-00 for opes-archive@ietf.org; Wed, 02 Jul 2003 18:06:01 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19Xpjk-0002XE-00 for opes-archive@ietf.org; Wed, 02 Jul 2003 18:06:00 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62LrAFK087386 for ; Wed, 2 Jul 2003 14:53:10 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h62LrAjp087385 for ietf-openproxy-bks; Wed, 2 Jul 2003 14:53:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from debian3-smtp ([217.146.159.49]) by above.proper.com (8.12.9/8.12.8) with SMTP id h62Lr8FK087361 for ; Wed, 2 Jul 2003 14:53:09 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] id 15T3ZJAX; 03 Jul 2003 02:00:06 +0200 content-class: urn:content-classes:message Subject: RE: NO messages MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 2 Jul 2003 23:53:05 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D013F7A@mail.webwasher.com> Thread-Topic: NO messages Thread-Index: AcNA0ZZy5unZbFS4QsSxfOLGH1+EaAAD1PjA From: "Martin Stecher" To: "OPES WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h62Lr9FK087379 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > > I suggest that we use the "variable" approach: > > > > > > P: NO ( service-feature1, service-feature2, ... ); > > > S: NR service-feature2; > > > P: TS 1 service-group-id2; > > > > > > Where "service-feature" is the following structure: > > > > > > { service-group-id service profile } > > > > > > Where "service-group-id" is an "sg-id:" UNI that can be used in TS > > > messages if negotiation is successful. "Service" and "profile" are > > > structures describing callout service and profile > information (they > > > are already defined in OCP). > > > > Service-Group-ID defines a list of services. What is then the extra > > service - the second element in the "service-feature" structure. > > Service-Group-ID is just a variable name. Alone, it does not define > anything; it plays the same role as the current sg-id does, but it has > to be a URI so that the receiver of NR message knows what is being > negotiated (services, and not, say, transport encryption). Recall that > negotiated features must be structures that start with a "feature ID" > field. > > The "service" structure defines the service ID and service parameters, > just like in the current spec. Same for the profile structure. > > The "service-feature" structure simply ties a feature and profile > together and assigns them an ID (variable name). It is an assignment > operator that may raise exceptions (failed negotiation), if you will. > > Does this clarify? Still not completly. Sorry, it may be too late over here ;-) First you defined "service-group-id" is an "sg-id:" UNI now you wrote "service-group-id" ... same role as ... sg-id, but it has to be a URI So what is it uni or URI? Until now sg-id is being used as an uni (number) within a SGC message, where a list of services is bound to that number identifier and that number can be used in a transaction. So far so good. Now I understand that NO with service-featureX structure defines a sg-id as uni or URI where a single service and profile are bound to. And we may introduce the problem of the lifespan of that sg-id. Is this correct. Please confirm or correct again (I may need an example with real values, sorry). If this is all true, wouldn't it be more natural to re-use the existing sg-id, i.e. first use SGC and already assign a LIST of services to an ID and then use that ID in the NO message to negotiate a profile that will be used with that list of services? That will solve the lifespan problem. [...] > > Note that old-style feature negotiations still can be used. Not all > negotiations have to be in the above form. Old-style negotiations > still have connection scope (by default). For example, it is possible > to do this: > [...] > > Does this address your concerns? Yes, thanks. That point is clear now. From owner-ietf-openproxy@mail.imc.org Wed Jul 2 19:12:31 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00050 for ; Wed, 2 Jul 2003 19:12:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xqm7-0004l3-00 for opes-archive@ietf.org; Wed, 02 Jul 2003 19:12:31 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19Xqm6-0004l0-00 for opes-archive@ietf.org; Wed, 02 Jul 2003 19:12:30 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62N3BFK090227 for ; Wed, 2 Jul 2003 16:03:11 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h62N3AvQ090226 for ietf-openproxy-bks; Wed, 2 Jul 2003 16:03:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62N39FK090221 for ; Wed, 2 Jul 2003 16:03:09 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h62N3B8d076737; Wed, 2 Jul 2003 17:03:11 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h62N3BiZ076736; Wed, 2 Jul 2003 17:03:11 -0600 (MDT) (envelope-from rousskov) Date: Wed, 2 Jul 2003 17:03:11 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: RE: NO messages In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D013F7A@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D013F7A@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 2 Jul 2003, Martin Stecher wrote: > Still not completly. > [ snip ] I am not going to clarify further because your understand was correct, and because your proposal below is better than my scheme. > If this is all true, wouldn't it be more natural to re-use the > existing sg-id, i.e. first use SGC and already assign a LIST of > services to an ID and then use that ID in the NO message to > negotiate a profile that will be used with that list of services? What you describe should work and will emphasize that there can be only one profile for a given transaction, even if there are many services. The scheme I proposed implied that each service within a Service Group could have its own profile, which may be true in theory, but will not work with OCP transactions (profile is application data/metadata format of a transaction, essentially; it cannot vary within a transaction). Your scheme seems to be better. So let's use your scheme: SGC sg-id (services); // as before NO ( profile1, profile2, profile3 ) // as before Service-Group: sg-id; // new parameter NR profile2; // as before ... TS 1 sg-id; // sg-id now required ... SGD sg-id; // as before The first message (SGC) creates a list of services to be defined/remembered under sg-id Uni identifier (no need for a URI again). The second two messages (NO/NR) negotiate a single profile for the defined group of services. If the server does not support a service in the list, this would be the best time to reject the offer. The Transaction Start (TS) message used negotiated service group by its ID. The group is eventually deleted using Service Group Delete message. This looks like a combination of the best ideas from your original proposal (with SwitchProfile command) and my initial reaction to it. Perhaps we are moving in the right direction. :-) Is this clear enough or still too messy? Anything else that is broken or needs to be added? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Thu Jul 3 10:43:27 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13851 for ; Thu, 3 Jul 2003 10:43:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y5J1-0007N4-00 for opes-archive@ietf.org; Thu, 03 Jul 2003 10:43:27 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19Y5J1-0007N0-00 for opes-archive@ietf.org; Thu, 03 Jul 2003 10:43:27 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63EURFK060064 for ; Thu, 3 Jul 2003 07:30:27 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63EUREN060063 for ietf-openproxy-bks; Thu, 3 Jul 2003 07:30:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from debian3-smtp ([217.146.159.49]) by above.proper.com (8.12.9/8.12.8) with SMTP id h63EUOFK060046 for ; Thu, 3 Jul 2003 07:30:25 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] id 7PKRSC8Q; 03 Jul 2003 18:37:16 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: NO messages x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 Date: Thu, 3 Jul 2003 16:30:14 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D054FB2@mail.webwasher.com> Thread-Topic: NO messages Thread-Index: AcNA7h452zP7BGZqReOq4MRHYPwh3QAfj55w From: "Martin Stecher" To: "OPES WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h63EUQFK060059 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > So let's use your scheme: > > SGC sg-id (services); // as before > > NO ( profile1, profile2, profile3 ) // as before > Service-Group: sg-id; // new parameter > > NR profile2; // as before > ... > TS 1 sg-id; // sg-id now required > ... > SGD sg-id; // as before > > The first message (SGC) creates a list of services to be > defined/remembered under sg-id Uni identifier (no need for a URI > again). The second two messages (NO/NR) negotiate a single profile for > the defined group of services. If the server does not support a > service in the list, this would be the best time to reject the offer. > The Transaction Start (TS) message used negotiated service group by > its ID. The group is eventually deleted using Service Group Delete > message. > > This looks like a combination of the best ideas from your original > proposal (with SwitchProfile command) and my initial reaction to it. > Perhaps we are moving in the right direction. :-) > > > Is this clear enough or still too messy? Anything else that is broken > or needs to be added? > Looks good. It is either it now or it is very close. Let's check for finetuning: 1. The sequence P:NO (profile1, profile2, profile3) Service-Group: sg-id; S:NR profile2; negotiates that profile2 will be used in transactions for sg-id. There is no direct switch to profile2 on the connection. P:NO (profile1, profile2, profile3) S:NR profile2; negotiates profile2 on a connection level independend of any service or tranaction. Switch to profile2 is implied with the response. We may want to make this more obvious by adding a parameter also to the NR message that acknolowledgs that there is no direct profile switch. 2. More NO-NR dialogs are introduced with this approach. If one agent wants to check for several service group profile after each other, it always needs to wait for a NR message before sending the next NO message. The rid parameter had been removed from NO/NR before. Do we need to add it again? Eventually we can combine 1 and 2 by making sg-id an anonymous parameter and let it play the role of rid. But is it good to have that functionality through a second and optional parameter of NO/NR? Not sure. What do you think? Martin From owner-ietf-openproxy@mail.imc.org Thu Jul 3 10:49:35 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14070 for ; Thu, 3 Jul 2003 10:49:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y5Ox-0007Se-00 for opes-archive@ietf.org; Thu, 03 Jul 2003 10:49:35 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19Y5Ow-0007Sb-00 for opes-archive@ietf.org; Thu, 03 Jul 2003 10:49:34 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63EbNFK060467 for ; Thu, 3 Jul 2003 07:37:23 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63EbNnP060466 for ietf-openproxy-bks; Thu, 3 Jul 2003 07:37:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mailhost.ens-lyon.fr (pluvier.ens-lyon.fr [140.77.167.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63EbLFK060461 for ; Thu, 3 Jul 2003 07:37:22 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: from oceanite.ens-lyon.fr ([140.77.1.22]) by mailhost.ens-lyon.fr with esmtp (Exim 3.35 #1 (Debian)) id 19Y5D7-0005Zn-00 for ; Thu, 03 Jul 2003 16:37:21 +0200 Received: by oceanite.ens-lyon.fr (Postfix, from userid 1502) id 57378320064; Thu, 3 Jul 2003 16:37:14 +0200 (CEST) Received: from mailhost.ens-lyon.fr (pluvier.ens-lyon.fr [140.77.167.5]) by oceanite.ens-lyon.fr (Postfix) with SMTP id 7D8C5320060 for ; Thu, 3 Jul 2003 16:37:13 +0200 (CEST) Received: from above.proper.com ([208.184.76.39]) by mailhost.ens-lyon.fr with smtp (Exim 3.35 #1 (Debian)) id 19Y5Cv-0005UE-00 for ; Thu, 03 Jul 2003 16:37:09 +0200 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63EURFK060064 for ; Thu, 3 Jul 2003 07:30:27 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63EUREN060063 for ietf-openproxy-bks; Thu, 3 Jul 2003 07:30:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from debian3-smtp ([217.146.159.49]) by above.proper.com (8.12.9/8.12.8) with SMTP id h63EUOFK060046 for ; Thu, 3 Jul 2003 07:30:25 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] id 7PKRSC8Q; 03 Jul 2003 18:37:16 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: NO messages x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 Date: Thu, 3 Jul 2003 16:30:14 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D054FB2@mail.webwasher.com> Thread-Topic: NO messages Thread-Index: AcNA7h452zP7BGZqReOq4MRHYPwh3QAfj55w From: "Martin Stecher" To: "OPES WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h63EUQFK060059 List-Archive: List-Unsubscribe: List-ID: X-Spam-Status: No, hits=-0.9 required=5.0 tests=QUOTED_EMAIL_TEXT,X_AUTH_WARNING version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Spam-Report: ---- Start SpamAssassin results -0.90 points, 5 required; * -0.4 -- Has a X-Authentication-Warning header * -0.5 -- BODY: Contains what looks like a quoted email text ---- End of SpamAssassin results Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > So let's use your scheme: > > SGC sg-id (services); // as before > > NO ( profile1, profile2, profile3 ) // as before > Service-Group: sg-id; // new parameter > > NR profile2; // as before > ... > TS 1 sg-id; // sg-id now required > ... > SGD sg-id; // as before > > The first message (SGC) creates a list of services to be > defined/remembered under sg-id Uni identifier (no need for a URI > again). The second two messages (NO/NR) negotiate a single profile for > the defined group of services. If the server does not support a > service in the list, this would be the best time to reject the offer. > The Transaction Start (TS) message used negotiated service group by > its ID. The group is eventually deleted using Service Group Delete > message. > > This looks like a combination of the best ideas from your original > proposal (with SwitchProfile command) and my initial reaction to it. > Perhaps we are moving in the right direction. :-) > > > Is this clear enough or still too messy? Anything else that is broken > or needs to be added? > Looks good. It is either it now or it is very close. Let's check for finetuning: 1. The sequence P:NO (profile1, profile2, profile3) Service-Group: sg-id; S:NR profile2; negotiates that profile2 will be used in transactions for sg-id. There is no direct switch to profile2 on the connection. P:NO (profile1, profile2, profile3) S:NR profile2; negotiates profile2 on a connection level independend of any service or tranaction. Switch to profile2 is implied with the response. We may want to make this more obvious by adding a parameter also to the NR message that acknolowledgs that there is no direct profile switch. 2. More NO-NR dialogs are introduced with this approach. If one agent wants to check for several service group profile after each other, it always needs to wait for a NR message before sending the next NO message. The rid parameter had been removed from NO/NR before. Do we need to add it again? Eventually we can combine 1 and 2 by making sg-id an anonymous parameter and let it play the role of rid. But is it good to have that functionality through a second and optional parameter of NO/NR? Not sure. What do you think? Martin From owner-ietf-openproxy@mail.imc.org Thu Jul 3 10:53:31 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14201 for ; Thu, 3 Jul 2003 10:53:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y5Sl-0007WB-00 for opes-archive@ietf.org; Thu, 03 Jul 2003 10:53:31 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19Y5Sk-0007W8-00 for opes-archive@ietf.org; Thu, 03 Jul 2003 10:53:31 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63EfDFK060606 for ; Thu, 3 Jul 2003 07:41:13 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63EfCii060605 for ietf-openproxy-bks; Thu, 3 Jul 2003 07:41:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mailhost.ens-lyon.fr (pluvier.ens-lyon.fr [140.77.167.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63EfBFK060600 for ; Thu, 3 Jul 2003 07:41:11 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: from oceanite.ens-lyon.fr ([140.77.1.22]) by mailhost.ens-lyon.fr with esmtp (Exim 3.35 #1 (Debian)) id 19Y5Gp-0000UE-00 for ; Thu, 03 Jul 2003 16:41:11 +0200 Received: by oceanite.ens-lyon.fr (Postfix, from userid 1502) id CCA68320060; Thu, 3 Jul 2003 16:41:09 +0200 (CEST) Received: from mailhost.ens-lyon.fr (pluvier.ens-lyon.fr [140.77.167.5]) by oceanite.ens-lyon.fr (Postfix) with SMTP id 97E4A320058 for ; Thu, 3 Jul 2003 16:41:09 +0200 (CEST) Received: from above.proper.com ([208.184.76.39]) by mailhost.ens-lyon.fr with smtp (Exim 3.35 #1 (Debian)) id 19Y5Gj-0000Th-00 for ; Thu, 03 Jul 2003 16:41:05 +0200 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63EbNFK060467 for ; Thu, 3 Jul 2003 07:37:23 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63EbNnP060466 for ietf-openproxy-bks; Thu, 3 Jul 2003 07:37:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mailhost.ens-lyon.fr (pluvier.ens-lyon.fr [140.77.167.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63EbLFK060461 for ; Thu, 3 Jul 2003 07:37:22 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: from oceanite.ens-lyon.fr ([140.77.1.22]) by mailhost.ens-lyon.fr with esmtp (Exim 3.35 #1 (Debian)) id 19Y5D7-0005Zn-00 for ; Thu, 03 Jul 2003 16:37:21 +0200 Received: by oceanite.ens-lyon.fr (Postfix, from userid 1502) id 57378320064; Thu, 3 Jul 2003 16:37:14 +0200 (CEST) Received: from mailhost.ens-lyon.fr (pluvier.ens-lyon.fr [140.77.167.5]) by oceanite.ens-lyon.fr (Postfix) with SMTP id 7D8C5320060 for ; Thu, 3 Jul 2003 16:37:13 +0200 (CEST) Received: from above.proper.com ([208.184.76.39]) by mailhost.ens-lyon.fr with smtp (Exim 3.35 #1 (Debian)) id 19Y5Cv-0005UE-00 for ; Thu, 03 Jul 2003 16:37:09 +0200 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63EURFK060064 for ; Thu, 3 Jul 2003 07:30:27 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63EUREN060063 for ietf-openproxy-bks; Thu, 3 Jul 2003 07:30:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from debian3-smtp ([217.146.159.49]) by above.proper.com (8.12.9/8.12.8) with SMTP id h63EUOFK060046 for ; Thu, 3 Jul 2003 07:30:25 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] id 7PKRSC8Q; 03 Jul 2003 18:37:16 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: NO messages x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 Date: Thu, 3 Jul 2003 16:30:14 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D054FB2@mail.webwasher.com> Thread-Topic: NO messages Thread-Index: AcNA7h452zP7BGZqReOq4MRHYPwh3QAfj55w From: "Martin Stecher" To: "OPES WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h63EUQFK060059 List-Archive: List-Unsubscribe: List-ID: List-Archive: List-Unsubscribe: List-ID: X-Spam-Status: No, hits=-0.9 required=5.0 tests=QUOTED_EMAIL_TEXT,X_AUTH_WARNING version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Spam-Report: ---- Start SpamAssassin results -0.90 points, 5 required; * -0.4 -- Has a X-Authentication-Warning header * -0.5 -- BODY: Contains what looks like a quoted email text ---- End of SpamAssassin results Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > So let's use your scheme: > > SGC sg-id (services); // as before > > NO ( profile1, profile2, profile3 ) // as before > Service-Group: sg-id; // new parameter > > NR profile2; // as before > ... > TS 1 sg-id; // sg-id now required > ... > SGD sg-id; // as before > > The first message (SGC) creates a list of services to be > defined/remembered under sg-id Uni identifier (no need for a URI > again). The second two messages (NO/NR) negotiate a single profile for > the defined group of services. If the server does not support a > service in the list, this would be the best time to reject the offer. > The Transaction Start (TS) message used negotiated service group by > its ID. The group is eventually deleted using Service Group Delete > message. > > This looks like a combination of the best ideas from your original > proposal (with SwitchProfile command) and my initial reaction to it. > Perhaps we are moving in the right direction. :-) > > > Is this clear enough or still too messy? Anything else that is broken > or needs to be added? > Looks good. It is either it now or it is very close. Let's check for finetuning: 1. The sequence P:NO (profile1, profile2, profile3) Service-Group: sg-id; S:NR profile2; negotiates that profile2 will be used in transactions for sg-id. There is no direct switch to profile2 on the connection. P:NO (profile1, profile2, profile3) S:NR profile2; negotiates profile2 on a connection level independend of any service or tranaction. Switch to profile2 is implied with the response. We may want to make this more obvious by adding a parameter also to the NR message that acknolowledgs that there is no direct profile switch. 2. More NO-NR dialogs are introduced with this approach. If one agent wants to check for several service group profile after each other, it always needs to wait for a NR message before sending the next NO message. The rid parameter had been removed from NO/NR before. Do we need to add it again? Eventually we can combine 1 and 2 by making sg-id an anonymous parameter and let it play the role of rid. But is it good to have that functionality through a second and optional parameter of NO/NR? Not sure. What do you think? Martin From owner-ietf-openproxy@mail.imc.org Thu Jul 3 11:24:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15324 for ; Thu, 3 Jul 2003 11:24:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y5xA-0000AQ-00 for opes-archive@ietf.org; Thu, 03 Jul 2003 11:24:56 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19Y5x9-0000AN-00 for opes-archive@ietf.org; Thu, 03 Jul 2003 11:24:55 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63FDMFK064919 for ; Thu, 3 Jul 2003 08:13:22 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63FDLCj064916 for ietf-openproxy-bks; Thu, 3 Jul 2003 08:13:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63FDJFK064901 for ; Thu, 3 Jul 2003 08:13:19 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h63FDK8d099820; Thu, 3 Jul 2003 09:13:20 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h63FDKCl099819; Thu, 3 Jul 2003 09:13:20 -0600 (MDT) (envelope-from rousskov) Date: Thu, 3 Jul 2003 09:13:20 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: RE: NO messages In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D054FB2@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D054FB2@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 3 Jul 2003, Martin Stecher wrote: > Looks good. It is either it now or it is very close. Let's check for > finetuning: > > 1. The sequence > P:NO (profile1, profile2, profile3) > Service-Group: sg-id; > S:NR profile2; > negotiates that profile2 will be used in transactions for sg-id. > There is no direct switch to profile2 on the connection. Correct. > P:NO (profile1, profile2, profile3) > S:NR profile2; > > negotiates profile2 on a connection level independend of any > service or tranaction. Switch to profile2 is implied with the > response. Correct. > We may want to make this more obvious by adding a parameter also > to the NR message that acknolowledgs that there is no direct > profile switch. I thought about doing that as well. Let's make Service-Group mandatory in the response. Semantically, it would mean that the responder understands that we are negotiating service group settings (other than that, there is no information in that parameter in NR). Let's also call the parameter SG since it is going to be used a lot. > 2. More NO-NR dialogs are introduced with this approach. If one > agent wants to check for several service group profile after each > other, it always needs to wait for a NR message before sending the > next NO message. In some cases, it is possible to do optimistic negotiation (sending offers without waiting for responses). We will need to document that somehow (provide an example?) but the current spec wording should allow for that. For example (each line represents a moment in time): Processor Server send NO#1 send NO#2 send NO#3 recv NO#1 send NO#4 send NR to NO#1 recv NR to NO#1 recv NO#2 send NO#5 send NR to NO#2 recv NR to NO#2 TS 1 sg-id from NO#5 recv NO#3 ... ... As you can see, there is ordering/matching of NO and NR messages, but there is no synchronization at all. Note that the first TS is also optimistic. It may be rejected by the server if NR to NO#5 is negative. If processor wants to play it safe, it can wait for the corresponding NR before starting a transaction using its sg-id. > The rid parameter had been removed from NO/NR before. Do we need > to add it again? It will not help because there can be only one negotiation taking place at any given time. This may seem like a contradiction to the optimistic negotiation statement above, but it is not. > Eventually we can combine 1 and 2 by making sg-id an anonymous > parameter and let it play the role of rid. But is it good to have > that functionality through a second and optional parameter of NO/NR? > Not sure. We should try to avoid semantic overloading in protocols. Moreover, I do not think rid helps here (see above). Does the availability of optimistic negotiation address your concerns? Alex. From owner-ietf-openproxy@mail.imc.org Thu Jul 3 11:28:15 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15447 for ; Thu, 3 Jul 2003 11:28:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y60O-0000CW-00 for opes-archive@ietf.org; Thu, 03 Jul 2003 11:28:16 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19Y60N-0000CS-00 for opes-archive@ietf.org; Thu, 03 Jul 2003 11:28:15 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63FJ6FK065179 for ; Thu, 3 Jul 2003 08:19:06 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63FJ6ES065178 for ietf-openproxy-bks; Thu, 3 Jul 2003 08:19:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mailhost.ens-lyon.fr (pluvier.ens-lyon.fr [140.77.167.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63FJ4FK065173 for ; Thu, 3 Jul 2003 08:19:04 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: from oceanite.ens-lyon.fr ([140.77.1.22]) by mailhost.ens-lyon.fr with esmtp (Exim 3.35 #1 (Debian)) id 19Y5rU-0003B1-00 for ; Thu, 03 Jul 2003 17:19:04 +0200 Received: by oceanite.ens-lyon.fr (Postfix, from userid 1502) id EB9BB32005F; Thu, 3 Jul 2003 17:19:02 +0200 (CEST) Received: from mailhost.ens-lyon.fr (pluvier.ens-lyon.fr [140.77.167.5]) by oceanite.ens-lyon.fr (Postfix) with SMTP id AFBA6320058 for ; Thu, 3 Jul 2003 17:19:02 +0200 (CEST) Received: from above.proper.com ([208.184.76.39]) by mailhost.ens-lyon.fr with smtp (Exim 3.35 #1 (Debian)) id 19Y5rO-00039p-00 for ; Thu, 03 Jul 2003 17:18:58 +0200 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63FDMFK064919 for ; Thu, 3 Jul 2003 08:13:22 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63FDLCj064916 for ietf-openproxy-bks; Thu, 3 Jul 2003 08:13:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63FDJFK064901 for ; Thu, 3 Jul 2003 08:13:19 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h63FDK8d099820; Thu, 3 Jul 2003 09:13:20 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h63FDKCl099819; Thu, 3 Jul 2003 09:13:20 -0600 (MDT) (envelope-from rousskov) Date: Thu, 3 Jul 2003 09:13:20 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: RE: NO messages In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D054FB2@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D054FB2@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Archive: List-Unsubscribe: List-ID: X-Spam-Status: No, hits=-2.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_PINE,X_AUTH_WARNING version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Spam-Report: ---- Start SpamAssassin results -2.90 points, 5 required; * -0.5 -- Has a valid-looking References header * 0.0 -- Message-Id indicates a non-spam MUA (Pine) * -0.5 -- Has a In-Reply-To header * -0.4 -- Has a X-Authentication-Warning header * -0.5 -- BODY: Contains what looks like an email attribution * -0.5 -- BODY: Contains what looks like a quoted email text * -0.5 -- Reply with quoted text ---- End of SpamAssassin results Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 3 Jul 2003, Martin Stecher wrote: > Looks good. It is either it now or it is very close. Let's check for > finetuning: > > 1. The sequence > P:NO (profile1, profile2, profile3) > Service-Group: sg-id; > S:NR profile2; > negotiates that profile2 will be used in transactions for sg-id. > There is no direct switch to profile2 on the connection. Correct. > P:NO (profile1, profile2, profile3) > S:NR profile2; > > negotiates profile2 on a connection level independend of any > service or tranaction. Switch to profile2 is implied with the > response. Correct. > We may want to make this more obvious by adding a parameter also > to the NR message that acknolowledgs that there is no direct > profile switch. I thought about doing that as well. Let's make Service-Group mandatory in the response. Semantically, it would mean that the responder understands that we are negotiating service group settings (other than that, there is no information in that parameter in NR). Let's also call the parameter SG since it is going to be used a lot. > 2. More NO-NR dialogs are introduced with this approach. If one > agent wants to check for several service group profile after each > other, it always needs to wait for a NR message before sending the > next NO message. In some cases, it is possible to do optimistic negotiation (sending offers without waiting for responses). We will need to document that somehow (provide an example?) but the current spec wording should allow for that. For example (each line represents a moment in time): Processor Server send NO#1 send NO#2 send NO#3 recv NO#1 send NO#4 send NR to NO#1 recv NR to NO#1 recv NO#2 send NO#5 send NR to NO#2 recv NR to NO#2 TS 1 sg-id from NO#5 recv NO#3 ... ... As you can see, there is ordering/matching of NO and NR messages, but there is no synchronization at all. Note that the first TS is also optimistic. It may be rejected by the server if NR to NO#5 is negative. If processor wants to play it safe, it can wait for the corresponding NR before starting a transaction using its sg-id. > The rid parameter had been removed from NO/NR before. Do we need > to add it again? It will not help because there can be only one negotiation taking place at any given time. This may seem like a contradiction to the optimistic negotiation statement above, but it is not. > Eventually we can combine 1 and 2 by making sg-id an anonymous > parameter and let it play the role of rid. But is it good to have > that functionality through a second and optional parameter of NO/NR? > Not sure. We should try to avoid semantic overloading in protocols. Moreover, I do not think rid helps here (see above). Does the availability of optimistic negotiation address your concerns? Alex. From owner-ietf-openproxy@mail.imc.org Thu Jul 3 11:33:13 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17035 for ; Thu, 3 Jul 2003 11:33:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y65C-0000Ng-00 for opes-archive@ietf.org; Thu, 03 Jul 2003 11:33:14 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19Y65B-0000NP-00 for opes-archive@ietf.org; Thu, 03 Jul 2003 11:33:13 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63FMhFK065345 for ; Thu, 3 Jul 2003 08:22:43 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63FMh3p065344 for ietf-openproxy-bks; Thu, 3 Jul 2003 08:22:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mailhost.ens-lyon.fr (pluvier.ens-lyon.fr [140.77.167.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63FMeFK065337 for ; Thu, 3 Jul 2003 08:22:40 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: from oceanite.ens-lyon.fr ([140.77.1.22]) by mailhost.ens-lyon.fr with esmtp (Exim 3.35 #1 (Debian)) id 19Y5uy-0003rj-00 for ; Thu, 03 Jul 2003 17:22:40 +0200 Received: by oceanite.ens-lyon.fr (Postfix, from userid 1502) id 48A7032005F; Thu, 3 Jul 2003 17:22:39 +0200 (CEST) Received: from mailhost.ens-lyon.fr (pluvier.ens-lyon.fr [140.77.167.5]) by oceanite.ens-lyon.fr (Postfix) with SMTP id 0BC51320058 for ; Thu, 3 Jul 2003 17:22:39 +0200 (CEST) Received: from above.proper.com ([208.184.76.39]) by mailhost.ens-lyon.fr with smtp (Exim 3.35 #1 (Debian)) id 19Y5uk-0003pk-00 for ; Thu, 03 Jul 2003 17:22:27 +0200 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63FJ6FK065179 for ; Thu, 3 Jul 2003 08:19:06 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63FJ6ES065178 for ietf-openproxy-bks; Thu, 3 Jul 2003 08:19:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mailhost.ens-lyon.fr (pluvier.ens-lyon.fr [140.77.167.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63FJ4FK065173 for ; Thu, 3 Jul 2003 08:19:04 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: from oceanite.ens-lyon.fr ([140.77.1.22]) by mailhost.ens-lyon.fr with esmtp (Exim 3.35 #1 (Debian)) id 19Y5rU-0003B1-00 for ; Thu, 03 Jul 2003 17:19:04 +0200 Received: by oceanite.ens-lyon.fr (Postfix, from userid 1502) id EB9BB32005F; Thu, 3 Jul 2003 17:19:02 +0200 (CEST) Received: from mailhost.ens-lyon.fr (pluvier.ens-lyon.fr [140.77.167.5]) by oceanite.ens-lyon.fr (Postfix) with SMTP id AFBA6320058 for ; Thu, 3 Jul 2003 17:19:02 +0200 (CEST) Received: from above.proper.com ([208.184.76.39]) by mailhost.ens-lyon.fr with smtp (Exim 3.35 #1 (Debian)) id 19Y5rO-00039p-00 for ; Thu, 03 Jul 2003 17:18:58 +0200 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63FDMFK064919 for ; Thu, 3 Jul 2003 08:13:22 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63FDLCj064916 for ietf-openproxy-bks; Thu, 3 Jul 2003 08:13:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63FDJFK064901 for ; Thu, 3 Jul 2003 08:13:19 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h63FDK8d099820; Thu, 3 Jul 2003 09:13:20 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h63FDKCl099819; Thu, 3 Jul 2003 09:13:20 -0600 (MDT) (envelope-from rousskov) Date: Thu, 3 Jul 2003 09:13:20 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: RE: NO messages In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D054FB2@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D054FB2@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Archive: List-Unsubscribe: List-ID: List-Archive: List-Unsubscribe: List-ID: X-Spam-Status: No, hits=-2.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_PINE,X_AUTH_WARNING version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Spam-Report: ---- Start SpamAssassin results -2.90 points, 5 required; * -0.5 -- Has a valid-looking References header * 0.0 -- Message-Id indicates a non-spam MUA (Pine) * -0.5 -- Has a In-Reply-To header * -0.4 -- Has a X-Authentication-Warning header * -0.5 -- BODY: Contains what looks like an email attribution * -0.5 -- BODY: Contains what looks like a quoted email text * -0.5 -- Reply with quoted text ---- End of SpamAssassin results Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 3 Jul 2003, Martin Stecher wrote: > Looks good. It is either it now or it is very close. Let's check for > finetuning: > > 1. The sequence > P:NO (profile1, profile2, profile3) > Service-Group: sg-id; > S:NR profile2; > negotiates that profile2 will be used in transactions for sg-id. > There is no direct switch to profile2 on the connection. Correct. > P:NO (profile1, profile2, profile3) > S:NR profile2; > > negotiates profile2 on a connection level independend of any > service or tranaction. Switch to profile2 is implied with the > response. Correct. > We may want to make this more obvious by adding a parameter also > to the NR message that acknolowledgs that there is no direct > profile switch. I thought about doing that as well. Let's make Service-Group mandatory in the response. Semantically, it would mean that the responder understands that we are negotiating service group settings (other than that, there is no information in that parameter in NR). Let's also call the parameter SG since it is going to be used a lot. > 2. More NO-NR dialogs are introduced with this approach. If one > agent wants to check for several service group profile after each > other, it always needs to wait for a NR message before sending the > next NO message. In some cases, it is possible to do optimistic negotiation (sending offers without waiting for responses). We will need to document that somehow (provide an example?) but the current spec wording should allow for that. For example (each line represents a moment in time): Processor Server send NO#1 send NO#2 send NO#3 recv NO#1 send NO#4 send NR to NO#1 recv NR to NO#1 recv NO#2 send NO#5 send NR to NO#2 recv NR to NO#2 TS 1 sg-id from NO#5 recv NO#3 ... ... As you can see, there is ordering/matching of NO and NR messages, but there is no synchronization at all. Note that the first TS is also optimistic. It may be rejected by the server if NR to NO#5 is negative. If processor wants to play it safe, it can wait for the corresponding NR before starting a transaction using its sg-id. > The rid parameter had been removed from NO/NR before. Do we need > to add it again? It will not help because there can be only one negotiation taking place at any given time. This may seem like a contradiction to the optimistic negotiation statement above, but it is not. > Eventually we can combine 1 and 2 by making sg-id an anonymous > parameter and let it play the role of rid. But is it good to have > that functionality through a second and optional parameter of NO/NR? > Not sure. We should try to avoid semantic overloading in protocols. Moreover, I do not think rid helps here (see above). Does the availability of optimistic negotiation address your concerns? Alex. From owner-ietf-openproxy@mail.imc.org Thu Jul 3 12:17:06 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20885 for ; Thu, 3 Jul 2003 12:17:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y6lf-0001jg-00 for opes-archive@ietf.org; Thu, 03 Jul 2003 12:17:07 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19Y6le-0001jd-00 for opes-archive@ietf.org; Thu, 03 Jul 2003 12:17:07 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63G1Uqt002638 for ; Thu, 3 Jul 2003 09:01:30 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63G1Ud7002637 for ietf-openproxy-bks; Thu, 3 Jul 2003 09:01:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from debian3-smtp ([217.146.159.49]) by above.proper.com (8.12.9/8.12.8) with SMTP id h63G1Rqt002586 for ; Thu, 3 Jul 2003 09:01:28 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] id AH8MLVML; 03 Jul 2003 20:08:17 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: NO messages x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 Date: Thu, 3 Jul 2003 18:01:16 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D054FB7@mail.webwasher.com> Thread-Topic: NO messages Thread-Index: AcNBdaX9VzboZ7HDQzKGWy+22X/idwABhPYg From: "Martin Stecher" To: "OPES WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h63G1Tqt002629 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Great. We have it, I guess. Summary: - NO and NR have optional named parameter SG, which has an uni value sg-id - sg-id was previously created by SGC - If NR is sent in response to NO with SG parameter, NR also needs the same SG parameter - TS has mandantory sg-id anonymous parameter; the optional "service" parameter will go away Regards Martin > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Thursday, July 03, 2003 5:13 PM > To: OPES WG > Subject: RE: NO messages > > > > On Thu, 3 Jul 2003, Martin Stecher wrote: > > > Looks good. It is either it now or it is very close. Let's check for > > finetuning: > > > > 1. The sequence > > P:NO (profile1, profile2, profile3) > > Service-Group: sg-id; > > S:NR profile2; > > negotiates that profile2 will be used in transactions for sg-id. > > There is no direct switch to profile2 on the connection. > > Correct. > > > P:NO (profile1, profile2, profile3) > > S:NR profile2; > > > > negotiates profile2 on a connection level independend of any > > service or tranaction. Switch to profile2 is implied with the > > response. > > Correct. > > > We may want to make this more obvious by adding a parameter also > > to the NR message that acknolowledgs that there is no direct > > profile switch. > > I thought about doing that as well. Let's make Service-Group mandatory > in the response. Semantically, it would mean that the responder > understands that we are negotiating service group settings (other than > that, there is no information in that parameter in NR). > > Let's also call the parameter SG since it is going to be used a lot. > > > 2. More NO-NR dialogs are introduced with this approach. If one > > agent wants to check for several service group profile after each > > other, it always needs to wait for a NR message before sending the > > next NO message. > > In some cases, it is possible to do optimistic negotiation (sending > offers without waiting for responses). We will need to document that > somehow (provide an example?) but the current spec wording should > allow for that. > > For example (each line represents a moment in time): > > Processor Server > send NO#1 > send NO#2 > send NO#3 recv NO#1 > send NO#4 send NR to NO#1 > recv NR to NO#1 recv NO#2 > send NO#5 send NR to NO#2 > recv NR to NO#2 > TS 1 sg-id from NO#5 recv NO#3 > ... ... > > As you can see, there is ordering/matching of NO and NR messages, but > there is no synchronization at all. > > Note that the first TS is also optimistic. It may be rejected by the > server if NR to NO#5 is negative. If processor wants to play it safe, > it can wait for the corresponding NR before starting a transaction > using its sg-id. > > > The rid parameter had been removed from NO/NR before. Do we need > > to add it again? > > It will not help because there can be only one negotiation taking > place at any given time. This may seem like a contradiction to the > optimistic negotiation statement above, but it is not. > > > Eventually we can combine 1 and 2 by making sg-id an anonymous > > parameter and let it play the role of rid. But is it good to have > > that functionality through a second and optional parameter of NO/NR? > > Not sure. > > We should try to avoid semantic overloading in protocols. Moreover, I > do not think rid helps here (see above). Does the availability of > optimistic negotiation address your concerns? > > Alex. > > ------------------------------------------------------------ > This mail has been scanned by debian3-smtp > (WebWasher 4.4 fcs Build 556) > ------------------------------------------------------------ > From owner-ietf-openproxy@mail.imc.org Thu Jul 3 12:23:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21491 for ; Thu, 3 Jul 2003 12:23:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y6sJ-0001wS-00 for opes-archive@ietf.org; Thu, 03 Jul 2003 12:23:59 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19Y6sG-0001w7-00 for opes-archive@ietf.org; Thu, 03 Jul 2003 12:23:57 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63GBHqt003725 for ; Thu, 3 Jul 2003 09:11:17 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63GBHeo003723 for ietf-openproxy-bks; Thu, 3 Jul 2003 09:11:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mailhost.ens-lyon.fr (pluvier.ens-lyon.fr [140.77.167.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63GBFqt003702 for ; Thu, 3 Jul 2003 09:11:15 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: from oceanite.ens-lyon.fr ([140.77.1.22]) by mailhost.ens-lyon.fr with esmtp (Exim 3.35 #1 (Debian)) id 19Y6fx-0001ns-00 for ; Thu, 03 Jul 2003 18:11:13 +0200 Received: by oceanite.ens-lyon.fr (Postfix, from userid 1502) id 535DC32005F; Thu, 3 Jul 2003 18:11:11 +0200 (CEST) Received: from mailhost.ens-lyon.fr (pluvier.ens-lyon.fr [140.77.167.5]) by oceanite.ens-lyon.fr (Postfix) with SMTP id 16732320058 for ; Thu, 3 Jul 2003 18:11:11 +0200 (CEST) Received: from above.proper.com ([208.184.76.39]) by mailhost.ens-lyon.fr with smtp (Exim 3.35 #1 (Debian)) id 19Y6fr-0001eG-00 for ; Thu, 03 Jul 2003 18:11:07 +0200 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63G1Uqt002638 for ; Thu, 3 Jul 2003 09:01:30 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63G1Ud7002637 for ietf-openproxy-bks; Thu, 3 Jul 2003 09:01:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from debian3-smtp ([217.146.159.49]) by above.proper.com (8.12.9/8.12.8) with SMTP id h63G1Rqt002586 for ; Thu, 3 Jul 2003 09:01:28 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] id AH8MLVML; 03 Jul 2003 20:08:17 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: NO messages x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 Date: Thu, 3 Jul 2003 18:01:16 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D054FB7@mail.webwasher.com> Thread-Topic: NO messages Thread-Index: AcNBdaX9VzboZ7HDQzKGWy+22X/idwABhPYg From: "Martin Stecher" To: "OPES WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h63G1Tqt002629 List-Archive: List-Unsubscribe: List-ID: X-Spam-Status: No, hits=-0.9 required=5.0 tests=QUOTED_EMAIL_TEXT,X_AUTH_WARNING version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Spam-Report: ---- Start SpamAssassin results -0.90 points, 5 required; * -0.4 -- Has a X-Authentication-Warning header * -0.5 -- BODY: Contains what looks like a quoted email text ---- End of SpamAssassin results Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Great. We have it, I guess. Summary: - NO and NR have optional named parameter SG, which has an uni value sg-id - sg-id was previously created by SGC - If NR is sent in response to NO with SG parameter, NR also needs the same SG parameter - TS has mandantory sg-id anonymous parameter; the optional "service" parameter will go away Regards Martin > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Thursday, July 03, 2003 5:13 PM > To: OPES WG > Subject: RE: NO messages > > > > On Thu, 3 Jul 2003, Martin Stecher wrote: > > > Looks good. It is either it now or it is very close. Let's check for > > finetuning: > > > > 1. The sequence > > P:NO (profile1, profile2, profile3) > > Service-Group: sg-id; > > S:NR profile2; > > negotiates that profile2 will be used in transactions for sg-id. > > There is no direct switch to profile2 on the connection. > > Correct. > > > P:NO (profile1, profile2, profile3) > > S:NR profile2; > > > > negotiates profile2 on a connection level independend of any > > service or tranaction. Switch to profile2 is implied with the > > response. > > Correct. > > > We may want to make this more obvious by adding a parameter also > > to the NR message that acknolowledgs that there is no direct > > profile switch. > > I thought about doing that as well. Let's make Service-Group mandatory > in the response. Semantically, it would mean that the responder > understands that we are negotiating service group settings (other than > that, there is no information in that parameter in NR). > > Let's also call the parameter SG since it is going to be used a lot. > > > 2. More NO-NR dialogs are introduced with this approach. If one > > agent wants to check for several service group profile after each > > other, it always needs to wait for a NR message before sending the > > next NO message. > > In some cases, it is possible to do optimistic negotiation (sending > offers without waiting for responses). We will need to document that > somehow (provide an example?) but the current spec wording should > allow for that. > > For example (each line represents a moment in time): > > Processor Server > send NO#1 > send NO#2 > send NO#3 recv NO#1 > send NO#4 send NR to NO#1 > recv NR to NO#1 recv NO#2 > send NO#5 send NR to NO#2 > recv NR to NO#2 > TS 1 sg-id from NO#5 recv NO#3 > ... ... > > As you can see, there is ordering/matching of NO and NR messages, but > there is no synchronization at all. > > Note that the first TS is also optimistic. It may be rejected by the > server if NR to NO#5 is negative. If processor wants to play it safe, > it can wait for the corresponding NR before starting a transaction > using its sg-id. > > > The rid parameter had been removed from NO/NR before. Do we need > > to add it again? > > It will not help because there can be only one negotiation taking > place at any given time. This may seem like a contradiction to the > optimistic negotiation statement above, but it is not. > > > Eventually we can combine 1 and 2 by making sg-id an anonymous > > parameter and let it play the role of rid. But is it good to have > > that functionality through a second and optional parameter of NO/NR? > > Not sure. > > We should try to avoid semantic overloading in protocols. Moreover, I > do not think rid helps here (see above). Does the availability of > optimistic negotiation address your concerns? > > Alex. > > ------------------------------------------------------------ > This mail has been scanned by debian3-smtp > (WebWasher 4.4 fcs Build 556) > ------------------------------------------------------------ > From owner-ietf-openproxy@mail.imc.org Thu Jul 3 12:30:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22222 for ; Thu, 3 Jul 2003 12:30:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y6z3-0002EV-00 for opes-archive@ietf.org; Thu, 03 Jul 2003 12:30:57 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19Y6z2-0002EM-00 for opes-archive@ietf.org; Thu, 03 Jul 2003 12:30:56 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63GIaqt004310 for ; Thu, 3 Jul 2003 09:18:36 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63GIaYM004309 for ietf-openproxy-bks; Thu, 3 Jul 2003 09:18:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mailhost.ens-lyon.fr (pluvier.ens-lyon.fr [140.77.167.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63GIYqt004303 for ; Thu, 3 Jul 2003 09:18:34 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: from oceanite.ens-lyon.fr ([140.77.1.22]) by mailhost.ens-lyon.fr with esmtp (Exim 3.35 #1 (Debian)) id 19Y6n4-0001Rj-00 for ; Thu, 03 Jul 2003 18:18:34 +0200 Received: by oceanite.ens-lyon.fr (Postfix, from userid 1502) id 1C42E320062; Thu, 3 Jul 2003 18:18:29 +0200 (CEST) Received: from mailhost.ens-lyon.fr (pluvier.ens-lyon.fr [140.77.167.5]) by oceanite.ens-lyon.fr (Postfix) with SMTP id CF2D7320061 for ; Thu, 3 Jul 2003 18:18:28 +0200 (CEST) Received: from above.proper.com ([208.184.76.39]) by mailhost.ens-lyon.fr with smtp (Exim 3.35 #1 (Debian)) id 19Y6mt-0001Dq-00 for ; Thu, 03 Jul 2003 18:18:23 +0200 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63GBHqt003725 for ; Thu, 3 Jul 2003 09:11:17 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63GBHeo003723 for ietf-openproxy-bks; Thu, 3 Jul 2003 09:11:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mailhost.ens-lyon.fr (pluvier.ens-lyon.fr [140.77.167.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63GBFqt003702 for ; Thu, 3 Jul 2003 09:11:15 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: from oceanite.ens-lyon.fr ([140.77.1.22]) by mailhost.ens-lyon.fr with esmtp (Exim 3.35 #1 (Debian)) id 19Y6fx-0001ns-00 for ; Thu, 03 Jul 2003 18:11:13 +0200 Received: by oceanite.ens-lyon.fr (Postfix, from userid 1502) id 535DC32005F; Thu, 3 Jul 2003 18:11:11 +0200 (CEST) Received: from mailhost.ens-lyon.fr (pluvier.ens-lyon.fr [140.77.167.5]) by oceanite.ens-lyon.fr (Postfix) with SMTP id 16732320058 for ; Thu, 3 Jul 2003 18:11:11 +0200 (CEST) Received: from above.proper.com ([208.184.76.39]) by mailhost.ens-lyon.fr with smtp (Exim 3.35 #1 (Debian)) id 19Y6fr-0001eG-00 for ; Thu, 03 Jul 2003 18:11:07 +0200 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63G1Uqt002638 for ; Thu, 3 Jul 2003 09:01:30 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63G1Ud7002637 for ietf-openproxy-bks; Thu, 3 Jul 2003 09:01:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from debian3-smtp ([217.146.159.49]) by above.proper.com (8.12.9/8.12.8) with SMTP id h63G1Rqt002586 for ; Thu, 3 Jul 2003 09:01:28 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] id AH8MLVML; 03 Jul 2003 20:08:17 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: NO messages x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 Date: Thu, 3 Jul 2003 18:01:16 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D054FB7@mail.webwasher.com> Thread-Topic: NO messages Thread-Index: AcNBdaX9VzboZ7HDQzKGWy+22X/idwABhPYg From: "Martin Stecher" To: "OPES WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h63G1Tqt002629 List-Archive: List-Unsubscribe: List-ID: List-Archive: List-Unsubscribe: List-ID: X-Spam-Status: No, hits=-0.9 required=5.0 tests=QUOTED_EMAIL_TEXT,X_AUTH_WARNING version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Spam-Report: ---- Start SpamAssassin results -0.90 points, 5 required; * -0.4 -- Has a X-Authentication-Warning header * -0.5 -- BODY: Contains what looks like a quoted email text ---- End of SpamAssassin results Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Great. We have it, I guess. Summary: - NO and NR have optional named parameter SG, which has an uni value sg-id - sg-id was previously created by SGC - If NR is sent in response to NO with SG parameter, NR also needs the same SG parameter - TS has mandantory sg-id anonymous parameter; the optional "service" parameter will go away Regards Martin > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Thursday, July 03, 2003 5:13 PM > To: OPES WG > Subject: RE: NO messages > > > > On Thu, 3 Jul 2003, Martin Stecher wrote: > > > Looks good. It is either it now or it is very close. Let's check for > > finetuning: > > > > 1. The sequence > > P:NO (profile1, profile2, profile3) > > Service-Group: sg-id; > > S:NR profile2; > > negotiates that profile2 will be used in transactions for sg-id. > > There is no direct switch to profile2 on the connection. > > Correct. > > > P:NO (profile1, profile2, profile3) > > S:NR profile2; > > > > negotiates profile2 on a connection level independend of any > > service or tranaction. Switch to profile2 is implied with the > > response. > > Correct. > > > We may want to make this more obvious by adding a parameter also > > to the NR message that acknolowledgs that there is no direct > > profile switch. > > I thought about doing that as well. Let's make Service-Group mandatory > in the response. Semantically, it would mean that the responder > understands that we are negotiating service group settings (other than > that, there is no information in that parameter in NR). > > Let's also call the parameter SG since it is going to be used a lot. > > > 2. More NO-NR dialogs are introduced with this approach. If one > > agent wants to check for several service group profile after each > > other, it always needs to wait for a NR message before sending the > > next NO message. > > In some cases, it is possible to do optimistic negotiation (sending > offers without waiting for responses). We will need to document that > somehow (provide an example?) but the current spec wording should > allow for that. > > For example (each line represents a moment in time): > > Processor Server > send NO#1 > send NO#2 > send NO#3 recv NO#1 > send NO#4 send NR to NO#1 > recv NR to NO#1 recv NO#2 > send NO#5 send NR to NO#2 > recv NR to NO#2 > TS 1 sg-id from NO#5 recv NO#3 > ... ... > > As you can see, there is ordering/matching of NO and NR messages, but > there is no synchronization at all. > > Note that the first TS is also optimistic. It may be rejected by the > server if NR to NO#5 is negative. If processor wants to play it safe, > it can wait for the corresponding NR before starting a transaction > using its sg-id. > > > The rid parameter had been removed from NO/NR before. Do we need > > to add it again? > > It will not help because there can be only one negotiation taking > place at any given time. This may seem like a contradiction to the > optimistic negotiation statement above, but it is not. > > > Eventually we can combine 1 and 2 by making sg-id an anonymous > > parameter and let it play the role of rid. But is it good to have > > that functionality through a second and optional parameter of NO/NR? > > Not sure. > > We should try to avoid semantic overloading in protocols. Moreover, I > do not think rid helps here (see above). Does the availability of > optimistic negotiation address your concerns? > > Alex. > > ------------------------------------------------------------ > This mail has been scanned by debian3-smtp > (WebWasher 4.4 fcs Build 556) > ------------------------------------------------------------ > From owner-ietf-openproxy@mail.imc.org Wed Jul 9 10:56:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03728 for ; Wed, 9 Jul 2003 10:56:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aGNK-0007Ag-00 for opes-archive@ietf.org; Wed, 09 Jul 2003 10:56:54 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19aGNJ-0007Ac-00 for opes-archive@ietf.org; Wed, 09 Jul 2003 10:56:53 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h69Eetqt099534 for ; Wed, 9 Jul 2003 07:40:55 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h69Eet5D099525 for ietf-openproxy-bks; Wed, 9 Jul 2003 07:40:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h69Eerqt099491 for ; Wed, 9 Jul 2003 07:40:53 -0700 (PDT) (envelope-from info@utel.net) Received: from f13m-10-97.d1.club-internet.fr ([212.195.85.97] helo=jfc2.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 19aG7n-0005Ii-00 for ietf-openproxy@imc.org; Wed, 09 Jul 2003 07:40:52 -0700 Message-Id: <5.2.0.9.0.20030709160713.00a96e50@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 09 Jul 2003 16:46:06 +0200 To: "OPES WG" From: jfcm Subject: IPv6 In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D054FB7@mail.webwasher.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I apologize for not having participated lately to the work of the WG, being taken by others important (to my familly) tasks. I am trying to bring me up to speed now the fight seems over :-). An important point came accross recently at TFIPv6 and through some words of Tom Leighton (Akamai). It could be summarized this way "are routing and addressing" to be related? Today the routing is fixed tables dependant and addresses are ISP dependant. There are aound 140.000 routes in these tables. Rumors (? may be someone knows better) have that over 200.000 routes there might be instability. I observe that many problems currently discussed over IPv6 would disapear would the SLA (Second Level Address) be totally independant from the TLA (Top Level Adress). This would mean that the begining of the IPv6 address would be used identify the physical network (as the TLD indentifies the virtual network). And the SLA would identify the physical System (as does a telephone number which uniquely identify a mobile whatever the local network used to call it - for example abroad). This would for example permit to support Catenet (the archtecture of Louis Pouzin they considered for a while where the inputs of all the links are concatenated on a per port basis, so you may receive data through a non DoSed ISP). This would simplify the knowledge and the organization of dynamic tables for routing. To test the concept an archtecture is necessary without redesigning routers. Could the architecture be a network or OPES servers used to route datagrams over OCP. 1. let suppose that I use 60 or 100 OPES servers. 2. Each of them has physical links to Hosts and to other OPES. 3. each time a datagram is sent a dispatcher looks at the destination IP address and if it is among the connected Hosts it builds an OCP path to reach that host as a list of {OPES server:port nr}. a) I understand that OCP could support it b) I understand that OCP could support many additional services such as killing a blocked connexion? c) this is software, but I would be interested in comments about the probable speed? d) how OCP could support an exploration of the OPES servers network at start (or on demand) to kown the most simply the topology of the network and of the Hosts ports (this can be a simple application, but would you see some OCP features that would help verification, speed, etc.?) e) obviously this could be partly hard coded and gain speed and stability. CommentsN One of the interesting feature I suppose OCP would support easily would be a fast and no loop routing in having the current machine removed from the list of the {OPES:Ports] when the datagram is sent. This simple service by the current OPES server would create a true pipe, OCP being able to report the end success and the on-path failures and request alternate routing. The OPES servers could bufferise the data until they are told the next node forwarded them (or the first server until data reached the end). If the next node failedn an alternative path could be requested and no datagram could be lost. If I am right OCP would also make sure there is no intruding datagrams? jfc From owner-ietf-openproxy@mail.imc.org Thu Jul 10 17:54:26 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23551 for ; Thu, 10 Jul 2003 17:54:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ajMz-0007jI-00 for opes-archive@ietf.org; Thu, 10 Jul 2003 17:54:30 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19ajMy-0007jE-00 for opes-archive@ietf.org; Thu, 10 Jul 2003 17:54:29 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6ALfaqt018739 for ; Thu, 10 Jul 2003 14:41:36 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6ALfapT018738 for ietf-openproxy-bks; Thu, 10 Jul 2003 14:41:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6ALfZqt018733 for ; Thu, 10 Jul 2003 14:41:35 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h6ALfaFB017764 for ; Thu, 10 Jul 2003 15:41:36 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h6ALfQnP017763; Thu, 10 Jul 2003 15:41:26 -0600 (MDT) (envelope-from rousskov) Date: Thu, 10 Jul 2003 15:41:26 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: OCP: making AME and TE required Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I originally marked Application Message End (AME) and Transaction End (TE) messages as optional: Transaction End (TE) implied the end of corresponding data flows, while Connection End (CE) implied the end of all transactions. The motivation was simple: these messages are not required under some common circumstances, and we want to keep chatter to the minimum. First implementation experience showed that it may be confusing to coders when an AME or TE message should be sent. Not sending a termination message is likely to cause timeouts because the other side often has to wait for the end of the message to proceed. However, the bug may not be detected early enough because some services will not wait and successfully terminate transactions on their own. Would anybody be against making these messages required for normal transaction termination? I think the protocol will be more clear if we do so. IIRC, Oskar Batuner has already argued that these messages should be explicit. The drawback is that it would not be possible to normally terminate a connection with 10 ended transactions without sending 10 TE messages first, but such a situation is probably rare. Again, this is a pure "clarity" issue: Correct implementations would not benefit from having explicit AMEs and TEs, but we might get more correct implementations or ease development if AMEs and TEs are made explicit/required. Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Fri Jul 11 04:19:46 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20430 for ; Fri, 11 Jul 2003 04:19:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19at86-0003QI-00 for opes-archive@ietf.org; Fri, 11 Jul 2003 04:19:46 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19at85-0003QF-00 for opes-archive@ietf.org; Fri, 11 Jul 2003 04:19:45 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6B858qt060680 for ; Fri, 11 Jul 2003 01:05:08 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6B858aj060678 for ietf-openproxy-bks; Fri, 11 Jul 2003 01:05:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from debian3-smtp ([217.146.159.49]) by above.proper.com (8.12.9/8.12.8) with SMTP id h6B855qt060626 for ; Fri, 11 Jul 2003 01:05:06 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] id I46DBY5T; 11 Jul 2003 12:11:55 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: making AME and TE required Date: Fri, 11 Jul 2003 10:04:50 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D055020@mail.webwasher.com> Thread-Topic: making AME and TE required Thread-Index: AcNHMKLjzcq8gOoXRbGSyJBPTKB+BAAUG5SQ From: "Martin Stecher" To: "OPES WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h6B857qt060671 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Absolutely. It is really not easy to comprehend in each case where explicit *-end messages are necessary or where implicit messages are enough. In order to keep specifications short, to increase clarity and to reduce the risk of non-interoperable agents, I also think we should make *-end messages for NORMAL transaction termination mandantory. If an implementation is really aware at some point that it wants to close ten transactions at the same time, it could send all TE messages in a single TCP frame AND keep the connection still open. I guess the overall performance will then still be much better than shutting the connection down to imply transaction termination and then to open a new connection. Abnormal termination (agent detected a problem in message flow that it cannot compensate) closing of a connection/transaction must still be possible of course without a sequence of clean-up messages. Regards Martin > > > > I originally marked Application Message End (AME) and Transaction End > (TE) messages as optional: Transaction End (TE) implied the end of > corresponding data flows, while Connection End (CE) implied the end > of all transactions. The motivation was simple: these messages are not > required under some common circumstances, and we want to keep chatter > to the minimum. > > First implementation experience showed that it may be confusing to > coders when an AME or TE message should be sent. Not sending a > termination message is likely to cause timeouts because the other side > often has to wait for the end of the message to proceed. However, the > bug may not be detected early enough because some services will not > wait and successfully terminate transactions on their own. > > Would anybody be against making these messages required for normal > transaction termination? I think the protocol will be more clear if we > do so. IIRC, Oskar Batuner has already argued that these messages > should be explicit. The drawback is that it would not be possible to > normally terminate a connection with 10 ended transactions without > sending 10 TE messages first, but such a situation is probably rare. > > Again, this is a pure "clarity" issue: Correct implementations would > not benefit from having explicit AMEs and TEs, but we might get more > correct implementations or ease development if AMEs and TEs are made > explicit/required. > > Thanks, > > Alex. From owner-ietf-openproxy@mail.imc.org Fri Jul 11 05:59:14 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23345 for ; Fri, 11 Jul 2003 05:59:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19augN-0004G7-00 for opes-archive@ietf.org; Fri, 11 Jul 2003 05:59:15 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19augM-0004G1-00 for opes-archive@ietf.org; Fri, 11 Jul 2003 05:59:14 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6B9jMqt073912 for ; Fri, 11 Jul 2003 02:45:22 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6B9jM2C073910 for ietf-openproxy-bks; Fri, 11 Jul 2003 02:45:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from debian3-smtp ([217.146.159.49]) by above.proper.com (8.12.9/8.12.8) with SMTP id h6B9jJqt073898 for ; Fri, 11 Jul 2003 02:45:21 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] id 8D4SY49P; 11 Jul 2003 13:52:19 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: OCP error and result indication Date: Fri, 11 Jul 2003 11:45:15 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D055022@mail.webwasher.com> Thread-Topic: OCP error and result indication Thread-Index: AcNHkSFHXCYh/degR2GjAaKPSE5MBA== From: "Martin Stecher" To: "OPES WG (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h6B9jLqt073905 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi, we had already some discussion on this list regarding how to return a result or an error status. So far we see three options: a) Messages such as TE and CE have an anonymous result parameter which is a structure of the form {uni [string]}, where uni is the status/error code and string an optional human readable description. b) Like a) plus an error flag as additional named parameter for an abnormal condition that cannot be expressed via a result parameter. c) If we define only two result codes {200 ok} and {400 error} and allow for omitting the result in case of "ok" and there is probably no reason for a textual description of a successful operation, we can replace the result parameter by a named parameter "Error: text". I think a) is the best solution. Saying this I am simply lacking of imagination what these conditions in b) are that cannot be expressed via result. Oskar: I remember you talked about this. Can you show some examples why an additional error flag is needed and a result structure is not sufficient? This is why I prefer a) over c): 1. More than one error code is useful. In my prototype implementation I already used two different codes trying to differentiate between syntax errors and semantical errors. For the latter I used code 500 (which is probably not the best number), e.g. {500 "18:CS message missing"} vs. {400 "24:Leading zero not allowed"}. While one can argue that this differentiation is not really necessary, how about further error codes that tell one agent that the transaction was not terminated due to a syntax error but because the other agent reached its internal max. of open transactions per connection or because a negotiation offer did not contain any matching feature? I assume that some implementation can make use of well-known error codes (e.g. open a new connection and try that transaction there). 2. Protocol extensions such as TLS may need result codes to indicate s.th. like "authentication required" 3. Some application protocol bindings may benefit from more than one success status. FTP for example uses different codes to return if a file was created or replaced if I remember correctly. Maybe situations come up where such differentiation will also be wanted within OCP result codes. 4. Testing tools or statistics in OCP products will it have easier to count error conditions due to different codes rather than handling different textual error descriptions. Regards Martin From owner-ietf-openproxy@mail.imc.org Fri Jul 11 12:45:14 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05484 for ; Fri, 11 Jul 2003 12:45:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b11J-00074I-00 for opes-archive@ietf.org; Fri, 11 Jul 2003 12:45:17 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19b11I-00074F-00 for opes-archive@ietf.org; Fri, 11 Jul 2003 12:45:16 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6BGVDqt004205 for ; Fri, 11 Jul 2003 09:31:13 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6BGVDVa004204 for ietf-openproxy-bks; Fri, 11 Jul 2003 09:31:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6BGVBqt004199 for ; Fri, 11 Jul 2003 09:31:11 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h6BGVCFB044934; Fri, 11 Jul 2003 10:31:12 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h6BGVCO0044933; Fri, 11 Jul 2003 10:31:12 -0600 (MDT) (envelope-from rousskov) Date: Fri, 11 Jul 2003 10:31:12 -0600 (MDT) From: Alex Rousskov To: "OPES WG (E-mail)" Subject: Re: OCP error and result indication In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D055022@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D055022@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 11 Jul 2003, Martin Stecher wrote: > a) Messages such as TE and CE have an anonymous result parameter > which is a structure of the form {uni [string]}, where uni is the > status/error code and string an optional human readable description. Paraphrasing: Result is an anonymous parameter with the following syntax: result = { code [text] } code = decimal text = string > b) Like a) plus an error flag as additional named parameter for an > abnormal condition that cannot be expressed via a result parameter. Let's ignore this issue until Oskar provides more feedback. If something cannot be expressed via a result parameter/code, then we will add more options. If everything can be expressed with existing means, then (a) and (b) are the same. c) If we define only two result codes {200 ok} and {400 error} and > allow for omitting the result in case of "ok" and there is probably > no reason for a textual description of a successful operation, we > can replace the result parameter by a named parameter "Error: text". Scratch that. See (d) below. d) Errors are indicated by a named "Error" parameter with the following syntax: Error: code [text] Success is defined as absence of errors. e) Result is an anonymous parameter with the following syntax: result = { outcome code [text] } outcome = "+" | "-" code = decimal text = string we can replace "+" and "-" with something else, of course. Let's approach the problem from the design point of view. What information are we trying to relay here? 1) is the result a success or failure? (true/false) 2) what kind of success (if it is success)? 3) what kind of error (if it is an error)? (a) relies on specific code ranges (e.g., 2xx) to support (1) and supports (2) and (3) via specific code values (e.g., 404) (d) relies on the presence of Error parameter to support (1) and does not support (2) and supports (3) via specific code values (e.g., 404) (e) relies on the outcome "sign" to support (1) and supports (2) and (3) via specific code values (e.g., 404) (e) is clearly better than (a) from the design point of view because it is symmetric, but (a) is what people are used to. (d) lacks functionality that might be needed for extensions. Should we go with (a)? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Fri Jul 11 15:46:19 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14101 for ; Fri, 11 Jul 2003 15:46:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b3qV-0001Th-00 for opes-archive@ietf.org; Fri, 11 Jul 2003 15:46:20 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19b3qU-0001Te-00 for opes-archive@ietf.org; Fri, 11 Jul 2003 15:46:19 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6BJYcqt015503 for ; Fri, 11 Jul 2003 12:34:38 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6BJYcVT015502 for ietf-openproxy-bks; Fri, 11 Jul 2003 12:34:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from debian3-smtp ([217.146.159.49]) by above.proper.com (8.12.9/8.12.8) with SMTP id h6BJYaqt015495 for ; Fri, 11 Jul 2003 12:34:37 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] id VOV0PDC2; 11 Jul 2003 23:41:37 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: OCP error and result indication Date: Fri, 11 Jul 2003 21:34:32 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D013FA5@mail.webwasher.com> Thread-Topic: OCP error and result indication Thread-Index: AcNHydl1mg2wz0soSZaDvRRGx33ZQwAGO+Wg From: "Martin Stecher" To: "OPES WG (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h6BJYbqt015497 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > Let's approach the problem from the design point of view. What > information are we trying to relay here? > > 1) is the result a success or failure? (true/false) > 2) what kind of success (if it is success)? > 3) what kind of error (if it is an error)? > > (a) relies on specific code ranges (e.g., 2xx) to support (1) and > supports (2) and (3) via specific code values (e.g., 404) > > (d) relies on the presence of Error parameter to support (1) and > does not support (2) and > supports (3) via specific code values (e.g., 404) > > (e) relies on the outcome "sign" to support (1) and > supports (2) and (3) via specific code values (e.g., 404) > > > (e) is clearly better than (a) from the design point of view because > it is symmetric, but (a) is what people are used to. (d) lacks > functionality that might be needed for extensions. > Comparing (e) with (a), (a) remains my favorite. I got used to the specific code range meanings. > Should we go with (a)? I say: yes, let's go with (a). Martin From owner-ietf-openproxy@mail.imc.org Mon Jul 14 16:36:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24017 for ; Mon, 14 Jul 2003 16:36:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cA40-0007WY-00 for opes-archive@ietf.org; Mon, 14 Jul 2003 16:36:49 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19cA40-0007WU-00 for opes-archive@ietf.org; Mon, 14 Jul 2003 16:36:48 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6EKMmqt099596 for ; Mon, 14 Jul 2003 13:22:48 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6EKMm9p099595 for ietf-openproxy-bks; Mon, 14 Jul 2003 13:22:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6EKMkqt099587 for ; Mon, 14 Jul 2003 13:22:47 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h6EKMlFB060230 for ; Mon, 14 Jul 2003 14:22:47 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h6EKMbXO060229; Mon, 14 Jul 2003 14:22:37 -0600 (MDT) (envelope-from rousskov) Date: Mon, 14 Jul 2003 14:22:37 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: OCP Core version head_sid13 available Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The log of major changes is quoted below. The latest snapshot is at http://www.measurement-factory.com/tmp/opes/ Please continue to comment and work on the to-do list. Thank you, Alex. -------------- change log ---------------- Appendix B. Change Log head-sid13 * Added SG parameter to Negotiation Offer (NO) and Negotiation Response (NR) messages to limit the result of negotiations to the specified service group. Still need to document SG-related logic in the Negotiation section. * Removed "services" parameter from Transaction Start (TS) message because we have to rely on service groups exclusively, because only service groups can have negotiated application profiles associated with them. * Replaced data-id parameter with "Kept: kept-offset" and "Wont-Use: used-size" parameter. We probably need octet-based granularity, and old data-id only offered fragment-based granularity. * Made AME and TE messages required. * Documented result parameter syntax and two result codes: 200 (success) and 400 (failure). * Added optional "result" parameter to CE. From owner-ietf-openproxy@mail.imc.org Mon Jul 14 16:41:12 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24352 for ; Mon, 14 Jul 2003 16:41:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cA8H-0007c8-00 for opes-archive@ietf.org; Mon, 14 Jul 2003 16:41:13 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19cA8G-0007c5-00 for opes-archive@ietf.org; Mon, 14 Jul 2003 16:41:12 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6EKSVqt000490 for ; Mon, 14 Jul 2003 13:28:31 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6EKSVxR000489 for ietf-openproxy-bks; Mon, 14 Jul 2003 13:28:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6EKSTqt000480 for ; Mon, 14 Jul 2003 13:28:29 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h6EKSVFB060353 for ; Mon, 14 Jul 2003 14:28:31 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h6EKSVjb060352; Mon, 14 Jul 2003 14:28:31 -0600 (MDT) (envelope-from rousskov) Date: Mon, 14 Jul 2003 14:28:31 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: HTTP adaptation draft version head_sid13 available Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The "HTTP adaptation with OPES" draft will document all HTTP-specific things related to OPES core modules: tracing, bypass, and OCP. The latest snapshot is at http://www.measurement-factory.com/tmp/opes/ This draft has not been promoted to the WG status. Please contribute. Thank you, Alex. Appendix B. Change Log head-sid13 * Removed HTTP-transaction profile, added optional parts as feature parameters, added example. From owner-ietf-openproxy@mail.imc.org Wed Jul 16 17:02:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17430 for ; Wed, 16 Jul 2003 17:02:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ctQL-0003Kg-00 for opes-archive@ietf.org; Wed, 16 Jul 2003 17:02:53 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19ctQ5-0003KH-00 for opes-archive@ietf.org; Wed, 16 Jul 2003 17:02:37 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6GKgVqt007012 for ; Wed, 16 Jul 2003 13:42:31 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6GKgVns007011 for ietf-openproxy-bks; Wed, 16 Jul 2003 13:42:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6GKgUqt007005 for ; Wed, 16 Jul 2003 13:42:30 -0700 (PDT) (envelope-from markus@mhof.com) Received: from mhof.com (unknown[135.104.20.70](misconfigured sender)) by comcast.net (rwcrmhc13) with SMTP id <200307162042260150085d79e> (Authid: mhofmann); Wed, 16 Jul 2003 20:42:27 +0000 Message-ID: <3F15B8B4.3040404@mhof.com> Date: Wed, 16 Jul 2003 16:42:28 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030612 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES WG Subject: Re: HTTP adaptation draft version head_sid13 available References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Folks, I suggest that the current write-up on "HTTP adaptation with OPES" (see Alex reference below) gets adopted and published as WG Internet Draft, from which the WG will continue to work on. Unless someone objects by Friday 7/25, I'd ask Alex and Martin to submit the "HTTP adaptation with OPES" document for publication as WG ID. Please note that publication as WG draft does *not* imply that the document is finished. The WG will continue to work on the document and discuss it on this mailing list. Thanks, Markus Alex Rousskov wrote: > > The "HTTP adaptation with OPES" draft will document all HTTP-specific > things related to OPES core modules: tracing, bypass, and OCP. The > latest snapshot is at > > http://www.measurement-factory.com/tmp/opes/ > > This draft has not been promoted to the WG status. > Please contribute. > > Thank you, > > Alex. > > > Appendix B. Change Log > > head-sid13 > > * Removed HTTP-transaction profile, added optional parts as > feature parameters, added example. > > > From subs-reminder@imc.org Sat Jul 19 20:23:15 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26532 for ; Sat, 19 Jul 2003 20:23:15 -0400 (EDT) From: subs-reminder@imc.org Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19e1yv-0005KR-00 for opes-archive@ietf.org; Sat, 19 Jul 2003 20:23:17 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19e1yk-0005K7-00 for opes-archive@ietf.org; Sat, 19 Jul 2003 20:23:06 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6K0L1qt042057 for ; Sat, 19 Jul 2003 17:21:01 -0700 (PDT) (envelope-from subs-reminder@imc.org) Received: (from root@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6K0L1Ee042056; Sat, 19 Jul 2003 17:21:01 -0700 (PDT) Date: Sat, 19 Jul 2003 17:21:01 -0700 (PDT) Message-Id: <200307200021.h6K0L1Ee042056@above.proper.com> To: opes-archive@ietf.org Subject: [[881627325]] Subscription to ietf-openproxy for opes-archive@ietf.org Greetings. This message is a periodic reminder that opes-archive@ietf.org is subscribed to the ietf-openproxy mailing list. *** SEE BELOW: PLEASE DO NOT RESPOND TO THIS MESSAGE. *** There are two purposes for this message: - If this message is bounced by your mail server, I can remove you from the mailing list and reduce waste of bandwidth and resources. (If you are reading this message, it clearly didn't get bounced!) - Some people stay subscribed to mailing lists even though they do not want to because they do not know how to unsubscribe. If you want to stay subscribed to the ietf-openproxy mailing list, you do not need to do anything. Feel free to delete this message. On the other hand, if you want to unsubscribe from this list, simply go to the following link: If for some reason you cannot go to that web site, you can also unsubscribe by email; however, doing so is not as likely to get you unsubscribed as the web site is. To unsubscribe using email, you can respond to this message and I will unsubscribe you by hand in the next few days. Again, this is not assured to work because your mail system may make it impossible for me to determine who you are or what you want to unsubscribe to. Alternatively, you can send a plain-text message to: ietf-openproxy-request@imc.org with the single word unsubscribe in the body of the message. This last method assumes that the "From:" address in your mail is "opes-archive@ietf.org". Again, using the web site above is more likely to work than this method (due to limitations in Majordomo, the mailing list software we currently use). If you have any questions, feel free to contact me. --Paul Hoffman, list administrator From owner-ietf-openproxy@mail.imc.org Thu Jul 24 14:22:43 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19834 for ; Thu, 24 Jul 2003 14:22:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fkjl-0000h5-00 for opes-archive@ietf.org; Thu, 24 Jul 2003 14:22:45 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19fkjP-0000go-00 for opes-archive@ietf.org; Thu, 24 Jul 2003 14:22:26 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OI6Wqt062985 for ; Thu, 24 Jul 2003 11:06:32 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6OI6WEl062984 for ietf-openproxy-bks; Thu, 24 Jul 2003 11:06:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OI6Tqt062973 for ; Thu, 24 Jul 2003 11:06:31 -0700 (PDT) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h6OI6U9Y078137; Thu, 24 Jul 2003 14:06:30 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h6OI4D4e015419; Thu, 24 Jul 2003 14:04:14 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h6OI4Dh2008601; Thu, 24 Jul 2003 14:04:13 -0400 (EDT) Message-ID: <3F201FEB.4050404@mhof.com> Date: Thu, 24 Jul 2003 14:05:31 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Draft minutes from IETF 57 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi, below the draft minutes from the OPES meeting in Vienna. In the absence of substantive comments, the minutes get filed on Monday, 8/4/03. Thanks, Markus ================================================================== Minutes of the 57th Vienna OPES WG. CHAIRS: Markus Hofmann Minutes by Dimitri Tombroff. 1 Introduction and General Status: ---------------------------------- Status of OPES documents: Initial versions of tracing/bypassing (draft-ietf-opes-end-comm-00.txt) and OPES core protocol (draft-ietf-opes-ocp-core-00.txt) have been published. An individual submission about OCP/HTTP mapping has also been published, and the group intendes to adopt this draft as WG document. General comments from the chair: - WG needs more participants for reviewing drafts and brings in arguments. - WG needs additional focusing on tracing/bypassing issues. - WG is late with the rule language. Need expert contributors to start this. 2 Work on "Tracing/Bypass" document [P. Knight] ----------------------------------------------- Main issues is to decide on is traceable in an OPES flow, how to do it, and what are the requirements and privacy issues. The WG approach is to use in-band tracing on a per message flow with the following requirements: - an OPES system MUST be traceable - an OPES processor SHOULD be traceable - an OPES service MAY be traceable. question: this works only for application protocols that allow for in-band signaling of meta information. How would the first MUST apply to other application protocols? answer: At this point, it is assumed that the appplication protocol will have to support in-band signaling, which is in-line with the WG's charter to focus on HTTP. This issue should be mentioned in the drafts. question : what motivates the MUST, SHOULD, and MAY at three different levels ? answer: if you have a chain of processor, it may be unecessary that each processor adds a trace. One per domain is enough. On 'How to support tracing', the chair noted that although the WG has so far ruled out out-of-band notifications, more input is needed to confirm it is the correct approach. It was suggested that the resulting discussion should be reflected in the document(s). On another issue, the WG needs to detail the definition of an "OPES system". 3 OPES Core Callout Protocol presented [Martin Stecher] ------------------------------------------------------- The core OCP was presented. This was a rather detailed presentation, the remarks and questions were the following: The chair pointed out that there are still many open issues and optional mechanisms to discuss - just see the TBD section and the sections marked with XXX in the drafts. If no one is supporting the inclusion of currently open/optional mechanisms (e.g. capability query) on the mailing list, they will be removed for the sake of protocol simplicity. Performance is of big concern, and the WG needs to show benefits of OCP over ICAP. It was noted that after long discussions about using BEEP, SOAP, or HTTP, the consensus has been to move forward with a custom tailored transport protocol for OCP, and see how it works. Progresses have been mostly made on OCP messages format. The 'can you' and 'do you' set of messages might bring unecessary complication. Some input is needed to check if they are worthwhile. question : Since OCP is defined by a BNF grammar, is or will a parser be provided ? answer: none so far. 4 OCP Http Adaptation [Martin Stecher] -------------------------------------- The http adaptation was presented, as well as the status of prototype callout servers by A. Rousskov and M. Stecher. One issue was raised about HTTP keep-alive connections and HTTP/1.1 pipelining. The problem is that the callout server may have to transform a keep-alive http reply into a closed reply, because it may not be able to set the correct Content-Length http header, nor use the chunked transfer encoding. Having a callout generating closed http replies is bad because it breaks two desirable http properties: keep-alive connections and thus http pipelining (if any). It was also pointed out that it is not clear if it's the callout server responsability or the OPES processor responsability to handle such closing. 5 OPES treatment of IAB Consideration [P. Knight] ------------------------------------------------- IAB considerations were discussed. The goal is to show that all IAB considerations are addressed. Only IAB considerations are mentioned in this document that triggered some remarks/questions during the meeting. 5.0 IP layer Addressability Comment: must be addressible at IP layer. Otherwise encryption will not work. 5.1 Notification: As pointed out before, the tracing/notification issue is still at an early stage. Following Remarks: - hit metering analogy may not be approriate here, content providers might want at least some limited help in the OPES case - (out-of-band) notification may be a problem for the recipient if it must handle a lots of notification information. A solution (should notification be needed) would be to perform aggregation. I.e send me a notification every hour rather than for each message. 5.2 Non-blocking: OPES intermediaries MUST support a bypass feature. There is a clear open issue if the OPES service is essential. 5.3 Privacy. From the tracing information, the user can contact the OPES first node, then ask its privacy policy. What is not clear nor explicitely stated here is that the first OPES node is not necessarilly addressible. A statement like "at least one trace per domain must identify one addressible node" is needed. question : is there any relationship with the ALIAS WG wrt to establishing a trust relationship with an intermediary. answer: OPES is application level while ALIAS deals with the transport level. From owner-ietf-openproxy@mail.imc.org Thu Jul 24 16:56:16 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00151 for ; Thu, 24 Jul 2003 16:56:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fn8N-0002C5-00 for opes-archive@ietf.org; Thu, 24 Jul 2003 16:56:19 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19fn87-0002Bw-00 for opes-archive@ietf.org; Thu, 24 Jul 2003 16:56:03 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OKhpqt072246 for ; Thu, 24 Jul 2003 13:43:51 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6OKhpxx072245 for ietf-openproxy-bks; Thu, 24 Jul 2003 13:43:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OKhoqt072240 for ; Thu, 24 Jul 2003 13:43:50 -0700 (PDT) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h6OKhp9Y079388 for ; Thu, 24 Jul 2003 16:43:51 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h6OKhi4e028026 for ; Thu, 24 Jul 2003 16:43:45 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h6OKhih2014132 for ; Thu, 24 Jul 2003 16:43:44 -0400 (EDT) Message-ID: <3F20454E.9090706@mhof.com> Date: Thu, 24 Jul 2003 16:45:02 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES WG Subject: Re: draft-beck-opes-irml-03.txt References: <3EF8CADD.2060201@bell-labs.com> <3EF905A5.9000100@mhof.com> <3F0087EF.6020805@bell-labs.com> In-Reply-To: <3F0087EF.6020805@bell-labs.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 Folks, we need to get going on the rules language as well, we're already late on this one! There was only a single email from Alex coming back as response to the re-submitted IRML draft (draft-beck-opes-irml-03.txt). The intent has been to stimulate some discussions around this topic and to get started working on it... Well, if there's nothing more to discuss and no one is coming up with modifications or alternatives to the approach presented in the IRML draft, maybe we should move forward with it and declare it a WG draft. If not, please engage on this mailing list and provide alternative thoughts and approaches. We're aiming to submit an initial WG document on the rules language in August! Thanks, Markus From owner-ietf-openproxy@mail.imc.org Thu Jul 24 17:27:24 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01707 for ; Thu, 24 Jul 2003 17:27:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fncV-0002UE-00 for opes-archive@ietf.org; Thu, 24 Jul 2003 17:27:27 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19fncF-0002U6-00 for opes-archive@ietf.org; Thu, 24 Jul 2003 17:27:11 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OLF1qt073549 for ; Thu, 24 Jul 2003 14:15:01 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6OLF1lS073548 for ietf-openproxy-bks; Thu, 24 Jul 2003 14:15:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OLF0qt073540 for ; Thu, 24 Jul 2003 14:15:00 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.8/8.12.8) with ESMTP id h6OLBbD2025623; Thu, 24 Jul 2003 15:11:37 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.8/8.11.6) with ESMTP id h6OL28RW002452; Thu, 24 Jul 2003 15:02:08 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id h6OL27bQ002448; Thu, 24 Jul 2003 15:02:07 -0600 Date: Thu, 24 Jul 2003 15:02:07 -0600 Message-Id: <200307242102.h6OL27bQ002448@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: markus@mhof.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage <3F20454E.9090706@mhof.com> Subject: Re: draft-beck-opes-irml-03.txt Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The rules language should not be a programming language - it should be a constrained language that can be compiled into efficient runtime dispatches. XML seems like a reasonable way to represent rules, prior to compilation. The elements needed are regular expressions based on tokens; the tokens should encompass not only character strings but also grammatical elements from the underlying protocol. A BNF definition of the underlying protocol, for example, should provide the basis for the OPES rules language to specify header and body constructs. However, I believe that the constraint of triggering only a single action is too severe. It is important to be able to specify sequencing: e.g., action1, then action2. I am a proponent of an approach that supports detailed parsing of cached content. In this model, the OPES processor would take the content-related rule elements and compile them into a single parsing routine. This code might run on an OPES helper machine. The OPES processor would then attach the parsed attributes to cached items. Requests for such items would trigger OPES rules related to requestor profiles; the rules would determine which OPES services were to be applied to the cached items (such as, delivering an already modified and cached item, or applying further customization to such an item, or blocking the item). Hilarie From owner-ietf-openproxy@mail.imc.org Thu Jul 24 17:43:17 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02268 for ; Thu, 24 Jul 2003 17:43:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fnrt-0002aN-00 for opes-archive@ietf.org; Thu, 24 Jul 2003 17:43:21 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19fnrd-0002aB-00 for opes-archive@ietf.org; Thu, 24 Jul 2003 17:43:05 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OLVtqt074002 for ; Thu, 24 Jul 2003 14:31:55 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6OLVt4x074001 for ietf-openproxy-bks; Thu, 24 Jul 2003 14:31:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OLVsqt073993 for ; Thu, 24 Jul 2003 14:31:54 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.8/8.12.8) with ESMTP id h6OLSYD2026100 for ; Thu, 24 Jul 2003 15:28:34 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.8/8.11.6) with ESMTP id h6OLJ5RW003647 for ; Thu, 24 Jul 2003 15:19:05 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id h6OLJ5tJ003643; Thu, 24 Jul 2003 15:19:05 -0600 Date: Thu, 24 Jul 2003 15:19:05 -0600 Message-Id: <200307242119.h6OLJ5tJ003643@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: ietf-openproxy@imc.org Subject: IAB considerations Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I finally realized a point of confusion about the various forms of guidance OPES has received, and I think this should affect the "considerations" draft. The WG was chartered with instructions to address certain issues that more or less correspond to the IAB considerations. It is the things that correspond less that are of concern - particularly the "end-to-end" encryption issue. I think it would be helpful to address these in "considerations". The current consideration draft confuses "privacy" and "undetected modification" and "encryption". "Privacy" is about trusting a party with data that they may use but not disclose. The detection modification of data is its "integrity", and it can be ensured by cryptographic methods, including keyed hashes and public key methods, but in general, not encryption. Encryption is used for "confidentiality", and it can be accomplished by cryptographic methods, but it is not a way to ensure integrity: encrypted data on the wire can be undetectably modified by third parties unless a cryptographic integrity mechanism is used in conjunction with the encryption. The current draft characterizes processor identification at content provider sites as "irrational", which is probably overstating the issue. It is also argues that end users cannot identify themselves usefully to a content provider's internal processors. Although I don't disagree that this might be true in some implementations, it isn't clear that it is impossible in practice. I think that overall the viewpoint should clearly distinguish between protocol feasibility and impact on content provider practices. Hilarie From owner-ietf-openproxy@mail.imc.org Thu Jul 24 18:10:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03686 for ; Thu, 24 Jul 2003 18:10:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19foIe-0002mp-00 for opes-archive@ietf.org; Thu, 24 Jul 2003 18:11:00 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19foIO-0002mb-00 for opes-archive@ietf.org; Thu, 24 Jul 2003 18:10:44 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OLw4qt075773 for ; Thu, 24 Jul 2003 14:58:04 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6OLw4f6075772 for ietf-openproxy-bks; Thu, 24 Jul 2003 14:58:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OLw2qt075766 for ; Thu, 24 Jul 2003 14:58:02 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h6OLw0FB026974; Thu, 24 Jul 2003 15:58:00 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h6OLw0jB026973; Thu, 24 Jul 2003 15:58:00 -0600 (MDT) (envelope-from rousskov) Date: Thu, 24 Jul 2003 15:58:00 -0600 (MDT) From: Alex Rousskov To: Markus Hofmann cc: OPES WG Subject: Re: draft-beck-opes-irml-03.txt In-Reply-To: <3F20454E.9090706@mhof.com> Message-ID: References: <3EF8CADD.2060201@bell-labs.com> <3EF905A5.9000100@mhof.com> <3F0087EF.6020805@bell-labs.com> <3F20454E.9090706@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 24 Jul 2003, Markus Hofmann wrote: > we need to get going on the rules language as well, we're already > late on this one! I will respond to questions raised by my e-mail. For now, I am _not_ arguing that the rule language should be a general purpose programming language. I am arguing that it should be a domain specific language that allows for powerful and simple expression of what rules need to express. Or, at least, we should seriously consider that option. I will try to show that XML presents virtually no advantages compared to a domain specific language and introduces significant hurdles. I am on travel and may not be able to comment on this promptly, unfortunately. N.B. It is theoretically possible to continue working on the language without agreeing on its representation (XML or custom). Alex. From owner-ietf-openproxy@mail.imc.org Fri Jul 25 09:42:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04678 for ; Fri, 25 Jul 2003 09:42:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g2pf-0000LR-00 for opes-archive@ietf.org; Fri, 25 Jul 2003 09:42:03 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19g2pP-0000L5-00 for opes-archive@ietf.org; Fri, 25 Jul 2003 09:41:47 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PDRKqt052310 for ; Fri, 25 Jul 2003 06:27:20 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6PDRKqe052309 for ietf-openproxy-bks; Fri, 25 Jul 2003 06:27:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PDRIqt052303 for ; Fri, 25 Jul 2003 06:27:19 -0700 (PDT) (envelope-from markus@mhof.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h6PDRJHa056564 for ; Fri, 25 Jul 2003 09:27:19 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h6PDRC1u081459 for ; Fri, 25 Jul 2003 09:27:12 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h6PDRCh2025083 for ; Fri, 25 Jul 2003 09:27:12 -0400 (EDT) Message-ID: <3F21307E.3040000@mhof.com> Date: Fri, 25 Jul 2003 09:28:30 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openproxy@imc.org Subject: Re: draft-beck-opes-irml-03.txt References: <200307242102.h6OL27bQ002448@localhost.localdomain> In-Reply-To: <200307242102.h6OL27bQ002448@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit The Purple Streak, Hilarie Orman wrote: > The elements needed are regular expressions based on tokens; While it would be very helpful to have regular expressions, parsing rules and handling of rules with regular expressions can be quite expensive wrt processing capacity required - an OPES processor with a large number of such rules could easily become a bottleneck... It's a tradeoff between flexibility and performance. -Markus From owner-ietf-openproxy@mail.imc.org Fri Jul 25 09:44:12 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04798 for ; Fri, 25 Jul 2003 09:44:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g2rn-0000MJ-00 for opes-archive@ietf.org; Fri, 25 Jul 2003 09:44:15 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19g2rX-0000MC-00 for opes-archive@ietf.org; Fri, 25 Jul 2003 09:44:00 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PDVLqt052626 for ; Fri, 25 Jul 2003 06:31:21 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6PDVLjT052625 for ietf-openproxy-bks; Fri, 25 Jul 2003 06:31:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PDVJqt052620 for ; Fri, 25 Jul 2003 06:31:20 -0700 (PDT) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by dirty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h6PDVKHa056589 for ; Fri, 25 Jul 2003 09:31:20 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h6PDVE4e081638 for ; Fri, 25 Jul 2003 09:31:14 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h6PDVDh2025110 for ; Fri, 25 Jul 2003 09:31:13 -0400 (EDT) Message-ID: <3F21316F.5030504@mhof.com> Date: Fri, 25 Jul 2003 09:32:31 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES WG Subject: Re: draft-beck-opes-irml-03.txt References: <3EF8CADD.2060201@bell-labs.com> <3EF905A5.9000100@mhof.com> <3F0087EF.6020805@bell-labs.com> <3F20454E.9090706@mhof.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > I will try to show that XML presents virtually no advantages compared > to a domain specific language and introduces significant hurdles. I assume "domain specific language" implies a "custom/new/specific" language? If so, allow me to raise flag in that we should use existing approaches (e.g. XML or others) as long as they don't have serious disadvantages, rather than inventing everything ourselves. We're working with the goal of having an initial WG document in August time frame... -Markus From owner-ietf-openproxy@mail.imc.org Fri Jul 25 09:58:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05159 for ; Fri, 25 Jul 2003 09:58:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g365-0000R7-00 for opes-archive@ietf.org; Fri, 25 Jul 2003 09:59:01 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19g35p-0000R0-00 for opes-archive@ietf.org; Fri, 25 Jul 2003 09:58:45 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PDleqt055923 for ; Fri, 25 Jul 2003 06:47:40 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6PDlevb055920 for ietf-openproxy-bks; Fri, 25 Jul 2003 06:47:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PDlcqt055896 for ; Fri, 25 Jul 2003 06:47:39 -0700 (PDT) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h6PDld9Y085661 for ; Fri, 25 Jul 2003 09:47:39 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h6PDlH4e082706 for ; Fri, 25 Jul 2003 09:47:17 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h6PDlGh2025418 for ; Fri, 25 Jul 2003 09:47:16 -0400 (EDT) Message-ID: <3F213532.8090808@mhof.com> Date: Fri, 25 Jul 2003 09:48:34 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Dates for Milestones updated Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi, please note that we've updated the dates for our remaining milestones - please check out our charter at http://ietf.org/html.charters/opes-charter.html Thanks, Markus From owner-ietf-openproxy@mail.imc.org Fri Jul 25 10:24:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07224 for ; Fri, 25 Jul 2003 10:24:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g3UN-0000dC-00 for opes-archive@ietf.org; Fri, 25 Jul 2003 10:24:07 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19g3U7-0000d6-00 for opes-archive@ietf.org; Fri, 25 Jul 2003 10:23:51 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PEBVqt061379 for ; Fri, 25 Jul 2003 07:11:31 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6PEBVlb061378 for ietf-openproxy-bks; Fri, 25 Jul 2003 07:11:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PEBUqt061367 for ; Fri, 25 Jul 2003 07:11:30 -0700 (PDT) (envelope-from markus@mhof.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h6PEBV9Y085872 for ; Fri, 25 Jul 2003 10:11:31 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h6PEBN1u084463 for ; Fri, 25 Jul 2003 10:11:24 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h6PEBNh2025953 for ; Fri, 25 Jul 2003 10:11:23 -0400 (EDT) Message-ID: <3F213AD9.60002@mhof.com> Date: Fri, 25 Jul 2003 10:12:41 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openproxy@imc.org Subject: Re: IAB considerations References: <200307242119.h6OLJ5tJ003643@localhost.localdomain> In-Reply-To: <200307242119.h6OLJ5tJ003643@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hilarie, > The current consideration draft confuses "privacy" and "undetected > modification" and "encryption". Could you please work with Abbie and Alex and provide text for the draft that would help clarifying and resolving the confusion you describe? Thanks! > The current draft characterizes processor identification at content > provider sites as "irrational", which is probably overstating the > issue. It is also argues that end users cannot identify themselves > usefully to a content provider's internal processors. Although I don't > disagree that this might be true in some implementations, it isn't > clear that it is impossible in practice. I think that overall the > viewpoint should clearly distinguish between protocol feasibility > and impact on content provider practices. Agreed, should be reflected in the document. But even if something is feasible, we need to investigate whether it makes sense in practice and respective protocl mechanisms should be included in the specification. (Note: this is intended to encourage general questions, rather than giving a statement on this specific issue). -Markus From owner-ietf-openproxy@mail.imc.org Fri Jul 25 11:10:22 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08711 for ; Fri, 25 Jul 2003 11:10:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g4DC-0000y3-00 for opes-archive@ietf.org; Fri, 25 Jul 2003 11:10:26 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19g4Cw-0000xX-00 for opes-archive@ietf.org; Fri, 25 Jul 2003 11:10:10 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PEuVqt067592 for ; Fri, 25 Jul 2003 07:56:31 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6PEuVDD067591 for ietf-openproxy-bks; Fri, 25 Jul 2003 07:56:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PEuTqt067586 for ; Fri, 25 Jul 2003 07:56:30 -0700 (PDT) (envelope-from abeck@bell-labs.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by dirty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h6PEuUHa057284; Fri, 25 Jul 2003 10:56:30 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h6PEuM4e088019; Fri, 25 Jul 2003 10:56:23 -0400 (EDT) Received: from bell-labs.com (abeck-hopc [135.180.240.202]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h6PEuMh2027099; Fri, 25 Jul 2003 10:56:22 -0400 (EDT) Message-ID: <3F2144AE.30900@bell-labs.com> Date: Fri, 25 Jul 2003 10:54:38 -0400 From: Andre Beck User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "The Purple Streak, Hilarie Orman" CC: markus@mhof.com, ietf-openproxy@imc.org Subject: Re: draft-beck-opes-irml-03.txt References: <200307242102.h6OL27bQ002448@localhost.localdomain> In-Reply-To: <200307242102.h6OL27bQ002448@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hilarie, > The rules language should not be a programming language - it should be > a constrained language that can be compiled into efficient runtime > dispatches. XML seems like a reasonable way to represent rules, > prior to compilation. I agree. > However, I believe that the constraint of triggering only a single > action is too severe. It is important to be able to specify > sequencing: e.g., action1, then action2. I agree again. IRML already supports just that: it lets you specify one or more OPES services that are to be executed in the specified order. However, there still has to be a policy that determines how to order service execution requests from different rule authors. > I am a proponent of an approach that supports detailed parsing of > cached content. In this model, the OPES processor would take the > content-related rule elements and compile them into a single parsing > routine. This code might run on an OPES helper machine. The OPES > processor would then attach the parsed attributes to cached items. > Requests for such items would trigger OPES rules related to requestor > profiles; the rules would determine which OPES services were to be > applied to the cached items (such as, delivering an already modified and > cached item, or applying further customization to such an item, or blocking > the item). Would this be a performance optimization for those requests that can be served from cache? In other words, are you proposing to cache not only the content but also some aspects of the rule processing results for that content? Andre From owner-ietf-openproxy@mail.imc.org Fri Jul 25 12:01:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10302 for ; Fri, 25 Jul 2003 12:01:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g513-0001SF-00 for opes-archive@ietf.org; Fri, 25 Jul 2003 12:01:57 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19g50y-0001S5-00 for opes-archive@ietf.org; Fri, 25 Jul 2003 12:01:54 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PFmgqt069525 for ; Fri, 25 Jul 2003 08:48:42 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6PFmgda069524 for ietf-openproxy-bks; Fri, 25 Jul 2003 08:48:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PFmfqt069519 for ; Fri, 25 Jul 2003 08:48:41 -0700 (PDT) (envelope-from info@utel.net) Received: from f01v-28-141.d0.club-internet.fr ([212.195.247.141] helo=jfc2.utel.net) by hosting.altserver.com with esmtp (Exim 4.20) id 19g4oA-0004V0-JL; Fri, 25 Jul 2003 08:48:39 -0700 Message-Id: <5.2.0.9.0.20030725172454.09e16110@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 25 Jul 2003 17:25:30 +0200 To: Alex Rousskov , Markus Hofmann From: jfcm Subject: Re: draft-beck-opes-irml-03.txt Cc: OPES WG In-Reply-To: References: <3F20454E.9090706@mhof.com> <3EF8CADD.2060201@bell-labs.com> <3EF905A5.9000100@mhof.com> <3F0087EF.6020805@bell-labs.com> <3F20454E.9090706@mhof.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 23:58 24/07/03, Alex Rousskov wrote: >I will try to show that XML presents virtually no advantages compared to a >domain specific language and introduces significant hurdles. Total agreement. jfc From owner-ietf-openproxy@mail.imc.org Fri Jul 25 13:28:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13276 for ; Fri, 25 Jul 2003 13:28:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g6MQ-0002BL-00 for opes-archive@ietf.org; Fri, 25 Jul 2003 13:28:06 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19g6MP-0002BI-00 for opes-archive@ietf.org; Fri, 25 Jul 2003 13:28:05 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PHG5qt072287 for ; Fri, 25 Jul 2003 10:16:05 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6PHG5Oc072286 for ietf-openproxy-bks; Fri, 25 Jul 2003 10:16:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PHG3qt072281 for ; Fri, 25 Jul 2003 10:16:03 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.8/8.12.8) with ESMTP id h6PHCbD2030271; Fri, 25 Jul 2003 11:12:37 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.8/8.11.6) with ESMTP id h6PH2LRW006010; Fri, 25 Jul 2003 11:02:21 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id h6PH2K7F006006; Fri, 25 Jul 2003 11:02:20 -0600 Date: Fri, 25 Jul 2003 11:02:20 -0600 Message-Id: <200307251702.h6PH2K7F006006@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: markus@mhof.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage <3F21307E.3040000@mhof.com> Subject: Re: draft-beck-opes-irml-03.txt Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Once compiled, the rules can be executed with great efficiency. There are a couple of forms that must be excluded, but the statement that the processor would "easily" become a bottleneck is not true. Hilarie > The Purple Streak, Hilarie Orman wrote: > > The elements needed are regular expressions based on tokens; > While it would be very helpful to have regular expressions, parsing > rules and handling of rules with regular expressions can be quite > expensive wrt processing capacity required - an OPES processor with a > large number of such rules could easily become a bottleneck... > It's a tradeoff between flexibility and performance. > -Markus From owner-ietf-openproxy@mail.imc.org Fri Jul 25 13:48:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13648 for ; Fri, 25 Jul 2003 13:48:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g6fm-0002HK-00 for opes-archive@ietf.org; Fri, 25 Jul 2003 13:48:06 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19g6fl-0002HD-00 for opes-archive@ietf.org; Fri, 25 Jul 2003 13:48:05 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PHaUqt073296 for ; Fri, 25 Jul 2003 10:36:30 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6PHaUuE073295 for ietf-openproxy-bks; Fri, 25 Jul 2003 10:36:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PHaTqt073288 for ; Fri, 25 Jul 2003 10:36:29 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.8/8.12.8) with ESMTP id h6PHX0D2031035; Fri, 25 Jul 2003 11:33:00 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.8/8.11.6) with ESMTP id h6PHMjRW007123; Fri, 25 Jul 2003 11:22:45 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id h6PHMi7J007119; Fri, 25 Jul 2003 11:22:44 -0600 Date: Fri, 25 Jul 2003 11:22:44 -0600 Message-Id: <200307251722.h6PHMi7J007119@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: abeck@bell-labs.com Cc: ietf-openproxy@imc.org, markus@mhof.com In-reply-to: Yourmessage <3F2144AE.30900@bell-labs.com> Subject: Re: draft-beck-opes-irml-03.txt Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Andre Beck , writes: > Hilarie, > > The rules language should not be a programming language - it should be > > a constrained language that can be compiled into efficient runtime > > dispatches. XML seems like a reasonable way to represent rules, > > prior to compilation. > I agree. > > However, I believe that the constraint of triggering only a single > > action is too severe. It is important to be able to specify > > sequencing: e.g., action1, then action2. > I agree again. IRML already supports just that: it lets you specify one > or more OPES services that are to be executed in the specified order. > However, there still has to be a policy that determines how to order > service execution requests from different rule authors. Or even from the same author? There are many possible policies, but it might be good enough to say to order them by two metrics: most specific pre-condition match and specific ordering. Rules can have ordering metrics of "always first" "always last" "first of equal specificity", "last of equal specificity". > > I am a proponent of an approach that supports detailed parsing of > > cached content. In this model, the OPES processor would take the > > content-related rule elements and compile them into a single parsing > > routine. This code might run on an OPES helper machine. The OPES > > processor would then attach the parsed attributes to cached items. > > Requests for such items would trigger OPES rules related to requestor > > profiles; the rules would determine which OPES services were to be > > applied to the cached items (such as, delivering an already modified and > > cached item, or applying further customization to such an item, or blocking > > the item). > Would this be a performance optimization for those requests that can be > served from cache? In other words, are you proposing to cache not only > the content but also some aspects of the rule processing results for > that content? I'm planning on caching results of doing checks of the precondition clauses. For example, if a precondition is http:originatingsite =~*.troubletrouble.com then the cached content may get a tag of "precondition3881" entered into its "directory" entry (the 3881 is an arbitrary number assigned to the precondition, thus making the precondition into a boolean variable). Hilarie From owner-ietf-openproxy@mail.imc.org Fri Jul 25 15:31:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18152 for ; Fri, 25 Jul 2003 15:31:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g8HT-0002tv-00 for opes-archive@ietf.org; Fri, 25 Jul 2003 15:31:07 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19g8HS-0002tr-00 for opes-archive@ietf.org; Fri, 25 Jul 2003 15:31:06 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PJK1qt079321 for ; Fri, 25 Jul 2003 12:20:01 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6PJK1ji079320 for ietf-openproxy-bks; Fri, 25 Jul 2003 12:20:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PJJxqt079297 for ; Fri, 25 Jul 2003 12:19:59 -0700 (PDT) (envelope-from markus@mhof.com) Received: from mhof.com (unknown[135.104.20.70](misconfigured sender)) by comcast.net (sccrmhc13) with SMTP id <2003072519195501600aaleie> (Authid: mhofmann); Fri, 25 Jul 2003 19:19:55 +0000 Message-ID: <3F2182DE.4060301@mhof.com> Date: Fri, 25 Jul 2003 15:19:58 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030612 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES WG CC: rousskov@measurement-factory.com, Martin Stecher Subject: Re: HTTP adaptation draft version head_sid13 available References: <3F15B8B4.3040404@mhof.com> In-Reply-To: <3F15B8B4.3040404@mhof.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Martin, Alex, since there were no objections, please go ahead and submitthe latest version of the "HTTP adaptation with OPES" Intrnet Draft as OPES WG document. Thanks, Markus Markus Hofmann wrote: > > Folks, > > I suggest that the current write-up on "HTTP adaptation with OPES" (see > Alex reference below) gets adopted and published as WG Internet Draft, > from which the WG will continue to work on. > > Unless someone objects by Friday 7/25, I'd ask Alex and Martin to submit > the "HTTP adaptation with OPES" document for publication as WG ID. > > Please note that publication as WG draft does *not* imply that the > document is finished. The WG will continue to work on the document and > discuss it on this mailing list. > > Thanks, > Markus > > Alex Rousskov wrote: > >> >> The "HTTP adaptation with OPES" draft will document all HTTP-specific >> things related to OPES core modules: tracing, bypass, and OCP. The >> latest snapshot is at >> >> http://www.measurement-factory.com/tmp/opes/ >> >> This draft has not been promoted to the WG status. >> Please contribute. >> >> Thank you, >> >> Alex. >> >> >> Appendix B. Change Log >> >> head-sid13 >> >> * Removed HTTP-transaction profile, added optional parts as >> feature parameters, added example. >> >> >> > >