From owner-ietf-openproxy@mail.imc.org Mon Nov 3 01:43:47 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09015 for ; Mon, 3 Nov 2003 01:43:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGYRO-0000uA-00 for opes-archive@ietf.org; Mon, 03 Nov 2003 01:43:54 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AGYRO-0000u6-00 for opes-archive@ietf.org; Mon, 03 Nov 2003 01:43:54 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA36JZkT058262 for ; Sun, 2 Nov 2003 22:19:35 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA36JZG7058261 for ietf-openproxy-bks; Sun, 2 Nov 2003 22:19:35 -0800 (PST) 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.10/8.12.8) with ESMTP id hA36JXkT058246 for ; Sun, 2 Nov 2003 22:19:33 -0800 (PST) (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 hA36JaGh088330 for ; Sun, 2 Nov 2003 23:19:36 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hA36JQiK088329; Sun, 2 Nov 2003 23:19:26 -0700 (MST) (envelope-from rousskov) Date: Sun, 2 Nov 2003 23:19:26 -0700 (MST) From: Alex Rousskov To: OPES WG Subject: Re: OCP Core updates In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: FYI: OCP Core draft does not have any XXXs left. Please see Change Log for a list of recent changes. There are a few new issues that are worth discussing but I left them out of the draft for now in case we decide it is time for a last call instead. Alex. On Fri, 31 Oct 2003, Alex Rousskov wrote: > > Many editorial changes and a few important bug fixes were applied to > the last published OCP Core draft. The current version, along with the > change log, is available at > http://www.measurement-factory.com/tmp/opes/ > as usual. Please use the current version if you are reviewing the > draft. > > I intend to continue working on the draft over the weekend, making > mostly editorial changes. Most known major issues are resolved, and > only a few XXXs remain. > > Please let me know if you have any questions or concerns. > > Thank you, > > Alex. > From owner-ietf-openproxy@mail.imc.org Mon Nov 3 14:14: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 OAA15442 for ; Mon, 3 Nov 2003 14:14:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGk9d-0002n7-00 for opes-archive@ietf.org; Mon, 03 Nov 2003 14:14:22 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AGk9d-0002n4-00 for opes-archive@ietf.org; Mon, 03 Nov 2003 14:14:21 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3IvZkT046140 for ; Mon, 3 Nov 2003 10:57:35 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA3IvZhq046139 for ietf-openproxy-bks; Mon, 3 Nov 2003 10:57:35 -0800 (PST) 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.10/8.12.8) with ESMTP id hA3IvXkT046134 for ; Mon, 3 Nov 2003 10:57:33 -0800 (PST) (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 hA3IvYGh005585; Mon, 3 Nov 2003 11:57:34 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hA3IvYox005584; Mon, 3 Nov 2003 11:57:34 -0700 (MST) (envelope-from rousskov) Date: Mon, 3 Nov 2003 11:57:34 -0700 (MST) From: Alex Rousskov To: "OPES WG (E-mail)" Subject: Re: OCP/HTTP sample updated In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D0E65EF@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D0E65EF@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: Martin, I believe this example should be incorporated into HTTP Adaptations draft, perhaps as a new "Example" section. Is there a reason you did not want it in the draft? Alex. On Mon, 20 Oct 2003, Martin Stecher wrote: > > Hi, > > I updated the example I once created. > http://www.martin-stecher.de/opes/sample1.html > > Now it reflects all changes we did during the last months, regarding syntax and new parameters. > > Please tell me if you find errors. > > Regards > Martin > > From owner-ietf-openproxy@mail.imc.org Mon Nov 3 19:07:41 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04777 for ; Mon, 3 Nov 2003 19:07:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGojf-00018h-00 for opes-archive@ietf.org; Mon, 03 Nov 2003 19:07:51 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AGoje-00018d-00 for opes-archive@ietf.org; Mon, 03 Nov 2003 19:07:50 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3NrPkT057157 for ; Mon, 3 Nov 2003 15:53:25 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA3NrPKe057156 for ietf-openproxy-bks; Mon, 3 Nov 2003 15:53:25 -0800 (PST) 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.10/8.12.8) with ESMTP id hA3NrNkT057151 for ; Mon, 3 Nov 2003 15:53:23 -0800 (PST) (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 hA3NrPGh013957; Mon, 3 Nov 2003 16:53:25 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hA3NrPA9013956; Mon, 3 Nov 2003 16:53:25 -0700 (MST) (envelope-from rousskov) Date: Mon, 3 Nov 2003 16:53:25 -0700 (MST) From: Alex Rousskov To: OPES Group Subject: Re: WG Last Call: draft-ietf-opes-end-comm-05 In-Reply-To: <3F96BEA8.4090400@mhof.com> Message-ID: References: <3F96BEA8.4090400@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 22 Oct 2003, Markus Hofmann wrote: > We are starting WG last call on the "OPES entities and end points > communication" draft (see attached). The last call period closes on > Wednesday, November 5 at 5pm EST. Please post any comments, etc. to > the mailing list, and please point out whether you feel your comment > is editorial or a show-stopper. My comments are below. Original text is quoted with ">". Discussion and comments is surrounded by square [brackets]. Suggested text replacements are indented and not quoted/surrounded. Editorial/showstopper comments are prefixed with "E/S" tags followed by the issue number for ease of reference. Note that I am not always 100% sure what is the difference between the two categories; there are too many dependencies and uncertainties in some cases. > Network Working Group A. Barbir [S1: wrong working group?] > 3. Requirements for OPES Tracing . . . . . . . . . . . . . . . . 5 [E1: given section titles for section 3.1-4, the above reads as if "OPES Tracing" is an OPES Entity. Also, the whole draft scope is OPES so we do not have to repeat it all the time. Suggested replacement:] 3. Tracing Requirements . . . . . . . . . . . . . . . . 5 > 4. Requirements for OPES System Bypass (Non-blocking feature) . . 8 [E2: same as E1, plus it is not only the system that is being bypassed (in fact, I would argue that the system cannot be bypassed at all). Suggested replacement:] 4. Bypass Requirements . . . . . . . . . . . . . . . . 8 > 3.1 What is traceable in an OPES Flow? . . . . . . . . . . . . . . 5 > 4.1 What can be bypassed in an OPES Flow? . . . . . . . . . . . . 8 [E3: The whole draft scope is OPES Flow. Please say it once in draft scope statement and drop "OPES Flow" from the rest of the text. Otherwise, the reader expects to see a "What is traceable outside of the OPES Flow?" Suggested replacements:] 3.1 Traceable entities . . . . . . . . . . . . . . 5 4.1 Bypassable entities . . . . . . . . . . . . . . 8 > This work specifies the requirements for providing tracing > functionality for the OPES architecture [8]. [E4: simplify; something along these lines:] This work specifies OPES tracing functionality. > Tracing functionality enables a data provider or a data consumer > application to detect inappropriate actions that are performed by > OPES entities. [S2: Tracing does not enable end points to *detect* inappropriate actions] > The work also develops requirements that can be used to fulfill IAB > Notification and Bypass (Non-Blocking) requirements [2]. [E5: simplify and do not mention IAB as an excuse since you did not mention it when talking about tracing functionality requirements:] This work also specifies OPES bypass functionality. > The architecture document requires [8] that tracing is supported > in-band. This design goal limits the type of application protocols > that OPES can support. The details of what a trace record can > convey are also dependent on the choice of the application level > protocol. > For these reasons, this work documents requirements for application > protocols that need to support OPES traces and non-blocking > mechanism. The architecture does not prevent implementers of > developing out-of-band protocols and techniques to address these > limitation. [E6: Merge the above two paragraphs] > this work documents requirements for application protocols that > need to support OPES traces and non-blocking mechanism. [S28b: Where are the requirements for application protocols? I can only see requirements for OPES entities.] > The architecture does not prevent implementers of developing [E8a: "... from developing" ?] > In this document the key words that are used to signify > requirements are based on RFC 2119 [3]. [S3: Quote the recommended text from RFC 2119] [E7: Specify whether case is important for RFC 2119 keywords identification. See OCP Core for example if needed] > Definition: An OPES System is a set of all OPES entities [8] > authorized by either the data provider or the data consumer > application to process a given application message. [E8b: Note that [8] does not define OPES processor as an OPES entity. [8] defines a "data dispatcher" as an OPES entity. Consider redefining entity explicitly and removing reference to [8] from the above.] > the CDN uses to adapt and deliver the message comprise an OPES [E9: "and deliver the image" ?] > System. In a more complex example, an OPES System would contain CDN > entries [E10: "would contain CDN entities" ?] > In an OPES System tracing is defined as the inclusion of necessary > information within a message in an OPES Flow that identify the > collection of transformations or adaptations that have been > performed on it before its delivery to an end point (for example, > the data consumer application). [S4: The above definition is probably incorrect and is very awkward. It is incorrect because "inclusion of information" is not the only tracing activity. As we define below, exclusion or merging of trace entries is also a tracing activity. Also, it is not clear whether the "tracing" is the "inclusion" itself or the "process of inclusion" or, perhaps a "result of inclusion"?] > an end point (for example, the data > consumer application). [E11: Throughout the document: define "end point" once and avoid repeating "(for example, the data ... application)" every time the text says "end point". This just makes definitions and requirements longer.] > An OPES trace represents a snap shot of the > tracing information that have been added to a given application > message. [S4b: Depending on the S4-related definition, this may need to be revised. Overall, it is still not clear what an OPES trace is!] > A trace represents the collections of transformations on an > application message in the order that were performed. [S5: A collection of transformations or a collection of OPES entity IDs?] [S6: The order the transformations were performed or the order of which entities got traversed? If two callout services are working on the same message in a pipeline mode, which one will be listed first? The one that got called first? The one that received the call first? The one that finished first?] > A traceable entity can appear multiple times in a trace (every time > it acts on a message). [E12: insert "for example, " before "every time it acts". We allow for trace entries to be merged or to be missing.] > A data consumer application can use OPES trace to infer the actions > that have been performed by the OPES System. Actions are the set of > OPES services that were performed by OPES entities in an OPES > System. [S7: A trace does not document actions, only service invocations] > o Providers may be hesitant to reveal information about their > internal network infrastructure. [E13: simplify:} o Providers may hesitate to ... > o Within a service provider network, OPES processors may be > configured to use non-routable, private IP addresses. [E14: Why is this relevant here? We do not require IP addresses to be included in a trace, do we? We do not even encourage that, right?] > o A data consumer applications would prefer to have a single point > of contact regarding the trace information. [E15: "A data consumer application" not "applications" ] > In an OPES System some OPES services are message-agnostic and operate > on message content or parts of a message. Such services do not > manipulate message headers. Other services can manipulate message > headers. [E16: What is the reason for including the above text. In other words, "so what?". The text below does not seem to be related.] > OPES providers require some freedom in the way they deliver > tracing information to an end point. [E17: Not clear what "ways" you are referring to. In-band versus outband?] > Tracing information provides a data consumer application (or a data > provider application) with information about OPES entities that > adapted the data. [E18: simplify:] A trace provides endpoint application with information about OPES entities that adapted the data. > There are two distinct uses of OPES traces. First, > a trace enables an "end (content provider or consumer) to detect the > presence of OPES processors within an OPES System. Such "end" should [E19: missing quote after "end]. [S8a: IMO, a trace enables an endpoint to detect presence of an OPES System. Detection of OPES processors is a SHOULD-dependent feature not a MUST-dependent guarantee.] > Such "end" should > be able to see a trace entry, but does not need to be able to > interpret it beyond identification of the OPES System. [S8b: This sentence is a case in point for S8a above] > Since the administrators of various OPES Systems can have various > ways of looking into tracing, they require the choice of freedom in > what to put in trace records [E20: can you rephrase "ways of looking into tracing" to clarify the intent here?] [E21: simplify: replace "choice of freedom" with "freedom"] > and how to format them. [S9: We do not provide formatting freedom for trace entries to "administrators", do we?] > Trace records > should be easy to extend beyond basic OPES requirements. Trace > management algorithms should treat trace records as opaque data to > the extent possible. [E22a: How is the above relevant to this section? Same for S9 text]. > At the implementation level, for a given trace, an OPES entity > involved in handling the corresponding application message is > traceable or traced if information about it appears in that trace. [S10: Please answer the Section Title question explicitly. What is traceable? Give a list of entities if that is the best way to answer that question. The above text is OK but it does not answer the question on trace-independent level. What can be traced?] > OPES entities have different levels of traceability requirements. > Specifically, [S11: missing (misplaced?) an OPES System requirement:] o An OPES System MUST add its entry to the trace. > o An OPES processor MUST add its entry to the trace. [S12: I believe this should be a SHOULD, given the OPES System MUST-level requirement above (S11), the fact that processor is not clearly defined, the fact that there could be dozens of processors, and that we (should) allow processor entries to be merged/deleted] > o An OPES service MAY add its entry to the trace. [E22b: How is the above relevant to this section?]. > o An OPES entity MAY delegate addition of its trace entry to another > OPES entity. For example, an OPES System can have a dedicated OPES > processor for adding System entries; an OPES processor can use a > callout service to manage all OPES trace manipulations (since such > manipulations are OPES adaptations). [E22c: How is the above relevant to this section?]. > It is the responsibility of the operator to resolve the problems. [E23: add "to decode trace details and " before "to resolve"] > o An OPES System MUST trace itself. [S11b: See S11. Either all existing "MUST add its entry" MUSTs above are misplaced and should go to its own section OR this MUST should not be here and should be grouped with others.] [E24: keep format similar to other MUSTs:] o An OPES System MUST add its entry to the trace. > o An OPES System MUST include information about its privacy policy. > o An OPES System MUST identify the party responsible for setting and > enforcing that policy. [E25: group in one:] o An OPES System MUST include information about its privacy policy, including identity of the party responsible for setting and enforcing the policy. > o An OPES System MUST include information that identifies, to the > technical contact, the OPES processors involved in processing the > message. [S13: If processor tracing is a SHOULD, the above cannot be a MUST. See S12] [E26: identifies all OPES processors involved? some OPES processors involved? How is this requirement related to "An OPES processor MUST add its entry to the trace."? Are they equivalent?] > This specification does not define the meaning of the terms privacy > policy, policy enforcement, or technical contact and contains no > requirements regarding encoding, language, format, or any other > aspects of that information. [E27: Paragraph ends here] > Furthermore, an example of System > identification would be something like http://www.examplecompany.com/ > opes/?client=example.com. [E28: delete "furthermore" and be more specific:] For example, a URI used for an OPES System trace entry may look like "http://www.examplecompany.com/opes/?client=example.com" where the identified web page is dynamically generated and contains the all OPES System information required above. > o OPES processor MUST add its unique identification to the trace. > Here, uniqueness scope is the OPES System containing the > processor. [S12b: How is this related/different from a MUST referenced by S12 above? We should not have two overlapping (nearly identical) MUSTs. See S12 regarding MUST versus SHOULD.] [S14: "MUST add" for each invocation? once for all invocations? > o OPES processor MUST be able to trace it's own invocation and > service(s) execution. [S15: How does "trace it's own invocation" different from the previous MUST? See S12b.] [S16: What is a service execution? Is it different from service invocation as this MUST seem to imply?] [S17: Is "be able" a key here? Can it be removed without changing the requirement meaning? If not, what do you mean by "be able"? Can a processor be configured not to add these entries and be compliant in such a configuration?] > In an OPES system, it is the task of an OPES processor to add trace > records to application messages. However, in some cases, callout > servers may add trace information to application messages. This > should be done under the control of the OPES System provider. [E29: What exactly should be done under the control of the OPES System provider? What does it mean to do something "under the control of the OPES System provider"? Isn't everything on the provider side done under provider's control?] > In addressing IAB consideration (3.3), one need to specify what > constitute non-OPES content. [E30: "what constitutes" not "what constitute" ] > In this work the definition of "non-OPES" content is provider > dependent. However, in some cases, the availability of "non-OPES" > ... [E31: Replace "However, in some cases," with "For example, " and edit accordingly because what your case is just an example of a provider dependency. If you disagree that it is an example/subcase, please rephrase so that the difference between the two is clear.] > The above examples illustrates that the availability of non-OPES [E32: There is only one example above, right?] > In an OPES System a bypass request is defined as the act of avoiding [S18: A request to avoid is not an act of avoiding] > the invocation of a service(s) that is identified by a URI within a > message in an OPES Flow before its delivery to an end point (for > example, the data consumer application). The availability of non-OPES > content is a precondition to whether a bypass instruction is honored > or not in an OPES System. [S19: Does bypass semantics mean "give OPES version if non-OPES is not available" or "give an error if non-OPES is not available"? This is very important to document clearly because it affects bypass design/rules a lot.] > In the general case, a bypass request is viewed as a bypass > instruction that contains a URI that identifies an OPES entity or a > group of OPES entities that perform a service (or services) to be > bypassed. [S20: But we define bypass for OPES processors, not just services. Is processor "an OPES entity that performs a service"? Most requirements seem to apply that it is not possible to bypass a processor itself. Is it?] > instruction may contain more than one such URI. A special wildcard > identifier can be used to represent all possible URIs (i.e., all > possible OPES services that are relevant to an OPES processor). [S21: Does not wildcard identify all possible services and not only services that are relevant (known?) to an OPES processor? If yes, please delete the "i.e." part. If no, please define "relevant".] > In an OPES Flow, a bypass request is processed in a local manner by [E33: remove "local manner"] > each involved OPES processor. This means that an OPES processor > examines the bypass instruction and if non-OPES content is available, > the processor then bypasses services that are local to itself. [E34: What does "local to itself" mean?] > This > may include the act of bypassing itself completely depending on what > is specified in the URI. [S22: But processor is not a service so "may include" does not seem to apply to it because the above you say "bypasses services".] [S23: We need to define what "bypassing self completely" means. I am not sure how anything can bypass itself completely.] > At the OPES system level, a bypass instruction is honored when at > least one OPES processor bypasses the services that are specified > by the URI that is specified in the instruction (provided that the > non-OPES content is available). [S24: Does it mean that honoring a bypass of "*" it is sufficient to bypass one our of 100 services? If yes, I disagree that it is a good definition. If no, the above should be reworded.] [S25: So, what can be bypassed? What does it mean to bypass X? Please also see S10 for a related concern. We are not answering our own questions.] 4.2 Bypass requirements for OPES System > In an OPES System bypass requests are generally client centric and go [E35: what does "client centric" mean in this context? Originated by data consumer?] > Bypass can be performed out of band or in-band. This work requires > that the Bypass feature be performed in-band [E36: The above two sentences contradict each other. If we require that bypass is in-band, it cannot be performed out-of-band by a compliant OPES implementation. Please rephrase.] > o An OPES system MUST support a Bypass feature. This means that the > OPES System bypasses an entity whose URI is identified by an OPES > end (usually data consumer application). [S26: When more than one URI is specified, does OPES System need to bypass every entity, most entities, or just one entity? "*" URI is a test case here.] > why they ignored the bypass instruction. It is important to note that > in some cases the tracing facility itself may be broken and the whole > OPES System (or part) may need to be bypassed through the issue of a > bypass instruction. [E37: How is it possible to bypass the whole OPES System if only the OPES System is bypass-aware?] > For a given application protocol, in an OPES System there can be > services that operate on application message headers and those that > just operate on content. This mix of service requires that an OPES [E38: It is not the mix that requires, it is the existence of "services that operate on content"] > In some cases, the first OPES processor that will get the bypass > request may not be the first OPES processor that will know whether > a non-OPES version of the content is available or not. [E39: what does that imply? That is, why mention it?] > Bypass requirements for OPES processors are (the availability of a > non-OPES content is a precondition): ... > Provided that non-OPES content is available, [S27: What are the requirements if no non-OPES content is available?] 4.4 Bypass requirements for callout servers > This should be done under the control of the OPES System provider. [E29b: Please see E29 for this comment] > This work specifies high level requirements for tracing and bypass. > Protocol binding specifications MUST consider and follow all MUSTs in > this draft. [S28: There are no MUSTs for Protocol binding specifications in the draft as far as I can see. We have MUSTs for OPES entities only.] > Protocol binding specifications MUST be compliant to this > draft. [S29: You cannot require that something is compliant. You can only define what it means to be compliant. See OCP Core for an example of a Compliance Considerations section.] [S30: Do you intentionally exclude SHOULDs from compliance requirements? As of now, an implementation may violate every SHOULD and call itself compliant. We should discuss whether that's a good thing.] > document is a requirement document for tracing and Bypass feature. [E40: "features"; also "Bypass" capitalization seems inconsistent with the rest of the draft] > There are risks for the OPES System by non-OPES entities, whereby, > these entities can insert bypass instructions into the OPES Flow. The > threat can come from compromised non-OPES entities. The threat might > affect the overall integrity and effectiveness of an OPES System. For > example, a non-OPES proxy can add bypass instruction to bypass > legitimate OPES entities. The attack might result in overwhelming the > original content provider servers, since the attack essentially > bypass any load balancing techniques. In addition, such an attack is > also equivalent to a DoS attack, whereby, a legitimate data consumer > application may not be able to access some content from a content > provider or its OPES version. > Since an OPES Flow may include non-OPES entities, it is susceptible > to man-in-the-middle attacks, whereby an intruder may inject bypass > instructions into the data path. These attacks may affect content > availability or disturb load balancing techniques in the network. [E41: Is the second paragraph already covered in the first paragraph?] > The above threats can also arise by compromised OPES entities. An > intruder can compromise an OPES entities and then use > man-in-the-middle techniques to disturb content availability to a > data consumer application or overload a content provider server > (essentially, some form of a DoS attack). > Attackers can use the bypass instruction to affect the overall > integrity of the OPES System. The ability to introduce bypass > instructions into a data flow may effect the accounting of the OPES > Normative References > > [1] A. Barbir et al., "OPES Use Cases and Deployment Scenarios", > Internet-Draft http://www.ietf.org/internet-drafts/ > draft-ietf-opes-scenarios-01.txt, August 2002. [E42: Can a Scenarios document be normative? In what way?] > Informative References > [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement > Levels", RFC 2119, March 1997. [E43a: This should be a normative reference] > [6] Rousskov, A. et al, "HTTP adaptation with OPES", Internet-Draft > http://www.ietf.org/internet-drafts/draft-ietf-opes-http-00.txt, > July 2003. [E44a: Please update] > [8] A. Barbir et al., "An Architecture for Open Pluggable Edge > Services (OPES)", Internet-Draft http://www.ietf.org/ > internet-drafts/draft-ietf-opes-architecture-04, December 2002. [E43b: This should be a normative reference] > [9] A. Barbir et al., "OPES Treatment of IAB Considerations", > Internet-Draft http://www.ietf.org/internet-drafts/ > draft-ietf-opes-iab-02.txt, September 2003. [E44b: Please update] [S31: Did I miss a place in the spec were we allow for manipulation of trace entries such as merging or deleting callout service entries? I remember we used to say that, but I do not see that text now.] Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Tue Nov 4 15:18: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 PAA03373 for ; Tue, 4 Nov 2003 15:18:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH7dn-0004Wc-00 for opes-archive@ietf.org; Tue, 04 Nov 2003 15:19:03 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AH7dm-0004WY-00 for opes-archive@ietf.org; Tue, 04 Nov 2003 15:19:03 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4JxRkT070323 for ; Tue, 4 Nov 2003 11:59:27 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4JxQIQ070322 for ietf-openproxy-bks; Tue, 4 Nov 2003 11:59:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail2.webwasher.com (host2.webwasher.com [217.146.159.49]) by above.proper.com (8.12.10/8.12.8) with SMTP id hA4JxNkT070313 for ; Tue, 4 Nov 2003 11:59:25 -0800 (PST) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id I5NOBYGV outgoing id P0O5GM6S; 04 Nov 2003 23:06:36 +0100 Received: from jadzia ([10.2.0.81]) by mail.WEBWASHER.COM with Microsoft SMTPSVC(5.0.2195.6713); Tue, 4 Nov 2003 20:59:08 +0100 Message-ID: <007e01c3a30e$1ac518a0$9527eed9@jadzia> From: "Martin Stecher" To: "Alex Rousskov" , "OPES WG \(E-mail\)" References: <75F7E67FC45F6744A7D328D41E35376D0E65EF@mail.webwasher.com> Subject: Re: OCP/HTTP sample updated Date: Tue, 4 Nov 2003 20:59:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 04 Nov 2003 19:59:08.0902 (UTC) FILETIME=[1BDFB060:01C3A30E] Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Alex, of course examples in the draft are very helpful. But I am unsure whether an adstripping example is the best choice. Actually I planned for a number of examples that I wanted to make available and then pick the one or two best for the draft. I didn't find the time yet. Regards Martin ----- Original Message ----- From: "Alex Rousskov" To: "OPES WG (E-mail)" Sent: Monday, November 03, 2003 7:57 PM Subject: Re: OCP/HTTP sample updated > Martin, > > I believe this example should be incorporated into HTTP > Adaptations draft, perhaps as a new "Example" section. Is there a > reason you did not want it in the draft? > > Alex. > > On Mon, 20 Oct 2003, Martin Stecher wrote: > > > > > Hi, > > > > I updated the example I once created. > > http://www.martin-stecher.de/opes/sample1.html > > > > Now it reflects all changes we did during the last months, regarding syntax and new parameters. > > > > Please tell me if you find errors. > > > > Regards > > Martin > > > > > From owner-ietf-openproxy@mail.imc.org Tue Nov 4 19:00: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 TAA12206 for ; Tue, 4 Nov 2003 19:00:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHB69-00002N-00 for opes-archive@ietf.org; Tue, 04 Nov 2003 19:00:33 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AHB68-00002K-00 for opes-archive@ietf.org; Tue, 04 Nov 2003 19:00:33 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4NnekT077809 for ; Tue, 4 Nov 2003 15:49:40 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4Nnegu077808 for ietf-openproxy-bks; Tue, 4 Nov 2003 15:49:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4NnckT077801 for ; Tue, 4 Nov 2003 15:49:39 -0800 (PST) (envelope-from markus@mhof.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id hA4NnefO090299 for ; Tue, 4 Nov 2003 18:49:40 -0500 (EST) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id hA4NnY0C053869 for ; Tue, 4 Nov 2003 18:49:34 -0500 (EST) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id hA4NnXFU015601 for ; Tue, 4 Nov 2003 18:49:33 -0500 (EST) Message-ID: <3FA83B3F.2020005@mhof.com> Date: Tue, 04 Nov 2003 18:50:23 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: OPES Agenda 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, below the proposed agenda for our upcoming OPES WG meeting in Minneapolis. -Markus ----------------------------------------------------- Open Pluggable Edge Services WG (opes) ====================================== Tuesday, November 11, 1700-1800 CHAIR(S): Marshall Rose Markus Hofmann AGENDA: - Introduction, minutes taker, blue sheets - Agenda bashing - Status of WG documents - draft-ietf-opes-architecture-04 - draft-ietf-opes-protocol-reqs-03 - draft-ietf-opes-scenarios-01 - draft-ietf-opes-authorization-02 - draft-ietf-opes-threats-02 - Discussion on open issues with WG documents - draft-ietf-opes-iab-03 - draft-ietf-opes-end-comm-05 - draft-ietf-opes-ocp-core-02 - draft-ietf-opes-http-01 - draft-ietf-opes-rules-p-02 From owner-ietf-openproxy@mail.imc.org Thu Nov 6 12:24:44 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19264 for ; Thu, 6 Nov 2003 12:24:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHnsN-0004V3-00 for opes-archive@ietf.org; Thu, 06 Nov 2003 12:24:55 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AHnsM-0004Ut-00 for opes-archive@ietf.org; Thu, 06 Nov 2003 12:24:55 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6H8ckT019315 for ; Thu, 6 Nov 2003 09:08:38 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6H8cNR019314 for ietf-openproxy-bks; Thu, 6 Nov 2003 09:08:38 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6H8akT019308 for ; Thu, 6 Nov 2003 09:08:36 -0800 (PST) (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 hA6H8bGh010901 for ; Thu, 6 Nov 2003 10:08:37 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hA6H8bIt010900; Thu, 6 Nov 2003 10:08:37 -0700 (MST) (envelope-from rousskov) Date: Thu, 6 Nov 2003 10:08:37 -0700 (MST) From: Alex Rousskov To: OPES WG Subject: OCP Core issues for f2f discussion In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D0E66D9@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D0E66D9@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: Hi, Here are some OCP Core issues that may be worth discussing at the upcoming F2F meeting. Since I will not be at the meeting, I provided my current opinions on every issue. Please do not treat this list as a formal request to add all of the items below to the agenda. These are just suggestions. Meeting participants should decide among themselves what, if anything, here is worth discussing in Minneapolis. 1. Agent authentication negotiation. Should it be documented in the Core? Should it be required? My current opinion is that there should be a separate OCP Security draft because there are several standard ways to do authentication and at least two can be covered. Also, in-band authentication should not be optional which makes documenting such a big and independent feature in Core inappropriate. My second choice for placing this stuff would be a Core Appendix. However, I expect such Appendix introduce IANA considerations (registered URIs and such), and that is awkward to do in the Appendix. Also, it will delay last call for the Core. 2. OCP connection encryption negotiation. Should it be documented in the Core? Should it be required? My current opinion is the same as in #1, for same reasons. Note that it is common to have security covered in a separate draft(s). HTTP does that, for example (RFC 2616, 2617). 3. Should OCP Core contain a full adaptation example? It would have to be application-specific. IMO, OCP Core can refer to a full adaptation example in an adaptation draft such as HTTP Adaptation. 4. Should we solicit IETF SIRs review before going into last call? I would rely on chairs' opinion here. 5. OCP Core spends a lot of ink documenting application message identifiers (am-ids) in various contexts. There are original and adapted am-ids. HTTP does not use any am-ids, essentially. We do not know of any protocol that would need original am-id, but we still keep it so that processor and server sides are symmetric. The only reason to have adapted am-ids is to support SMTP and other protocols that may have multiple adapted dataflows for a single original dataflow. Yet, we have no experience whether Core has enough stuff to accomodate SMTP and similar needs. Should we yank am-ids from the core and rely on OCP extension mechanisms if/when we start supporting SMTP? To make future extensions easier, we can replace current "xid am-id" pair of anonymous parameters with a single anonymous {xid} structure so that new members (e.g., am-id) can be added to the structure without changing the overall look and feel of any am-related message. IMO, it may be a good idea to get rid of am-ids in Core, but I am not sure at all and would like to hear others' comments. 5a. Should we stuff all related anonymous parameters into structures? For example, "offset size" can become {offset size}. Again, the rationale would be to simplify extensions of those parameters (e.g., adding AM-Part to the structure) and to simplify extending the anonymous parameter list in case one or more existing parameters are optional. IMO, if we do the changes suggested in #5, we should do similar changes throughout the protocol. 6. Recent changes to the Core moved data preservation maintenance out of Data Use Mine/Yours commands. The rationale was that Data Use Mine/Yours commands are specific to a single adapted dataflow while data preservation maintenance applies to the original flow and, hence, to _all_ adapted flows. We should not confuse implementors with two different scopes within a single message. For example, callout server's preservation interest is now expressed in a Data Preservation Interest (DPI) message that refers to original dataflow only: DPI: extends message with { xid org-am-id org-offset org-size; }; This used to be a part of the Data Use Mine/Yours message (Wont-Use and similar parameters). The problem with this approach is a loss of simple optimization opportunities. Before, a Data Use Yours message with a Wont-Use parameter would allow the processor (recipient) to send the data out and free the data as it sends. Now, the processor has two choices: (a) send the specified data out and wait for a DPI message to free the data later; and (b) look ahead in hope to find a DPI message right after the DUY message and free as it sends if a DPI message follows. The difference between freeing eventually and while-you-send may be important. Depending on an implementation, gradual freeing might mean 50% more buffer space available (on average) to share among data streams. Look-ahead optimization sounds rather complex and error-prone to me. Question: what is more important here: the clarity of the protocol (the current spec is more clear) or the free-as-you-send optimization (the old spec allowed for that). Moreover, in the old spec, the preserved data could be freed by default when a Data Use Yours message is received. Thus, there were fewer chances that a callout server will "forget" to tell the processor that some data should be freed. Finally, if we go through with #5 changes, then the whole rationale for factoring out data preservation and similar information out of adapted dataflows becomes less convincing because there is only one adapted dataflow from Core point of view. On the other hand, if we go back to the original scheme, SMTP and other similar extensions would suffer from clarity point of view (the rationale would still be valid for them!). IMO, we should keep the current scheme, but I am not sure at all and would like to hear other opinions. 7. Protocol Element Type Declaration Mnemonic (PETDM) documented in Section 8 does not allow extending message semantics without renaming the message because the message name is the type name, and to extend semantics one must change the type. For example, an OCP extension cannot add a new parameter to the message without renaming it. IMO, this is wrong and must be fixed by somehow isolating message guts from message name. It should be possible to extend message.guts without renaming the message. 8. Is Appendix A "Message Summary" needed? IMO, we should keep it and add section references if the plain text rendering can fit them. 9. Should we add an index (words linked to sections where they are defined or talked about)? I do not have a strong opinion here. We could. I will post again if I can think of something else. HTH, Alex. From owner-ietf-openproxy@mail.imc.org Thu Nov 6 13:47:28 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22647 for ; Thu, 6 Nov 2003 13:47:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHpAQ-0005mz-00 for opes-archive@ietf.org; Thu, 06 Nov 2003 13:47:38 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AHpAP-0005mw-00 for opes-archive@ietf.org; Thu, 06 Nov 2003 13:47:37 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6IP3kT023081 for ; Thu, 6 Nov 2003 10:25:03 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6IP3ZW023080 for ietf-openproxy-bks; Thu, 6 Nov 2003 10:25:03 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6IP2kT023073 for ; Thu, 6 Nov 2003 10:25:02 -0800 (PST) (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 hA6IP3Gh012692 for ; Thu, 6 Nov 2003 11:25:03 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hA6IP32c012691; Thu, 6 Nov 2003 11:25:03 -0700 (MST) (envelope-from rousskov) Date: Thu, 6 Nov 2003 11:25:03 -0700 (MST) From: Alex Rousskov To: OPES WG Subject: HTTP Adaptations issues for f2f discussion 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: Hi, Here are some open HTTP Adaptations issues that may be worth discussing at the upcoming F2F meeting. I will skip issues already documented as XXXs in the draft itself. 1. Security Considerations Are there really no HTTP-specific considerations in OCP? Do things like wrong Content-MD5 checksums belong here? Also see #6,7,9 below; are those related to security considerations? 2. Scope. Do we need to clearly say (in one place) what it means to adapt HTTP? Is HTTP connection adaptation in scope? Is URL blocking or redirection in scope? Is HTTP authentication (via callout services) in scope? This sounds like a simple question, perhaps, but, as usual, scope is one of the most difficult things to define. See issues #3,5,6,7 below, for example. They are all scope-related in some way! 3. Partial Content Do we need to say anything special about adapting "206 Partial Content" HTTP responses? There are two cases here: multipart/byteranges media type and a single "part" case. multipart/byteranges are expressed via Content-Type, not Content-Encoding. Thus, we currently have no mechanism to negotiate support for those. On the other hand HTTP does have such a mechanism for its agents (if you do not support it, you do not ask for multiple parts). IMO, we should say something, even if we are not going to provide explicit support for this special content type. 4. Authentication and other sensitive information. Do we need to specify whether authentication information should be passed "as is" to callout servers by default? IMO, it should be because we pass all other "sensitive" information already. We should probably explicitly say that the processor should treat any sensitive data as regular data in this context (by default). This places stringent requirements on callout server security and trust, but that is how OPES is supposed to work. 5. FTP -> HTTP HTTP proxies that proxy ftp://host URLs have to do FTP and transform FTP messages to HTTP responses. Do we need to mention this case in some way? Is it special or out of scope (i.e., we assume that all transformations have been already performed). 6. 100 Continue 100 Continue messages are sent as a part of an HTTP transaction but they are not true "responses". What should an OPES processor do about these? Technically, they can be viewed as another original application message to be adapted within the same OCP transaction (multiple original am-ids)! If we want to avoid multiple original am-ids, but still want to adapt 100 Continue messages, we can introduce a notion of "related transactions". Each 100 Continue would cause the processor to start a new OCP transaction, related to the original one (so that the request message does not need to be resent). But, on a technical level, multiple original am-ids is exactly what is going in here, I guess. We have to say whether processor must skip them. If processor skips them, does it open a [security] whole for clients or servers to bypass OPES. These messages do not have bodies, but their headers can be used to send information that OPES entities may be interested in. 7. CONNECT method CONNECT method establishes a tunnel through the proxy. Should OPES processor adapt just the CONNECT request and response, or should it stay in the loop for the tunnel itself? If the processor stays, we do not have a good mechanism in the current draft to adapt a bi-directional tunnel, right? Tunnel adaptation is more like streaming adaptation, isn't it? That's an unchartered territory for OCP, including OCP Core. We have to be explicit what the processor is supposed to do. 8. SIRs or HTTP WG review Should we solicit SIRs and/or HTTP WG review of this. There is no formal HTTP WG, but there is a semi-alive mailing list that HTTP gurus read. 9. Concurrent request and response. What happens when the HTTP client is sending a request body _while_ the HTTP server is sending a response, and the callout server requested HTTP request body to adapt the HTTP response. Do we have a deadlock? The above can happen when the HTTP server is sending a constant response regardless of the PUT/POST body or is sending an error message. For example, an error message can say "I got 1MB of your POST request and I will not accept any more. Go away!". OPES has to adapt such a response, but it looks like we cannot until the client stops and the client may not stop for another 100MBs (because it is broken/malicious or because it does not get the error message that is waiting for our adaptation). 10. Huge request bodies and RESPMOD There is no way for the callout server to skip a huge request body when doing RESPMOD. Is that acceptable? Should OCP Core support "skip N original octets" interface (that does not affect offset/size calculations). Should HTTP draft support "skip this part until its end" interface? Instead? N.B. Does ICAP address #3,5,6,7? ICAP does not have a problem with #9 and #10 because ICAP does not allow sending request body in RESPMOD, right? Note that there are some synchronization issues between OCP Core and HTTP drafts, but they are probably not worth discussing in public. Also, some of the above issues might be too technical and HTTP-specific for the f2f meeting. Again, please pick-and-choose what you want to discuss. Thank you, Alex. P.S. I think we should have thought of some of the above issues earlier. On the other hand, I think we did discuss them briefly but ignored when it came to writing the guts of the draft. I hope we can "escape" them with little effort, but some look pretty tricky to me. From owner-ietf-openproxy@mail.imc.org Thu Nov 6 15:00:39 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26142 for ; Thu, 6 Nov 2003 15:00:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHqJF-0006zc-00 for opes-archive@ietf.org; Thu, 06 Nov 2003 15:00:49 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AHqJF-0006zW-00 for opes-archive@ietf.org; Thu, 06 Nov 2003 15:00:49 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6JjIkT026923 for ; Thu, 6 Nov 2003 11:45:18 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6JjI4K026922 for ietf-openproxy-bks; Thu, 6 Nov 2003 11:45:18 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6JjHkT026917 for ; Thu, 6 Nov 2003 11:45:17 -0800 (PST) (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 hA6JjIGh015809 for ; Thu, 6 Nov 2003 12:45:18 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hA6JjIiO015808; Thu, 6 Nov 2003 12:45:18 -0700 (MST) (envelope-from rousskov) Date: Thu, 6 Nov 2003 12:45:18 -0700 (MST) From: Alex Rousskov To: OPES WG Subject: Communication draft issues for f2f discussion 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: Hi, I have already sent comments on the latest Communications draft (Subject: Re: WG Last Call: draft-ietf-opes-end-comm-05). The ones marked with "S" could be worth discussing at the meeting. Here is a high-level summary: 1. At what requirement level should OPES System be traced? 2. At what requirement level should OPES processor be traced? 3. Should the draft have requirements for other specifications? For example, "application binding specs MUST document X and Y". 4. Polish/discuss Trace and Tracing definitions. 5. Do we trace the order of service invocations or service completions or something else? See S6 and related discussion/items. 6. [S19: Does bypass semantics mean "give OPES version if non-OPES is not available" or "give an error if non-OPES is not available"? This is very important to document clearly because it affects bypass design/rules a lot.] 7. [S25: What can be bypassed? What does it mean to bypass X?] Things to consider are "*" URIs and bypassing OPES processors down the stream. Can processors be bypassed at all? 8. Do we allow trace manipulations (see S31)? 9. Should we use a single HTTP header for all trace entries to preserve order? If yes, how to distinguish one OPES system entries from another? This issue affects Tracing examples and may affect some draft requirements as well. Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Thu Nov 6 16:01:45 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00813 for ; Thu, 6 Nov 2003 16:01:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHrGO-0000Td-00 for opes-archive@ietf.org; Thu, 06 Nov 2003 16:01:56 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AHrGN-0000TZ-00 for opes-archive@ietf.org; Thu, 06 Nov 2003 16:01:55 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6Kn5kT029395 for ; Thu, 6 Nov 2003 12:49:05 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6Kn5XN029394 for ietf-openproxy-bks; Thu, 6 Nov 2003 12:49:05 -0800 (PST) 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.10/8.12.8) with ESMTP id hA6Kn2kT029384 for ; Thu, 6 Nov 2003 12:49:03 -0800 (PST) (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 hA6Kn4Gh017387 for ; Thu, 6 Nov 2003 13:49:04 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hA6Kn4Fo017386; Thu, 6 Nov 2003 13:49:04 -0700 (MST) (envelope-from rousskov) Date: Thu, 6 Nov 2003 13:49:04 -0700 (MST) From: Alex Rousskov To: OPES WG Subject: P issues for f2f discussion 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: Hi, Here are some big P-issues that may be worth discussing at the upcoming F2F meeting. 1. What information does the interpreter has access to? Complete messages? Just meta-information? Anything that is small? Do we define that, does the module author, or does the ruleset writer? 2a. Should this WG work on defining interface(s) between P interpreters and module suppliers? 2b. Should this WG work on defining interface(s) between P interpreters and callout services? 3. Is single-assignment worth keeping if we agree that P deals only with small objects that are cheap to copy? 4. Should more support for writing modules natively in P be added? How much more support is needed? 5. Should this WG document HTTP module for P? As a part of HTTP Adaptation draft or a separate document references from the adaptation draft? 6. If service invocation is just a module method call, how do services return results? Should OCP core document ways to return P-result via the OCP-result structure? See also 2b. Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Thu Nov 6 20:49: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 UAA12243 for ; Thu, 6 Nov 2003 20:49:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHvkm-0004Ql-00 for opes-archive@ietf.org; Thu, 06 Nov 2003 20:49:36 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AHvkl-0004Qi-00 for opes-archive@ietf.org; Thu, 06 Nov 2003 20:49:36 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA71aakT039073 for ; Thu, 6 Nov 2003 17:36:36 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA71aZY3039072 for ietf-openproxy-bks; Thu, 6 Nov 2003 17:36:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA71aYkT039063 for ; Thu, 6 Nov 2003 17:36:35 -0800 (PST) (envelope-from markus@mhof.com) Received: from mhof.com (unknown[135.104.20.67]) by comcast.net (rwcrmhc11) with ESMTP id <2003110701363101300oft0le> (Authid: mhofmann); Fri, 7 Nov 2003 01:36:32 +0000 Message-ID: <3FAAF71F.2020107@mhof.com> Date: Thu, 06 Nov 2003 20:36:31 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031105 Thunderbird/0.4a X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Updated OPES agenda 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, slightly updated agenda for our OPES meeting below. -Markus ----------------------------------------------------- Open Pluggable Edge Services WG (opes) ====================================== Tuesday, November 11, 1700-1800 CHAIR(S): Marshall Rose Markus Hofmann AGENDA: - Introduction, minutes taker, blue sheets - Agenda bashing - Status of WG documents - draft-ietf-opes-architecture-04 - draft-ietf-opes-protocol-reqs-03 - draft-ietf-opes-scenarios-01 - draft-ietf-opes-authorization-02 - draft-ietf-opes-threats-02 - Discussion on open issues with WG documents - draft-ietf-opes-iab-03 - draft-ietf-opes-end-comm-05 - draft-ietf-opes-ocp-core-02 - draft-ietf-opes-http-01 - draft-ietf-opes-rules-p-02 - OPES WG future - Solicitation for additional OPES work items - Re-charter or conclude? From owner-ietf-openproxy@mail.imc.org Thu Nov 6 20:49:32 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12259 for ; Thu, 6 Nov 2003 20:49:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHvks-0004Qs-00 for opes-archive@ietf.org; Thu, 06 Nov 2003 20:49:42 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AHvkr-0004Qp-00 for opes-archive@ietf.org; Thu, 06 Nov 2003 20:49:41 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA71aNkT039059 for ; Thu, 6 Nov 2003 17:36:23 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA71aNbS039058 for ietf-openproxy-bks; Thu, 6 Nov 2003 17:36:23 -0800 (PST) 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.10/8.12.8) with ESMTP id hA71aMkT039053 for ; Thu, 6 Nov 2003 17:36:22 -0800 (PST) (envelope-from markus@mhof.com) Received: from mhof.com (unknown[135.104.20.67]) by comcast.net (rwcrmhc13) with ESMTP id <2003110701361901500bdm9se> (Authid: mhofmann); Fri, 7 Nov 2003 01:36:19 +0000 Message-ID: <3FAAF713.9070507@mhof.com> Date: Thu, 06 Nov 2003 20:36:19 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031105 Thunderbird/0.4a X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: OPES WG Future 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, with all documents getting close to a stable version, it's time to think about our last charter item, namely "Consider additional OPES work such as extension to traffic beyond HTTP and RTSP and present new charter to IESG, or conclude working group." Thoughts? Suggestions? Comments? Please post to the mailing list. -Markus From owner-ietf-openproxy@mail.imc.org Fri Nov 7 08:09:44 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13483 for ; Fri, 7 Nov 2003 08:09:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI6N7-0004p5-00 for opes-archive@ietf.org; Fri, 07 Nov 2003 08:09:53 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AI6N6-0004p2-00 for opes-archive@ietf.org; Fri, 07 Nov 2003 08:09:53 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7D0dkT031987 for ; Fri, 7 Nov 2003 05:00:39 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA7D0daF031986 for ietf-openproxy-bks; Fri, 7 Nov 2003 05:00:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from atlrel6.hp.com (atlrel6.hp.com [156.153.255.205]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7D0ckT031981 for ; Fri, 7 Nov 2003 05:00:38 -0800 (PST) (envelope-from geetham@india.hp.com) Received: from observer.india.hp.com (observer.india.hp.com [15.76.122.45]) by atlrel6.hp.com (Postfix) with ESMTP id A384F1C01E3C; Fri, 7 Nov 2003 08:00:36 -0500 (EST) Received: from india.hp.com (ob9786.india.hp.com [15.76.97.86]) by observer.india.hp.com with ESMTP (8.9.3 (PHNE_28760)/8.8.6 SMKit7.02) id SAA19740; Fri, 7 Nov 2003 18:41:51 +0530 (IST) Message-ID: <3FAB9772.A304A28@india.hp.com> Date: Fri, 07 Nov 2003 18:30:34 +0530 From: Geetha Manjunath Organization: Hewlett Packard ISO X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Markus Hofmann Cc: OPES Group Subject: Re: OPES WG Future References: <3FAAF713.9070507@mhof.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi Markus, I feel there is quite some work that still needs to be done in the OPES area regarding the specification of rules for filtering.. Using a language like 'P' (or something similar) to control activities at the OPES can throw up several interesting opportunities... * The P language (interpreted) would help one to define the dynamic behaviour of an OPES processor. * The above control to change the behaviour can be left to the administrator to support QOS needs. However, interesting possibilities and challenges will open up if we let 'others' define the behaviour. * For example, if a user is able to define his/her own 'P' program (ruleset) and send a link to that as a part of the request itself, the request/response would get modified somewhere along the path whereever that service is available! That is a good thing for the user! Ofcourse, the fallback action on failure to do so would also be provided by the user. * Similarly, the content provider could define a P program and send it across as one of the response headers (in HTTP for eg). Now, depending upon the local characteristics of the network, a specific adaptor would be invoked. This adaptor can be provided by the content provider himself. [ I understand that IRML supports specification of rules by client and content provider but there is no standard way of communicating the same to an OPES processor...] Now , this may inturn throw up standardization needs for the following: * how does one specify/name an OPES service ? * discover an OPES service, * authorization and authentication of the person to deploy a P program on an OPES processor * some work in sand boxing capability to P language itself * Definition of protocol specific interfaces available from P * Specifying mandatory protocols that need to be supported by an OPES * Way of negotiating on where a specific filter is best executed and so on. * If we allow the user-specified modifications (or end point requested adaptation) to look at lower layers (IP and below), it throws up another possibility of end nodes defining the protocol to some extent... * One can think of OPES processors that are able to uniformly understand one standard language to be able to dynamically change their behaviour. * Are we going along the lines of standardization required for 'active networks' - AFAIK there is no such standard as of now .. I guess we could use some existing protocols for some of the above needs or modify some existing ones - but it definitely needs some serious exploration/consensus as per my understanding...Is it worth putting these under the purview of OPES? Comments? Inputs? regards Geetha Markus Hofmann wrote: > > Folks, > > with all documents getting close to a stable version, it's time to > think about our last charter item, namely > > "Consider additional OPES work such as extension to traffic beyond > HTTP and RTSP and present new charter to IESG, or conclude working > group." > > Thoughts? Suggestions? Comments? Please post to the mailing list. > > -Markus From owner-ietf-openproxy@mail.imc.org Fri Nov 7 11:12:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20501 for ; Fri, 7 Nov 2003 11:12:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI9EP-0006xM-00 for opes-archive@ietf.org; Fri, 07 Nov 2003 11:13:05 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AI9EO-0006xI-00 for opes-archive@ietf.org; Fri, 07 Nov 2003 11:13:04 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7G12kT041328 for ; Fri, 7 Nov 2003 08:01:02 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA7G1261041327 for ietf-openproxy-bks; Fri, 7 Nov 2003 08:01:02 -0800 (PST) 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.10/8.12.8) with ESMTP id hA7G11kT041321 for ; Fri, 7 Nov 2003 08:01:01 -0800 (PST) (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 hA7G12Gh043931; Fri, 7 Nov 2003 09:01:02 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hA7G12jx043930; Fri, 7 Nov 2003 09:01:02 -0700 (MST) (envelope-from rousskov) Date: Fri, 7 Nov 2003 09:01:01 -0700 (MST) From: Alex Rousskov To: OPES Group Subject: Re: OPES WG Future In-Reply-To: <3FAAF713.9070507@mhof.com> Message-ID: References: <3FAAF713.9070507@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, 6 Nov 2003, Markus Hofmann wrote: > "Consider additional OPES work such as extension to traffic > beyond HTTP and RTSP and present new charter to IESG, or conclude > working group." > > Thoughts? Suggestions? Comments? Please post to the mailing list. I would like to see OPES WG finishing the work that it started. IMO, the current charter was written to cover the next, but not the last phase in OPES existence. There is still a lot of OPES work to be done, and I believe we are on the right track. Frankly, I do not see any good reasons to conclude now. Moreover, concluding now will most likely mean death to the protocol, tracing, and language work we have already done, at least as far as IETF is concerned. Such forceful death would be unacceptable to me, given the effort and already achieved results. A good time to kill OPES has passed. I wish the group had more active participants. However, (a) the number of active participants is not as relevant as the results we are able to produce (so we should concentrate on evaluating results rather than mailing list volume) and (b) I expect noticeable increase in OPES interest once we start marketing our results (and now we actually have something to show people). I will send specific work item suggestions in a separate e-mail. Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Fri Nov 7 12:28:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25648 for ; Fri, 7 Nov 2003 12:28:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIAP6-00003k-00 for opes-archive@ietf.org; Fri, 07 Nov 2003 12:28:12 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AIAP6-00003f-00 for opes-archive@ietf.org; Fri, 07 Nov 2003 12:28:12 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7HF6kT044440 for ; Fri, 7 Nov 2003 09:15:06 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA7HF69n044439 for ietf-openproxy-bks; Fri, 7 Nov 2003 09:15:06 -0800 (PST) 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.10/8.12.8) with ESMTP id hA7HF5kT044432 for ; Fri, 7 Nov 2003 09:15:05 -0800 (PST) (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 hA7HF6Gh045495; Fri, 7 Nov 2003 10:15:06 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hA7HF6lp045494; Fri, 7 Nov 2003 10:15:06 -0700 (MST) (envelope-from rousskov) Date: Fri, 7 Nov 2003 10:15:06 -0700 (MST) From: Alex Rousskov To: OPES Group Subject: Re: OPES WG Future In-Reply-To: <3FAAF713.9070507@mhof.com> Message-ID: References: <3FAAF713.9070507@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: Hi, In short, I suggest to work on the following new items: - "OCP Security" specification - "SMTP Adaptation with OPES" specification - "IMAP Adaptation with OPES" investigation - RT*P Adaptation investigation - P modules and interfaces The above assumes that we can finish IAB, OCP Core, HTTP Adaptations, P, and Communication drafts before rechartering. If not, the remaining work needs to be included in the new charter. Below are some details about each proposed work item. Except for the P-related items, I tried to word the items for easy inclusion in the revised WG charter: OCP Security specification -------------------------- Define encryption and authentication mechanism for OCP. The resulting specification will be a compliant OCP Core extension. The specification should reuse existing security mechanisms developed within IETF. The specification must be application agnostic and should make it possible for application-specific details to be communicated via application-specific extensions if needed. SMTP Adaptation with OPES specification --------------------------------------- OPES WG defined HTTP adaptation mechanisms in "HTTP adaptation with OPES" specification. SMTP adaptations are arguably as widespread as HTTP adaptations (especially on the client-side edge), but the area is not mature and allows for standardization to enforce OPES principles. The SMTP Adaptation specification must provide SMTP-specific bindings for OCP Core and Communications protocols and may provide SMTP-specific modules for P language. The protocol work on SMTP adaptation may require OCP Core and Communication protocol revisions. The working group will coordinate its efforts with the LEMONADE working group as necessary. It is expected that OPES deliveries can be used to assist with LEMONADE stated goal of ensuring interoperability among e-mail enhancing services, existing e-mail protocols, and new and traditional e-mail users. IMAP Adaptation with OPES investigation --------------------------------------- The working group will investigate interest within the email/IMAP communities to support IMAP adaptation using OPES framework. Provided sufficient interest, the working group will add "IMAP Adaptation with OPES" specification to its work items. The protocol work on IMAP adaptations may require OCP Core and Communication protocol revisions. RT*P Adaptation investigation ----------------------------- Streaming media continues to gain popularity and IETF is making progress with RT*P specifications. Traditional protocols such as e-mail IMAP are being extended to support streaming media. OCP Core and OPES Communication protocols have been designed to be application-agnostic. HTTP and SMTP Adaptation specifications illustrate that application-specific bindings can be built on top of those core protocols. The possibility of providing good adaptation support for streaming protocols is desirable but not certain. The working group will investigate interest within the streaming media communities to support streaming adaptation using OPES framework. Provided sufficient interest, the working group will add "RT*P Adaptation with OPES" and/or similar specifications to its work items. The protocol work on streaming adaptations may require OCP Core and Communication protocol revisions. P modules and interfaces ------------------------- IMO, this work item requires further discussion more than any other item on my list. Geetha Manjunath has already posted some relevant ideas, but we need more input. We have to make three big decisions: - P does not have application-specific modules or capabilities. Do we want to define them? - P does not document the interface between P interpreter (compiler, whatever) and P modules. This assumes that callout service interface is identical to the module interface. - Should we add more P features to make it possible to write meaningful modules in P? What are the missing features here? Should we make these decisions now? Or should we add "make these decisions" our charter work items? Since several adaptable protocol deal with MIME entities (HTTP, SMTP, IMAP) it is possible that we would need some kind of "MIME Entity Adaptation with OPES" specification to factor out things common to all MIME-related protocols. We may want to reflect this possibility in the charter. I did not list "IM Adaptations" investigation in the above. Does anybody think we should engage instant messaging community and see if there is any interest there? I suggest that deadlines are discussed after the work items are agreed on. Please object/add/comment. Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Fri Nov 7 13:05: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 NAA27104 for ; Fri, 7 Nov 2003 13:05:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIAzO-0000Zv-00 for opes-archive@ietf.org; Fri, 07 Nov 2003 13:05:42 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AIAzM-0000Zr-00 for opes-archive@ietf.org; Fri, 07 Nov 2003 13:05:40 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7Ht9kT046686 for ; Fri, 7 Nov 2003 09:55:09 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA7Ht9rw046685 for ietf-openproxy-bks; Fri, 7 Nov 2003 09:55:09 -0800 (PST) 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.10/8.12.8) with ESMTP id hA7Ht7kT046678 for ; Fri, 7 Nov 2003 09:55:07 -0800 (PST) (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 hA7Ht9Gh046377; Fri, 7 Nov 2003 10:55:09 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hA7Ht9n0046376; Fri, 7 Nov 2003 10:55:09 -0700 (MST) (envelope-from rousskov) Date: Fri, 7 Nov 2003 10:55:09 -0700 (MST) From: Alex Rousskov To: OPES Group Subject: P future in OPES WG Future In-Reply-To: <3FAB9772.A304A28@india.hp.com> Message-ID: References: <3FAAF713.9070507@mhof.com> <3FAB9772.A304A28@india.hp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 7 Nov 2003, Geetha Manjunath wrote: > Using a language like 'P' (or something similar) to control > activities at the OPES can throw up several interesting > opportunities... > * The P language (interpreted) would help one to define the dynamic > behaviour of an OPES processor. > * The above control to change the behaviour can be left to the > administrator to support QOS needs. However, interesting > possibilities and challenges will open up if we let 'others' define > the behaviour. > * For example, if a user is able to define his/her own 'P' program > (ruleset) and send a link to that as a part of the request itself, > the request/response would get modified somewhere along the path > whereever that service is available! That is a good thing for the > user! Ofcourse, the fallback action on failure to do so would also > be provided by the user. > * Similarly, the content provider could define a P program and send > it across as one of the response headers (in HTTP for eg). Now, > depending upon the local characteristics of the network, a specific > adaptor would be invoked. This adaptor can be provided by the > content provider himself. [ I understand that IRML supports > specification of rules by client and content provider but there is > no standard way of communicating the same to an OPES processor...] There are two distinct (IMO) things that you are mixing above. First, is the rule authorship. I agree that there are 2.5 possible authors here: data provider, data consumer, and intermediary administrator acting on behalf of provider or consumer. All these authors are in scope and must be supported by OPES. All other authors are out of scope (but may still be supported as a side effect, of course). We indeed have not documented authorization aspects related to ruleset authorship versus content ownership versus hop ownership versus service ownership. I suspect there are existing solutions here such as IETF Policy Framework mentioned in our current charter. The second thing you mention is message-embedded rulesets. This is the "Active Networks" territory and we are going to alienate at least half of IETF folks if we are not extra careful. Combining Active Networks with OPES Adaptations in one context is likely to cause an explosion of emotions within IAB and IESG. However, I do not think that any direction should be banned for that reason alone. Can you provide a couple of specific use cases that we could address with message-embedded rulesets? Is there a real need? If we have specific use cases in mind, we may be able to achieve what you want without disturbing the Active Adaptation daemons. Note that one of the P goal was to allow for embedded rulesets. Now it is time to ask the question whether that feature is needed and, if yes, how we can address those needs. > Now , this may inturn throw up standardization needs for the following: > * how does one specify/name an OPES service? We tackled that when doing OPES Communication draft. OPES service can be identified by one or more URIs. If we can agree on the URI-based identification, the rest is probably out of P scope. > * discover an OPES service, This should be out of WG scope for the next round, IMO. > * authorization and authentication of the person to deploy a P > program on an OPES processor The core of this problem (adaptation authorization and authentication) is out of P scope, but, ideally, the WG should address this problem. It is in our charter, but there are no specific deliveries. > * some work in sand boxing capability to P language itself Yes. And this is unrelated to embedded rulesets and other items above. > * Definition of protocol specific interfaces available from P Yes, we need to define HTTP and possibly other modules. I have included that on my suggested items list as well. > * Specifying mandatory protocols that need to be supported by an > OPES I do not think any application protocol support can be mandatory. We cannot require OPES to support HTTP or SMTP, for example. Or did you mean something else? > * Way of negotiating on where a specific filter is best executed Sounds like a sub-problem to service identification above and, hence, an external to P issue? > * If we allow the user-specified modifications (or end point requested > adaptation) to look at lower layers (IP and below), it throws up another > possibility of end nodes defining the protocol to some extent... I see no good reason to limit P or OPES adaptations to any specific layer on a protocol level. The only question is whether this WG should, for example, define an IP adaptation module/specification? I doubt because we do not have the expertise and are in the wrong IETF area (but others can do that). However, we can define a P module that provides (read-only) IP-level information, for example. We would need good use cases to justify such development, I guess. > I guess we could use some existing protocols for some of the above > needs or modify some existing ones - but it definitely needs some > serious exploration/consensus as per my understanding...Is it worth > putting these under the purview of OPES? IMO, some of the things you mentioned are in OPES scope, and some others can be in scope if you manage to convince the group and IESG with good rationale/examples. Please see detailed comments above. Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Sat Nov 8 12:18:34 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21191 for ; Sat, 8 Nov 2003 12:18:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIWjU-0001or-00 for opes-archive@ietf.org; Sat, 08 Nov 2003 12:18:44 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AIWjT-0001on-00 for opes-archive@ietf.org; Sat, 08 Nov 2003 12:18:43 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA8H7GkT091868 for ; Sat, 8 Nov 2003 09:07:16 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA8H7Gn3091867 for ietf-openproxy-bks; Sat, 8 Nov 2003 09:07:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail2.webwasher.com (host2.webwasher.com [217.146.159.49]) by above.proper.com (8.12.10/8.12.8) with SMTP id hA8H7DkT091861 for ; Sat, 8 Nov 2003 09:07:14 -0800 (PST) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id A92YCJFJ outgoing id NS6I2CPC; 08 Nov 2003 20:14:27 +0100 Received: from jadzia ([10.2.0.81]) by mail.WEBWASHER.COM with Microsoft SMTPSVC(5.0.2195.6713); Sat, 8 Nov 2003 18:06:58 +0100 Message-ID: <001401c3a61a$b03f8820$9d2aeed9@jadzia> From: "Martin Stecher" To: "OPES Group" References: <3FAAF713.9070507@mhof.com> Subject: Re: OPES WG Future Date: Sat, 8 Nov 2003 18:06:44 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C3A623.11714D10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 08 Nov 2003 17:06:59.0052 (UTC) FILETIME=[B874AAC0:01C3A61A] Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C3A623.11714D10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable OPES WG FutureHi, we should not conclude but recharter. OCP core is a good concept and working well for the HTTP adaptation. We will need some more time and work to polish this protocol when real = products will have collected their experience with OCP. It will most likely show that it is faster than ICAP/1.0 in many = deployments and therefore already a valid successor. But it can do much more which we did not yet exploit, for example, - adaptation of other protocols - agent authentication - transport level security Especially I think that we should do the SMTP adaptation. Today Email filtering is done by building a chain of MTAs which is a = more serious problem as with HTTP because every agent take over = responsibility for a message it received - it must not loose it, even if = it crashes. A callout protocol designed for SMTP would make filtering much easier, = filtering services can concentrate on pure filtering and leave the SMTP = routing stuff for other specialized programs. Regards Martin Folks,=20 with all documents getting close to a stable version, it's time to=20 think about our last charter item, namely=20 "Consider additional OPES work such as extension to traffic beyond=20 HTTP and RTSP and present new charter to IESG, or conclude working = group."=20 Thoughts? Suggestions? Comments? Please post to the mailing list.=20 -Markus=20 ------=_NextPart_000_0011_01C3A623.11714D10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable OPES WG Future
Hi,

we=20 should not conclude but recharter.

OCP core is a good concept and = working=20 well for the HTTP adaptation.
We will need some more time and work to = polish=20 this protocol when real products will have collected their experience = with=20 OCP.

It will most likely show that it is faster than ICAP/1.0 in = many=20 deployments and therefore already a valid successor.

But it can = do much=20 more which we did not yet exploit, for example,
  - adaptation = of other=20 protocols
  - agent authentication
  - transport level=20 security

Especially I think that we should do the SMTP=20 adaptation.
Today Email=20 filtering is done by building a chain of MTAs which is a more serious = problem as=20 with HTTP because every agent take over responsibility for a message it = received=20 - it must not loose it, even if it crashes.
A callout=20 protocol designed for SMTP would make filtering much easier, filtering = services=20 can concentrate on pure filtering and leave the SMTP routing stuff for = other=20 specialized = programs.


Regards
Martin
 


Folks,

with all documents getting close to a stable = version, it's=20 time to
think about our last charter item,=20 namely

   "Consider additional OPES work such as = extension=20 to traffic beyond
    HTTP = and RTSP and=20 present new charter to IESG, or conclude working
    group."

Thoughts? Suggestions? Comments? Please post to the = mailing=20 list.

-Markus

 

------=_NextPart_000_0011_01C3A623.11714D10-- From owner-ietf-openproxy@mail.imc.org Sat Nov 8 12:21: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 MAA21264 for ; Sat, 8 Nov 2003 12:21:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIWm6-0001qL-00 for opes-archive@ietf.org; Sat, 08 Nov 2003 12:21:26 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AIWm6-0001qI-00 for opes-archive@ietf.org; Sat, 08 Nov 2003 12:21:26 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA8HA0kT091937 for ; Sat, 8 Nov 2003 09:10:00 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA8HA0oP091936 for ietf-openproxy-bks; Sat, 8 Nov 2003 09:10:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from montage.altserver.com (montage.altserver.com [63.247.74.122]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA8H9xkT091927 for ; Sat, 8 Nov 2003 09:10:00 -0800 (PST) (envelope-from info@utel.net) Received: from f01m-26-206.d0.club-internet.fr ([212.195.225.206] helo=jfc2.utel.net) by montage.altserver.com with esmtp (Exim 4.24) id 1AIWb1-0005Z3-Fy for ietf-openproxy@imc.org; Sat, 08 Nov 2003 09:09:59 -0800 Message-Id: <6.0.0.22.2.20031108175724.0433fdc0@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Sat, 08 Nov 2003 18:17:28 +0100 To: OPES Group From: jfcm Subject: Re: OPES WG Future In-Reply-To: References: <3FAAF713.9070507@mhof.com> Mime-Version: 1.0 Content-Type: text/plain; x-avg-checked=avg-ok-64412B1C; charset=us-ascii; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 17:01 07/11/03, Alex Rousskov wrote: >Moreover, concluding now will most likely mean death to the protocol, >tracing, and language work we have already done, at least as far as >IETF is concerned. Such forceful death would be unacceptable to me, >given the effort and already achieved results. A good time to kill >OPES has passed. > >I wish the group had more active participants. However, (a) the number >of active participants is not as relevant as the results we are able >to produce (so we should concentrate on evaluating results rather than >mailing list volume) and (b) I expect noticeable increase in OPES >interest once we start marketing our results (and now we actually have >something to show people). I could not dedicate time to the OPES efort enought nor to come with example enough lately because of hard time to fight for other concepts and financiing needs. My be this will have a break and sometimes a financing. So, I start seeing all this work as a "user" of it. My first suggestion would be a summary. A book on OPES. Not only to specify it, but to explain it. This would may be increase the number of interested people and inputs. It might also help to put everything in perspective in a real environment. For example I am extremely interested in OPES and SMTP as I advance on the definition and operational demands for "weemail" (yet only in French at http://weemail.org). The idea is to use SMTP only to carry message pointers and open header information. Mails stay at the author mail server and is read on an as requested basis. Great for speed and bandwidth. Any messaging service can be used to carry that "weeheader" (SMS, telephone, fax, written mail, radio, Teletex, etc...). This approach looks like simplifing spamming; but puts it very unatease as the message must be retrieved at a stable disclosed URL and additionnal information in the header make it very easy to put spam at such a low reading priority that it will not hurt. In this architecture weemail policing would be brillantly supported by OPES (if I have authorithy I could use OPES to kill access to spam from all my domain people, in dynamilcally adding a filtering rule: every weemail or retreiving request at a given URL would be killed or reported as spam) This is my ONES issue again. The future of the network is necessarily ONES (look at VISA which nearly went broke last week because as a ONES VISA froze 15 years ago and has not conceptually built on its ONES to the users architecture. Until IETF and IAB start modelzing a little bit the real network or the NGN takes over, OPES are the next thing to ONES we may have. Freezing OPES now would be a mistake. Thak you Alex for all the work achieved. But I do think again that a book explaining it would help every one. Starting with you? jfc From owner-ietf-openproxy@mail.imc.org Mon Nov 10 08:00: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 IAA18273 for ; Mon, 10 Nov 2003 08:00:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJBfK-0004C2-00 for opes-archive@ietf.org; Mon, 10 Nov 2003 08:01:10 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AJBfK-0004By-00 for opes-archive@ietf.org; Mon, 10 Nov 2003 08:01:10 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAACjIkT070890 for ; Mon, 10 Nov 2003 04:45:18 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAACjIQC070889 for ietf-openproxy-bks; Mon, 10 Nov 2003 04:45:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAACjHkT070884 for ; Mon, 10 Nov 2003 04:45:17 -0800 (PST) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAACj5417086; Mon, 10 Nov 2003 07:45:05 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Nov 2003 07:45:05 -0500 Message-ID: <87609AFB433BD5118D5E0002A52CD7540788841D@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Alex Rousskov , OPES Group Subject: feed back WG Last Call: draft-ietf-opes-end-comm-05: Definition o f a trace Date: Mon, 10 Nov 2003 07:45:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A788.76697C22" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3A788.76697C22 Content-Type: text/plain Alex, Thanks for the feedback. Can you please state your own definition of an OPES trace so we can close this subject once and for all. > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Monday, November 03, 2003 6:53 PM > To: OPES Group > Subject: Re: WG Last Call: draft-ietf-opes-end-comm-05 SNIP ------_=_NextPart_001_01C3A788.76697C22 Content-Type: text/html Content-Transfer-Encoding: quoted-printable feed back WG Last Call: draft-ietf-opes-end-comm-05: Definition = of a trace

Alex,
Thanks for the feedback.

Can you please state your own definition of an OPES = trace so we can close this subject once and for all.



> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Monday, November 03, 2003 6:53 PM
> To: OPES Group
> Subject: Re: WG Last Call: = draft-ietf-opes-end-comm-05


SNIP

------_=_NextPart_001_01C3A788.76697C22-- From owner-ietf-openproxy@mail.imc.org Mon Nov 10 13:57:38 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05686 for ; Mon, 10 Nov 2003 13:57:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJHET-0002J2-00 for opes-archive@ietf.org; Mon, 10 Nov 2003 13:57:49 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AJHES-0002Iz-00 for opes-archive@ietf.org; Mon, 10 Nov 2003 13:57:48 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAIgFkT087026 for ; Mon, 10 Nov 2003 10:42:15 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAAIgFmT087025 for ietf-openproxy-bks; Mon, 10 Nov 2003 10:42:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAIgEkT087019 for ; Mon, 10 Nov 2003 10:42:14 -0800 (PST) (envelope-from apache@asgard.ietf.org) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1AJGek-0007xa-5V; Mon, 10 Nov 2003 13:20:54 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , Subject: Document Action: 'OPES Use Cases and Deployment Scenarios' to Informational RFC Message-Id: Date: Mon, 10 Nov 2003 13:20:54 -0500 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The IESG has approved following document: - 'OPES Use Cases and Deployment Scenarios ' as an Informational RFC This document is the product of the Open Pluggable Edge Services Working Group. The IESG contact persons are Ned Freed and Ted Hardie. From owner-ietf-openproxy@mail.imc.org Mon Nov 10 15:26:39 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11577 for ; Mon, 10 Nov 2003 15:26:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJIcd-000407-00 for opes-archive@ietf.org; Mon, 10 Nov 2003 15:26:51 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AJIcc-000404-00 for opes-archive@ietf.org; Mon, 10 Nov 2003 15:26:50 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAK9RkT090441 for ; Mon, 10 Nov 2003 12:09:27 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAAK9RZp090440 for ietf-openproxy-bks; Mon, 10 Nov 2003 12:09:27 -0800 (PST) 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.10/8.12.8) with ESMTP id hAAK9PkT090434 for ; Mon, 10 Nov 2003 12:09:25 -0800 (PST) (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 hAAK9QGh055898; Mon, 10 Nov 2003 13:09:26 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hAAK9Q2m055897; Mon, 10 Nov 2003 13:09:26 -0700 (MST) (envelope-from rousskov) Date: Mon, 10 Nov 2003 13:09:26 -0700 (MST) From: Alex Rousskov To: OPES Group Subject: Re: OPES WG Future In-Reply-To: <6.0.0.22.2.20031108175724.0433fdc0@mail.utel.net> Message-ID: References: <3FAAF713.9070507@mhof.com> <6.0.0.22.2.20031108175724.0433fdc0@mail.utel.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, 8 Nov 2003, jfcm wrote: > My first suggestion would be a summary. A book on OPES. Not only to > specify it, but to explain it. This would may be increase the number > of interested people and inputs. It might also help to put > everything in perspective in a real environment. A book on OPES or at least a good chapter in some web architecture book would be great. Personally, I do not have the resources to write or publish one, but would be happy to assist others in doing so. > For example I am extremely interested in OPES and SMTP as I advance > on the definition and operational demands for "weemail" (yet only in > French at http://weemail.org). I am glad to see more use cases for SMTP adaptations. As you may have seen, I suggested adding SMTP as the next adaptation goal for OPES charter. Alex. From owner-ietf-openproxy@mail.imc.org Tue Nov 11 01:19: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 BAA07935 for ; Tue, 11 Nov 2003 01:19:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJRsf-0005qD-00 for opes-archive@ietf.org; Tue, 11 Nov 2003 01:20:01 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AJRse-0005qA-00 for opes-archive@ietf.org; Tue, 11 Nov 2003 01:20:00 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAB67nkT016694 for ; Mon, 10 Nov 2003 22:07:49 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAB67nvC016693 for ietf-openproxy-bks; Mon, 10 Nov 2003 22:07:49 -0800 (PST) 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.10/8.12.8) with ESMTP id hAB67mkT016687 for ; Mon, 10 Nov 2003 22:07:48 -0800 (PST) (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 hAB67pGh070482; Mon, 10 Nov 2003 23:07:51 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hAB67pVT070481; Mon, 10 Nov 2003 23:07:51 -0700 (MST) (envelope-from rousskov) Date: Mon, 10 Nov 2003 23:07:51 -0700 (MST) From: Alex Rousskov To: OPES Group Subject: Re: feed back WG Last Call: draft-ietf-opes-end-comm-05: Definition o f a trace In-Reply-To: <87609AFB433BD5118D5E0002A52CD7540788841D@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD7540788841D@zcard0k6.ca.nortel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 10 Nov 2003, Abbie Barbir wrote: > Can you please state your own definition of an OPES trace I am still happy with the wording I proposed in May. Here is a slightly polished version: OPES trace: application message information about OPES entities that adapted the message OPES tracing: the process of creating, manipulating, or interpreting an OPES trace Note that the above trace definition assumes in-band tracing. This dependency can be removed if desired. The definitions would be accompanied by rules (e.g., "application bindings MUST define trace format" or "OPES entities MAY perform tracing on behalf of other entities"). I believe you did have definitions similar to the above in a few revisions of the draft. The current definitions in the draft are: > In an OPES System tracing is defined as the inclusion of necessary > information within a message in an OPES Flow that identify the > collection of transformations or adaptations that have been > performed on it before its delivery to an end point (for example, > the data consumer application). > An OPES trace represents a snap shot of the tracing information > that have been added to a given application message. > A trace represents the collections of transformations on an > application message in the order that were performed. HTH, Alex. From owner-ietf-openproxy@mail.imc.org Tue Nov 11 04:14:47 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24877 for ; Tue, 11 Nov 2003 04:14:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJUbv-00006y-00 for opes-archive@ietf.org; Tue, 11 Nov 2003 04:14:55 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AJUbv-00006v-00 for opes-archive@ietf.org; Tue, 11 Nov 2003 04:14:55 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAB8qOkT074830 for ; Tue, 11 Nov 2003 00:52:24 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAB8qOsC074829 for ietf-openproxy-bks; Tue, 11 Nov 2003 00:52:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAB8qNkT074820 for ; Tue, 11 Nov 2003 00:52:24 -0800 (PST) (envelope-from geetham@india.hp.com) Received: from observer.india.hp.com (observer.india.hp.com [15.76.122.45]) by palrel13.hp.com (Postfix) with ESMTP id ECF0E1C010FB; Tue, 11 Nov 2003 00:52:20 -0800 (PST) Received: from india.hp.com (ob9786.india.hp.com [15.76.97.86]) by observer.india.hp.com with ESMTP (8.9.3 (PHNE_28760)/8.8.6 SMKit7.02) id OAA08585; Tue, 11 Nov 2003 14:33:39 +0530 (IST) Message-ID: <3FB0A346.29D1A8F5@india.hp.com> Date: Tue, 11 Nov 2003 14:22:22 +0530 From: Geetha Manjunath Organization: Hewlett Packard ISO X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Alex Rousskov Cc: OPES Group Subject: Re: P future in OPES WG Future References: <3FAAF713.9070507@mhof.com> <3FAB9772.A304A28@india.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hello Alex, Sorry if my earlier (as usual hurried) mail sounded mixed up.. Actually, I was just trying to arrive at the 'undone work' of OPES with the starting point being 'P'. While visualizing the different ways in which 'P' can be best deployed or exploited, I found some gaps that OPES could choose to take up.. I was not necessarily saying that 'P' should address all the issues though.. Please find my specific responses inline.. > There are two distinct (IMO) things that you are mixing above. First, > is the rule authorship. I agree that there are 2.5 possible authors > here: data provider, data consumer, and intermediary administrator > acting on behalf of provider or consumer. All these authors are in > scope and must be supported by OPES. All other authors are out of > scope (but may still be supported as a side effect, of course). GEETHA> While data provider and data consumer are the main authors as you point out, I think the intermediary administrator can play a bigger role than just 'acting on behalf of provider/consumer'. I am actually referring to a case wherein the deployer of the intermediary (/administrator) can also be a service provider - as in the case of wireless access points in public places for connectivity .... The wireless access provider (say in a public place such as airports and shopping malls) can now provide several additional context dependent web services for business and advertising purposes. The rules that this more powerful admin can set could be for client authorization, based on last-leg bandwidth availability, QOS promises among others - all these irrespective of the client and the content provider. > We indeed have not documented authorization aspects related to ruleset > authorship versus content ownership versus hop ownership versus > service ownership. I suspect there are existing solutions here such as > IETF Policy Framework mentioned in our current charter. GEETHA> I need to look into those specifications ... > The second thing you mention is message-embedded rulesets. . Can you provide a > couple of specific use cases that we could address with > message-embedded rulesets? Is there a real need? If we have specific > use cases in mind, we may be able to achieve what you want without > disturbing the Active Adaptation daemons. GEETHA> The specific use case is also in the same scenario as above - the wireless access points. Just as the case of special web services that could be deployed by the access provider, the filtering or adaptation services could also be made available to the user - free of charge or pay per use basis. In case of 'paid filtering services', the client should be given a choice of whether he/she wants the filter to be applied or not. One way of doing this, is through the request itself - what you termed as 'message-embedded rulesets'. Some of the examples filtering services that the client may be willing to pay for could be video transcoding, virus filter and so on... > Note that one of the P goal was to allow for embedded rulesets. Now it > is time to ask the question whether that feature is needed and, if > yes, how we can address those needs. > > > Now , this may inturn throw up standardization needs for the following: > > * how does one specify/name an OPES service? > > We tackled that when doing OPES Communication draft. OPES service can > be identified by one or more URIs. If we can agree on the URI-based > identification, the rest is probably out of P scope. GEETHA> While URI may be a way to refer to a remote callout service and get that executed, I thought it may be required to identify a filter service based on its functionality. This is again in the context of the above scenario wherein a nomadic client moves from one public place to another but wants the virus filter to be referred to with the same name - irrespective of the actual tool used by the deployer to do the filtering. > > * discover an OPES service, > > This should be out of WG scope for the next round, IMO. GEETHA> I think even this can be in the WG scope again in the above context - wherein the discovery is limited to the filters in the local OPES processor /wireless access point. > > > * authorization and authentication of the person to deploy a P > > program on an OPES processor > > The core of this problem (adaptation authorization and authentication) > is out of P scope, but, ideally, the WG should address this problem. > It is in our charter, but there are no specific deliveries. > > > * some work in sand boxing capability to P language itself > > Yes. And this is unrelated to embedded rulesets and other items above. > > > * Definition of protocol specific interfaces available from P > > Yes, we need to define HTTP and possibly other modules. I have > included that on my suggested items list as well. > > > * Specifying mandatory protocols that need to be supported by an > > OPES > > I do not think any application protocol support can be mandatory. We > cannot require OPES to support HTTP or SMTP, for example. Or did you > mean something else? GEETHA> Here, I was basically coming from the angle of - if someone were to write a 'P' program that for example works on HTTP message and were to send it across along with the message, he better be comfortable executing his code on the OPES nodes. I mean - rather than just assuming that the exception handler (try statement) would take care of the default, it would be better to send it to an OPES where he is somewhat assured about the execution of the code without exception. For this reason, we may have to ONE of the following alternatives (IMO): * all OPES processors conforming to version m.n of P must support x,y,z protocol modules * Reference versions of the protocol modules are provided at a location L - and if the OPES processor does not support one, it has to download and execute * Have an 'options handshake' mechanism wherein a P program can query about the modules supported by the next upstream OPES procs and send it over to the one that supports a given protocol.... *??? > > * Way of negotiating on where a specific filter is best executed > > Sounds like a sub-problem to service identification above and, hence, > an external to P issue? > > > * If we allow the user-specified modifications (or end point requested > > adaptation) to look at lower layers (IP and below), it throws up another > > possibility of end nodes defining the protocol to some extent... > > I see no good reason to limit P or OPES adaptations to any specific > layer on a protocol level. The only question is whether this WG > should, for example, define an IP adaptation module/specification? I > doubt because we do not have the expertise and are in the wrong IETF > area (but others can do that). However, we can define a P module that > provides (read-only) IP-level information, for example. We would need > good use cases to justify such development, I guess. GEETHA> Typically, type of wireless network (802.11, BT,..) would be a good input to execute certain filters. Ofcourse, use of client-IP has become failry std i guess... Actually, I suspect this will have heavier implications for multi media protocols though. > > I guess we could use some existing protocols for some of the above > > needs or modify some existing ones - but it definitely needs some > > serious exploration/consensus as per my understanding...Is it worth > > putting these under the purview of OPES? Hope this speaks sense.. regards Geetha From owner-ietf-openproxy@mail.imc.org Tue Nov 11 15:56:37 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21568 for ; Tue, 11 Nov 2003 15:56:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJfZA-0001yr-00 for opes-archive@ietf.org; Tue, 11 Nov 2003 15:56:48 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AJfZ9-0001yn-00 for opes-archive@ietf.org; Tue, 11 Nov 2003 15:56:47 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABKgckT020350 for ; Tue, 11 Nov 2003 12:42:38 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABKgc5M020349 for ietf-openproxy-bks; Tue, 11 Nov 2003 12:42:38 -0800 (PST) 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.10/8.12.8) with ESMTP id hABKgXkT020344 for ; Tue, 11 Nov 2003 12:42:36 -0800 (PST) (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 hABKgXGh092256; Tue, 11 Nov 2003 13:42:33 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hABKgX59092255; Tue, 11 Nov 2003 13:42:33 -0700 (MST) (envelope-from rousskov) Date: Tue, 11 Nov 2003 13:42:33 -0700 (MST) From: Alex Rousskov To: OPES Group Subject: Re: P future in OPES WG Future In-Reply-To: <3FB0A346.29D1A8F5@india.hp.com> Message-ID: References: <3FAAF713.9070507@mhof.com> <3FAB9772.A304A28@india.hp.com> <3FB0A346.29D1A8F5@india.hp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 11 Nov 2003, Geetha Manjunath wrote: > Sorry if my earlier (as usual hurried) mail sounded mixed up.. > Actually, I was just trying to arrive at the 'undone work' of OPES > with the starting point being 'P'. While visualizing the different > ways in which 'P' can be best deployed or exploited, I found some > gaps that OPES could choose to take up.. I was not necessarily > saying that 'P' should address all the issues though.. I see! That clarifies some of the points you made. Thank you. > While data provider and data consumer are the main authors as you > point out, I think the intermediary administrator can play a bigger > role than just 'acting on behalf of provider/consumer'. I am > actually referring to a case wherein the deployer of the > intermediary (/administrator) can also be a service provider - as in > the case of wireless access points in public places for connectivity Within the IETF context, we have to assume that the administrator is acting on behalf of provider/consumer. Please note that this addresses authorization concerns and does not preclude administrator from being a service provider. This is one of those things were we have to be careful to avoid raising red flags for no good reason. As long as all provided services are authorized (one way or another) by one of the ends, we are fine. > .... The wireless access provider (say in a public place such as > airports and shopping malls) can now provide several additional > context dependent web services for business and advertising > purposes. The rules that this more powerful admin can set could be > for client authorization, based on last-leg bandwidth availability, > QOS promises among others - all these irrespective of the client and > the content provider. Within the IETF context, OPES adaptation services would have to be authorized by a client or content provider. Authorization is not OPES adaptation (because it is performed explicitly by the application hop and not implicitly on the traffic in transit). QoS can be borderline. For example, doing traffic shaping can be done without explicit authorization because it does not affect content. However, doing image quality transformation has to be authorized. Note that there could be valid unauthorized adaptations that an OPES system can perform well in real life. We just need to be careful not to use such cases in examples and motivation if we want IETF/IESG approval. In other words, we are developing a peaceful nuclear reactor. As any technology it can be misused to build an atomic bomb and even the definition of "misuse" is unclear. > The specific use case is also in the same scenario as above - the > wireless access points. Just as the case of special web services > that could be deployed by the access provider, the filtering or > adaptation services could also be made available to the user - free > of charge or pay per use basis. In case of 'paid filtering > services', the client should be given a choice of whether he/she > wants the filter to be applied or not. One way of doing this, is > through the request itself - what you termed as 'message-embedded > rulesets'. Some of the examples filtering services that the client > may be willing to pay for could be video transcoding, virus filter > and so on... Hmm... I understand the need for the services you mention but I am not sure I understand how they are related to message-embedded rulesets. If the proxy asks a user what services she wants to enable, that is not an embedded ruleset because the rules will always reside on the proxy (the client will not see/manipulate/embed them other than via user-friendly interfaces). The closest thing I can think of is creating an HTTP cookie with a ruleset so that the proxy does not have to remember client-rules associations. Is that something you are after here? Or are you talking about clients that have pre-built rulesets in their browsers and those rulesets are submitted to proxies by browsers in hope that some proxies would support them? Kind of like "preference" indication: "I would like my GIFs to be black and white, if possible". > While URI may be a way to refer to a remote callout service and get > that executed, I thought it may be required to identify a filter > service based on its functionality. URI is not a URL. URI can be used to identify a group of services, including by-functionality or by-side-effects grouping. There was a short thread about that some time ago. Please see http://www.imc.org/ietf-openproxy/mail-archive/msg02554.html http://www.imc.org/ietf-openproxy/mail-archive/msg02556.html > This is again in the context of the above scenario wherein a nomadic > client moves from one public place to another but wants the virus > filter to be referred to with the same name - irrespective of the > actual tool used by the deployer to do the filtering. Right. URIs should do the trick well, IMO. However, I agree that there may be a place for small message-embedded rulesets that represent client preferences here. Something that requires non-static logic like "if it is before 17:00, please filter porn out". > > > * discover an OPES service, > > > > This should be out of WG scope for the next round, IMO. > > I think even this can be in the WG scope again in the above context > - wherein the discovery is limited to the filters in the local OPES > processor /wireless access point. Agreed. I just would not call it discovery. To me, it sounds a lot more like expressing one's preferences. If we accept this as a work item, we must learn from P3P (http://www.w3.org/P3P/) experience, I guess. Our scope is wider/different, but available mechanisms are probably similar. > > I do not think any application protocol support can be mandatory. > > We cannot require OPES to support HTTP or SMTP, for example. Or > > did you mean something else? > > Here, I was basically coming from the angle of - if someone were to > write a 'P' program that for example works on HTTP message and were > to send it across along with the message, he better be comfortable > executing his code on the OPES nodes. I mean - rather than just > assuming that the exception handler (try statement) would take care > of the default, it would be better to send it to an OPES where he is > somewhat assured about the execution of the code without exception. I do not think it is realistic to support the above given the diversity of intermediaries out there. Also, exception handling is a MUST-level requirement in P so the ruleset author should not worry whether it is supported or not. She does not have to use it either -- if she does not care, the first failure will terminate the P script, which is probably the author-intended/desired behavior in 95% of cases. > For this reason, we may have to ONE of the following alternatives > (IMO): > * all OPES processors conforming to version m.n of P must support > x,y,z protocol modules I cannot find a nonempty subset of protocols that would be acceptable. For example, SMTP servers will not support HTTP and vice versa. If course, if a ruleset is attached to an HTTP message, there are good chances that OPES hops will support HTTP module. > * Reference versions of the protocol modules are provided at a > location L - and if the OPES processor does not support one, it has > to download and execute That should be supported already, kind of. The modules are identified bu URIs which could be URNs (location-independent names) with known repositories of actual module implementations for those hops that miss a module. However, I suspect that most proxies will not download 3rd party modules on the fly -- too risky. This approach may work well in certain walled gardens where the modules are signed or otherwise secured, of course. > * Have an 'options handshake' mechanism wherein a P program can > query about the modules supported by the next upstream OPES procs > and send it over to the one that supports a given protocol.... That would be outside of P scope (P is a language, not a communication protocol so it cannot have negotiations like that). Note that almost identical functionality can be implemented by using P exceptions. Moreover, it is unlikely that a ruleset author would have a choice of several modules doing the same thing; either the needed module is available or not (ignoring module-vendor differences and such). Unless there is more P-feedback, I think we are ready for the next step. I will try to summarize in the next e-mail. Alex. From owner-ietf-openproxy@mail.imc.org Tue Nov 11 15:59: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 PAA21699 for ; Tue, 11 Nov 2003 15:59:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJfbt-00020u-00 for opes-archive@ietf.org; Tue, 11 Nov 2003 15:59:37 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AJfbs-00020r-00 for opes-archive@ietf.org; Tue, 11 Nov 2003 15:59:37 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABKkokT020533 for ; Tue, 11 Nov 2003 12:46:50 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABKkoK7020532 for ietf-openproxy-bks; Tue, 11 Nov 2003 12:46:50 -0800 (PST) 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.10/8.12.8) with ESMTP id hABKknkT020527 for ; Tue, 11 Nov 2003 12:46:49 -0800 (PST) (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 hABKkpGh092375; Tue, 11 Nov 2003 13:46:51 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hABKkpdL092374; Tue, 11 Nov 2003 13:46:51 -0700 (MST) (envelope-from rousskov) Date: Tue, 11 Nov 2003 13:46:51 -0700 (MST) From: Alex Rousskov To: OPES Group Subject: Re: P future in OPES WG Future In-Reply-To: <3FB0A346.29D1A8F5@india.hp.com> Message-ID: References: <3FAAF713.9070507@mhof.com> <3FAB9772.A304A28@india.hp.com> <3FB0A346.29D1A8F5@india.hp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Geetha, IMHO, there is a lot of good stuff in what you are proposing. The next step would be to phrase your favorite items as proposed working group actions and specific deliverables for the new WG charter, I guess. While doing that, please do not count on much legwork support from other working group members. There are probably less than 2.0 person-equivalents available on a daily basis to assist you right now. Thus, be prepared to lead the work (which I think you are) and limit your proposal to the most interesting/essential items that you want to work on. My understanding is that the working group would then review your proposal and try to reach consensus on what to include in the revised charter. Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Wed Nov 12 13:06: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 NAA00393 for ; Wed, 12 Nov 2003 13:06:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJzO3-0003LT-00 for opes-archive@ietf.org; Wed, 12 Nov 2003 13:06:39 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AJzO2-0003LQ-00 for opes-archive@ietf.org; Wed, 12 Nov 2003 13:06:38 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hACHpFkT035876 for ; Wed, 12 Nov 2003 09:51:15 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hACHpF40035875 for ietf-openproxy-bks; Wed, 12 Nov 2003 09:51:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hACHpDkT035870 for ; Wed, 12 Nov 2003 09:51:13 -0800 (PST) (envelope-from markus@mhof.com) X-Sasl-enc: w9Sf4wY2Kd8OBTjHYZsdqQ 1068659329 Received: from mhof.com (unknown [135.104.20.76]) by www.fastmail.fm (Postfix) with ESMTP id EC5883FD5C7 for ; Wed, 12 Nov 2003 12:48:48 -0500 (EST) Message-ID: <3FB27350.1070500@mhof.com> Date: Wed, 12 Nov 2003 12:52:16 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Draft minutes from IETF 58 Content-Type: multipart/mixed; boundary="------------020503070507000309070802" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. --------------020503070507000309070802 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Folks, attached the *draft* minutes from our meeting at IETF 58. Thanks to Eric for taking the minutes, and thanks to Marshall for taking care of the Jabber. In case you've comments, please provide them by Friday, 11/14, 5pm (EDT), so that we can forward the minutes to the IETF in a timely manner. Thanks, Markus --------------020503070507000309070802 Content-Type: text/plain; name="ietf58-opes-minutes.txt" Content-Disposition: inline; filename="ietf58-opes-minutes.txt" Content-Transfer-Encoding: 7bit Open Pluggable Edge Services (OPES) 58th IETF Meeting 11 November 2003 Eric Burger, scribe Jabber log is at ===== Agenda Bashing: Markus Hofmann ===== Document Status - See slides & ID Tracker Goal: finish documents in "ID Exists" status by end of November ===== OPES Treatment of IAB Considerations draft-ietf-opes-iab-03 - Abbie Barbir See slides On Considerations 3.1 & 3.2: chose to make notifications optional; focus on tracing. Clearly, OPES cannot do end-to-end encryption. OPES can do hop-by-hop encryption. Sally Floyd: Likes document; addresses IAB issues Markus: expect WGLC soon after IETF ===== OPES process and end points communications Draft-ietf-opes-end-comm-05 - Abbie Barbir See slides Tracing ------- Open issue: What is OPES Tracing? Current wording has problem with "inclusion". Does that mean that trace can be adapted (pruned, modified, added-to)? Should we allow trace adaptation? Trace information designed for system administrators, not users. Bypass ------ IAB Considerations said to bypass non-OPES content. But, what is OPES content? Solution: punt -- definition of OPES content is outside scope of OPES. Sally Floyd: Comment: IAB document isn't legal language. Try to figure out what the intent is. The IAB document does not mean "user has to have a way to bypass firewalls, boundaries, etc." It is saying, "If a user asks for content from web server, and the content gets mangled by an OPES server, then user needs to be able to figure out what went wrong." MUST/SHOULD/MAY questions: see slides w.r.t. OPES bypass - Sally Floyd: Source of IAB concern about non-OPES is data integrity, e.g., how does one detect malicious transformation of data. ===== OPC: OPES Callout Protocol draft-ietf-opes-ocp-core-03 - Abbie Barbir see slides Should authentication be in the core or binding (HTTP)? Should authentication be in this draft, or a separate draft? Same issues for Encryption. Should we get IETF review before going to WGLC? Marshall: "NO" Application message identifiers are irrelevant for HTTP, but might not be robust enough for SMTP. Should we dump them and figure out the right thing for SMTP later, if there is a later? Markus: Please post comments on AM-ID's to the list! ===== HTTP Adaptation with OPES Draft-ietf-opes-http-01 (from Martin and Alex) presented by Markus See slides Targeting WGLC for end of November Need HTTP expert to review HTTP-specific issues, and in particular on HTTP-specific security considerations Open issues: How to avoid blocking; skip uninteresting request bodies in 'response mode'; and handle HTTP-specific things like 100 Continue and 206 Partial Content? Please check for XXX's in document and send text to mail list! ===== P: Message Processing Language Presented by Markus See slides Open issues: What information is available to interpreter? Complete message? Headers only? Punt? Is doing HTTP module in scope for work group? If so, in what document? Should work group define interfaces between P interpreters and module suppliers or callout services? If so, how do services return results, e.g., from OCP? Ted Hardie: Working group should specify what information is available to the interpreter. Not a value judgement of where, just we should set expectations for community. Ted Hardie: When do we expect the current charter items to be done? Markus: Hopefully December. ===== OPES Future Markus Note: Re-chartering is ONLY for adding new work items, not for staying alive to do work from old charter. Keep new work in OPES framework, not something new. Really need to know who will be committed to working on new work items. PLEASE POST THOUGHTS AND SUGGESTIONS TO MAIL LIST. PLEASE VOLUNTEER TO DO WORK!!! OPES for SMTP and IMAP: does it conflict with lemonade? Eric Burger: Not at all. Definitely fits into OPES, just need to coordinate groups. If you have interest in a topic, want to be an editor or contributor, please post to list. Marshall: Importance of finishing documents -- "credibility is the coin of the realm." --------------020503070507000309070802-- From owner-ietf-openproxy@mail.imc.org Wed Nov 12 21:08:18 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 VAA22512 for ; Wed, 12 Nov 2003 21:08:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK6uJ-0003NN-00 for opes-archive@ietf.org; Wed, 12 Nov 2003 21:08:28 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AK6uJ-0003NJ-00 for opes-archive@ietf.org; Wed, 12 Nov 2003 21:08:27 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAD1pVkT055945 for ; Wed, 12 Nov 2003 17:51:31 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAD1pVDd055944 for ietf-openproxy-bks; Wed, 12 Nov 2003 17:51:31 -0800 (PST) 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.10/8.12.8) with ESMTP id hAD1pUkT055939 for ; Wed, 12 Nov 2003 17:51:30 -0800 (PST) (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 hAD1pWGh061957 for ; Wed, 12 Nov 2003 18:51:32 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hAD1pMiR061955; Wed, 12 Nov 2003 18:51:22 -0700 (MST) (envelope-from rousskov) Date: Wed, 12 Nov 2003 18:51:22 -0700 (MST) From: Alex Rousskov To: OPES WG Subject: Re: Draft minutes from IETF 58 In-Reply-To: <3FB27350.1070500@mhof.com> Message-ID: References: <3FB27350.1070500@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: Thanks for the minutes and Jabber! How many people, approximately, attended the meeting? Also, Jabber log says: - Marshall asks who's an old-timer - Lots of applause all around Was the question about people who were WG participants from early OPES days? What caused the round of applause? Lack of old-timers? Thank you, Alex. On Wed, 12 Nov 2003, Markus Hofmann wrote: > Folks, > > attached the *draft* minutes from our meeting at IETF 58. Thanks to > Eric for taking the minutes, and thanks to Marshall for taking care > of the Jabber. > > In case you've comments, please provide them by Friday, 11/14, 5pm > (EDT), so that we can forward the minutes to the IETF in a timely > manner. > > Thanks, > Markus > > From owner-ietf-openproxy@mail.imc.org Wed Nov 12 22:25: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 WAA24714 for ; Wed, 12 Nov 2003 22:25:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK873-0004Kg-00 for opes-archive@ietf.org; Wed, 12 Nov 2003 22:25:41 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AK872-0004Kd-00 for opes-archive@ietf.org; Wed, 12 Nov 2003 22:25:40 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAD3ApkT059468 for ; Wed, 12 Nov 2003 19:10:51 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAD3Apxo059467 for ietf-openproxy-bks; Wed, 12 Nov 2003 19:10:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAD3AokT059462 for ; Wed, 12 Nov 2003 19:10:50 -0800 (PST) (envelope-from markus@mhof.com) Received: from server2.messagingengine.com (server2.internal [10.202.2.133]) by mail.messagingengine.com (Postfix) with ESMTP id 8A9053FEBAC for ; Wed, 12 Nov 2003 22:10:48 -0500 (EST) Received: by server2.messagingengine.com (Postfix, from userid 99) id D5FEE79414; Wed, 12 Nov 2003 22:10:47 -0500 (EST) Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.2 (F2.71; T1.001; A1.51; B2.12; Q2.03) From: "Markus Hofmann" To: "OPES WG" Date: Wed, 12 Nov 2003 22:10:47 -0500 X-Sasl-Enc: AMWfYZWe+zFySWGTtggUYA 1068693047 Subject: Re: Draft minutes from IETF 58 References: <3FB27350.1070500@mhof.com> In-Reply-To: Message-Id: <20031113031047.D5FEE79414@server2.messagingengine.com> Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Alex, > How many people, approximately, attended the meeting? There were about 20 people in the room. > Also, Jabber log says: > - Marshall asks who's an old-timer > - Lots of applause all around > > Was the question about people who were WG participants from early OPES > days? What caused the round of applause? Lack of old-timers? Marshall asked who participated in the 1st BOF, the 2nd,... the 1st WG meeting, the 2nd... If I recall correctly, the applause was triggered by a statement from Marshall in which he emphasized that the WG made tremendeous progress in being so close to meeting all charter items. -Markus From owner-ietf-openproxy@mail.imc.org Thu Nov 13 00:33:41 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28797 for ; Thu, 13 Nov 2003 00:33:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKA75-0006CS-00 for opes-archive@ietf.org; Thu, 13 Nov 2003 00:33:52 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AKA75-0006CP-00 for opes-archive@ietf.org; Thu, 13 Nov 2003 00:33:51 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAD5FdkT064104 for ; Wed, 12 Nov 2003 21:15:39 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAD5FdwZ064102 for ietf-openproxy-bks; Wed, 12 Nov 2003 21:15:39 -0800 (PST) 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.10/8.12.8) with ESMTP id hAD5FbkT064097 for ; Wed, 12 Nov 2003 21:15:38 -0800 (PST) (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 hAD5FfGh071447 for ; Wed, 12 Nov 2003 22:15:41 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hAD5Ffbi071446; Wed, 12 Nov 2003 22:15:41 -0700 (MST) (envelope-from rousskov) Date: Wed, 12 Nov 2003 22:15:40 -0700 (MST) From: Alex Rousskov To: OPES WG Subject: Re: Draft minutes from IETF 58 In-Reply-To: <20031113031047.D5FEE79414@server2.messagingengine.com> Message-ID: References: <3FB27350.1070500@mhof.com> <20031113031047.D5FEE79414@server2.messagingengine.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 12 Nov 2003, Markus Hofmann wrote: > Marshall asked who participated in the 1st BOF, the 2nd,... the 1st WG > meeting, the 2nd... What was the breakdown, very approximately? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Thu Nov 13 18:24:42 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28902 for ; Thu, 13 Nov 2003 18:24:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKQpY-0007nT-00 for opes-archive@ietf.org; Thu, 13 Nov 2003 18:24:52 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AKQpX-0007nQ-00 for opes-archive@ietf.org; Thu, 13 Nov 2003 18:24:51 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADN8rkT083445 for ; Thu, 13 Nov 2003 15:08:53 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hADN8rHv083444 for ietf-openproxy-bks; Thu, 13 Nov 2003 15:08:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADN8pkT083433 for ; Thu, 13 Nov 2003 15:08:52 -0800 (PST) (envelope-from markus@mhof.com) Received: from mhof.com (unknown[135.104.20.73]) by comcast.net (sccrmhc12) with ESMTP id <2003111323084801200s6umde> (Authid: mhofmann); Thu, 13 Nov 2003 23:08:48 +0000 Message-ID: <3FB40F04.9010104@mhof.com> Date: Thu, 13 Nov 2003 18:08:52 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031110 Thunderbird/0.4a X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES WG Subject: Re: Draft minutes from IETF 58 References: <3FB27350.1070500@mhof.com> <20031113031047.D5FEE79414@server2.messagingengine.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > What was the breakdown, very approximately? Someone correct me if I recall wrongly, but I'd say about half was at the first BOF, and the number got little smaller the higher the BOF/WG meeting number. -Markus From owner-ietf-openproxy@mail.imc.org Mon Nov 17 06:23:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08392 for ; Mon, 17 Nov 2003 06:23:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALhTR-0004wb-00 for opes-archive@ietf.org; Mon, 17 Nov 2003 06:23:17 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ALhTR-0004wX-00 for opes-archive@ietf.org; Mon, 17 Nov 2003 06:23:17 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAHAvPkT017423 for ; Mon, 17 Nov 2003 02:57:25 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAHAvOuT017414 for ietf-openproxy-bks; Mon, 17 Nov 2003 02:57:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAHAvNkT017401 for ; Mon, 17 Nov 2003 02:57:24 -0800 (PST) (envelope-from geetham@india.hp.com) Received: from observer.india.hp.com (observer.india.hp.com [15.76.122.45]) by atlrel9.hp.com (Postfix) with ESMTP id D0F341C03693; Mon, 17 Nov 2003 07:43:42 -0500 (EST) Received: from india.hp.com (ob9786.india.hp.com [15.76.97.86]) by observer.india.hp.com with ESMTP (8.9.3 (PHNE_28760)/8.8.6 SMKit7.02) id QAA18603; Mon, 17 Nov 2003 16:26:30 +0530 (IST) Message-ID: <3FB8A98C.A7A771E7@india.hp.com> Date: Mon, 17 Nov 2003 16:27:16 +0530 From: Geetha Manjunath Organization: Hewlett Packard ISO X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Markus Hofmann Cc: OPES Group Subject: Re: Draft minutes from IETF 58 References: <3FB27350.1070500@mhof.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > OPES Future > > Markus > > Note: Re-chartering is ONLY for adding new work items, not for staying alive to do work from old charter. Keep new work in OPES framework, not something new. > > Really need to know who will be committed to working on new work items. > > PLEASE POST THOUGHTS AND SUGGESTIONS TO MAIL LIST. PLEASE VOLUNTEER TO DO WORK!!! > I am willing to volunteer some of my time for the rule language related work - review, authoring/editing,whatever is needed... Specifically, on the following work items: 1. Enhancements to 'P language' (if it is decided to have a few) 2. Work that Alex called as "P modules and interfaces" - HTTP protocol specific module work - Defining a specification for the 'P' runtime engine - so that people can claim 'conformant P runtime'. - [Java,C++,Python] Language binding for authoring modules. 3. Investigate whether there are any existing Policy frameworks that help articulate authorization aspects related to ruleset authorship versus content ownership versus hop ownership versus service ownership. 4. Investigate what is needed to enable more standard global deployment of 'P'. Some of the possibilities here are: - Mode by which a client can query the available filtering services. This can be used by the client to authorize a few of them to always execute on his messages. Can we do this with OPTIONS like feature of the OCP client by propagating it to the end-user? Else Can we define a subset of OCP core protocol itself to be supported between 2 OPES entities? - Will an alternate representation for 'P' help in speeding up things? Is it useful to have a pre-parsed intermediate representation of 'P'? Does a virtual machine model be useful here? 5. Investigate whether 'filtering service' can be made as a 'first class service' that can be requested by the client? If so, what is the mode by which a client can request 'P' processing (message embedded?) Is is useful to have a way by which the user can request for a specific filter to be applied for specific HTTP requests? Alternatively, is it useful to allow clients to query for the location of a filter to later send in their files to be adapted by the filter? BTW, I am not sure which of these can/cannot come under OPES charter... Thanks and regards Geetha From owner-ietf-openproxy@mail.imc.org Mon Nov 17 09:51:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13225 for ; Mon, 17 Nov 2003 09:51:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALkik-0007L1-00 for opes-archive@ietf.org; Mon, 17 Nov 2003 09:51:18 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ALkik-0007Ky-00 for opes-archive@ietf.org; Mon, 17 Nov 2003 09:51:18 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAHEa7kT029835 for ; Mon, 17 Nov 2003 06:36:07 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAHEa7Jc029833 for ietf-openproxy-bks; Mon, 17 Nov 2003 06:36:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAHEa5kT029824 for ; Mon, 17 Nov 2003 06:36:05 -0800 (PST) (envelope-from markus@mhof.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id hAHEa4fO003241 for ; Mon, 17 Nov 2003 09:36:04 -0500 (EST) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id hAHEZv0C079260 for ; Mon, 17 Nov 2003 09:35:57 -0500 (EST) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id hAHEZuMl025599 for ; Mon, 17 Nov 2003 09:35:57 -0500 (EST) Message-ID: <3FB8DD02.7080702@mhof.com> Date: Mon, 17 Nov 2003 09:36:50 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: Draft minutes from IETF 58 References: <3FB27350.1070500@mhof.com> In-Reply-To: <3FB27350.1070500@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 Hi, since there were no further comments, these minutes are final now and have been forwarded to IETF secretariat. -Markus Markus Hofmann wrote: > Folks, > > attached the *draft* minutes from our meeting at IETF 58. Thanks to Eric > for taking the minutes, and thanks to Marshall for taking care of the > Jabber. > > In case you've comments, please provide them by Friday, 11/14, 5pm > (EDT), so that we can forward the minutes to the IETF in a timely manner. > > Thanks, > Markus > > > ------------------------------------------------------------------------ > > Open Pluggable Edge Services (OPES) > > 58th IETF Meeting > > 11 November 2003 > > > > Eric Burger, scribe > > > > Jabber log is at > > > > > > ===== > > Agenda Bashing: Markus Hofmann > > > > ===== > > Document Status - See slides & ID Tracker > > Goal: finish documents in "ID Exists" status by end of November > > > > ===== > > OPES Treatment of IAB Considerations > > draft-ietf-opes-iab-03 - Abbie Barbir > > See slides > > On Considerations 3.1 & 3.2: chose to make notifications optional; focus on tracing. > > Clearly, OPES cannot do end-to-end encryption. OPES can do hop-by-hop encryption. > > > > Sally Floyd: Likes document; addresses IAB issues > > > > Markus: expect WGLC soon after IETF > > > > ===== > > OPES process and end points communications > > Draft-ietf-opes-end-comm-05 - Abbie Barbir > > See slides > > > > Tracing > > ------- > > Open issue: What is OPES Tracing? Current wording has problem with "inclusion". Does that mean that trace can be adapted (pruned, modified, added-to)? > > > > Should we allow trace adaptation? > > > > Trace information designed for system administrators, not users. > > > > Bypass > > ------ > > IAB Considerations said to bypass non-OPES content. But, what is OPES content? Solution: punt -- definition of OPES content is outside scope of OPES. > > > > Sally Floyd: Comment: IAB document isn't legal language. Try to figure out what the intent is. The IAB document does not mean "user has to have a way to bypass firewalls, boundaries, etc." It is saying, "If a user asks for content from web server, and the content gets mangled by an OPES server, then user needs to be able to figure out what went wrong." > > > > MUST/SHOULD/MAY questions: see slides > > > > w.r.t. OPES bypass - Sally Floyd: Source of IAB concern about non-OPES is data integrity, e.g., how does one detect malicious transformation of data. > > > > ===== > > OPC: OPES Callout Protocol > > draft-ietf-opes-ocp-core-03 - Abbie Barbir > > see slides > > > > Should authentication be in the core or binding (HTTP)? > > Should authentication be in this draft, or a separate draft? > > Same issues for Encryption. > > Should we get IETF review before going to WGLC? Marshall: "NO" > > Application message identifiers are irrelevant for HTTP, but might not be robust enough for SMTP. Should we dump them and figure out the right thing for SMTP later, if there is a later? > > > > Markus: Please post comments on AM-ID's to the list! > > > > ===== > > HTTP Adaptation with OPES > > Draft-ietf-opes-http-01 (from Martin and Alex) presented by Markus > > See slides > > > > Targeting WGLC for end of November > > > > Need HTTP expert to review HTTP-specific issues, and in particular on HTTP-specific security considerations > > > > Open issues: How to avoid blocking; skip uninteresting request bodies in 'response mode'; and handle HTTP-specific things like 100 Continue and 206 Partial Content? > > > > Please check for XXX's in document and send text to mail list! > > > > ===== > > P: Message Processing Language > > Presented by Markus > > See slides > > > > Open issues: > > What information is available to interpreter? Complete message? Headers only? Punt? > > Is doing HTTP module in scope for work group? If so, in what document? > > Should work group define interfaces between P interpreters and module suppliers or callout services? If so, how do services return results, e.g., from OCP? > > > > Ted Hardie: Working group should specify what information is available to the interpreter. Not a value judgement of where, just we should set expectations for community. > > > > Ted Hardie: When do we expect the current charter items to be done? > > Markus: Hopefully December. > > > > ===== > > OPES Future > > Markus > > > > Note: Re-chartering is ONLY for adding new work items, not for staying alive to do work from old charter. Keep new work in OPES framework, not something new. > > > > Really need to know who will be committed to working on new work items. > > > > PLEASE POST THOUGHTS AND SUGGESTIONS TO MAIL LIST. PLEASE VOLUNTEER TO DO WORK!!! > > > > OPES for SMTP and IMAP: does it conflict with lemonade? > > Eric Burger: Not at all. Definitely fits into OPES, just need to coordinate groups. > > > > If you have interest in a topic, want to be an editor or contributor, please post to list. > > > > Marshall: Importance of finishing documents -- "credibility is the coin of the realm." From owner-ietf-openproxy@mail.imc.org Mon Nov 17 10:05:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13805 for ; Mon, 17 Nov 2003 10:05:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALkx7-0007UO-00 for opes-archive@ietf.org; Mon, 17 Nov 2003 10:06:09 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ALkx6-0007UL-00 for opes-archive@ietf.org; Mon, 17 Nov 2003 10:06:08 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAHEnikT030513 for ; Mon, 17 Nov 2003 06:49:44 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAHEni3h030512 for ietf-openproxy-bks; Mon, 17 Nov 2003 06:49:44 -0800 (PST) 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.10/8.12.8) with ESMTP id hAHEngkT030504 for ; Mon, 17 Nov 2003 06:49:42 -0800 (PST) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id hAHEnhfO003381 for ; Mon, 17 Nov 2003 09:49:43 -0500 (EST) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id hAHEnaJl083722 for ; Mon, 17 Nov 2003 09:49:36 -0500 (EST) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id hAHEnaMl025882 for ; Mon, 17 Nov 2003 09:49:36 -0500 (EST) Message-ID: <3FB8E036.5010103@mhof.com> Date: Mon, 17 Nov 2003 09:50:30 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: Draft minutes from IETF 58 References: <3FB27350.1070500@mhof.com> <3FB8A98C.A7A771E7@india.hp.com> In-Reply-To: <3FB8A98C.A7A771E7@india.hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Geetha, > I am willing to volunteer some of my time for the rule language related > work - review, authoring/editing,whatever is needed... Specifically, > on the following work items: > [...] Thanks much for your suggestions and your email indicating your willingness to contribute to possible future work items. Several good ideas - we'll discuss them in greater detail a little later when we've wrapped up the active documents and decide on possible re-charter. Folks - anyone else interested in working on new work items? We've a nice collection of ideas so far, and three folks who expressed their willingness and ability to keep contributing. Thanks, Markus From owner-ietf-openproxy@mail.imc.org Mon Nov 17 19:42:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15854 for ; Mon, 17 Nov 2003 19:42:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALtwe-0002QP-00 for opes-archive@ietf.org; Mon, 17 Nov 2003 19:42:16 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ALtwe-0002QM-00 for opes-archive@ietf.org; Mon, 17 Nov 2003 19:42:16 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAI0StkT058244 for ; Mon, 17 Nov 2003 16:28:55 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAI0SsOQ058243 for ietf-openproxy-bks; Mon, 17 Nov 2003 16:28:54 -0800 (PST) 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.10/8.12.8) with ESMTP id hAI0SokT058232 for ; Mon, 17 Nov 2003 16:28:53 -0800 (PST) (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 hAI0SgGh067353 for ; Mon, 17 Nov 2003 17:28:42 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hAI0Sg1U067352; Mon, 17 Nov 2003 17:28:42 -0700 (MST) (envelope-from rousskov) Date: Mon, 17 Nov 2003 17:28:42 -0700 (MST) From: Alex Rousskov To: OPES WG Subject: Re: HTTP/OCP: OPES-Via to replace OPES-Processor and OPES-Service In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This issue prevents us from issuing WG last call on IAB draft and is a dependency between IAB draft and HTTP Adaptations draft. I will be making the OPES-Via modifications described below in both drafts: - delete OPES-Processor and OPES-Service headers - add OPES-Via header that contains trace entries for OPES system, OPES processor, and callout services. - leave OPES-System header that contains OPES system identifiers only. These identifiers will be repeated in OPES-Via. This repetition will establish boundaries between entries for two OPES systems (consumer and producer) in a detailed OPES-Via trace. Please comment or object ASAP. Thank you, Alex. On Fri, 24 Oct 2003, Alex Rousskov wrote: > > The current HTTP/OCP draft defines OPES-System, OPES-Processor, and > OPES-Service to support tracing requirements of the Communications > draft. OPES-System is mean to contain a URL that a user will access to > get high-level information about what is going on. The OPES-Processor > and OPES-Service headers are to specify OPES agents that touched the > application message. > > OPES processor and service are not a well-defined thing. A processor > can be a service at the same time, and vice-versa. It is possible that > there will be a third kind of entity that would need to be traced in > the future (proxylet or whatever). > > Having two headers makes it impossible to determine the order of > agent invocations. Was the second processor or the second service > applied first? > > Header names are singular but may contain multiple agent entries. > > To solve all of the above problems, I suggest that we use a > single, more general header: OPES-Via. > > I will make documentation changes unless there are objections or > better ideas. > > Alex. > > P.S. OPES-System is not perfect either, especially given the > fact that there could be two systems applied to the > same message. In that case, there is no way to match > OPES-Via entries with OPES-System entries. > > We could put everything into OPES-Via, I guess, but that > would make it more difficult for end-user to troubleshoot. > One the other hand, do we really expect dumb end-users > to trouble shoot (the smart ones will figure it out)? > From owner-ietf-openproxy@mail.imc.org Tue Nov 18 10:01:37 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23349 for ; Tue, 18 Nov 2003 10:01:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM7MS-0006R9-00 for opes-archive@ietf.org; Tue, 18 Nov 2003 10:01:48 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AM7MR-0006R5-00 for opes-archive@ietf.org; Tue, 18 Nov 2003 10:01:47 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAIEfCkT066968 for ; Tue, 18 Nov 2003 06:41:12 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAIEfCeS066967 for ietf-openproxy-bks; Tue, 18 Nov 2003 06:41:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAIEfBkT066962 for ; Tue, 18 Nov 2003 06:41:11 -0800 (PST) (envelope-from markus@mhof.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id hAIEfBfO013936 for ; Tue, 18 Nov 2003 09:41:11 -0500 (EST) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id hAIEf50C083405 for ; Tue, 18 Nov 2003 09:41:05 -0500 (EST) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id hAIEf4Ml020435 for ; Tue, 18 Nov 2003 09:41:05 -0500 (EST) Message-ID: <3FBA2FB6.4030300@mhof.com> Date: Tue, 18 Nov 2003 09:41:58 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES WG Subject: Re: HTTP/OCP: OPES-Via to replace OPES-Processor and OPES-Service References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > I will be making the OPES-Via modifications described below in both > drafts: > > - delete OPES-Processor and OPES-Service headers > > - add OPES-Via header that contains trace entries for > OPES system, OPES processor, and callout services. > > - leave OPES-System header that contains OPES system > identifiers only. These identifiers will be repeated > in OPES-Via. This repetition will establish > boundaries between entries for two OPES systems > (consumer and producer) in a detailed OPES-Via trace. Sounds good to me. -Markus From owner-ietf-openproxy@mail.imc.org Tue Nov 18 10:32:45 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25823 for ; Tue, 18 Nov 2003 10:32:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM7qa-0006yF-00 for opes-archive@ietf.org; Tue, 18 Nov 2003 10:32:56 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AM7qa-0006yB-00 for opes-archive@ietf.org; Tue, 18 Nov 2003 10:32:56 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAIFL7kT069247 for ; Tue, 18 Nov 2003 07:21:07 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAIFL7oL069246 for ietf-openproxy-bks; Tue, 18 Nov 2003 07:21:07 -0800 (PST) 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.10/8.12.8) with ESMTP id hAIFL5kT069240 for ; Tue, 18 Nov 2003 07:21:05 -0800 (PST) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id hAIFL6xl099651 for ; Tue, 18 Nov 2003 10:21:06 -0500 (EST) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id hAIFKxJl093495 for ; Tue, 18 Nov 2003 10:20:59 -0500 (EST) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id hAIFKxMl022076 for ; Tue, 18 Nov 2003 10:20:59 -0500 (EST) Message-ID: <3FBA3911.3040508@mhof.com> Date: Tue, 18 Nov 2003 10:21:53 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: feed back WG Last Call: draft-ietf-opes-end-comm-05: Definition o f a trace References: <87609AFB433BD5118D5E0002A52CD7540788841D@zcard0k6.ca.nortel.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Folks, quick update on the status of draft-ietf-opes-end-comm-05: Abbie is currently addressing Alex comments from WGLC and expects to submit a new version by Monday next week. We'll then submit this new version to IESG. -Markus From owner-ietf-openproxy@mail.imc.org Tue Nov 18 12:49: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 MAA03751 for ; Tue, 18 Nov 2003 12:49:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM9zC-00021s-00 for opes-archive@ietf.org; Tue, 18 Nov 2003 12:49:58 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AM9zB-00021p-00 for opes-archive@ietf.org; Tue, 18 Nov 2003 12:49:57 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAIHZNkT074982 for ; Tue, 18 Nov 2003 09:35:23 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAIHZN0B074981 for ietf-openproxy-bks; Tue, 18 Nov 2003 09:35:23 -0800 (PST) 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.10/8.12.8) with ESMTP id hAIHZMkT074976 for ; Tue, 18 Nov 2003 09:35:22 -0800 (PST) (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 hAIHZNGh009231; Tue, 18 Nov 2003 10:35:23 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hAIHZMQp009230; Tue, 18 Nov 2003 10:35:22 -0700 (MST) (envelope-from rousskov) Date: Tue, 18 Nov 2003 10:35:22 -0700 (MST) From: Alex Rousskov To: Markus Hofmann cc: OPES Group Subject: Re: feed back WG Last Call: draft-ietf-opes-end-comm-05: Definition o f a trace In-Reply-To: <3FBA3911.3040508@mhof.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD7540788841D@zcard0k6.ca.nortel.com> <3FBA3911.3040508@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Markus, Isn't one more WG Last Call required if there were non-editorial changes made since the last WG Last Call? Just want to make sure we play by the IETF rules here... Alex. On Tue, 18 Nov 2003, Markus Hofmann wrote: > > Folks, > > quick update on the status of draft-ietf-opes-end-comm-05: > > Abbie is currently addressing Alex comments from WGLC and expects to > submit a new version by Monday next week. We'll then submit this new > version to IESG. > > -Markus > > From owner-ietf-openproxy@mail.imc.org Tue Nov 18 17:06: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 RAA20754 for ; Tue, 18 Nov 2003 17:06:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AME01-0000Gg-00 for opes-archive@ietf.org; Tue, 18 Nov 2003 17:07:05 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AME00-0000GY-00 for opes-archive@ietf.org; Tue, 18 Nov 2003 17:07:05 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAILp5kT083285 for ; Tue, 18 Nov 2003 13:51:05 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAILp4QQ083284 for ietf-openproxy-bks; Tue, 18 Nov 2003 13:51:04 -0800 (PST) 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.10/8.12.8) with ESMTP id hAILp3kT083278 for ; Tue, 18 Nov 2003 13:51:03 -0800 (PST) (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 hAILp5Gh022457; Tue, 18 Nov 2003 14:51:05 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hAILp5ID022456; Tue, 18 Nov 2003 14:51:05 -0700 (MST) (envelope-from rousskov) Date: Tue, 18 Nov 2003 14:51:05 -0700 (MST) From: Alex Rousskov To: Markus Hofmann cc: OPES WG Subject: Re: HTTP/OCP: OPES-Via to replace OPES-Processor and OPES-Service In-Reply-To: <3FBA2FB6.4030300@mhof.com> Message-ID: References: <3FBA2FB6.4030300@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: I have updated HTTP Adaptations draft accordingly: http://www.measurement-factory.com/tmp/opes Martin has not reviewed my changes yet. Alex. On Tue, 18 Nov 2003, Markus Hofmann wrote: > > Alex Rousskov wrote: > > > I will be making the OPES-Via modifications described below in both > > drafts: > > > > - delete OPES-Processor and OPES-Service headers > > > > - add OPES-Via header that contains trace entries for > > OPES system, OPES processor, and callout services. > > > > - leave OPES-System header that contains OPES system > > identifiers only. These identifiers will be repeated > > in OPES-Via. This repetition will establish > > boundaries between entries for two OPES systems > > (consumer and producer) in a detailed OPES-Via trace. > > Sounds good to me. > > -Markus > > From owner-ietf-openproxy@mail.imc.org Wed Nov 19 10:49: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 KAA22871 for ; Wed, 19 Nov 2003 10:49:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMUag-0001YV-00 for opes-archive@ietf.org; Wed, 19 Nov 2003 10:50:02 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AMUaf-0001YQ-00 for opes-archive@ietf.org; Wed, 19 Nov 2003 10:50:02 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAJFVEkT096374 for ; Wed, 19 Nov 2003 07:31:14 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAJFVEX0096373 for ietf-openproxy-bks; Wed, 19 Nov 2003 07:31:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAJFVDkT096368 for ; Wed, 19 Nov 2003 07:31:13 -0800 (PST) (envelope-from markus@mhof.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id hAJFVDfO025250 for ; Wed, 19 Nov 2003 10:31:13 -0500 (EST) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id hAJFV60C087778 for ; Wed, 19 Nov 2003 10:31:07 -0500 (EST) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id hAJFV6Ml016371 for ; Wed, 19 Nov 2003 10:31:06 -0500 (EST) Message-ID: <3FBB8CF0.2010403@mhof.com> Date: Wed, 19 Nov 2003 10:32:00 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: feed back WG Last Call: draft-ietf-opes-end-comm-05: Definition o f a trace References: <87609AFB433BD5118D5E0002A52CD7540788841D@zcard0k6.ca.nortel.com> <3FBA3911.3040508@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: > Isn't one more WG Last Call required if there were > non-editorial changes made since the last WG Last Call? Just want to > make sure we play by the IETF rules here... We certainly post the updated draft to the list for review by the WG before submitting to IESG. However, given that (a) we already had WGLC on the draft, and (b) your detailed comments were the only ones, and (c) that no one objected you suggestions, I expect to keep this additioanl review time very short, so that we submit to IESG shorty after. -Markus From owner-ietf-openproxy@mail.imc.org Wed Nov 19 15:41: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 PAA10840 for ; Wed, 19 Nov 2003 15:41:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMZ9K-0001pm-00 for opes-archive@ietf.org; Wed, 19 Nov 2003 15:42:07 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AMZ9K-0001pg-00 for opes-archive@ietf.org; Wed, 19 Nov 2003 15:42:06 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAJKSUkT010494 for ; Wed, 19 Nov 2003 12:28:30 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAJKSUg4010493 for ietf-openproxy-bks; Wed, 19 Nov 2003 12:28:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAJKSTkT010486 for ; Wed, 19 Nov 2003 12:28:29 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09864; Wed, 19 Nov 2003 15:28:17 -0500 (EST) Message-Id: <200311192028.PAA09864@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-openproxy@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-opes-ocp-core-03.txt Date: Wed, 19 Nov 2003 15:28:17 -0500 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Pluggable Edge Services Working Group of the IETF. Title : OPES Callout Protocol Core Author(s) : A. Rousskov Filename : draft-ietf-opes-ocp-core-03.txt Pages : 69 Date : 2003-11-19 This document specifies Open Pluggable Edge Services (OPES) Callout Protocol (OCP). OCP is an application-agnostic protocol that facilitates exchange of application messages between an OPES processor and a callout server, for the purpose of adaptation of application messages at the callout server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opes-ocp-core-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-opes-ocp-core-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-opes-ocp-core-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-11-19144754.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-opes-ocp-core-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-opes-ocp-core-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-19144754.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-openproxy@mail.imc.org Wed Nov 19 16:47: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 QAA15086 for ; Wed, 19 Nov 2003 16:47:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMaAL-0003PL-00 for opes-archive@ietf.org; Wed, 19 Nov 2003 16:47:13 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AMaAK-0003PI-00 for opes-archive@ietf.org; Wed, 19 Nov 2003 16:47:12 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAJLZIkT013356 for ; Wed, 19 Nov 2003 13:35:18 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAJLZIxS013355 for ietf-openproxy-bks; Wed, 19 Nov 2003 13:35:18 -0800 (PST) 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.10/8.12.8) with ESMTP id hAJLZGkT013350 for ; Wed, 19 Nov 2003 13:35:17 -0800 (PST) (envelope-from markus@mhof.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id hAJLZIxl014232 for ; Wed, 19 Nov 2003 16:35:18 -0500 (EST) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id hAJLZ90C024940 for ; Wed, 19 Nov 2003 16:35:09 -0500 (EST) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id hAJLZ9Ml028042 for ; Wed, 19 Nov 2003 16:35:09 -0500 (EST) Message-ID: <3FBBE243.4050106@mhof.com> Date: Wed, 19 Nov 2003 16:36:03 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: WG Last Call: draft-ietf-opes-ocp-core-03.txt Content-Type: multipart/mixed; boundary="------------000301060106080608070202" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. --------------000301060106080608070202 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit We are starting WG last call on the "OPES Callout Protocol Core" draft (see attached). The last call period closes on Wednesday, November 26 at 5pm EST. Please post any comments, etc. to the mailing list, and please point out whether you feel your comment is editorial or a show-stopper. Thanks, Markus --------------000301060106080608070202 Content-Type: message/rfc822; name="I-D ACTION:draft-ietf-opes-ocp-core-03.txt" Content-Disposition: inline; filename="I-D ACTION:draft-ietf-opes-ocp-core-03.txt" Return-Path: Received: from server3.fastmail.fm (server3.internal [10.202.2.134]) by server2.fastmail.fm (Cyrus v2.1.9) with LMTP; Wed, 19 Nov 2003 15:50:00 -0500 X-Sieve: CMU Sieve 2.2 X-Spam-score: 0.2 X-Spam-hits: BAYES_00, MIME_BOUND_NEXTPART, NO_REAL_NAME X-Virus-checked: Yes X-Attached: draft-ietf-opes-ocp-core-03.txt X-Attached: draft-ietf-opes-ocp-core-03.txt X-Resolved-to: hofmann@fastmail.fm X-Delivered-to: markus@mhof.com X-Mail-from: owner-ietf-openproxy@mail.imc.org Received: from above.proper.com (above.proper.com [208.184.76.39]) by mail.messagingengine.com (Postfix) with ESMTP id 6320F99C29 for ; Wed, 19 Nov 2003 15:49:56 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAJKSUkT010494 for ; Wed, 19 Nov 2003 12:28:30 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAJKSUg4010493 for ietf-openproxy-bks; Wed, 19 Nov 2003 12:28:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAJKSTkT010486 for ; Wed, 19 Nov 2003 12:28:29 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09864; Wed, 19 Nov 2003 15:28:17 -0500 (EST) Message-Id: <200311192028.PAA09864@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-openproxy@imc.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-opes-ocp-core-03.txt Date: Wed, 19 Nov 2003 15:28:17 -0500 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Pluggable Edge Services Working Group of the IETF. Title : OPES Callout Protocol Core Author(s) : A. Rousskov Filename : draft-ietf-opes-ocp-core-03.txt Pages : 69 Date : 2003-11-19 This document specifies Open Pluggable Edge Services (OPES) Callout Protocol (OCP). OCP is an application-agnostic protocol that facilitates exchange of application messages between an OPES processor and a callout server, for the purpose of adaptation of application messages at the callout server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opes-ocp-core-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-opes-ocp-core-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-opes-ocp-core-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-11-19144754.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-opes-ocp-core-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-opes-ocp-core-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-19144754.I-D@ietf.org> --OtherAccess-- --NextPart-- --------------000301060106080608070202-- From owner-ietf-openproxy@mail.imc.org Thu Nov 20 16:00: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 QAA26128 for ; Thu, 20 Nov 2003 16:00:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMvuf-0002YE-00 for opes-archive@ietf.org; Thu, 20 Nov 2003 16:00:29 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AMvue-0002YA-00 for opes-archive@ietf.org; Thu, 20 Nov 2003 16:00:28 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAKKiKkT051808 for ; Thu, 20 Nov 2003 12:44:20 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAKKiKad051807 for ietf-openproxy-bks; Thu, 20 Nov 2003 12:44:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail2.webwasher.com (host2.webwasher.com [217.146.159.49]) by above.proper.com (8.12.10/8.12.8) with SMTP id hAKKiHkT051798 for ; Thu, 20 Nov 2003 12:44:18 -0800 (PST) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id 0R6PLRJV outgoing id D9O5WN0X; 20 Nov 2003 23:51:37 +0100 Received: from jadzia ([10.2.0.97]) by mail.WEBWASHER.COM with Microsoft SMTPSVC(5.0.2195.6713); Thu, 20 Nov 2003 21:44:02 +0100 Message-ID: <002001c3afa7$01a55ec0$9c30eed9@jadzia> From: "Martin Stecher" To: "Alex Rousskov" , "Markus Hofmann" Cc: "OPES WG" References: <3FBA2FB6.4030300@mhof.com> Subject: Re: HTTP/OCP: OPES-Via to replace OPES-Processor and OPES-Service Date: Thu, 20 Nov 2003 21:43:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 20 Nov 2003 20:44:02.0946 (UTC) FILETIME=[08422E20:01C3AFA7] Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi Alex, > Other OPES agents MUST use the OPES-Via header if they add their > tracing entries. All OPES agents MUST append their entries. I stumbled over the second sentence. To me it sounds that all agents MUST add their entries but what you want to say is that if an agents add its entry, it MUST append at the end of existing lists and not replace or insert somewhere else > If an OPES-Via header is used in the original application message, an > OPES System MUST append its entry to the OPES-Via header. Otherwise, > an OPES System MAY append its entry to the OPES-Via header. Again not so clear to me. "Otherwise" is if there is no OPES-Via header in the original app message, so how can someone append its entry to something that does not exist. So how about: Otherwise, an OPES System MAY add an OPES-Via header with its entry. Typo in next sentence: > If an > OPES System is using both headers, it MUST add identical trace > entries except it MAY omit some or all trace-entry parameters from > the the OPES-Via header. Double "the". Regards Martin ----- Original Message ----- From: "Alex Rousskov" To: "Markus Hofmann" Cc: "OPES WG" Sent: Tuesday, November 18, 2003 10:51 PM Subject: Re: HTTP/OCP: OPES-Via to replace OPES-Processor and OPES-Service > > > I have updated HTTP Adaptations draft accordingly: > > http://www.measurement-factory.com/tmp/opes > > Martin has not reviewed my changes yet. > > Alex. > > On Tue, 18 Nov 2003, Markus Hofmann wrote: > > > > > Alex Rousskov wrote: > > > > > I will be making the OPES-Via modifications described below in both > > > drafts: > > > > > > - delete OPES-Processor and OPES-Service headers > > > > > > - add OPES-Via header that contains trace entries for > > > OPES system, OPES processor, and callout services. > > > > > > - leave OPES-System header that contains OPES system > > > identifiers only. These identifiers will be repeated > > > in OPES-Via. This repetition will establish > > > boundaries between entries for two OPES systems > > > (consumer and producer) in a detailed OPES-Via trace. > > > > Sounds good to me. > > > > -Markus > > > > > From owner-ietf-openproxy@mail.imc.org Thu Nov 20 16:30:44 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29094 for ; Thu, 20 Nov 2003 16:30:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMwO8-0003kv-00 for opes-archive@ietf.org; Thu, 20 Nov 2003 16:30:56 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AMwO7-0003kq-00 for opes-archive@ietf.org; Thu, 20 Nov 2003 16:30:55 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAKLDfkT053044 for ; Thu, 20 Nov 2003 13:13:41 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAKLDfCc053043 for ietf-openproxy-bks; Thu, 20 Nov 2003 13:13:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail2.webwasher.com (host2.webwasher.com [217.146.159.49]) by above.proper.com (8.12.10/8.12.8) with SMTP id hAKLDckT053038 for ; Thu, 20 Nov 2003 13:13:39 -0800 (PST) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id ZNNAYRDQ outgoing id JI9DZJFC; 21 Nov 2003 00:21:09 +0100 Received: from jadzia ([10.2.0.97]) by mail.WEBWASHER.COM with Microsoft SMTPSVC(5.0.2195.6713); Thu, 20 Nov 2003 22:13:34 +0100 Message-ID: <002701c3afab$21e7be90$9c30eed9@jadzia> From: "Martin Stecher" To: "Alex Rousskov" , "OPES WG" References: Subject: Re: HTTP Adaptations issues for f2f discussion Date: Thu, 20 Nov 2003 22:13:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 20 Nov 2003 21:13:34.0946 (UTC) FILETIME=[2873EC20:01C3AFAB] Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi, here a few comments. > > 3. Partial Content > > Do we need to say anything special about adapting > "206 Partial Content" HTTP responses? There are > two cases here: multipart/byteranges media type and a > single "part" case. > > multipart/byteranges are expressed via Content-Type, > not Content-Encoding. Thus, we currently have no > mechanism to negotiate support for those. On the > other hand HTTP does have such a mechanism for its > agents (if you do not support it, you do not ask > for multiple parts). > > IMO, we should say something, even if we are not > going to provide explicit support for this > special content type. I think that this is out of scope because it is a Content-Type thing. Either an agent should handle these types or should not care, or it has to try to get a request profile service into the traffic that removes the support advertisement of partial content from the HTTP requests. Is this something we need to describe in the draft? > > > 4. Authentication and other sensitive information. > > Do we need to specify whether authentication information > should be passed "as is" to callout servers by default? > > IMO, it should be because we pass all other "sensitive" > information already. We should probably explicitly say > that the processor should treat any sensitive data as > regular data in this context (by default). This places > stringent requirements on callout server security and > trust, but that is how OPES is supposed to work. Agreed. > > > 5. FTP -> HTTP > > HTTP proxies that proxy ftp://host URLs have to > do FTP and transform FTP messages to HTTP responses. > > Do we need to mention this case in some way? Is it > special or out of scope (i.e., we assume that all > transformations have been already performed). As you said, FTP over HTTP to native FTP transformation has to be done by the last HTTP proxy server and has nothing to do with HTTP adaptation of OCP. The only difference to "normal" HTTP is that the URL starts with ftp. Since 3.2.2 of RFC 2616 specifies that a http_URL has to start with "http:", OCP/HTTP does not apply which is a shame because it works (if the service supports it). Other protocol prefixes could also be there; it's not only for FTP. Is there somewhere something said how HTTP proxies should handle URLs that have another protocol prefix than "http:", especially if they have another next-hop-proxy and do not need to do protocol conversion? This could probably be copied to our case. > > > 6. 100 Continue > > 100 Continue messages are sent as a part of an HTTP > transaction but they are not true "responses". > What should an OPES processor do about > these? Technically, they can be viewed as another > original application message to be adapted within > the same OCP transaction (multiple original am-ids)! > > If we want to avoid multiple original am-ids, but > still want to adapt 100 Continue messages, we can > introduce a notion of "related transactions". Each > 100 Continue would cause the processor to start > a new OCP transaction, related to the original > one (so that the request message does not need to > be resent). But, on a technical level, multiple > original am-ids is exactly what is going in here, > I guess. > > We have to say whether processor must skip them. > If processor skips them, does it open a [security] > whole for clients or servers to bypass OPES. These > messages do not have bodies, but their headers can > be used to send information that OPES entities may > be interested in. I agree that multipe origin am-ids would solve this issue best but it seems to be the wrong timing to me to change the concept now and allow them. In ICAP/1.0 I have never seen an encapsulated 100 Continue message. But this does not mean that there are no such messages. I think that a) most ICAP clients do not send 100 Continue messages to ICAP servers and b) most/some ICAP servers will simply return 100 Continue messages unchanged or apply some header filters usually without effect since those messages do not have many header fields in praxis While ICAP/1.0 has no transaction concept, it is o.k. to send two separate RESPMOD messages, one for the 100 Continue and one for the final response. > > > 7. CONNECT method > > CONNECT method establishes a tunnel through the > proxy. Should OPES processor adapt just the CONNECT > request and response, or should it stay in the loop > for the tunnel itself? If the processor stays, we > do not have a good mechanism in the current draft > to adapt a bi-directional tunnel, right? > > Tunnel adaptation is more like streaming adaptation, > isn't it? That's an unchartered territory for OCP, > including OCP Core. > > We have to be explicit what the processor is supposed > to do. A typical ICAP/1.0 client would generate a REQMOD request for a CONNECT request but would not try a RESPMOD request for the response or tunneled data. HTTPS proxies can generate REQMOD/RESPMOD messages for the decoded HTTP of course. > > > 8. SIRs or HTTP WG review > > Should we solicit SIRs and/or HTTP WG review of > this. There is no formal HTTP WG, but there is > a semi-alive mailing list that HTTP gurus read. > > > 9. Concurrent request and response. > > What happens when the HTTP client is sending a request > body _while_ the HTTP server is sending a response, and the > callout server requested HTTP request body to > adapt the HTTP response. Do we have a deadlock? > > The above can happen when the HTTP server is > sending a constant response regardless of the PUT/POST > body or is sending an error message. For example, > an error message can say "I got 1MB of your POST > request and I will not accept any more. Go away!". > OPES has to adapt such a response, but it looks > like we cannot until the client stops and the > client may not stop for another 100MBs (because > it is broken/malicious or because it does not > get the error message that is waiting for our > adaptation). This is indeed a problem. Do we have use cases where a response profile OCP service needs to see the original request body? Filters I can think of that use the request-body part better belong to request profile. ICAP/1.0 does not support request-body encapsulation in RESPMOD, so there are no existing services for this feature. Is it a good moment to remove support for this application message part from request profile? > > > 10. Huge request bodies and RESPMOD > > There is no way for the callout server to > skip a huge request body when doing RESPMOD. > Is that acceptable? Should OCP Core support > "skip N original octets" interface (that > does not affect offset/size calculations). > Should HTTP draft support "skip this part > until its end" interface? Instead? Removing request-body part would solve this too ;-) Regards Martin From owner-ietf-openproxy@mail.imc.org Thu Nov 20 16:48: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 QAA00489 for ; Thu, 20 Nov 2003 16:48:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMwf2-0004Gu-00 for opes-archive@ietf.org; Thu, 20 Nov 2003 16:48:24 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AMwf1-0004Gr-00 for opes-archive@ietf.org; Thu, 20 Nov 2003 16:48:23 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAKLJIkT053196 for ; Thu, 20 Nov 2003 13:19:18 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAKLJIpg053194 for ietf-openproxy-bks; Thu, 20 Nov 2003 13:19:18 -0800 (PST) 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.10/8.12.8) with ESMTP id hAKLJGkT053186 for ; Thu, 20 Nov 2003 13:19:16 -0800 (PST) (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 hAKLJIGh038572; Thu, 20 Nov 2003 14:19:18 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hAKLJIMe038571; Thu, 20 Nov 2003 14:19:18 -0700 (MST) (envelope-from rousskov) Date: Thu, 20 Nov 2003 14:19:18 -0700 (MST) From: Alex Rousskov To: OPES WG Subject: Re: HTTP/OCP: OPES-Via to replace OPES-Processor and OPES-Service In-Reply-To: <002001c3afa7$01a55ec0$9c30eed9@jadzia> Message-ID: References: <3FBA2FB6.4030300@mhof.com> <002001c3afa7$01a55ec0$9c30eed9@jadzia> 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, 20 Nov 2003, Martin Stecher wrote: > Hi Alex, > > > Other OPES agents MUST use the OPES-Via header if they add their > > tracing entries. All OPES agents MUST append their entries. > > I stumbled over the second sentence. To me it sounds that all agents > MUST add their entries but what you want to say is that if an agents > add its entry, it MUST append at the end of existing lists and not > replace or insert somewhere else You are right, this MUST should be reworded to indicate the latter meaning. > > If an OPES-Via header is used in the original application message, > > an OPES System MUST append its entry to the OPES-Via header. > > Otherwise, an OPES System MAY append its entry to the OPES-Via > > header. > > Again not so clear to me. "Otherwise" is if there is no OPES-Via > header in the original app message, so how can someone append its > entry to something that does not exist. So how about: Otherwise, an > OPES System MAY add an OPES-Via header with its entry. Sounds good to me. It is still not perfect because, technically, one can have an empty OPES-Via header. Your version is better though. > Typo in next sentence: > > If an > > OPES System is using both headers, it MUST add identical trace > > entries except it MAY omit some or all trace-entry parameters from > > the the OPES-Via header. > Double "the". Ack. Thank you, Alex. > ----- Original Message ----- > From: "Alex Rousskov" > To: "Markus Hofmann" > Cc: "OPES WG" > Sent: Tuesday, November 18, 2003 10:51 PM > Subject: Re: HTTP/OCP: OPES-Via to replace OPES-Processor and OPES-Service > > > > > > > > I have updated HTTP Adaptations draft accordingly: > > > > http://www.measurement-factory.com/tmp/opes > > > > Martin has not reviewed my changes yet. > > > > Alex. > > > > On Tue, 18 Nov 2003, Markus Hofmann wrote: > > > > > > > > Alex Rousskov wrote: > > > > > > > I will be making the OPES-Via modifications described below in both > > > > drafts: > > > > > > > > - delete OPES-Processor and OPES-Service headers > > > > > > > > - add OPES-Via header that contains trace entries for > > > > OPES system, OPES processor, and callout services. > > > > > > > > - leave OPES-System header that contains OPES system > > > > identifiers only. These identifiers will be repeated > > > > in OPES-Via. This repetition will establish > > > > boundaries between entries for two OPES systems > > > > (consumer and producer) in a detailed OPES-Via trace. > > > > > > Sounds good to me. > > > > > > -Markus > > > > > > > > > > > -------------------------------------------------------------- > This mail has been inspected by Webwasher - leading technology > for E-mail and Web Security. > > Webwasher - keeping your Web clean! > -------------------------------------------------------------- > From owner-ietf-openproxy@mail.imc.org Thu Nov 20 17:17: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 RAA03106 for ; Thu, 20 Nov 2003 17:17:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMx7p-0005Dd-00 for opes-archive@ietf.org; Thu, 20 Nov 2003 17:18:09 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AMx7o-0005Da-00 for opes-archive@ietf.org; Thu, 20 Nov 2003 17:18:08 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAKLxskT054871 for ; Thu, 20 Nov 2003 13:59:54 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAKLxsSA054870 for ietf-openproxy-bks; Thu, 20 Nov 2003 13:59:54 -0800 (PST) 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.10/8.12.8) with ESMTP id hAKLxqkT054865 for ; Thu, 20 Nov 2003 13:59:52 -0800 (PST) (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 hAKLxsGh040857; Thu, 20 Nov 2003 14:59:54 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hAKLxso2040856; Thu, 20 Nov 2003 14:59:54 -0700 (MST) (envelope-from rousskov) Date: Thu, 20 Nov 2003 14:59:54 -0700 (MST) From: Alex Rousskov To: Martin Stecher cc: OPES WG Subject: Re: HTTP Adaptations issues for f2f discussion In-Reply-To: <002701c3afab$21e7be90$9c30eed9@jadzia> Message-ID: References: <002701c3afab$21e7be90$9c30eed9@jadzia> 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, 20 Nov 2003, Martin Stecher wrote: > > 3. Partial Content > > > > Do we need to say anything special about adapting > > "206 Partial Content" HTTP responses? There are > > two cases here: multipart/byteranges media type and a > > single "part" case. > > I think that this is out of scope because it is a Content-Type > thing. Either an agent should handle these types or should not care, > or it has to try to get a request profile service into the traffic > that removes the support advertisement of partial content from the > HTTP requests. Is this something we need to describe in the draft? I agree that we do not have to provide explicit negotiation at this time (though I disagree that Content-Type is the excuse here; Content-Type is [ab]used for _encoding_ here). I think we must document the issue somewhere to warn implementations that they may see these responses. Finally, I think it is a security consideration! I may be able to bypass OPES filters by constructing a request with two ranges that cover the entire resource being requested. If the server does not merge (I do not think it has to), I will get the entire response while some OPES entities will not be able to handle it. In fact, requesting a resource part by part can probably fool many OPES entities even if we add Content-Type negotiation. We must document this. (Removing Range headers from the request is a solution but is an ugly one because things like PDF viewers will be screwed big time by that -- Squid proxy had a long history of fighting with those issues). > > 5. FTP -> HTTP > > As you said, FTP over HTTP to native FTP transformation > has to be done by the last HTTP proxy server and has > nothing to do with HTTP adaptation of OCP. > The only difference to "normal" HTTP is that the URL starts > with ftp. and that there is not HTTP connection on the server side. We do not care about HTTP connections for now, but some extensions might. But let's not document that, I guess. > Since 3.2.2 of RFC 2616 specifies that a http_URL has to start with > "http:", OCP/HTTP does not apply which is a shame because it works > (if the service supports it). Other protocol prefixes could also be > there; it's not only for FTP. I hope you misinterpret RFC 2616! Request-URI is defined as: URI = "*" | absoluteURI | abs_path | authority and absoluteURI comes from generic RFC 2396 http_URL is just one documented case (do document HTTP access semantics such as default TCP port numbers). IMO, OCP/HTTP applies to any URI scheme as long as message is HTTP-formatted. > Is there somewhere something said how HTTP proxies should handle > URLs that have another protocol prefix than "http:", especially if > they have another next-hop-proxy and do not need to do protocol > conversion? This could probably be copied to our case. Did the above clarifies why no special handling is needed as far as URI scheme is concerned? > > 6. 100 Continue > > > I agree that multipe origin am-ids would solve this issue best > but it seems to be the wrong timing to me to change the concept > now and allow them. So, for now, should we say that 100 Continue MUST NOT be forwarded to callout servers unless their adaptation is negotiated? (and thanks for the ICAP info). > > 7. CONNECT method > > A typical ICAP/1.0 client would generate a REQMOD request for > a CONNECT request but would not try a RESPMOD request > for the response or tunneled data. The latter seems inconsistent. Should we document that both requests and response are subject to adaptation but the tunnel is not? > > 9. Concurrent request and response. > > > This is indeed a problem. Do we have use cases where a response > profile OCP service needs to see the original request body? Filters > I can think of that use the request-body part better belong to > request profile. I do not have such use cases. > ICAP/1.0 does not support request-body encapsulation in RESPMOD, > so there are no existing services for this feature. Right. > Is it a good moment to remove support for this application message > part from request profile? That would be another blow to OCP/HTTP "theoretical" coverage of HTTP protocol, in addition to "100 Continue" non-support. How about documenting this deadlock and requiring that OCP agents are able to handle it like any other resource-limitation issue? Either OPES processor or callout server can terminate the transaction if the request body gets too long. Document this as a security concern as well. > > 10. Huge request bodies and RESPMOD > > > > There is no way for the callout server to > > skip a huge request body when doing RESPMOD. > > Is that acceptable? Should OCP Core support > > "skip N original octets" interface (that > > does not affect offset/size calculations). > > Should HTTP draft support "skip this part > > until its end" interface? Instead? > > Removing request-body part would solve this too ;-) True. Still, I do not want to drop coverage of potentially useful cases just because there are some corner cases that can be abused. Will the above "treat it like any other resource-limitation issue" loophole work? Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Fri Nov 21 03:44: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 DAA05384 for ; Fri, 21 Nov 2003 03:44:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN6uL-0006Hb-00 for opes-archive@ietf.org; Fri, 21 Nov 2003 03:44:53 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AN6uK-0006HR-00 for opes-archive@ietf.org; Fri, 21 Nov 2003 03:44:52 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAL8V5kT026971 for ; Fri, 21 Nov 2003 00:31:05 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAL8V54R026970 for ietf-openproxy-bks; Fri, 21 Nov 2003 00:31:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail2.webwasher.com (host2.webwasher.com [217.146.159.49]) by above.proper.com (8.12.10/8.12.8) with SMTP id hAL8V2kT026908 for ; Fri, 21 Nov 2003 00:31:04 -0800 (PST) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id XZ2L6UVF outgoing id KAKRX8IQ; 21 Nov 2003 11:38:26 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: HTTP Adaptations issues for f2f discussion X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 21 Nov 2003 09:30:51 +0100 Message-ID: <75F7E67FC45F6744A7D328D41E35376D0E6765@mail.webwasher.com> Thread-Topic: HTTP Adaptations issues for f2f discussion Thread-Index: AcOvsaL9eQlokh8IR++RW9oMClNl9AAVpgHQ From: "Martin Stecher" To: "Alex Rousskov" Cc: "OPES WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hAL8V4kT026959 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi Alex, > > I hope you misinterpret RFC 2616! Request-URI is defined as: > URI = "*" | absoluteURI | abs_path | authority > and absoluteURI comes from generic RFC 2396 > > http_URL is just one documented case (do document HTTP access > semantics such as default TCP port numbers). > > IMO, OCP/HTTP applies to any URI scheme as long as message is > HTTP-formatted. Of course, sorry. Although I had this in mind, I found that http_uri paragraph and got confused. Was somehow too late yesterday. > > Did the above clarifies why no special handling is needed as far as > URI scheme is concerned? Yes. > > > > 6. 100 Continue > > > > > I agree that multipe origin am-ids would solve this issue best > > but it seems to be the wrong timing to me to change the concept > > now and allow them. > > So, for now, should we say that 100 Continue MUST NOT be forwarded to > callout servers unless their adaptation is negotiated? (and thanks for > the ICAP info). Seems reasonable. > > > > 7. CONNECT method > > > > A typical ICAP/1.0 client would generate a REQMOD request for > > a CONNECT request but would not try a RESPMOD request > > for the response or tunneled data. > > The latter seems inconsistent. Should we document that both requests > and response are subject to adaptation but the tunnel is not? Yes. > > > > 9. Concurrent request and response. ... > > How about documenting this deadlock and requiring that OCP agents are > able to handle it like any other resource-limitation issue? Either > OPES processor or callout server can terminate the transaction if the > request body gets too long. Document this as a security concern as > well. OK, but let's somehow introduce that paragraph in a way that the reader understands again that most OCP services do not ask for request-body in response profile and that this is therefore not a common problem. > > > > 10. Huge request bodies and RESPMOD > > > > > > There is no way for the callout server to > > > skip a huge request body when doing RESPMOD. > > > Is that acceptable? Should OCP Core support > > > "skip N original octets" interface (that > > > does not affect offset/size calculations). > > > Should HTTP draft support "skip this part > > > until its end" interface? Instead? > > > > Removing request-body part would solve this too ;-) > > True. Still, I do not want to drop coverage of potentially useful > cases just because there are some corner cases that can be abused. > Will the above "treat it like any other resource-limitation issue" > loophole work? Yes. Due to the lack of use cases and limited likelihood that someone will use this feature extensivly, we can probably do without the skip extension here. Martin From owner-ietf-openproxy@mail.imc.org Fri Nov 21 04:13: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 EAA06420 for ; Fri, 21 Nov 2003 04:13:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN7M6-0006i4-00 for opes-archive@ietf.org; Fri, 21 Nov 2003 04:13:34 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AN7M5-0006hz-00 for opes-archive@ietf.org; Fri, 21 Nov 2003 04:13:34 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAL90tkT036609 for ; Fri, 21 Nov 2003 01:00:55 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAL90t1p036607 for ietf-openproxy-bks; Fri, 21 Nov 2003 01:00:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from lifelesslap.robertcollins.net (dsl-89.4.240.220.lns02-kent-syd.dsl.comindico.com.au [220.240.4.89]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAL90qkT036547 for ; Fri, 21 Nov 2003 01:00:53 -0800 (PST) (envelope-from robert.collins@syncretize.net) Received: from localhost ([127.0.0.1] ident=robertc) by lifelesslap.robertcollins.net with esmtp (Exim 3.36 #1 (Debian)) id 1AN79N-0005ax-00; Fri, 21 Nov 2003 20:00:25 +1100 Subject: Re: HTTP Adaptations issues for f2f discussion From: Robert Collins To: Alex Rousskov Cc: Martin Stecher , OPES WG In-Reply-To: References: <002701c3afab$21e7be90$9c30eed9@jadzia> Content-Type: text/plain Message-Id: <1069405211.18254.16.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 21 Nov 2003 20:00:12 +1100 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2003-11-21 at 08:59, Alex Rousskov wrote: > > > > 6. 100 Continue > > > > > I agree that multipe origin am-ids would solve this issue best > > but it seems to be the wrong timing to me to change the concept > > now and allow them. > > So, for now, should we say that 100 Continue MUST NOT be forwarded to > callout servers unless their adaptation is negotiated? (and thanks for > the ICAP info). Huh? This seems orthogonal: the handshaking involved in rfc 2616 uploads is essentially a buffering mechanism, the adaptation device must handle the client and server ends as per HTTP semantics. So far, the callout protocols have no 'send / don't send' concepts in them, so the semantics there are clear. The corollary is that 100 continue must (not MUST) be sent http/1.1 clients without delay, and the adaptation device implement buffering before sending to the http origin / delaying of reads from the client as appropriate for local policy. > > > 7. CONNECT method > > > > A typical ICAP/1.0 client would generate a REQMOD request for > > a CONNECT request but would not try a RESPMOD request > > for the response or tunneled data. > > The latter seems inconsistent. Should we document that both requests > and response are subject to adaptation but the tunnel is not? I agree. Rob -- GPG key available at: . From owner-ietf-openproxy@mail.imc.org Fri Nov 21 11:25:20 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19977 for ; Fri, 21 Nov 2003 11:25:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANE68-0004S2-00 for opes-archive@ietf.org; Fri, 21 Nov 2003 11:25:32 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ANE67-0004Ry-00 for opes-archive@ietf.org; Fri, 21 Nov 2003 11:25:31 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hALFwqkT069611 for ; Fri, 21 Nov 2003 07:58:52 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hALFwqvm069610 for ietf-openproxy-bks; Fri, 21 Nov 2003 07:58:52 -0800 (PST) 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.10/8.12.8) with ESMTP id hALFwpkT069604 for ; Fri, 21 Nov 2003 07:58:51 -0800 (PST) (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 hALFwpGh089652; Fri, 21 Nov 2003 08:58:51 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hALFwpFM089651; Fri, 21 Nov 2003 08:58:51 -0700 (MST) (envelope-from rousskov) Date: Fri, 21 Nov 2003 08:58:51 -0700 (MST) From: Alex Rousskov To: Robert Collins cc: OPES WG Subject: Re: HTTP Adaptations issues for f2f discussion In-Reply-To: <1069405211.18254.16.camel@localhost> Message-ID: References: <002701c3afab$21e7be90$9c30eed9@jadzia> <1069405211.18254.16.camel@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 21 Nov 2003, Robert Collins wrote: > On Fri, 2003-11-21 at 08:59, Alex Rousskov wrote: > > > > > 6. 100 Continue > > > > > > > I agree that multipe origin am-ids would solve this issue best > > > but it seems to be the wrong timing to me to change the concept > > > now and allow them. > > > > So, for now, should we say that 100 Continue MUST NOT be forwarded to > > callout servers unless their adaptation is negotiated? (and thanks for > > the ICAP info). > > Huh? This seems orthogonal: the handshaking involved in rfc 2616 > uploads is essentially a buffering mechanism, the adaptation device > must handle the client and server ends as per HTTP semantics. So > far, the callout protocols have no 'send / don't send' concepts in > them, so the semantics there are clear. The corollary is that 100 > continue must (not MUST) be sent http/1.1 clients without delay, and > the adaptation device implement buffering before sending to the http > origin / delaying of reads from the client as appropriate for local > policy. Robert, I am sorry but I do not understand what you mean. Can you rephrase please? We are trying to decide what to do when the origin server responds with 100 Continue before sending 200 OK; there is no mechanism in current OCP Core to handle multiple original application messages for the same transaction. Are you saying that 100 Continue mechanism is essentially external to HTTP messages being adapted? Like, for example, HTTP connections or TCP ACKs are external to the messages that flow on those connections -- we adapt messages and not the connections or ACKs. If so, the suggested "MUST NOT forward" rule seems appropriate. Or are you saying that 100 Continue messages must be forwarded to the callout server for some reason? Please clarify. Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Fri Nov 21 16:07: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 QAA02881 for ; Fri, 21 Nov 2003 16:07:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANIUm-0000rJ-00 for opes-archive@ietf.org; Fri, 21 Nov 2003 16:07:16 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ANIUl-0000r5-00 for opes-archive@ietf.org; Fri, 21 Nov 2003 16:07:15 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hALKf1kT083638 for ; Fri, 21 Nov 2003 12:41:01 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hALKf11q083637 for ietf-openproxy-bks; Fri, 21 Nov 2003 12:41:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from lifelesslap.robertcollins.net (dsl-89.4.240.220.lns02-kent-syd.dsl.comindico.com.au [220.240.4.89]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hALKewkT083624 for ; Fri, 21 Nov 2003 12:40:59 -0800 (PST) (envelope-from robert.collins@syncretize.net) Received: from localhost ([127.0.0.1] ident=robertc) by lifelesslap.robertcollins.net with esmtp (Exim 3.36 #1 (Debian)) id 1ANI5I-0007zj-00; Sat, 22 Nov 2003 07:40:56 +1100 Subject: Re: HTTP Adaptations issues for f2f discussion From: Robert Collins To: Alex Rousskov Cc: OPES WG In-Reply-To: References: <002701c3afab$21e7be90$9c30eed9@jadzia> <1069405211.18254.16.camel@localhost> Content-Type: text/plain Message-Id: <1069447256.18254.113.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sat, 22 Nov 2003 07:40:56 +1100 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sat, 2003-11-22 at 02:58, Alex Rousskov wrote: > On Fri, 21 Nov 2003, Robert Collins wrote: > > > On Fri, 2003-11-21 at 08:59, Alex Rousskov wrote: > > > > Huh? This seems orthogonal: the handshaking involved in rfc 2616 > > uploads is essentially a buffering mechanism, the adaptation device > > must handle the client and server ends as per HTTP semantics. So > > far, the callout protocols have no 'send / don't send' concepts in > > them, so the semantics there are clear. The corollary is that 100 > > continue must (not MUST) be sent http/1.1 clients without delay, and > > the adaptation device implement buffering before sending to the http > > origin / delaying of reads from the client as appropriate for local > > policy. > > Robert, > > I am sorry but I do not understand what you mean. Can you > rephrase please? We are trying to decide what to do when the origin > server responds with 100 Continue before sending 200 OK; there is no > mechanism in current OCP Core to handle multiple original application > messages for the same transaction. Yep. > Are you saying that 100 Continue mechanism is essentially > external to HTTP messages being adapted? Like, for example, HTTP > connections or TCP ACKs are external to the messages that flow on > those connections -- we adapt messages and not the connections or > ACKs. If so, the suggested "MUST NOT forward" rule seems appropriate. I guess I'm saying that things emerge from the OCP protocol and the http protocol. Documenting them would make sense :}. 1) Information status messages MUST be dealt with in the HTTP guidelines. That means that outside of the OCP environment, protocol behaviour must be enforced by the adaptation client in whatever degree of cooperation with OCP we design... That includes 100 continue, and 101 upgrade likewise, and ANY 1XX interim response. (RFC 2616 10.1 - all 1xx status codes MUST be delivered to the client UNLESS a proxy initiated the request for that particular 1xx response.) 2) 100 is a special case of these, where the semantics of uploads and resource management requirements on a http-proxy-like device ensure there will be some mechanism that can be exploited to implement the 100 semantics (From an external perspective) 3) 101 upgrade has ocp issues if the response circumvents OCP - as a) the client will know they have switched b) the OCP infrastructure won't [know they have switched]. c) respmod logic may not even be able to handle the upgraded protocol - i.e. what if it's a rtsp stream? or a TLS encoded session? (And as more servers support Upgrade to TLS, port 80 adaptation could be circumvented quite easily (*)) 4) all of the above are no more than special case ramifications of ANY Http reverse proxy scenario : they are not unique to the adaption environment, yet they will impact it heavily. > Or are you saying that 100 Continue messages must be forwarded > to the callout server for some reason? Well I'm not sure.. thats the crux of it. If you don't give OCP visibilty to 1XX series messages, then OCP cannot (for instance) handle any messages that goes through a protocol upgrade. Likewise, we place extra buffering overhead on the adaptation client when it must treat the OCP subsystem as (for all intents and purposes) an HTTP/1.0 client. Conversely, if you expose the 100 and 101 messages (And any extensions that involve 1XX messages - remember they MAY arrive unexpectedly), then you may as well use http for OCP as you've just stuffed the remainder of the protocol in there. We've got an issue in squid, where I'm currently designing 100 series message support, that relates to this, getting all 100 series messages via the internal pipeline requires significant changes, to have a multiple-response per transaction concept. 100-Continue is easy by comparison, as it's literally no more than removing a status flag to allow the clients req buffer to flow upwards - and issue a notification to the client to effect the same. (*) Which comes back to the trust issues discussed already, and the issue of who is authoritative for the delivered content: if the adapting device is authoritative, it should implement appropiate policy and request transformations to ensure that upgrades to tls happen at it's client facing side, not at the origins - which means it MUST have an appropriate TLS certificate etc etc etc. Rob -- GPG key available at: . From owner-ietf-openproxy@mail.imc.org Fri Nov 21 16:34:44 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03866 for ; Fri, 21 Nov 2003 16:34:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANIvX-0001Ey-00 for opes-archive@ietf.org; Fri, 21 Nov 2003 16:34:55 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ANIvX-0001Ev-00 for opes-archive@ietf.org; Fri, 21 Nov 2003 16:34:55 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hALLFQkT085509 for ; Fri, 21 Nov 2003 13:15:26 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hALLFQsL085508 for ietf-openproxy-bks; Fri, 21 Nov 2003 13:15:26 -0800 (PST) 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.10/8.12.8) with ESMTP id hALLFPkT085503 for ; Fri, 21 Nov 2003 13:15:25 -0800 (PST) (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 hALLFQGh003272; Fri, 21 Nov 2003 14:15:26 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hALLFQV7003271; Fri, 21 Nov 2003 14:15:26 -0700 (MST) (envelope-from rousskov) Date: Fri, 21 Nov 2003 14:15:26 -0700 (MST) From: Alex Rousskov To: Robert Collins cc: OPES WG Subject: Re: HTTP Adaptations issues for f2f discussion In-Reply-To: <1069447256.18254.113.camel@localhost> Message-ID: References: <002701c3afab$21e7be90$9c30eed9@jadzia> <1069405211.18254.16.camel@localhost> <1069447256.18254.113.camel@localhost> 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: Robert, Thanks for the clarification! Your thoughts make it more clear that the scoping issue (already marked as unresolved!) plays a crucial role here: HTTP/OCP agents are not HTTP agents. They are not adapting HTTP protocol as a whole. They are adapting isolated HTTP messages only. They are not adapting HTTP connections, they are not adapting 1xx mechanism, they are not adapting HTTP cache, they are not adapting TCP flow underneath HTTP connections, etc. HTTP/OCP scope is an atomic HTTP message. Other OCP Core extensions can be written to adapt other things if needed. Furthermore, we acknowledge that HTTP introduces relationship between HTTP messages. HTTP/OCP handles one kind of such relationship: a given HTTP response being adopted is related to a single HTTP request. This relationship is handled via optional original parts, a negotiated HTTP profile feature. The fact that _multiple_ HTTP responses may be related to a single HTTP request when 1xx responses are present is acknowledged, but is out of the draft scope. In other words, HTTP/OCP does not have a mechanism to relate multiple HTTP responses to a single request as a part of a single OCP transaction. It is possible to express that relationship via OCP Core extensions, but the HTTP/OCP specification does not do that. Consequently, callout server (OCP server) MUST be able to handle all HTTP responses, including 1xx responses. OPES processor (OCP client) MAY NOT forward 1xx responses to a callout server. If OPES processor forwards 1xx responses to a callout server, and negotiated profile requires forwarding of request parts, then OPES processor MUST forward those request parts. Informally, this means that callout servers may receive identical request parts multiple times: each time the processor forwards a 1xx response and one time the processor forwards the final response. Similarly, HTTP upgrade and other HTTP mechanisms are out of HTTP/OCP scope. The OPES processor MAY forward HTTP message to the callout server. Informally, this implies that the processor may forward only a subset of messages. HTTP semantics related to messages such as Continue or Upgrade is beyond HTTP/OCP specification scope. Do you see what I am getting at? Will the above scoping rules work well enough? Alex. P.S. The idea may become more clear if you consider adapting protocols with a large number of control messages/dialogs. For example, the same scoping rules above are meant to apply well to SMTP. > On Sat, 2003-11-22 at 02:58, Alex Rousskov wrote: > > On Fri, 21 Nov 2003, Robert Collins wrote: > > > > > On Fri, 2003-11-21 at 08:59, Alex Rousskov wrote: > > > > > > Huh? This seems orthogonal: the handshaking involved in rfc 2616 > > > uploads is essentially a buffering mechanism, the adaptation device > > > must handle the client and server ends as per HTTP semantics. So > > > far, the callout protocols have no 'send / don't send' concepts in > > > them, so the semantics there are clear. The corollary is that 100 > > > continue must (not MUST) be sent http/1.1 clients without delay, and > > > the adaptation device implement buffering before sending to the http > > > origin / delaying of reads from the client as appropriate for local > > > policy. > > > > Robert, > > > > I am sorry but I do not understand what you mean. Can you > > rephrase please? We are trying to decide what to do when the origin > > server responds with 100 Continue before sending 200 OK; there is no > > mechanism in current OCP Core to handle multiple original application > > messages for the same transaction. > > Yep. > > > Are you saying that 100 Continue mechanism is essentially > > external to HTTP messages being adapted? Like, for example, HTTP > > connections or TCP ACKs are external to the messages that flow on > > those connections -- we adapt messages and not the connections or > > ACKs. If so, the suggested "MUST NOT forward" rule seems appropriate. > > I guess I'm saying that things emerge from the OCP protocol and the http > protocol. Documenting them would make sense :}. > > 1) Information status messages MUST be dealt with in the HTTP > guidelines. That means that outside of the OCP environment, protocol > behaviour must be enforced by the adaptation client in whatever degree > of cooperation with OCP we design... That includes 100 continue, and 101 > upgrade likewise, and ANY 1XX interim response. (RFC 2616 10.1 - all 1xx > status codes MUST be delivered to the client UNLESS a proxy initiated > the request for that particular 1xx response.) > 2) 100 is a special case of these, where the semantics of uploads and > resource management requirements on a http-proxy-like device ensure > there will be some mechanism that can be exploited to implement the 100 > semantics (From an external perspective) > 3) 101 upgrade has ocp issues if the response circumvents OCP - as > a) the client will know they have switched > b) the OCP infrastructure won't [know they have switched]. > c) respmod logic may not even be able to handle the upgraded protocol - > i.e. what if it's a rtsp stream? or a TLS encoded session? (And as more > servers support Upgrade to TLS, port 80 adaptation could be circumvented > quite easily (*)) > 4) all of the above are no more than special case ramifications of ANY > Http reverse proxy scenario : they are not unique to the adaption > environment, yet they will impact it heavily. > > > Or are you saying that 100 Continue messages must be forwarded > > to the callout server for some reason? > > Well I'm not sure.. thats the crux of it. > > If you don't give OCP visibilty to 1XX series messages, then OCP cannot > (for instance) handle any messages that goes through a protocol upgrade. > Likewise, we place extra buffering overhead on the adaptation client > when it must treat the OCP subsystem as (for all intents and purposes) > an HTTP/1.0 client. > > Conversely, if you expose the 100 and 101 messages (And any extensions > that involve 1XX messages - remember they MAY arrive unexpectedly), then > you may as well use http for OCP as you've just stuffed the remainder of > the protocol in there. > > We've got an issue in squid, where I'm currently designing 100 series > message support, that relates to this, getting all 100 series messages > via the internal pipeline requires significant changes, to have a > multiple-response per transaction concept. 100-Continue is easy by > comparison, as it's literally no more than removing a status flag to > allow the clients req buffer to flow upwards - and issue a notification > to the client to effect the same. > > (*) Which comes back to the trust issues discussed already, and the > issue of who is authoritative for the delivered content: if the adapting > device is authoritative, it should implement appropiate policy and > request transformations to ensure that upgrades to tls happen at it's > client facing side, not at the origins - which means it MUST have an > appropriate TLS certificate etc etc etc. > > Rob > > -- > GPG key available at: . > > From owner-ietf-openproxy@mail.imc.org Wed Nov 26 03:02: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 DAA26722 for ; Wed, 26 Nov 2003 03:02:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOudB-0001Ag-00 for opes-archive@ietf.org; Wed, 26 Nov 2003 03:02:37 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AOudA-0001Ac-00 for opes-archive@ietf.org; Wed, 26 Nov 2003 03:02:36 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQ7ghib063239 for ; Tue, 25 Nov 2003 23:42:43 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQ7ghkN063238 for ietf-openproxy-bks; Tue, 25 Nov 2003 23:42:43 -0800 (PST) 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.10/8.12.8) with ESMTP id hAQ7gdib063199 for ; Tue, 25 Nov 2003 23:42:39 -0800 (PST) (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 hAQ7gbGh035962; Wed, 26 Nov 2003 00:42:37 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hAQ7gaqY035961; Wed, 26 Nov 2003 00:42:36 -0700 (MST) (envelope-from rousskov) Date: Wed, 26 Nov 2003 00:42:36 -0700 (MST) From: Alex Rousskov To: Markus Hofmann cc: OPES Group Subject: Re: WG Last Call: draft-ietf-opes-ocp-core-03.txt In-Reply-To: <3FBBE243.4050106@mhof.com> Message-ID: References: <3FBBE243.4050106@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 19 Nov 2003, Markus Hofmann wrote: > We are starting WG last call on the "OPES Callout Protocol Core" > draft (see attached). The last call period closes on Wednesday, > November 26 at 5pm EST. Please post any comments, etc. to the > mailing list, and please point out whether you feel your comment is > editorial or a show-stopper. Below are my show-stopping comments for OCP Core. These are based on the "Open Issues" list I posted earlier. That list, containing some discussion about possible alternatives, is quoted at the end of this message. The list is _not_ a part of the last call feedback. S1. Explicitly document that OCP Core does not require OCP connection encryption and does not document encryption negotiation. Refer to OCP extensions as places where encryption and authentication may be documented. Do not name specific OCP extension drafts since they do not exist yet, and since we do not want to end up waiting for their maturity to move Core to proposed standard status. S2a. Drop application message identifiers from OCP Core. They are not used by HTTP Adaptation draft; thus adapted am-ids are application-specific. The Core already [correctly] says that there can be only one original application message that is being adapted in a given OCP transaction; thus, original am-id is useless. S2b. Replace xid atom with {xid} structure to allow for seamless addition of adapted am-ids in OCP application bindings such as SMTP/OCP. S3. Similar to S2b, group related anonymous parameters into structures. Specifically, (offset, size) pairs and offset atoms must be grouped into corresponding structures. This may simplify OCP extensions that use additional ways of addressing [original] content (e.g., AM-Part-based addressing). S4. Fix Protocol Element Type Declaration Mnemonic to allow for extending message semantics without changing message names. HTTP Adaptation draft already needs that, not to mention that it is a PETDM design flaw. N.B. I also have a rather long list of minor editorial changes. Since I am the draft editor, I would prefer to type those in directly and post a diff for those who care. Doing so will save me a lot of time on describing those editorial comments in prose before applying them. If you have any objections, please let me know ASAP; I hope to finish editorial comments by the last call deadline at 17:00 EST. Thank you, Alex. On Thu, 6 Nov 2003, Alex Rousskov wrote: > Hi, > > Here are some OCP Core issues that may be worth discussing at > the upcoming F2F meeting. Since I will not be at the meeting, I > provided my current opinions on every issue. Please do not treat this > list as a formal request to add all of the items below to the agenda. > These are just suggestions. Meeting participants should decide among > themselves what, if anything, here is worth discussing in Minneapolis. > > 1. Agent authentication negotiation. Should it be > documented in the Core? Should it be required? > > My current opinion is that there should be > a separate OCP Security draft because there > are several standard ways to do authentication > and at least two can be covered. Also, in-band > authentication should not be optional which > makes documenting such a big and independent > feature in Core inappropriate. > > My second choice for placing this stuff > would be a Core Appendix. However, I expect such > Appendix introduce IANA considerations (registered > URIs and such), and that is awkward to do in the > Appendix. Also, it will delay last call for the Core. > > > 2. OCP connection encryption negotiation. Should it be > documented in the Core? Should it be required? > > My current opinion is the same as in #1, for same > reasons. Note that it is common to have security > covered in a separate draft(s). HTTP does that, > for example (RFC 2616, 2617). > > > 3. Should OCP Core contain a full adaptation example? > It would have to be application-specific. > > IMO, OCP Core can refer to a full adaptation example > in an adaptation draft such as HTTP Adaptation. > > > 4. Should we solicit IETF SIRs review before going > into last call? > > I would rely on chairs' opinion here. > > > 5. OCP Core spends a lot of ink documenting application > message identifiers (am-ids) in various contexts. There > are original and adapted am-ids. HTTP does not use any > am-ids, essentially. We do not know of any protocol > that would need original am-id, but we still keep it > so that processor and server sides are symmetric. > > The only reason to have adapted am-ids is to support > SMTP and other protocols that may have multiple adapted > dataflows for a single original dataflow. Yet, we have > no experience whether Core has enough stuff to accomodate > SMTP and similar needs. Should we yank am-ids from > the core and rely on OCP extension mechanisms if/when > we start supporting SMTP? > > To make future extensions easier, we can replace current > "xid am-id" pair of anonymous parameters with a single > anonymous {xid} structure so that new members (e.g., am-id) > can be added to the structure without changing the overall > look and feel of any am-related message. > > IMO, it may be a good idea to get rid of am-ids in Core, > but I am not sure at all and would like to hear others' > comments. > > 5a. Should we stuff all related anonymous parameters into > structures? For example, "offset size" can become > {offset size}. Again, the rationale would be to > simplify extensions of those parameters (e.g., adding > AM-Part to the structure) and to simplify extending > the anonymous parameter list in case one or more > existing parameters are optional. > > IMO, if we do the changes suggested in #5, we should > do similar changes throughout the protocol. > > 6. Recent changes to the Core moved data preservation > maintenance out of Data Use Mine/Yours commands. > The rationale was that Data Use Mine/Yours commands > are specific to a single adapted dataflow while > data preservation maintenance applies to the > original flow and, hence, to _all_ adapted flows. > We should not confuse implementors with two different > scopes within a single message. > > For example, callout server's preservation interest > is now expressed in a Data Preservation Interest > (DPI) message that refers to original dataflow only: > DPI: extends message with { > xid org-am-id org-offset org-size; > }; > This used to be a part of the Data Use Mine/Yours > message (Wont-Use and similar parameters). > > The problem with this approach is a loss of simple > optimization opportunities. Before, a Data Use Yours > message with a Wont-Use parameter would allow the > processor (recipient) to send the data out and > free the data as it sends. Now, the processor has two > choices: (a) send the specified data out and > wait for a DPI message to free the data later; > and (b) look ahead in hope to find a DPI message > right after the DUY message and free as it sends > if a DPI message follows. > > The difference between freeing eventually and > while-you-send may be important. Depending on > an implementation, gradual freeing might mean 50% > more buffer space available (on average) to > share among data streams. Look-ahead optimization > sounds rather complex and error-prone to me. > > Question: what is more important here: the clarity > of the protocol (the current spec is more clear) or > the free-as-you-send optimization (the old spec > allowed for that). > > Moreover, in the old spec, the preserved data could be > freed by default when a Data Use Yours message is received. > Thus, there were fewer chances that a callout server will > "forget" to tell the processor that some data should be > freed. > > Finally, if we go through with #5 changes, then > the whole rationale for factoring out data preservation > and similar information out of adapted dataflows becomes > less convincing because there is only one adapted > dataflow from Core point of view. On the other hand, > if we go back to the original scheme, SMTP and other > similar extensions would suffer from clarity point > of view (the rationale would still be valid for them!). > > IMO, we should keep the current scheme, but I am not > sure at all and would like to hear other opinions. > > > 7. Protocol Element Type Declaration Mnemonic (PETDM) > documented in Section 8 does not allow extending > message semantics without renaming the message because > the message name is the type name, and to extend > semantics one must change the type. For example, > an OCP extension cannot add a new parameter to > the message without renaming it. > > IMO, this is wrong and must be fixed by somehow > isolating message guts from message name. It should > be possible to extend message.guts without renaming > the message. > > > 8. Is Appendix A "Message Summary" needed? > > IMO, we should keep it and add section references > if the plain text rendering can fit them. > > > 9. Should we add an index (words linked to sections > where they are defined or talked about)? > > I do not have a strong opinion here. We could. > > > I will post again if I can think of something else. > > HTH, > > Alex. > From owner-ietf-openproxy@mail.imc.org Wed Nov 26 11:10:34 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14641 for ; Wed, 26 Nov 2003 11:10:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP2Fb-0000Oq-00 for opes-archive@ietf.org; Wed, 26 Nov 2003 11:10:47 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AP2Fb-0000On-00 for opes-archive@ietf.org; Wed, 26 Nov 2003 11:10:47 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFxFib029063 for ; Wed, 26 Nov 2003 07:59:15 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQFxFRB029062 for ietf-openproxy-bks; Wed, 26 Nov 2003 07:59:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQFxEib029007 for ; Wed, 26 Nov 2003 07:59:14 -0800 (PST) (envelope-from markus@mhof.com) Received: from mhof.com (unknown[135.104.20.65]) by comcast.net (sccrmhc11) with ESMTP id <2003112615590901100mv3ude> (Authid: mhofmann); Wed, 26 Nov 2003 15:59:09 +0000 Message-ID: <3FC4CDCF.7000902@mhof.com> Date: Wed, 26 Nov 2003 10:59:11 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031110 Thunderbird/0.4a X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: WG Last Call: draft-ietf-opes-ocp-core-03.txt References: <3FBBE243.4050106@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: > S2a. Drop application message identifiers from > OCP Core. They are not used by HTTP Adaptation > draft; thus adapted am-ids are application-specific. > The Core already [correctly] says that > there can be only one original application message > that is being adapted in a given OCP transaction; > thus, original am-id is useless. What about multiple am-ids for the responses coming back from the callout server (possibly required for SMTP)? Will this still be documented in OCP core or moved out to application-specific bindings? > S2b. Replace xid atom with {xid} structure to allow > for seamless addition of adapted am-ids in OCP > application bindings such as SMTP/OCP. OK, I believe that answers my question above... OCP core will *not* document am-ids, but define a structure that allows application-specific bindings to include such am-ids for responses, right? > N.B. I also have a rather long list of minor editorial changes. Since > I am the draft editor, I would prefer to type those in directly and > post a diff for those who care. That's fine. > Doing so will save me a lot of time on > describing those editorial comments in prose before applying them. If > you have any objections, please let me know ASAP; I hope to finish > editorial comments by the last call deadline at 17:00 EST. Alex, when will you be able to address your show-stopping comments in thedraft? If no one objects to your comments/suggestions in your earlier email, please go ahead and merge them into the draft. We'll then issue (the hopefully final) WGLC on this draft. If someone has objections to what Alex outlined, please raise your concrn NOW! Thanks, Markus From owner-ietf-openproxy@mail.imc.org Wed Nov 26 12:14:30 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17807 for ; Wed, 26 Nov 2003 12:14:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP3FT-0001Sz-00 for opes-archive@ietf.org; Wed, 26 Nov 2003 12:14:43 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AP3FT-0001Sp-00 for opes-archive@ietf.org; Wed, 26 Nov 2003 12:14:43 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQH3rib032173 for ; Wed, 26 Nov 2003 09:03:53 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQH3rOp032172 for ietf-openproxy-bks; Wed, 26 Nov 2003 09:03:53 -0800 (PST) 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.10/8.12.8) with ESMTP id hAQH3pib032166 for ; Wed, 26 Nov 2003 09:03:52 -0800 (PST) (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 hAQH3rGh054363; Wed, 26 Nov 2003 10:03:53 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hAQH3r35054362; Wed, 26 Nov 2003 10:03:53 -0700 (MST) (envelope-from rousskov) Date: Wed, 26 Nov 2003 10:03:52 -0700 (MST) From: Alex Rousskov To: Markus Hofmann cc: OPES Group Subject: Re: WG Last Call: draft-ietf-opes-ocp-core-03.txt In-Reply-To: <3FC4CDCF.7000902@mhof.com> Message-ID: References: <3FBBE243.4050106@mhof.com> <3FC4CDCF.7000902@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 26 Nov 2003, Markus Hofmann wrote: > Alex Rousskov wrote: > > > S2a. Drop application message identifiers from > > OCP Core. They are not used by HTTP Adaptation > > draft; thus adapted am-ids are application-specific. > > The Core already [correctly] says that > > there can be only one original application message > > that is being adapted in a given OCP transaction; > > thus, original am-id is useless. > > What about multiple am-ids for the responses coming back from the > callout server (possibly required for SMTP)? Will this still be > documented in OCP core or moved out to application-specific > bindings? The possibility of multiple responses will remain documented. The exact mechanism (am-ids) will not be. > > S2b. Replace xid atom with {xid} structure to allow > > for seamless addition of adapted am-ids in OCP > > application bindings such as SMTP/OCP. > > OK, I believe that answers my question above... OCP core will *not* > document am-ids, but define a structure that allows > application-specific bindings to include such am-ids for responses, right? Exactly. > Alex, when will you be able to address your show-stopping comments in > thedraft? If no one objects to your comments/suggestions in your > earlier email, please go ahead and merge them into the draft. We'll > then issue (the hopefully final) WGLC on this draft. Given impending holidays in the US, I am uncertain about my availability for the next 4 days. I will do my best to apply everything by Tuesday morning, hopefully sooner. Alex. From owner-ietf-openproxy@mail.imc.org Wed Nov 26 17:02: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 RAA29970 for ; Wed, 26 Nov 2003 17:02:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP7kL-0005Xp-00 for opes-archive@ietf.org; Wed, 26 Nov 2003 17:02:53 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AP7kK-0005Xm-00 for opes-archive@ietf.org; Wed, 26 Nov 2003 17:02:52 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQLo1ib045835 for ; Wed, 26 Nov 2003 13:50:01 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQLo0oN045834 for ietf-openproxy-bks; Wed, 26 Nov 2003 13:50:00 -0800 (PST) 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.10/8.12.8) with ESMTP id hAQLnxib045825 for ; Wed, 26 Nov 2003 13:49:59 -0800 (PST) (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 hAQLo1Gh066924; Wed, 26 Nov 2003 14:50:01 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hAQLo11C066923; Wed, 26 Nov 2003 14:50:01 -0700 (MST) (envelope-from rousskov) Date: Wed, 26 Nov 2003 14:50:01 -0700 (MST) From: Alex Rousskov To: Markus Hofmann cc: OPES Group Subject: Re: WG Last Call: draft-ietf-opes-ocp-core-03.txt In-Reply-To: <3FC4E0EB.4050701@mhof.com> Message-ID: References: <3FBBE243.4050106@mhof.com> <3FC4CDCF.7000902@mhof.com> <3FC4E0EB.4050701@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: Hi, One more issue has just cropped up while I was applying editorial changes. It probably has status above "editorial": S5. Remove overlap between DIY and DWOL semantics. Resolve 206 response status code ambiguity by adding a "you can stop sending data now" message. OCP Core defines Ignoring Your Data (DIY) and Want Out of the Data Loop (DWOL) messages. Both are sent by the callout server to indicate disinterest in original data (DIY and DWOL) and to indicate desire to quit sending adapted data (DWOL only). The processor can stop sending original data by responding with Application Message End (AME) message with 206 (partial) status code. In case of DIY, a 206 response means that there will be no more original data. In case of DWOL, the same response means that there will be no more original data _and_ that the server may get out of the loop. The above description clearly shows the overlap in DIY and DWOL semantics; both messages mean, in part, "I do not care about original data". This creates problems because the two messages cannot be combined on the same transaction (that would make 206 response ambiguous). If they are combined, it is not clear what the processor has to do (short to bailing with an error). The solution is to remove "I do not care about original data" from the DWOL logic. We need two separate messages: "I do not care about original data" (current DIY) and "I would rather not send you original data". Combined, the two can implement current DWOL logic, but they are useful in isolation as well. Finally, a "you can stop sending data now" message should be added so that the processor can inform the callout server that the server can quit and processor would not mind. This will remove overloading of the 206 status code we have now. This is not a big change, but it probably goes beyond editorial status so I wanted to post it before the deadline in case there are any objections or improvement suggestions. Thank you, Alex, 10 minutes before the last call cut-off deadline!