From owner-ietf-openproxy@mail.imc.org Wed Oct 1 12:55:19 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23335 for ; Wed, 1 Oct 2003 12:55:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4kG6-00028F-00 for opes-archive@ietf.org; Wed, 01 Oct 2003 12:55:26 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A4kG5-00028B-00 for opes-archive@ietf.org; Wed, 01 Oct 2003 12:55:25 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91GbfKP091083 for ; Wed, 1 Oct 2003 09:37:41 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h91GbffG091082 for ietf-openproxy-bks; Wed, 1 Oct 2003 09:37:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91GbdKP091077 for ; Wed, 1 Oct 2003 09:37:39 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h91GbeGh037501 for ; Wed, 1 Oct 2003 10:37:40 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h91GbUWI037500; Wed, 1 Oct 2003 10:37:30 -0600 (MDT) (envelope-from rousskov) Date: Wed, 1 Oct 2003 10:37:30 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: feedback on draft-ietf-opes-end-comm-02 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: Abbie, Here is my comments on the latest Communication draft, draft-ietf-opes-end-comm-02. The overall structure and flow of the document improved significantly. Thank you! There are several major flaws and few minor bugs remaining. In this email, I will try to concentrate on major flaws: * Compliance subjects: The number of things for which there is at least one MUST/SHOULD/MAY requirement, is too large. Sometimes it is even not clear what subject a requirement applies to. Please make sure that all requirements apply to an OPES entity, an OPES system, or a application binding specification. If you feel that other compliance subjects are needed, let's discuss this. Please add a "Compliance Considerations" section. * Misplaced compliance requirements: Please avoid sprinkling informative text and definitions(!) with MUST/SHOULD/MAYs. Let's try to move all requirements for OPES entities to the corresponding sections of the draft. * Multiple definitions: Several concepts have multiple definitions. There must be one definition, optionally followed by examples and rationale. * Vague requirements: Please check that every MUST/SHOULD/MAY uses no undefined or unnecessary adjectives. If a particular requirement cannot be formulated without a vague adjective, perhaps it should not be a requirement. This may seem like a lot of work but (a) it is an important spec quality aspect and (b) you are likely to end up with fewer requirements after the above flaws are addressed. * Vague definitions: same as vague requirements but as applied to definitions. Avoid adjectives and implied clauses in a definition. * Implied definitions: "Foo is Bar" is a definition. "Foo can be Bar", "Foo describes Bar", etc. are not. MUST/SHOULD/MAY keywords identify requirements. You may want to use "Definition:" prefix to identify definitions. If you do not like the prefix, please make sure that all definition-looking sentences are either clearly marked as definitions or rephrased to avoid misleading looks. * Bypass: the draft does not mention bypass mechanisms but should. Below, I will point to specific places exhibiting the above flaws. Your original text is quoted using "> ". I will use flaw headings from the above list to shorten notes when possible. > This memo documents tracing requirements for Open Pluggable Edge > Services (OPES). Bypass. > The execution of such services is governed by a set of rules > installed on the OPES processor. ... The above paragraph seem to have very little to do with tracing. Do we need to repeat architecture description here? > The work specify the requirements for providing tracing functionality > for the OPES architecture [8]. This document specifies tracing > mechanisms that the OPES architecture could provide that enable data > provider application to detect inappropriate client centric actions > by OPES entities. So which is it? "Requirements for providing tracing functionality" or "tracing mechanisms"? > This document specifies tracing > mechanisms that the OPES architecture could provide that enable data > provider application to detect inappropriate client centric actions > by OPES entities. What about inappropriate server-centric actions? Are tracing mechanisms symmetric? > This work investigates this possibility and discusses possible > methods that could be used to detect faulty OPES processors or > callout servers by end points in an OPES flow. Let's be more firm/specific: "This document specifies ... for ..." Avoid "possibilities", "investigations", and "coulds". > The document is organized as follows: Section 2 defines OPES Domain > ... Delete the above paragraph. It is an [incorrect] repetition of the table of contents. This is not a research paper without a TOC where such paragraphs are common and useful. > This sections clarifies the terms OPES system and OPES Domain [8]. [8], the Architecture draft you are referring to does not define OPES system and OPES Domain. Are you implying that the Architecture draft should be fixed to include such definitions? If yes, please place an XXX note so that we do not forget to change the Architecture draft and remove system/domain definitions from Communications draft when the Architecture draft is updated. If you are not implying anything, then please remove the above reference to [8]. > An OPES domain describes the collection of OPES entities that a > single provider operates. Implied definition? An OPES domain is ... I failed to find much text that actually uses OPES Domain. I can only see two requirements (and I do not understand their rationale). If those requirements are gone, I would suggest removing OPES Domain until is needed. (OPES Domain is different from OPES trust domain, right?). > An OPES domain describes the collection of OPES entities that a > single provider operates. Please give an example. It is not clear what "single provider operates" means because it is not clear what is a "provider" in this context and what it means to "operate" an OPES entity. > OPES domains can be based on trust or other operational boundaries. Is "trust" an operational boundary? What is an "operational boundary"? > All entities of an "OPES Domain" MUST be in the same trust domain. Compliance subjects. Does not your OPES Domain definition above imply the "same trust domain" clause? > An OPES system consists of a limited set of OPES entities, parts of a > single or of multiple OPES domains, organized by (or on behalf) of > either a data provider application or a data consumer application to > perform authorized services on a given application message. Vague definition. > An OPES system can be formed in a recursive manner. An OPES system > can start ... Implied definition? Multiple definitions for OPES system? > Each OPES entity in an OPES system MUST be directly addressable at > the IP level by a data consumer application. Misplaced compliance requirement. Also, is this requirement really in Communications draft scope? > An OPES domain MUST not be an OPES sub-system. Compliance subject. Also, what is an OPES sub-system? A subset of OPES entities within an OPES System? If yes, then does not Figure 1 show OPES domains that are OPES sub-systems? > An OPES domain MUST > require external resources to provide services. Compliance subject. Or is it a part of an implied definition? > A data consumer > application MUST be able to receive tracing information on per > message basis Compliance subject. > Tracing is defined as the inclusion of > necessary information within a message in an OPES flow that could be and > o OPES tracing: the process of including, manipulating, and > interpreting an OPES trace in an OPES System. Multiple definitions. > To emphasize, the above definition means that OPES tracing SHOULD be > performed on per message basis. Compliance subject. > In an OPES System the task of providing tracing information, must > take into account the following considerations: Assuming the above "must" is a "MUST", this is a Compliance subject flaw. The subject of the above must is the "task of providing tracing information"! > Tracing information MUST be able to provide a data consumer > application with useful information without tracing the exact OPES > Processor or callout servers that adapted the data. Compliance subject. Vague requirement. > o An OPES service SHOULD add its entry to the trace. I believe this should be a MAY. Rationale: Many OPES services are message-agnostic and operate on message content or parts. Such services cannot manipulate message headers and, hence, cannot trace themselves. Since an ideal OPES service is usually message-agnostic, it seems inappropriate to place a SHOULD-level requirement that an ideal implementation would necessarily violate. > For example, an OPES processor may add or > remove callout service entries in order to manage the size of a > trace. Consider making this a separate paragraph, with an appropriate intro phrase. Let's not clobber the requirements list. > trace. Other considerations include: Is this still a part of a "For example" clause? > * The OPES processor MAY have a fixed configuration that enable > it to respond to tracing inquires. Unclear. Needs more details/examples? Is this (and others in the same list) an example or a MAY-level requirement? They look like examples to me. "A proxy MAY cache" is a requirement. "A proxy can keep its cache in RAM" is an example or similar informative text. In our scope, if something does not effect traffic on the wire, it is most likely NOT a requirement. > From an OPES context, a good tracing approach is similar to a trouble > ticket ready for submission to a known address. The trouble ticket analogy is good. Please rephrase so that it is clear that the "known address" is _included_ in (a part of) the "ticket" in our case. > 3.2 Requirements for Information Related to Traceable Entities? Is question mark at the end intentional? Compliance subject. > The requirements for information as related to entities that are > traceable in an OPES flow are: Compliance subject. What level (MUST/SHOULD/MAY) are these requirements. > the concept of an "OPES system" > being traceable, requires that each OPES processor MUST support > tracing. The concept most certainly does not require that. > An OPES provider can have its private policy for trace information, > but it MUST support tracing mechanisms and it MUST reveal its > policy. Compliance subject. > o Each OPES processor MUST belong to a single OPES Domain. > o Each OPES processor MUST have a Unique Identity in that Domain. Why? > In an OPES system, it is the task of an OPES processor to add trace > records to application messages. In this case, the callout servers > that uses the OCP protocol [5] are not affected by tracing > requirements. And yet, we say that callout servers SHOULD add trace records. > In order for an OCP protocol to be tracing neutral, an OPES > processor in an OPES system MUST be able to meet the following > requirements: Why is Communication draft concerned with OCP protocol neutrality? > o Callout services adapt payload regardless of the application > protocol in use and leave header adjustment to OPES processor. This is not a requirement. > o OPES processor SHOULD be able to trace it's own invocation and > service(s) execution since they understand the application > protocol. Misplaced compliance requirement. > o Callout servers MAY be able to add their own OPES trace records > to application level messages. Conflicts with an earlier SHOULD? > A trust domain may include several OPES systems. By definition of an OPES system, it is not possible. OPES system includes everybody that trusts somebody within that system. > Within a trust domain, there MUST be at least support for one trace > entry per OPES system. Compliance subject. > Entities outside of that system may or may not see any traces, > depending on domain policies or configuration. For example, if an > OPES system is on the content provider "side", end-users are not > guaranteed any traces. If an OPES system is working inside end-user > domain, the origin server is not guaranteed any traces related to > user requests. While I agree with the realism of the above statement, it goes against IAB wishes, does it not? We already require on a MUST level that the above does not happen. > In order to support tracing, the following aspects must be addressed: > ... Misplaced compliance requirements. Compliance subjects. (this applies pretty much to the whole section 7 as it repeats many requirements and introduces many requirements for unclear or inappropriate subjects) > 8. Tracing Examples Since all current examples are HTTP-specific, would it be better to keep them in the HTTP Adaptation draft? Is it a good idea to repeat more than one example from another draft? If you keep the examples, please update 1995 dates used (see latest HTTP adaptation draft or use any recent date of your choice). > 9. Optional Notification The text of this section repeats IAB draft rant. Should we keep the rant in IAB draft and just leave one short paragraph with a single example from the HTTP Adaptation draft? HTH, Alex. From owner-ietf-openproxy@mail.imc.org Wed Oct 1 13:26: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 NAA24650 for ; Wed, 1 Oct 2003 13:26:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4kkf-0002WD-00 for opes-archive@ietf.org; Wed, 01 Oct 2003 13:27:01 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A4kke-0002WA-00 for opes-archive@ietf.org; Wed, 01 Oct 2003 13:27:00 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91HF5KP092805 for ; Wed, 1 Oct 2003 10:15:05 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h91HF5Bj092804 for ietf-openproxy-bks; Wed, 1 Oct 2003 10:15:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail2.webwasher.com ([213.70.80.11]) by above.proper.com (8.12.9/8.12.8) with SMTP id h91HF3KP092796 for ; Wed, 1 Oct 2003 10:15:04 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] id MLKQY83Y; 01 Oct 2003 21:22:01 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: Bypassing Date: Wed, 1 Oct 2003 19:14:52 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D014036@mail.webwasher.com> Thread-Topic: Bypassing Thread-Index: AcOIP4bY641h5yghRUmuWxVyiNJ5Cw== From: "Martin Stecher" To: "OPES WG (E-Mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h91HF4KP092800 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi, some questions about how to fill the Bypass section in the http adaption document. 0. Information missing in other drafts? draft-ietf-opes-end-comm-02 does not include any information about bypassing. draft-ietf-opes-iab-02 only points out that the tracin information can be later used to request OPES bypass. Do we need more elaboration on bypassing in draft-ietf-opes-end-comm? 1. What to bypass? There are trace headers OPES-System, OPES-Processor and OPES-Service. Which ones make sense to use in bypassing? Usually it will not be possible to bypass an OPES-Processor but is it required to ask for bypassing of all OPES services that an OPES processor uses? So, do we need one, two or three OPES-Bypass headers? 2. Wildcards I guess we want to allow something like OPES-Bypass: * to request bypassing of all OPES services. Did we ever think about different classes of services? It could make sense to allow all non-modifying OPES services, i.e. those that do some logging/reporting wihtout touching the data at all or those that block the complete message on policy violation (e.g. virus found) but would not alter the page itself. I guess due to the notification/tracing dilema in almost all cases, the HTTP server will not know about single OPES services to bypass and if it is concerned about OPES services it has to request bypass of all or at least of some sort of OPES services. Regards Martin From owner-ietf-openproxy@mail.imc.org Wed Oct 1 13:59: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 NAA25714 for ; Wed, 1 Oct 2003 13:59:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4lGW-0002q0-00 for opes-archive@ietf.org; Wed, 01 Oct 2003 13:59:56 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A4lGW-0002px-00 for opes-archive@ietf.org; Wed, 01 Oct 2003 13:59:56 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91HgtKP094028 for ; Wed, 1 Oct 2003 10:42:55 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h91Hgt0O094027 for ietf-openproxy-bks; Wed, 1 Oct 2003 10:42:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91HgsKP094014 for ; Wed, 1 Oct 2003 10:42:54 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h91Hgl005864; Wed, 1 Oct 2003 13:42:47 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Oct 2003 13:42:48 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD75407182716@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Martin Stecher , "OPES WG (E-Mail)" Subject: RE: Bypassing Date: Wed, 1 Oct 2003 13:42:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38843.6D584F5A" 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_01C38843.6D584F5A Content-Type: text/plain Martin, I think we only need one header (at the service level). This header should be applicable to requets and/or responces. This header must not be deleted. abbie > -----Original Message----- > From: Martin Stecher [mailto:martin.stecher@webwasher.com] > Sent: Wednesday, October 01, 2003 1:15 PM > To: OPES WG (E-Mail) > Subject: Bypassing > > > > Hi, > > some questions about how to fill the Bypass section in the > http adaption document. > > 0. Information missing in other drafts? > draft-ietf-opes-end-comm-02 does not include any information > about bypassing. draft-ietf-opes-iab-02 only points out that > the tracin information can be later used to request OPES > bypass. Do we need more elaboration on bypassing in > draft-ietf-opes-end-comm? > > 1. What to bypass? > There are trace headers OPES-System, OPES-Processor and > OPES-Service. Which ones make sense to use in bypassing? > Usually it will not be possible to bypass an OPES-Processor > but is it required to ask for bypassing of all OPES services > that an OPES processor uses? So, do we need one, two or three > OPES-Bypass headers? > > 2. Wildcards > I guess we want to allow something like > OPES-Bypass: * > to request bypassing of all OPES services. > Did we ever think about different classes of services? > It could make sense to allow all non-modifying OPES services, > i.e. those that do some logging/reporting wihtout touching > the data at all or those that block the complete message on > policy violation (e.g. virus found) but would not alter the > page itself. I guess due to the notification/tracing dilema > in almost all cases, the HTTP server will not know about > single OPES services to bypass and if it is concerned about > OPES services it has to request bypass of all or at least of > some sort of OPES services. > > > Regards > Martin > > ------_=_NextPart_001_01C38843.6D584F5A Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Bypassing

Martin,

I think we only need one header (at the service = level). This header should be applicable to requets and/or responces. = This header must not be deleted.

abbie


> -----Original Message-----
> From: Martin Stecher [mailto:martin.stecher@webwa= sher.com]
> Sent: Wednesday, October 01, 2003 1:15 = PM
> To: OPES WG (E-Mail)
> Subject: Bypassing
>
>
>
> Hi,
>
> some questions about how to fill the Bypass = section in the
> http adaption document.
>
> 0. Information missing in other drafts?
> draft-ietf-opes-end-comm-02 does not include = any information
> about bypassing. draft-ietf-opes-iab-02 only = points out that
> the tracin information can be later used to = request OPES
> bypass. Do we need more elaboration on = bypassing in
> draft-ietf-opes-end-comm?
>
> 1. What to bypass?
> There are trace headers OPES-System, = OPES-Processor and
> OPES-Service. Which ones make sense to use in = bypassing?
> Usually it will not be possible to bypass an = OPES-Processor
> but is it required to ask for bypassing of all = OPES services
> that an OPES processor uses? So, do we need = one, two or three
> OPES-Bypass headers?
>
> 2. Wildcards
> I guess we want to allow something like
>   OPES-Bypass: *
> to request bypassing of all OPES = services.
> Did we ever think about different classes of = services?
> It could make sense to allow all non-modifying = OPES services,
> i.e. those that do some logging/reporting = wihtout touching
> the data at all or those that block the = complete message on
> policy violation (e.g. virus found) but would = not alter the
> page itself. I guess due to the = notification/tracing dilema
> in almost all cases, the HTTP server will not = know about
> single OPES services to bypass and if it is = concerned about
> OPES services it has to request bypass of all = or at least of
> some sort of OPES services.
>
>
> Regards
> Martin
>
>

------_=_NextPart_001_01C38843.6D584F5A-- From owner-ietf-openproxy@mail.imc.org Wed Oct 1 14:12:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26088 for ; Wed, 1 Oct 2003 14:12:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4lSM-0002xj-00 for opes-archive@ietf.org; Wed, 01 Oct 2003 14:12:10 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A4lSL-0002xg-00 for opes-archive@ietf.org; Wed, 01 Oct 2003 14:12:09 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91HvdKP094539 for ; Wed, 1 Oct 2003 10:57:39 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h91HvdiT094537 for ietf-openproxy-bks; Wed, 1 Oct 2003 10:57:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91HvcKP094532 for ; Wed, 1 Oct 2003 10:57:38 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h91HvdGh039497; Wed, 1 Oct 2003 11:57:39 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h91HvdFl039496; Wed, 1 Oct 2003 11:57:39 -0600 (MDT) (envelope-from rousskov) Date: Wed, 1 Oct 2003 11:57:39 -0600 (MDT) From: Alex Rousskov To: Martin Stecher cc: "OPES WG (E-Mail)" Subject: Re: Bypassing In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D014036@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D014036@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 1 Oct 2003, Martin Stecher wrote: > some questions about how to fill the Bypass section in the http > adaption document. > > 0. Information missing in other drafts? > draft-ietf-opes-end-comm-02 does not include any information about bypassing. > draft-ietf-opes-iab-02 only points out that the tracin information can be later > used to request OPES bypass. > Do we need more elaboration on bypassing in draft-ietf-opes-end-comm? Yes. I also included a note about that in my review (sent to the list an hour or so ago). > 1. What to bypass? > There are trace headers OPES-System, OPES-Processor and OPES-Service. > Which ones make sense to use in bypassing? > Usually it will not be possible to bypass an OPES-Processor but is it required > to ask for bypassing of all OPES services that an OPES processor uses? > So, do we need one, two or three OPES-Bypass headers? For simplicity and generality, I would suggest one header. Each OPES entity above must be identified by its URI. So, assuming different kinds of entities have different URIs, one header to bypass anything is sufficient. Of course, some entities (on any level) may not be bypass-able for a given application message. That's OK. > 2. Wildcards > I guess we want to allow something like > OPES-Bypass: * > to request bypassing of all OPES services. Yes. > Did we ever think about different classes of services? It could make > sense to allow all non-modifying OPES services, i.e. those that do > some logging/reporting wihtout touching the data at all or those > that block the complete message on policy violation (e.g. virus > found) but would not alter the page itself. Good point. I would suggest that we standardize URIs that identify overlapping "classes" or "types" of OPES entities: - modifying (forwarding with modifications other than traces) - blocking (not forwarding) - reading (forwarding without modifications other than traces) - logging (keeping a portion of a message beyond message TTL) - unknown (the entity in charge of bypass does not know the class of an entity it forwards OPES traffic to) More or better class names, anyone? One could argue that pure "reading" entities do not exist. We can leave it as a loophole for statistics-collecting entities, but note that statistics collection at a "reading-only" entity MUST NOT include storing samples of any size. This addition will not affect OPES-Bypass header syntax or semantics. We are still doing a URI match. It's just that some entities are known by several URIs (unique one and a "group/class" URI). See below for an example. > I guess due to the notification/tracing dilema in almost all cases, > the HTTP server will not know about single OPES services to bypass > and if it is concerned about OPES services it has to request bypass > of all or at least of some sort of OPES services. I agree that it would take some advance configuration support on processor side to implement bypass, but it is probably relatively easy to document in the draft. Eventually, it may become implemented: id: unique URI aka: classification URIs (at least one SHOULD be present since we have an unknown category) protocol: internal info describing ways to communicate with the service (ICAP, OCP, plugin, etc.) bypassable: yes/no (indicates whether requests to bypass the service should be honored) HTH, Alex. From owner-ietf-openproxy@mail.imc.org Wed Oct 1 20:05: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 UAA11302 for ; Wed, 1 Oct 2003 20:05:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4qya-0007Mz-00 for opes-archive@ietf.org; Wed, 01 Oct 2003 20:05:48 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A4qyZ-0007Mw-00 for opes-archive@ietf.org; Wed, 01 Oct 2003 20:05:47 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91Np8KP008100 for ; Wed, 1 Oct 2003 16:51:08 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h91Np8Yt008099 for ietf-openproxy-bks; Wed, 1 Oct 2003 16:51:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91Np6KP008094 for ; Wed, 1 Oct 2003 16:51:07 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h91Np9Gh048985 for ; Wed, 1 Oct 2003 17:51:09 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h91Np9WT048984; Wed, 1 Oct 2003 17:51:09 -0600 (MDT) (envelope-from rousskov) Date: Wed, 1 Oct 2003 17:51:09 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: honoring bypass is a MUST 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: Abbie, You asked me to investigate whether honoring bypass is a MUST or a SHOULD. IMO, IAB consideration 3.3 clearly indicates that it has to be a MUST, with a caveat: (3.3) Non-blocking: If there exists a "non-OPES" version of content available from the content provider, the OPES architecture must not prevent users from retrieving this "non-OPES" version from the content provider. The bypass requirement will be non-trivial to define accurately. First, you have to distinguish two cases based on availability of non-OPES content. Second, you have to be careful not to require compliance from OPES entities that do not care about application message headers that may contain bypass instructions. For example, it is unreasonable to expect an image transformation service that works with content, not HTTP headers to handle bypass -- an OPES processor calling that service must handle bypass. On the other hand, in some cases, only the service would be able to match the bypass URI because an OPES processor will not know the URI of the service or will not know its "class" (see Martin's thoughts on classes of services). Now, what do we do when the two cases are combined (the service is not able and the processor is able but does not have the required information)?? Third, you have to document what happens when an OPES entity needs to bypass itself. Clearly, it should not modify message content, but should it add its own trace since it touched the message? Yes, because it did touch the message. No, because maybe its [corrupted] trace entry is the reason the other end wants to bypass! Finally, you should not rely on bypass instructions to be transmitted in-band (e.g., in request headers). Bypass information transmission should be left to the application binding drafts. Keep it simple :-). Good luck, Alex. From owner-ietf-openproxy@mail.imc.org Thu Oct 2 04:11:29 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07112 for ; Thu, 2 Oct 2003 04:11:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4yYh-0004Wn-00 for opes-archive@ietf.org; Thu, 02 Oct 2003 04:11:35 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A4yYh-0004Wk-00 for opes-archive@ietf.org; Thu, 02 Oct 2003 04:11:35 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h927wJKP076734 for ; Thu, 2 Oct 2003 00:58:19 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h927wJoL076732 for ietf-openproxy-bks; Thu, 2 Oct 2003 00:58:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail2.webwasher.com ([213.70.80.11]) by above.proper.com (8.12.9/8.12.8) with SMTP id h927wGKP076676 for ; Thu, 2 Oct 2003 00:58:17 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] id RUWHGCRH; 02 Oct 2003 12:05:13 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: honoring bypass is a MUST Date: Thu, 2 Oct 2003 09:58:04 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D0552DB@mail.webwasher.com> Thread-Topic: honoring bypass is a MUST Thread-Index: AcOIfF+eexukn4voQRWfOHQH6Ali3QAOhWeA From: "Martin Stecher" To: "OPES WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h927wIKP076723 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi, if we require that the service's trace URI is identical with the service URI being used by the OPES processor in the SGC (service group create) command, then we ensure that the OPES processor is able to handle the bypass without contacting the service at all. Martin > -----Original Message----- > From: owner-ietf-openproxy@mail.imc.org > [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of Alex Rousskov > Sent: Thursday, October 02, 2003 1:51 AM > To: OPES WG > Subject: honoring bypass is a MUST > > > > Abbie, > > You asked me to investigate whether honoring bypass is a MUST > or a SHOULD. IMO, IAB consideration 3.3 clearly indicates that it has > to be a MUST, with a caveat: > > (3.3) Non-blocking: If there exists a "non-OPES" version of content > available from the content provider, the OPES architecture must not > prevent users from retrieving this "non-OPES" version from the > content provider. > > The bypass requirement will be non-trivial to define accurately. > First, you have to distinguish two cases based on availability of > non-OPES content. > > Second, you have to be careful not to require compliance from OPES > entities that do not care about application message headers that may > contain bypass instructions. For example, it is unreasonable to expect > an image transformation service that works with content, not HTTP > headers to handle bypass -- an OPES processor calling that service > must handle bypass. On the other hand, in some cases, only the service > would be able to match the bypass URI because an OPES processor will > not know the URI of the service or will not know its "class" (see > Martin's thoughts on classes of services). Now, what do we do when the > two cases are combined (the service is not able and the processor is > able but does not have the required information)?? > > Third, you have to document what happens when an OPES entity needs to > bypass itself. Clearly, it should not modify message content, but > should it add its own trace since it touched the message? Yes, because > it did touch the message. No, because maybe its [corrupted] trace > entry is the reason the other end wants to bypass! > > Finally, you should not rely on bypass instructions to be transmitted > in-band (e.g., in request headers). Bypass information transmission > should be left to the application binding drafts. > > Keep it simple :-). > > Good luck, > > Alex. > > ------------------------------------------------------------ > This mail has been scanned by debian3-smtp > (WebWasher 4.4.1 Build 652) > ------------------------------------------------------------ > From owner-ietf-openproxy@mail.imc.org Thu Oct 2 04:20: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 EAA07341 for ; Thu, 2 Oct 2003 04:20:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4yhg-0004bj-00 for opes-archive@ietf.org; Thu, 02 Oct 2003 04:20:52 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A4yhg-0004bg-00 for opes-archive@ietf.org; Thu, 02 Oct 2003 04:20:52 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92896KP079837 for ; Thu, 2 Oct 2003 01:09:06 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h92896hs079836 for ietf-openproxy-bks; Thu, 2 Oct 2003 01:09:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail2.webwasher.com ([213.70.80.11]) by above.proper.com (8.12.9/8.12.8) with SMTP id h92894KP079810 for ; Thu, 2 Oct 2003 01:09:04 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] id ZI61SYIB; 02 Oct 2003 12:16:08 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: Bypassing Date: Thu, 2 Oct 2003 10:08:58 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D0552DC@mail.webwasher.com> Thread-Topic: Bypassing Thread-Index: AcOIRYKczoZ4i9DMRMG5Vm3HGBjzPAAdh7Uw From: "Martin Stecher" To: "OPES WG (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h92895KP079827 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi, >... > > > Did we ever think about different classes of services? It could make > > sense to allow all non-modifying OPES services, i.e. those that do > > some logging/reporting wihtout touching the data at all or those > > that block the complete message on policy violation (e.g. virus > > found) but would not alter the page itself. > > Good point. I would suggest that we standardize URIs that identify > overlapping "classes" or "types" of OPES entities: > - modifying (forwarding with modifications other than traces) > - blocking (not forwarding) > - reading (forwarding without modifications other than traces) > - logging (keeping a portion of a message beyond message TTL) > - unknown (the entity in charge of bypass does not know the > class of an entity it forwards OPES traffic to) > > More or better class names, anyone? > What about encoding changes? Is removing/adding a content or transfer encoding a modification? Not of the real content but we may have this as an additional class or subclass. - modifying - blocking+encoding - logging+encoding - blocking - logging - reading - unknown Does this make sense? If yes, what if the service is of class "blocking" and the OPES processor does the preprocessing of removing gzip-encoding? Is the OPES processor then responsible for adjusting the class? Martin From owner-ietf-openproxy@mail.imc.org Thu Oct 2 11:26: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 LAA26423 for ; Thu, 2 Oct 2003 11:26:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A55Lw-0002GG-00 for opes-archive@ietf.org; Thu, 02 Oct 2003 11:26:52 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A55Lv-0002G5-00 for opes-archive@ietf.org; Thu, 02 Oct 2003 11:26:51 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92FAIKP099537 for ; Thu, 2 Oct 2003 08:10:18 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h92FAIME099536 for ietf-openproxy-bks; Thu, 2 Oct 2003 08:10:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92FAGKP099527 for ; Thu, 2 Oct 2003 08:10:16 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h92FAHGh071344; Thu, 2 Oct 2003 09:10:17 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h92FAG33071343; Thu, 2 Oct 2003 09:10:16 -0600 (MDT) (envelope-from rousskov) Date: Thu, 2 Oct 2003 09:10:16 -0600 (MDT) From: Alex Rousskov To: Martin Stecher cc: OPES WG Subject: RE: honoring bypass is a MUST In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D0552DB@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D0552DB@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 2 Oct 2003, Martin Stecher wrote: > if we require that the service's trace URI is identical with the > service URI being used by the OPES processor in the SGC (service > group create) command, then we ensure that the OPES processor is > able to handle the bypass without contacting the service at all. I would not require that (MUST). It can be a SHOULD, I guess. Imagine a callout server that does one of 10 things to the message, depending on message content. The processor will know the server under i-do-10-things URI, but a trace may contain a more specific i-did-1-thing URI (unknown a priory to the processor). Also, with your adaptation classes idea, the processor may not know the class of the adaptation service it is using and, hence, would not be able to bypass it without communicating with the service first. This implies that we should probably pass bypass URIs in the SGC or a similar command, right? This way the service can bypass itself before it sees the message, if possible. Since bypass is, by nature, an imprecise no-guarantees mechanism, my preference would be to leave things simple and flexible rather than introduce a new layer of strict/rigid requirements on service identification. On the other hand, I understand that we need to find a balance between "a overly complicated optional feature that nobody supports" and "an overly flexible optional feature that is widely supported but offers no reliability". Alex. > > -----Original Message----- > > From: owner-ietf-openproxy@mail.imc.org > > [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of Alex Rousskov > > Sent: Thursday, October 02, 2003 1:51 AM > > To: OPES WG > > Subject: honoring bypass is a MUST > > > > > > > > Abbie, > > > > You asked me to investigate whether honoring bypass is a MUST > > or a SHOULD. IMO, IAB consideration 3.3 clearly indicates that it has > > to be a MUST, with a caveat: > > > > (3.3) Non-blocking: If there exists a "non-OPES" version of content > > available from the content provider, the OPES architecture must not > > prevent users from retrieving this "non-OPES" version from the > > content provider. > > > > The bypass requirement will be non-trivial to define accurately. > > First, you have to distinguish two cases based on availability of > > non-OPES content. > > > > Second, you have to be careful not to require compliance from OPES > > entities that do not care about application message headers that may > > contain bypass instructions. For example, it is unreasonable to expect > > an image transformation service that works with content, not HTTP > > headers to handle bypass -- an OPES processor calling that service > > must handle bypass. On the other hand, in some cases, only the service > > would be able to match the bypass URI because an OPES processor will > > not know the URI of the service or will not know its "class" (see > > Martin's thoughts on classes of services). Now, what do we do when the > > two cases are combined (the service is not able and the processor is > > able but does not have the required information)?? > > > > Third, you have to document what happens when an OPES entity needs to > > bypass itself. Clearly, it should not modify message content, but > > should it add its own trace since it touched the message? Yes, because > > it did touch the message. No, because maybe its [corrupted] trace > > entry is the reason the other end wants to bypass! > > > > Finally, you should not rely on bypass instructions to be transmitted > > in-band (e.g., in request headers). Bypass information transmission > > should be left to the application binding drafts. > > > > Keep it simple :-). > > > > Good luck, > > > > Alex. > > > > ------------------------------------------------------------ > > This mail has been scanned by debian3-smtp > > (WebWasher 4.4.1 Build 652) > > ------------------------------------------------------------ > > > > From owner-ietf-openproxy@mail.imc.org Thu Oct 2 12:00:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28209 for ; Thu, 2 Oct 2003 12:00:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A55sy-0002m9-00 for opes-archive@ietf.org; Thu, 02 Oct 2003 12:01:00 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A55sx-0002lx-00 for opes-archive@ietf.org; Thu, 02 Oct 2003 12:01:00 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92FhZKP001226 for ; Thu, 2 Oct 2003 08:43:35 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h92FhZOM001225 for ietf-openproxy-bks; Thu, 2 Oct 2003 08:43:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92FhXKP001218 for ; Thu, 2 Oct 2003 08:43:33 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h92FhYGh072305; Thu, 2 Oct 2003 09:43:34 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h92FhYKW072304; Thu, 2 Oct 2003 09:43:34 -0600 (MDT) (envelope-from rousskov) Date: Thu, 2 Oct 2003 09:43:34 -0600 (MDT) From: Alex Rousskov To: Martin Stecher cc: "OPES WG (E-mail)" Subject: RE: Bypassing In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D0552DC@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D0552DC@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 2 Oct 2003, Martin Stecher wrote: > What about encoding changes? > Is removing/adding a content or transfer encoding a modification? > Not of the real content but we may have this as an additional class > or subclass. > > - modifying > - blocking+encoding > - logging+encoding > - blocking > - logging > - reading > - unknown Indeed! Looks like we have modification of content/message _meaning_ and modification of content/message presentation (encodings and formats of all sorts). In general, it is impossible to distinguish the two formally, but there are many specific adaptations where the difference is clear. I would suggest: - modifying ~ meaning ~ presentation - blocking - logging - reading - unknown The total of 7 classes. One would be able to request a bypass of all services that modify the message (in any way) OR bypass of all services that modify the message beyond presentational modifications such as content encoding or image quality adaptations. Any combination is permitted, of course. An entity may be both meaning-modifying and blocking. Somebody may request bypass for all unknown and logging entities. N.B. Transfer encoding allowed by the application protocol is not adaptation we care about, I guess. This can be done outside of OPES already, without violating protocol rules. We only care about OPES-enabled adaptations that are not allowed by application protocols or break end-to-end expectations (e.g., addition of ads or logging adaptations). > If yes, what if the service is of class "blocking" and the OPES > processor does the preprocessing of removing gzip-encoding? Is the > OPES processor then responsible for adjusting the class? The class is currently not reported anywhere (we should probably add this as an optional parameter to the OPES-* headers though!). Thus, there is nothing to adjust. Each entity (including processors and services) is responsible for handling bypass instructions it receives. If processor only knows its own class, it will handle bypass based on that class and, optionally, handle bypass for "unknown" class of service (since the processor does not know the class of service). The service, in turn, will bypass its own class if it can. Of course, if the processor does know more about the service it uses, it should bypass the service when there is a match. Does this clarify? Did I miss anything? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Fri Oct 3 10:13:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08608 for ; Fri, 3 Oct 2003 10:12:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Qg7-0001Ip-00 for opes-archive@ietf.org; Fri, 03 Oct 2003 10:13:07 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A5Qg6-0001Il-00 for opes-archive@ietf.org; Fri, 03 Oct 2003 10:13:06 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93DwFKP021632 for ; Fri, 3 Oct 2003 06:58:15 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h93DwFOA021631 for ietf-openproxy-bks; Fri, 3 Oct 2003 06:58:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zrtps0kn.nortelnetworks.com (zrtps0kn.nortelnetworks.com [47.140.192.55]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93DwEKP021625 for ; Fri, 3 Oct 2003 06:58:14 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h93DvoL25885; Fri, 3 Oct 2003 09:57:50 -0400 (EDT) Received: from zrtpd0jh.us.nortel.com ([47.140.202.34]) by zrtpd0jn.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T9HC3L3T; Fri, 3 Oct 2003 09:57:50 -0400 Received: by zrtpd0jh.us.nortel.com with Internet Mail Service (5.5.2653.19) id <41VAYBGB>; Fri, 3 Oct 2003 09:57:50 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754071ECC1E@zcard0k6.ca.nortel.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Abbie Barbir" To: Alex Rousskov , Martin Stecher Cc: "OPES WG (E-mail)" Subject: RE: Bypassing Date: Fri, 3 Oct 2003 09:57:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Regarding Bypass, I really think we should call it non-blocking, since the term bypass is being misused. Let us not loose sight of what is needed. (3.3) Non-blocking: If there exists a "non-OPES" version of content available from the content provider, the OPES architecture must not prevent users from retrieving this "non-OPES" version from the content provider. It is important for us to understand what this means. So here what I think 1. This is related to content modification (like image cropping, translation etc) 2. Presentation is not the issue as long as the original content is presented in the way that the content provider has intended. 3. It is the task of the content provider to make non-OPES versions available, so OPES can serve them. In this case, the first OPES processor will check the header of the message and see a non-blocking header on it, in the simplest scenario, it will just fwd the request to the origin content provider if the content provider allows that, otherwise, the opes version is served. The user may get a page with missing weather info or no ads and may be pink background, (so that what he gets...) A user can issue non-blocking requests, but whether it is honored or not is a function of how the content is/was or will be created and what the content provider provides and its agreement with the OPES provider. Looking at the bypass thread, it seems to me that we are not following what IAB 3.3 suggests. We are not in the business of providing the user with optional services or processors or callout servers that he/she can bypass (or what you call class of services). As far as our non-blocking requirements go: 1. An OPES System Must Support non-blocking 2. An OPES Processor MUST be able to process a non-blocking header 3. Non-blocking MUST be Done in-band. So, from your e-mails, non-blocking default to a wildcard request, where what it means is a fucntion of the agreement between the content provider and the OPES provider. PS: The IAB has asked us to build a house (and from the bypass thread, it seems that you want to build a Castle). Abbie From owner-ietf-openproxy@mail.imc.org Fri Oct 3 10:55: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 KAA10864 for ; Fri, 3 Oct 2003 10:55:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5RKp-0001n9-00 for opes-archive@ietf.org; Fri, 03 Oct 2003 10:55:11 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A5RKo-0001n6-00 for opes-archive@ietf.org; Fri, 03 Oct 2003 10:55:10 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93EhTKP023896 for ; Fri, 3 Oct 2003 07:43:29 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h93EhTOo023895 for ietf-openproxy-bks; Fri, 3 Oct 2003 07:43:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93EhSKP023889 for ; Fri, 3 Oct 2003 07:43:28 -0700 (PDT) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id h93EhThg041437 for ; Fri, 3 Oct 2003 10:43:29 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h93EhMJl066249 for ; Fri, 3 Oct 2003 10:43:22 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h93EhLFU015853 for ; Fri, 3 Oct 2003 10:43:21 -0400 (EDT) Message-ID: <3F7D8B73.4030105@mhof.com> Date: Fri, 03 Oct 2003 10:45:07 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "OPES WG (E-mail)" Subject: Re: Bypassing References: <87609AFB433BD5118D5E0002A52CD754071ECC1E@zcard0k6.ca.nortel.com> In-Reply-To: <87609AFB433BD5118D5E0002A52CD754071ECC1E@zcard0k6.ca.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I mostly agree with Abbie's observations in that the fine-grained BYPASS features discussed earlier in the thread are not really what we need to do and too complicated. In particular, I'd be reluctant to specify classes of OPES services, since we'll never be able to predict all future OPES service classes... If a user requests non-blocking, OPES processor needs to determine whether a "non-OPES" version is available. If yes, this version will have to be served. If not, either an error is returned or the OPES version is served. It then boils down on how to determine whether there's a non-OPES version available, which Abbie addresses under (3) below. Couldn't we go that far and say that requests with non-blocking flag are always being forwarded to the origin server. Now, when an error comes back (because there's no non-OPES version), we could either leave it to the user to remove the non-blocking flag (if wanted), or invoke the OPES service and serve the OPES version. -Markus Abbie Barbir wrote: > > Regarding Bypass, > > I really think we should call it non-blocking, since the term bypass is > being misused. > Let us not loose sight of what is needed. > > (3.3) Non-blocking: If there exists a "non-OPES" version of content > available from the content provider, the OPES architecture must not > prevent users from retrieving this "non-OPES" version from the > content provider. > > It is important for us to understand what this means. So here what I think > > 1. This is related to content modification (like image cropping, translation > etc) > 2. Presentation is not the issue as long as the original content is > presented in the way that the content provider has intended. > > 3. It is the task of the content provider to make non-OPES versions > available, so OPES can serve them. In this case, the first OPES processor > will check the header of the message and see a non-blocking header on it, in > the simplest scenario, it will just fwd the request to the origin content > provider if the content provider allows that, otherwise, the opes version is > served. The user may get a page with missing weather info or no ads and may > be pink background, (so that what he gets...) > > A user can issue non-blocking requests, but whether it is honored or not is > a function of how the content is/was or will be created and what the content > provider provides and its agreement with the OPES provider. > > Looking at the bypass thread, it seems to me that we are not following what > IAB 3.3 suggests. We are not in the business of providing the user with > optional services or processors or callout servers that he/she can bypass > (or what you call class of services). > > As far as our non-blocking requirements go: > > 1. An OPES System Must Support non-blocking > 2. An OPES Processor MUST be able to process a non-blocking header > 3. Non-blocking MUST be Done in-band. > > So, from your e-mails, non-blocking default to a wildcard request, where > what it means is a fucntion of the agreement between the content provider > and the OPES provider. > > PS: The IAB has asked us to build a house (and from the bypass thread, it > seems that you want to build a Castle). > > > Abbie > > > > From owner-ietf-openproxy@mail.imc.org Fri Oct 3 11:57:11 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13370 for ; Fri, 3 Oct 2003 11:57:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5SIx-0002Xi-00 for opes-archive@ietf.org; Fri, 03 Oct 2003 11:57:19 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A5SIx-0002Xf-00 for opes-archive@ietf.org; Fri, 03 Oct 2003 11:57:19 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93FkQKP027275 for ; Fri, 3 Oct 2003 08:46:26 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h93FkQLZ027274 for ietf-openproxy-bks; Fri, 3 Oct 2003 08:46:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93FkOKP027269 for ; Fri, 3 Oct 2003 08:46:24 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h93FkPGh009038; Fri, 3 Oct 2003 09:46:25 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h93FkPnx009037; Fri, 3 Oct 2003 09:46:25 -0600 (MDT) (envelope-from rousskov) Date: Fri, 3 Oct 2003 09:46:25 -0600 (MDT) From: Alex Rousskov To: "OPES WG (E-mail)" Subject: RE: Bypassing In-Reply-To: <87609AFB433BD5118D5E0002A52CD754071ECC1E@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD754071ECC1E@zcard0k6.ca.nortel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 3 Oct 2003, Abbie Barbir wrote: > I really think we should call it non-blocking, since the term bypass > is being misused. I disagree. What we need is a bypass mechanism. OPES does not block anything in general, it adapts. Not to mention that using a negated term to name a concept is not "right". Finally, non-blocking is not a noun, is it? > Let us not loose sight of what is needed. > > (3.3) Non-blocking: If there exists a "non-OPES" version of content > available from the content provider, the OPES architecture must not > prevent users from retrieving this "non-OPES" version from the > content provider. > > It is important for us to understand what this means. So here what I think > > 1. This is related to content modification (like image cropping, > translation > etc) Not necessarily. For example, if I know that my ISP is logging all HTTP request bodies to be sent to FBI or a marketing agency, I want to tell my ISP to bypass that feature. An OPES-compliant ISP will honor my request if possible. > 2. Presentation is not the issue as long as the original content is > presented in the way that the content provider has intended. We do not know providers intent. Some providers would consider translation an acceptable presentational change. Some would consider content encoding change (GIF->PNG) as unacceptable. Is image cropping a presentational issue? Depends on the context... > 3. It is the task of the content provider to make non-OPES versions > available, so OPES can serve them. In this case, the first OPES > processor will check the header of the message and see a > non-blocking header on it, in the simplest scenario, it will just > fwd the request to the origin content provider if the content > provider allows that, otherwise, the opes version is served. The > user may get a page with missing weather info or no ads and may be > pink background, (so that what he gets...) True, except we cannot tell whether it is the first or any other OPES processor or callout service that will honor the bypass instruction. We should not tell an OPES system exactly how to implement bypass. > A user can issue non-blocking requests, but whether it is honored or > not is a function of how the content is/was or will be created and > what the content provider provides and its agreement with the OPES > provider. Agreed. > Looking at the bypass thread, it seems to me that we are not > following what IAB 3.3 suggests. We are not in the business of > providing the user with optional services or processors or callout > servers that he/she can bypass (or what you call class of services). IAB is concerned about some minimal functionality. We can get a lot more, at about the same cost. We do follow what IAB 3.3 suggests, but we go further. If you disagree or do not want to do the legwork, I suggest a simple compromise: Document the Bypass: URI|* feature, but leave URI semantics interpretation for future drafts to define (with an appropriate default). Document just the "Bypass: *" version. This way, we are addressing an IAB concern and leaving enough room for future extensions. This has to be documented in a application-agnostic way, of course. > As far as our non-blocking requirements go: > > 1. An OPES System Must Support non-blocking non-blocking what? Bypass is a noun, non-blocking is not, right? > 2. An OPES Processor MUST be able to process a non-blocking header You have to define _how_ it MUST process it for this requirement to make sense. Clearly, a processor will process it somehow (e.g., forward it to the next application hop). > 3. Non-blocking MUST be Done in-band. Do you mean "and only in-band"? What does this requirement buy you? > So, from your e-mails, non-blocking default to a wildcard request, > where what it means is a fucntion of the agreement between the > content provider and the OPES provider. I agree with the wildcard part, but I think that we must define "what it means" or there is not reason to document it at all. > PS: The IAB has asked us to build a house (and from the bypass > thread, it seems that you want to build a Castle). Let's not go down this path or we will never stop arguing: The IAB has asked us to make sure kids do not eat poisonous mushrooms. What you are suggesting is to make sure kids do not eat mushrooms. See for a constructive compromise idea above. Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Fri Oct 3 12:12:33 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14045 for ; Fri, 3 Oct 2003 12:12:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5SXp-0002mG-00 for opes-archive@ietf.org; Fri, 03 Oct 2003 12:12:42 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A5SXp-0002mD-00 for opes-archive@ietf.org; Fri, 03 Oct 2003 12:12:41 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93FwYKP028007 for ; Fri, 3 Oct 2003 08:58:34 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h93FwXVV028006 for ietf-openproxy-bks; Fri, 3 Oct 2003 08:58:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93FwWKP028000 for ; Fri, 3 Oct 2003 08:58:32 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h93FwXGh009267; Fri, 3 Oct 2003 09:58:33 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h93FwXFC009266; Fri, 3 Oct 2003 09:58:33 -0600 (MDT) (envelope-from rousskov) Date: Fri, 3 Oct 2003 09:58:33 -0600 (MDT) From: Alex Rousskov To: "OPES WG (E-mail)" Subject: Re: Bypassing In-Reply-To: <3F7D8B73.4030105@mhof.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD754071ECC1E@zcard0k6.ca.nortel.com> <3F7D8B73.4030105@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 3 Oct 2003, Markus Hofmann wrote: > I mostly agree with Abbie's observations in that the fine-grained > BYPASS features discussed earlier in the thread are not really what > we need to do and too complicated. In particular, I'd be reluctant > to specify classes of OPES services, since we'll never be able to > predict all future OPES service classes... We do not have to specify all classes or _any_ classes. I suggest that we specify a URI-based interface (with a wildcard) and specify appropriate defaults for implementations that do not understand the meaning of a given URI. Others may use our interface and specify URI meanings. > If a user requests non-blocking, OPES processor needs to determine > whether a "non-OPES" version is available. If yes, this version will > have to be served. If not, either an error is returned or the OPES > version is served. Agreed. > It then boils down on how to determine whether there's a non-OPES > version available, The exact mechanism is out of our scope. OPES systems will "determine" somehow. > Couldn't we go that far and say that requests with non-blocking flag > are always being forwarded to the origin server. Not in general. (a) A request may need to be modified for non-OPES content to be served by the OPES-unaware server (e.g., a particular header or parameter may need to be added by an OPES processor). And (b) this is too HTTP-specific. > Now, when an error comes back (because there's no non-OPES version), > we could either leave it to the user to remove the non-blocking flag > (if wanted), or invoke the OPES service and serve the OPES version. A user usually does not have control over low-level information such as HTTP headers. The bypass has to be implemented entirely within the OPES system (or it is not a bypass). Alex. From owner-ietf-openproxy@mail.imc.org Fri Oct 3 12:13: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 MAA14077 for ; Fri, 3 Oct 2003 12:13:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5SYT-0002mn-00 for opes-archive@ietf.org; Fri, 03 Oct 2003 12:13:21 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A5SYS-0002mk-00 for opes-archive@ietf.org; Fri, 03 Oct 2003 12:13:20 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93G1FKP028239 for ; Fri, 3 Oct 2003 09:01:15 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h93G1FIx028238 for ietf-openproxy-bks; Fri, 3 Oct 2003 09:01:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zrtps0kn.nortelnetworks.com (zrtps0kn.nortelnetworks.com [47.140.192.55]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93G14KP028212 for ; Fri, 3 Oct 2003 09:01:14 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h93G0qL26265; Fri, 3 Oct 2003 12:00:52 -0400 (EDT) Received: from zrtpd0jh.us.nortel.com ([47.140.202.34]) by zrtpd0j7.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZYG61YC; Fri, 3 Oct 2003 12:00:53 -0400 Received: by zrtpd0jh.us.nortel.com with Internet Mail Service (5.5.2653.19) id <41VAY3LQ>; Fri, 3 Oct 2003 12:00:52 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD75407250728@zcard0k6.ca.nortel.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Abbie Barbir" To: Alex Rousskov , "OPES WG (E-mail)" Subject: RE: Bypassing Date: Fri, 3 Oct 2003 12:00:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Alex, I will not argue non-blocking vs bypass. I am very comfortable to use the IAB term (just to be consistent). From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Friday, October 03, 2003 11:46 AM > To: OPES WG (E-mail) > Subject: RE: Bypassing SNIP > Not necessarily. For example, if I know that my ISP is > logging all HTTP request bodies to be sent to FBI or a > marketing agency, I want to tell my ISP to bypass that > feature. An OPES-compliant ISP will honor my request if possible. I recommend that you change ISP or better move to another country. This is not what we are asked to do here by the IAB. > True, except we cannot tell whether it is the first or any > other OPES processor or callout service that will honor the > bypass instruction. We should not tell an OPES system exactly > how to implement bypass. It is clear from (3.3) it is client centric (It is the 1st OPES processor that will get the request) > IAB is concerned about some minimal functionality. We can get > a lot more, at about the same cost. We do follow what IAB 3.3 > suggests, but we go further. U can if u have the time. I suggest that u do the minimum for now and get the OCP/HTTP drafts done, otherwise, just packup and go home. > > 3. Non-blocking MUST be Done in-band. > > Do you mean "and only in-band"? What does this requirement buy you? What I mean, just ride on tracing (one extra header all what we need) Regarding your compromise, I will consider it Abbie > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Friday, October 03, 2003 11:46 AM > To: OPES WG (E-mail) > Subject: RE: Bypassing > > > > On Fri, 3 Oct 2003, Abbie Barbir wrote: > > > I really think we should call it non-blocking, since the > term bypass > > is being misused. > > I disagree. What we need is a bypass mechanism. OPES does not > block anything in general, it adapts. Not to mention that > using a negated term to name a concept is not "right". > Finally, non-blocking is not a noun, is it? > > > Let us not loose sight of what is needed. > > > > (3.3) Non-blocking: If there exists a "non-OPES" version of content > > available from the content provider, the OPES > architecture must not > > prevent users from retrieving this "non-OPES" version from the > > content provider. > > > > It is important for us to understand what this means. So > here what I > > think > > > > 1. This is related to content modification (like image cropping, > > translation > > etc) > > Not necessarily. For example, if I know that my ISP is > logging all HTTP request bodies to be sent to FBI or a > marketing agency, I want to tell my ISP to bypass that > feature. An OPES-compliant ISP will honor my request if possible. > > > 2. Presentation is not the issue as long as the original content is > > presented in the way that the content provider has intended. > > We do not know providers intent. Some providers would > consider translation an acceptable presentational change. > Some would consider content encoding change (GIF->PNG) as > unacceptable. Is image cropping a presentational issue? > Depends on the context... > > > 3. It is the task of the content provider to make non-OPES versions > > available, so OPES can serve them. In this case, the first OPES > > processor will check the header of the message and see a > non-blocking > > header on it, in the simplest scenario, it will just fwd > the request > > to the origin content provider if the content provider allows that, > > otherwise, the opes version is served. The user may get a page with > > missing weather info or no ads and may be pink background, (so that > > what he gets...) > > True, except we cannot tell whether it is the first or any > other OPES processor or callout service that will honor the > bypass instruction. We should not tell an OPES system exactly > how to implement bypass. > > > A user can issue non-blocking requests, but whether it is > honored or > > not is a function of how the content is/was or will be created and > > what the content provider provides and its agreement with the OPES > > provider. > > Agreed. > > > Looking at the bypass thread, it seems to me that we are > not following > > what IAB 3.3 suggests. We are not in the business of providing the > > user with optional services or processors or callout servers that > > he/she can bypass (or what you call class of services). > > IAB is concerned about some minimal functionality. We can get > a lot more, at about the same cost. We do follow what IAB 3.3 > suggests, but we go further. > > If you disagree or do not want to do the legwork, I suggest a simple > compromise: Document the > Bypass: URI|* > feature, but leave URI semantics interpretation for future > drafts to define (with an appropriate default). Document just > the "Bypass: *" version. This way, we are addressing an IAB > concern and leaving enough room for future extensions. > > This has to be documented in a application-agnostic way, of course. > > > As far as our non-blocking requirements go: > > > > 1. An OPES System Must Support non-blocking > > non-blocking what? Bypass is a noun, non-blocking is not, right? > > > 2. An OPES Processor MUST be able to process a non-blocking header > > You have to define _how_ it MUST process it for this > requirement to make sense. Clearly, a processor will process > it somehow (e.g., forward it to the next application hop). > > > 3. Non-blocking MUST be Done in-band. > > Do you mean "and only in-band"? What does this requirement buy you? > > > So, from your e-mails, non-blocking default to a wildcard request, > > where what it means is a fucntion of the agreement between > the content > > provider and the OPES provider. > > I agree with the wildcard part, but I think that we must > define "what it means" or there is not reason to document it at all. > > > PS: The IAB has asked us to build a house (and from the > bypass thread, > > it seems that you want to build a Castle). > > Let's not go down this path or we will never stop arguing: > The IAB has asked us to make sure kids do not eat poisonous > mushrooms. What you are suggesting is to make sure kids do > not eat mushrooms. > > See for a constructive compromise idea above. > > Thanks, > > Alex. > From owner-ietf-openproxy@mail.imc.org Fri Oct 3 12:30: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 MAA15272 for ; Fri, 3 Oct 2003 12:30:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5SpW-0003FN-00 for opes-archive@ietf.org; Fri, 03 Oct 2003 12:30:58 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A5SpW-0003FK-00 for opes-archive@ietf.org; Fri, 03 Oct 2003 12:30:58 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93GG5KP029241 for ; Fri, 3 Oct 2003 09:16:05 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h93GG5jg029240 for ietf-openproxy-bks; Fri, 3 Oct 2003 09:16:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93GG3KP029234 for ; Fri, 3 Oct 2003 09:16:03 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h93GG4Gh009697; Fri, 3 Oct 2003 10:16:04 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h93GG4m9009696; Fri, 3 Oct 2003 10:16:04 -0600 (MDT) (envelope-from rousskov) Date: Fri, 3 Oct 2003 10:16:04 -0600 (MDT) From: Alex Rousskov To: "OPES WG (E-mail)" Subject: RE: Bypassing In-Reply-To: <87609AFB433BD5118D5E0002A52CD75407250728@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD75407250728@zcard0k6.ca.nortel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 3 Oct 2003, Abbie Barbir wrote: > > Not necessarily. For example, if I know that my ISP is logging all > > HTTP request bodies to be sent to FBI or a marketing agency, I > > want to tell my ISP to bypass that feature. An OPES-compliant ISP > > will honor my request if possible. > > I recommend that you change ISP or better move to another country. > This is not what we are asked to do here by the IAB. IMO, this is _exactly_ what IAB was (or should have been) concerned about: corrupted or misbehaving OPES intermediaries. Clearly, it is a matter of IAB RFC interpretation, but I would rather err on the safe side than narrow down IAB implications to a trivial case. Even today, content is being composed from dozens of sources and pieces. An all-or-nothing approach would more and more often mean "nothing". Not just will you strip the ad or weather info. You will not get the news page at all. The URI-based approach lets you get the page you want, with some missing information. > > True, except we cannot tell whether it is the first or any other > > OPES processor or callout service that will honor the bypass > > instruction. We should not tell an OPES system exactly how to > > implement bypass. > > It is clear from (3.3) it is client centric (It is the 1st OPES > processor that will get the request) While 3.3 indeed applies to content, it says nothing about the OPES side (client or server) or the OPES processor number. While it is the 1st OPES processor that will get the request, it may not be the 1st OPES processor that will know whether a non-OPES version is available. > > IAB is concerned about some minimal functionality. We can get a > > lot more, at about the same cost. We do follow what IAB 3.3 > > suggests, but we go further. > > U can if u have the time. I suggest that u do the minimum for now > and get the OCP/HTTP drafts done, otherwise, just packup and go > home. Agreed. That minimum, for me, is a URI-based interface with a wildcard option and appropriate defaults. > > > 3. Non-blocking MUST be Done in-band. > > > > Do you mean "and only in-band"? What does this requirement buy > > you? > > What I mean, just ride on tracing (one extra header all what we > need) Not sure I follow. Traces go in the opposite direction of bypass requests so you cannot reuse them for bypass. I am not suggesting that we specify an out-of-band mechanism, but I do not see any reason to prohibit one either. Alex. From owner-ietf-openproxy@mail.imc.org Fri Oct 3 12:48:14 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16221 for ; Fri, 3 Oct 2003 12:48:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5T6M-0003Zj-00 for opes-archive@ietf.org; Fri, 03 Oct 2003 12:48:22 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A5T6L-0003Zg-00 for opes-archive@ietf.org; Fri, 03 Oct 2003 12:48:21 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93GTkKP030621 for ; Fri, 3 Oct 2003 09:29:46 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h93GTkUi030620 for ietf-openproxy-bks; Fri, 3 Oct 2003 09:29:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zrtps0kp.nortelnetworks.com (zrtps0kp.nortelnetworks.com [47.140.192.56]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93GTjKP030614 for ; Fri, 3 Oct 2003 09:29:46 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h93GTX318356; Fri, 3 Oct 2003 12:29:34 -0400 (EDT) Received: from zrtpd0jh.us.nortel.com ([47.140.202.34]) by zrtpd0j7.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZYG6KJV; Fri, 3 Oct 2003 12:29:34 -0400 Received: by zrtpd0jh.us.nortel.com with Internet Mail Service (5.5.2653.19) id <41VAYQQ1>; Fri, 3 Oct 2003 12:29:34 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD75407250761@zcard0k6.ca.nortel.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Abbie Barbir" To: Alex Rousskov , "OPES WG (E-mail)" Subject: RE: Bypassing Date: Fri, 3 Oct 2003 12:29:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > IMO, this is _exactly_ what IAB was (or should have been) concerned > about: corrupted or misbehaving OPES intermediaries. Clearly, > it is a matter of IAB RFC interpretation, but I would rather > err on the safe side than narrow down IAB implications to a > trivial case. IAB used non-blocking as a means to find corrupted imtermediaries. > Even today, content is being composed from dozens of sources > and pieces. An all-or-nothing approach would more and more > often mean "nothing". Not just will you strip the ad or > weather info. You will not get the news page at all. The > URI-based approach lets you get the page you want, with some > missing information. So, what is the point. if non-blocking means nothing, then that is the non-opes version. > While 3.3 indeed applies to content, it says nothing about > the OPES side (client or server) or the OPES processor > number. While it is the 1st OPES processor that will get the > request, it may not be the 1st OPES processor that will know > whether a non-OPES version is available. > Design issue here. A system that requires you to go through 100 hops before determing that you have taken the wrong pass is not optimal. So simply, keep the non-blocking header in the flow until it reaches the first processor that is capapble of handeling it. > Agreed. That minimum, for me, is a URI-based interface with a > wildcard option and appropriate defaults. So what do u mean by a URI-based approach? Abbie > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Friday, October 03, 2003 12:16 PM > To: OPES WG (E-mail) > Subject: RE: Bypassing > > > On Fri, 3 Oct 2003, Abbie Barbir wrote: > > > > Not necessarily. For example, if I know that my ISP is > logging all > > > HTTP request bodies to be sent to FBI or a marketing > agency, I want > > > to tell my ISP to bypass that feature. An OPES-compliant ISP will > > > honor my request if possible. > > > > I recommend that you change ISP or better move to another country. > > This is not what we are asked to do here by the IAB. > > IMO, this is _exactly_ what IAB was (or should have been) concerned > about: corrupted or misbehaving OPES intermediaries. Clearly, > it is a matter of IAB RFC interpretation, but I would rather > err on the safe side than narrow down IAB implications to a > trivial case. > > Even today, content is being composed from dozens of sources > and pieces. An all-or-nothing approach would more and more > often mean "nothing". Not just will you strip the ad or > weather info. You will not get the news page at all. The > URI-based approach lets you get the page you want, with some > missing information. > > > > True, except we cannot tell whether it is the first or any other > > > OPES processor or callout service that will honor the bypass > > > instruction. We should not tell an OPES system exactly how to > > > implement bypass. > > > > It is clear from (3.3) it is client centric (It is the 1st OPES > > processor that will get the request) > > While 3.3 indeed applies to content, it says nothing about > the OPES side (client or server) or the OPES processor > number. While it is the 1st OPES processor that will get the > request, it may not be the 1st OPES processor that will know > whether a non-OPES version is available. > > > > IAB is concerned about some minimal functionality. We can > get a lot > > > more, at about the same cost. We do follow what IAB 3.3 suggests, > > > but we go further. > > > > U can if u have the time. I suggest that u do the minimum > for now and > > get the OCP/HTTP drafts done, otherwise, just packup and go home. > > Agreed. That minimum, for me, is a URI-based interface with a > wildcard option and appropriate defaults. > > > > > 3. Non-blocking MUST be Done in-band. > > > > > > Do you mean "and only in-band"? What does this > requirement buy you? > > > > What I mean, just ride on tracing (one extra header all what we > > need) > > Not sure I follow. Traces go in the opposite direction of > bypass requests so you cannot reuse them for bypass. I am not > suggesting that we specify an out-of-band mechanism, but I do > not see any reason to prohibit one either. > > Alex. > From owner-ietf-openproxy@mail.imc.org Fri Oct 3 13:24: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 NAA17321 for ; Fri, 3 Oct 2003 13:24:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Tfn-0003wV-00 for opes-archive@ietf.org; Fri, 03 Oct 2003 13:24:59 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A5Tfn-0003wS-00 for opes-archive@ietf.org; Fri, 03 Oct 2003 13:24:59 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93H6PKP032587 for ; Fri, 3 Oct 2003 10:06:25 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h93H6Puf032586 for ietf-openproxy-bks; Fri, 3 Oct 2003 10:06:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93H6NKP032581 for ; Fri, 3 Oct 2003 10:06:23 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h93H6OGh010792; Fri, 3 Oct 2003 11:06:24 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h93H6Ok3010791; Fri, 3 Oct 2003 11:06:24 -0600 (MDT) (envelope-from rousskov) Date: Fri, 3 Oct 2003 11:06:24 -0600 (MDT) From: Alex Rousskov To: "OPES WG (E-mail)" Subject: RE: Bypassing In-Reply-To: <87609AFB433BD5118D5E0002A52CD75407250761@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD75407250761@zcard0k6.ca.nortel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 3 Oct 2003, Abbie Barbir wrote: > IAB used non-blocking as a means to find corrupted imtermediaries. I disagree. In general, one cannot find corrupted intermediaries by any programmatic means. One can bypass corrupted imtermediaries, once they are found, using programmatic means such as bypass. IAB was concerned that if OPES intermediaries become ubiquitous, then corruption of a small number of unimportant services will lead to essential information being unavailable to Internet users (humans and machines). This is similar to the current wildcard DNS mess: Verisign does OPES-like transformations on DNS messages, but DNS does not have a bypass feature so many users (humans and machines) get "blocked". > > Even today, content is being composed from dozens of sources and > > pieces. An all-or-nothing approach would more and more often mean > > "nothing". Not just will you strip the ad or weather info. You > > will not get the news page at all. The URI-based approach lets you > > get the page you want, with some missing information. > > > So, what is the point. if non-blocking means nothing, then that is > the non-opes version. The point is that with a more flexible bypass interface you can bypass _corrupted_ intermediaries (and get the content rather than nothing). With a wildcard interface you can only bypass all intermediaries which will most likely leave you without any content or without bypass. BTW, this brings up an important question: What should an OPES system return if there is no non-OPES content and bypass was requested. IMO, it should return an error of some sorts rather than OPES content. Otherwise, it would be impossible to determine whether bypass was processed or ignored. Returning OPES content instead of an error would also make bypass a lot less effective: imagine a situation where a corrupted (but unimportant) portion of a web page (e.g., some ad applet) crashes your browser... > Design issue here. A system that requires you to go through 100 hops > before determing that you have taken the wrong pass is not optimal. It is not up to us to decide what is optimal in an OPES system. I can easily come up with a realistic case where checking for bypass at the first hop is actually much worse than checking at the 100th hop, especially if bypass instruction is an exception rather than a rule. > So simply, keep the non-blocking header in the flow until it reaches > the first processor that is capapble of handeling it. Even simpler and more general: bypass instruction semantics is end-to-end and not hop-by-hop (not all application protocols have headers AND just because a processor is capapble of handeling an instruction, does not mean it is authorized to remove it). > > Agreed. That minimum, for me, is a URI-based interface with a > > wildcard option and appropriate defaults. > > So what do u mean by a URI-based approach? Something along these lines, if you wish: A bypass instruction contains a URI that identifies an OPES entities or a group of OPES entities to be bypassed. An 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 entities). The recipient of a bypass instruction containing a URI that identifies a known-to-recipient OPES entity MUST ... The recipient of a bypass instruction containing a URI that identifies the recipient itself MUST ... The recipient of a bypass instruction with a URI that does not identify any known-to-recipient OPES entity MUST ... (treat that URI as a wildcard identifier?). Bypass instruction semantics is end-to-end and not hop-by-hop. The recipient MUST forward bypass instructions to the next application hop provided that next hop speaks application protocol with OPES bypass support. This requirement applies to all bypass instructions, including those that identify known-to-recipient entities. Application-specific bindings MUST map the above bypass mechanism to their application protocol. An explicit declaration of no bypass support is an acceptable mapping. HTH, Alex. From owner-ietf-openproxy@mail.imc.org Fri Oct 3 13:28:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17509 for ; Fri, 3 Oct 2003 13:28:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Tji-0003yn-00 for opes-archive@ietf.org; Fri, 03 Oct 2003 13:29:02 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A5Tjh-0003yk-00 for opes-archive@ietf.org; Fri, 03 Oct 2003 13:29:01 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93HAeKP032765 for ; Fri, 3 Oct 2003 10:10:40 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h93HAeCm032764 for ietf-openproxy-bks; Fri, 3 Oct 2003 10:10:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zrtps0kp.nortelnetworks.com (zrtps0kp.nortelnetworks.com [47.140.192.56]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93HAdKP032758 for ; Fri, 3 Oct 2003 10:10:40 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h93HAS329643; Fri, 3 Oct 2003 13:10:28 -0400 (EDT) Received: from zrtpd0jh.us.nortel.com ([47.140.202.34]) by zrtpd0j7.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZYG6SB6; Fri, 3 Oct 2003 13:10:29 -0400 Received: by zrtpd0jh.us.nortel.com with Internet Mail Service (5.5.2653.19) id <41VAYTSM>; Fri, 3 Oct 2003 13:10:29 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754072507C5@zcard0k6.ca.nortel.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Abbie Barbir" To: Alex Rousskov , "OPES WG (E-mail)" Subject: RE: Bypassing Date: Fri, 3 Oct 2003 13:10:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Tracing can be used to detremine if non-blocking was performed or not. abbie > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Friday, October 03, 2003 1:06 PM > To: OPES WG (E-mail) > Subject: RE: Bypassing > > > > On Fri, 3 Oct 2003, Abbie Barbir wrote: > > > IAB used non-blocking as a means to find corrupted imtermediaries. > > I disagree. In general, one cannot find corrupted > intermediaries by any programmatic means. One can bypass > corrupted imtermediaries, once they are found, using > programmatic means such as bypass. IAB was concerned that if > OPES intermediaries become ubiquitous, then corruption of a > small number of unimportant services will lead to essential > information being unavailable to Internet users (humans and machines). > > This is similar to the current wildcard DNS mess: Verisign > does OPES-like transformations on DNS messages, but DNS does > not have a bypass feature so many users (humans and machines) > get "blocked". > > > > Even today, content is being composed from dozens of sources and > > > pieces. An all-or-nothing approach would more and more often mean > > > "nothing". Not just will you strip the ad or weather > info. You will > > > not get the news page at all. The URI-based approach lets you get > > > the page you want, with some missing information. > > > > > > So, what is the point. if non-blocking means nothing, then > that is the > > non-opes version. > > The point is that with a more flexible bypass interface you > can bypass _corrupted_ intermediaries (and get the content > rather than nothing). With a wildcard interface you can only > bypass all intermediaries which will most likely leave you > without any content or without bypass. > > BTW, this brings up an important question: What should an > OPES system return if there is no non-OPES content and bypass > was requested. IMO, it should return an error of some sorts > rather than OPES content. Otherwise, it would be impossible > to determine whether bypass was processed or ignored. > Returning OPES content instead of an error would also make > bypass a lot less effective: imagine a situation where a > corrupted (but unimportant) portion of a web page (e.g., some ad > applet) crashes your browser... > > > Design issue here. A system that requires you to go through > 100 hops > > before determing that you have taken the wrong pass is not optimal. > > It is not up to us to decide what is optimal in an OPES > system. I can easily come up with a realistic case where > checking for bypass at the first hop is actually much worse > than checking at the 100th hop, especially if bypass > instruction is an exception rather than a rule. > > > So simply, keep the non-blocking header in the flow until > it reaches > > the first processor that is capapble of handeling it. > > Even simpler and more general: > > bypass instruction semantics is end-to-end and not hop-by-hop > > (not all application protocols have headers AND just because > a processor is capapble of handeling an instruction, does not > mean it is authorized to remove it). > > > > Agreed. That minimum, for me, is a URI-based interface with a > > > wildcard option and appropriate defaults. > > > > So what do u mean by a URI-based approach? > > Something along these lines, if you wish: > > A bypass instruction contains a URI that identifies an OPES > entities or a group of OPES entities to be bypassed. An > 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 entities). > > The recipient of a bypass instruction containing a URI > that identifies a known-to-recipient OPES entity MUST ... > > The recipient of a bypass instruction containing a URI > that identifies the recipient itself MUST ... > > The recipient of a bypass instruction with a URI that does > not identify any known-to-recipient OPES entity MUST ... > (treat that URI as a wildcard identifier?). > > Bypass instruction semantics is end-to-end and not > hop-by-hop. The recipient MUST forward bypass instructions to > the next application hop provided that next hop speaks > application protocol with OPES bypass support. This > requirement applies to all bypass instructions, including > those that identify known-to-recipient entities. > > Application-specific bindings MUST map the above bypass > mechanism to their application protocol. An explicit > declaration of no bypass support is an acceptable mapping. > > > HTH, > > Alex. > From owner-ietf-openproxy@mail.imc.org Fri Oct 3 13:33:09 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17649 for ; Fri, 3 Oct 2003 13:33:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Tnn-00041c-00 for opes-archive@ietf.org; Fri, 03 Oct 2003 13:33:15 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A5Tnm-00041Z-00 for opes-archive@ietf.org; Fri, 03 Oct 2003 13:33:15 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93HIXKP033605 for ; Fri, 3 Oct 2003 10:18:33 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h93HIXGw033604 for ietf-openproxy-bks; Fri, 3 Oct 2003 10:18:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93HIVKP033599 for ; Fri, 3 Oct 2003 10:18:31 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h93HIWGh011038; Fri, 3 Oct 2003 11:18:32 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h93HIWTF011037; Fri, 3 Oct 2003 11:18:32 -0600 (MDT) (envelope-from rousskov) Date: Fri, 3 Oct 2003 11:18:32 -0600 (MDT) From: Alex Rousskov To: Abbie Barbir cc: "OPES WG (E-mail)" Subject: RE: Bypassing In-Reply-To: <87609AFB433BD5118D5E0002A52CD754072507C5@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD754072507C5@zcard0k6.ca.nortel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 3 Oct 2003, Abbie Barbir wrote: > Tracing can be used to detremine if non-blocking was performed or not. Not exactly (depending on what you mean by "perform"). Tracing can be used to determine whether OPES is still in the loop. The trace does not tell you whether bypass was considered but no non-OPES version of the content was available (and so you should stop trying) or whether bypass instruction was ignored (and so you might be lucky if you try again, perhaps using a different path through OPES). This is an important distinction to document. I do not know whether it is important enough for us to require that the trace includes "I tried but could not bypass" info. Alex. From owner-ietf-openproxy@mail.imc.org Fri Oct 3 13:36:08 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17757 for ; Fri, 3 Oct 2003 13:36:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Tqg-00043E-00 for opes-archive@ietf.org; Fri, 03 Oct 2003 13:36:14 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A5Tqf-00043B-00 for opes-archive@ietf.org; Fri, 03 Oct 2003 13:36:13 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93HLAKP033743 for ; Fri, 3 Oct 2003 10:21:10 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h93HLAUK033742 for ietf-openproxy-bks; Fri, 3 Oct 2003 10:21:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zrtps0kn.nortelnetworks.com (zrtps0kn.nortelnetworks.com [47.140.192.55]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93HL8KP033733 for ; Fri, 3 Oct 2003 10:21:09 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h93HKvL19243; Fri, 3 Oct 2003 13:20:57 -0400 (EDT) Received: from zrtpd0jh.us.nortel.com ([47.140.202.34]) by zrtpd0jn.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T9HC396W; Fri, 3 Oct 2003 13:20:57 -0400 Received: by zrtpd0jh.us.nortel.com with Internet Mail Service (5.5.2653.19) id <41VAY432>; Fri, 3 Oct 2003 13:20:57 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754072507E9@zcard0k6.ca.nortel.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Abbie Barbir" To: Alex Rousskov Cc: "OPES WG (E-mail)" Subject: RE: Bypassing Date: Fri, 3 Oct 2003 13:20:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Yes, the loop u r righ good point abbie > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Friday, October 03, 2003 1:19 PM > To: Barbir, Abbie [CAR:1A11:EXCH] > Cc: OPES WG (E-mail) > Subject: RE: Bypassing > > > > On Fri, 3 Oct 2003, Abbie Barbir wrote: > > > Tracing can be used to detremine if non-blocking was > performed or not. > > Not exactly (depending on what you mean by "perform"). > Tracing can be used to determine whether OPES is still in the > loop. The trace does not tell you whether bypass was > considered but no non-OPES version of the content was > available (and so you should stop trying) or whether bypass > instruction was ignored (and so you might be lucky if you try > again, perhaps using a different path through OPES). > > This is an important distinction to document. I do not know > whether it is important enough for us to require that the > trace includes "I tried but could not bypass" info. > > Alex. > > From owner-ietf-openproxy@mail.imc.org Fri Oct 3 14:33:11 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19611 for ; Fri, 3 Oct 2003 14:33:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Ujt-0004bY-00 for opes-archive@ietf.org; Fri, 03 Oct 2003 14:33:18 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A5Ujt-0004bV-00 for opes-archive@ietf.org; Fri, 03 Oct 2003 14:33:17 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93IHCKP036298 for ; Fri, 3 Oct 2003 11:17:12 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h93IHCeL036297 for ietf-openproxy-bks; Fri, 3 Oct 2003 11:17:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93IHBKP036292 for ; Fri, 3 Oct 2003 11:17:11 -0700 (PDT) (envelope-from markus@mhof.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id h93IHCkE029216 for ; Fri, 3 Oct 2003 14:17:12 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h93IH60C073531 for ; Fri, 3 Oct 2003 14:17:06 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h93IH5FU022170 for ; Fri, 3 Oct 2003 14:17:05 -0400 (EDT) Message-ID: <3F7DBD8B.90100@mhof.com> Date: Fri, 03 Oct 2003 14:18:51 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: "OPES WG (E-mail)" Subject: Re: Bypassing References: <87609AFB433BD5118D5E0002A52CD754071ECC1E@zcard0k6.ca.nortel.com> <3F7D8B73.4030105@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: > We do not have to specify all classes or _any_ classes. I suggest that > we specify a URI-based interface (with a wildcard) and specify > appropriate defaults for implementations that do not understand the > meaning of a given URI. Others may use our interface and specify URI > meanings. That's fine, as long as we don't have pre-defined classes. >>If a user requests non-blocking, OPES processor needs to determine >>whether a "non-OPES" version is available. If yes, this version will >>have to be served. If not, either an error is returned or the OPES >>version is served. > > > Agreed. I actually start believeing that an error should be returned in the latter case... >>Couldn't we go that far and say that requests with non-blocking flag >>are always being forwarded to the origin server. > > > Not in general. (a) A request may need to be modified for non-OPES > content to be served by the OPES-unaware server (e.g., a particular > header or parameter may need to be added by an OPES processor). Agreed, good point. >>Now, when an error comes back (because there's no non-OPES version), >>we could either leave it to the user to remove the non-blocking flag >>(if wanted), or invoke the OPES service and serve the OPES version. > > > A user usually does not have control over low-level information such > as HTTP headers. The bypass has to be implemented entirely within the > OPES system (or it is not a bypass). First of all, someone needs to articulate the desire to bypass OPES, and this someone I would expect is the user. And I would assume that this could be done, for example, similar to the "hard reload" feature of Web browsers. When I hit CTRL-F% in my IE, it adds an "no-cache" header to the outgoing HTTTP request. -Markus From owner-ietf-openproxy@mail.imc.org Sat Oct 4 10:32:06 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07067 for ; Sat, 4 Oct 2003 10:32:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5nSA-0000bC-00 for opes-archive@ietf.org; Sat, 04 Oct 2003 10:32:14 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A5nS9-0000b8-00 for opes-archive@ietf.org; Sat, 04 Oct 2003 10:32:13 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h94EEvKP035691 for ; Sat, 4 Oct 2003 07:14:57 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h94EEvIr035690 for ietf-openproxy-bks; Sat, 4 Oct 2003 07:14:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zrtps0kn.nortelnetworks.com (zrtps0kn.nortelnetworks.com [47.140.192.55]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h94EEtKP035684 for ; Sat, 4 Oct 2003 07:14:56 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h94EEIW22408; Sat, 4 Oct 2003 10:14:18 -0400 (EDT) Received: from zrtpd0jh.us.nortel.com ([47.140.202.34]) by zrtpd0j7.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZYG9G9X; Sat, 4 Oct 2003 10:14:19 -0400 Received: by zrtpd0jh.us.nortel.com with Internet Mail Service (5.5.2653.19) id <41VAZQM4>; Sat, 4 Oct 2003 10:14:18 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD75407250B31@zcard0k6.ca.nortel.com> X-Sybari-Trust: 7d1655d1 aee23e9e 3fcd0116 00000104 From: "Abbie Barbir" To: "'internet-drafts@ietf.org'" Cc: ietf-openproxy@imc.org, "Abbie Barbir" , Markus Hofmann Subject: Request to publish :draft-ietf-opes-end-comm-03 Date: Sat, 4 Oct 2003 10:14:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C38A81.CA34A38C" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C38A81.CA34A38C Content-Type: text/plain Please publish the following draft-ietf-opes-end-comm-03 as a WG Draft. Thanks Abbie ------_=_NextPart_000_01C38A81.CA34A38C Content-Type: text/plain; name="draft-ietf-opes-end-comm-03.txt" Content-Disposition: attachment; filename="draft-ietf-opes-end-comm-03.txt" Content-Transfer-Encoding: quoted-printable Network Working Group A. = Barbir Internet-Draft Nortel = Networks Expires: April 3, 2004 October 4, = 2003 OPES processor and end points communications draft-ietf-opes-end-comm-03 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that = other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six = months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 3, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This memo documents tracing and non-blocking requirements for Open Pluggable Edge Services (OPES). Barbir Expires April 3, 2004 [Page = 1] =0C Internet-Draft OPES processor and end points communications = October 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . = 3 2. OPES System . . . . . . . . . . . . . . . . . . . . . . . . . = 4 3. Requirements for OPES Tracing . . . . . . . . . . . . . . . . = 5 3.1 What is traceable in an OPES Flow? . . . . . . . . . . . . . . = 5 3.2 Requirements for Information Related to Traceable Entities . . = 6 3.3 Requirements for OPES processors . . . . . . . . . . . . . . . = 7 3.4 Requirements for callout servers . . . . . . . . . . . . . . . = 7 3.5 Protocol Binding . . . . . . . . . . . . . . . . . . . . . . . = 8 4. Non-Blocking . . . . . . . . . . . . . . . . . . . . . . . . . = 9 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . = 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . = 13 Normative References . . . . . . . . . . . . . . . . . . . . . = 14 Informative References . . . . . . . . . . . . . . . . . . . . = 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . = 15 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . = 16 Intellectual Property and Copyright Statements . . . . . . . . = 17 Barbir Expires April 3, 2004 [Page = 2] =0C Internet-Draft OPES processor and end points communications = October 2003 1. Introduction The Open Pluggable Edge Services (OPES) architecture [8] enables cooperative application services (OPES services) between a data provider, a data consumer, and zero or more OPES processors. The application services under consideration analyze and possibly transform application-level messages exchanged between the data provider and the data consumer. This work specify the requirements for providing tracing functionality for the OPES architecture [8]. Tracing functionality enables a data provider application to detect inappropriate actions that are performed by OPES entities. The work also develops requirements that can be used to fulfill IAB Notification and Non-Blocking requirements [2]. The architecture document requires [8] that tracing be 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 is 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. = However, the architecture does not prevent implementers of developing out-of-band protocols and techniques to address these limitation. Barbir Expires April 3, 2004 [Page = 3] =0C Internet-Draft OPES processor and end points communications = October 2003 2. OPES System This sections provides a definition of OPES System. This is needed = in order to define what is traceable in an OPES Flow. Definition: An OPES System is a set of all OPES entities authorized by either the data provider or the data consumer application to process a given application message. The nature of the authorization agreement determines if authority delegation is transitive (meaning an authorized entities is authorized to include other entities). Transitive authority delegation is common in information systems. If specific authority agreements allow for re-delegation, an OPES system can be formed by induction. In this case, an OPES system starts with entities directly authorized by a data provider (or a data consumer) application. The OPES system then includes any OPES entity authorized by an entity that is already in the OPES system. The authority delegation is always viewed in the context of a given application message. An OPES System is defined on an application message basis. Having an authority to process a message does not imply being involved in message processing. Thus, some OPES system members may not participate in processing of a message. Similarly, some members may process the same message several times. The above definition implies that there can be no more than one OPES system processing a single message at a given time. This is based on the assumption that there is a single data provider and a single = data consumer as far as a given application message is concerned. For example, consider a Content Delivery Network (CDN) delivering an image on behalf of a busy web site. OPES processors and services = that the CDN uses to adapt and deliver the message comprise an OPES system. In a more complex example, an OPES System would contain CDN entries as well as 3rd-party OPES entities that CDN engages to perform adaptations (e.g., to adjust image quality). Barbir Expires April 3, 2004 [Page = 4] =0C Internet-Draft OPES processor and end points communications = October 2003 3. Requirements for OPES Tracing In an OPES System tracing is defined as the inclusion of necessary information within a message in an OPES Flow that identify the set = 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. In an OPES System tracing is performed on per message basis. Trace format is dependent on the application protocol that is being = adapted by OPES. 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 authorized OPES services that were performed by OPES entities in an OPES System. Providing tracing information, MUST take into account the following considerations: o Providers may be hesitant to reveal information about their internal network infrastructure. o Within a service provider network, OPES processors may be configured to use non-routable, private IP addresses. o A Data consumer applications would prefer to have a single point of contact regarding the trace information. 3.1 What is traceable in an OPES Flow? This section focuses on identifying traceable entities in an OPES Flow. Tracing information provides a data consumer application (or a data provider application) with useful information without tracing the exact OPES Processor or callout servers that adapted the data. For example, some OPES services are message-agnostic and operate on message content or parts of a message. Such services cannot manipulate message headers. Hence, a data consumer application would be interested in knowing that a translation service on the message content was performed. It does not need to know the exact entity = that has performed the service. 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 be able to see a trace entry, but does not need to be able to interpret it beyond Barbir Expires April 3, 2004 [Page = 5] =0C Internet-Draft OPES processor and end points communications = October 2003 identification of the OPES System. Second, the OPES System administrator is expected to be able to interpret the contents of an OPES trace. The trace can be provided = by an end (data consumer or provider) as an opaque string. The administrator can use the trace information to identify the participating OPES processor(s). The administrator can use the trace to identify the applied adaptation services along with other message-specific information. Since the administrators of various OPES Systems can have various ways of looking into tracing, they MAY require the choice of freedom in what to put in trace records and how to format them. Trace = records should be easy to extend beyond basic OPES requirements. Trace management algorithms should treat trace records as opaque data to the extent possible. 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. OPES entities have different levels of traceability requirements. Specifically, o An OPES system MUST add its entry to the trace. o An OPES processor SHOULD add its entry to the trace. o An OPES service May add its entry to the trace. o An OPES entity MAY manage trace information from entities that = are under its control. For example, an OPES processor may add or remove callout service entries in order to manage the size of a trace. From an OPES context, a good tracing approach is similar to a = trouble ticket ready for submission to a known address. The address is printed on the ticket. The trace in itself is not necessarily a detailed description of what has happened. It is the responsibility of the operator to resolve the problems. 3.2 Requirements for Information Related to Traceable Entities The following MUST requirements apply for information as related to entities that are traceable in an OPES flow: o Identification of the OPES System privacy policy at the time it dealt with the message. Barbir Expires April 3, 2004 [Page = 6] =0C Internet-Draft OPES processor and end points communications = October 2003 o Identification of the party responsible for setting and enforcing that policy. o Information pointing to a technical contact. o Information that identifies, to the technical contact, the OPES processors involved in processing the message. 3.3 Requirements for OPES processors The requirements for OPES processors that are applicable to tracing are: o Each OPES processor MUST be uniquely identified in an OPES = System. o Each OPES processor MUST support tracing, policy can be used to turn tracing on and to determine its granularity. o If tracing is turned on, then the OPES processor MUST add its identification to the trace. o OPES processor SHOULD be able to trace it's own invocation and service(s) execution since it understands the application protocol. To fulfill this: * An OPES processor MAY have a fixed configuration that enable = it to respond to tracing inquires. For example, entity X performs service Y and so on. * An OPES processor MAY package tracing information related to the entities that it control based on the policy of a given OPES System. For example, the trace may state that service W was performed. The OPES processor knows that service W is composed of services X, Y and Z in a given order o An OPES processor SHOULD add to the trace identification of every callout service that processed the application message. o An OPES processor MAY delegate trace management to a callout service within the same OPES System. 3.4 Requirements for callout servers 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 Barbir Expires April 3, 2004 [Page = 7] =0C Internet-Draft OPES processor and end points communications = October 2003 should be done under the control of the OPES System provider. 3.5 Protocol Binding The task of adding tracing information is application protocol specific. Separate documents will address HTTP and other protocols. This work documents what tracing information is required and some common tracing elements. Barbir Expires April 3, 2004 [Page = 8] =0C Internet-Draft OPES processor and end points communications = October 2003 4. Non-Blocking In [9] recommendation addresses the issue of non-blocking in an OPES System. The recommendation is restated below for ease of reference. (3.3) Non-blocking: If there exists a non-OPES version of content available from the content provider, the OPES architecture must not prevent users from retrieving this non-OPES version from the content provider. The IAB recommendation implies that it is up to the content provider to make non-OPES versions of a given content available. The actual meaning of non-OPES version of the content depended on the agreement between the OPES provider and the content provider. The agreement = can allow OPES to perform some services (such as logging services) and prevent it from performing other services (such as data to audio transformation). Whether an OPES System honor a non-blocking request from a data consumer application (user) can also be a function of deployment. Consider the case where Company A has as contract with an OPES provider to perform virus checking on all e-mail attachments. An employee X of Company A can issue a non-blocking request for the virus scanning service. However, the request could be ignored by the OPES provider since it contradicts its agreement with Company A. As a second example, a user may issue a non-blocking request for adult content, this request may be declined by the OPES provider simply because it contradicts its internal policy or its agreement with the end subscriber. In some cases, a data consumer application will issue a non-blocking request since it suspects that the OPES System is corrupting the data. For example, an OPES entity has determined that a Virus is present in an attachment, while the user is aware that some versions of virus scanners will make that mistake. In this case, the user can use the non-blocking technique (can be used in combination with the tracing facility) to solve the problem. However, whether the OPES System will honor the non-blocking request or not is still a = function of the deployment scenario, content availability and related policies. Like tracing, Non-blocking operates on per application message = bases. Non-Blocking is an end-end operation as opposed to a hop-by-hop operation. Non-blocking requests are generally client centric and go in the opposite direction of tracing requests. Non-blocking can be performed out of band or in-band. This work requires non-blocking to be performed in-band as an extension to an application specific protocol. Non-OPES entities should be able to safely ignore the Barbir Expires April 3, 2004 [Page = 9] =0C Internet-Draft OPES processor and end points communications = October 2003 extensions. The work does not prevent OPES Systems from developing their own out of band protocols. Non-blocking format is dependent on the application protocol that is being adapted by OPES. 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 processor that is calling the service(s) to handle the non-blocking request. In some cases, the first OPES processor that will get the non-blocking request may not be the = first OPES processor that will know whether a non-OPES version of the content is available or not. In an OPES System, the OPES provider is expected to configure at least one OPES processor to process a non-blocking header based on content availability and related policies. In this case the OPES processor is expected to determine the set of services that will be bypassed (or those services that will be performed) or whether the request should be forwarded directly to the data provider = application (origin content provider). Although, IAB recommendation (3.3) has intended for non-blocking approach to be used as a vehicle to bypass faulty OPES intermediaries. However, this work recognizes that the same = technique can be used to enable a data consumer application to select the set of services that it would like to be bypassed for a given = application message. For this reason, a non-blocking 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. An 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). This version of the work requires that all non-blocking instructions to use the wildcard approach. For example, an application level protocol (such as HTTP) can be extended to include the following OPES non-blocking related header: OPES-Bypass: * The following requirements apply for non-blocking feature: o An OPES System MUST support the non-blocking feature for requests of non-OPES content for a given application message. o An OPES System MUST treat the non-blocking feature as an end-to-end operation. Barbir Expires April 3, 2004 [Page = 10] =0C Internet-Draft OPES processor and end points communications = October 2003 * This means that there MUST be at least one OPES processor in = an OPES System that knows how to interpret and process the non-blocking feature. * The recipient MUST forward the bypass instructions to the next application hop provided that the next hop speaks application protocol with OPES bypass support. * This requirement applies to all bypass instructions, including those that identify known-to-recipient entities. o Application-specific bindings MUST map the above non-blocking mechanism to their application protocol. End users may not be able to know if their non-blocking request was honored or not by the OPES System. In this case, it would be beneficial if tracing can provide additional information regarding whether a non-blocking request was honored or not. For this reason, the following requirement also apply to the tracing facility: o An OPES System SHOULD assist the data consumer application in determining if a non-blocking request was performed by the = system. Assistance is viewed as the addition of information about services that were skipped and those that could not be bypassed. Barbir Expires April 3, 2004 [Page = 11] =0C Internet-Draft OPES processor and end points communications = October 2003 5. IANA considerations This work does not require any IANA consideration since any actions will be addressed in [6]. Barbir Expires April 3, 2004 [Page = 12] =0C Internet-Draft OPES processor and end points communications = October 2003 6. Security Considerations The security considerations for OPES are documented in [7]. This document is a requirement document for tracing and non-blocking and as such does not develop any new protocols that require security considerations. Barbir Expires April 3, 2004 [Page = 13] =0C Internet-Draft OPES processor and end points communications = October 2003 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. [2] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002. [3] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [4] A. Barbir et al., "Policy, Authorization and Enforcement Requirements of OPES", Internet-Draft http://www.ietf.org/ internet-drafts/draft-ietf-opes-authorization-02.txt, February 2003. [5] Rousskov, A., "OPES Callout Protocol Core", Internet-Draft http://www.ietf.org/internet-drafts/ draft-ietf-opes-ocp-core-01.txt, August 2003. [6] Rousskov, A., "HTTP adaptation with OPES", Internet-Draft TBD, September 2003. [7] A. Barbir et al., "Security Threats and Risks for Open = Pluggable Edge Services", Internet-Draft http://www.ietf.org/ internet-drafts/draft-ietf-opes-threats-02.txt, February 2003. [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. [9] A. Barbir et al., "OPES Treatment of IAB Considerations", Internet-Draft http://www.ietf.org/internet-drafts/ draft-ietf-opes-iab-01.txt, February 2004. Barbir Expires April 3, 2004 [Page = 14] =0C Internet-Draft OPES processor and end points communications = October 2003 Informative References [10] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and = S. Waldbusser, "Terminology for Policy-Based Management", RFC 3198, November 2001. [11] L. Cranor, et. al, "The Platform for Privacy Preferences 1.0 (P3P1.0) Specification", W3C Recommendation 16 http:// www.w3.org/TR/2002/REC-P3P-20020416/ , April 2002. Author's Address Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean, Ontario K2H 8E9 Canada Phone: +1 613 763 5229 EMail: abbieb@nortelnetworks.com Barbir Expires April 3, 2004 [Page = 15] =0C Internet-Draft OPES processor and end points communications = October 2003 Appendix A. Acknowledgements Several people has contributed to this work. Many thanks to: Alex Rousskov, Hilarie Orman, Oscar Batuner, Markus Huffman, Martin Stecher, Marshall Rose and Reinaldo Penno. Barbir Expires April 3, 2004 [Page = 16] =0C Internet-Draft OPES processor and end points communications = October 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances = of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification = can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph = are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Barbir Expires April 3, 2004 [Page = 17] =0C Internet-Draft OPES processor and end points communications = October 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Barbir Expires April 3, 2004 [Page = 18] =0C ------_=_NextPart_000_01C38A81.CA34A38C-- From owner-ietf-openproxy@mail.imc.org Mon Oct 6 00:21: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 AAA04980 for ; Mon, 6 Oct 2003 00:21:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6MsV-0000c7-00 for opes-archive@ietf.org; Mon, 06 Oct 2003 00:21:47 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A6MsU-0000c3-00 for opes-archive@ietf.org; Mon, 06 Oct 2003 00:21:46 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h9646WKP063183 for ; Sun, 5 Oct 2003 21:06:32 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h9646Wx0063181 for ietf-openproxy-bks; Sun, 5 Oct 2003 21:06:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h9646UKP063175 for ; Sun, 5 Oct 2003 21:06:31 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h9646VGh097351; Sun, 5 Oct 2003 22:06:31 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9646LAv097350; Sun, 5 Oct 2003 22:06:21 -0600 (MDT) (envelope-from rousskov) Date: Sun, 5 Oct 2003 22:06:21 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: Feedback on draft-ietf-opes-end-comm-03 In-Reply-To: <87609AFB433BD5118D5E0002A52CD75407250B31@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD75407250B31@zcard0k6.ca.nortel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Abbie, Here are my comments about version 03 of the Communications draft you submitted for publication this weekend. Your original text is ">" quoted. My comments are in square [brackets]. Suggested replacement text is not. Thank you, Alex. > OPES processor and end points communications > draft-ietf-opes-end-comm-03 [Since the draft also contains requirements for callout services and OPES systems, it would be more appropriate to title it] OPES entities and end points communication [No change in filename is required.] > This work specify the requirements for providing tracing > functionality for the OPES architecture [8]. ... specifies ... (?) > Tracing functionality > enables a data provider application to detect inappropriate actions > that are performed by OPES entities. ... enables a data provider or consumer application to ... [Also, tracing cannot be used to detect actions, it can only be used to detect intermediaries] > The architecture document requires [8] that tracing be supported ... 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 > is also dependent on the choice of the application level protocol ... are also dependent (?) > For these reasons, this work documents requirements for application > protocols that need to support OPES traces and non-blocking. [Non-blocking is not a noun, right? If you insist on using that expression as a noun, I would suggest to always append "feature" or "mechanism" to make the sentences appear more grammatically correct. Note that IAB RFC never uses non-blocking as a noun. In fact, IAB never uses "blocking" in any sentence! The non-word is only used as a label. This, and other reasons I have already mentioned, make me feel that we should not be using this non-word for anything other than referring to IAB consideration by label. If you disagree, let's at least make the sentences grammatically correct. If non-blocking is indeed a perfectly valid noun, please ignore my grammar-related comments (with apologies).] > However, > the architecture does not prevent implementers of developing > out-of-band protocols and techniques to address these limitation. > Definition: An OPES System is a set of all OPES entities authorized > by either the data provider or the data consumer application to > process a given application message. > The nature of the authorization agreement determines if authority > delegation is transitive (meaning an authorized entities is ... an authorized entity is > The above definition implies that there can be no more than one OPES > system processing a single message at a given time. ... no more than two OPES systems (?) [Client-side and server-side OPES systems can process the same message at the same time] ... processing the same message at a given time. or ... processing the given message at a given time. > For example, consider a Content Delivery Network (CDN) delivering an > image on behalf of a busy web site. OPES processors and services that > the CDN uses to adapt and deliver the message comprise an OPES > system. In a more complex example, an OPES System would contain CDN [Please capitalize System in "OPES System" consistently throughout the text] > In an OPES System tracing is performed on per message basis. Trace > format is dependent on the application protocol that is being adapted > by OPES. A Data consumer application can use OPES trace to infer the A data ... > actions that have been performed by the OPES system. Actions are the > set of authorized OPES services that were performed by OPES entities > in an OPES System. ... set of OPES services that ... [The trace is no guarantee or even an indication of authorization ] > Providing tracing information, MUST take into account the following > considerations: [Missing compliance subject/noun] > o Providers may be hesitant to reveal information about their > internal network infrastructure. > o Within a service provider network, OPES processors may be > configured to use non-routable, private IP addresses. > o A Data consumer applications would prefer to have a single point > of contact regarding the trace information. [It is not clear to a reader what tracing properties these considerations affect. In other words, how to take them into account? Looks like some context is missing here] > 3.1 What is traceable in an OPES Flow? > This section focuses on identifying traceable entities in an OPES > Flow. > Tracing information provides a data consumer application (or a data > provider application) with useful information without tracing the ... with information ... > exact OPES Processor or callout servers that adapted the data. [But often exact OPES Processor or callout servers are traced! Missing "for example" or "may" somewhere above?] > For > example, some OPES services are message-agnostic and operate on > message content or parts of a message. Such services cannot > manipulate message headers. Hence, a data consumer application would > be interested in knowing that a translation service on the message > content was performed. [The first ("for example") and the second ("hence") sentences seem unrelated to me. Why "hence"?] > It does not need to know the exact entity that > has performed the service. [Unless it wants to bypass that exact entity?] [Overall, it is not clear what all the text above from "without tracing" to "has performed the service" is trying to accomplish] > 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 be able to see a > trace entry, but does not need to be able to interpret it beyond > identification of the OPES System. > Second, the OPES System administrator is expected to be able to > interpret the contents of an OPES trace. The trace can be provided by > an end (data consumer or provider) as an opaque string. ... can be relayed to the administrator by an end (data consumer or provider) without interpretation, as opaque data (e.g., a TCP packet or an HTTP message snapshot). > Since the administrators of various OPES Systems can have various > ways of looking into tracing, they MAY require the choice of freedom > in what to put in trace records and how to format them. ... they require freedom in ... [this should not be a compliance requirement because we are not in business of certifying administrators; so no MAY] > 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. [Are these shoulds SHOULDs? Rephrase or capitalize them.] [Also, the second should is out of scope in this section The first one may be out of scope as well unless "extensibility" means adding info on new entities that can be traced"]. > At the implementation level, for a given trace, an OPES entity For a given trace, ... > involved in handling the corresponding application message is > traceable or traced if information about it appears in that trace. > OPES entities have different levels of traceability requirements. > Specifically, [Is OPES system an OPES entity? Please define OPES entity somewhere. You can say, for example, that OPES entity is OPES processor or callout server, and that we also treat OPES system as OPES entity where that does not lead to conflicts (e.g., we do not do that when we define an OPES System).] > o An OPES system MUST add its entry to the trace. > o An OPES processor SHOULD add its entry to the trace. > o An OPES service May add its entry to the trace. ... MAY ... [Why are the above three rules here? Don't they belong to corresponding "Requirements for XXX" sections?] > o An OPES entity MAY manage trace information from entities that are > under its control. For example, an OPES processor may add or > remove callout service entries in order to manage the size of a > trace. [Since OPES System is not something that can "add entries" on its own, how about adding something like: 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). ] [We also must address the ordering here. Are trace entries ordered?] [We also must specify whether a trace is a set or collection: if an OPES processor is involved twice on the message path, should it trace itself twice?] > From an OPES context, a good tracing approach is similar to a trouble In an OPES context, ... (?) > 3.2 Requirements for Information Related to Traceable Entities 3.2 Information required in a trace > The following MUST requirements apply for information as related to > entities that are traceable in an OPES flow: [Delete the above sentence. It is too awkward and complex] > o Identification of the OPES System privacy policy at the time it > dealt with the message. OPES System MUST include information about its privacy policy. [Note that we would need to say how that information can be included without making the trace too large. For example, we can say that it is sufficient to provide a URL to the OPES System web page that has links to privacy and other policies.] > o Identification of the party responsible for setting and enforcing > that policy. [Same note as above] > o Information pointing to a technical contact. [Same note as above] > o Information that identifies, to the technical contact, the OPES > processors involved in processing the message. OPES processors MUST include their identification. [Now, if you look at the above, this section is really a "Requirements for OPES Systems" section, with the exception of the last MUST that belong to the "Requirements for OPES processors" below! I would rename/move/rephrase accordingly.] > 3.3 Requirements for OPES processors > The requirements for OPES processors that are applicable to tracing > are: Tracing requirements for OPES processors are: > o Each OPES processor MUST be uniquely identified in an OPES System. [Remove the above. Since processor tracing is a SHOULD, there is no reason to have a MUST concerning processor IDs] > o Each OPES processor MUST support tracing, policy can be used to > turn tracing on and to determine its granularity. [Remove the above. It makes not practical sense. If a particular policy says "turn tracing off", and a particular processor implementation is based exclusively on that policy, that implementation should not be forced to "support" tracing. Processor tracing is a SHOULD.] > o If tracing is turned on, then the OPES processor MUST add its > identification to the trace. OPES processor SHOULD add its unique identification to the trace. Here, uniqueness scope is the OPES System containing the processor. [Another trouble to address: What if a client-side OPES System and a server-side OPES System share a processor? For example, a server is translating from British English to American based on client IP address and a client (a Briton temporary in the US) is translating back to British English, using the same well-known OPES processor (but under a different contract, of course). We should make sure that OPES processor includes two unique IDs in this scenario so it would be clear that two translations were made and so that one can be bypassed if buggy. I am not sure the above rules address this kind of sharing.] > o OPES processor SHOULD be able to trace it's own invocation and > service(s) execution since it understands the application > protocol. [How is that different from the above rule? Do you mean to add a rule that requires processor to trace its services?] > To fulfill this: [Fulfill what?] > * An OPES processor MAY have a fixed configuration that enable it > to respond to tracing inquires. For example, entity X performs > service Y and so on. [It is unclear to me what this rule is trying to accomplish. Of course, processor can have fixed configurations. Why are we suddenly talking about "tracing inquires"??] > * An OPES processor MAY package tracing information related to > the entities that it control based on the policy of a given > OPES System. For example, the trace may state that service W > was performed. The OPES processor knows that service W is > composed of services X, Y and Z in a given order [Isn't that already covered in "An OPES entity MAY manage trace information" rule?] > o An OPES processor SHOULD add to the trace identification of every > callout service that processed the application message. [What if the service identified itself already?] > o An OPES processor MAY delegate trace management to a callout > service within the same OPES System. [That should be covered by "An OPES entity MAY manage trace information" rule in the revised version above] > 3.4 Requirements for callout servers > 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. [Isn't everything in an OPES System done under the control of the OPES System provider?] > 3.5 Protocol Binding [Should this section follow the Non-blocking section and be not so tracing-specific? Bindings are equally needed for tracing and bypass features...] > The task of adding tracing information is application protocol > specific. The task of encoding tracing information is ... > Separate documents will address HTTP and other protocols. > This work documents what tracing information is required and some > common tracing elements. [Remove the above sentence because it is both quite imprecise and unnecessary here?] > 4. Non-Blocking [I find it strange that the layout of this section is not the same as the layout of the Tracing section. We seem to be talking about very similar things in both sections, but the Tracing section is much better organized.] > In [9] recommendation addresses the issue of non-blocking in an OPES > System. The recommendation is restated below for ease of reference. > (3.3) Non-blocking: If there exists a non-OPES version of content > available from the content provider, the OPES architecture must > not prevent users from retrieving this non-OPES version from the > content provider. > The IAB recommendation implies that it is up to the content provider > to make non-OPES versions of a given content available. [IAB consideration is not (should not be) the motivation or reason to support bypass. Let's leave addressing of IAB considerations to the IAB Treatment draft. We can simply state that bypass is necessary to prevent [malfunctioning] intermediaries from blocking the way to non-OPES content.] > The actual > meaning of non-OPES version of the content depended on the agreement > between the OPES provider and the content provider. The agreement can > allow OPES to perform some services (such as logging services) and > prevent it from performing other services (such as data to audio > transformation). [Two things seem to be mixed here: It is not clear whether the above paragraph explains that data provider can prohibit certain services OR whether the above paragraph asserts that definition of "non-OPES" is provider-dependent and may include content adapted by OPES.] > Whether an OPES System honor a non-blocking request from a data > consumer application (user) can also be a function of deployment. > Consider the case where Company A has as contract with an OPES > provider to perform virus checking on all e-mail attachments. An > employee X of Company A can issue a non-blocking request for the > virus scanning service. However, the request could be ignored by the > OPES provider since it contradicts its agreement with Company A. [Can we say that the above example is an example of "no non-OPES content available" (and, hence, the above OPES System does not violate any OPES rules)? Or are you implying that the OPES System above is violating OPES rules by ignoring user bypass request?] > As > a second example, a user may issue a non-blocking request for adult > content, this request may be declined by the OPES provider simply > because it contradicts its internal policy or its agreement with the > end subscriber. [Same concerns as above: what are we trying to illustrate here?] > Like tracing, Non-blocking operates on per application message bases. > Non-Blocking is an end-end operation as opposed to a hop-by-hop > operation. Non-blocking requests are generally client centric and go > in the opposite direction of tracing requests. Non-blocking can be > performed out of band or in-band. This work requires non-blocking to > be performed in-band as an extension to an application specific > protocol. > Non-OPES entities should be able to safely ignore the > extensions. The work does not prevent OPES Systems from developing > their own out of band protocols. > Non-blocking format is dependent on the application protocol that is > being adapted by OPES. 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 processor that is calling the service(s) to > handle the non-blocking request. In some cases, the first OPES > processor that will get the non-blocking request may not be the first > OPES processor that will know whether a non-OPES version of the > content is available or not. > In an OPES System, the OPES provider is expected to configure at > least one OPES processor to process a non-blocking header based on > content availability and related policies. In this case the OPES > processor is expected to determine the set of services that will be > bypassed (or those services that will be performed) or whether the > request should be forwarded directly to the data provider application > (origin content provider). [All of the above is a non-normative (informative) text (i.e., it contains no requirements or definitions), right? If something above is normative, please use appropriate keywords (MUST/SHOULD/MAY).] > Although, IAB recommendation (3.3) has intended for non-blocking > approach to be used as a vehicle to bypass faulty OPES > intermediaries. IAB recommendation (3.3) uses non-blocking requests as a vehicle to bypass faulty OPES intermediaries. > However, this work recognizes that the same technique > can be used to enable a data consumer application to select the set > of services that it would like to be bypassed for a given application > message. [I do not see a clear difference between the above two sentences. If you are implying that our bypass feature is designed to select a subset of useful services, than I disagree. Bypass feature is designed specifically to bypass faulty/malfunctioning/corrupted services. While it can be used for other purposes, any such use would be out of scope here] > For this reason, a non-blocking 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. ... identifies an OPES entity or a group of OPES entities to be bypassed. > An 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). > This version of the work > requires that all non-blocking instructions to use the wildcard > approach. ["version of the work"?? If we require that all instructions use wildcards, then why are we documenting URIs? Any URI use would be a violation of this spec!] > For example, an application level protocol (such as HTTP) can be > extended to include the following OPES non-blocking related header: > OPES-Bypass: * For example, HTTP can be extended to ... > The following requirements apply for non-blocking feature: > o An OPES System MUST support the non-blocking feature for requests > of non-OPES content for a given application message. [What does it mean to "support" a non-blocking feature? Does it mean to bypass? Does it mean to bypass unless no non-OPES content exists? Something else?] > o An OPES System MUST treat the non-blocking feature as an > end-to-end operation. [Do the above two requirements apply to OPES entities or just the System as a whole?] > * This means that there MUST be at least one OPES processor in an > OPES System that knows how to interpret and process the > non-blocking feature. [If this is implied (i.e., there is no way around it), why another MUST? Also, what is the compliance subject of this MUST?] > * The recipient MUST forward the bypass instructions to the next > application hop provided that the next hop speaks application > protocol with OPES bypass support. [Again, if this is an explanation of the above MUST, then this text should not be normative] > End users may not be able to know if their non-blocking request was > honored or not by the OPES System. In this case, it would be > beneficial if tracing can provide additional information regarding > whether a non-blocking request was honored or not. For this reason, > the following requirement also apply to the tracing facility: > o An OPES System SHOULD assist the data consumer application in > determining if a non-blocking request was performed by the system. > Assistance is viewed as the addition of information about services > that were skipped and those that could not be bypassed. [But what if it is the OPES tracing facility that is broken and needs to be bypassed? In other words, should not bypass apply to tracing adaptations as well? We could recommend that non-bypassed entities include information why/that they ignored the bypass instruction, but we should not recommend that bypassed entities were traced.] > 5. IANA considerations > This work does not require any IANA consideration since any actions > will be addressed in [6]. [ but [6] only addresses HTTP-specific IANA considerations. How about:] This specification contains no IANA considerations. Application bindings MAY contain application-specific IANA considerations. 6. Security Considerations > The security considerations for OPES are documented in [7]. This > document is a requirement document for tracing and non-blocking and > as such does not develop any new protocols that require security > considerations. [I strongly disagree. We certainly specify a high-level tracing and bypass protocol here. There are security considerations to document. For example, an OPES intermediary can add so many trace entries that another OPES intermediary will be overwhelmed (DoS attack or worse). Another example is fake trace entries. What bad things can be done by faking a trace? Finally, can bypass be used for DoS attacks because bypassed path is not optimized (e.g., bypassing CDN may overwhelm the server). Etc. etc.] > 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. > [3] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., > Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- > HTTP/1.1", RFC 2616, June 1999. > [5] Rousskov, A., "OPES Callout Protocol Core", Internet-Draft > http://www.ietf.org/internet-drafts/ > draft-ietf-opes-ocp-core-01.txt, August 2003. > [6] Rousskov, A., "HTTP adaptation with OPES", Internet-Draft TBD, > September 2003. > [7] A. Barbir et al., "Security Threats and Risks for Open Pluggable > Edge Services", Internet-Draft http://www.ietf.org/ > internet-drafts/draft-ietf-opes-threats-02.txt, February 2003. > [9] A. Barbir et al., "OPES Treatment of IAB Considerations", > Internet-Draft http://www.ietf.org/internet-drafts/ > draft-ietf-opes-iab-01.txt, February 2004. [In what way are the above reference normative? They seem to contain no normative text at all (e.g., [9]) or contain no normative text cited in this Tracing document.] > Informative References > [10] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., > Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S. > Waldbusser, "Terminology for Policy-Based Management", RFC > 3198, November 2001. > [11] L. Cranor, et. al, "The Platform for Privacy Preferences 1.0 > (P3P1.0) Specification", W3C Recommendation 16 http:// > www.w3.org/TR/2002/REC-P3P-20020416/ , April 2002. [I could not find any references from the draft text to the above two] From owner-ietf-openproxy@mail.imc.org Mon Oct 6 09:16:09 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28790 for ; Mon, 6 Oct 2003 09:16:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6VDk-000507-00 for opes-archive@ietf.org; Mon, 06 Oct 2003 09:16:16 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A6VDj-000504-00 for opes-archive@ietf.org; Mon, 06 Oct 2003 09:16:15 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96CueKP047314 for ; Mon, 6 Oct 2003 05:56:40 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96CueKF047313 for ietf-openproxy-bks; Mon, 6 Oct 2003 05:56:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zrtps06s.nortelnetworks.com (zrtps06s.nortelnetworks.com [47.140.48.50]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96CubKP047306 for ; Mon, 6 Oct 2003 05:56:40 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h96CuPp01126; Mon, 6 Oct 2003 08:56:25 -0400 (EDT) Received: from zrtpd0jh.us.nortel.com ([47.140.202.34]) by zrtpd0jn.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T9HCQ3ZM; Mon, 6 Oct 2003 08:56:25 -0400 Received: by zrtpd0jh.us.nortel.com with Internet Mail Service (5.5.2653.19) id <41VA51RZ>; Mon, 6 Oct 2003 08:56:25 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD75407250D54@zcard0k6.ca.nortel.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Abbie Barbir" To: Alex Rousskov , OPES WG Subject: RE: Feedback on draft-ietf-opes-end-comm-03 Date: Mon, 6 Oct 2003 08:56:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ALex, Thanks we will incporporate , sometime today. At this stage, I highly recommend that the IAB draft be polished and be ready for WGLC. ps: if u need help in the ocp/http drafts (please ask) Abbie > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Monday, October 06, 2003 12:06 AM > To: OPES WG > Subject: Feedback on draft-ietf-opes-end-comm-03 > > > Abbie, > > Here are my comments about version 03 of the > Communications draft you submitted for publication this > weekend. Your original text is ">" quoted. My comments are in > square [brackets]. Suggested replacement text is not. > > Thank you, > > Alex. > > > > > > OPES processor and end points communications > > draft-ietf-opes-end-comm-03 > > [Since the draft also contains requirements for callout > services and OPES systems, it would be more appropriate to title it] > > OPES entities and end points communication > > [No change in filename is required.] > > > This work specify the requirements for providing tracing > functionality > > for the OPES architecture [8]. > > ... specifies ... (?) > > > Tracing functionality > > enables a data provider application to detect inappropriate actions > > that are performed by OPES entities. > > ... enables a data provider or consumer application to ... > > [Also, tracing cannot be used to detect actions, it can only > be used to detect intermediaries] > > > The architecture document requires [8] that tracing be supported > > ... 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 > > is also dependent on the choice of the application level protocol > > ... are also dependent (?) > > > For these reasons, this work documents requirements for application > > protocols that need to support OPES traces and non-blocking. > > [Non-blocking is not a noun, right? If you insist on using > that expression as a noun, I would suggest to always append > "feature" or "mechanism" to make the sentences appear more > grammatically correct. Note that IAB RFC never uses > non-blocking as a noun. In fact, IAB never uses "blocking" > in any sentence! The non-word is only used as a label. This, > and other reasons I have already mentioned, make me feel > that we should not be using this non-word for anything other > than referring to IAB consideration by label. If you > disagree, let's at least make the sentences grammatically > correct. If non-blocking is indeed a perfectly valid noun, > please ignore my grammar-related comments (with apologies).] > > > However, > > the architecture does not prevent implementers of developing > > out-of-band protocols and techniques to address these limitation. > > > Definition: An OPES System is a set of all OPES entities > authorized by > > either the data provider or the data consumer application > to process a > > given application message. > > > The nature of the authorization agreement determines if authority > > delegation is transitive (meaning an authorized entities is > > ... an authorized entity is > > > The above definition implies that there can be no more than > one OPES > > system processing a single message at a given time. > > ... no more than two OPES systems (?) > > [Client-side and server-side OPES systems can process the > same message at the same time] > > ... processing the same message at a given time. > or > ... processing the given message at a given time. > > > > For example, consider a Content Delivery Network (CDN) > delivering an > > image on behalf of a busy web site. OPES processors and > services that > > the CDN uses to adapt and deliver the message comprise an > OPES system. > > In a more complex example, an OPES System would contain CDN > > [Please capitalize System in "OPES System" consistently > throughout the text] > > > In an OPES System tracing is performed on per message basis. Trace > > format is dependent on the application protocol that is > being adapted > > by OPES. A Data consumer application can use OPES trace to infer the > > A data ... > > > actions that have been performed by the OPES system. > Actions are the > > set of authorized OPES services that were performed by OPES > entities > > in an OPES System. > > ... set of OPES services that ... > > [The trace is no guarantee or even an indication of authorization ] > > > Providing tracing information, MUST take into account the following > > considerations: > > [Missing compliance subject/noun] > > > o Providers may be hesitant to reveal information about their > > internal network infrastructure. > > o Within a service provider network, OPES processors may be > > configured to use non-routable, private IP addresses. > > o A Data consumer applications would prefer to have a single point > > of contact regarding the trace information. > > [It is not clear to a reader what tracing properties these > considerations affect. In other words, how to take them into > account? Looks like some context is missing here] > > > 3.1 What is traceable in an OPES Flow? > > > This section focuses on identifying traceable entities in an OPES > > Flow. > > > Tracing information provides a data consumer application (or a data > > provider application) with useful information without tracing the > > ... with information ... > > > exact OPES Processor or callout servers that adapted the data. > > [But often exact OPES Processor or callout servers are > traced! Missing "for example" or "may" somewhere above?] > > > For > > example, some OPES services are message-agnostic and operate on > > message content or parts of a message. Such services cannot > manipulate > > message headers. Hence, a data consumer application would be > > interested in knowing that a translation service on the message > > content was performed. > > [The first ("for example") and the second ("hence") sentences > seem unrelated to me. Why "hence"?] > > > It does not need to know the exact entity that > > has performed the service. > > [Unless it wants to bypass that exact entity?] > > [Overall, it is not clear what all the text above from > "without tracing" to "has performed the service" is trying to > accomplish] > > > 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 be able > to see a > > trace entry, but does not need to be able to interpret it beyond > > identification of the OPES System. > > > Second, the OPES System administrator is expected to be able to > > interpret the contents of an OPES trace. The trace can be > provided by > > an end (data consumer or provider) as an opaque string. > > ... can be relayed to the administrator by an end (data consumer or > provider) without interpretation, as opaque data (e.g., a TCP > packet or an HTTP message snapshot). > > > Since the administrators of various OPES Systems can have > various ways > > of looking into tracing, they MAY require the choice of freedom in > > what to put in trace records and how to format them. > > ... they require freedom in ... > > [this should not be a compliance requirement because we are > not in business of certifying administrators; so no MAY] > > > 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. > > [Are these shoulds SHOULDs? Rephrase or capitalize them.] > > [Also, the second should is out of scope in this section The > first one may be out of scope as well unless "extensibility" > means adding info on new entities that can be traced"]. > > > At the implementation level, for a given trace, an OPES entity > > For a given trace, ... > > > involved in handling the corresponding application message is > > traceable or traced if information about it appears in that trace. > > OPES entities have different levels of traceability requirements. > > Specifically, > > [Is OPES system an OPES entity? Please define OPES entity > somewhere. You can say, for example, that OPES entity is > OPES processor or callout server, and that we also treat OPES > system as OPES entity where that does not lead to conflicts > (e.g., we do not do that when we define an OPES System).] > > > o An OPES system MUST add its entry to the trace. > > > o An OPES processor SHOULD add its entry to the trace. > > > o An OPES service May add its entry to the trace. > > ... MAY ... > > [Why are the above three rules here? Don't they belong to > corresponding "Requirements for XXX" sections?] > > > o An OPES entity MAY manage trace information from > entities that are > > under its control. For example, an OPES processor may add or > > remove callout service entries in order to manage the size of a > > trace. > > [Since OPES System is not something that can "add entries" on > its own, how about adding something like: > > 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). > ] > > [We also must address the ordering here. Are trace entries ordered?] > > [We also must specify whether a trace is a set or collection: > if an OPES processor is involved twice on the message path, > should it trace itself twice?] > > > From an OPES context, a good tracing approach is similar to > a trouble > > In an OPES context, ... (?) > > > > 3.2 Requirements for Information Related to Traceable Entities > > 3.2 Information required in a trace > > > The following MUST requirements apply for information as related to > > entities that are traceable in an OPES flow: > > [Delete the above sentence. It is too awkward and complex] > > > o Identification of the OPES System privacy policy at the time it > > dealt with the message. > > OPES System MUST include information about its privacy policy. > > [Note that we would need to say how that information can be > included without making the trace too large. For example, we > can say that it is sufficient to provide a URL to the OPES > System web page that has links to privacy and other policies.] > > > o Identification of the party responsible for setting and enforcing > > that policy. > > [Same note as above] > > > o Information pointing to a technical contact. > > [Same note as above] > > > o Information that identifies, to the technical contact, the OPES > > processors involved in processing the message. > > OPES processors MUST include their identification. > > [Now, if you look at the above, this section is really a > "Requirements for OPES Systems" section, with the exception > of the last MUST that belong to the "Requirements for OPES > processors" below! I would rename/move/rephrase accordingly.] > > > 3.3 Requirements for OPES processors > > > The requirements for OPES processors that are applicable to tracing > > are: > > Tracing requirements for OPES processors are: > > > o Each OPES processor MUST be uniquely identified in an > OPES System. > > [Remove the above. Since processor tracing is a SHOULD, there > is no reason to have a MUST concerning processor IDs] > > > o Each OPES processor MUST support tracing, policy can be used to > > turn tracing on and to determine its granularity. > > [Remove the above. It makes not practical sense. If a > particular policy says "turn tracing off", and a particular > processor implementation is based exclusively on that policy, > that implementation should not be forced to "support" > tracing. Processor tracing is a SHOULD.] > > > o If tracing is turned on, then the OPES processor MUST add its > > identification to the trace. > > OPES processor SHOULD add its unique identification to the > trace. Here, uniqueness scope is the OPES System containing > the processor. > > [Another trouble to address: What if a client-side OPES > System and a server-side OPES System share a processor? For > example, a server is translating from British English to > American based on client IP address and a client (a Briton > temporary in the US) is translating back to British English, > using the same well-known OPES processor (but under a > different contract, of course). We should make sure that OPES > processor includes two unique IDs in this scenario so it > would be clear that two translations were made and so that > one can be bypassed if buggy. I am not sure the above rules > address this kind of sharing.] > > > o OPES processor SHOULD be able to trace it's own invocation and > > service(s) execution since it understands the application > > protocol. > > [How is that different from the above rule? Do you mean to > add a rule that requires processor to trace its services?] > > > To fulfill this: > > [Fulfill what?] > > > * An OPES processor MAY have a fixed configuration that > enable it > > to respond to tracing inquires. For example, entity X performs > > service Y and so on. > > [It is unclear to me what this rule is trying to accomplish. > Of course, processor can have fixed configurations. Why are > we suddenly talking about "tracing inquires"??] > > > * An OPES processor MAY package tracing information related to > > the entities that it control based on the policy of a given > > OPES System. For example, the trace may state that service W > > was performed. The OPES processor knows that service W is > > composed of services X, Y and Z in a given order > > [Isn't that already covered in "An OPES entity MAY manage > trace information" rule?] > > > o An OPES processor SHOULD add to the trace identification of every > > callout service that processed the application message. > > [What if the service identified itself already?] > > > o An OPES processor MAY delegate trace management to a callout > > service within the same OPES System. > > [That should be covered by "An OPES entity MAY manage trace > information" rule in the revised version above] > > > > 3.4 Requirements for callout servers > > > 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. > > [Isn't everything in an OPES System done under the control of > the OPES System provider?] > > > 3.5 Protocol Binding > > [Should this section follow the Non-blocking section and be > not so tracing-specific? Bindings are equally needed for > tracing and bypass features...] > > > The task of adding tracing information is application protocol > > specific. > > The task of encoding tracing information is ... > > > Separate documents will address HTTP and other protocols. > > > This work documents what tracing information is required and some > > common tracing elements. > > [Remove the above sentence because it is both quite imprecise > and unnecessary here?] > > > 4. Non-Blocking > > [I find it strange that the layout of this section is not the > same as the layout of the Tracing section. We seem to be > talking about very similar things in both sections, but the > Tracing section is much better organized.] > > > In [9] recommendation addresses the issue of non-blocking > in an OPES > > System. The recommendation is restated below for ease of reference. > > > (3.3) Non-blocking: If there exists a non-OPES version of content > > available from the content provider, the OPES architecture must > > not prevent users from retrieving this non-OPES version from the > > content provider. > > > The IAB recommendation implies that it is up to the content > provider > > to make non-OPES versions of a given content available. > > [IAB consideration is not (should not be) the motivation or > reason to support bypass. Let's leave addressing of IAB > considerations to the IAB Treatment draft. We can simply > state that bypass is necessary to prevent [malfunctioning] > intermediaries from blocking the way to non-OPES content.] > > > The actual > > meaning of non-OPES version of the content depended on the > agreement > > between the OPES provider and the content provider. The > agreement can > > allow OPES to perform some services (such as logging services) and > > prevent it from performing other services (such as data to audio > > transformation). > > [Two things seem to be mixed here: It is not clear whether > the above paragraph explains that data provider can prohibit > certain services OR whether the above paragraph asserts that > definition of "non-OPES" is provider-dependent and may > include content adapted by OPES.] > > > Whether an OPES System honor a non-blocking request from a data > > consumer application (user) can also be a function of deployment. > > Consider the case where Company A has as contract with an OPES > > provider to perform virus checking on all e-mail attachments. An > > employee X of Company A can issue a non-blocking request > for the virus > > scanning service. However, the request could be ignored by the OPES > > provider since it contradicts its agreement with Company A. > > [Can we say that the above example is an example of "no > non-OPES content available" (and, hence, the above OPES > System does not violate any OPES rules)? Or are you implying > that the OPES System above is violating OPES rules by > ignoring user bypass request?] > > > As > > a second example, a user may issue a non-blocking request for adult > > content, this request may be declined by the OPES provider simply > > because it contradicts its internal policy or its agreement > with the > > end subscriber. > > [Same concerns as above: what are we trying to illustrate here?] > > > Like tracing, Non-blocking operates on per application > message bases. > > Non-Blocking is an end-end operation as opposed to a hop-by-hop > > operation. Non-blocking requests are generally client > centric and go > > in the opposite direction of tracing requests. Non-blocking can be > > performed out of band or in-band. This work requires > non-blocking to > > be performed in-band as an extension to an application specific > > protocol. > > > Non-OPES entities should be able to safely ignore the > extensions. The > > work does not prevent OPES Systems from developing their own out of > > band protocols. > > > Non-blocking format is dependent on the application > protocol that is > > being adapted by OPES. 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 processor that is calling the service(s) to > > handle the non-blocking request. In some cases, the first OPES > > processor that will get the non-blocking request may not be > the first > > OPES processor that will know whether a non-OPES version of the > > content is available or not. > > > In an OPES System, the OPES provider is expected to > configure at least > > one OPES processor to process a non-blocking header based > on content > > availability and related policies. In this case the OPES > processor is > > expected to determine the set of services that will be bypassed (or > > those services that will be performed) or whether the > request should > > be forwarded directly to the data provider application > (origin content > > provider). > > [All of the above is a non-normative (informative) text > (i.e., it contains no requirements or definitions), right? If > something above is normative, please use appropriate keywords > (MUST/SHOULD/MAY).] > > > Although, IAB recommendation (3.3) has intended for non-blocking > > approach to be used as a vehicle to bypass faulty OPES > intermediaries. > > IAB recommendation (3.3) uses non-blocking requests as a > vehicle to bypass faulty OPES intermediaries. > > > However, this work recognizes that the same technique > > can be used to enable a data consumer application to select > the set of > > services that it would like to be bypassed for a given application > > message. > > [I do not see a clear difference between the above two > sentences. If you are implying that our bypass feature is > designed to select a subset of useful services, than I > disagree. Bypass feature is designed specifically to bypass > faulty/malfunctioning/corrupted services. While it can be > used for other purposes, any such use would be out of scope here] > > > For this reason, a non-blocking 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. > > ... identifies an OPES entity or a group of OPES entities to > be bypassed. > > > An 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). > > > > This version of the work > > requires that all non-blocking instructions to use the wildcard > > approach. > > ["version of the work"?? If we require that all instructions > use wildcards, then why are we documenting URIs? Any URI use > would be a violation of this spec!] > > > For example, an application level protocol (such as HTTP) can be > > extended to include the following OPES non-blocking related header: > > OPES-Bypass: * > > For example, HTTP can be extended to ... > > > The following requirements apply for non-blocking feature: > > > o An OPES System MUST support the non-blocking feature for requests > > of non-OPES content for a given application message. > > [What does it mean to "support" a non-blocking feature? Does > it mean to bypass? Does it mean to bypass unless no non-OPES > content exists? Something else?] > > > o An OPES System MUST treat the non-blocking feature as an > > end-to-end operation. > > [Do the above two requirements apply to OPES entities or just > the System as a whole?] > > > * This means that there MUST be at least one OPES > processor in an > > OPES System that knows how to interpret and process the > > non-blocking feature. > > [If this is implied (i.e., there is no way around it), why > another MUST? Also, what is the compliance subject of this MUST?] > > > * The recipient MUST forward the bypass instructions to the next > > application hop provided that the next hop speaks application > > protocol with OPES bypass support. > > [Again, if this is an explanation of the above MUST, then > this text should not be normative] > > > End users may not be able to know if their non-blocking request was > > honored or not by the OPES System. In this case, it would be > > beneficial if tracing can provide additional information regarding > > whether a non-blocking request was honored or not. For this reason, > > the following requirement also apply to the tracing facility: > > > o An OPES System SHOULD assist the data consumer application in > > determining if a non-blocking request was performed by > the system. > > > Assistance is viewed as the addition of information about services > > that were skipped and those that could not be bypassed. > > [But what if it is the OPES tracing facility that is broken > and needs to be bypassed? In other words, should not bypass > apply to tracing adaptations as well? We could recommend that > non-bypassed entities include information why/that they > ignored the bypass instruction, but we should not recommend > that bypassed entities were traced.] > > > 5. IANA considerations > > > This work does not require any IANA consideration since any actions > > will be addressed in [6]. > > [ but [6] only addresses HTTP-specific IANA considerations. > How about:] > > This specification contains no IANA considerations. > Application bindings MAY contain application-specific IANA > considerations. > > 6. Security Considerations > > > The security considerations for OPES are documented in [7]. This > > document is a requirement document for tracing and > non-blocking and as > > such does not develop any new protocols that require security > > considerations. > > [I strongly disagree. We certainly specify a high-level > tracing and bypass protocol here. There are security > considerations to document. For example, an OPES > intermediary can add so many trace entries that another OPES > intermediary will be overwhelmed (DoS attack or worse). > Another example is fake trace entries. What bad things can > be done by faking a trace? Finally, can bypass be used for > DoS attacks because bypassed path is not optimized (e.g., > bypassing CDN may overwhelm the server). Etc. etc.] > > > > 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. > > > [3] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., > > Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- > > HTTP/1.1", RFC 2616, June 1999. > > > [5] Rousskov, A., "OPES Callout Protocol Core", Internet-Draft > > http://www.ietf.org/internet-drafts/ > > draft-ietf-opes-ocp-core-01.txt, August 2003. > > > [6] Rousskov, A., "HTTP adaptation with OPES", Internet-Draft TBD, > > September 2003. > > > [7] A. Barbir et al., "Security Threats and Risks for Open > Pluggable > > Edge Services", Internet-Draft http://www.ietf.org/ > > internet-drafts/draft-ietf-opes-threats-02.txt, February 2003. > > > [9] A. Barbir et al., "OPES Treatment of IAB Considerations", > > Internet-Draft http://www.ietf.org/internet-drafts/ > > draft-ietf-opes-iab-01.txt, February 2004. > > [In what way are the above reference normative? They seem to > contain no normative text at all (e.g., [9]) or contain no > normative text cited in this Tracing document.] > > > Informative References > > > [10] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., > > Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, > J. and S. > > Waldbusser, "Terminology for Policy-Based Management", RFC > > 3198, November 2001. > > > [11] L. Cranor, et. al, "The Platform for Privacy Preferences 1.0 > > (P3P1.0) Specification", W3C Recommendation 16 http:// > > www.w3.org/TR/2002/REC-P3P-20020416/ , April 2002. > > [I could not find any references from the draft text to the above two] > > > From owner-ietf-openproxy@mail.imc.org Mon Oct 6 09:19:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28937 for ; Mon, 6 Oct 2003 09:19:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6VGY-000533-00 for opes-archive@ietf.org; Mon, 06 Oct 2003 09:19:10 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A6VGY-000530-00 for opes-archive@ietf.org; Mon, 06 Oct 2003 09:19:10 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96D6VKP047662 for ; Mon, 6 Oct 2003 06:06:31 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96D6VO8047661 for ietf-openproxy-bks; Mon, 6 Oct 2003 06:06:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96D6UKP047656 for ; Mon, 6 Oct 2003 06:06:30 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h96D6VGh009660 for ; Mon, 6 Oct 2003 07:06:31 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h96D6VQU009659; Mon, 6 Oct 2003 07:06:31 -0600 (MDT) (envelope-from rousskov) Date: Mon, 6 Oct 2003 07:06:31 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: RE: Feedback on draft-ietf-opes-end-comm-03 In-Reply-To: <87609AFB433BD5118D5E0002A52CD75407250D54@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD75407250D54@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, 6 Oct 2003, Abbie Barbir wrote: > At this stage, I highly recommend that the IAB draft be polished and be > ready for WGLC. I believe the IAB draft is in a relatively good shape. I would rather wait for Sally's feedback or October 17th before making any serious changes to avoid changing the same thing more than once. I will be concentrating on OCP-related drafts for now. Alex. From owner-ietf-openproxy@mail.imc.org Mon Oct 6 11:14: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 LAA06678 for ; Mon, 6 Oct 2003 11:14:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6X4h-0006wv-00 for opes-archive@ietf.org; Mon, 06 Oct 2003 11:15:04 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A6X4h-0006wq-00 for opes-archive@ietf.org; Mon, 06 Oct 2003 11:15:03 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96F0tKP054146 for ; Mon, 6 Oct 2003 08:00:55 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96F0sPJ054145 for ietf-openproxy-bks; Mon, 6 Oct 2003 08:00:54 -0700 (PDT) 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.9/8.12.8) with ESMTP id h96F0rKP054138 for ; Mon, 6 Oct 2003 08:00:54 -0700 (PDT) (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 LAA05123; Mon, 6 Oct 2003 11:00:45 -0400 (EDT) Message-Id: <200310061500.LAA05123@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-end-comm-03.txt Date: Mon, 06 Oct 2003 11:00:45 -0400 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 processor and end points communications Author(s) : A. Barbir Filename : draft-ietf-opes-end-comm-03.txt Pages : 18 Date : 2003-10-6 This memo documents tracing requirements for Open Pluggable Edge Services (OPES) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opes-end-comm-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-end-comm-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-end-comm-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-10-6105828.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-opes-end-comm-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-opes-end-comm-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-6105828.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-openproxy@mail.imc.org Mon Oct 6 16:34: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 QAA21096 for ; Mon, 6 Oct 2003 16:34:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6c44-0003Np-00 for opes-archive@ietf.org; Mon, 06 Oct 2003 16:34:44 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A6bvI-0003GJ-00 for opes-archive@ietf.org; Mon, 06 Oct 2003 16:25:40 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96K8XKP069584 for ; Mon, 6 Oct 2003 13:08:33 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96K8Xes069583 for ietf-openproxy-bks; Mon, 6 Oct 2003 13:08:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96K8WKP069578 for ; Mon, 6 Oct 2003 13:08:32 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h96K8YGh020172; Mon, 6 Oct 2003 14:08:34 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h96K8X1s020171; Mon, 6 Oct 2003 14:08:33 -0600 (MDT) (envelope-from rousskov) Date: Mon, 6 Oct 2003 14:08:33 -0600 (MDT) From: Alex Rousskov To: "OPES WG (E-mail)" Subject: Re: capability negotiations In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D0552A0@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D0552A0@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 like simplifications and understand what you are trying to do. I agree that there is a complexity problem here. I think your solution works OK on a local level. I am, however, concerned about overall consistency and symmetry of protocol mechanisms. Let me try to explain with a couple of examples and observations. You propose to use Optional-Parts, Skip-Parts using named headers as opposed to [named] feature parameters. Once we separate a feature ID and its parameters, how will agents report their [multiple] capabilities in a [single] "I Support" (i-can) response? For example, consider a callout service that wants to always receive request-headers in RESPMOD mode and wants to receive request-body in RESPMOD mode if and only if that body is chunked. You cannot express that condition using a single feature structure or a single feature ID with attached named parameters. You need two structures OR two messages each with its own group of named parameters. Do you think that the above scenario is too esoteric to support? When negotiating/announcing encryption, would not the same problem arise? How to express "RSA with 512bit keys" and "DES with 1024bit keys" in a single NO or i-can message? Will we never need to offer two features at once? Do we want to eliminate i-can mechanism altogether? Once we start using named parameters for features, we cannot describe multiple conflicting features within one OCP message. A general solution is a list of structures (with [named] members). I would even argue that we can make everything symmetric if named members are using name:value MIME syntax OR if named parameters adopt a name=value non-MIME syntax instead. This generalization allows us to, essentially, list OCP statements/messages (such as negotiation offers or i-can responses) in a single OCP message: NO ({ "feature-id1" param1: value1a param2: value2a },{ "feature-id1" param1: value1b param2: value2b }) Applies-to-whole-message-name1: value1 Applies-to-whole-message-name2: value2 ... where "Applies-to-whole-message-name" stands for a property that applies to the whole NO message and not any feature being negotiated in particular. SG, for example, is one of such named parameters. As you can see, this leads to a very symmetric/consistent syntax because the whole message prefix becomes nothing but an OCP structure (just without the surrounding {} which perhaps should be added)! This simplifies parsing and internal representation, IMO: the same code/structures are used to store and manage whole messages and message parts. We are now kind of stuck in the middle: we have structures but we are afraid of them. This is probably the worst position to be in! I like symmetry and consistency. The idealist in me says "a feature should be a structure OR we should not have structures at all". Or, in other words, "either we commit to support structures in any context or we do not support them at all". Do you see what I am getting at? Would you prefer to get rid of structures completely OR use them extensively? Do you see any other consistent design options? Thanks, Alex. On Mon, 29 Sep 2003, Martin Stecher wrote: > > Hi, > > here are some thoughts about the capability negotiations. > > > Current status: > HTTP/OCP uses NO and NR messages to negotiate one of the two defined application profiles (request or response) plus optional message parts. > Futher information exchange about capabilities for transfer- and content-encodings needs to be defined and done. > > > Question: > Can we simplify the application profiles negotiation and how to implement the encodings stuff? > > > Compare with ICAP/1.0: > ICAP defines the OPTIONS method; in a response to an OPTIONS request, the ICAP server returns various information, including support for the main methods (REQMOD/RESPMOD). But which method to use is not negotiated and ICAP does not know something about optional message parts, skipped parts or information about supported encodings. > If to be implemented it would probably be done in the OPTIONS request. > > > Do we really need to negotiate the HTTP profile? > Depending on the vectoring point, an OPES processor will either send a HTTP request or an HTTP response via OCP to the callout server. It makes not much sense to offer both profiles and let the callout server select. > All ICAP implementations I know and the rules language show: The decision which profile to use is being done in the OPES processor. > Still the information whether a callout server at all supports this profile is important; but it could be done in a "has feature" message, rather than in the negotiation offer. > So, I vote for restricting the NO message to send a single application profile, not a list of profiles. > The callout server can then either accept or decline. > Having a list of profiles can make the negotiation offer very long if additional parameters are offered as an option. In the current draft we offer additional message parts as options and adding more paramters would make this much too long. > > Other parameters > Client and server need to exchange information about (or negotiate on): > 1. wanted additional optional message parts > server asks client > e.g. please add original HTTP request headers to HTTP response) > 2. standard message parts not needed > server tells client > e.g. do not need long HTTP request body, only interested in headers > 3. supported transfer encodings (or HTTP version) > client and server need to tell each other > e.g. is it ok for the server to add chunked transfer encoding? > 4. supported content encodings > client and server need to tell each other > e.g. does the client need to decode gzip encoding before sending message to server? > 5. maybe additional parameters, specific for the callout server > e.g. number of parallel connections supported > 6. maybe additional parameters, specific to the service to use > e.g. please add more meta information such as user info > > I think it is not a good idea to create separate messages (negotiation offer or has-feature) for each parameter although several messages could be sent in a single TCP frame. > > So, what about adding these paramters as named parameters to the NO and NR messages. If the NO message has only a single application profile it works that way. > > Example: > NO "38:http://iana.org/opes/ocp/HTTP/response" > SG: 10 > Optional-Parts: request-header, request-body > Transfer-Encodings: chunked > Content-Encodings: gzip, compress > > NR "38:http://iana.org/opes/ocp/HTTP/response" > SG: 10 > Optional-Parts: request-header > Skip-Parts: response-body > Transfer-Encodings: chunked > > It means: > Client wants to do response modification with services in group ten. > It offers two additional optional message parts. > Client supported chunked transfer encoding and gzip and compress content encoding > Server confirms that it can do response modification and asks for the request-header as an optional message part. > If the client is able skip the response body part, it may do so. > Chunked transfer encoding is also supported by the server but if the message has a content encoding, the client has either to decode it or the server won't understand it (not a problem in this example because Skip-Parts header indicates that it does not need the body at all. > > > What do you think about this? Can we do it that way? > > Regards > Martin > > From owner-ietf-openproxy@mail.imc.org Mon Oct 6 17:42: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 RAA24039 for ; Mon, 6 Oct 2003 17:42:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6d7J-0004dw-00 for opes-archive@ietf.org; Mon, 06 Oct 2003 17:42:09 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A6cuy-0004Xp-00 for opes-archive@ietf.org; Mon, 06 Oct 2003 17:29:24 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96LCSKP072233 for ; Mon, 6 Oct 2003 14:12:28 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96LCSGl072232 for ietf-openproxy-bks; Mon, 6 Oct 2003 14:12:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail2.webwasher.com ([213.70.80.11]) by above.proper.com (8.12.9/8.12.8) with SMTP id h96LCPKP072209 for ; Mon, 6 Oct 2003 14:12:26 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] id 0IEBKVYA; 07 Oct 2003 01:19:21 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: capability negotiations Date: Mon, 6 Oct 2003 23:12:09 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D014043@mail.webwasher.com> Thread-Topic: capability negotiations Thread-Index: AcOMRaCDrBTp6IwPTqG3OZf5btgDmQAA4H5A From: "Martin Stecher" To: "OPES WG (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h96LCRKP072225 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi Alex, > > I like simplifications and understand what you are trying to > do. I agree that there is a complexity problem here. I think your > solution works OK on a local level. I am, however, concerned about > overall consistency and symmetry of protocol mechanisms. Let me try to > explain with a couple of examples and observations. > > You propose to use Optional-Parts, Skip-Parts using named > headers as opposed to [named] feature parameters. Once we separate a > feature ID and its parameters, how will agents report their [multiple] > capabilities in a [single] "I Support" (i-can) response? > > For example, consider a callout service that wants to always > receive request-headers in RESPMOD mode and wants to receive > request-body in RESPMOD mode if and only if that body is chunked. You > cannot express that condition using a single feature structure or a > single feature ID with attached named parameters. You need two > structures OR two messages each with its own group of named > parameters. > > Do you think that the above scenario is too esoteric to > support? Yes, I think it is too esoteric. So far, I am not aware of an existing filter application that needs request-bodies in RESPMOD, but probably there are some useful filters that like to have this meta info. But why should the interest in that data depend on the transfer encoding between client and proxy? I am lacking phantasy here. What I understand is your desire to keep the protocol as unrestricted and powerful as possible. Not restricting any protocol feature we have, because it may be useful now or later in some more or less esoteric environment. That's fine with me. On the other hand I am concerned about negotiation complexity. I think that it is unlikely that two agents find a perfect match or the nearly perfect second choice even if you list all features in a complicated decision matrix. Agents need to workaround lacks of capabilities of the other side and so they could work around a slightly restricted negotiation procedure. > > When negotiating/announcing encryption, would not the same > problem arise? How to express "RSA with 512bit keys" and "DES with > 1024bit keys" in a single NO or i-can message? I do not think that encryption is transaction dependend, it works on connections. Certainly an agent can respond to a "which encryption method do you support" with a list of encryptions in an i-can message. Even if it was a feature of an NO message, the value of the named parameter could be a list of course, such as my example Optional-Parts: request-header, request-body which should better read Optional-Parts: (request-header, request-body) to be consistent and symetric, sorry for that mistake. > > Will we never need to offer two features at once? > > Do we want to eliminate i-can mechanism altogether? > > Once we start using named parameters for features, we cannot > describe multiple conflicting features within one OCP message. A > general solution is a list of structures (with [named] members). I > would even argue that we can make everything symmetric if named > members are using name:value MIME syntax OR if named parameters adopt > a name=value non-MIME syntax instead. > > This generalization allows us to, essentially, list OCP > statements/messages (such as negotiation offers or i-can responses) in > a single OCP message: > > NO ({ > "feature-id1" > param1: value1a > param2: value2a > },{ > "feature-id1" > param1: value1b > param2: value2b > }) > Applies-to-whole-message-name1: value1 > Applies-to-whole-message-name2: value2 > ... > > where "Applies-to-whole-message-name" stands for a property that > applies to the whole NO message and not any feature being negotiated > in particular. SG, for example, is one of such named parameters. We can go this way, if you insist. I think usage of named items (either parameters or members of structures) is the key. Whether structures are needed for (some) features depends on the complexity we believe is necessary for a powerful protocol vs. the complexity that makes the protocol hard to handle (for a human being). > > As you can see, this leads to a very symmetric/consistent syntax > because the whole message prefix becomes nothing but an OCP structure > (just without the surrounding {} which perhaps should be added)! This > simplifies parsing and internal representation, IMO: the same > code/structures are used to store and manage whole messages and > message parts. > > We are now kind of stuck in the middle: we have structures but we are > afraid of them. This is probably the worst position to be in! > > I like symmetry and consistency. The idealist in me says "a feature > should be a structure OR we should not have structures at all". Or, in > other words, "either we commit to support structures in any context or > we do not support them at all". For me this is too black and white. It is great to have structures. Structures with named members are even better. But that does not imply automatically that structures need to be used everywhere, IMO. Symmetry is great but is it the number 1 design rule that must never break? > > Do you see what I am getting at? Would you prefer to get rid of > structures completely OR use them extensively? Do you see any other > consistent design options? If you (still) insist in black and white decision, I vote for extensive usage. I assume that you then also like to continue support for multiple application profile features in NR messages? No restrictions because the syntax is there to make it possible. So be it. For my full understanding, could you please write the structured NO/NR messages for my specific example that I gave in the previous message; and also how it will look like when adding the esoteric condition you suggested? Regards Martin > > On Mon, 29 Sep 2003, Martin Stecher wrote: > > > > > Hi, > > > > here are some thoughts about the capability negotiations. > > > > > > Current status: > > HTTP/OCP uses NO and NR messages to negotiate one of the > two defined application profiles (request or response) plus > optional message parts. > > Futher information exchange about capabilities for > transfer- and content-encodings needs to be defined and done. > > > > > > Question: > > Can we simplify the application profiles negotiation and > how to implement the encodings stuff? > > > > > > Compare with ICAP/1.0: > > ICAP defines the OPTIONS method; in a response to an > OPTIONS request, the ICAP server returns various information, > including support for the main methods (REQMOD/RESPMOD). But > which method to use is not negotiated and ICAP does not know > something about optional message parts, skipped parts or > information about supported encodings. > > If to be implemented it would probably be done in the > OPTIONS request. > > > > > > Do we really need to negotiate the HTTP profile? > > Depending on the vectoring point, an OPES processor will > either send a HTTP request or an HTTP response via OCP to the > callout server. It makes not much sense to offer both > profiles and let the callout server select. > > All ICAP implementations I know and the rules language > show: The decision which profile to use is being done in the > OPES processor. > > Still the information whether a callout server at all > supports this profile is important; but it could be done in a > "has feature" message, rather than in the negotiation offer. > > So, I vote for restricting the NO message to send a single > application profile, not a list of profiles. > > The callout server can then either accept or decline. > > Having a list of profiles can make the negotiation offer > very long if additional parameters are offered as an option. > In the current draft we offer additional message parts as > options and adding more paramters would make this much too long. > > > > Other parameters > > Client and server need to exchange information about (or > negotiate on): > > 1. wanted additional optional message parts > > server asks client > > e.g. please add original HTTP request headers to > HTTP response) > > 2. standard message parts not needed > > server tells client > > e.g. do not need long HTTP request body, only > interested in headers > > 3. supported transfer encodings (or HTTP version) > > client and server need to tell each other > > e.g. is it ok for the server to add chunked transfer > encoding? > > 4. supported content encodings > > client and server need to tell each other > > e.g. does the client need to decode gzip encoding > before sending message to server? > > 5. maybe additional parameters, specific for the callout server > > e.g. number of parallel connections supported > > 6. maybe additional parameters, specific to the service to use > > e.g. please add more meta information such as user info > > > > I think it is not a good idea to create separate messages > (negotiation offer or has-feature) for each parameter > although several messages could be sent in a single TCP frame. > > > > So, what about adding these paramters as named parameters > to the NO and NR messages. If the NO message has only a > single application profile it works that way. > > > > Example: > > NO "38:http://iana.org/opes/ocp/HTTP/response" > > SG: 10 > > Optional-Parts: request-header, request-body > > Transfer-Encodings: chunked > > Content-Encodings: gzip, compress > > > > NR "38:http://iana.org/opes/ocp/HTTP/response" > > SG: 10 > > Optional-Parts: request-header > > Skip-Parts: response-body > > Transfer-Encodings: chunked > > > > It means: > > Client wants to do response modification with services in > group ten. > > It offers two additional optional message parts. > > Client supported chunked transfer encoding and gzip and > compress content encoding > > Server confirms that it can do response modification and > asks for the request-header as an optional message part. > > If the client is able skip the response body part, it may do so. > > Chunked transfer encoding is also supported by the server > but if the message has a content encoding, the client has > either to decode it or the server won't understand it (not a > problem in this example because Skip-Parts header indicates > that it does not need the body at all. > > > > > > What do you think about this? Can we do it that way? > > > > Regards > > Martin > > > > > > ------------------------------------------------------------ > This mail has been scanned by debian3-smtp > (WebWasher 4.4.1 Build 652) > ------------------------------------------------------------ > From owner-ietf-openproxy@mail.imc.org Mon Oct 6 18:59: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 SAA27316 for ; Mon, 6 Oct 2003 18:59:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6eK5-0005Sj-00 for opes-archive@ietf.org; Mon, 06 Oct 2003 18:59:25 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A6eK5-0005Sg-00 for opes-archive@ietf.org; Mon, 06 Oct 2003 18:59:25 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96Mj4KP076670 for ; Mon, 6 Oct 2003 15:45:04 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96Mj4MT076669 for ietf-openproxy-bks; Mon, 6 Oct 2003 15:45:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96Mj2KP076664 for ; Mon, 6 Oct 2003 15:45:02 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h96Mj5Gh023536; Mon, 6 Oct 2003 16:45:05 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h96Mj46x023535; Mon, 6 Oct 2003 16:45:04 -0600 (MDT) (envelope-from rousskov) Date: Mon, 6 Oct 2003 16:45:04 -0600 (MDT) From: Alex Rousskov To: "OPES WG (E-mail)" Subject: RE: capability negotiations In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D014043@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D014043@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 6 Oct 2003, Martin Stecher wrote: > On the other hand I am concerned about negotiation complexity. I > think that it is unlikely that two agents find a perfect match or > the nearly perfect second choice even if you list all features in a > complicated decision matrix. Agents need to workaround lacks of > capabilities of the other side and so they could work around a > slightly restricted negotiation procedure. This is my concern as well. Perhaps we can address both concerns (clean design and negotiation complexity) without too many sacrifices. > > When negotiating/announcing encryption, would not the same > > problem arise? How to express "RSA with 512bit keys" and "DES with > > 1024bit keys" in a single NO or i-can message? > > I do not think that encryption is transaction dependend, it works on > connections. Yes, I was using connection encryption to provide a better example. But it makes no difference since negotiation _mechanisms_ for connection- and transaction-scope should be the same, right? > Certainly an agent can respond to a "which encryption method do you > support" with a list of encryptions in an i-can message. Unless I am missing something, using your simplified format, the agent will _not_ be able to offer the above choices in NO and will not be able to respond with them in an i-can response. Given your single feature option, an agent can only say: NO "opes:connection-encryption" Algorithms: (RSA) Key-Sizes: (512); or NO "opes:connection-encryption" Algorithms: (DES) Key-Sizes: (1024) The agent cannot say: NO "opes:connection-encryption" Algorithms: (RSA,DES) Key-Sizes: (512,1024) because the agent does not offer/support RSA with 1024bit keys and DES with 512bit keys. With current, more complex scheme, the agent can express both options (I will use named members): NO ({ "opes:connection-encryption" Algorithms: (RSA) Key-Sizes: (512) },{ "opes:connection-encryption" Algorithms: (DES) Key-Sizes: (1024) }) SG: 10 ; And the recipient can make a choice knowing all available options (there are two options available in this example). Do you see what I am getting at? All of the above applies to i-can responses as well, of course: Only lists of structures can express RSAx512 and DESx1024 ability without implying RSAx1024 and DESx512 support. > Even if it was a feature of an NO message, the value of the named > parameter could be a list of course, such as my example > Optional-Parts: request-header, request-body > which should better read > Optional-Parts: (request-header, request-body) > to be consistent and symetric, sorry for that mistake. Of course. That's the way I interpreted it. The problem is that name parameter lists create a full mesh of choices and do not allow for specific subsets (see example above). The lists should still be allowed. The above example can be extended to show a more powerful DES implementation: NO ({ "opes:connection-encryption" Algorithms: (RSA) Key-Sizes: (512) },{ "opes:connection-encryption" Algorithms: (DES) Key-Sizes: (1024,2048,8192) }) SG: 10 ; > I think usage of named items (either parameters or members of > structures) is the key. > Whether structures are needed for (some) features depends on the > complexity we believe is necessary for a powerful protocol vs. the > complexity that makes the protocol hard to handle (for a human > being). Exactly. It seems that the final decision depends on whether we think that supplying more than one feature in a NO and responding with more than one feature in i-can is essential to support. If the answer is "yes", then we should support the lists of structures in NO messages. If the answer is "no, not essential". Then we can limit NO messages to a single feature (with a full mesh of named parameters). Do you agree that this is the choice we face? Did the examples above convince you that we need to support multiple features in some negotiations? Also, let's compare the complexity of the two approaches: a) Multiple structures with named members. A minimal implementation would require parsing each structure, checking whether the feature matches capabilities, until the first matching feature is found. b) Single feature with named parameters. A minimal implementation would require parsing the message headers and checking whether the feature matches capabilities So the only difference is in the extra iteration in case (a). Is this the added complexity you are concerned with? Or did I miss any other complications? > It is great to have structures. Structures with named members are > even better. But that does not imply automatically that structures > need to be used everywhere, IMO. True. They only need to be used where the information cannot be represented using simpler elements. I do not think we disagree on whether or how to use structures. I think the only thing we need to agree on is whether we need multiple non-meshed features in a single negotiation offer or i-can response. > I assume that you then also like to continue support for multiple > application profile features in NR messages? Not necessarily. Again, I like your simplification. I just want to make sure it is still general _enough_ :-). > For my full understanding, could you please write the structured > NO/NR messages for my specific example that I gave in the previous > message; This dialog: > NO "38:http://iana.org/opes/ocp/HTTP/response" > SG: 10 > Optional-Parts: request-header, request-body > Transfer-Encodings: chunked > Content-Encodings: gzip, compress > > NR "38:http://iana.org/opes/ocp/HTTP/response" > SG: 10 > Optional-Parts: request-header > Skip-Parts: response-body > Transfer-Encodings: chunked becomes this: NO ({ "38:http://iana.org/opes/ocp/HTTP/response" Optional-Parts: (request-header,request-body) Transfer-Encodings: (chunked) Content-Encodings: (gzip, compress) }) SG: 10 NR { "38:http://iana.org/opes/ocp/HTTP/response" Optional-Parts: (request-header) Skip-Parts: (response-body) Transfer-Encodings: (chunked) } SG: 10 That is, one feature offered (but there could have been more) and one more specific feature is accepted (there could not have been more than one). > message; and also how it will look like when adding the esoteric > condition you suggested? Well, now you are pushing it! :-) i-can ({ "38:http://iana.org/opes/ocp/HTTP/response" Optional-Parts: (request-header) },{ "38:http://iana.org/opes/ocp/HTTP/response" Optional-Parts: (request-header,request-body) Transfer-Encodings: (chunked) }) See also encryption negotiation examples above. Again, there seems to be only one important choice here: multiple structures versus one; all in the context of negotiations and capability reporting. Did more examples and clarifications change your preferences in any way? Thank you, Alex. From subs-reminder@imc.org Tue Oct 7 00:00:12 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04549 for ; Tue, 7 Oct 2003 00:00:12 -0400 (EDT) From: subs-reminder@imc.org Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6j1I-0000Cz-00 for opes-archive@ietf.org; Tue, 07 Oct 2003 00:00:20 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A6j1H-0000Cw-00 for opes-archive@ietf.org; Tue, 07 Oct 2003 00:00:19 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h9740GKP010185 for ; Mon, 6 Oct 2003 21:00:16 -0700 (PDT) (envelope-from subs-reminder@imc.org) Received: (from root@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h9740GC3010183; Mon, 6 Oct 2003 21:00:16 -0700 (PDT) Date: Mon, 6 Oct 2003 21:00:16 -0700 (PDT) Message-Id: <200310070400.h9740GC3010183@above.proper.com> To: opes-archive@ietf.org Subject: [[834890315]] Subscription to ietf-openproxy for opes-archive@ietf.org Greetings. This message is a periodic reminder that opes-archive@ietf.org is subscribed to the ietf-openproxy mailing list. *** SEE BELOW: PLEASE DO NOT RESPOND TO THIS MESSAGE. *** There are two purposes for this message: - If this message is bounced by your mail server, I can remove you from the mailing list and reduce waste of bandwidth and resources. (If you are reading this message, it clearly didn't get bounced!) - Some people stay subscribed to mailing lists even though they do not want to because they do not know how to unsubscribe. If you want to stay subscribed to the ietf-openproxy mailing list, you do not need to do anything. Feel free to delete this message. On the other hand, if you want to unsubscribe from this list, simply go to the following link: If for some reason you cannot go to that web site, you can also unsubscribe by email; however, doing so is not as likely to get you unsubscribed as the web site is. To unsubscribe using email, you can respond to this message and I will unsubscribe you by hand in the next few days. Again, this is not assured to work because your mail system may make it impossible for me to determine who you are or what you want to unsubscribe to. Alternatively, you can send a plain-text message to: ietf-openproxy-request@imc.org with the single word unsubscribe in the body of the message. This last method assumes that the "From:" address in your mail is "opes-archive@ietf.org". Again, using the web site above is more likely to work than this method (due to limitations in Majordomo, the mailing list software we currently use). If you have any questions, feel free to contact me. --Paul Hoffman, list administrator From owner-ietf-openproxy@mail.imc.org Tue Oct 7 06:26:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25908 for ; Tue, 7 Oct 2003 06:26:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6p2g-0003fn-00 for opes-archive@ietf.org; Tue, 07 Oct 2003 06:26:10 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A6p2f-0003fa-00 for opes-archive@ietf.org; Tue, 07 Oct 2003 06:26:09 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97A8oKP018113 for ; Tue, 7 Oct 2003 03:08:50 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h97A8o3i018112 for ietf-openproxy-bks; Tue, 7 Oct 2003 03:08:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail2.webwasher.com ([213.70.80.11]) by above.proper.com (8.12.9/8.12.8) with SMTP id h97A8jKP018090 for ; Tue, 7 Oct 2003 03:08:48 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] id CH7LEKVJ; 07 Oct 2003 14:15:44 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: capability negotiations Date: Tue, 7 Oct 2003 12:08:33 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D055309@mail.webwasher.com> Thread-Topic: capability negotiations Thread-Index: AcOMW33jr3uD9YMhTpOHIW+aSH2MEgAW1STQ From: "Martin Stecher" To: "OPES WG (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h97A8nKP018108 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi Alex, > > Unless I am missing something, using your simplified format, the agent > will _not_ be able to offer the above choices in NO and will not be > able to respond with them in an i-can response. Given your single > feature option, an agent can only say: > > NO "opes:connection-encryption" > Algorithms: (RSA) > Key-Sizes: (512); > > or > > NO "opes:connection-encryption" > Algorithms: (DES) > Key-Sizes: (1024) > > The agent cannot say: > > NO "opes:connection-encryption" > Algorithms: (RSA,DES) > Key-Sizes: (512,1024) > > because the agent does not offer/support RSA with 1024bit keys and DES > with 512bit keys. With current, more complex scheme, the agent can > express both options (I will use named members): > > NO ({ > "opes:connection-encryption" > Algorithms: (RSA) > Key-Sizes: (512) > },{ > "opes:connection-encryption" > Algorithms: (DES) > Key-Sizes: (1024) > }) > SG: 10 > ; > > And the recipient can make a choice knowing all available options > (there are two options available in this example). Do you see what I > am getting at? Yes, thank you very much for clarification. As many others I best grap things with real examples ;-) From your last message I thought about a combined algorithm-keysize value and so didn't get the point The simple header "Encryption: (RSA-512, DES-1024)" works of course. I hear you saying (and agree) that assembling of such a value is not an OCP standard thing; so why introducing such misfitting element if the same can be expressed with an OCP standard structure. You are right. The only answer could be "because humans find it easier to read", but since OCP is usally handled by a machine... ;-) When using the structures for NO messages, we need to make sure that we have also such a more complicated example in the specs. Otherwise I am afraid that programers oversee this point and implement something that only works for lists with a single element which probably often works but will break general interoperability. [...] > > > Also, let's compare the complexity of the two approaches: > > a) Multiple structures with named members. A minimal > implementation would require parsing each structure, > checking whether the feature matches capabilities, > until the first matching feature is found. > > b) Single feature with named parameters. A minimal > implementation would require parsing the message > headers and checking whether the feature matches > capabilities > > So the only difference is in the extra iteration in case (a). Is this > the added complexity you are concerned with? Or did I miss any other > complications? I think (a) is a little more complicated. You cannot stop with the first matching feature, you have to continue and see whether an even better match will be found. In the example above RSAx512 may work but DESx1024 may be preferred. But I agree that the software can handle this and it is not hard to program. [...] > > Again, there seems to be only one important choice here: multiple > structures versus one; all in the context of negotiations and > capability reporting. Did more examples and clarifications change your > preferences in any way? > Again, thank you for the many examples. They really helped me. The good thing is that many real-world examples will probably just have a single feature in the list and the list of structures does then look still easy enough for a human being to understand. When also giving a more complicated example in the specs, I guess that we can achieve powerful, flexible and interoperable OCP implementations. So, yes, you convinced me. Let's do it this way. Will you add the named structure member concept to the OCP core? I could then describe the feature negotiation in the HTTP draft, if you like. Are you ok with the suggested member names? Optional-Parts, Skip-Parts, Transfer-Encodings, Content-Encodings We also now have a good start for connection encryption negotiation, I guess :-) Best regards Martin From owner-ietf-openproxy@mail.imc.org Tue Oct 7 10:28: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 KAA04043 for ; Tue, 7 Oct 2003 10:28:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6spC-0006D3-00 for opes-archive@ietf.org; Tue, 07 Oct 2003 10:28:30 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A6spB-0006Ct-00 for opes-archive@ietf.org; Tue, 07 Oct 2003 10:28:29 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97EE2KP028440 for ; Tue, 7 Oct 2003 07:14:02 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h97EE2xl028439 for ietf-openproxy-bks; Tue, 7 Oct 2003 07:14:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97EE0KP028434 for ; Tue, 7 Oct 2003 07:14:01 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h97EE1Gh045228; Tue, 7 Oct 2003 08:14:01 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h97EE1Jn045227; Tue, 7 Oct 2003 08:14:01 -0600 (MDT) (envelope-from rousskov) Date: Tue, 7 Oct 2003 08:14:01 -0600 (MDT) From: Alex Rousskov To: "OPES WG (E-mail)" Subject: RE: capability negotiations In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D055309@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D055309@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 7 Oct 2003, Martin Stecher wrote: > The good thing is that many real-world examples will probably just > have a single feature in the list and the list of structures does > then look still easy enough for a human being to understand. Agreed. > When also giving a more complicated example in the specs, I guess > that we can achieve powerful, flexible and interoperable OCP > implementations. One could only hope. > Will you add the named structure member concept to the OCP core? Yes, with the next revision, probably this week. Named members will use the same syntax as named parameters to keep the grammar simple. I will need to think about end-of-member delimiters though. I will try to convince myself that we should always use CRLF, but I am not sure yet. The subgoal is for any OCP message to be a valid OCP structure so that parsing, storing, and managing a message would be the same as parsing, storing, and managing any complete part of a message, just like it is with XML. > I could then describe the feature negotiation in the HTTP draft, if > you like. Please do. > Are you ok with the suggested member names? > Optional-Parts, Skip-Parts, Transfer-Encodings, Content-Encodings Do we assume that these negotiations will happen infrequently in most cases (because negotiated service group will be reused for many transactions)? If yes, then I have no problems with the above names. If we assume rather frequent negotiations, I would suggest abbreviating the above: PO, PS, ET, EC. > We also now have a good start for connection encryption negotiation, > I guess :-) Yes, that's another big pending chunk of work. Once you are done with HTTP negotiations we can solicit help with connection encryption negotiation, using your text as an example. Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Tue Oct 7 17:57:35 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23996 for ; Tue, 7 Oct 2003 17:57:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6zpv-0004O7-00 for opes-archive@ietf.org; Tue, 07 Oct 2003 17:57:43 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A6zpu-0004O1-00 for opes-archive@ietf.org; Tue, 07 Oct 2003 17:57:42 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97LhQKP047139 for ; Tue, 7 Oct 2003 14:43:26 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h97LhQC1047138 for ietf-openproxy-bks; Tue, 7 Oct 2003 14:43:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail2.webwasher.com ([213.70.80.11]) by above.proper.com (8.12.9/8.12.8) with SMTP id h97LhNKP047130 for ; Tue, 7 Oct 2003 14:43:24 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] id PAOFRYQB; 08 Oct 2003 01:50:28 +0200 Subject: RE: capability negotiations Date: Tue, 7 Oct 2003 23:43:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <75F7E67FC45F6744A7D328D41E35376D055310@mail.webwasher.com> content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: capability negotiations Thread-Index: AcOM3UPlHDfCanfMSbytQVGufnaNXgAPgtYg From: "Martin Stecher" To: "OPES WG (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h97LhPKP047133 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi, > > > Are you ok with the suggested member names? > > Optional-Parts, Skip-Parts, Transfer-Encodings, Content-Encodings > > Do we assume that these negotiations will happen infrequently in most > cases (because negotiated service group will be reused for many > transactions)? If yes, then I have no problems with the above names. > If we assume rather frequent negotiations, I would suggest > abbreviating the above: PO, PS, ET, EC. > I assume only few negotiations per connection, just to get service group features negotiated. The SG parameter of NO/NR was the important thing we introduced earlier. Connections should then stay open and handle many transactions. There will probably be some number of parallel open connections, so negotiation will be repeated here and there, but this will still be infrequently compared with the number of transactions handled. If there are no further comments, I will use the long names here. Regards MArtin From owner-ietf-openproxy@mail.imc.org Tue Oct 7 18:20:21 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25723 for ; Tue, 7 Oct 2003 18:20:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A70Bx-0004cL-00 for opes-archive@ietf.org; Tue, 07 Oct 2003 18:20:29 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A70Bx-0004cI-00 for opes-archive@ietf.org; Tue, 07 Oct 2003 18:20:29 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97M8lKP048120 for ; Tue, 7 Oct 2003 15:08:47 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h97M8lqK048119 for ietf-openproxy-bks; Tue, 7 Oct 2003 15:08:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97M8jKP048113 for ; Tue, 7 Oct 2003 15:08:45 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h97M8lGh058376; Tue, 7 Oct 2003 16:08:47 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h97M8lLx058375; Tue, 7 Oct 2003 16:08:47 -0600 (MDT) (envelope-from rousskov) Date: Tue, 7 Oct 2003 16:08:47 -0600 (MDT) From: Alex Rousskov To: "OPES WG (E-mail)" Subject: RE: capability negotiations In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D055310@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D055310@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 7 Oct 2003, Martin Stecher wrote: > If there are no further comments, I will use the long names here. Sounds good to me. Alex. From owner-ietf-openproxy@mail.imc.org Tue Oct 7 20:08: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 UAA28714 for ; Tue, 7 Oct 2003 20:08:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A71sa-0005c6-00 for opes-archive@ietf.org; Tue, 07 Oct 2003 20:08:36 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A71sa-0005c3-00 for opes-archive@ietf.org; Tue, 07 Oct 2003 20:08:36 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97NuWKP052708 for ; Tue, 7 Oct 2003 16:56:32 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h97NuWJE052707 for ietf-openproxy-bks; Tue, 7 Oct 2003 16:56:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h97NuUKP052702 for ; Tue, 7 Oct 2003 16:56:31 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h97NuXGh061147 for ; Tue, 7 Oct 2003 17:56:33 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h97NuXZ8061146; Tue, 7 Oct 2003 17:56:33 -0600 (MDT) (envelope-from rousskov) Date: Tue, 7 Oct 2003 17:56:33 -0600 (MDT) From: Alex Rousskov To: "OPES WG (E-mail)" Subject: RE: capability negotiations In-Reply-To: Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D055309@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 7 Oct 2003, Alex Rousskov wrote: > > Will you add the named structure member concept to the OCP core? > > Yes, with the next revision, probably this week. Done. See the latest snapshot at http://www.measurement-factory.com/tmp/opes/ Essentially, only the "structure" definition was changed from structure = "{" [ value *(SP value) ] "}" ; spaced values to structure = "{" parameters "}" ; a.k.a structure members where parameters = [anonym-parameters] [named-parameters] Alex. From owner-ietf-openproxy@mail.imc.org Tue Oct 7 20:54:19 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29904 for ; Tue, 7 Oct 2003 20:54:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A72aw-00061h-00 for opes-archive@ietf.org; Tue, 07 Oct 2003 20:54:26 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A72av-00061e-00 for opes-archive@ietf.org; Tue, 07 Oct 2003 20:54:25 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h980fIKP054126 for ; Tue, 7 Oct 2003 17:41:18 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h980fIsj054125 for ietf-openproxy-bks; Tue, 7 Oct 2003 17:41:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h980fGKP054120 for ; Tue, 7 Oct 2003 17:41:16 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h980fJGh062266 for ; Tue, 7 Oct 2003 18:41:19 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h980fJTe062265; Tue, 7 Oct 2003 18:41:19 -0600 (MDT) (envelope-from rousskov) Date: Tue, 7 Oct 2003 18:41:19 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: OCP message rendering Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I got tired from counting characters and trying to preserve correct spacing when typing OCP examples. Since OCP message format is strict and well documented for machine use, I think it is wrong for us, humans, to suffer from machine-level optimizations when typesetting OCP examples irrelevant to those optimizations. Therefore, if there are no violent objections, the following informative section will appear in the next OCP draft release: 3.2 Message Rendering OCP message samples in this specification and its application bindings are not typeset to depict syntactical details of OCP message format. Specifically, strict spacing requirements are not followed and string length is not shown in quoted strings. Thus, no rendering of an OCP message can be used to infer message format. The message format definition above is the only normative source for all implementations. In the following example, the first line contains more syntactical details, while the second line shows typical rendering of the same message in this specification. i-can {"28:http://iana.org/opes/ocp/TLS"};CRLF i-can {"http://iana.org/opes/ocp/TLS"}; Figure 4 OCP debugging and traffic visualization tools are encouraged to use the same simplifications when rendering OCP messages for human use. Rationale: OCP message syntax is optimized for the common case, which is machine use. It is awkward for humans to type valid OCP strings (because humans do not like to count characters). Spacing requirements make it awkward to type large OCP messages, and use of CRLF sequence makes it impossible to render valid OCP messages in printable subset of ASCII code. This specification text is also optimized for the common case, which is human use. Message examples are meant to illustrate important logical concepts for the implementor. The above BNF and message formatting rules are deemed sufficient to implement correct message parsers and generators. Those readers that do not like our rendering simplifications are encouraged to treat OCP messages as "binary structures" for which there is no good text mapping. Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Wed Oct 8 05:16:08 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07094 for ; Wed, 8 Oct 2003 05:16:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7AQY-0002U9-00 for opes-archive@ietf.org; Wed, 08 Oct 2003 05:16:14 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A7AQY-0002U6-00 for opes-archive@ietf.org; Wed, 08 Oct 2003 05:16:14 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h9890HKP033768 for ; Wed, 8 Oct 2003 02:00:17 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h9890H5l033767 for ietf-openproxy-bks; Wed, 8 Oct 2003 02:00:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail2.webwasher.com ([213.70.80.11]) by above.proper.com (8.12.9/8.12.8) with SMTP id h9890CKP033755 for ; Wed, 8 Oct 2003 02:00:16 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] id 0T4VRYG0; 08 Oct 2003 13:07:05 +0200 Subject: RE: OCP message rendering MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 8 Oct 2003 10:59:52 +0200 content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <75F7E67FC45F6744A7D328D41E35376D014047@mail.webwasher.com> Thread-Topic: OCP message rendering Thread-Index: AcONONHqmBPn6oFYRYip9mC9TobutAAP+xBA From: "Martin Stecher" To: "OPES WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9890GKP033763 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > I got tired from counting characters and trying to preserve correct > spacing when typing OCP examples. Since OCP message format is strict > and well documented for machine use, I think it is wrong for us, > humans, to suffer from machine-level optimizations when > typesetting OCP > examples irrelevant to those optimizations. > > ... I do not agree here. People try how examples work. We will have prototype implementations that just replay the examples from the draft and people wonder that they fail, even more if the debugging output of a working other solution shows the same output. OCP is not a binary format and as being text it is easy to copy sample messages and paste them in a telnet client, playing around with these examples. So, I am a strong supporter of having working examples somewhere. And one of the best places for me is the official draft or RFC. Line breaks are an exception, they are essential for rendering purposes, some of those need to be removed to get working samples. An alternative here could be to print a special character that marks those soft breaks for rendering purposes. That's why I'd welcome a Message Rendering Section that explains this. I can review the examples in the draft and help to ensure correct character counts and spaces. Regards Martin From owner-ietf-openproxy@mail.imc.org Wed Oct 8 06:44:21 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09070 for ; Wed, 8 Oct 2003 06:44:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Bnw-0003Gn-00 for opes-archive@ietf.org; Wed, 08 Oct 2003 06:44:28 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A7Bnv-0003Gj-00 for opes-archive@ietf.org; Wed, 08 Oct 2003 06:44:27 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98AWKKP037879 for ; Wed, 8 Oct 2003 03:32:20 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98AWKDK037878 for ietf-openproxy-bks; Wed, 8 Oct 2003 03:32:20 -0700 (PDT) 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.9/8.12.8) with ESMTP id h98AWJKP037873 for ; Wed, 8 Oct 2003 03:32:19 -0700 (PDT) (envelope-from geetham@india.hp.com) Received: from fakir.india.hp.com (fakir.india.hp.com [15.10.40.3]) by palrel13.hp.com (Postfix) with ESMTP id 18D691C01B35; Wed, 8 Oct 2003 03:32:15 -0700 (PDT) Received: from india.hp.com (ob9786.india.hp.com [15.76.97.86]) by fakir.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id QAA09063; Wed, 8 Oct 2003 16:13:47 +0530 (IST) Message-ID: <3F83E7A3.15C617B1@india.hp.com> Date: Wed, 08 Oct 2003 16:02:03 +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 WG Subject: Comments on the P Language References: 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, Please find my comments on the internet draft on P language below. It also has some suggestions for new constructs for the 'P' language. * Section 2, Syntax: While several operators are listed out along with their precedence, it may be helpful to support the commonly used parenthesized expression with an additional rule : expression = '(' expression ')' * Section 3.3 Operators: Even I did not like the use of case to distinguish operator attributes (such as case sensitivity) eg: EqualS, ContainS. On the contrary, I think it would be nice to have the operators themselves case insensitive, so EQUAL = equal = EquaL . Use of equal_i and equal_s is preferable. * Section 3.6 Assignments: I like the single assignment approach of P. However, I feel the need for a few additional statements (or Core services) to manipulate the scope of a name - for eg: 'kill' a name in the current scope. Some uses of such a construct would be: ** We could essentially acheive a private name space when modules are imported. This can be done by killing all the private variables from a module before exiting the module ( if the module is written in P). ** This is will also help in reducing name clashes that may result in use of same names from 2 different modules. The case of smtp := import ".."; http := import ".."; kill SMTP.message ; meth = message.method; ** "kill moduleName " could unload a module too. ** Another useful scope manipulation statement would be something like "inline Http" (or "use Http") statement that makes references to be resolved in the context of module Http (instead of the default behaviour of resolving in the context of *all* the modules being imported) * Section 4.1: Interpreter-module interface. ** I think we should at the minimum specify a minumum interface that must be supported by a module, such as - isDefined("membername") and so on - which could typically be provided a default behaviour by the interpreter (based on the semantics of the import statement). ** There is also a need to specify the characterisitics of the service being returned by the imported module. (or give a reference to where this info is available) *** What is the interface expected of this service? Is it a proxylet? Web service? *** How does it get access to the request/response being manipulated? *** What is the semantics of the Services.applyone(service)? Will it modify the response/request to be used further on? *** Will the interpreter employ the call-out protocol at this point? If so, does it send the response or the request? For example, in the ICAP case, is it RESPMOD or REQMOD? ** How does one specify the vectoring point (equivalent of 1,2,3,4 in IRML)? * Section 4.2: In my opinion, the case of module being a P program needs to be further thrashed out. For example: which are the valid members of a module defined using P. All the names in the program ? * Finally, with my small exposure of writing an IRML parser that generates a python rule engine, I feel this language 'P' is very well suited to be implemented in Python. In fact, if we excuse the syntactic changes, P can straight away be expressed in Python! and that's nice. Hope this helps. Incidently, are there any efforts underway to implement this language? Thanks and regards Geetha > 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 : P: Message Processing Language > Author(s) : A. Beck, A. Rousskov > Filename : draft-ietf-opes-rules-p-01.txt > Pages : 30 > Date : 2003-9-22 > > P is a simple configuration language designed for specification of > message processing instructions at application proxies. P can be used > to instruct an intermediary how to manipulate the application message > being proxied. Such instructions are needed in an Open Pluggable Edge > Services (OPES) context. > From owner-ietf-openproxy@mail.imc.org Wed Oct 8 10:44:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18357 for ; Wed, 8 Oct 2003 10:44:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7FYm-0005zV-00 for opes-archive@ietf.org; Wed, 08 Oct 2003 10:45:04 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A7FYm-0005zR-00 for opes-archive@ietf.org; Wed, 08 Oct 2003 10:45:04 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98EX6KP048729 for ; Wed, 8 Oct 2003 07:33:06 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98EX6SO048728 for ietf-openproxy-bks; Wed, 8 Oct 2003 07:33:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail2.webwasher.com ([213.70.80.11]) by above.proper.com (8.12.9/8.12.8) with SMTP id h98EX3KP048696 for ; Wed, 8 Oct 2003 07:33:05 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] id GV0SEAMH; 08 Oct 2003 18:40:08 +0200 content-class: urn:content-classes:message Subject: RE: capability negotiations MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 8 Oct 2003 16:32:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <75F7E67FC45F6744A7D328D41E35376D055316@mail.webwasher.com> Thread-Topic: capability negotiations Thread-Index: AcONMprWcUwOJlleTUmcbGW8BETY0QAdYdhg From: "Martin Stecher" To: "OPES WG (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h98EX5KP048723 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi, I do not really like that a structure does now start with either SP or CRLF right after the bracket. (No wonder that you want to change rendering, looks ugly in the original way ;-) I think, we could easily solve by defining the BNF this way: message = name [SP anonym-parameters] [CRLF named-parameters] [CRLF payload] ";" CRLF anonym-parameters = value *(SP value) ; spaced values named-parameters = named-value *(CRLF named-value) ; CRLF-separated values list-parameters = value *("," value) ; comma-separated payload = data value = atom / structure / list named-value = name ":" SP value atom = bare-value / quoted-value structure = "{" [named-parameters] / [anonym-parameters [CRLF named-parameters]] "}" list = "(" [list-parameters] ")" Then syntax is again easy to write, no problem with the spaces I think. The only burden remains to count characters for quoted strings (but since my text editorn shows number of selected characters, that is not too bad). Regards Martin > -----Original Message----- > From: owner-ietf-openproxy@mail.imc.org > [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of Alex Rousskov > Sent: Wednesday, October 08, 2003 1:57 AM > To: OPES WG (E-mail) > Subject: RE: capability negotiations > > > > > On Tue, 7 Oct 2003, Alex Rousskov wrote: > > > > Will you add the named structure member concept to the OCP core? > > > > Yes, with the next revision, probably this week. > > Done. See the latest snapshot at > http://www.measurement-factory.com/tmp/opes/ > > Essentially, only the "structure" definition was changed from > > structure = "{" [ value *(SP value) ] "}" ; spaced values > > to > > structure = "{" parameters "}" ; a.k.a structure members > > where > > parameters = [anonym-parameters] [named-parameters] > > Alex. > > ------------------------------------------------------------ > This mail has been scanned by debian3-smtp > (WebWasher 4.4.1 Build 652) > ------------------------------------------------------------ > From owner-ietf-openproxy@mail.imc.org Wed Oct 8 13:07: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 NAA27813 for ; Wed, 8 Oct 2003 13:07:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Hmp-0001Hg-00 for opes-archive@ietf.org; Wed, 08 Oct 2003 13:07:43 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A7Hmo-0001Hd-00 for opes-archive@ietf.org; Wed, 08 Oct 2003 13:07:42 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98GkxKP056222 for ; Wed, 8 Oct 2003 09:46:59 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98Gkx9a056221 for ietf-openproxy-bks; Wed, 8 Oct 2003 09:46:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98GkvKP056215 for ; Wed, 8 Oct 2003 09:46:58 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h98GkwGh085246; Wed, 8 Oct 2003 10:46:58 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h98GkwOg085245; Wed, 8 Oct 2003 10:46:58 -0600 (MDT) (envelope-from rousskov) Date: Wed, 8 Oct 2003 10:46:58 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: RE: OCP message rendering In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D014047@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D014047@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 will reverse the changes and document line breaks exceptions in the message rendering section. I am not sure whether it is a good idea to add a special "soft break" character (e.g., '\' to follow C and Unix shell convention). Using your own arguments, people may try to use those "soft break" characters in real world and complain that they do not work. Anybody thinks it is a good idea to add '\' for rendering purposes only? One solution would be to make SP and CRLF interchangeable, but that complicates parsing. MIME has something like that (implied LWS rule), but virtually no HTTP agent we tested supported it correctly! Finally, what do you think about indentation? Can we still use it for rendering purposes? Please? :-) { n1: v1 n2: { n21: v21 n22: v22 } } looks/reads much better than { n1: v1 n2: { n21: v21 n22: v22 } } Comments/opinions? Thanks, Alex. On Wed, 8 Oct 2003, Martin Stecher wrote: > > > > > > I got tired from counting characters and trying to preserve correct > > spacing when typing OCP examples. Since OCP message format is strict > > and well documented for machine use, I think it is wrong for us, > > humans, to suffer from machine-level optimizations when > > typesetting OCP > > examples irrelevant to those optimizations. > > > > ... > > I do not agree here. > People try how examples work. We will have prototype implementations that > just replay the examples from the draft and people wonder that they fail, > even more if the debugging output of a working other solution shows the > same output. > OCP is not a binary format and as being text it is easy to copy sample > messages and paste them in a telnet client, playing around with these > examples. > So, I am a strong supporter of having working examples somewhere. > And one of the best places for me is the official draft or RFC. > > Line breaks are an exception, they are essential for rendering purposes, > some of those need to be removed to get working samples. An alternative > here could be to print a special character that marks those soft breaks > for rendering purposes. > That's why I'd welcome a Message Rendering Section that explains this. > > I can review the examples in the draft and help to ensure correct character > counts and spaces. > > Regards > Martin > > From owner-ietf-openproxy@mail.imc.org Wed Oct 8 13:31:33 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28582 for ; Wed, 8 Oct 2003 13:31:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7IA0-0001Z8-00 for opes-archive@ietf.org; Wed, 08 Oct 2003 13:31:40 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A7I9y-0001Z5-00 for opes-archive@ietf.org; Wed, 08 Oct 2003 13:31:39 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98HH8KP058268 for ; Wed, 8 Oct 2003 10:17:08 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98HH890058267 for ietf-openproxy-bks; Wed, 8 Oct 2003 10:17:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98HH6KP058262 for ; Wed, 8 Oct 2003 10:17:06 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h98HH7Gh086056; Wed, 8 Oct 2003 11:17:07 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h98HH7XN086055; Wed, 8 Oct 2003 11:17:07 -0600 (MDT) (envelope-from rousskov) Date: Wed, 8 Oct 2003 11:17:07 -0600 (MDT) From: Alex Rousskov To: "OPES WG (E-mail)" Subject: RE: capability negotiations In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D055316@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D055316@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 8 Oct 2003, Martin Stecher wrote: > I do not really like that a structure does now start with either SP > or CRLF right after the bracket. I like it 50%. The leading SP is indeed a bug that should be fixed. Leading CRLF is intentional -- it allows the parser to switch to named-value parsing mode by looking ahead one character only. Incidently, it makes syntax constructs simpler and also follows classic C formatting style. How about this compromise (get rid of leading SP, leave leading CRLF): message = name [SP anonym-parameters] [CRLF named-parameters CRLF] [CRLF payload] ";" CRLF anonym-parameters = value *(SP value) ; spaced values named-parameters = named-value *(CRLF named-value) ; CRLF-separated values list-parameters = value *("," value) ; comma-separated payload = data value = atom / structure / list named-value = name ":" SP value atom = bare-value / quoted-value structure = "{" [anonym-parameters] [CRLF named-parameters CRLF] "}" list = "(" [list-parameters] ")" The above is (should be) identical to your proposal, except: - named-parameters always start with CRLF, making parsing optimizations possible - named-parameters always end with CRLF, making the layout classic C-like and allowing for easier MIME-style payload identification (CRLFCRLF or CRLF; terminates "headers"), a very useful parsing optimization For example, CMD1; CMD2 { n1: v1 n2: { n21: {v21a v21b} n22: (v22a,v22b) } }; CMD3 1 2 3 n1: v1 n2: v2 ; I think we actually migrated to an even cleaner/simpler syntax with all these named-members-related changes! Any corrections or objections? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Wed Oct 8 15:14:20 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04314 for ; Wed, 8 Oct 2003 15:14:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7JlT-00033n-00 for opes-archive@ietf.org; Wed, 08 Oct 2003 15:14:28 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A7JlT-00033h-00 for opes-archive@ietf.org; Wed, 08 Oct 2003 15:14:27 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98J0UKP064054 for ; Wed, 8 Oct 2003 12:00:30 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98J0UqT064053 for ietf-openproxy-bks; Wed, 8 Oct 2003 12:00:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail2.webwasher.com ([213.70.80.11]) by above.proper.com (8.12.9/8.12.8) with SMTP id h98J0RKP064044 for ; Wed, 8 Oct 2003 12:00:29 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] id H9AA4EJP; 08 Oct 2003 23:07:34 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: OCP message rendering Date: Wed, 8 Oct 2003 21:00:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <75F7E67FC45F6744A7D328D41E35376D01404C@mail.webwasher.com> Thread-Topic: OCP message rendering Thread-Index: AcONu8z6sKEJeDnPQ3uK2IDwk4uJ2QAEcWRQ From: "Martin Stecher" To: "OPES WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h98J0TKP064049 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > I will reverse the changes and document line breaks exceptions > in the message rendering section. Thank you. > > I am not sure whether it is a good idea to add a special "soft > break" character (e.g., '\' to follow C and Unix shell convention). > Using your own arguments, people may try to use those "soft break" > characters in real world and complain that they do not work. > > Anybody thinks it is a good idea to add '\' for rendering > purposes only? I am also not 100% sure. But such a character could then easily be used to do a "Replace All". I hope that soft breaks in text will not be needed often. But if we need to add, the example will not work directly neither with CRLF nor with \CRLF. Easy transformation to working code is a plus I think. > > One solution would be to make SP and CRLF interchangeable, but > that complicates parsing. MIME has something like that (implied LWS > rule), but virtually no HTTP agent we tested supported it correctly! > > Finally, what do you think about indentation? Can we still > use it for rendering purposes? Please? :-) ... > Comments/opinions? I agree, that this is much nicer. But it will break many more examples than soft line breaks. I think we either need to define in OCP that any number of TAB characters are allowed after CRLF or forget about the indentation in the text. We could replace all existing CRLF in the BNF with NewLine and define NewLine = CRLF *(TAB) ; if TAB is the correct name for that char Regards Martin From owner-ietf-openproxy@mail.imc.org Wed Oct 8 15:32:10 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05615 for ; Wed, 8 Oct 2003 15:32:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7K2k-0003NZ-00 for opes-archive@ietf.org; Wed, 08 Oct 2003 15:32:18 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A7K2j-0003NU-00 for opes-archive@ietf.org; Wed, 08 Oct 2003 15:32:17 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98JDhKP064565 for ; Wed, 8 Oct 2003 12:13:43 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98JDh0B064564 for ietf-openproxy-bks; Wed, 8 Oct 2003 12:13:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail2.webwasher.com ([213.70.80.11]) by above.proper.com (8.12.9/8.12.8) with SMTP id h98JDeKP064551 for ; Wed, 8 Oct 2003 12:13:41 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] id 7UHW4UFC; 08 Oct 2003 23:20:49 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: capability negotiations Date: Wed, 8 Oct 2003 21:13:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <75F7E67FC45F6744A7D328D41E35376D01404D@mail.webwasher.com> Thread-Topic: capability negotiations Thread-Index: AcONwAH1IoBrtukTSrSrx1ldvGS+mwADmzBA From: "Martin Stecher" To: "OPES WG (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h98JDgKP064560 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > > I do not really like that a structure does now start with either SP > > or CRLF right after the bracket. > > I like it 50%. The leading SP is indeed a bug that should be fixed. > > Leading CRLF is intentional -- it allows the parser to switch to > named-value parsing mode by looking ahead one character only. > Incidently, it makes syntax constructs simpler and also follows > classic C formatting style. I got the same idea after posting the last message. Although I think it could be handled without the CRLF (parse a value, check whether it is also a name and followed by a colon, if yes switch to named-parameter), I agree, that an indication in front is better. We have it for all other elements in OCP, so we should have it here too. > How about this compromise (get rid of > leading SP, leave leading CRLF): > > message = name [SP anonym-parameters] > [CRLF named-parameters CRLF] > [CRLF payload] > ";" CRLF > > anonym-parameters = value *(SP value) ; spaced values > named-parameters = named-value *(CRLF named-value) ; > CRLF-separated values > list-parameters = value *("," value) ; > comma-separated > payload = data > > value = atom / structure / list > named-value = name ":" SP value > atom = bare-value / quoted-value > structure = "{" [anonym-parameters] [CRLF named-parameters CRLF] "}" > list = "(" [list-parameters] ")" > > The above is (should be) identical to your proposal, except: > > - named-parameters always start with CRLF, > making parsing optimizations possible > > - named-parameters always end with CRLF, > making the layout classic C-like and > allowing for easier MIME-style payload > identification (CRLFCRLF or CRLF; terminates > "headers"), a very useful parsing optimization > > For example, > > CMD1; > > CMD2 { > n1: v1 > n2: { > n21: {v21a v21b} > n22: (v22a,v22b) > } > }; > > CMD3 1 2 3 > n1: v1 > n2: v2 > ; > Agreed, regarding the syntax of structures. > > I think we actually migrated to an even cleaner/simpler syntax with > all these named-members-related changes! Any corrections or > objections? > Almost perfect, IMO. I don't like yet that payload is separated with an empty line from headers in case of named parameters but starts on a new line if there are only anonymous params. And the semicolon should either always or never start on a new line, I think. So, how about this little change? message = name [SP anonym-parameters] CRLF [named-parameters CRLF] [payload CRLF] ";" CRLF Every element, but anonymous parameters, starts on a new line. Regards Martin From owner-ietf-openproxy@mail.imc.org Wed Oct 8 16:18:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07425 for ; Wed, 8 Oct 2003 16:18:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Klw-0003tx-00 for opes-archive@ietf.org; Wed, 08 Oct 2003 16:19:00 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A7Klv-0003tk-00 for opes-archive@ietf.org; Wed, 08 Oct 2003 16:18:59 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98K52KP066324 for ; Wed, 8 Oct 2003 13:05:02 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98K52qJ066323 for ietf-openproxy-bks; Wed, 8 Oct 2003 13:05:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98K4wKP066313 for ; Wed, 8 Oct 2003 13:05:01 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h98K50Gh091600; Wed, 8 Oct 2003 14:05:00 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h98K50QX091599; Wed, 8 Oct 2003 14:05:00 -0600 (MDT) (envelope-from rousskov) Date: Wed, 8 Oct 2003 14:05:00 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: RE: OCP message rendering In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D01404C@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D01404C@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 8 Oct 2003, Martin Stecher wrote: > I am also not 100% sure. But such a character could then easily be > used to do a "Replace All". I hope that soft breaks in text will not > be needed often. But if we need to add, the example will not work > directly neither with CRLF nor with \CRLF. Easy transformation to > working code is a plus I think. OK. I will document '\'. > I agree, that this is much nicer. But it will break many more > examples than soft line breaks. But this only makes a difference for editors that allow selecting multi-line blocks of text in the horizontal-middle of a page. With most editors, cut-and-paste from an RFC text does not work anyway because _all_ RFC text is indented, including any examples! Thus, normally, a person would have to remove indentation from examples anyway. > I think we either need to define in OCP that any number of TAB > characters are allowed after CRLF or forget about the indentation in > the text. > > We could replace all existing CRLF in the BNF with NewLine and > define NewLine = CRLF *(TAB) ; if TAB is the correct name for that char It would have to be CRLF*(SP|HT) and it will slow down parsers a little. I would vote against such syntax change. I would prefer to separate rendering from the traffic on the wire once and for all, but I do not want to make a big deal out of it. If nobody else supports "nice rendering", I will abandon the idea until RFC default format becomes something better than plain text. Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Wed Oct 8 17:03:09 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09137 for ; Wed, 8 Oct 2003 17:03:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7LSn-0004RJ-00 for opes-archive@ietf.org; Wed, 08 Oct 2003 17:03:17 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A7LSn-0004RG-00 for opes-archive@ietf.org; Wed, 08 Oct 2003 17:03:17 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98KnfKP067536 for ; Wed, 8 Oct 2003 13:49:41 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98KnfWW067535 for ietf-openproxy-bks; Wed, 8 Oct 2003 13:49:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98KneKP067529 for ; Wed, 8 Oct 2003 13:49:40 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h98KngGh092807; Wed, 8 Oct 2003 14:49:42 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h98KnfdL092806; Wed, 8 Oct 2003 14:49:41 -0600 (MDT) (envelope-from rousskov) Date: Wed, 8 Oct 2003 14:49:41 -0600 (MDT) From: Alex Rousskov To: "OPES WG (E-mail)" Subject: RE: capability negotiations In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D01404D@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D01404D@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 8 Oct 2003, Martin Stecher wrote: > Agreed, regarding the syntax of structures. Great. > I don't like yet that payload is separated with an empty line from > headers in case of named parameters but starts on a new line if > there are only anonymous params. Yeah. > And the semicolon should either always or never start on a new line, > I think. I like being able to write simple messages on one line CMD 1 2 3 4; This would look worse, IMO: CMD 1 2 3 4 ; There is virtually no difference for the parser, I think. This is a purely visual/presentational effect. One-liners are nice when you brag about how compact OCP can be. > So, how about this little change? > > message = name [SP anonym-parameters] CRLF > [named-parameters CRLF] > [payload CRLF] > ";" CRLF > > Every element, but anonymous parameters, starts on a new line. This does not allow for fast separation of "header" and payload using a unique CRLFCRLF sequence. The latter is useful to make avoid parsing partial input buffers until they are likely to contain complete message headers. I would like to keep simple messages on one line. How about always separating payload with CRLFCRLF while still allowing for one-liners: message = name [SP anonym-parameters] [CRLF named-parameters] [CRLF CRLF payload] ";" CRLF Every element, including anonymous parameters, starts with its own unique sequence: SP, CRLF, and CRLFCRLF, and ;CRLF. This would result in a very simple logic: 1. Parse name. 2. parse anonym-parameters if the next character is SP 3. parse named-parameters if next characters are CRLF but not CRLFCRLF 4. parse payload if next characters are CRLFCRLF 5. parse trailer: ;CRLF while allowing for an optimization: - Keep buffering until CRLFCRLF or ;CRLF is found or the buffer is full. We can go further and replace [CRLF CRLF payload] with [":" CRLF payload] to avoid the "but not CRLFCRLF" clause above, but let's make MIME fans comfortable, I guess. This is probably equivalent to your last proposal except I preserved one-liners and made payload easier to find without parsing. Objections or further improvements? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Wed Oct 8 17:34: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 RAA10316 for ; Wed, 8 Oct 2003 17:34:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Lwu-0004mA-00 for opes-archive@ietf.org; Wed, 08 Oct 2003 17:34:24 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A7Lwt-0004m7-00 for opes-archive@ietf.org; Wed, 08 Oct 2003 17:34:24 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98LMMKP068748 for ; Wed, 8 Oct 2003 14:22:22 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98LMMvq068747 for ietf-openproxy-bks; Wed, 8 Oct 2003 14:22:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail2.webwasher.com ([213.70.80.11]) by above.proper.com (8.12.9/8.12.8) with SMTP id h98LMKKP068732 for ; Wed, 8 Oct 2003 14:22:20 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] id 1M7IZY6D; 09 Oct 2003 01:29:27 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: capability negotiations X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Wed, 8 Oct 2003 23:22:14 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D05531F@mail.webwasher.com> Thread-Topic: capability negotiations Thread-Index: AcON3bQ0CL2npXheTwKkC5Wx2ZdMNQABFg9g From: "Martin Stecher" To: "OPES WG (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h98LMLKP068743 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > > Agreed, regarding the syntax of structures. > > Great. > > > I don't like yet that payload is separated with an empty line from > > headers in case of named parameters but starts on a new line if > > there are only anonymous params. > > Yeah. > > > And the semicolon should either always or never start on a new line, > > I think. > > I like being able to write simple messages on one line > > CMD 1 2 3 4; > > This would look worse, IMO: > > CMD 1 2 3 4 > ; > > There is virtually no difference for the parser, I think. This is a > purely visual/presentational effect. One-liners are nice when you brag > about how compact OCP can be. > > > So, how about this little change? > > > > message = name [SP anonym-parameters] CRLF > > [named-parameters CRLF] > > [payload CRLF] > > ";" CRLF > > > > Every element, but anonymous parameters, starts on a new line. > > This does not allow for fast separation of "header" and payload using > a unique CRLFCRLF sequence. The latter is useful to make avoid parsing > partial input buffers until they are likely to contain complete > message headers. > > I would like to keep simple messages on one line. How about always > separating payload with CRLFCRLF while still allowing for one-liners: > > message = name [SP anonym-parameters] > [CRLF named-parameters] > [CRLF CRLF payload] > ";" CRLF > [...] > > This is probably equivalent to your last proposal except I preserved > one-liners and made payload easier to find without parsing. Yes, great. Let's do it that way. Martin From owner-ietf-openproxy@mail.imc.org Wed Oct 8 17:49: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 RAA10839 for ; Wed, 8 Oct 2003 17:49:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7MBs-0004wK-00 for opes-archive@ietf.org; Wed, 08 Oct 2003 17:49:52 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A7MBs-0004wG-00 for opes-archive@ietf.org; Wed, 08 Oct 2003 17:49:52 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98LcDKP069356 for ; Wed, 8 Oct 2003 14:38:13 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98LcD1q069355 for ietf-openproxy-bks; Wed, 8 Oct 2003 14:38:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98LcBKP069348 for ; Wed, 8 Oct 2003 14:38:12 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h98LcDGh094200; Wed, 8 Oct 2003 15:38:13 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h98LcDKk094199; Wed, 8 Oct 2003 15:38:13 -0600 (MDT) (envelope-from rousskov) Date: Wed, 8 Oct 2003 15:38:13 -0600 (MDT) From: Alex Rousskov To: Geetha Manjunath cc: OPES WG Subject: Re: Comments on the P Language In-Reply-To: <3F83E7A3.15C617B1@india.hp.com> Message-ID: References: <3F83E7A3.15C617B1@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 Wed, 8 Oct 2003, Geetha Manjunath wrote: > Please find my comments on the internet draft on P language below. > It also has some suggestions for new constructs for the 'P' > language. Appreciate the comments! > * Section 2, Syntax: While several operators are listed out along > with their precedence, it may be helpful to support the commonly > used parenthesized expression with an additional rule : expression > = '(' expression ')' Mea culpa. Now fixed at http://www.measurement-factory.com/tmp/opes/ > * Section 3.3 Operators: Even I did not like the use of case to > distinguish operator attributes (such as case sensitivity) eg: EqualS, > ContainS. > On the contrary, I think it would be nice to have the operators > themselves case insensitive, so EQUAL = equal = EquaL . Use of equal_i > and equal_s is preferable. I agree that using case to distinguish operators is a bad idea. I have a better(?), not yet documented, idea. String should have case sensitivity attached to them by module methods that produce them. String constants would default to case-sensitive. This will make it possible to compare, say, HTTP request method with "GET" or "connect" constants and always get "correct" result depending on protocol sensitivity rules. This is a big problem with string comparison in the current spec -- one have to be very careful to use the right comparison operator. With sensitive strings (rather than operators), the module authors would take care of most common cases by returning strings with appropriate sensitivity. case_sensitive() and case_insensitive() Core methods are provided to force particular sensitivity mode when needed. Comparing a case sensitive string with a case insensitive string will result in case insensitive comparison. This needs further thought/polishing. Have you seen sensitive strings anywhere? Do you think this approach will work? > * Section 3.6 Assignments: I like the single assignment approach of > P. However, I feel the need for a few additional statements (or Core > services) to manipulate the scope of a name - for eg: 'kill' a name > in the current scope. I have rejected scope for the sake of simplicity. I could not find convincing examples where it would be really needed. With single-assignment approach, global scope is needed to name expressions based on external conditions: if (condition) { name = value1; } else { name = value2; } > Some uses of such a construct would be: > ** We could essentially acheive a private name space when modules are > imported. This can be done by killing all the private variables from a > module before exiting the module ( if the module is written in P). If a name is not used outside the module, the optimizer will remove it. Thus, the above is only helpful to avoid name collision. If this becomes a true problem, "local" variables should be introduced into the language. Personally, I doubt many general-purpose modules would be written as P programs. > ** This is will also help in reducing name clashes that may result in > use of same names from 2 different modules. The case of > smtp := import ".."; > http := import ".."; > kill SMTP.message ; > meth = message.method; I would prefer to see more explicit Http.message.method in the above case. > ** "kill moduleName " could unload a module too. An optimizer can do that once a module is unused. Again, this seems to be useful only to avoid name collisions. > ** Another useful scope manipulation statement would be something like > "inline Http" (or "use Http") statement that makes references to be > resolved in the context of module Http (instead of the default > behaviour of resolving in the context of *all* the modules being > imported) Are you talking about the difference between use and require in Perl? I agree that adding require would be a good solution if many modules are written in P, but I think to support modules written in P well, more things like explicit exported or explicit local variables will need to be added. > * Section 4.1: Interpreter-module interface. > ** I think we should at the minimum specify a minumum interface that > must be supported by a module, such as - isDefined("membername") and so > on - which could typically be provided a default behaviour by the > interpreter (based on the semantics of the import statement). Not sure what general interface functions we can document. Can you give more examples? Is isDefined really needed? If something is not defined, P interpreter will raise a failure. Is that not sufficient to detect undefined things? > ** There is also a need to specify the characterisitics of the service > being returned by the imported module. (or give a reference to where > this info is available) I agree that service interface needs to be documented. > *** What is the interface expected of this service? Is it a proxylet? > Web service? Whatever interface the service provides and P implementation host supports. > *** How does it get access to the request/response being manipulated? Implementation dependent. > *** What is the semantics of the Services.applyone(service)? Will it > modify the response/request to be used further on? This needs to be documented. I think the semantics should be apply once and then continue interpretation. However, we need to document whether named expressions may change after service invocation: a = message.headers.have("Via"); // suppose there is no Via if (not a) { Services.apply(service); // adds Via } if (a) { // should this be executed? } My feeling is that the computed (used) value should not change. Assignment is not a macro. > *** Will the interpreter employ the call-out protocol at this point? If > so, does it send the response or the request? For example, in the ICAP > case, is it RESPMOD or REQMOD? It may employ OCP. I think that services need service-specific configuration parameters that determine mode and what needs to be supplied (e.g., request, response, or both). > ** How does one specify the vectoring point (equivalent of 1,2,3,4 in > IRML)? Application-dependent. HTTP Adaptation draft or other documents may document this as a part of HttpProxy module description. > * Section 4.2: In my opinion, the case of module being a P program needs > to be further thrashed out. For example: which are the valid members of > a module defined using P. All the names in the program ? Yes, for now. Import simply loads the program into the namespace. Again, I agree that if P modules in P become popular, more control would be needed. The current preference is to start with something small and simple. > * Finally, with my small exposure of writing an IRML parser that > generates a python rule engine, I feel this language 'P' is very > well suited to be implemented in Python. In fact, if we excuse the > syntactic changes, P can straight away be expressed in Python! and > that's nice. I am not a big fan of languages that do not catch variable name typos, but I am glad you think that a Python implementation would be simple. I agree that it may be possible to write a P-to-Python converter. > Incidently, are there any efforts underway to implement this > language? Personally, I have not seen any real demand for P (or IRML for that matter) yet. Thanks a lot for your feedback. I hope that my "we want to keep it simpler for now" responses did not discourage you. This is just a starting point. With sufficient demand and real-world use, we should be able to polish and enhance the language. Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Wed Oct 8 19:37:08 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15020 for ; Wed, 8 Oct 2003 19:37:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Nro-0005xz-00 for opes-archive@ietf.org; Wed, 08 Oct 2003 19:37:16 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A7Nrn-0005xw-00 for opes-archive@ietf.org; Wed, 08 Oct 2003 19:37:16 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98NMLKP072795 for ; Wed, 8 Oct 2003 16:22:21 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h98NMLIt072794 for ietf-openproxy-bks; Wed, 8 Oct 2003 16:22:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h98NMJKP072787 for ; Wed, 8 Oct 2003 16:22:19 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h98NMLGh097163; Wed, 8 Oct 2003 17:22:21 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h98NMLRB097162; Wed, 8 Oct 2003 17:22:21 -0600 (MDT) (envelope-from rousskov) Date: Wed, 8 Oct 2003 17:22:21 -0600 (MDT) From: Alex Rousskov To: "OPES WG (E-mail)" Subject: RE: capability negotiations In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D05531F@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D05531F@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 8 Oct 2003, Martin Stecher wrote: > > message = name [SP anonym-parameters] > > [CRLF named-parameters] > > [CRLF CRLF payload] > > ";" CRLF > > > Yes, great. Let's do it that way. This BNF change and new rendering caveats are now committed. The web site has an updated version. Thank you. Now, what I really want is to add optional namespace prefixes to parameter and message names: "opes://vendorA/BU1::My-Extension". Just kidding. We do need i18n-related review of the BNF though. We already support Unicode in quoted strings, but I am worried that ASCII-restricted bare names go against current internationalization requirements. Alex. From owner-ietf-openproxy@mail.imc.org Thu Oct 9 04:09:10 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10999 for ; Thu, 9 Oct 2003 04:09:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7VrH-0003Fn-00 for opes-archive@ietf.org; Thu, 09 Oct 2003 04:09:15 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A7VrG-0003Fk-00 for opes-archive@ietf.org; Thu, 09 Oct 2003 04:09:15 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h997tLKP037278 for ; Thu, 9 Oct 2003 00:55:21 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h997tLdl037277 for ietf-openproxy-bks; Thu, 9 Oct 2003 00:55:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail2.webwasher.com ([213.70.80.11]) by above.proper.com (8.12.9/8.12.8) with SMTP id h997tIKP037220 for ; Thu, 9 Oct 2003 00:55:19 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] id Q2EM7E20; 09 Oct 2003 12:02:18 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: OCP message rendering X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Thu, 9 Oct 2003 09:55:06 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D0E6565@mail.webwasher.com> Thread-Topic: OCP message rendering Thread-Index: AcONONHqmBPn6oFYRYip9mC9TobutABAVHMg From: "Martin Stecher" To: "OPES WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h997tKKP037269 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > I got tired from counting characters... I now moved this work to a spreadsheet ;-) When typing manual examples, I type the string into cell A1 of my spreadsheet and then copy the quoted value with correct size from another cell that has this formula: =""""&LEN(A1)&":"&A1&"""" Regards Martin From owner-ietf-openproxy@mail.imc.org Fri Oct 10 03:55: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 DAA13267 for ; Fri, 10 Oct 2003 03:55:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7s7o-0003a7-00 for opes-archive@ietf.org; Fri, 10 Oct 2003 03:55:48 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A7s7m-0003a3-00 for opes-archive@ietf.org; Fri, 10 Oct 2003 03:55:47 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9A7ekZA060829 for ; Fri, 10 Oct 2003 00:40:46 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9A7ekiw060828 for ietf-openproxy-bks; Fri, 10 Oct 2003 00:40:46 -0700 (PDT) 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 h9A7eiZA060806 for ; Fri, 10 Oct 2003 00:40:45 -0700 (PDT) (envelope-from geetham@india.hp.com) Received: from redsea.india.hp.com (redsea.india.hp.com [15.76.97.3]) by atlrel9.hp.com (Postfix) with ESMTP id 017E01C0142A; Fri, 10 Oct 2003 03:40:39 -0400 (EDT) Received: from india.hp.com (ob9786.india.hp.com [15.76.97.86]) by redsea.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id NAA05338; Fri, 10 Oct 2003 13:19:55 +0530 (IST) Message-ID: <3F866273.293AEF3A@india.hp.com> Date: Fri, 10 Oct 2003 13:10:35 +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 WG Subject: Re: Comments on the P Language References: <3F83E7A3.15C617B1@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, Thanks for the quick response. > > expression = '(' expression ')' > > Mea culpa. Now fixed at http://www.measurement-factory.com/tmp/opes/ That's nice. > I agree that using case to distinguish operators is a bad idea. I have > a better(?), not yet documented, idea. String should have case > sensitivity attached to them by module methods that produce them. > String constants would default to case-sensitive. This will make it > possible to compare, say, HTTP request method with "GET" or "connect" > constants and always get "correct" result depending on protocol > sensitivity rules. I like this idea! > case_sensitive() and case_insensitive() Core methods are provided to > force particular sensitivity mode when needed. Comparing a case > sensitive string with a case insensitive string will result in case > insensitive comparison. Here I still prefer having different operators for sensitive and insensitive. However, based on your idea above, we could probably have a default behaviour defined for comparison (which is based on the attributes of the string). > This needs further thought/polishing. Have you seen sensitive strings > anywhere? Do you think this approach will work? I cannot recall seeing it anywhere else at the language level ... only sensitivity at operators/API. But yes, python allows defining regular expressions that can be optionally case insensitive (compile method), similarly Java specifies some classes whose objects can have case sensitivity as an attribute for comparison. > I have rejected scope for the sake of simplicity. I could not find > convincing examples where it would be really needed. With > single-assignment approach, global scope is needed to name expressions > based on external conditions: Yes, the need for global assignment is clear. > If a name is not used outside the module, the optimizer will remove > it. Thus, the above is only helpful to avoid name collision. If this > becomes a true problem, "local" variables should be introduced into > the language. Personally, I doubt many general-purpose modules would > be written as P programs. Yes, the scope manipulation statements will only aid in avoiding name collision. Alternatively, you could always mandate a need to qualify any member with the module name (ie., name representing the import statement) as opposed to providing features that may result in name collision. I beleive, the optimizer cannot apriori know whether or not the name is used outside the module. What happens if the current P source file is imported in another (nested modules!) ? > I would prefer to see more explicit Http.message.method in the above > case. But, consider the case wherein a module implements an operation such as regular expression match. In that case, I would prefer to say matchRE(expr1,string) rather than re.matchRE(..) Nevertheless, it may be better to make that a language restriction itself and mandate the need to qualify members (as I mentioned in an earlier point)! > Are you talking about the difference between use and require in Perl? > I agree that adding require would be a good solution if many modules > are written in P, but I think to support modules written in P well, > more things like explicit exported or explicit local variables will > need to be added. That would be an alternative way of extending the scope - that would be more like other languages and would probably be prefered. > > * Section 4.1: Interpreter-module interface. > > ** I think we should at the minimum specify a minumum interface that > > must be supported by a module, such as - isDefined("membername") and so > > on - which could typically be provided a default behaviour by the > > interpreter (based on the semantics of the import statement). > > Not sure what general interface functions we can document. Can you > give more examples? > > Is isDefined really needed? If something is not defined, P interpreter > will raise a failure. Is that not sufficient to detect undefined > things? Yes, some things may be caught with exceptions.. How about isCaseSensitive(string) ? Assuming the new attributed string that you mentioned. I will try and list those one of these days.. As of now, I am thinking of some methods that provide reflective property. > > > ** There is also a need to specify the characterisitics of the service > > being returned by the imported module. (or give a reference to where > > this info is available) > > I agree that service interface needs to be documented. > > This needs to be documented. I think the semantics should be apply > once and then continue interpretation. However, we need to document > whether named expressions may change after service invocation: > > a = message.headers.have("Via"); // suppose there is no Via > > if (not a) { > Services.apply(service); // adds Via > } > > if (a) { > // should this be executed? > } > > My feeling is that the computed (used) value should not change. > Assignment is not a macro. As per the description in 3.6, the computed value should change! The alternative semantics can be obtained by if (not a) { Services.apply(service); } else { /* if not a */ } > > *** Will the interpreter employ the call-out protocol at this point? If > > so, does it send the response or the request? For example, in the ICAP > > case, is it RESPMOD or REQMOD? > > It may employ OCP. I think that services need service-specific > configuration parameters that determine mode and what needs to be > supplied (e.g., request, response, or both). Don't we then need to specify how to get the request and response from the Core? Do you assume that the interfaces for the request/response objects will be provided by the protocol module? > > ** How does one specify the vectoring point (equivalent of 1,2,3,4 in > > IRML)? > > Application-dependent. HTTP Adaptation draft or other documents may > document this as a part of HttpProxy module description. > > Thanks a lot for your feedback. I hope that my "we want to keep it > simpler for now" responses did not discourage you. This is just a > starting point. With sufficient demand and real-world use, we should > be able to polish and enhance the language. Personally, I have seen the need for a conditional expression (at the minimum with OR and AND) and also need for regular expression match while using IRML... Thanks for making this discussion interesting.. regards Geetha From owner-ietf-openproxy@mail.imc.org Fri Oct 10 08:51:35 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25852 for ; Fri, 10 Oct 2003 08:51:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7wk4-0002vs-00 for opes-archive@ietf.org; Fri, 10 Oct 2003 08:51:36 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A7wk3-0002vb-00 for opes-archive@ietf.org; Fri, 10 Oct 2003 08:51:36 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9ACacZA090287 for ; Fri, 10 Oct 2003 05:36:38 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9ACac73090286 for ietf-openproxy-bks; Fri, 10 Oct 2003 05:36:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail2.webwasher.com ([213.70.80.11]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9ACaaZA090277 for ; Fri, 10 Oct 2003 05:36:37 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id MJIMBEYCoutgoing id D4N50VNH; 10 Oct 2003 16:43:37 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: capability negotiations X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 10 Oct 2003 14:36:23 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D0E657F@mail.webwasher.com> Thread-Topic: capability negotiations Thread-Index: AcONwAH1IoBrtukTSrSrx1ldvGS+mwBaun3Q From: "Martin Stecher" To: "OPES WG (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9ACabZA090282 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi Alex, in this message from Wednesday > Sent: Wednesday, October 08, 2003 7:17 PM you defined > structure = "{" [anonym-parameters] [CRLF named-parameters CRLF] "}" but in OCP-Core you did now type structure = "{" [anonym-parameters] [CRLF named-parameters] "}" Typo, or did you change your mind? Regards Martin From owner-ietf-openproxy@mail.imc.org Fri Oct 10 11:40:30 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04024 for ; Fri, 10 Oct 2003 11:40:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7zNd-0005Fr-00 for opes-archive@ietf.org; Fri, 10 Oct 2003 11:40:38 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A7zNd-0005Fl-00 for opes-archive@ietf.org; Fri, 10 Oct 2003 11:40:37 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9AFE5ZA097075 for ; Fri, 10 Oct 2003 08:14:05 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9AFE516097074 for ietf-openproxy-bks; Fri, 10 Oct 2003 08:14:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail2.webwasher.com ([213.70.80.11]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9AFE2ZA097049 for ; Fri, 10 Oct 2003 08:14:03 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id R5FQTC0Routgoing id F1I97LHP; 10 Oct 2003 19:21:09 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: transfer- and content-encoding X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 10 Oct 2003 17:13:56 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D0E6584@mail.webwasher.com> Thread-Topic: transfer- and content-encoding Thread-Index: AcOPQR+W08mtBrZgTZ2xSRP3J5U0cg== From: "Martin Stecher" To: "OPES WG (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9AFE4ZA097069 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi, I got some questions when I wanted to document negotiation on transfer-encoding and content-encoding. Both are planned to be named parameters in the feature structure of NO and NR messages. Example: NO ({"38:http://iana.org/opes/ocp/HTTP/response" Transfer-Encodings: (chunked) Content-Encodings: (gzip, compress) }) SG: 5; NR {"38:http://iana.org/opes/ocp/HTTP/response" Content-Encodings: (compress) } SG: 5; So, what does this mean? The OPES processor advertises its capability to handle chunked transfer encoding. So, it has the knowledge how to remove this encoding, i.e. how to preprocess the data for the callout server in order to transfer the data without transfer encoding (with identity encoding). Because transfer encoding is hop-by-hop, we can assume that an OPES processor can do this preprocessing for every transfer-encoding it supports; the data will not come in any transfer-encoding that is unknown to the OPES processor. This negotiation is also a hint for the callout server, because it MAY introduce a transfer encoding that is handled and advertised by the OPES processor but not anything else. That all seems to work. Content encodings are different. A proxy server usually does not need to have knowledge about the content encoding; it is an end-to-end encoding. Still the OPES processor can list those content encodings it is able to remove and the callout server lists those that it is aware of. But what does this really mean? If data is gzipped and callout server did not list that encoding, does this always mean that the processor should do the preprocessing; maybe the callout server does not need the decoded data at all and preprocessing is for nothing. And what about content encodings that both agents do not support? Simply still send the data to the callout server? And is the callout server allowed to introduce a content-encoding that the OPES processor does not support? At least after it has checked the request-header (where we also not know exactly which one it will get, an original or adapted version). Comments? Clarification? Let me suggest this interpretation: Content-Encoding list sent by OPES processor: Does not advertise decoding capabilities Does only accept adapted content in one of these encodings No Content-Encoding parameter, if it does not care about new introduced encodings Content-Encoding list sent by callout server: This is the list of supported content encodings. If data is of any other encoding, OCP client shall do preprocessing if capabable, otherwise send the stuff as is. If it accepts all content-encodings, or does not care, Content-Encoding parameter is omitted. Does that work? Thank you Martin From owner-ietf-openproxy@mail.imc.org Fri Oct 10 12:01: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 MAA04716 for ; Fri, 10 Oct 2003 12:01:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7zi9-0005VN-00 for opes-archive@ietf.org; Fri, 10 Oct 2003 12:01:49 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A7zi8-0005VJ-00 for opes-archive@ietf.org; Fri, 10 Oct 2003 12:01:48 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9AFYxZA097940 for ; Fri, 10 Oct 2003 08:34:59 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9AFYx17097939 for ietf-openproxy-bks; Fri, 10 Oct 2003 08:34:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9AFYwZA097932 for ; Fri, 10 Oct 2003 08:34:58 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h9AFYxGh055441; Fri, 10 Oct 2003 09:34:59 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9AFYxnP055440; Fri, 10 Oct 2003 09:34:59 -0600 (MDT) (envelope-from rousskov) Date: Fri, 10 Oct 2003 09:34:59 -0600 (MDT) From: Alex Rousskov To: "OPES WG (E-mail)" Subject: RE: capability negotiations In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D0E657F@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D0E657F@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 10 Oct 2003, Martin Stecher wrote: > you defined > > > structure = "{" [anonym-parameters] [CRLF named-parameters CRLF] "}" > > but in OCP-Core you did now type > > structure = "{" [anonym-parameters] [CRLF named-parameters] "}" > > Typo, or did you change your mind? Oof. The change was not intentional, but I am now not sure what the "right" syntax is. No trailing CRLF above is consistent with the named-parameters syntax of the message itself because there a named-parameter may be terminated by a ';' rather than CRLF: message = name [SP anonym-parameters] [CRLF named-parameters] [CRLF CRLF payload] ";" CRLF Adding a CRLF trailer to named-parameters would make it easier to optimize parsing of named-parameters and would make the {structure} look more consistent. A trailing CRLF is what our current examples use as well. If we go down this path, we should change the above message definition (again) to make CRLF named-parameter trailer mandatory everywhere: message = name [SP anonym-parameters] ( [CRLF named-parameters CRLF CRLF payload] | [CRLF CRLF payload] ) ";" CRLF Is there a more elegant/consistent way of doing this while keeping one-liners and CRLF CRLF as a body indication? Or should we accept some inconsistency and stick with a simpler: message = name [SP anonym-parameters] [CRLF named-parameters] [CRLF CRLF payload] ";" CRLF structure = "{" [anonym-parameters] [CRLF named-parameters CRLF] "}" What's your preference? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Fri Oct 10 12:58: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 MAA07226 for ; Fri, 10 Oct 2003 12:58:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A80ba-0006FE-00 for opes-archive@ietf.org; Fri, 10 Oct 2003 12:59:06 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A80bZ-0006F1-00 for opes-archive@ietf.org; Fri, 10 Oct 2003 12:59:06 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9AGiWZA000520 for ; Fri, 10 Oct 2003 09:44:32 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9AGiWbE000519 for ietf-openproxy-bks; Fri, 10 Oct 2003 09:44:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9AGiUZA000513 for ; Fri, 10 Oct 2003 09:44:31 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h9AGiWGh057035; Fri, 10 Oct 2003 10:44:32 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9AGiVjU057034; Fri, 10 Oct 2003 10:44:31 -0600 (MDT) (envelope-from rousskov) Date: Fri, 10 Oct 2003 10:44:31 -0600 (MDT) From: Alex Rousskov To: "OPES WG (E-mail)" Subject: Re: transfer- and content-encoding In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D0E6584@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D0E6584@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 10 Oct 2003, Martin Stecher wrote: > I got some questions when I wanted to document negotiation on > transfer-encoding and content-encoding. Both are planned to be named > parameters in the feature structure of NO and NR messages. > > Example: > > NO ({"38:http://iana.org/opes/ocp/HTTP/response" > Transfer-Encodings: (chunked) > Content-Encodings: (gzip, compress) > }) > SG: 5; > NR {"38:http://iana.org/opes/ocp/HTTP/response" > Content-Encodings: (compress) > } > SG: 5; > > So, what does this mean? > > The OPES processor advertises its capability to handle chunked > transfer encoding. So, it has the knowledge how to remove this > encoding, i.e. how to preprocess the data for the callout server in > order to transfer the data without transfer encoding (with identity > encoding). Because transfer encoding is hop-by-hop, we can assume > that an OPES processor can do this preprocessing for every > transfer-encoding it supports; the data will not come in any > transfer-encoding that is unknown to the OPES processor. This > negotiation is also a hint for the callout server, because it MAY > introduce a transfer encoding that is handled and advertised by the > OPES processor but not anything else. That all seems to work. Is the following summary accurate? Transfer-Encoding list sent by OCP agent: Advertises encoding and decoding capabilities Accepts and generates only listed encodings Encodings listed earlier are preferred. Defaults to (identity) Note that HTTP/1.1 default is (identity, chunked). Also, how do we handle a situation where multiple transfer encodings are applied? > Content encodings are different. A proxy server usually does not > need to have knowledge about the content encoding; it is an > end-to-end encoding. Still the OPES processor can list those content > encodings it is able to remove and the callout server lists those > that it is aware of. But what does this really mean? If data is > gzipped and callout server did not list that encoding, does this > always mean that the processor should do the preprocessing; maybe > the callout server does not need the decoded data at all and > preprocessing is for nothing. And what about content encodings that > both agents do not support? Simply still send the data to the > callout server? And is the callout server allowed to introduce a > content-encoding that the OPES processor does not support? At least > after it has checked the request-header (where we also not know > exactly which one it will get, an original or adapted version). > > Comments? > Clarification? > > > Let me suggest this interpretation: > > Content-Encoding list sent by OPES processor: > Does not advertise decoding capabilities > Does only accept adapted content in one of these encodings > No Content-Encoding parameter, if it does not care about new introduced encodings > > Content-Encoding list sent by callout server: > This is the list of supported content encodings. > If data is of any other encoding, OCP client shall do preprocessing if capabable, otherwise send the stuff as is. > If it accepts all content-encodings, or does not care, Content-Encoding parameter is omitted. > > Does that work? I am not sure. The "if capabable, otherwise send the stuff as is" part sounds fishy. It implies that we are declaring a weak preference (please change encoding if possible) rather than negotiating an interoperability requirement. That is, it sounds like the value of Content-Encoding parameter cannot affect the result of the negotiation (but might affect future processor actions). I do agree that a typical OPES processor would not care about content encodings or know how to change them (which is an _adaptation_ while changing transfer encoding is not). Also, the processor should not prohibit content-encoding adaptations. If such a feature is needed, it should be implemented separately from these negotiations because there may be other adaptations that an OPES processor may want to prohibit. How about this simpler version: A callout server MAY send a Content-Encodings list to indicate its preferences in content encodings. Encodings listed first are preferred to other encodings. An OPES processor MAY use any content encoding when sending application messages to a callout server. If an OCP agent receives an application message that it cannot handle due to specific content encoding, the usual transaction termination rules apply. An alternative is to make early termination by processor possible: A callout server MAY send a Content-Encodings list to indicate its requirements for supported content encodings. Encodings listed first are preferred to other encodings. A special "*" identifier stands for any encoding. Empty list indicates that the callout server is not capable of handling any content encodings and, hence, does not want to receive any content. Absent parameter defaults to ("*"). An OPES processor MUST use a content encoding supported by the callout server or MUST terminate (or not initiate) the transaction that uses unsupported content encoding for application data. If an OCP agent receives an application message that it cannot handle due to specific content encoding, the usual transaction termination rules apply. Which one will work better? Also, how do we handle a situation where multiple content encodings are applied? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Fri Oct 10 17:17:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23259 for ; Fri, 10 Oct 2003 17:17:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A84e6-0002px-00 for opes-archive@ietf.org; Fri, 10 Oct 2003 17:17:58 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A84e5-0002pu-00 for opes-archive@ietf.org; Fri, 10 Oct 2003 17:17:57 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9AL0QZA009772 for ; Fri, 10 Oct 2003 14:00:26 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9AL0QFJ009771 for ietf-openproxy-bks; Fri, 10 Oct 2003 14:00:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail2.webwasher.com ([213.70.80.11]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9AL0NZA009761 for ; Fri, 10 Oct 2003 14:00:24 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id VQ50S3WXoutgoing id 43TPC9TX; 11 Oct 2003 01:07:31 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: capability negotiations X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 10 Oct 2003 23:00:18 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D014052@mail.webwasher.com> Thread-Topic: capability negotiations Thread-Index: AcOPRBI1sFQSqkymSViuqTXDC7QgUwAKE4HQ From: "Martin Stecher" To: "OPES WG (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9AL0PZA009766 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > Adding a CRLF trailer to named-parameters would make it easier to > optimize parsing of named-parameters and would make the {structure} > look more consistent. A trailing CRLF is what our current examples use > as well. If we go down this path, we should change the above message > definition (again) to make CRLF named-parameter trailer mandatory > everywhere: > > message = name [SP anonym-parameters] > ( [CRLF named-parameters CRLF CRLF payload] | [CRLF CRLF payload] ) > ";" CRLF Olala. Although being more consistent it looks very strange, I guess that people don't understand the motiviation here. This is not an option for me. Anyway let's call it option 1 for further reference. > > Is there a more elegant/consistent way of doing this while keeping > one-liners and CRLF CRLF as a body indication? Yes, I think so, see below (option 4). ------------------ > Or should we accept > some inconsistency and stick with a simpler: > > message = name [SP anonym-parameters] > [CRLF named-parameters] > [CRLF CRLF payload] > ";" CRLF > > structure = "{" [anonym-parameters] [CRLF named-parameters CRLF] "}" I think this is indeed an option. Let's call it option 2. It is a small inconsistency, but still looks good to me. ------------------ Option 3 is as shown in the OCP core in today's CVS version: message = name [SP anonym-parameters] [CRLF named-parameters] [CRLF CRLF payload] ";" CRLF structure = "{" [anonym-parameters] [CRLF named-parameters] "}" This option is consistent but has the non C-style closing bracket problem. ------------------ I would like to propose option 4, my favorite: message = name [SP anonym-parameters] [CRLF named-parameters CRLF] [CRLF payload CRLF] ";" CRLF structure = "{" [anonym-parameters] [CRLF named-parameters CRLF] "}" This is a consistent and symetric and easy syntax. It allows for single line messages. Message rendering looks good. Examples: CS; TS 88 10; DUM 88 1 0 AM-Part: request-body 15:This is my body ; DUM 88 2 0 20:no named params here ; CE Error: "13:Out of memory" ; Cons: After scanning the anonymous params, the next element could either be a named param or payload (but we do not have a real-life case for this yet). Pros: Semicolon is on the same line only for single line commands; otherwise it is always on its own line The only message with payload with know today is DUM, it will always have named params for HTTP and probably also for other applications; here it looks MIME-like (headers, empty line, body). I think, scanning is still quite easy. If you want to have the universal scanner, that allows for payload without named parameters, just check for the character after the first CRLF. If it is a digit, then there are no named-params; otherwise use the algorithm that Alex presented earlier Is this algorithm change acceptable for you? What is your favorite? Regards Martin From owner-ietf-openproxy@mail.imc.org Fri Oct 10 17:30:33 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23774 for ; Fri, 10 Oct 2003 17:30:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A84qO-00030I-00 for opes-archive@ietf.org; Fri, 10 Oct 2003 17:30:40 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A84qN-00030F-00 for opes-archive@ietf.org; Fri, 10 Oct 2003 17:30:39 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9ALJXZA010496 for ; Fri, 10 Oct 2003 14:19:33 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9ALJWEA010495 for ietf-openproxy-bks; Fri, 10 Oct 2003 14:19:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail2.webwasher.com ([213.70.80.11]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9ALJUZA010488 for ; Fri, 10 Oct 2003 14:19:31 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id P69QMR59outgoing id CCFSQERN; 11 Oct 2003 01:26:40 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: transfer- and content-encoding X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 10 Oct 2003 23:19:27 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D014053@mail.webwasher.com> Thread-Topic: transfer- and content-encoding Thread-Index: AcOPTck0nVUMjIezTlaF5RufbkE6dQAI9T8g From: "Martin Stecher" To: "OPES WG (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9ALJWZA010491 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > I got some questions when I wanted to document negotiation on > > transfer-encoding and content-encoding. Both are planned to be named > > parameters in the feature structure of NO and NR messages. > > > > Example: > > > > NO ({"38:http://iana.org/opes/ocp/HTTP/response" > > Transfer-Encodings: (chunked) > > Content-Encodings: (gzip, compress) > > }) > > SG: 5; > > NR {"38:http://iana.org/opes/ocp/HTTP/response" > > Content-Encodings: (compress) > > } > > SG: 5; > > > > So, what does this mean? > > > > The OPES processor advertises its capability to handle chunked > > transfer encoding. So, it has the knowledge how to remove this > > encoding, i.e. how to preprocess the data for the callout server in > > order to transfer the data without transfer encoding (with identity > > encoding). Because transfer encoding is hop-by-hop, we can assume > > that an OPES processor can do this preprocessing for every > > transfer-encoding it supports; the data will not come in any > > transfer-encoding that is unknown to the OPES processor. This > > negotiation is also a hint for the callout server, because it MAY > > introduce a transfer encoding that is handled and advertised by the > > OPES processor but not anything else. That all seems to work. > > Is the following summary accurate? Yes. > > Transfer-Encoding list sent by OCP agent: > Advertises encoding and decoding capabilities > Accepts and generates only listed encodings > Encodings listed earlier are preferred. > Defaults to (identity) > > Note that HTTP/1.1 default is (identity, chunked). Yes. > > Also, how do we handle a situation where multiple transfer encodings > are applied? If data is encoding with transfer encoding X and then again with encoding Y, then this must happen. If the other agent advertises both X and Y, then data can be sent with double encoding. If the other agent advertises only X, then message needs to be Y-decoded, staying X-encoded. If the other agent advertises only Y, then message needs to be decoded completly, re-encoding to Y is possible. If the other agent advertises neither X not Y, then message needs to be decoded completly. Regarding content encoding: > > How about this simpler version: > > A callout server MAY send a Content-Encodings list to > indicate its preferences in content encodings. Encodings > listed first are preferred to other encodings. An OPES > processor MAY use any content encoding when sending > application messages to a callout server. > > If an OCP agent receives an application message that it > cannot handle due to specific content encoding, the usual > transaction termination rules apply. > Fine with me. It also means that the OPES processor does not use the Content-Encodings header at all. We just still need to allow that the callout service still handles the data (for example replacing by an error message or returning unchanged) even if it does not support that encoding, rather than termination the transaction. > > An alternative is to make early termination by processor > possible: > > A callout server MAY send a Content-Encodings list to > indicate its requirements for supported content > encodings. Encodings listed first are preferred to other > encodings. A special "*" identifier stands for any > encoding. Empty list indicates that the callout server is > not capable of handling any content encodings and, hence, > does not want to receive any content. Absent parameter > defaults to ("*"). > > An OPES processor MUST use a content encoding supported > by the callout server or MUST terminate (or not initiate) > the transaction that uses unsupported content encoding > for application data. > > If an OCP agent receives an application message that it > cannot handle due to specific content encoding, the usual > transaction termination rules apply. > > Which one will work better? The first one. A typical callout service only acts on certain media types. Let's say it is a text translator. Any image will be returned unchanged. Termination of the transactions seems to be inappropriate if an image is in an encoding that the callout server does not support. An opposite example is a virus scanner that wants to parse all files. If it receives one in a content encoding that it does not understand it could always replace the content by an error message which seems still nicer to me than termination of the OCP transaction which does not define what is done with the HTTP message. BTW: A callout service that does not support common content encodings but inists to understand the data of all transferred messages should better already adapt the HTTP request and strip unsupported encodings from the Accept-Encodings header. > > Also, how do we handle a situation where multiple content > encodings are > applied? Not an issue when following your first option. Or is there one that I do not see? Regards Martin From owner-ietf-openproxy@mail.imc.org Fri Oct 10 18:04: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 SAA25236 for ; Fri, 10 Oct 2003 18:04:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A85N2-0003VG-00 for opes-archive@ietf.org; Fri, 10 Oct 2003 18:04:24 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A85N1-0003VC-00 for opes-archive@ietf.org; Fri, 10 Oct 2003 18:04:23 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9ALqBZA011525 for ; Fri, 10 Oct 2003 14:52:11 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9ALqBFL011524 for ietf-openproxy-bks; Fri, 10 Oct 2003 14:52:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9ALqAZA011519 for ; Fri, 10 Oct 2003 14:52:10 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h9ALqCGh065195; Fri, 10 Oct 2003 15:52:12 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9ALqCBQ065194; Fri, 10 Oct 2003 15:52:12 -0600 (MDT) (envelope-from rousskov) Date: Fri, 10 Oct 2003 15:52:12 -0600 (MDT) From: Alex Rousskov To: "OPES WG (E-mail)" Subject: RE: capability negotiations In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D014052@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D014052@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 10 Oct 2003, Martin Stecher wrote: > I would like to propose option 4, my favorite: > > message = name [SP anonym-parameters] > [CRLF named-parameters CRLF] > [CRLF payload CRLF] > ";" CRLF > > structure = "{" [anonym-parameters] [CRLF named-parameters CRLF] "}" > > This is a consistent and symetric and easy syntax. > It allows for single line messages. Message rendering looks good. We have a winner, I think. Fast-scanning for end-of-headers is more difficult with this option, but is still simple enough, I guess. One just have to scan for: CRLF digit / ";" CRLF I was too stuck on CRLF CRLF payload separator to see option 4 :-/. I will commit the change. Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Fri Oct 10 18:20:11 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26970 for ; Fri, 10 Oct 2003 18:20:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A85cQ-0003id-00 for opes-archive@ietf.org; Fri, 10 Oct 2003 18:20:18 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A85cP-0003ia-00 for opes-archive@ietf.org; Fri, 10 Oct 2003 18:20:17 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9AM8kZA012004 for ; Fri, 10 Oct 2003 15:08:46 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9AM8kJN012003 for ietf-openproxy-bks; Fri, 10 Oct 2003 15:08:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9AM8jZA011996 for ; Fri, 10 Oct 2003 15:08:45 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h9AM8lGh065537; Fri, 10 Oct 2003 16:08:47 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9AM8lMe065536; Fri, 10 Oct 2003 16:08:47 -0600 (MDT) (envelope-from rousskov) Date: Fri, 10 Oct 2003 16:08:47 -0600 (MDT) From: Alex Rousskov To: "OPES WG (E-mail)" Subject: RE: transfer- and content-encoding In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D014053@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D014053@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 10 Oct 2003, Martin Stecher wrote: > If data is encoding with transfer encoding X and then again with > encoding Y, then this must happen. > > If the other agent advertises both X and Y, then data can be sent with > double encoding. > If the other agent advertises only X, then message needs to be Y-decoded, > staying X-encoded. > If the other agent advertises only Y, then message needs to be decoded > completly, re-encoding to Y is possible. > If the other agent advertises neither X not Y, then message needs to be > decoded completly. In other words: An OCP agent MUST send data using only transport encoding(s) supported by its peer, regardless of the number of transport encodings applied to the application message. To satisfy previous requirement, the agent may have to partially or fully decode the application message and then re-encode it as necessary. An OCP agent receiving application data from its peer, MUST be ready to accept multiple transport encodings, in any order, if it advertised support for multiple transport encodings. Do we need to prohibit encoding sequences like (chunked,identity,chunked,identity)? The above rules do not. > Regarding content encoding: > > > > How about this simpler version: > > > > A callout server MAY send a Content-Encodings list to > > indicate its preferences in content encodings. Encodings > > listed first are preferred to other encodings. An OPES > > processor MAY use any content encoding when sending > > application messages to a callout server. > > > > If an OCP agent receives an application message that it > > cannot handle due to specific content encoding, the usual > > transaction termination rules apply. > > > > Fine with me. It also means that the OPES processor does not use > the Content-Encodings header at all. Right. > We just still need to allow that the callout service still handles > the data (for example replacing by an error message or returning unchanged) > even if it does not support that encoding, rather than termination the > transaction. I think that is implied by the above rules, but we can be more specific: The list of preferred content encodings does not imply lack of support for other encodings. OPES processor MUST NOT bypass a service just because the actual content encoding does not match service's preferences. > > Also, how do we handle a situation where multiple content > > encodings are applied? > > Not an issue when following your first option. Or is there one that > I do not see? Not an issue when following the first option. Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Sat Oct 11 14:17: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 OAA07751 for ; Sat, 11 Oct 2003 14:17:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8OJG-0006DZ-00 for opes-archive@ietf.org; Sat, 11 Oct 2003 14:17:46 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A8OJF-0006DV-00 for opes-archive@ietf.org; Sat, 11 Oct 2003 14:17:45 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9BHv5I7018563 for ; Sat, 11 Oct 2003 10:57:05 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9BHv5NR018562 for ietf-openproxy-bks; Sat, 11 Oct 2003 10:57:05 -0700 (PDT) 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 h9BHv4I7018557 for ; Sat, 11 Oct 2003 10:57:04 -0700 (PDT) (envelope-from info@utel.net) Received: from f01v-27-30.d0.club-internet.fr ([212.195.246.30] helo=jfc2.utel.net) by montage.altserver.com with esmtp (Exim 4.24) id 1A8Nz9-00040b-QI for ietf-openproxy@imc.org; Sat, 11 Oct 2003 10:57:00 -0700 Message-Id: <6.0.0.22.2.20031011192044.05591cc0@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Sat, 11 Oct 2003 19:22:32 +0200 To: "OPES WG" From: jfcm Subject: an interesting OPES application In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D014047@mail.webwasher.com> References: <75F7E67FC45F6744A7D328D41E35376D014047@mail.webwasher.com> Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-8D6EC1; boundary="=======AVGMAIL-3F8846EA6EF5=======" 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=======AVGMAIL-3F8846EA6EF5======= Content-Type: multipart/alternative; x-avg-checked=avg-ok-8D6EC1; boundary="=====================_102345865==.ALT" --=====================_102345865==.ALT Content-Type: text/plain; x-avg-checked=avg-ok-8D6EC1; charset=us-ascii; format=flowed I am sure OCP could help this guy a lot. [for information only] --------------------- URL http://www.lurhq.com/migmaf.html Release Date July 11, 2003 In late June 2003, spam-fighters from the news.admin.net-abuse.email Usenet group noticed a particular spammer seemed to be able to move his websites around at will, minute-by-minute. This activity was also pointed out in an article by Richard M. Smith of computerbytesman.com. It appeared at first that the spammer had managed to infect thousands of systems with a small webserver trojan - rotating them in and out of the DNS for the domain names he owned every 10 minutes. It made it nearly impossible for ISPs to track and shut down, as the IP addresses were largely owned by dialup users, so ISPs would be fighting a constant battle to keep track of all the reports. The sites being advertised in the emails were generally Russian porn sites, and Richard Smith pointed out the same servers were involved in a Paypal scam email he had seen. LURHQ was able to obtain a copy of the trojan - detected from suspicious activity originating from a VPN user on a firewall on a network we monitor. What we found was the trojan was not a webserver at all, but instead: a reverse proxy server. Instead of hosting the content on the victim's computer, the spammer instead maintained a "master" webserver. We have dubbed this trojan "Migmaf". Functionality of Migmaf Someone requesting the URL core.onlycoredomains.com (among several others) would be directed to one of the trojaned machines, where the connection would be in turn relayed to the master webserver. The returned page would be passed back to the trojaned machine, where it was then sent back to the requesting user's web browser. In this way it is impossible for the user to tell the actual IP address of the master server - giving the spammer's real site refuge from being shut down by his ISP. But that isn't the only service Migmaf offers to the spammer - it also listens on TCP port 81 and acts as a socks proxy server. This allows the spammer to bounce spam email through the trojaned machine to his target recipients. This means the spammer has a complete end-to-end anonymous system for spam, and it lends itself well to the kind of scams already being seen. In one scam, the spammer directs the user to enter Paypal information into a form on the spammer's server. Posters to the Usenet spam-fighting groups have also speculated that the porn sites being advertised by the spammer may be merely a front to steal credit card numbers. Migmaf has some features designed to make efficient use of resources. The trojan reports statistics and current state information back to the master webserver. The trojan actually checks to see how much available bandwidth it has by sending several hundred kilobytes of garbage data to www.microsoft.com on port 80. Because this might look like a denial-of-service attack or an exploit attempt, the trojan code actually contains the following text: "disclaimer: www.microsoft.com used for bandwith speed testing only" The copy of Migmaf we obtained was compiled at the following time: Tue Jul 8 13:33:57 2003 Since the trojan has obviously been around longer than that, we can safely assume that the author is constantly changing the code he is sending out to evade anti-virus detection or to perhaps direct the traffic to another master webserver. Migmaf itself has no spreading capability, so we don't yet know how the spammer is spreading the trojan to thousands of users. It could be piggybacked on a virus, or could perhaps use the IE exploit the Windows-Update trojan used, or it could be spread via IRC or KaZaA. One interesting thing to note is the large percentage of AOL users that seem to be infected - this may indicate a chat or instant-message method of transfer. The filename of the trojan, "wingate.exe" has been used by the Lovgate worm, but it does not appear to be the same file, and thus is not believed to be related to Lovgate. Migmaf tries to conceal the IP address of the master server by use of a "combination lock" algorithm. Basically it chooses each octet of the address to report back to by cycling through three choices per octet. So, the total possible combinations are 3x3x3x3 or 81. One time out of those 81 tries it will hit the correct address. The other 80 times it will try to connect to other combinations, thus if you are just looking at the traffic for a short time, you won't know which address is the real. In determining the origin of Migmaf, consider this: Before it does anything else, Migmaf checks the value of the following registry key: Keyboard Layout\Preload If it determines the keyboard layout indicates a Russian keyboard, it will exit. This suggests the authors are based in Russia, but it could be misdirection. Either way, the trojan will not work on Windows computers with a Russian keyboard. Removal Remove the following registry key: Software\Microsoft\Windows\CurrentVersion\Run\Login Service = wingate.exe Reboot the computer and remove the following file: %windir%\system32\wingate.exe About LURHQ Corporation LURHQ Corporation is the trusted provider of Managed Security Services. Founded in 1996, LURHQ has built a strong business protecting the critical information assets of more than 400 customers by offering managed intrusion prevention and protection services. LURHQ's 24X7 Incident Handling capabilities enable customers to enhance their security posture while reducing the costs of managing their security environments. LURHQ's OPEN Service Delivery™ methodology facilitates a true partnership with customers by providing a real time view of the organization's security status via the Sherlock Enterprise Security Portal. For more information visit http://www.lurhq.com Copyright (c) 2003 LURHQ Corporation Permission is hereby granted for the redistribution of this document electronically. It is not to be altered or edited in any way without the express written consent of LURHQ Corporation. If you wish to reprint the whole or any part of this document in any other medium excluding electronic media, please e-mail advisories@lurhq.com for permission. Disclaimer The information within this paper may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties implied or otherwise with regard to this information. In no event shall the author be liable for any damages whatsoever arising out of or in connection with the use or spread of this information. Feedback Updates and/or comments to: LURHQ Corporation http://www.lurhq.com/ advisories@lurhq.com --=====================_102345865==.ALT Content-Type: text/html; x-avg-checked=avg-ok-8D6EC1; charset=us-ascii I am sure OCP could help this guy a lot.
[for information only]

---------------------


URL
http://www.lurhq.com/migmaf.html

Release Date
July 11, 2003

In late June 2003, spam-fighters from the news.admin.net-abuse.email Usenet group noticed a particular spammer seemed to be able to move his websites around at will, minute-by-minute. This activity was also pointed out in an article by Richard M. Smith of computerbytesman.com.

It appeared at first that the spammer had managed to infect thousands of systems with a small webserver trojan - rotating them in and out of the DNS for the domain names he owned every 10 minutes. It made it nearly impossible for ISPs to track and shut down, as the IP addresses were largely owned by dialup users, so ISPs would be fighting a constant battle to keep track of all the reports.

The sites being advertised in the emails were generally Russian porn sites, and Richard Smith pointed out the same servers were involved in a Paypal scam email he had seen.

LURHQ was able to obtain a copy of the trojan - detected from suspicious activity originating from a VPN user on a firewall on a network we monitor. What we found was the trojan was not a webserver at all, but instead: a reverse proxy server. Instead of hosting the content on the victim's computer, the spammer instead maintained a "master" webserver. We have dubbed this trojan "Migmaf".

Functionality of Migmaf
Someone requesting the URL core.onlycoredomains.com (among several others) would be directed to one of the trojaned machines, where the connection would be in turn relayed to the master webserver. The returned page would be passed back to the trojaned machine, where it was then sent back to the requesting user's web browser. In this way it is impossible for the user to tell the actual IP address of the master server - giving the spammer's real site refuge from being shut down by his ISP.

But that isn't the only service Migmaf offers to the spammer - it also listens on TCP port 81 and acts as a socks proxy server. This allows the spammer to bounce spam email through the trojaned machine to his target recipients. This means the spammer has a complete end-to-end anonymous system for spam, and it lends itself well to the kind of scams already being seen. In one scam, the spammer directs the user to enter Paypal information into a form on the spammer's server. Posters to the Usenet spam-fighting groups have also speculated that the porn sites being advertised by the spammer may be merely a front to steal credit card numbers.

Migmaf has some features designed to make efficient use of resources. The trojan reports statistics and current state information back to the master webserver. The trojan actually checks to see how much available bandwidth it has by sending several hundred kilobytes of garbage data to www.microsoft.com on port 80. Because this might look like a denial-of-service attack or an exploit attempt, the trojan code actually contains the following text: 
"disclaimer: www.microsoft.com used for bandwith speed testing only"
The copy of Migmaf we obtained was compiled at the following time: 
Tue Jul  8 13:33:57 2003
Since the trojan has obviously been around longer than that, we can safely assume that the author is constantly changing the code he is sending out to evade anti-virus detection or to perhaps direct the traffic to another master webserver.

Migmaf itself has no spreading capability, so we don't yet know how the spammer is spreading the trojan to thousands of users. It could be piggybacked on a virus, or could perhaps use the IE exploit the Windows-Update trojan used, or it could be spread via IRC or KaZaA. One interesting thing to note is the large percentage of AOL users that seem to be infected - this may indicate a chat or instant-message method of transfer. The filename of the trojan, "wingate.exe" has been used by the Lovgate worm, but it does not appear to be the same file, and thus is not believed to be related to Lovgate.

Migmaf tries to conceal the IP address of the master server by use of a "combination lock" algorithm. Basically it chooses each octet of the address to report back to by cycling through three choices per octet. So, the total possible combinations are 3x3x3x3 or 81. One time out of those 81 tries it will hit the correct address. The other 80 times it will try to connect to other combinations, thus if you are just looking at the traffic for a short time, you won't know which address is the real.

In determining the origin of Migmaf, consider this: Before it does anything else, Migmaf checks the value of the following registry key: 
Keyboard Layout\Preload
If it determines the keyboard layout indicates a Russian keyboard, it will exit. This suggests the authors are based in Russia, but it could be misdirection. Either way, the trojan will not work on Windows computers with a Russian keyboard.
Removal
Remove the following registry key:

Software\Microsoft\Windows\CurrentVersion\Run\Login Service = wingate.exe

Reboot the computer and remove the following file:

%windir%\system32\wingate.exe
 

About LURHQ Corporation
LURHQ Corporation is the trusted provider of Managed Security Services. Founded in 1996, LURHQ has built a strong business protecting the critical information assets of more than 400 customers by offering managed intrusion prevention and protection services. LURHQ's 24X7 Incident Handling capabilities enable customers to enhance their security posture while reducing the costs of managing their security environments. LURHQ's OPEN Service Delivery&trade; methodology facilitates a true partnership with customers by providing a real time view of the organization's security status via the Sherlock Enterprise Security Portal. For more information visit http://www.lurhq.com

Copyright (c) 2003 LURHQ Corporation Permission is hereby granted for the redistribution of this document electronically. It is not to be altered or edited in any way without the express written consent of LURHQ Corporation. If you wish to reprint the whole or any part of this document in any other medium excluding electronic media, please e-mail advisories@lurhq.com for permission.

Disclaimer
The information within this paper may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties implied or otherwise with regard to this information. In no event shall the author be liable for any damages whatsoever arising out of or in connection with the use or spread of this information.

Feedback
Updates and/or comments to:
LURHQ Corporation
http://www.lurhq.com/
advisories@lurhq.com
--=====================_102345865==.ALT-- --=======AVGMAIL-3F8846EA6EF5=======-- From owner-ietf-openproxy@mail.imc.org Mon Oct 13 06:38: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 GAA29602 for ; Mon, 13 Oct 2003 06:38:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A906B-0001K7-00 for opes-archive@ietf.org; Mon, 13 Oct 2003 06:38:47 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A906A-0001K3-00 for opes-archive@ietf.org; Mon, 13 Oct 2003 06:38:47 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DANeI7025792 for ; Mon, 13 Oct 2003 03:23:40 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9DANeNC025791 for ietf-openproxy-bks; Mon, 13 Oct 2003 03:23:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail2.webwasher.com ([213.70.80.11]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9DANbI7025781 for ; Mon, 13 Oct 2003 03:23:39 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id A52MQZQVoutgoing id O4WZZ82H; 13 Oct 2003 14:30:38 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: transfer- and content-encoding Date: Mon, 13 Oct 2003 12:23:23 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D0E6593@mail.webwasher.com> Thread-Topic: transfer- and content-encoding Thread-Index: AcOPgZxMsCUO7EX4T0a2B1BK3NzzSQB8Rtfw From: "Martin Stecher" To: "OPES WG (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9DANdI7025787 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi Alex, > > > Do we need to prohibit encoding sequences like > > > (chunked,identity,chunked,identity)? The above rules do not. > > > > > > > Do you mean multiple usage of the same encoding in the list of the > > Transfer-Encoding member? > > No. Repetitions in Transfer-Encodings list should not cause any > problems. > > > Or that a transfer encoding could be applied several times > to some data? > > Right, the same transfer encoding(s) applied several times. > > Transfer-Encoding: (chunked,chunked,chunked) > > > What kind of problem do you see here? > > If we say nothing about it, them existing rules imply that the > recipient should handle (chunked,chunked,chunked) encoding if it > advertised support for chunked. I doubt many implementations would be > that flexible; I doubt they would be able to dechunk the same content > three times. It might also be a security vulnerability for the service > if the list gets rather long or something of that kind. That makes me > think that we should say something about it, if not outright prohibit > it. > > RFC 2616 has some text related to this problem, though its motivation > is probably different: > > When the "chunked" transfer- > coding is used, it MUST be the last transfer-coding applied to the > message-body. The "chunked" transfer-coding MUST NOT be applied > more than once to a message-body. > > Should we copy that? I like your general approach below even better. > > It is unlikely that OPES processors would _add_ transfer encoding > because there is really no need for it with OCP. Content-encoding can > be used for compression, I guess. So we are most likely talking about > removing chunking or any extension encoding supported by the > processor. I agree. > > I would suggest that we require identity transfer encoding, but I am > afraid that some processors may not want to dechunk a message (perhaps > they are doing some kind of zero-copy I/O or TCP slicing?). Another > problem is that if there is an extension transfer encoding than the > processor may not be able to dechunk back to identity. > > It's a mess. So, how about a SHOULD? Agents SHOULD support both identity and chunked transfer encoding. > > How about this: > > If OPES processor applies transfer encoding, it MUST NOT > apply any encoding more than once. Callout services > MAY reject content for which a transfer encoding > was applied more than once (XXX: document this as > a potential exploit area). Good, I just want to generalize to agent and peer rather than OPES processor and callout services. Also the callout server MUST NOT apply any encoding more than once. > > And then perhaps give a typical example with chunked encoding being > stripped by the processor. > I now wrote this paragraph. 2.2.3 Transfer-Encodings The agents need to negotiate their encoding and decoding capabilities. Transfer encodings that are not supported by one agents MUST NOT be used. HTTP messages with a transfer encoding that is not supported by the callout server MUST be decoded by the OPES processor and eventually be re-encoded with a supported transfer coding. Negotiation is done using the Transfer-Encoding parameter of the profile feature. Both agents advertise a list of supported transfer-codings for encoding and decoding. Encodings listed earlier are preferred. The Transfer-Encodings parameter MAY be omitted if only the identity coding is supported. An OCP agent receiving application data from its peer, MUST be ready to accept multiple transport encodings, in any order, if it advertised support for multiple transport encodings. If an agent applies transfer encoding, it MUST NOT apply any encoding more than once. The peer MAY reject content for which a transfer encoding was applied more than once (XXX: document this as a potential exploit area). OCP agents supporting HTTP profiles SHOULD support and advertise identity and chunked transfer coding. Transfer-Encodings = "Transfer-Encodings:" SP "(" [transfer-coding-list] ")" transfer-coding-list = transfer-coding *("," transfer-coding) for example Transfer-Encodings: (identity,chunked) Figure 5 transfer-coding is defined in section 3.6 of [RFC2616]. What do you think? Regards Martin From owner-ietf-openproxy@mail.imc.org Mon Oct 13 07:36: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 HAA00679 for ; Mon, 13 Oct 2003 07:36:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A910A-0001j7-00 for opes-archive@ietf.org; Mon, 13 Oct 2003 07:36:38 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A910A-0001j4-00 for opes-archive@ietf.org; Mon, 13 Oct 2003 07:36:38 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DBNMI7028114 for ; Mon, 13 Oct 2003 04:23:22 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9DBNMwA028113 for ietf-openproxy-bks; Mon, 13 Oct 2003 04:23:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from lifelesslap.robertcollins.net (dsl-131.10.240.220.lns02-kent-syd.dsl.comindico.com.au [220.240.10.131]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DBNGI7028103 for ; Mon, 13 Oct 2003 04:23:18 -0700 (PDT) (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 1A90my-0000La-00; Mon, 13 Oct 2003 21:23:00 +1000 Subject: RE: transfer- and content-encoding From: Robert Collins To: Martin Stecher Cc: "OPES WG (E-mail)" In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D0E6593@mail.webwasher.com> References: <75F7E67FC45F6744A7D328D41E35376D0E6593@mail.webwasher.com> Content-Type: text/plain Message-Id: <1066044174.838.63.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 13 Oct 2003 21:22:54 +1000 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 2003-10-13 at 20:23, Martin Stecher wrote: > I now wrote this paragraph. > > 2.2.3 Transfer-Encodings > > The agents need to negotiate their encoding and decoding > capabilities. Transfer encodings that are not supported by one agents > MUST NOT be used. HTTP messages with a transfer encoding that is not > supported by the callout server MUST be decoded by the OPES processor > and eventually be re-encoded with a supported transfer coding. > > Negotiation is done using the Transfer-Encoding parameter of the > profile feature. Both agents advertise a list of supported > transfer-codings for encoding and decoding. Encodings listed earlier > are preferred. The Transfer-Encodings parameter MAY be omitted if > only the identity coding is supported. > > An OCP agent receiving application data from its peer, MUST be ready > to accept multiple transport encodings, in any order, if it > advertised support for multiple transport encodings. If an agent > applies transfer encoding, it MUST NOT apply any encoding more than > once. The peer MAY reject content for which a transfer encoding was > applied more than once (XXX: document this as a potential exploit > area). > > OCP agents supporting HTTP profiles SHOULD support and advertise > identity and chunked transfer coding. > > Transfer-Encodings = "Transfer-Encodings:" SP > "(" [transfer-coding-list] ")" > transfer-coding-list = transfer-coding *("," transfer-coding) > > for example > Transfer-Encodings: (identity,chunked) > > Figure 5 > > transfer-coding is defined in section 3.6 of [RFC2616]. > > > > What do you think? Well the HTTP errata removed the 'identity' Transfer coding. I don't see any reason to reinstate it. Secondly, the prohibition against double encoding doesn't seem required to me: Chunked has explicit rules (*) - only one application, and always the last one. Other transfer codings may have their own rule. As a counter example, one may wish to use a transfer coding that provides delta-information, and use this twice (say working of different basis objects). As TE is hop by hop in HTTP, we need to ensure that any OPES processor's TE field passed to upstreams, and TE field passed in responses to client (for them to decide on upload Transfer-Encodings) is the processors capabilities, not the actual client / origin respectively. Once we do that, we know that an OPES processor will only receive codings it can handle, so we can say MUST reject with a 5xx error (sorry to lazy to dig up the best match) on an unhandlable transfer-coding. With that in place, the interaction from processor to processor can 'trivially' follow the HTTP Transfer-coding negotiation rules. That is, from a protocol viewpoint, all transfer-codings must be removed and applied anew across hops. By definition - implementations can shortcut this when a compatible transfer-coding sequence exists across the relevant hop. Cheers, Rob (*) RFC 2616 3.6 " Whenever a transfer-coding is applied to a message-body, the set of transfer-codings MUST include "chunked", unless the message is terminated by closing the connection. When the "chunked" transfer- coding is used, it MUST be the last transfer-coding applied to the message-body. The "chunked" transfer-coding MUST NOT be applied more than once to a message-body. These rules allow the recipient to determine the transfer-length of the message (section 4.4)." -- GPG key available at: . From owner-ietf-openproxy@mail.imc.org Mon Oct 13 08:53: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 IAA02452 for ; Mon, 13 Oct 2003 08:53:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A92D0-00029W-00 for opes-archive@ietf.org; Mon, 13 Oct 2003 08:53:58 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A92Cz-00029T-00 for opes-archive@ietf.org; Mon, 13 Oct 2003 08:53:57 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DCe5I7030924 for ; Mon, 13 Oct 2003 05:40:05 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9DCe5dQ030923 for ietf-openproxy-bks; Mon, 13 Oct 2003 05:40:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail2.webwasher.com ([213.70.80.11]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9DCe2I7030910 for ; Mon, 13 Oct 2003 05:40:03 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id CAO2DA2Koutgoing id 3AXVPAL9; 13 Oct 2003 16:47:10 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: transfer- and content-encoding Date: Mon, 13 Oct 2003 14:39:55 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D0E659E@mail.webwasher.com> Thread-Topic: transfer- and content-encoding Thread-Index: AcORfGF7rjhbwSlURKiFgnr4n3LCxAACQdwQ From: "Martin Stecher" To: "Robert Collins" Cc: "OPES WG (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9DCe4I7030918 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi Rob, thank you for your feedback - much appreciated. > > I now wrote this paragraph. > > > > 2.2.3 Transfer-Encodings > > > > The agents need to negotiate their encoding and decoding > > capabilities. Transfer encodings that are not supported > by one agents > > MUST NOT be used. HTTP messages with a transfer encoding > that is not > > supported by the callout server MUST be decoded by the > OPES processor > > and eventually be re-encoded with a supported transfer coding. > > > > Negotiation is done using the Transfer-Encoding parameter of the > > profile feature. Both agents advertise a list of supported > > transfer-codings for encoding and decoding. Encodings > listed earlier > > are preferred. The Transfer-Encodings parameter MAY be omitted if > > only the identity coding is supported. > > > > An OCP agent receiving application data from its peer, > MUST be ready > > to accept multiple transport encodings, in any order, if it > > advertised support for multiple transport encodings. If an agent > > applies transfer encoding, it MUST NOT apply any > encoding more than > > once. The peer MAY reject content for which a transfer > encoding was > > applied more than once (XXX: document this as a potential exploit > > area). > > > > OCP agents supporting HTTP profiles SHOULD support and advertise > > identity and chunked transfer coding. > > > > Transfer-Encodings = "Transfer-Encodings:" SP > > "(" [transfer-coding-list] ")" > > transfer-coding-list = transfer-coding *("," > transfer-coding) > > > > for example > > Transfer-Encodings: (identity,chunked) > > > > Figure 5 > > > > transfer-coding is defined in section 3.6 of [RFC2616]. > > > > > > > > What do you think? > > Well the HTTP errata removed the 'identity' Transfer coding. > I don't see > any reason to reinstate it. Alex argued that an OPES processor might not be able or willing to remove chunked transfer encoding. By forcing to name the identity encoding, there is the possibility to not support it. Questionable whether this is then what the OPES processor wants because it requires (at least from the callout server) to send all messages chunked encoded. > Secondly, the prohibition against double > encoding doesn't seem required to me: Chunked has explicit rules (*) - > only one application, and always the last one. Other transfer codings > may have their own rule. As a counter example, one may wish to use a > transfer coding that provides delta-information, and use this > twice (say > working of different basis objects). That was the alternative we discussed. Just copying the chunked coding requirements from RFC 2616. I am fine with that solution too. Might really be the way how OCP adapts HTTP best. Alex: What do you think? Thank you Martin From owner-ietf-openproxy@mail.imc.org Mon Oct 13 21:01: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 VAA07998 for ; Mon, 13 Oct 2003 21:01:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9DYy-0003xZ-00 for opes-archive@ietf.org; Mon, 13 Oct 2003 21:01:24 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A9DYx-0003xR-00 for opes-archive@ietf.org; Mon, 13 Oct 2003 21:01:23 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9E0nMI7056621 for ; Mon, 13 Oct 2003 17:49:23 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9E0nMnR056618 for ietf-openproxy-bks; Mon, 13 Oct 2003 17:49:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9E0nLI7056611 for ; Mon, 13 Oct 2003 17:49:21 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h9E0nNGh071296; Mon, 13 Oct 2003 18:49:23 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9E0nDD6071294; Mon, 13 Oct 2003 18:49:13 -0600 (MDT) (envelope-from rousskov) Date: Mon, 13 Oct 2003 18:49:13 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: Re: an interesting OPES application In-Reply-To: <6.0.0.22.2.20031011192044.05591cc0@mail.utel.net> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D014047@mail.webwasher.com> <6.0.0.22.2.20031011192044.05591cc0@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, 11 Oct 2003, jfcm wrote: > I am sure OCP could help this guy a lot. > http://www.lurhq.com/migmaf.html Could you please clarify in what way the OCP protocol would be helpful in this context? It seems that the reverse proxy is a better tool for his/her purpose because there is no exchange or adaptation of non-HTTP messages? It looks to me that the key functionality here is URL rewriting which is what reverse proxies are good for. Are you implying that the trojan in question could have been more powerful and could easily "adapt" more protocols if it were using OCP? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Tue Oct 14 01:12:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13684 for ; Tue, 14 Oct 2003 01:12:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9HUT-0005rv-00 for opes-archive@ietf.org; Tue, 14 Oct 2003 01:13:01 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A9HUT-0005rs-00 for opes-archive@ietf.org; Tue, 14 Oct 2003 01:13:01 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9E52jI7065014 for ; Mon, 13 Oct 2003 22:02:45 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9E52j6B065013 for ietf-openproxy-bks; Mon, 13 Oct 2003 22:02:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9E52gI7064988 for ; Mon, 13 Oct 2003 22:02:43 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h9E52iGh077209; Mon, 13 Oct 2003 23:02:44 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9E52ijX077208; Mon, 13 Oct 2003 23:02:44 -0600 (MDT) (envelope-from rousskov) Date: Mon, 13 Oct 2003 23:02:44 -0600 (MDT) From: Alex Rousskov To: Robert Collins cc: "OPES WG (E-mail)" Subject: RE: transfer- and content-encoding In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D0E659E@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D0E659E@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 13 Oct 2003, Martin Stecher wrote: > That was the alternative we discussed. Just copying the chunked > coding requirements from RFC 2616. I am fine with that solution too. > Might really be the way how OCP adapts HTTP best. Alex: What do you > think? We probably need to do more or less than just copying HTTP rules. Please see my response to Rob. I am undecided at this point, unfortunately. I want to support more than identity, but it is seems rather difficult. I hope the questions I raise will help us narrow down the solution space. Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Tue Oct 14 01:14:15 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13708 for ; Tue, 14 Oct 2003 01:14:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9HVk-0005sj-00 for opes-archive@ietf.org; Tue, 14 Oct 2003 01:14:20 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A9HVk-0005sg-00 for opes-archive@ietf.org; Tue, 14 Oct 2003 01:14:20 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9E4xLI7064614 for ; Mon, 13 Oct 2003 21:59:25 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9E4xLdm064613 for ietf-openproxy-bks; Mon, 13 Oct 2003 21:59:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9E4xJI7064607 for ; Mon, 13 Oct 2003 21:59:19 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h9E4xLGh077089; Mon, 13 Oct 2003 22:59:21 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9E4xALs077088; Mon, 13 Oct 2003 22:59:10 -0600 (MDT) (envelope-from rousskov) Date: Mon, 13 Oct 2003 22:59:10 -0600 (MDT) From: Alex Rousskov To: Robert Collins cc: "OPES WG (E-mail)" Subject: RE: transfer- and content-encoding In-Reply-To: <1066044174.838.63.camel@localhost> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D0E6593@mail.webwasher.com> <1066044174.838.63.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 Mon, 13 Oct 2003, Robert Collins wrote: > Well the HTTP errata removed the 'identity' Transfer coding. I don't > see any reason to reinstate it. The reason for documenting "identity" encoding tag is to express the lack of support for identity encoding. For example, a particular service may want to receive all data using some custom transfer encoding. I doubt such design is worth supporting though. That is, this reason is probably not good enough. A service that requires custom encoding can probably use content-encoding instead or rely on manual configuration rather than run-time negotiation. > Secondly, the prohibition against double encoding doesn't seem > required to me: Chunked has explicit rules (*) - only one > application, and always the last one. Other transfer codings may > have their own rule. As a counter example, one may wish to use a > transfer coding that provides delta-information, and use this twice > (say working of different basis objects). This is debatable. I would say that two delta encodings with different base objects are two different encodings. On the other hand, there is no pressing need to prohibit encoding repetitions where they are allowed by HTTP. > As TE is hop by hop in HTTP, we need to ensure that any OPES > processor's TE field passed to upstreams, and TE field passed in > responses to client (for them to decide on upload > Transfer-Encodings) is the processors capabilities, not the actual > client / origin respectively. Proposed TEs headers are exchanged among OPES agents only and are not passed to HTTP agents. It is an OCP header, not an HTTP header. We cannot assume that OPES agents will control HTTP headers when adapting HTTP payloads. This caveat is at the core of our problems here. Consider an virus scanning service -- it should not affect TE headers on the "outside" wire, but it should be able to handle any common content that the corresponding HTTP intermediary proxies. That is, OCP agents should be able to handle a variety of common transfer encodings without being able to affect "outside" encoding negotiations. > Once we do that, we know that an OPES processor will only receive > codings it can handle, so we can say MUST reject with a 5xx error > (sorry to lazy to dig up the best match) on an unhandlable > transfer-coding. HTTP proxy capabilities may be different from an attached OPES processor capabilities (which, in turn, may be different from an attached callout service capabilities). This is true for Transfer-Codings and for some other features. We cannot simply assume that OPES processor is an HTTP proxy, even if it adapts HTTP messages. > With that in place, the interaction from processor to processor can > 'trivially' follow the HTTP Transfer-coding negotiation rules. That > is, from a protocol viewpoint, all transfer-codings must be removed > and applied anew across hops. By definition - implementations can > shortcut this when a compatible transfer-coding sequence exists > across the relevant hop. I agree with the above. However, we still need to provide a negotiation mechanism for OPES agents to agree on the actual transfer encoding to be used. We cannot rely exclusively on HTTP specs because our agents, especially callout service, may not be HTTP agents. For example, many callout services will work with message payload and disregard any HTTP headers; those services will be very sensitive to encoding issues; they may not, for example, support chunked encoding. XXX: we need to document HTTP Adaptation scope. Does the draft apply only to agents that are HTTP compliant? Or to any adaptation of an HTTP messages, including those where the service is not HTTP-aware? Or something else? There are quote a few sane options available to us, depending on what encodings have to be supported and on what to do with custom encodings that an OCP agent does not support. Given your feedback and the multitude of options we face, I would propose the following: 0) Do not negotiate Transfer-Encodings at all. 1) An OCP agent sending data MUST remove all transfer encodings it supports. If any encodings remain, an OCP agent sending data MUST specify remaining encodings using the Transfer-Encoding parameter of a DUM OCP message. 2) If an OCP agent receives Transfer-Encoding parameter indicating unsupported encoding, it MAY terminate the corresponding OCP transaction. Do you think the above rules create any interoperability problems that more complex rules can eliminate? Can we think of a realistic-enough example where removing supported encodings is bad for performance reasons? Note that an agent may be _configured_ to leave certain encodings -- that qualifies as lack of support for their removal. Perhaps the above "MUST remove" can be rephrased to better reflect this caveat? Do the above rules still allow a callout service to form a chunked HTTP response it order to, for example, indicate service progress on a persistent HTTP/1.1 connection? Or should we not expect any processor to be able to handle chunked responses from a callout service? Should we add the following rule? 1a) OPES processors MUST support chunked transfer coding when handling data send by an OCP server. Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Tue Oct 14 06:57: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 GAA03424 for ; Tue, 14 Oct 2003 06:57:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Ms6-0000kt-00 for opes-archive@ietf.org; Tue, 14 Oct 2003 06:57:46 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A9Ms5-0000kp-00 for opes-archive@ietf.org; Tue, 14 Oct 2003 06:57:45 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EAiXI7039200 for ; Tue, 14 Oct 2003 03:44:33 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EAiXSi039199 for ietf-openproxy-bks; Tue, 14 Oct 2003 03:44:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail2.webwasher.com ([213.70.80.11]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9EAiVI7039189 for ; Tue, 14 Oct 2003 03:44:32 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id A5XFWT9Eoutgoing id 403HUW86; 14 Oct 2003 14:51:29 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: transfer- and content-encoding Date: Tue, 14 Oct 2003 12:44:14 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D0E65B1@mail.webwasher.com> Thread-Topic: transfer- and content-encoding Thread-Index: AcOSD/Gb5ZbhD4tJR96EWJ4QOZSRXgAKHRjg From: "Martin Stecher" To: "OPES WG (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9EAiWI7039195 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi, > >... > > There are quote a few sane options available to us, depending on what > encodings have to be supported and on what to do with custom > encodings that an OCP agent does not support. Given your feedback and > the multitude of options we face, I would propose the following: > > 0) Do not negotiate Transfer-Encodings at all. > > 1) An OCP agent sending data MUST remove all > transfer encodings it supports. If any encodings remain, an > OCP agent sending data MUST specify remaining encodings > using the Transfer-Encoding parameter of a DUM > OCP message. > > 2) If an OCP agent receives Transfer-Encoding parameter > indicating unsupported encoding, it MAY terminate > the corresponding OCP transaction. > > Do you think the above rules create any interoperability problems that > more complex rules can eliminate? > > Can we think of a realistic-enough example where removing supported > encodings is bad for performance reasons? Note that an agent may be > _configured_ to leave certain encodings -- that qualifies as lack of > support for their removal. Perhaps the above "MUST remove" can be > rephrased to better reflect this caveat? > > Do the above rules still allow a callout service to form a chunked > HTTP response it order to, for example, indicate service progress on a > persistent HTTP/1.1 connection? Or should we not expect any processor > to be able to handle chunked responses from a callout service? Should > we add the following rule? > > 1a) OPES processors MUST support chunked transfer coding > when handling data send by an OCP server. > I think removal of transfer encoding by the OPES processor will work and will probably simplify everything. If we do this, then adding chunked coding by the callout service seems to be odd to me. Forcing an OCP client to handle chunked transfer coding is maybe unfair; it it is a simple HTTP/1.0 proxy that is so far unaware of chunked transfer encoding, why should it support it? It will need to remove it again before sending on the HTTP path and it is technically not needed. In ICAP/1.0 we need chunked transfer encoding to track the message body length in OCP we do not need this. So there was a reason to force an HTTP/1.0 ICAP client to support chunked coding on the ICAP path but there is only little reason to do this for OCP. The motivation you give to do this here is very important though. Let's for now look at the typical case where the OCP client is a HTTP/1.1 proxy and talks to a HTTP/1.1 client and can therefore use chunked transfer encoding. Some callout services modify the HTTP body and do not know at the time of header processing how long the content will be. In terms of low latency and ability to keep persistent connections, it is best if the OPES processor then uses chunked transfer coding when talking to the HTTP client. I am concerned that many OCP client implementations will not implement this. Callout services that do this kind of content modification are the more reliable place for that transfer coding introduction, unless... Unless we find another good way to highlight this aspect in the specs. Reminds me that we had parts of this discussion in early June. I remember that we agreed that the OPES processor is responsible for correct headers and that we can use the sizep parameter to transmit a known content length. There we ended with two options I remember: i) OPES processor MUST ignore Content-Length header and depending on existence of sizep parameter - adjust the Content-Length header - introduce chunked transfer coding - collect all data before sending on - close the connection at the end We can now add: it MUST also ignore Transfer-Encoding header because OCP message do not have transfer encodings If we document this aspect and make ignoring the Content-Length header a MUST, OPES processors are forced to deal with this problem and are likely to find a good or acceptable implementation for it. ii) Add a data-you-check message which will then mean that the headers sent with a data-use-mine message are correct, including Content-Length and Transfer-Encoding. I do not like this so much, because it forces the OPES processors will be again in the dilemma to trust DUM messages but still having responsibility for correct headers. And it will only half way solve the Transfer-Encoding problem (callout services may still introduce). So, here is my today's proposal (sorry for changing my mind quickly ;-) I tries to combine your proposal with option i) above. 0) Do not negotiate Transfer-Encodings at all. 1) An OCP agent sending data MUST remove all transfer encodings it supports. If any encodings remain, an OCP agent sending data MUST specify remaining encodings using the Transfer-Encoding parameter of a DUM OCP message. A new transfer encoding MUST NOT be applied to a message. 2) If an OCP agent receives Transfer-Encoding parameter indicating unsupported encoding, it MAY terminate the corresponding OCP transaction. 3) If the Content-Length is known by the callout service, a sizep parameter MUST be added to all DUM messages. An OPES processor MUST ignore Content-Length and Transfer-Encoding HTTP headers. XXX: Document the options it has: - adjust the Content-Length header - introduce chunked transfer coding - collect all data before sending on - close the connection at the end Regards Martin From owner-ietf-openproxy@mail.imc.org Tue Oct 14 11:51:17 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15898 for ; Tue, 14 Oct 2003 11:51:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9RSG-0004Rt-00 for opes-archive@ietf.org; Tue, 14 Oct 2003 11:51:24 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A9RSF-0004Rp-00 for opes-archive@ietf.org; Tue, 14 Oct 2003 11:51:23 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EFZoI7052672 for ; Tue, 14 Oct 2003 08:35:50 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EFZo40052671 for ietf-openproxy-bks; Tue, 14 Oct 2003 08:35:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EFZnI7052666 for ; Tue, 14 Oct 2003 08:35:49 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h9EFZoGh092238; Tue, 14 Oct 2003 09:35:50 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9EFZoaq092237; Tue, 14 Oct 2003 09:35:50 -0600 (MDT) (envelope-from rousskov) Date: Tue, 14 Oct 2003 09:35:49 -0600 (MDT) From: Alex Rousskov To: "OPES WG (E-mail)" Subject: RE: transfer- and content-encoding In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D0E65B1@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D0E65B1@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 first responded to your message in detail (see below). While responding I realized that we may be missing an important point that Rob made. That realization prompted me to drastically simplify encoding rules (see (***) at the end of the message below). On Tue, 14 Oct 2003, Martin Stecher wrote: > Unless we find another good way to highlight this aspect in the > specs. Reminds me that we had parts of this discussion in early > June. I remember that we agreed that the OPES processor is > responsible for correct headers and that we can use the sizep > parameter to transmit a known content length. Indeed! I believe decoupling processor actions when forming the final message to the HTTP agent from OCP agent actions is the right thing to do here. OCP scope is efficient exchange of application messages being adapted. If a service wants to adapt transfer encodings it can, in theory, do that. However, that would be a service-specific operation built on _top_ of OCP mechanisms; not something we have to support explicitly. > There we ended with two options I remember: > > i) OPES processor MUST ignore Content-Length header > and depending on existence of sizep parameter > - adjust the Content-Length header > - introduce chunked transfer coding > - collect all data before sending on > - close the connection at the end Agreed (some polishing of the above may be required). > We can now add: it MUST also ignore Transfer-Encoding header > because OCP message do not have transfer encodings It can only ignore Transfer-Encoding if services are prohibited from changing transfer encodings. This is actually related to recomputation of Content-Length header above because Transfer-Encoding affects Content-Length presence and value. > So, here is my today's proposal (sorry for changing my mind quickly > ;-) I tries to combine your proposal with option i) above. > > 0) Do not negotiate Transfer-Encodings at all. > > 1) An OCP agent sending data MUST remove all > transfer encodings it supports. If any encodings remain, an > OCP agent sending data MUST specify remaining encodings > using the Transfer-Encoding parameter of a DUM > OCP message. The above should be AMS message (not DUM), I think. Sorry. Encodings have application message scope, not data chunk scope. To increase interoperability, I would also add An OCP processor SHOULD remove chunked encoding. Most callout services are not expected to be able to dechunk. > A new transfer encoding MUST NOT be applied to a message. This requirement is out of scope, I think. An agent can always argue that the encoding was applied before the application message entered OCP scope. We should always keep this scope picture in mind: +--OCP agent--+ +--OCP agent--+ | | | | things that | | things that happen outside ----- OCP scope ---- happen outside of OCP scope | | of OCP scope | | | | +-------------+ +-------------+ (processor side) (callout service side) Do you see what I am getting at? > 2) If an OCP agent receives Transfer-Encoding parameter > indicating unsupported encoding, it MAY terminate > the corresponding OCP transaction. Agreed. > 3) If the Content-Length is known by the callout service, a sizep > parameter MUST be added to all DUM messages. > An OPES processor MUST ignore Content-Length and Transfer-Encoding > HTTP headers. I do not like the word "ignore". On a logical level, the processor should delete Content-Length and Transfer-Encoding headers and either add correct header(s) or do other things you list below. > XXX: Document the options it has: > - adjust the Content-Length header > - introduce chunked transfer coding > - collect all data before sending on > - close the connection at the end (***) However, I think Rob has a very good point that we are missing here. Since HTTP transfer encodings are negotiated hop-by-hop by HTTP agents, the OPES processor or the HTTP proxy that embeds it _have to_ support encodings they receive (or it becomes an HTTP problem)! For example, an HTTP/1.0 proxy should not receive chunked encoding (by default) because it will not be able to find the end of a chunked HTTP message. Thus, I am thinking it would be acceptable to simplify the above rules: Adaptations that use HTTP transfer-encodings MUST be explicitly negotiated. This specification does not document such negotiations. In the absence of explicit transfer-encoding negotiations, an OCP agent MUST NOT send transfer-encoded application messages. Informally, this means that the agent or its environment have to make sure that all transfer encodings are stripped before an application message enters OCP scope. If an OCP agent receives transfer-encoded application data in violation of the above requirement, the agent MAY terminate the corresponding OCP transaction. The new rules above also leave us an opportunity to document transfer-encoding negotiations later if we decide they are worth supporting. You will need to add Content-Length and Transfer-Encoding "recalculation" rules you mentioned above. As agreed, the processor is still the enforcement point for those. HTH, Alex. From owner-ietf-openproxy@mail.imc.org Wed Oct 15 18:54: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 SAA28815 for ; Wed, 15 Oct 2003 18:54:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9uXW-000542-00 for opes-archive@ietf.org; Wed, 15 Oct 2003 18:54:46 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A9uXW-00053y-00 for opes-archive@ietf.org; Wed, 15 Oct 2003 18:54:46 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FMe5I7094895 for ; Wed, 15 Oct 2003 15:40:05 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9FMe50o094894 for ietf-openproxy-bks; Wed, 15 Oct 2003 15:40:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FMe4I7094880 for ; Wed, 15 Oct 2003 15:40:04 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h9FMe6Gh038756 for ; Wed, 15 Oct 2003 16:40:06 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9FMe6Te038755; Wed, 15 Oct 2003 16:40:06 -0600 (MDT) (envelope-from rousskov) Date: Wed, 15 Oct 2003 16:40:06 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: HTTP/OCP: All Content-* headers are special 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: Martin, Could you please check that HTTP Adaptations draft talks about OPES processor responsibility for "correctness" of not just Content-Length header but all(?) Content- headers including things like Content-MD5? Perhaps we can include a general statement that covers all headers? HTTP OPES processors MUST insure correctness of all HTTP headers documented in specifications that the processors intend to be compliant with. For example, the correctness of Content-Length and Content-MD5 headers have to be insured by processors claiming compliance with HTTP/1.1 (RFC 2616). Or would that be an overkill? Motivation: We are running some ICAP tests here, and Polygraph is detecting MD5 checksum errors on messages that went through an HTTP proxy that uses an ICAP server. Apparently, neither the proxy nor the ICAP server are adjusting Content-MD5 value when adapting content. I checked ICAP RFC and did not find references to Content-MD5, only Content-Length. I suspect an implementor may overlook the dependency between adapted content and HTTP/MIME checksums if we are not being more explicit about such dependencies. It would still be up to the processor how to "insure correctness". As discussed earlier, a given processor may have enough reasons to trust a given service to adjust all headers accordingly. The processor is judged by the final outcome only, not by the mechanism used to achieve that outcome. Sizep tricks will make Content-Length adjustments at the processor cheap. I am not sure that Content-MD5 adjustments at the processor can be cheap, but I think we have to document what the processor has to do to avoid end-to-end checksum errors. Perhaps the only realistic default for a processor would be to remove Content-MD5 header: absence of truth is better than lies. Alex. From owner-ietf-openproxy@mail.imc.org Wed Oct 15 19:13:15 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29284 for ; Wed, 15 Oct 2003 19:13:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9upX-0005Eh-00 for opes-archive@ietf.org; Wed, 15 Oct 2003 19:13:23 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A9upW-0005Ee-00 for opes-archive@ietf.org; Wed, 15 Oct 2003 19:13:22 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FMwrI7095516 for ; Wed, 15 Oct 2003 15:58:53 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9FMwrGd095515 for ietf-openproxy-bks; Wed, 15 Oct 2003 15:58:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FMwpI7095504 for ; Wed, 15 Oct 2003 15:58:52 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.8/8.12.8) with ESMTP id h9FMrZRd011186; Wed, 15 Oct 2003 16:53:35 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.8/8.11.6) with ESMTP id h9FMpwxq003489; Wed, 15 Oct 2003 16:51:58 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id h9FMpvhs003485; Wed, 15 Oct 2003 16:51:57 -0600 Date: Wed, 15 Oct 2003 16:51:57 -0600 Message-Id: <200310152251.h9FMpvhs003485@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: rousskov@measurement-factory.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage Subject: Re: HTTP/OCP: All Content-* headers are special Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is the tip of the integrity iceberg. If the point of the Content-MD5 header is to ensure end-to-end integrity, then it cannot be modified by intermediaries (even though it would generally but pretty cheap to do so). It would be more appropriate to add an OPES-Integrity header with a checksum. If the Content-MD5 header means "integrity from the last hop that modified the data, so you can see that there are no transmission errors", then modifying it is no big deal. What does the community think it means? Hilarie > Motivation: We are running some ICAP tests here, and Polygraph is > detecting MD5 checksum errors on messages that went through an HTTP > proxy that uses an ICAP server. Apparently, neither the proxy nor the > ICAP server are adjusting Content-MD5 value when adapting content. I > checked ICAP RFC and did not find references to Content-MD5, only > Content-Length. I suspect an implementor may overlook the dependency > between adapted content and HTTP/MIME checksums if we are not being > more explicit about such dependencies. > I am not sure that Content-MD5 adjustments at the processor can > be cheap, but I think we have to document what the processor has to do > to avoid end-to-end checksum errors. Perhaps the only realistic > default for a processor would be to remove Content-MD5 header: absence > of truth is better than lies. From owner-ietf-openproxy@mail.imc.org Wed Oct 15 19:37: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 TAA29735 for ; Wed, 15 Oct 2003 19:37:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9vD3-0005P8-00 for opes-archive@ietf.org; Wed, 15 Oct 2003 19:37:41 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A9vD2-0005P5-00 for opes-archive@ietf.org; Wed, 15 Oct 2003 19:37:40 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FNOUI7096570 for ; Wed, 15 Oct 2003 16:24:30 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9FNOUlF096568 for ietf-openproxy-bks; Wed, 15 Oct 2003 16:24:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FNOTI7096563 for ; Wed, 15 Oct 2003 16:24:29 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h9FNOVGh039810; Wed, 15 Oct 2003 17:24:31 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9FNOVaW039809; Wed, 15 Oct 2003 17:24:31 -0600 (MDT) (envelope-from rousskov) Date: Wed, 15 Oct 2003 17:24:31 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: Re: HTTP/OCP: All Content-* headers are special In-Reply-To: <200310152251.h9FMpvhs003485@localhost.localdomain> Message-ID: References: <200310152251.h9FMpvhs003485@localhost.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 15 Oct 2003, The Purple Streak, Hilarie Orman wrote: > This is the tip of the integrity iceberg. If the point of the > Content-MD5 header is to ensure end-to-end integrity, then it cannot > be modified by intermediaries (even though it would generally but > pretty cheap to do so). It would be more appropriate to add an > OPES-Integrity header with a checksum. > > If the Content-MD5 header means "integrity from the last hop that > modified the data, so you can see that there are no transmission > errors", then modifying it is no big deal. > > What does the community think it means? From HTTP point of view, Content-MD5 header is an end-to-end header. There can be no questions about that. The true question is: what an "end" means in the context where content is produced dynamically or in stages, like what we have with OPES. IMO, from content (and Content-MD5) point of view, an OPES proxy doing content modification is not an intermediary or a hop, but an "end" or an "edge" so "content integrity" arguments simply do not apply. From content consumer point of view, there is no integral content "behind" an OPES system; content starts after OPES has done its job. That's what Content-MD5 should represent. OPES adaptations have to be authorized by content provider and traced by others, of course, but that is irrelevant to HTTP or OCP issues being raised in this thread. We already agreed that OPES proxies can change content. Thus, we have to give OPES the right to modify or delete content checksums or the whole architecture would make no sense! Alex. P.S. Note that HTTP itself allows for similar modifications that some might mistakenly call "end-to-end" violations. For example, HTTP allows for aggregation and anonymization of Via: values. Such actions are HTTP-equivalent of OPES adjustment of Content-MD5 values. From owner-ietf-openproxy@mail.imc.org Wed Oct 15 21:28:08 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02057 for ; Wed, 15 Oct 2003 21:28:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9ww2-0006GV-00 for opes-archive@ietf.org; Wed, 15 Oct 2003 21:28:14 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A9ww1-0006GS-00 for opes-archive@ietf.org; Wed, 15 Oct 2003 21:28:13 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9G1FMI7099711 for ; Wed, 15 Oct 2003 18:15:22 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9G1FMAe099710 for ietf-openproxy-bks; Wed, 15 Oct 2003 18:15:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9G1FLI7099705 for ; Wed, 15 Oct 2003 18:15:21 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h9G1FNGh042372 for ; Wed, 15 Oct 2003 19:15:23 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9G1FNUV042371; Wed, 15 Oct 2003 19:15:23 -0600 (MDT) (envelope-from rousskov) Date: Wed, 15 Oct 2003 19:15:23 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: standardized URIs 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: -- Reposting with a different subject line as the original version apparently did not make it to the list for some unknown to me reason. ---------- Forwarded message ---------- Date: Mon, 6 Oct 2003 17:10:10 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: Help needed: standardized URIs Several kind folks expressed their desire to help with OCP Core and HTTP Adaptations drafts (both on this list and in private). There is one area, common to both drafts, that I am not familiar enough and need help with: These drafts propose to use URIs to identify certain features, adaptations, modes, or mechanisms. In some cases, we need to propose specific URIs to be used by all implementations (e.g., a URI to represent REQMOD or RESPMOD profile in HTTP Adaptations or URIs to represent specific connection encryption schemes). If any of the volunteers have time and desire to research the issue, it would be very helpful if they could produce answers to the following specific questions: - What URI scheme should we use? (http://, opes://, etc)? - If we use a URI scheme that has a domain name, what domain name should we use? (ietf.org, iana.org, etc)? - Are there any IETF/IANA/W3C requirements or best-practice principles for the path part of a URI? (/opes/ocp/request, wgs/opes/OCP-request) - Is there a template for the "IANA Considerations" section that we can use? If not, would should that section say about each URI we standardize? - What is the right thing to require from extensions as far as URIs are concerned? Should they use different schemes, different domains, or just different paths with x- in front of the last component to mimic MIME tradition with X-Extension headers? - If we can use an http:// URI scheme, would it be possible to put some documentation on the pages the URIs will refer to if the domain name to be used is iana.org or ietf.org? Or do we have to maintain our own domain (http://www.ietf-opes.net/ or whatever) to post actual pages? If you decide to take on this issue, please post to the list so that myself and others will not. Thanks a lot, Alex. From owner-ietf-openproxy@mail.imc.org Thu Oct 16 02:59:23 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 CAA22112 for ; Thu, 16 Oct 2003 02:59:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA26c-0001I8-00 for opes-archive@ietf.org; Thu, 16 Oct 2003 02:59:30 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AA26b-0001I5-00 for opes-archive@ietf.org; Thu, 16 Oct 2003 02:59:29 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9G6kWI7032093 for ; Wed, 15 Oct 2003 23:46:32 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9G6kWP3032091 for ietf-openproxy-bks; Wed, 15 Oct 2003 23:46:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from lifelesslap.robertcollins.net (dsl-3.7.240.220.lns02-kent-syd.dsl.comindico.com.au [220.240.7.3]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9G6kTI7032047 for ; Wed, 15 Oct 2003 23:46:30 -0700 (PDT) (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 1AA1to-0000I1-00; Thu, 16 Oct 2003 16:46:16 +1000 Subject: Re: HTTP/OCP: All Content-* headers are special From: Robert Collins To: Alex Rousskov Cc: OPES WG In-Reply-To: References: Content-Type: text/plain Message-Id: <1066286775.850.77.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 16 Oct 2003 16:46:16 +1000 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2003-10-16 at 08:40, Alex Rousskov wrote: > Martin, > > Could you please check that HTTP Adaptations draft talks about > OPES processor responsibility for "correctness" of not just > Content-Length header but all(?) Content- headers including things > like Content-MD5? Perhaps we can include a general statement that > covers all headers? > > HTTP OPES processors MUST insure correctness of > all HTTP headers documented in specifications > that the processors intend to be compliant with. > For example, the correctness of Content-Length > and Content-MD5 headers have to be insured by > processors claiming compliance with HTTP/1.1 > (RFC 2616). > > Or would that be an overkill? I think its a necessary condition. > Perhaps the only realistic > default for a processor would be to remove Content-MD5 header: absence > of truth is better than lies. For rfc2617/digest signed message bodies and similar mechanisms, it's probably intractable. For non verifiable headers - I think it depends on the advertisied origin: that is if the OPES device is comparable to a reverse proxy, it is considered authoritative for the entity and can safely correct such headers. For non authoritative OPES devices - say ISP's performing local ad replacement (ignoring the policy questions surrounding that) - then removing it is probably the most accurate step. Rob -- GPG key available at: . From owner-ietf-openproxy@mail.imc.org Thu Oct 16 03:19: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 DAA22652 for ; Thu, 16 Oct 2003 03:19:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA2Pg-0001UF-00 for opes-archive@ietf.org; Thu, 16 Oct 2003 03:19:12 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AA2Pf-0001UC-00 for opes-archive@ietf.org; Thu, 16 Oct 2003 03:19:12 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9G7A8I7037829 for ; Thu, 16 Oct 2003 00:10:08 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9G7A8YA037828 for ietf-openproxy-bks; Thu, 16 Oct 2003 00:10:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from lifelesslap.robertcollins.net (dsl-3.7.240.220.lns02-kent-syd.dsl.comindico.com.au [220.240.7.3]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9G7A6I7037811 for ; Thu, 16 Oct 2003 00:10:06 -0700 (PDT) (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 1AA2Gr-0000JP-00; Thu, 16 Oct 2003 17:10:05 +1000 Subject: RE: transfer- and content-encoding From: Robert Collins To: Alex Rousskov Cc: "OPES WG (E-mail)" In-Reply-To: References: <75F7E67FC45F6744A7D328D41E35376D0E65B1@mail.webwasher.com> Content-Type: text/plain Message-Id: <1066288205.857.99.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 16 Oct 2003 17:10:05 +1000 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2003-10-15 at 01:35, Alex Rousskov wrote: > (***) However, I think Rob has a very good point that we are missing > here. Since HTTP transfer encodings are negotiated hop-by-hop by HTTP > agents, the OPES processor or the HTTP proxy that embeds it _have to_ > support encodings they receive (or it becomes an HTTP problem)! For > example, an HTTP/1.0 proxy should not receive chunked encoding (by > default) should never actually - it's a MUST NOT in rfc 2616. > because it will not be able to find the end of a chunked HTTP > message. Thus, I am thinking it would be acceptable to simplify the > above rules: > > Adaptations that use HTTP transfer-encodings MUST be > explicitly negotiated. This specification does not document > such negotiations. Yes. > In the absence of explicit transfer-encoding negotiations, an > OCP agent MUST NOT send transfer-encoded application messages. > Informally, this means that the agent or its environment have > to make sure that all transfer encodings are stripped before > an application message enters OCP scope. Yes. > If an OCP agent receives transfer-encoded application data > in violation of the above requirement, the agent MAY terminate > the corresponding OCP transaction. I prefer MUST terminate. It will make things cleaner - there is little benefit in having an undefined behaviour, when we have explicit requirement for negotiation already there (three paragraphs up :}). Cheers, Rob -- GPG key available at: . From owner-ietf-openproxy@mail.imc.org Thu Oct 16 03:44: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 DAA23557 for ; Thu, 16 Oct 2003 03:44:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA2oL-0001lw-00 for opes-archive@ietf.org; Thu, 16 Oct 2003 03:44:41 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AA2oJ-0001lt-00 for opes-archive@ietf.org; Thu, 16 Oct 2003 03:44:40 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9G7V0I7043194 for ; Thu, 16 Oct 2003 00:31:00 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9G7V0Hm043193 for ietf-openproxy-bks; Thu, 16 Oct 2003 00:31:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from lifelesslap.robertcollins.net (dsl-3.7.240.220.lns02-kent-syd.dsl.comindico.com.au [220.240.7.3]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9G7UvI7043173 for ; Thu, 16 Oct 2003 00:30:57 -0700 (PDT) (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 1AA2az-0000KA-00; Thu, 16 Oct 2003 17:30:53 +1000 Subject: RE: transfer- and content-encoding From: Robert Collins To: Alex Rousskov Cc: "OPES WG (E-mail)" In-Reply-To: References: <75F7E67FC45F6744A7D328D41E35376D0E6593@mail.webwasher.com> <1066044174.838.63.camel@localhost> Content-Type: text/plain Message-Id: <1066289453.858.120.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 16 Oct 2003 17:30:53 +1000 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 2003-10-14 at 14:59, Alex Rousskov wrote: > On Mon, 13 Oct 2003, Robert Collins wrote: > > > Well the HTTP errata removed the 'identity' Transfer coding. I don't > > see any reason to reinstate it. > > The reason for documenting "identity" encoding tag is to express the > lack of support for identity encoding. For example, a particular > service may want to receive all data using some custom transfer > encoding. I doubt such design is worth supporting though. That is, > this reason is probably not good enough. A service that requires > custom encoding can probably use content-encoding instead or rely on > manual configuration rather than run-time negotiation. I think that the solution implied by your later message (I've already replied to that) is much better. That is - everything is identity between agents unless explicitly negotiated into a different transfer coding. Even so sending via chunked may be a better lowest common denominator due to the built in end of data indicator. I'm not fully up to speed on the current draft - I've been skim reading due to general busyness unfortunately. > > As TE is hop by hop in HTTP, we need to ensure that any OPES > > processor's TE field passed to upstreams, and TE field passed in > > responses to client (for them to decide on upload > > Transfer-Encodings) is the processors capabilities, not the actual > > client / origin respectively. > > Proposed TEs headers are exchanged among OPES agents only and are not > passed to HTTP agents. It is an OCP header, not an HTTP header. We > cannot assume that OPES agents will control HTTP headers when adapting > HTTP payloads. This caveat is at the core of our problems here. > Consider an virus scanning service -- it should not affect TE headers > on the "outside" wire, but it should be able to handle any common > content that the corresponding HTTP intermediary proxies. That is, OCP > agents should be able to handle a variety of common transfer encodings > without being able to affect "outside" encoding negotiations. Which directly conflicts with HTTP's hop by hop requirements - anything that is hop by hop will break, and break badly, unless we explicitly handle the hop by hop semantics. (And any other message based protocol other than HTTP that splits hops and messages will have similar issues). I hope I'm not missing an existing solution when I point out that the OCP device performing the interception and upstream forwarding has the responsibility of negotiating in the intercepted protocols boundaries, and gatewaying into the OCP protocol. So yes: the internal OCP encodings should stay in the OCP area, but that wasn't what I referred to. What I was saying is that: Origin | AV interceptor(OPES processor) ---- AV engine | Client in this diagram, the AV interceptor is responsible for Connection: semantics, for TE and transfer-encoding semantics, and Trailer: semantics, to pick a few common headers. Thus: the client will see the AV Interceptors TE headers, not the origins TE headers. > > Once we do that, we know that an OPES processor will only receive > > codings it can handle, so we can say MUST reject with a 5xx error > > (sorry to lazy to dig up the best match) on an unhandlable > > transfer-coding. > > HTTP proxy capabilities may be different from an attached OPES > processor capabilities (which, in turn, may be different from an > attached callout service capabilities). This is true for > Transfer-Codings and for some other features. We cannot simply assume > that OPES processor is an HTTP proxy, even if it adapts HTTP messages. But we can assume that the OPES processor will only negotiate what it can handle, in the protocol(s) it exposes to the clients/origins. So for the OCP protocol to have unhandlable transfer-codings arrive is in fact a failure of the OPES processors responsbilities to the protocol it's exposing, and IMO a OPES error of some sort is appropriate. > > With that in place, the interaction from processor to processor can > > 'trivially' follow the HTTP Transfer-coding negotiation rules. That > > is, from a protocol viewpoint, all transfer-codings must be removed > > and applied anew across hops. By definition - implementations can > > shortcut this when a compatible transfer-coding sequence exists > > across the relevant hop. > > I agree with the above. However, we still need to provide a > negotiation mechanism for OPES agents to agree on the actual transfer > encoding to be used. We cannot rely exclusively on HTTP specs because > our agents, especially callout service, may not be HTTP agents. For > example, many callout services will work with message payload and > disregard any HTTP headers; those services will be very sensitive to > encoding issues; they may not, for example, support chunked encoding. Ah. Very good point. Any reason not to leverage the connection termination, Connection: TE: and Transfer-Encoding: headers wholesale? (Yes, showing my skim reading again, I know). > There are quote a few sane options available to us, depending on what > encodings have to be supported and on what to do with custom > encodings that an OCP agent does not support. Given your feedback and > the multitude of options we face, I would propose the following: > > 0) Do not negotiate Transfer-Encodings at all. > > 1) An OCP agent sending data MUST remove all > transfer encodings it supports. If any encodings remain, an > OCP agent sending data MUST specify remaining encodings > using the Transfer-Encoding parameter of a DUM > OCP message. > > 2) If an OCP agent receives Transfer-Encoding parameter > indicating unsupported encoding, it MAY terminate > the corresponding OCP transaction. for 2) I think MUST terminate is a requirement. 0) seems short sighted to me - I'd rather see an analogous environment to HTTP: 1) messages pushing data to the agent require foreknowledge of supported encodings - i.e. during initial handshaking. 2) messages from the agent back to the processor use metadata supplied by the processor to determine acceptable codings. 3) all agents and processors must support chunked, which is trivial to implement efficiently. > Do you think the above rules create any interoperability problems that > more complex rules can eliminate? Other than what I mention above, no. > Can we think of a realistic-enough example where removing supported > encodings is bad for performance reasons? Note that an agent may be > _configured_ to leave certain encodings -- that qualifies as lack of > support for their removal. Perhaps the above "MUST remove" can be > rephrased to better reflect this caveat? Yes - rproxy. That is rsync over http. Mind you, to do *anything* nearly all agents will need the data in identity format eventually. So perhaps the strip everything to identity is the sanest option. > 1a) OPES processors MUST support chunked transfer coding > when handling data send by an OCP server. IMO Yes. chunked is a good thing. Rob -- GPG key available at: . From owner-ietf-openproxy@mail.imc.org Thu Oct 16 07:41: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 HAA29189 for ; Thu, 16 Oct 2003 07:41:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA6VF-0003jd-00 for opes-archive@ietf.org; Thu, 16 Oct 2003 07:41:13 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AA6VE-0003jX-00 for opes-archive@ietf.org; Thu, 16 Oct 2003 07:41:12 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GBQJI7083276 for ; Thu, 16 Oct 2003 04:26:19 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GBQJU5083275 for ietf-openproxy-bks; Thu, 16 Oct 2003 04:26:19 -0700 (PDT) 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 h9GBQGI7083253 for ; Thu, 16 Oct 2003 04:26:17 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id WGVR1QEEoutgoing id 5GWR0IRQ; 16 Oct 2003 15:33:18 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: transfer- and content-encoding Date: Thu, 16 Oct 2003 13:26:01 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D0E65C2@mail.webwasher.com> Thread-Topic: transfer- and content-encoding Thread-Index: AcOTt2CYgJw7EIsAQ1+RRifaoJIJ7gAIAYzw From: "Martin Stecher" To: "OPES WG (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9GBQII7083270 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi, > > > > Adaptations that use HTTP transfer-encodings MUST be > > explicitly negotiated. This specification does not document > > such negotiations. > > Yes. I will incorporate into the draft. > > > In the absence of explicit transfer-encoding negotiations, an > > OCP agent MUST NOT send transfer-encoded application messages. > > Informally, this means that the agent or its environment have > > to make sure that all transfer encodings are stripped before > > an application message enters OCP scope. > > Yes. I will incorporate into the draft. > > > If an OCP agent receives transfer-encoded application data > > in violation of the above requirement, the agent MAY > terminate > > the corresponding OCP transaction. > > I prefer MUST terminate. It will make things cleaner - there is little > benefit in having an undefined behaviour, when we have explicit > requirement for negotiation already there (three paragraphs up :}). > I think MAY is better. Think about a callout service which is not dealing with the message body at all. We should not force it to implement checks for protocol correctness of the peer, if it works even with the violation. Regards Martin From owner-ietf-openproxy@mail.imc.org Thu Oct 16 07:53:29 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29498 for ; Thu, 16 Oct 2003 07:53:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA6hG-0003r6-00 for opes-archive@ietf.org; Thu, 16 Oct 2003 07:53:38 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AA6hF-0003r2-00 for opes-archive@ietf.org; Thu, 16 Oct 2003 07:53:37 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GBgaI7083989 for ; Thu, 16 Oct 2003 04:42:36 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GBgadb083988 for ietf-openproxy-bks; Thu, 16 Oct 2003 04:42:36 -0700 (PDT) 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 h9GBgYI7083982 for ; Thu, 16 Oct 2003 04:42:34 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id OQM1PIA5outgoing id Z0S35RB3; 16 Oct 2003 15:49:45 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: transfer- and content-encoding Date: Thu, 16 Oct 2003 13:42:29 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D0E65C3@mail.webwasher.com> Thread-Topic: transfer- and content-encoding Thread-Index: AcOTu5vizN+KZovKQNGGlTyS+YJTkgAHVDIQ From: "Martin Stecher" To: "OPES WG (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9GBgZI7083984 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > > 1a) OPES processors MUST support chunked transfer coding > > when handling data send by an OCP server. > > IMO Yes. chunked is a good thing. > IMO no for now. While chunked coding is a good thing for HTTP to get low latency and persistency for data that's length is not known a priori, chunked coding is not needed for OCP because it encapsulated data in DUM messages with size parameter which is the same functionality as chunked encoding (and more). If there is a HTTP/1.0 proxy for which you want to write an OCP client (e.g. Squid), why adding chunked encoding, if it is not needed? It cannot be forwarded to the client (unless you want to update Squid to support HTTP/1.1 at the same time ;-), and so needs to be removed again. I think from all the discussion with header correctness and OPES processor's responsibility here, it is better to not add any transfer encoding by the callout service. It is better if only the OPES processor does this for now. And transferring DUM messages into chunked encoding for HTTP is very simple. Regards Martin From owner-ietf-openproxy@mail.imc.org Thu Oct 16 08:48: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 IAA00978 for ; Thu, 16 Oct 2003 08:48:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA7YG-0004NH-00 for opes-archive@ietf.org; Thu, 16 Oct 2003 08:48:24 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AA7YF-0004N7-00 for opes-archive@ietf.org; Thu, 16 Oct 2003 08:48:24 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GCZTI7085624 for ; Thu, 16 Oct 2003 05:35:29 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GCZTu7085623 for ietf-openproxy-bks; Thu, 16 Oct 2003 05:35:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from lifelesslap.robertcollins.net (dsl-3.7.240.220.lns02-kent-syd.dsl.comindico.com.au [220.240.7.3]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GCZQI7085616 for ; Thu, 16 Oct 2003 05:35:27 -0700 (PDT) (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 1AA7Lj-0007OD-00; Thu, 16 Oct 2003 22:35:27 +1000 Subject: RE: transfer- and content-encoding From: Robert Collins To: Martin Stecher Cc: "OPES WG (E-mail)" In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D0E65C3@mail.webwasher.com> References: <75F7E67FC45F6744A7D328D41E35376D0E65C3@mail.webwasher.com> Content-Type: text/plain Message-Id: <1066307724.858.140.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 16 Oct 2003 22:35:24 +1000 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2003-10-16 at 21:42, Martin Stecher wrote: > > > > > 1a) OPES processors MUST support chunked transfer coding > > > when handling data send by an OCP server. > > > > IMO Yes. chunked is a good thing. > > > > IMO no for now. > While chunked coding is a good thing for HTTP to get low latency and > persistency for data that's length is not known a priori, chunked > coding is not needed for OCP because it encapsulated data in DUM > messages with size parameter which is the same functionality as > chunked encoding (and more). Cool - thats one of the recent opes WG developments that I've only been peripherally aware of. No need for 1a) IMO given that. > If there is a HTTP/1.0 proxy for which you want to write an OCP client > (e.g. Squid), why adding chunked encoding, if it is not needed? It > cannot be forwarded to the client (unless you want to update Squid to > support HTTP/1.1 at the same time ;-), and so needs to be removed > again. Funny you should mention that. I updated a one-sided (squid->server only) TE implementation for squid circa squid 2.4, but pipeline issues prevented robust operation with range requests, and I let the branch lapse. We've corrected those internal issues in 3.0, and if we find a sponsor, HTTP/1.1 for squid-3.1 will happen. > I think from all the discussion with header correctness and OPES > processor's responsibility here, it is better to not add any transfer > encoding by the callout service. It is better if only the OPES > processor does this for now. And transferring DUM messages into > chunked encoding for HTTP is very simple. Sure, and conversely. Chunked after all is essentially just pascal style string :}. Rob -- GPG key available at: . From owner-ietf-openproxy@mail.imc.org Thu Oct 16 08:56: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 IAA01308 for ; Thu, 16 Oct 2003 08:56:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA7g3-0004SK-00 for opes-archive@ietf.org; Thu, 16 Oct 2003 08:56:27 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AA7g2-0004SH-00 for opes-archive@ietf.org; Thu, 16 Oct 2003 08:56:26 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GCfkI7085860 for ; Thu, 16 Oct 2003 05:41:46 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GCfkNa085859 for ietf-openproxy-bks; Thu, 16 Oct 2003 05:41:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from lifelesslap.robertcollins.net (dsl-3.7.240.220.lns02-kent-syd.dsl.comindico.com.au [220.240.7.3]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GCfiI7085854 for ; Thu, 16 Oct 2003 05:41:45 -0700 (PDT) (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 1AA7Rq-0007Ob-00; Thu, 16 Oct 2003 22:41:46 +1000 Subject: RE: transfer- and content-encoding From: Robert Collins To: Martin Stecher Cc: "OPES WG (E-mail)" In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D0E65C2@mail.webwasher.com> References: <75F7E67FC45F6744A7D328D41E35376D0E65C2@mail.webwasher.com> Content-Type: text/plain Message-Id: <1066308105.847.148.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 16 Oct 2003 22:41:45 +1000 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2003-10-16 at 21:26, Martin Stecher wrote: > > > > If an OCP agent receives transfer-encoded application data > > > in violation of the above requirement, the agent MAY > > terminate > > > the corresponding OCP transaction. > > > > I prefer MUST terminate. It will make things cleaner - there is little > > benefit in having an undefined behaviour, when we have explicit > > requirement for negotiation already there (three paragraphs up :}). > > > > I think MAY is better. Think about a callout service which is not dealing with > the message body at all. We should not force it to implement checks for protocol > correctness of the peer, if it works even with the violation. It depends. If we adopt some or all of the TE HTTP specs for OCP, then correct behaviour will depend on protocol correctness. If we don't have TE at all - just use the size prefixed DUM messages with the identity data, then TE will not appear in any OCP message because the OCP client will have stripped it to get to the identity. So, I think its simple: if we use TE, we need to use it correctly. If we don't use TE, then there's no issue, and the rules can be very simple: 0) All Hop by Hop protocol headers, for any adapted protocol MUST be removed before handoff to the OCP agent. Any relevant data from those headers MAY be presented in the appropriate OCP message header as appropriate. I.e. an HTTP adaptation service that expects to receive uploads will always recieve them without any transfer encodings applied. OCP doesn't provide a message encoding mechanism. Rob -- GPG key available at: . From owner-ietf-openproxy@mail.imc.org Thu Oct 16 08:56:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01327 for ; Thu, 16 Oct 2003 08:56:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA7ga-0004SW-00 for opes-archive@ietf.org; Thu, 16 Oct 2003 08:57:00 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AA7ga-0004ST-00 for opes-archive@ietf.org; Thu, 16 Oct 2003 08:57:00 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GCmbI7086081 for ; Thu, 16 Oct 2003 05:48:37 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GCmbtR086080 for ietf-openproxy-bks; Thu, 16 Oct 2003 05:48:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail2.webwasher.com ([213.70.80.11]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9GCmZI7086074 for ; Thu, 16 Oct 2003 05:48:35 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id FUUJSYN9outgoing id TL5GED4K; 16 Oct 2003 16:55:44 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: HTTP/OCP: All Content-* headers are special Date: Thu, 16 Oct 2003 14:48:28 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D0E65C6@mail.webwasher.com> Thread-Topic: HTTP/OCP: All Content-* headers are special Thread-Index: AcOTtkl/KJf/SDCTT/CppMcRoD8XeAAJF6jA From: "Martin Stecher" To: "OPES WG (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9GCmaI7086076 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > On Thu, 2003-10-16 at 08:40, Alex Rousskov wrote: > > Martin, > > > > Could you please check that HTTP Adaptations draft talks about > > OPES processor responsibility for "correctness" of not just > > Content-Length header but all(?) Content- headers including things > > like Content-MD5? Perhaps we can include a general statement that > > covers all headers? > > > > HTTP OPES processors MUST insure correctness of > > all HTTP headers documented in specifications > > that the processors intend to be compliant with. > > For example, the correctness of Content-Length > > and Content-MD5 headers have to be insured by > > processors claiming compliance with HTTP/1.1 > > (RFC 2616). > > > > Or would that be an overkill? > > I think its a necessary condition. Agreed. > > > Perhaps the only realistic > > default for a processor would be to remove Content-MD5 > header: absence > > of truth is better than lies. > For Content-Length adaptation we will use the sizep value. It seems to be an overkill to add more values for other headers. So, removing of those headers such as Content-MD5 is the only choice, unless - OPES processor collects all data until the end and recalucates the value if possible/capable - callout services responds with DUY message(s) that the message did not change > For rfc2617/digest signed message bodies and similar mechanisms, it's > probably intractable. > For non verifiable headers - I think it depends on the advertisied > origin: that is if the OPES device is comparable to a reverse > proxy, it > is considered authoritative for the entity and can safely correct such > headers. For non authoritative OPES devices - say ISP's > performing local > ad replacement (ignoring the policy questions surrounding that) - then > removing it is probably the most accurate step. I like the example of the reverse proxy that may even deploy an OPES callout service to calculate the MD5 checksum. In this case, the header will be introduced by the callout service. If the OPES processor trusts that service, it can leave it in (still being responsible for the correctness). Question is now: Is this trustability something which is defined outside of OCP? Or do we after all need a way to signal "I, the callout service, checked/modified/added this header and say it is good so, please trust me and use it when forwarding on the HTTP path" And is it so simple to talk about all headers that start with "Content-". Are all of those and only those affected? I don't think so. - Content-Encoding we already discussed, it's different - Changin the Content-Language is nothing that happens accidentally as MD5 checksum changes. If a callout service does language translation, it should also adapt this header field. I don't know how an OPES processor could recalculate this easily. Language changes are very exceptional, always deleting the header seems to be an overkill - Content-Type is the same as Content-Language I believe. Regards Martin From owner-ietf-openproxy@mail.imc.org Thu Oct 16 09:32: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 JAA02557 for ; Thu, 16 Oct 2003 09:32:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA8F1-0004uo-00 for opes-archive@ietf.org; Thu, 16 Oct 2003 09:32:35 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AA8F0-0004ul-00 for opes-archive@ietf.org; Thu, 16 Oct 2003 09:32:34 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GDJ5I7087321 for ; Thu, 16 Oct 2003 06:19:05 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GDJ5kJ087320 for ietf-openproxy-bks; Thu, 16 Oct 2003 06:19:05 -0700 (PDT) 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 h9GDJ3I7087313 for ; Thu, 16 Oct 2003 06:19:03 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id 2QHR28BDoutgoing id UMR62TFW; 16 Oct 2003 17:26:14 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: OCP core: sizep parameter Date: Thu, 16 Oct 2003 15:18:58 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D0E65C7@mail.webwasher.com> Thread-Topic: OCP core: sizep parameter Thread-Index: AcOT6A6+gzO5/M7qTnG35M2Uiq6r3g== From: "Martin Stecher" To: "OPES WG (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9GDJ4I7087315 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi Alex, from the OCP core draft: 8.9 sizep ... This parameter can be used with any OCP message that has am-id parameter. But sizep is only mentioned in the named parameter list of DUM messages. Will you add (at least) to AMS? Regards Martin From owner-ietf-openproxy@mail.imc.org Thu Oct 16 11:34: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 LAA07291 for ; Thu, 16 Oct 2003 11:34:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAA97-00060Z-00 for opes-archive@ietf.org; Thu, 16 Oct 2003 11:34:37 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AAA97-00060W-00 for opes-archive@ietf.org; Thu, 16 Oct 2003 11:34:37 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GFN3I7092716 for ; Thu, 16 Oct 2003 08:23:03 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GFN3dJ092715 for ietf-openproxy-bks; Thu, 16 Oct 2003 08:23:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GFN2I7092710 for ; Thu, 16 Oct 2003 08:23:02 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h9GFN2Gh061613; Thu, 16 Oct 2003 09:23:02 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9GFN22R061612; Thu, 16 Oct 2003 09:23:02 -0600 (MDT) (envelope-from rousskov) Date: Thu, 16 Oct 2003 09:23:02 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: Re: HTTP/OCP: All Content-* headers are special In-Reply-To: <1066286775.850.77.camel@localhost> Message-ID: References: <1066286775.850.77.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 Thu, 16 Oct 2003, Robert Collins wrote: > On Thu, 2003-10-16 at 08:40, Alex Rousskov wrote: > > > HTTP OPES processors MUST insure correctness of > > all HTTP headers documented in specifications > > that the processors intend to be compliant with. > > For example, the correctness of Content-Length > > and Content-MD5 headers have to be insured by > > processors claiming compliance with HTTP/1.1 > > (RFC 2616). > > I think its a necessary condition. OK. Looks like we have consensus on the above. Martin, please add to HTTP draft. I will try to add an OCP Core requirement for all OCP bindings to address the problem so that other bindings do not miss the issue. > > Perhaps the only realistic default for a processor would be to > > remove Content-MD5 header: absence of truth is better than lies. > > For rfc2617/digest signed message bodies and similar mechanisms, it's > probably intractable. Agreed. If an OPES system is adapting a securely signed message without access to private keys, that OPES system is misconfigured or is not authorized to do adaptations. In either case, secure signatures will work well as long as the client checks for their presence and validity (assuming they are essential). > For non verifiable headers - I think it depends on the advertisied > origin: that is if the OPES device is comparable to a reverse proxy, > it is considered authoritative for the entity and can safely correct > such headers. For non authoritative OPES devices - say ISP's > performing local ad replacement (ignoring the policy questions > surrounding that) - then removing it is probably the most accurate > step. Agreed. Alex. From owner-ietf-openproxy@mail.imc.org Thu Oct 16 11:50: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 LAA07768 for ; Thu, 16 Oct 2003 11:50:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAAOb-000689-00 for opes-archive@ietf.org; Thu, 16 Oct 2003 11:50:37 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AAAOa-000685-00 for opes-archive@ietf.org; Thu, 16 Oct 2003 11:50:37 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GFdfI7093398 for ; Thu, 16 Oct 2003 08:39:41 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GFdfgS093397 for ietf-openproxy-bks; Thu, 16 Oct 2003 08:39:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GFdeI7093392 for ; Thu, 16 Oct 2003 08:39:40 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h9GFdfGh061972; Thu, 16 Oct 2003 09:39:41 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9GFdfZY061971; Thu, 16 Oct 2003 09:39:41 -0600 (MDT) (envelope-from rousskov) Date: Thu, 16 Oct 2003 09:39:41 -0600 (MDT) From: Alex Rousskov To: "OPES WG (E-mail)" Subject: RE: transfer- and content-encoding In-Reply-To: <1066289453.858.120.camel@localhost> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D0E6593@mail.webwasher.com> <1066044174.838.63.camel@localhost> <1066289453.858.120.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 Thu, 16 Oct 2003, Robert Collins wrote: > I think that the solution implied by your later message (I've already > replied to that) is much better. I will not argue with the rest of this e-mail then, except that I want to clarify one important point. > Which directly conflicts with HTTP's hop by hop requirements - anything > that is hop by hop will break, and break badly, unless we explicitly > handle the hop by hop semantics > > Origin > | > AV interceptor(OPES processor) ---- AV engine > | > Client > > in this diagram, the AV interceptor is responsible for Connection: > semantics, for TE and transfer-encoding semantics, and Trailer: > semantics, to pick a few common headers. Thus: the client will see > the AV Interceptors TE headers, not the origins TE headers. I agree, but let's not forget that our scope is OPES agents and not the entire intermediary. A more accurate/detailed picture would look like this: Origin | HTTP proxy -?- OPES processor -*- OPES callout service | Client OCP scope is the "-*-" link. All "|" links are HTTP links. OPES processor can be viewed as an HTTP hop from HTTP proxy view _or_ it can be integrated with the HTTP proxy. Processor traffic and actions on the "proxy side" (the "-?-" link) would depend on the degree of that integration. Thus, it is not accurate to say that OPES processor has to be responsible for Connection semantics; that would depend on the link. However, if that OPES processor is using an HTTP link (and claims HTTP compliance), then it becomes responsible. Finally, the callout service may be interested in hop-by-hop headers. For example, a logging service may want to log them. Thus, it is not a good idea to require OPES processor to strip them. We should require correctness on "|" links. What happens on "-*-" link is not important from HTTP point of view because "-*-" link is not an HTTP link. Hope this clarifies, Alex. From owner-ietf-openproxy@mail.imc.org Thu Oct 16 12:04:27 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08286 for ; Thu, 16 Oct 2003 12:04:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAAc5-0006Ev-00 for opes-archive@ietf.org; Thu, 16 Oct 2003 12:04:33 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AAAc4-0006Es-00 for opes-archive@ietf.org; Thu, 16 Oct 2003 12:04:32 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GFu3I7093884 for ; Thu, 16 Oct 2003 08:56:03 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GFu3IP093883 for ietf-openproxy-bks; Thu, 16 Oct 2003 08:56:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GFu1I7093878 for ; Thu, 16 Oct 2003 08:56:01 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h9GFu3Gh062427 for ; Thu, 16 Oct 2003 09:56:03 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9GFu2uQ062426; Thu, 16 Oct 2003 09:56:02 -0600 (MDT) (envelope-from rousskov) Date: Thu, 16 Oct 2003 09:56:02 -0600 (MDT) From: Alex Rousskov To: "OPES WG (E-mail)" Subject: RE: transfer- and content-encoding In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D0E65C2@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D0E65C2@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 16 Oct 2003, Martin Stecher wrote: > > > If an OCP agent receives transfer-encoded application > > > data in violation of the above requirement, the agent MAY > > > terminate the corresponding OCP transaction. > > > > I prefer MUST terminate. It will make things cleaner - there is > > little benefit in having an undefined behaviour, when we have > > explicit requirement for negotiation already there (three > > paragraphs up :}). > > I think MAY is better. Think about a callout service which is not > dealing with the message body at all. We should not force it to > implement checks for protocol correctness of the peer, if it works > even with the violation. Hmm... We may have a problem here. I agree with Martin in principle(*), but since Transfer-Encoding header is gone, an agent cannot reliably detect non-identity coding since we do not document any way of describing present transfer encodings. If we say MUST, how will an agent check? Since we provide no way to detect transfer codings, should we delete the above MAY? The "receives transfer-encoded application data" condition seems to be uncomputable in general! Alex. (*) We do not know what the service is doing. In addition to Martin's example above, consider a logging service. OPES should not prevent FBI from getting all data from a tap just because two P2P nodes are using a custom transfer encoding underneath HTTP chunks. From owner-ietf-openproxy@mail.imc.org Thu Oct 16 12:27:24 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09518 for ; Thu, 16 Oct 2003 12:27:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAAyM-0006bE-00 for opes-archive@ietf.org; Thu, 16 Oct 2003 12:27:34 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AAAyL-0006bB-00 for opes-archive@ietf.org; Thu, 16 Oct 2003 12:27:33 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GGF5I7094533 for ; Thu, 16 Oct 2003 09:15:05 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GGF5l7094532 for ietf-openproxy-bks; Thu, 16 Oct 2003 09:15:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GGF3I7094527 for ; Thu, 16 Oct 2003 09:15:04 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h9GGF5Gh062808 for ; Thu, 16 Oct 2003 10:15:05 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9GGF5T6062807; Thu, 16 Oct 2003 10:15:05 -0600 (MDT) (envelope-from rousskov) Date: Thu, 16 Oct 2003 10:15:05 -0600 (MDT) From: Alex Rousskov To: "OPES WG (E-mail)" Subject: Re: OCP core: sizep parameter In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D0E65C7@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D0E65C7@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 16 Oct 2003, Martin Stecher wrote: > from the OCP core draft: > > 8.9 sizep > > ... This parameter can be used > with any OCP message that has am-id parameter. > > But sizep is only mentioned in the named parameter list of DUM messages. > Will you add (at least) to AMS? Will do. The way OCP draft documents message parameters and their types is rather messy and awkward IMO. I will try to find a better way, but do not have any good ideas right now. Suggestions are very welcome. Alex. From owner-ietf-openproxy@mail.imc.org Thu Oct 16 12:31:49 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09916 for ; Thu, 16 Oct 2003 12:31:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAB2d-0006jC-00 for opes-archive@ietf.org; Thu, 16 Oct 2003 12:31:59 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AAB2c-0006j9-00 for opes-archive@ietf.org; Thu, 16 Oct 2003 12:31:58 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GGCoI7094394 for ; Thu, 16 Oct 2003 09:12:50 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GGCooc094393 for ietf-openproxy-bks; Thu, 16 Oct 2003 09:12:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GGCmI7094388 for ; Thu, 16 Oct 2003 09:12:48 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h9GGCnGh062793; Thu, 16 Oct 2003 10:12:50 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9GGCnej062792; Thu, 16 Oct 2003 10:12:49 -0600 (MDT) (envelope-from rousskov) Date: Thu, 16 Oct 2003 10:12:49 -0600 (MDT) From: Alex Rousskov To: "OPES WG (E-mail)" Subject: RE: HTTP/OCP: All Content-* headers are special In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D0E65C6@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D0E65C6@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 16 Oct 2003, Martin Stecher wrote: > For Content-Length adaptation we will use the sizep value. > It seems to be an overkill to add more values for other headers. Or nearly impossible, as the case with Content-MD5 is. A service that modifies content is very unlikely to be able to compute new MD5 in advance. > So, removing of those headers such as Content-MD5 is the only choice, unless > - OPES processor collects all data until the end and recalucates the value if possible/capable > - callout services responds with DUY message(s) that the message did not change Agreed (the latter condition assumes that processor trusts the service enough to risk its own [in]compliance on service behavior). > I like the example of the reverse proxy that may even deploy an OPES > callout service to calculate the MD5 checksum. In this case, the > header will be introduced by the callout service. If the OPES > processor trusts that service, it can leave it in (still being > responsible for the correctness). Agreed. > Question is now: Is this trustability something which is defined > outside of OCP? Or do we after all need a way to signal "I, the > callout service, checked/modified/added this header and say it is > good so, please trust me and use it when forwarding on the HTTP > path" I think we tried to do this in the past and failed. I suggest that this kind of statements are outside of our scope. In most cases, processors will know what services they deal with and can be configured to [not] trust them accordingly, on a case-by-case basis with "do not trust" as the default. Perhaps we should make that default more clear in the specs. I hope your [very valid] Content-Language concerns below can be addressed without adding "trust me with this header" interface. > And is it so simple to talk about all headers that start with > "Content-". Are all of those and only those affected? > I don't think so. Good point. > - Changin the Content-Language is nothing that happens accidentally > as MD5 checksum changes. If a callout service does language > translation, it should also adapt this header field. I don't know > how an OPES processor could recalculate this easily. Language > changes are very exceptional, always deleting the header seems to > be an overkill Content-MD5 computation is clearly documented. Content-Language is not a computable setting so OPES processor cannot verify or "fix" it. Perhaps our rules should be more precise to exclude non-computable headers? > - Content-Type is the same as Content-Language I believe. Yes. Alex. From owner-ietf-openproxy@mail.imc.org Fri Oct 17 04:35: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 EAA24241 for ; Fri, 17 Oct 2003 04:35:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAQ4s-0000go-00 for opes-archive@ietf.org; Fri, 17 Oct 2003 04:35:18 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AAQ4r-0000gk-00 for opes-archive@ietf.org; Fri, 17 Oct 2003 04:35:18 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9H8LbI7079379 for ; Fri, 17 Oct 2003 01:21:37 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9H8Lbt5079377 for ietf-openproxy-bks; Fri, 17 Oct 2003 01:21:37 -0700 (PDT) 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 h9H8LYI7079335 for ; Fri, 17 Oct 2003 01:21:35 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id LVW7I4I8outgoing id DX7U4R4G; 17 Oct 2003 12:28:40 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: HTTP/OCP: All Content-* headers are special Date: Fri, 17 Oct 2003 10:21:23 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D0E65CC@mail.webwasher.com> Thread-Topic: HTTP/OCP: All Content-* headers are special Thread-Index: AcOUAFrOxgXvB7yrTyqvYOUMAgnjGAAhc+Ew From: "Martin Stecher" To: "OPES WG (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9H8LaI7079370 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi, it is not even that the OPES processor MUST NOT by default trust the Content-Length header returned by a callout service, actually neither agent can trust that header. An OPES processor may call a first callout service and then forward the response to a second callout service, i.e. implementing a pipe of callout services. We should not force the OPES processor to do the header correctness check and recalculation after each callout service response but only at the very end before sending on the HTTP message on the HTTP path. That means that a callout server may see the HTTP message that was already modified by another service and hence some headers may be incorrect. I would therefore like to require that both agents MUST use sizep parameter if they know the message length and no agent SHOULD trust the Content-Length header. That makes it also simpler for the callout service to use the sizep parameter. If the service does not need to parse the HTTP headers for its filtering purpose, it would not be nice if it needs to lookup the content length header value in order to insert sizep parameters. If it already receives sizep from the OCP client, it has an easier job. The OCP client, as typically being tightly bound to a HTTP proxy, has probably easy access to the content length header of the message (if any). Regards Martin From owner-ietf-openproxy@mail.imc.org Fri Oct 17 09:21: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 JAA01022 for ; Fri, 17 Oct 2003 09:21:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAUYC-0003Ij-00 for opes-archive@ietf.org; Fri, 17 Oct 2003 09:21:53 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AAUYC-0003If-00 for opes-archive@ietf.org; Fri, 17 Oct 2003 09:21:52 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9HDBRI7009605 for ; Fri, 17 Oct 2003 06:11:27 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9HDBRXQ009604 for ietf-openproxy-bks; Fri, 17 Oct 2003 06:11:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail2.webwasher.com ([217.146.159.49]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9HDBOI7009548 for ; Fri, 17 Oct 2003 06:11:25 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id RZK08K1Koutgoing id K18LZCS9; 17 Oct 2003 17:17:21 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: sizep parameter again Date: Fri, 17 Oct 2003 15:10:04 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D0E65D1@mail.webwasher.com> Thread-Topic: sizep parameter again Thread-Index: AcOUr/sfvv6gYprUQamW9RmsecLqdQ== From: "Martin Stecher" To: "OPES WG (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9HDBQI7009600 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi, I am not sure, please help: The sizep parameter is the "remaining application data prediction" according to OCP-Core draft. I see some conflicts: 1. What if the agent knows that it will skip certain message parts? Does it need to substract this skipped size from the sizep parameter? This will break our Content-Length idea. Or does skipping of parts not affect sizep parameter? Is this then still the "remaining application data"? 2. What about optional parts? Should their size be added to sizep? Will again break Content-Length trick. 3. Trailers belong to the application data. Therefore the DUM message containing the response-header should have a sizep parameter equal to response-body size plus response-trailer size. But this is not the size that we can use for Content-Length correction. 4. If response-header part is sent in multiple DUM messages, only the last DUM message contains the correct sizep value. I am concerned some implementations will not be prepared for this case. Putting all this together, I feel that using the sizep parameter for Content-Length indication does not really work. Shouldn't we better introduce a Content-Length named parameter to AMS messages that does what we really want: Promise a length that can be used for HTTP Content-Length header correction? Regards Martin From owner-ietf-openproxy@mail.imc.org Fri Oct 17 12:23:11 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09142 for ; Fri, 17 Oct 2003 12:23:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAXNn-0005Hh-00 for opes-archive@ietf.org; Fri, 17 Oct 2003 12:23:19 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AAXNm-0005HZ-00 for opes-archive@ietf.org; Fri, 17 Oct 2003 12:23:18 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9HG4mI7015968 for ; Fri, 17 Oct 2003 09:04:48 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9HG4mdP015967 for ietf-openproxy-bks; Fri, 17 Oct 2003 09:04:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9HG4kI7015962 for ; Fri, 17 Oct 2003 09:04:47 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9HG49d17510; Fri, 17 Oct 2003 12:04:09 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66W1GP>; Fri, 17 Oct 2003 12:04:10 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD7540746917C@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: internet-drafts@ietf.org Cc: "'ietf-openproxy@imc.org'" , "Abbie Barbir" , "'Markus Hofmann'" Subject: Request to publish :draft-ietf-opes-end-comm-04 Date: Fri, 17 Oct 2003 12:04:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C394C8.49953592" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C394C8.49953592 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C394C8.49953592" ------_=_NextPart_001_01C394C8.49953592 Content-Type: text/plain Please publish the following draft-ietf-opes-end-comm-04 as a WG Draft. Thanks Abbie ------_=_NextPart_001_01C394C8.49953592 Content-Type: text/html Request to publish :draft-ietf-opes-end-comm-04

Please publish the following

draft-ietf-opes-end-comm-04

as a WG Draft.

Thanks
Abbie

  ------_=_NextPart_001_01C394C8.49953592-- ------_=_NextPart_000_01C394C8.49953592 Content-Type: text/plain; name="draft-ietf-opes-end-comm-04.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-opes-end-comm-04.txt" Content-Transfer-Encoding: quoted-printable Network Working Group A. = Barbir Internet-Draft Nortel = Networks Expires: March 31, 2004 Oct. = 2003 OPES entities and end points communication draft-ietf-opes-end-comm-04 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that = other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six = months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 31, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This memo documents tracing and non-blocking requirements for Open Pluggable Edge Services (OPES). Barbir Expires March 31, 2004 [Page = 1] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . = 3 2. OPES System . . . . . . . . . . . . . . . . . . . . . . . . . = 4 3. Requirements for OPES Tracing . . . . . . . . . . . . . . . . = 5 3.1 What is traceable in an OPES Flow? . . . . . . . . . . . . . . = 5 3.2 Requirements for OPES System . . . . . . . . . . . . . . . . . = 6 3.3 Requirements for OPES processors . . . . . . . . . . . . . . . = 7 3.4 Requirements for callout servers . . . . . . . . . . . . . . . = 7 4. Requirements for OPES System Bypass (Non-blocking feature) . . = 8 4.1 What can be bypassed in an OPES Flow? . . . . . . . . . . . . = 8 4.2 Bypass requirements for OPES System . . . . . . . . . . . . . = 9 4.3 Bypass requirements for OPES processors . . . . . . . . . . . = 9 4.4 Bypass requirements for callout servers . . . . . . . . . . . = 10 5. Protocol Binding . . . . . . . . . . . . . . . . . . . . . . . = 11 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . = 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . = 13 7.1 Tracing security considerations . . . . . . . . . . . . . . . = 13 7.2 Bypass security considerations . . . . . . . . . . . . . . . . = 14 Normative References . . . . . . . . . . . . . . . . . . . . . = 16 Informative References . . . . . . . . . . . . . . . . . . . . = 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . = 17 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . = 18 Intellectual Property and Copyright Statements . . . . . . . . = 19 Barbir Expires March 31, 2004 [Page = 2] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 1. Introduction The Open Pluggable Edge Services (OPES) architecture [7] enables cooperative application services (OPES services) between a data provider, a data consumer, and zero or more OPES processors. The application services under consideration analyze and possibly transform application-level messages exchanged between the data provider and the data consumer. This work specifies the requirements for providing tracing functionality for the OPES architecture [7]. Tracing functionality enables a data provider or a data consumer application to detect inappropriate actions that are performed by OPES entities. The work also develops requirements that can be used to fulfill IAB Notification and Bypass (Non-Blocking) requirements [2]. The architecture document requires [7] 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. However, the architecture does not prevent implementers = of developing out-of-band protocols and techniques to address these limitation. Barbir Expires March 31, 2004 [Page = 3] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 2. OPES System This sections provides a definition of OPES System. This is needed = in order to define what is traceable in an OPES Flow. Definition: An OPES System is a set of all OPES entities [7] authorized by either the data provider or the data consumer application to process a given application message. The nature of the authorization agreement determines if authority delegation is transitive (meaning an authorized entity is authorized to include other entities). If specific authority agreements allow for re-delegation, an OPES system can be formed by induction. In this case, an OPES system starts with entities directly authorized by a data provider (or a data consumer) application. The OPES system then includes any OPES entity authorized by an entity that is already in the OPES system. The authority delegation is always viewed in the context of a given application message. An OPES System is defined on an application message basis. Having an authority to process a message does not imply being involved in message processing. Thus, some OPES system members may not participate in processing of a message. Similarly, some members may process the same message several times. The above definition implies that there can be no more than two OPES systems [Client-side and server-side OPES systems can process the same message at the same time] processing the same message at a = given time. This is based on the assumption that there is a single data provider and a single data consumer as far as a given application message is concerned. For example, consider a Content Delivery Network (CDN) delivering an image on behalf of a busy web site. OPES processors and services = that the CDN uses to adapt and deliver the message comprise an OPES System. In a more complex example, an OPES System would contain CDN entries as well as 3rd-party OPES entities that CDN engages to perform adaptations (e.g., to adjust image quality). Barbir Expires March 31, 2004 [Page = 4] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 3. Requirements for OPES Tracing 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. A traceable entity can appear multiple times in a trace (every time it acts on a message). In an OPES System tracing is performed on per message basis. Trace format is dependent on the application protocol that is being = adapted by OPES. 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. In an OPES System, the task of providing tracing information, can depend on many factors. Some considerations are: o Providers may be hesitant to reveal information about their internal network infrastructure. o Within a service provider network, OPES processors may be configured to use non-routable, private IP addresses. o A data consumer applications would prefer to have a single point of contact regarding the trace information. 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. OPES providers require some freedom in the way they deliver tracing information to an end point. 3.1 What is traceable in an OPES Flow? This section focuses on identifying traceable entities in an OPES Flow. Tracing information provides a data consumer application (or a data provider 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 Barbir Expires March 31, 2004 [Page = 5] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 be able to see a trace entry, but does not need to be able to interpret it beyond identification of the OPES System. Second, the OPES System administrator is expected to be able to interpret the contents of an OPES trace. The trace can be relayed to the administrator by an end (data consumer or provider) without interpretation, as opaque data (e.g., a TCP packet or an HTTP = message snapshot). The administrator can use the trace information to identify the participating OPES entities. The administrator can use the trace to identify the applied adaptation services along with other message-specific information. 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 and how to format them. Trace records should be easy to extend beyond basic OPES requirements. Trace management algorithms should treat trace records as opaque data to the extent possible. 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. OPES entities have different levels of traceability requirements. Specifically, o An OPES processor SHOULD add its entry to the trace. o An OPES service May add its entry to the trace. 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). In an OPES context, a good tracing approach is similar to a trouble ticket ready for submission to a known address. The address is printed on the ticket. The trace in itself is not necessarily a detailed description of what has happened. It is the responsibility of the operator to resolve the problems. 3.2 Requirements for OPES System The following requirements apply for information as related to an OPES System: o An OPES system MUST add its identification to the trace. Barbir Expires March 31, 2004 [Page = 6] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 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. o An OPES System MUST include information pointing to a technical contact. o An OPES System MUST include information that identifies, to the technical contact, the OPES processors involved in processing = the message. In addressing the above requirements and in order to reduce the size of the trace, an OPES System can provide a URL to the OPES System = web page that has links to privacy and other policies. 3.3 Requirements for OPES processors Tracing requirements for OPES processors are: o Each OPES processor MUST support tracing, policy can be used to turn tracing on and to determine its granularity. o If tracing is turned on, OPES processor SHOULD add its unique identification to the trace. Here, uniqueness scope is the OPES System containing the processor. o OPES processor SHOULD be able to trace it's own invocation and service(s) execution since it understands the application protocol. 3.4 Requirements for callout servers 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. Barbir Expires March 31, 2004 [Page = 7] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 4. Requirements for OPES System Bypass (Non-blocking feature) IAB recommendation (3.3) [2] requires that the OPES architecture = does not prevent a data consumer application from retrieving non-OPES version of content from a data provider application, provided that the non-OPES content exists. IAB recommendation (3.3) suggests that the Non-blocking feature (Bypass) be used to bypass faulty OPES intermediaries (once they have been identified, by some method). In addressing IAB consideration (3.3), one need to specify what constitute non-OPES content. In some cases, the definition of "non-OPES" content is provider-dependent and may include content adapted by OPES. Examples include content that is adapted for Black and White hand held devices or logging services. In other cases, the availability of certain content can be a function of the internal policy of a given organization that has contracted the services of = an OPES provider. For example, Company A has as contract with an OPES provider to perform virus checking on all e-mail attachments. An employee X of Company A can issue a non-blocking request for the virus scanning service. However, the request could be ignored by the OPES provider since it contradicts its agreement with Company A. The above examples illustrates that the availability of non-OPES content can be a function of content providers (or consumers or = both) policy and deployment scenarios [1]. For this reason, this work does not attempt to define what is an OPES content as opposed to non-OPES content. The meaning of OPES versus non-OPES content is assumed to = be determined through various agreements between the OPES provider, = data provider and data consumer application. The agreement will also determine what OPES services can be bypassed and in what order (if applicable). In an OPES System a Bypass request is defined as the 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). 4.1 What can be bypassed in an OPES Flow? In this work, the focus is on developing a bypass feature that allow a user to instruct the OPES System to bypass some or all of its services. The collection of OPES services that can be bypassed is a function of the agreement of the OPES provider with either (or both) the content provider or the content consumer applications. 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. An instruction may contain more than one such URI. A special wildcard Barbir Expires March 31, 2004 [Page = 8] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 identifier can be used to represent all possible URIs (i.e., all possible OPES services). 4.2 Bypass requirements for OPES System In an OPES System the Bypass feature is an end-to-end operation as opposed to a hop-by-hop operation. Bypass requests are generally client centric and go in the opposite direction of tracing requests. Bypass can be performed out of band or in-band. This work requires that the Bypass feature be performed in-band as an extension to an application specific protocol. Non-OPES entities should be able to safely ignore these extensions. The work does not prevent OPES Systems from developing their own out of band protocols. The following requirements apply for Bypass feature as related to an OPES System: 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). o An OPES System MUST treat a Bypass request as an end-to-end operation. This applies to the whole system. o An OPES System MUST include information about its bypass policy. o An OPES System MUST identify the party responsible for setting = and enforcing the bypass policy. o An OPES System MUST include information that identifies, to a technical contact, the OPES processors involved in processing = the bypass request. In addressing the above requirements an OPES System can provide a = URL to the OPES System web page that has links to Bypass and other policies. In order to facilitate the debugging (or data consumer user experience) of the bypass feature in an OPES System, it would be beneficial if non-bypassed entities include information related to 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. 4.3 Bypass requirements for OPES processors For a given application protocol, in an OPES System there can be Barbir Expires March 31, 2004 [Page = 9] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 services that operate on application message headers and those that just operate on content. This mix of service requires that an OPES processor that is calling the service(s) to handle the bypass request. 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. Bypass requirements for OPES processors are: o There MUST be at least one OPES processor in an OPES System that knows how to interpret and process a bypass request. This requirement applies to all bypass instructions, including those that identify known-to-recipient entities. o OPES processors that do not know how to process a bypass request MUST forward the request to the next application hop provided = that the next hop speaks application protocol with OPES bypass = support. o The recipient of a bypass instruction with a URI that does not identify any known-to-recipient OPES entity MUST treat that URI = as a wildcard identifier (meaning bypass all applicable services). o OPES processor SHOULD be able to bypass it's own invocation and service(s) execution since it understands the application protocol. 4.4 Bypass requirements for callout servers In an OPES system, it is the task of an OPES processor to process bypass requests. However, in some cases, callout servers May be involved in processing Bypass requests. This should be done under = the control of the OPES System provider. Barbir Expires March 31, 2004 [Page = 10] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 5. Protocol Binding The task of encoding tracing and bypass features is application protocol specific. Separate documents will address HTTP and other protocols. Barbir Expires March 31, 2004 [Page = 11] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 6. IANA considerations This specification contains no IANA considerations. Application bindings MAY contain application-specific IANA considerations. Barbir Expires March 31, 2004 [Page = 12] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 7. Security Considerations The security considerations for OPES are documented in [6]. This document is a requirement document for tracing and Bypass feature. The requirements that are stated in this document can be used to extend an application level protocol to support these features. As such, the work has security precautions. 7.1 Tracing security considerations The tracing facility for OPES architecture is implemented as a protocol extension. Inadequate implementations of the tracing facility may defeat safeguards built into the OPES architecture. The tracing facility by itself can become a target of malicious attacks or used to lunch attacks on an OPES System. Threats caused by or against the tracing facility can be viewed as threats at the application level in an OPES Flow. In this case, the threats can affect the data consumer and the data provider application. Since tracing information is a protocol extension, these traces can be injected in the data flow by non-OPES entities. In this case, there are risks that non-OPES entities can be compromised in a fashion that threat the overall integrity and effectiveness of an OPES System. For example, a non-OPES proxy can add fake tracing information into a trace. This can be done in the form of wrong, or unwanted, or non existent services. A non-OPES entity can inject large size traces that may cause buffer overflow in a data consumer application. The same threats can arise from compromised OPES entities. An attacker can control an OPES entity and inject wrong, = or very large trace information that can overwhelm an end or the next OPES entity in an OPES flow. Similar threats can result from bad implementations of the tracing facility in trusted OPES entities. Compromised tracing information can be used to launch attacks on an OPES System that give the impression that unwanted content transformation was performed on the data. This can be achieved by inserting wrong entity (such OPES processor) identifiers. A compromised trace can affect the overall message integrity = structure. This can affect entities that use message header information to perform services such as accounting, load balancing, or reference-based services. Compromised trace information can be used to launch DoS attacks that can overwhelm a data consumer application or an OPES entity in an OPES Flow. Inserting wrong tracing information can complicates the debugging tasks performed by system administrator during trouble Barbir Expires March 31, 2004 [Page = 13] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 shooting of OPES System behavior. Specific protocol binding documents ought to take these security threats into consideration. It is recommended that protocol bindings provide safe features into their specifications. Such features may include a place holder in the message header that indicates the size of the trace. Other holders can include the option of signing the trace information as a proof of authenticity. As a precaution, OPES entities ought to be capable of verifying that the inserted traces are performed by legal OPES entities. This can = be done as part of the authorization and authentication face. Policy = can be used to indicate what trace information can be expected from a peer entity. Other application level related security concerns can = be found in [6]. 7.2 Bypass security considerations The bypass facility for OPES architecture is implemented as a protocol extension. Inadequate implementations of the bypass = facility may defeat safeguards built into the OPES architecture. The bypass facility by itself can become a target of malicious attacks or used to lunch attacks on an OPES System. Threats caused by or against the bypass facility can be viewed as threats at the application level in an OPES Flow. In this case, the threats can affect the data consumer and the data provider application. 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. The above threats can also arise by compromised OPES entities. An intruder can compromise an OPES entities and then use Barbir Expires March 31, 2004 [Page = 14] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 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 illegally introduce bypass instructions into a data flow may effect the accounting of = the OPES System. It may also affect the quality of content that is delivered to the data consumer applications. Similar threats can arise from bad implementations of the bypass facility. Specific protocol binding documents ought to take these security threats into consideration. It is recommended that protocol bindings provide safe features into their specifications. Such features may include a place holder in the message header that indicates who originated the bypass request. Other holders can include the option of signing the bypass request as a proof of identity. Other application level related security concerns can be found in [6]. Barbir Expires March 31, 2004 [Page = 15] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 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. Barbir Expires March 31, 2004 [Page = 16] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 Informative References [2] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002. [3] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [4] A. Barbir et al., "Policy, Authorization and Enforcement Requirements of OPES", Internet-Draft http://www.ietf.org/ internet-drafts/draft-ietf-opes-authorization-02.txt, February 2003. [5] Rousskov, A., "HTTP adaptation with OPES", Internet-Draft TBD, September 2003. [6] A. Barbir et al., "Security Threats and Risks for Open = Pluggable Edge Services", Internet-Draft http://www.ietf.org/ internet-drafts/draft-ietf-opes-threats-02.txt, February 2003. [7] 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. [8] A. Barbir et al., "OPES Treatment of IAB Considerations", Internet-Draft http://www.ietf.org/internet-drafts/ draft-ietf-opes-iab-02.txt, February 2004. Author's Address Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean, Ontario K2H 8E9 Canada Phone: +1 613 763 5229 EMail: abbieb@nortelnetworks.com Barbir Expires March 31, 2004 [Page = 17] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 Appendix A. Acknowledgements Several people has contributed to this work. Many thanks to: Alex Rousskov, Hilarie Orman, Oscar Batuner, Markus Huffman, Martin Stecher, Marshall Rose and Reinaldo Penno. Barbir Expires March 31, 2004 [Page = 18] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances = of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification = can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph = are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Barbir Expires March 31, 2004 [Page = 19] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Barbir Expires March 31, 2004 [Page = 20] =0C ------_=_NextPart_000_01C394C8.49953592-- From owner-ietf-openproxy@mail.imc.org Fri Oct 17 14:11: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 OAA14015 for ; Fri, 17 Oct 2003 14:11:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAZ4n-0006gJ-00 for opes-archive@ietf.org; Fri, 17 Oct 2003 14:11:49 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AAZ4m-0006gG-00 for opes-archive@ietf.org; Fri, 17 Oct 2003 14:11:48 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9HHvpI7019906 for ; Fri, 17 Oct 2003 10:57:51 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9HHvpeB019905 for ietf-openproxy-bks; Fri, 17 Oct 2003 10:57:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9HHvoI7019900 for ; Fri, 17 Oct 2003 10:57:50 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h9HHvpGh006258; Fri, 17 Oct 2003 11:57:51 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9HHvpFN006257; Fri, 17 Oct 2003 11:57:51 -0600 (MDT) (envelope-from rousskov) Date: Fri, 17 Oct 2003 11:57:50 -0600 (MDT) From: Alex Rousskov To: "OPES WG (E-mail)" Subject: Re: sizep parameter again In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D0E65D1@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D0E65D1@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 think you've raised two important design questions that must be addressed explicitly, possibly in OCP Core (in part). (1) We need to be more clear what is being adapted, what is being supplied for information purposes only, what is being skipped, what is potentially stale and must be checked by processor (and when the checks are made). (2) We need a "content" size prediction for performance reasons, but we do not have a definition of "content", only data. Sizep seems to be useless. A new parameter, tied to the "content" definition is needed. "Content" definition should probably be application-specific and negotiable. On Fri, 17 Oct 2003, Martin Stecher wrote: > it is not even that the OPES processor MUST NOT by default trust the > Content-Length header returned by a callout service, actually > neither agent can trust that header. Debatable. This depends on where we place processor header-adjustment requirements: after all processing or after each processing step. > An OPES processor may call a first callout service and then forward > the response to a second callout service, i.e. implementing a pipe > of callout services. True. A good design will not place the second callout service at a disadvantage. Thus, either all callout services should assume out-of-sync headers or processor should fix headers after each service. The former deprives certain services from required information (they would have to buffer whole responses to obtain it). The latter makes pipelining impossible or inefficient in some situations. > We should not force the OPES processor to do the header correctness > check and recalculation after each callout service response but only > at the very end before sending on the HTTP message on the HTTP path. That's a design choice, but I tend to agree with your preference because more systems will benefit from a pipeline than from having message length to be known in advance. However, I sense that we are facing a bigger problem here that has to be addressed on a higher level. See below. > That means that a callout server may see the HTTP message that was > already modified by another service and hence some headers may be > incorrect. Exactly. Essentially, all headers in this case represent potentially stale information and are subject to further modification by processor and other services. On the other hand, a service may want to adapt some headers. Thus, we have one object (headers) that is partially stale and partially adapted. This is a mess. > I would therefore like to require that both agents MUST use sizep > parameter if they know the message length and no agent SHOULD trust > the Content-Length header. That would be a logical conclusion, yes. In that case, I would want to argue that Content-Length HTTP header MUST NOT be transmitted over OCP. However, logging services would need complete headers so that is not acceptable. > That makes it also simpler for the callout service to use the sizep > parameter. If the service does not need to parse the HTTP headers > for its filtering purpose, it would not be nice if it needs to > lookup the content length header value in order to insert sizep > parameters. If it already receives sizep from the OCP client, it has > an easier job. Agreed. > The OCP client, as typically being tightly bound to a HTTP proxy, > has probably easy access to the content length header of the message > (if any). Agreed. Even if the bound is not tight, a client must know message size one way or the other. On Fri, 17 Oct 2003, Martin Stecher wrote: > The sizep parameter is the "remaining application data prediction" > according to OCP-Core draft. > > I see some conflicts: > > 1. What if the agent knows that it will skip certain message parts? > Does it need to substract this skipped size from the sizep > parameter? This will break our Content-Length idea. sizep should refer to what the after-adaptation application message will look like. If a service deletes parts of a message, sizep will decrease. If a service ignores parts of a message but expects processor to add them, sizep will not change. Moreover, only content-related parts should be counted. > Or does skipping of parts not affect sizep parameter? Is this then > still the "remaining application data"? It looks like the definition has to be polished to reflect the "OCP client and server are working together on a complete application message, whether they see/skip/ignore parts or not" view. The definition of "application message" is to be negotiated. More below. > 2. What about optional parts? Should their size be added to sizep? > Will again break Content-Length trick. We need to change something here. Sizep should be referring to the thing we are adapting, not optional header information that may be supplied. Right? > 3. Trailers belong to the application data. Therefore the DUM > message containing the response-header should have a sizep parameter > equal to response-body size plus response-trailer size. But this is > not the size that we can use for Content-Length correction. True. It looks like sizep does not work on application data level (at that level all data looks the same). It works on a higher level, where headers are different from bodies different from trailers. I do not know if we can document sizep in a application-agnostic way. > 4. If response-header part is sent in multiple DUM messages, only > the last DUM message contains the correct sizep value. I am > concerned some implementations will not be prepared for this case. Sizep should probably not include HTTP headers in a standard HTTP profile. > Putting all this together, I feel that using the sizep parameter for > Content-Length indication does not really work. I agree. > Shouldn't we better introduce a Content-Length named parameter to > AMS messages that does what we really want: Promise a length that > can be used for HTTP Content-Length header correction? Does sizep have any useful purpose at the lower (application data) level it is being used right now? Should we delete sizep from the Core and add AM-CLP parameter instead (application message content length prediction)? Alex. From owner-ietf-openproxy@mail.imc.org Fri Oct 17 17:33: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 RAA25438 for ; Fri, 17 Oct 2003 17:33:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAcEK-0001s7-00 for opes-archive@ietf.org; Fri, 17 Oct 2003 17:33:52 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AAcEJ-0001s4-00 for opes-archive@ietf.org; Fri, 17 Oct 2003 17:33:51 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9HLLFI7026285 for ; Fri, 17 Oct 2003 14:21:15 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9HLLFiF026284 for ietf-openproxy-bks; Fri, 17 Oct 2003 14:21:15 -0700 (PDT) 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 h9HLLCI7026279 for ; Fri, 17 Oct 2003 14:21:13 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id Q3M2OJOXoutgoing id 3EZG0HYD; 18 Oct 2003 01:28:25 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: sizep parameter again Date: Fri, 17 Oct 2003 23:21:08 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D01406B@mail.webwasher.com> Thread-Topic: sizep parameter again Thread-Index: AcOU2DDN0qLmdU8ZQ8GU9njptjQXDQAGey3A From: "Martin Stecher" To: "OPES WG (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9HLLEI7026280 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > I think you've raised two important design questions that must > be addressed explicitly, possibly in OCP Core (in part). > > (1) We need to be more clear what is being adapted, what is > being supplied for information purposes only, what is being skipped, > what is potentially stale and must be checked by processor (and when > the checks are made). Yes. > > (2) We need a "content" size prediction for performance > reasons, but we do not have a definition of "content", only data. > Sizep seems to be useless. A new parameter, tied to the "content" > definition is needed. "Content" definition should probably be > application-specific and negotiable. I agree. > ... > > > Putting all this together, I feel that using the sizep parameter for > > Content-Length indication does not really work. > > I agree. > > > Shouldn't we better introduce a Content-Length named parameter to > > AMS messages that does what we really want: Promise a length that > > can be used for HTTP Content-Length header correction? > > Does sizep have any useful purpose at the lower (application data) > level it is being used right now? Should we delete sizep from the Core > and add AM-CLP parameter instead (application message content length > prediction)? > Yes, we should add AM-CLP. For the HTTP request profile this is the predicted length of the request-body message part. For the HTTP response profile this is the predicted length of the response-body message part. Correct? I suggest that the AM-CLP is not decreased from DUM to DUM message such as sizep. Is it suitable to make it a parameter of the AMS message and not of DUM messages? Is there then a useful purpose of sizep? I am not sure. I tend to agree that AM-CLP could replace sizep. The only purpose I can think of is to allow the peer to prepare some buffer size for all application data. I don't think that this will be necessary for HTTP adaption but it may make sense for other application bindings. Maybe we just leave sizep in. If it does not help, it does not hurt either as an optional parameter. What do you think? Martin From owner-ietf-openproxy@mail.imc.org Fri Oct 17 18:39:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28372 for ; Fri, 17 Oct 2003 18:39:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAdFY-0002Ue-00 for opes-archive@ietf.org; Fri, 17 Oct 2003 18:39:12 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AAdFX-0002Ub-00 for opes-archive@ietf.org; Fri, 17 Oct 2003 18:39:11 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9HMTRI7028329 for ; Fri, 17 Oct 2003 15:29:27 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9HMTROr028328 for ietf-openproxy-bks; Fri, 17 Oct 2003 15:29:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9HMTPI7028323 for ; Fri, 17 Oct 2003 15:29:25 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h9HMTRGh014143; Fri, 17 Oct 2003 16:29:27 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9HMTRTt014142; Fri, 17 Oct 2003 16:29:27 -0600 (MDT) (envelope-from rousskov) Date: Fri, 17 Oct 2003 16:29:27 -0600 (MDT) From: Alex Rousskov To: "OPES WG (E-mail)" Subject: RE: sizep parameter again In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D01406B@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D01406B@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 17 Oct 2003, Martin Stecher wrote: > Yes, we should add AM-CLP. > For the HTTP request profile this is the predicted length of the > request-body message part. > For the HTTP response profile this is the predicted length of the > response-body message part. Correct? Let's avoid confusions of RFC 2616 terminology in sections 4.4 Message Length and 14.13 Content-Length and use Section 7.2.2 Entity Length terminology instead. This will let us to be more precise. Also, note that "predictions" are usueless in this context because HTTP does not support them. If we do not know future length for sure, we should not be producing a Content-Length header. Let's call the HTTP-specific OCP named parameter "AM-EL" (application message entity length): An OCP Agent that knows the exact length of the HTTP message entity (Section 7.2.2 Entity Length in RFC 2616), SHOULD announce that length using an AM-EL named parameter of an AMS message. An OCP Agent that does not know the exact length of the HTTP message entity, MUST NOT include an AM-EL named parameter in AMS message. Informally, an abcent AM-EL parameter in an AMS message means that the entity length is not known a priory; an OPES processor would have to use chunked transfer-encoding or terminate the HTTP connection after sending the adapted HTTP message to the next HTTP hop. An OPES processor receiving an AM-EL parameter MAY use parameter value in a Content-Length HTTP entity header when constructing an HTTP message (provided a Content-Length HTTP entity header is allowed for the given application message by HTTP) and MAY forward it to the next callout service (if any). Whether a processor will use and forward AM-EL parameter depends primarily on how much it trusts the service to produce correct AM-EL values. Using and forwarding correct AM-EL values is important for HTTP and OCP pipelining optimizations. I am not so sure about the second paragraph. Perhaps the MUST NOT in the first paragraph is sufficient to replace all MAYs in the second paragraph with SHOULDs? Note that not using or not sending AM-EL does not break interoperability, so we cannot say MUST send/use/forward. Not using or not sending AM-EL breaks the OCP pipeline only. Thus, we can say SHOULD send/use/forward or MAY send/use/forward, probably depending on how many implementions are expected to send incorrect AM-ELs. > I suggest that the AM-CLP is not decreased from DUM to DUM message > such as sizep. Is it suitable to make it a parameter of the AMS > message and not of DUM messages? Yes, it is mostly useless in DUM messages. Let's make it AMS-exclusive. > Is there then a useful purpose of sizep? I am not sure. I tend to > agree that AM-CLP could replace sizep. The only purpose I can think > of is to allow the peer to prepare some buffer size for all > application data. I don't think that this will be necessary for HTTP > adaption but it may make sense for other application bindings. Maybe > we just leave sizep in. If it does not help, it does not hurt either > as an optional parameter. What do you think? I will be removing sizep from the Core. If we cannot think of a general purpose for it, it should not be there. Applications that need it will document it. Alex. From owner-ietf-openproxy@mail.imc.org Sat Oct 18 14:07: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 OAA04108 for ; Sat, 18 Oct 2003 14:07:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAvU8-0003y4-00 for opes-archive@ietf.org; Sat, 18 Oct 2003 14:07:28 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AAvU7-0003y0-00 for opes-archive@ietf.org; Sat, 18 Oct 2003 14:07:27 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IHu0I7026023 for ; Sat, 18 Oct 2003 10:56:00 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9IHu0TE026022 for ietf-openproxy-bks; Sat, 18 Oct 2003 10:56:00 -0700 (PDT) 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 h9IHtwI7026006 for ; Sat, 18 Oct 2003 10:55:59 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id 8FIRVTWVoutgoing id HORGW9XH; 18 Oct 2003 22:03:01 +0200 Subject: RE: sizep parameter again MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sat, 18 Oct 2003 19:55:44 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D01406C@mail.webwasher.com> X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: sizep parameter again Thread-Index: AcOU/iH9ktbqQBVcQB6WJOtXNBfuPgAnX59A From: "Martin Stecher" To: "OPES WG (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9IHtxI7026018 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > > Yes, we should add AM-CLP. > > For the HTTP request profile this is the predicted length of the > > request-body message part. > > For the HTTP response profile this is the predicted length of the > > response-body message part. Correct? > > Let's avoid confusions of RFC 2616 terminology in sections 4.4 Message > Length and 14.13 Content-Length and use Section 7.2.2 Entity Length > terminology instead. This will let us to be more precise. Though I do not see this as critical right now as we do not have transfer- codings, I agree that entity-length is more correct and should be used. > Also, note > that "predictions" are usueless in this context because HTTP does not > support them. If we do not know future length for sure, we should not > be producing a Content-Length header. You are right. > > Let's call the HTTP-specific OCP named parameter "AM-EL" (application > message entity length): ok. I will create a new section and introduce this parameter for AMS. > > An OCP Agent that knows the exact length of the HTTP > message entity (Section 7.2.2 Entity Length in RFC 2616), > SHOULD announce that length using an AM-EL named parameter > of an AMS message. May I quote you here, Alex? ;-) You wrote on June, 2nd: "Why not a MUST? If something so important is known, why not report it?" What I am missing in this description is the mention of the adapted message part. As you already pointed out earlier, we have to make it very clear what length we are talking about. If, for example, an OPES processor is sending a HTTP message for response modification with request-body as optional part and skipping the response- body part, the AM-EL parameter must still specify the size of the response body length and not of the request body length. How about this: An OCP Agent that knows the exact length of the HTTP message entity (Section 7.2.2 Entity Length in RFC 2616) at the time it sends the AMS message, MUST announce that length using an AM-EL named parameter of an AMS message. In the HTTP request profile AM-EL is the length of the request-body part and in the HTTP response profile the length of the response-body part each before any transfer-codings have been applied. > An OCP Agent that does not know the exact > length of the HTTP message entity, MUST NOT include an AM-EL > named parameter in AMS message. Informally, an abcent > AM-EL parameter in an AMS message means that the entity > length is not known a priory Good. > an OPES processor would > have to use chunked transfer-encoding or terminate > the HTTP connection after sending the adapted HTTP message > to the next HTTP hop. This is not always true. OPES processor could wait for the transaction to complete (on cost of latency) or close the connection. It's a little tricky and their is no general advice. I tried to discuss this is the draft in the section Message Header Correctness, subsection about Message Length. It's not yet perfect and needs polishing but I think it is better to have a separate section about this. > > An OPES processor receiving an AM-EL parameter MAY use > parameter value in a Content-Length HTTP entity header > when constructing an HTTP message (provided a > Content-Length HTTP entity header is allowed for the > given application message by HTTP) and MAY forward it to > the next callout service (if any). Whether a processor > will use and forward AM-EL parameter depends primarily on > how much it trusts the service to produce correct AM-EL > values. Using and forwarding correct AM-EL values is > important for HTTP and OCP pipelining optimizations. > > I am not so sure about the second paragraph. Perhaps the MUST NOT in > the first paragraph is sufficient to replace all MAYs in the second > paragraph with SHOULDs? Note that not using or not sending AM-EL does > not break interoperability, so we cannot say MUST send/use/forward. > Not using or not sending AM-EL breaks the OCP pipeline only. Thus, we > can say SHOULD send/use/forward or MAY send/use/forward, probably > depending on how many implementions are expected to send incorrect > AM-ELs. I think the specs should presume that most implementations are sending correct AM-ELs. Therefore I vote for SHOULD. Again, I would prefer to keep this short in the (new) section that will introduce AM-EL and have the detailed description in the message length section. > > > I suggest that the AM-CLP is not decreased from DUM to DUM message > > such as sizep. Is it suitable to make it a parameter of the AMS > > message and not of DUM messages? > > Yes, it is mostly useless in DUM messages. Let's make it > AMS-exclusive. Agreed. > > > Is there then a useful purpose of sizep? I am not sure. I tend to > > agree that AM-CLP could replace sizep. The only purpose I can think > > of is to allow the peer to prepare some buffer size for all > > application data. I don't think that this will be necessary for HTTP > > adaption but it may make sense for other application bindings. Maybe > > we just leave sizep in. If it does not help, it does not hurt either > > as an optional parameter. What do you think? > > I will be removing sizep from the Core. If we cannot think of a > general purpose for it, it should not be there. Applications that need > it will document it. Fine with me. Regards Martin From owner-ietf-openproxy@mail.imc.org Sun Oct 19 23:01: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 XAA27775 for ; Sun, 19 Oct 2003 23:01:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABQIo-00039V-00 for opes-archive@ietf.org; Sun, 19 Oct 2003 23:01:50 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ABQIn-00039P-00 for opes-archive@ietf.org; Sun, 19 Oct 2003 23:01:49 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9K2mSI7005116 for ; Sun, 19 Oct 2003 19:48:28 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9K2mS2j005115 for ietf-openproxy-bks; Sun, 19 Oct 2003 19:48:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9K2mQI7005109 for ; Sun, 19 Oct 2003 19:48:26 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h9K2mSGh090220; Sun, 19 Oct 2003 20:48:28 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9K2mIP1090219; Sun, 19 Oct 2003 20:48:18 -0600 (MDT) (envelope-from rousskov) Date: Sun, 19 Oct 2003 20:48:18 -0600 (MDT) From: Alex Rousskov To: "OPES WG (E-mail)" Subject: RE: sizep parameter again In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D01406C@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D01406C@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, 18 Oct 2003, Martin Stecher wrote: > > An OCP Agent that knows the exact length of the HTTP > > message entity (Section 7.2.2 Entity Length in RFC 2616), > > SHOULD announce that length using an AM-EL named parameter > > of an AMS message. > > May I quote you here, Alex? ;-) > You wrote on June, 2nd: > "Why not a MUST? If something so important is known, why not report it?" :-) Answering my own question here, apparently: if NOT doing the required action does not lead to interoperability problems, it is a SHOULD, not a MUST. But this is all very fuzzy, of course. If you prefer a MUST, I would not argue (for a few months, anyway). > What I am missing in this description is the mention of the adapted > message part. As you already pointed out earlier, we have to make it > very clear what length we are talking about. If, for example, an > OPES processor is sending a HTTP message for response modification > with request-body as optional part and skipping the response- body > part, the AM-EL parameter must still specify the size of the > response body length and not of the request body length. > > How about this: > > An OCP Agent that knows the exact length of the HTTP > message entity (Section 7.2.2 Entity Length in RFC 2616) > at the time it sends the AMS message, MUST announce that > length using an AM-EL named parameter of an AMS message. > In the HTTP request profile AM-EL is the length of the > request-body part and in the HTTP response profile the > length of the response-body part each before any > transfer-codings have been applied. I agree that we have to be specific. Your version is fine. It might be better to document "entity" when we document "profiles" instead of piggibacking entity definition to this requirement, but this is up to you. > > an OPES processor would > > have to use chunked transfer-encoding or terminate > > the HTTP connection after sending the adapted HTTP message > > to the next HTTP hop. > > This is not always true. OPES processor could wait for the > transaction to complete (on cost of latency) or close the > connection. It's a little tricky and their is no general advice. I > tried to discuss this is the draft in the section Message Header > Correctness, subsection about Message Length. It's not yet perfect > and needs polishing but I think it is better to have a separate > section about this. Agreed. > I think the specs should presume that most implementations are sending > correct AM-ELs. Therefore I vote for SHOULD. Agreed. > Again, I would prefer to keep this short in the (new) section that > will introduce AM-EL and have the detailed description in the > message length section. Agreed. Alex. From owner-ietf-openproxy@mail.imc.org Mon Oct 20 11:47: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 LAA01340 for ; Mon, 20 Oct 2003 11:47:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABcFv-0001Zw-00 for opes-archive@ietf.org; Mon, 20 Oct 2003 11:47:40 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ABcFv-0001Zt-00 for opes-archive@ietf.org; Mon, 20 Oct 2003 11:47:39 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9KFYMI7096831 for ; Mon, 20 Oct 2003 08:34:22 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9KFYM28096830 for ietf-openproxy-bks; Mon, 20 Oct 2003 08:34:22 -0700 (PDT) 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 h9KFYJI7096823 for ; Mon, 20 Oct 2003 08:34:20 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id 1Y3E3AROoutgoing id RNQZS655; 20 Oct 2003 19:41:23 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: OCP/HTTP sample updated Date: Mon, 20 Oct 2003 17:34:05 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D0E65EF@mail.webwasher.com> Thread-Topic: OCP/HTTP sample updated Thread-Index: AcOXH5iFTSAuXyDCQY6JucDeWILEYg== From: "Martin Stecher" To: "OPES WG (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9KFYLI7096825 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit 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 Oct 20 16:01:15 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27100 for ; Mon, 20 Oct 2003 16:01:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABgDT-0006NT-00 for opes-archive@ietf.org; Mon, 20 Oct 2003 16:01:23 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ABgDS-0006N3-00 for opes-archive@ietf.org; Mon, 20 Oct 2003 16:01:22 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9KJjUI7006244 for ; Mon, 20 Oct 2003 12:45:30 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9KJjU8P006243 for ietf-openproxy-bks; Mon, 20 Oct 2003 12:45:30 -0700 (PDT) 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 h9KJjTI7006237 for ; Mon, 20 Oct 2003 12:45:29 -0700 (PDT) (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 PAA22197; Mon, 20 Oct 2003 15:45:20 -0400 (EDT) Message-Id: <200310201945.PAA22197@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-end-comm-04.txt Date: Mon, 20 Oct 2003 15:45:20 -0400 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 processor and end points communications Author(s) : A. Barbir Filename : draft-ietf-opes-end-comm-04.txt Pages : 20 Date : 2003-10-20 This memo documents tracing requirements for Open Pluggable Edge Services (OPES) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opes-end-comm-04.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-end-comm-04.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-end-comm-04.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-10-20145318.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-opes-end-comm-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-opes-end-comm-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-20145318.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-openproxy@mail.imc.org Tue Oct 21 00:44: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 AAA22376 for ; Tue, 21 Oct 2003 00:44:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABoO4-0006qn-00 for opes-archive@ietf.org; Tue, 21 Oct 2003 00:44:52 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ABoO4-0006qj-00 for opes-archive@ietf.org; Tue, 21 Oct 2003 00:44:52 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9L4WpI7025923 for ; Mon, 20 Oct 2003 21:32:51 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9L4WpqP025922 for ietf-openproxy-bks; Mon, 20 Oct 2003 21:32:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9L4WoI7025912 for ; Mon, 20 Oct 2003 21:32:50 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h9L4WrGh027675 for ; Mon, 20 Oct 2003 22:32:53 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9L4WrFv027674; Mon, 20 Oct 2003 22:32:53 -0600 (MDT) (envelope-from rousskov) Date: Mon, 20 Oct 2003 22:32:52 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: feedback on draft-ietf-opes-end-comm-04 In-Reply-To: <200310201945.PAA22197@ietf.org> Message-ID: References: <200310201945.PAA22197@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Abbie, Yet another significantly improved draft version, thank you! Here are a few remaining (mostly high-level) issues that I could spot after a quick review: * Please cite RFC 2119 * In Section 3.2 "Requirements for OPES System" you list 5 MUST-level requirements for adding information to the trace and then finish off with informative (not-normative) text saying that most of the above requirements can be satisfied by providing a URL to a web site. If we ignore informative text, the requirements are likely to cause too large trace entries. We need to convert informative text to a normative one. For example, you could add another requirement similar to the one below: When providing required information, an OPES System MAY use a single URI to identify a resource containing several required items. For example, an OPES System can point to a single web page with a reference to System privacy policy and technical contact information. I also believe that we must add explicit text clarifying the meaning of the terms used by this section rules. Something along these lines: 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. In other words, we are saying that Systems must provide something that they believe is a privacy policy or technical contact OR that other specs may define these terms and details. This is a very important "full disclosure" statement of our inability to fully address a known problem. > An OPES system MUST add its identification to the trace. Any requirements regarding System identification? Is it supposed to be globally unique, for example? If yes, then are we proposing a registry for system IDs?? If not, then a system can use "system" as an identifier and satisfy the above requirement. > An OPES System MUST include information that identifies, to the > technical contact, the OPES processors involved in processing the > message. This contradicts the fact that OPES processor tracing is not a MUST, does not it? Given this two contradicting requirements, it is not clear whether an end is guaranteed a processor trace entry for each processor involved. Please resolve this important conflict. > Each OPES processor MUST support tracing, policy can be used to turn > tracing on and to determine its granularity. I continue to note that the above requirement does not make much sense to me. If a policy can be used, can I use a policy that always turns tracing off and have that as the only, hard-coded policy? I think this is a failed attempt to appear directly compliant with an IAB consideration and it should be removed. > OPES processor SHOULD be able to trace it's own invocation and > service(s) execution since it understands the application protocol. Is it a requirement or a consequence of the "since it understands" part? There is another "SHOULD ... since" requirement elsewhere in the draft. * Please make sure that all "May"s are converted to "MAY"s or "may"s. * Please include a Compliance Considerations section or equivalent. What does it mean to be compliant with your spec? Are there multiple levels of compliance? > the definition of "non-OPES" content is provider-dependent and may > include content adapted by OPES. I agree with the first part, but cannot concatenate that with the second part. Given an OPES-adapted content, a content provider may designate any other content as a non-OPES content, but that designated content cannot be OPES-adapted. > Examples include content that is adapted for Black > and White hand held devices or logging services. Is this an example of non-OPES content or OPES content? Please give a single example that contains both so that the difference becomes clear. > An OPES System MUST include information about its bypass policy. > An OPES System MUST identify the party responsible for setting > and enforcing the bypass policy. > An OPES System MUST include information that identifies, to a > technical contact, the OPES processors involved in processing the > bypass request. MUST include/identify where? In a trace? Then these should be moved to tracing requirements. > OPES processor SHOULD be able to bypass it's own invocation Isn't this a self-contradiction? Like lifting oneself by one's own hair? If the processor is looking at the bypass instruction, it is already invoked. > Specific protocol binding documents ought to take these security > threats into consideration. It is recommended that protocol bindings > provide safe features into their specifications. Such features may > include a place holder in the message header that indicates the size > of the trace. I am not sure what you mean here. The documented security threats do not seem to be application-specific so it it not clear why or how application-specific specifications can "take them into consideration". * Please add "inconsistent/selective bypass" as a threat: One end can try to bypass a subset of OPES entities so that the resulting content is malformed and crashes or compromises entities that process that content (and expect that content to be complete and valid). Such exceptions are often not tested because implementors do not expect a vital service to "disappear" from the processing loop. * Please add "ACL bypass" as a threat: Systems implementing access controls via OPES entities may be incorrectly configured to honor bypass and, hence, give unauthorized access to the world. * Please add "Tap bypass" as a threat: Systems implementing "wiretaps" of all sorts via OPES entities may be incorrectly configured to honor bypass and, hence, ignore (leave undetected) traffic with bypass instructions that should have been tapped/logged. * Do you already document a threat where one end can disable things like virus checkers at the other edge? Please add if not. I am sure you cover this in some general statement, but general security statements are known to be ignored. We need specific examples to get folks attention. > There are risks for the OPES System by non-OPES entities, whereby, > these entities can insert bypass instructions into the OPES Flow. Isn't that usually the case that bypass instructions are inserted by non-OPES entities (e.g., end-user browsers)? > The ability to illegally introduce bypass instructions into a data > flow Do we define a legal way of introducing bypass instructions? > [5] Rousskov, A., "HTTP adaptation with OPES", Internet-Draft TBD, Please update the above reference, including the authors list. > draft-ietf-opes-iab-02.txt, February 2004 What's the price of MS stock in your time zone? :-) Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Tue Oct 21 11:56:09 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24217 for ; Tue, 21 Oct 2003 11:56:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AByrr-0005I4-00 for opes-archive@ietf.org; Tue, 21 Oct 2003 11:56:19 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AByrp-0005I1-00 for opes-archive@ietf.org; Tue, 21 Oct 2003 11:56:18 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LFekI7029188 for ; Tue, 21 Oct 2003 08:40:46 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LFekVu029187 for ietf-openproxy-bks; Tue, 21 Oct 2003 08:40:46 -0700 (PDT) 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 h9LFejI7029175 for ; Tue, 21 Oct 2003 08:40:45 -0700 (PDT) (envelope-from markus@mhof.com) Received: from mhof.com (unknown[135.104.20.78]) by comcast.net (sccrmhc11) with SMTP id <2003102115404001100fqmhue> (Authid: mhofmann); Tue, 21 Oct 2003 15:40:40 +0000 Message-ID: <3F95537A.6050007@mhof.com> Date: Tue, 21 Oct 2003 11:40:42 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES WG Subject: Re: feedback on draft-ietf-opes-end-comm-04 References: <200310201945.PAA22197@ietf.org> 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, please follow Alex example and take a very, very careful look at this version of the draft (draft-ietf-opes-end-comm-04). THIS IS THE FINAL DOCUMENT CANDIDATE. Please post your comments to the mailing list by 11/1, so that Abbie can prepare the final document, on which we'll then issue WGLC. I'd expect that open issues get resolved beforehand, so please check it out NOW!! Thanks, Markus Alex Rousskov wrote: > Abbie, > > Yet another significantly improved draft version, thank you! > Here are a few remaining (mostly high-level) issues that I could spot > after a quick review: > > * Please cite RFC 2119 > > * In Section 3.2 "Requirements for OPES System" you list 5 MUST-level > requirements for adding information to the trace and then finish off > with informative (not-normative) text saying that most of the above > requirements can be satisfied by providing a URL to a web site. If we > ignore informative text, the requirements are likely to cause too > large trace entries. We need to convert informative text to a > normative one. For example, you could add another requirement similar > to the one below: > > When providing required information, an OPES System MAY > use a single URI to identify a resource containing several > required items. For example, an OPES System can point to > a single web page with a reference to System privacy policy > and technical contact information. > > I also believe that we must add explicit text clarifying the meaning > of the terms used by this section rules. Something along these lines: > > 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. > > In other words, we are saying that Systems must provide something that > they believe is a privacy policy or technical contact OR that other > specs may define these terms and details. This is a very important > "full disclosure" statement of our inability to fully address a known > problem. > > >>An OPES system MUST add its identification to the trace. > > > Any requirements regarding System identification? Is it supposed to be > globally unique, for example? If yes, then are we proposing a registry > for system IDs?? If not, then a system can use "system" as an > identifier and satisfy the above requirement. > > >>An OPES System MUST include information that identifies, to the >>technical contact, the OPES processors involved in processing the >>message. > > > This contradicts the fact that OPES processor tracing is not a MUST, > does not it? Given this two contradicting requirements, it is not > clear whether an end is guaranteed a processor trace entry for each > processor involved. Please resolve this important conflict. > > >>Each OPES processor MUST support tracing, policy can be used to turn >>tracing on and to determine its granularity. > > > I continue to note that the above requirement does not make much sense > to me. If a policy can be used, can I use a policy that always turns > tracing off and have that as the only, hard-coded policy? I think this > is a failed attempt to appear directly compliant with an IAB > consideration and it should be removed. > > >>OPES processor SHOULD be able to trace it's own invocation and >>service(s) execution since it understands the application protocol. > > > Is it a requirement or a consequence of the "since it understands" > part? There is another "SHOULD ... since" requirement elsewhere in the > draft. > > * Please make sure that all "May"s are converted to "MAY"s or "may"s. > > * Please include a Compliance Considerations section or equivalent. > What does it mean to be compliant with your spec? Are there multiple > levels of compliance? > > >>the definition of "non-OPES" content is provider-dependent and may >>include content adapted by OPES. > > > I agree with the first part, but cannot concatenate that with the > second part. Given an OPES-adapted content, a content provider may > designate any other content as a non-OPES content, but that designated > content cannot be OPES-adapted. > > >>Examples include content that is adapted for Black >>and White hand held devices or logging services. > > > Is this an example of non-OPES content or OPES content? Please give a > single example that contains both so that the difference becomes > clear. > > > >>An OPES System MUST include information about its bypass policy. > > >>An OPES System MUST identify the party responsible for setting >>and enforcing the bypass policy. > > >>An OPES System MUST include information that identifies, to a >>technical contact, the OPES processors involved in processing the >>bypass request. > > > MUST include/identify where? In a trace? Then these should be moved to > tracing requirements. > > >>OPES processor SHOULD be able to bypass it's own invocation > > > Isn't this a self-contradiction? Like lifting oneself by one's own > hair? If the processor is looking at the bypass instruction, it is > already invoked. > > >>Specific protocol binding documents ought to take these security >>threats into consideration. It is recommended that protocol bindings >>provide safe features into their specifications. Such features may >>include a place holder in the message header that indicates the size >>of the trace. > > > I am not sure what you mean here. The documented security threats do > not seem to be application-specific so it it not clear why or how > application-specific specifications can "take them into > consideration". > > * Please add "inconsistent/selective bypass" as a threat: One end can > try to bypass a subset of OPES entities so that the resulting > content is malformed and crashes or compromises entities that > process that content (and expect that content to be complete and > valid). Such exceptions are often not tested because implementors do > not expect a vital service to "disappear" from the processing loop. > > * Please add "ACL bypass" as a threat: Systems implementing access > controls via OPES entities may be incorrectly configured to honor > bypass and, hence, give unauthorized access to the world. > > * Please add "Tap bypass" as a threat: Systems implementing "wiretaps" > of all sorts via OPES entities may be incorrectly configured to > honor bypass and, hence, ignore (leave undetected) traffic with > bypass instructions that should have been tapped/logged. > > * Do you already document a threat where one end can disable things > like virus checkers at the other edge? Please add if not. I am sure > you cover this in some general statement, but general security > statements are known to be ignored. We need specific examples to > get folks attention. > > >>There are risks for the OPES System by non-OPES entities, whereby, >>these entities can insert bypass instructions into the OPES Flow. > > > Isn't that usually the case that bypass instructions are inserted by > non-OPES entities (e.g., end-user browsers)? > > >>The ability to illegally introduce bypass instructions into a data >>flow > > > Do we define a legal way of introducing bypass instructions? > > >>[5] Rousskov, A., "HTTP adaptation with OPES", Internet-Draft TBD, > > > Please update the above reference, including the authors list. > > >>draft-ietf-opes-iab-02.txt, February 2004 > > > What's the price of MS stock in your time zone? :-) > > > Thank you, > > Alex. From owner-ietf-openproxy@mail.imc.org Tue Oct 21 13:33: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 NAA27331 for ; Tue, 21 Oct 2003 13:33:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC0OE-0006OQ-00 for opes-archive@ietf.org; Tue, 21 Oct 2003 13:33:50 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AC0OD-0006OM-00 for opes-archive@ietf.org; Tue, 21 Oct 2003 13:33:49 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LHHrI7032489 for ; Tue, 21 Oct 2003 10:17:53 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LHHrxL032488 for ietf-openproxy-bks; Tue, 21 Oct 2003 10:17:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LHHqI7032482 for ; Tue, 21 Oct 2003 10:17:53 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9LHHbN18829; Tue, 21 Oct 2003 13:17:38 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Oct 2003 13:17:38 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754074E6DC6@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Alex Rousskov , OPES WG Subject: RE: feedback on draft-ietf-opes-end-comm-04 Date: Tue, 21 Oct 2003 13:17:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C397F7.38E04DEA" 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_01C397F7.38E04DEA Content-Type: text/plain Alex, Thanks for the feedback. see inline Abbie > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Tuesday, October 21, 2003 12:33 AM > To: OPES WG > Subject: feedback on draft-ietf-opes-end-comm-04 > SNIP > > An OPES system MUST add its identification to the trace. > > Any requirements regarding System identification? Is it > supposed to be globally unique, for example? If yes, then are > we proposing a registry for system IDs?? If not, then a > system can use "system" as an identifier and satisfy the > above requirement. > No registery is proposed. Can u be more clear on what do u mean by system? Give an example please. > > An OPES System MUST include information that identifies, to the > > technical contact, the OPES processors involved in processing the > > message. > > This contradicts the fact that OPES processor tracing is not > a MUST, does not it? Given this two contradicting > requirements, it is not clear whether an end is guaranteed a > processor trace entry for each processor involved. Please > resolve this important conflict. > OPES tracing is a MUST. I do not see why u say contradicting statment. > > Each OPES processor MUST support tracing, policy can be > used to turn > > tracing on and to determine its granularity. > > I continue to note that the above requirement does not make > much sense to me. If a policy can be used, can I use a policy > that always turns tracing off and have that as the only, > hard-coded policy? I think this is a failed attempt to appear > directly compliant with an IAB consideration and it should be removed. > Alex, if your ploicy trun all processor off, then u r not compliant. SNIP ------_=_NextPart_001_01C397F7.38E04DEA Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: feedback on draft-ietf-opes-end-comm-04

Alex,
Thanks for the feedback.
see inline

Abbie


> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Tuesday, October 21, 2003 12:33 AM
> To: OPES WG
> Subject: feedback on = draft-ietf-opes-end-comm-04
>
SNIP


> > An OPES system MUST add its identification = to the trace.
>
> Any requirements regarding System = identification? Is it
> supposed to be globally unique, for example? If = yes, then are
> we proposing a registry for system IDs?? If = not, then a
> system can use "system" as an = identifier and satisfy the
> above requirement.
>

No registery is proposed.
Can u be more clear on what do u mean by system? = Give an example please.


> > An OPES System MUST include information = that identifies, to the
> > technical contact, the OPES processors = involved in processing the
> > message.
>
> This contradicts the fact that OPES processor = tracing is not
> a MUST, does not it? Given this two = contradicting
> requirements, it is not clear whether an end is = guaranteed a
> processor trace entry for each processor = involved. Please
> resolve this important conflict.
>

OPES tracing is a MUST.

I do not see why u say contradicting statment.


> > Each OPES processor MUST support tracing, = policy can be
> used to turn
> > tracing on and to determine its = granularity.
>
> I continue to note that the above requirement = does not make
> much sense to me. If a policy can be used, can = I use a policy
> that always turns tracing off and have that as = the only,
> hard-coded policy? I think this is a failed = attempt to appear
> directly compliant with an IAB consideration = and it should be removed.
>

Alex, if your ploicy trun all processor off, then u r = not compliant.

SNIP



------_=_NextPart_001_01C397F7.38E04DEA-- From owner-ietf-openproxy@mail.imc.org Tue Oct 21 13:43:10 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27822 for ; Tue, 21 Oct 2003 13:43:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC0XO-0006Yn-00 for opes-archive@ietf.org; Tue, 21 Oct 2003 13:43:18 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AC0XN-0006Yk-00 for opes-archive@ietf.org; Tue, 21 Oct 2003 13:43:18 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LHUfI7032787 for ; Tue, 21 Oct 2003 10:30:41 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LHUfJ7032786 for ietf-openproxy-bks; Tue, 21 Oct 2003 10:30:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LHUeI7032781 for ; Tue, 21 Oct 2003 10:30:40 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9LHUSN20577; Tue, 21 Oct 2003 13:30:28 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Oct 2003 13:30:29 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754074E6DFF@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Alex Rousskov , OPES WG Subject: RE: feedback on draft-ietf-opes-end-comm-04 Date: Tue, 21 Oct 2003 13:30:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C397F9.042F9446" 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_01C397F9.042F9446 Content-Type: text/plain see inline, abbie > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Tuesday, October 21, 2003 12:33 AM > To: OPES WG > Subject: feedback on draft-ietf-opes-end-comm-04 > > SNIP > > OPES processor SHOULD be able to trace it's own invocation and > > service(s) execution since it understands the application protocol. > > Is it a requirement or a consequence of the "since it > understands" part? There is another "SHOULD ... since" > requirement elsewhere in the draft. > The since explains why the SHOULD was there in the first place. If still unhappy can u reword please. SNIP > > the definition of "non-OPES" content is provider-dependent and may > > include content adapted by OPES. > > I agree with the first part, but cannot concatenate that with > the second part. Given an OPES-adapted content, a content > provider may designate any other content as a non-OPES > content, but that designated content cannot be OPES-adapted. > I see the confusion. I will fix it. SNIP > > An OPES System MUST include information about its bypass policy. > > > An OPES System MUST identify the party responsible for setting and > > enforcing the bypass policy. > > > An OPES System MUST include information that identifies, to a > > technical contact, the OPES processors involved in processing the > > bypass request. > > MUST include/identify where? In a trace? Then these should be > moved to tracing requirements. > Should be included in the OPES provider policy. > > OPES processor SHOULD be able to bypass it's own invocation > > Isn't this a self-contradiction? Like lifting oneself by > one's own hair? If the processor is looking at the bypass > instruction, it is already invoked. > This means bypass services that it is responsible for. This may be obvious, so i can deleted. SNIP ------_=_NextPart_001_01C397F9.042F9446 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: feedback on draft-ietf-opes-end-comm-04

see inline,

abbie

> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Tuesday, October 21, 2003 12:33 AM
> To: OPES WG
> Subject: feedback on = draft-ietf-opes-end-comm-04
>
>
SNIP

> > OPES processor SHOULD be able to trace it's = own invocation and
> > service(s) execution since it understands = the application protocol.
>
> Is it a requirement or a consequence of the = "since it
> understands" part? There is another = "SHOULD ... since"
> requirement elsewhere in the draft.
>

The since explains why the SHOULD was there in the = first place. If still unhappy can u reword please.


SNIP

> > the definition of "non-OPES" = content is provider-dependent and may
> > include content adapted by OPES.
>
> I agree with the first part, but cannot = concatenate that with
> the second part. Given an OPES-adapted content, = a content
> provider may designate any other content as a = non-OPES
> content, but that designated content cannot be = OPES-adapted.
>


I see the confusion. I will fix it.

SNIP
 
> > An  OPES System MUST include = information about its bypass policy.
>
> > An OPES System MUST identify the party = responsible for setting and
> > enforcing the bypass policy.
>
> > An OPES System MUST include information = that identifies, to a
> > technical contact, the OPES  = processors involved in processing the
> > bypass request.
>
> MUST include/identify where? In a trace? Then = these should be
> moved to tracing requirements.
>

Should be included in the OPES provider = policy.

> > OPES processor SHOULD be able to bypass = it's own invocation
>
> Isn't this a self-contradiction? Like lifting = oneself by
> one's own hair? If the processor is looking at = the bypass
> instruction, it is already invoked.
>


This means bypass services that it is responsible = for. This may be obvious, so i can deleted.

SNIP


------_=_NextPart_001_01C397F9.042F9446-- From owner-ietf-openproxy@mail.imc.org Tue Oct 21 13:50: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 NAA28053 for ; Tue, 21 Oct 2003 13:50:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC0e4-0006gJ-00 for opes-archive@ietf.org; Tue, 21 Oct 2003 13:50:12 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AC0e3-0006gG-00 for opes-archive@ietf.org; Tue, 21 Oct 2003 13:50:12 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LHcII7032960 for ; Tue, 21 Oct 2003 10:38:18 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LHcIx3032959 for ietf-openproxy-bks; Tue, 21 Oct 2003 10:38:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LHcGI7032952 for ; Tue, 21 Oct 2003 10:38:16 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h9LHcHGh045812; Tue, 21 Oct 2003 11:38:17 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9LHcHvR045811; Tue, 21 Oct 2003 11:38:17 -0600 (MDT) (envelope-from rousskov) Date: Tue, 21 Oct 2003 11:38:17 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: RE: feedback on draft-ietf-opes-end-comm-04 In-Reply-To: <87609AFB433BD5118D5E0002A52CD754074E6DC6@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD754074E6DC6@zcard0k6.ca.nortel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 21 Oct 2003, Abbie Barbir wrote: > Can u be more clear on what do u mean by system? Give an example > please. You already have a definition of an OPES system. I do not mean anything beyond that. An example would be a CDN doing distribution and adaptation of an example.com web site. > > > An OPES System MUST include information that identifies, to the > > > technical contact, the OPES processors involved in processing the > > > message. > > > > This contradicts the fact that OPES processor tracing is not > > a MUST, does not it? Given this two contradicting > > requirements, it is not clear whether an end is guaranteed a > > processor trace entry for each processor involved. Please > > resolve this important conflict. > > > > OPES tracing is a MUST. > > I do not see why u say contradicting statment. I am talking about specific requirements you have in the draft. There is no "OPES tracing is a MUST" requirement. However, there is a requirement quoted above that implies that an OPES System MUST trace every OPES processor. Since OPES System has to delegate actual actions to processors, the above really means that an OPES processor MUST trace itself. There is also a requirement on page 6 that "OPES processor SHOULD add its entry to the trace". For me, there is a requirement level conflict here. Either it is a SHOULD or a MUST, it cannot be both. > > > > Each OPES processor MUST support tracing, policy can be used to > > > turn tracing on and to determine its granularity. > > > > I continue to note that the above requirement does not make much > > sense to me. If a policy can be used, can I use a policy that > > always turns tracing off and have that as the only, hard-coded > > policy? I think this is a failed attempt to appear directly > > compliant with an IAB consideration and it should be removed. > > > > Alex, if your ploicy trun all processor off, then u r not compliant. Why? I am not violating the "support" requirement above. Alex. From owner-ietf-openproxy@mail.imc.org Tue Oct 21 14:11:15 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28799 for ; Tue, 21 Oct 2003 14:11:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC0ya-0006yL-00 for opes-archive@ietf.org; Tue, 21 Oct 2003 14:11:24 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AC0yY-0006y6-00 for opes-archive@ietf.org; Tue, 21 Oct 2003 14:11:23 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LHw1I7033603 for ; Tue, 21 Oct 2003 10:58:01 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LHw1hS033602 for ietf-openproxy-bks; Tue, 21 Oct 2003 10:58:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LHw0I7033595 for ; Tue, 21 Oct 2003 10:58:00 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9LHvnN24387; Tue, 21 Oct 2003 13:57:50 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Oct 2003 13:57:50 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754074E6E5C@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Alex Rousskov , OPES WG Subject: RE: feedback on draft-ietf-opes-end-comm-04 Date: Tue, 21 Oct 2003 13:57:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C397FC.D7BDDB44" 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_01C397FC.D7BDDB44 Content-Type: text/plain > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Tuesday, October 21, 2003 1:38 PM > To: OPES WG > Subject: RE: feedback on draft-ietf-opes-end-comm-04 > > > SNIP > I am talking about specific requirements you have in the > draft. There is no "OPES tracing is a MUST" requirement. > However, there is a requirement quoted above that implies > that an OPES System MUST trace every OPES processor. Since > OPES System has to delegate actual actions to processors, the > above really means that an OPES processor MUST trace itself. > There is also a requirement on page 6 that "OPES processor > SHOULD add its entry to the trace". For me, there is a > requirement level conflict here. Either it is a SHOULD or a > MUST, it cannot be both. > Ok, I see. I could make it both a SHOULD. But does this result that tracing in the system is not a MUST. > > > > > > Each OPES processor MUST support tracing, policy can be used to > > > > turn tracing on and to determine its granularity. > > > > > > I continue to note that the above requirement does not make much > > > sense to me. If a policy can be used, can I use a policy > that always > > > turns tracing off and have that as the only, hard-coded policy? I > > > think this is a failed attempt to appear directly > compliant with an > > > IAB consideration and it should be removed. > > > > > > > Alex, if your ploicy trun all processor off, then u r not compliant. > > Why? I am not violating the "support" requirement above. > > Alex. > If tracing is off for all, then u r not supporting tracing. Abbie ------_=_NextPart_001_01C397FC.D7BDDB44 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: feedback on draft-ietf-opes-end-comm-04

> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Tuesday, October 21, 2003 1:38 PM
> To: OPES WG
> Subject: RE: feedback on = draft-ietf-opes-end-comm-04
>
>
>
SNIP

> I am talking about specific requirements you = have in the
> draft. There is no "OPES tracing is a = MUST" requirement.
> However, there is a requirement quoted above = that implies
> that an OPES System MUST trace every OPES = processor. Since
> OPES System has to delegate actual actions to = processors, the
> above really means that an OPES processor MUST = trace itself.
> There is also a requirement on page 6 that = "OPES processor
> SHOULD add its entry to the trace". For = me, there is a
> requirement level conflict here. Either it is a = SHOULD or a
> MUST, it cannot be both.
>


Ok, I see.
I could make it both a SHOULD. But does this result = that tracing in the system is not a MUST.


> >
> > > > Each OPES processor MUST support = tracing, policy can be used to
> > > > turn tracing on and to determine = its granularity.
> > >
> > > I continue to note that the above = requirement does not make much
> > > sense to me. If a policy can be used, = can I use a policy
> that always
> > > turns tracing off and have that as = the only, hard-coded policy? I
> > > think this is a failed attempt to = appear directly
> compliant with an
> > > IAB consideration and it should be = removed.
> > >
> >
> > Alex, if your ploicy trun all processor = off, then u r not compliant.
>
> Why? I am not violating the "support" = requirement above.
>
> Alex.
>

If tracing is off for all, then u r not supporting = tracing.

Abbie

 

------_=_NextPart_001_01C397FC.D7BDDB44-- From owner-ietf-openproxy@mail.imc.org Tue Oct 21 14:22:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29077 for ; Tue, 21 Oct 2003 14:22:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC18y-00076m-00 for opes-archive@ietf.org; Tue, 21 Oct 2003 14:22:08 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AC18y-00076j-00 for opes-archive@ietf.org; Tue, 21 Oct 2003 14:22:08 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LI9II7034322 for ; Tue, 21 Oct 2003 11:09:18 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LI9INa034321 for ietf-openproxy-bks; Tue, 21 Oct 2003 11:09:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LI9EI7034314 for ; Tue, 21 Oct 2003 11:09:16 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h9LI9GGh047669; Tue, 21 Oct 2003 12:09:16 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9LI9Gfn047668; Tue, 21 Oct 2003 12:09:16 -0600 (MDT) (envelope-from rousskov) Date: Tue, 21 Oct 2003 12:09:16 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: RE: feedback on draft-ietf-opes-end-comm-04 In-Reply-To: <87609AFB433BD5118D5E0002A52CD754074E6DFF@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD754074E6DFF@zcard0k6.ca.nortel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 21 Oct 2003, Abbie Barbir wrote: > > > OPES processor SHOULD be able to trace it's own invocation and > > > service(s) execution since it understands the application > > > protocol. > > > > Is it a requirement or a consequence of the "since it understands" > > part? There is another "SHOULD ... since" requirement elsewhere > > in the draft. > > > > The since explains why the SHOULD was there in the first place. If still > unhappy can u reword please. (1) Remove the informative "since ... " part (2) Make sure the remaining requirement does not duplicate other existing requirement > > > An OPES System MUST include information about its bypass policy. > > > > > An OPES System MUST identify the party responsible for setting and > > > enforcing the bypass policy. > > > > > An OPES System MUST include information that identifies, to a > > > technical contact, the OPES processors involved in processing the > > > bypass request. > > > > MUST include/identify where? In a trace? Then these should be > > moved to tracing requirements. > > > > Should be included in the OPES provider policy. Including the last one? How do you include OPES processor IDs/info into a provider policy? Also, how is the "provider policy" made accessible? Is it a URI in a trace message? > > > OPES processor SHOULD be able to bypass it's own invocation > > > > Isn't this a self-contradiction? Like lifting oneself by > > one's own hair? If the processor is looking at the bypass > > instruction, it is already invoked. > > > > > This means bypass services that it is responsible for. Please reward "own" to "services" then. Alex. From owner-ietf-openproxy@mail.imc.org Tue Oct 21 14:32: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 OAA29513 for ; Tue, 21 Oct 2003 14:32:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC1JQ-0007GD-00 for opes-archive@ietf.org; Tue, 21 Oct 2003 14:32:56 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AC1JP-0007GA-00 for opes-archive@ietf.org; Tue, 21 Oct 2003 14:32:55 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LIGwI7034548 for ; Tue, 21 Oct 2003 11:16:58 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LIGw8n034547 for ietf-openproxy-bks; Tue, 21 Oct 2003 11:16:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LIGuI7034542 for ; Tue, 21 Oct 2003 11:16:56 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h9LIGwGh047896; Tue, 21 Oct 2003 12:16:58 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9LIGwdE047895; Tue, 21 Oct 2003 12:16:58 -0600 (MDT) (envelope-from rousskov) Date: Tue, 21 Oct 2003 12:16:58 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: RE: feedback on draft-ietf-opes-end-comm-04 In-Reply-To: <87609AFB433BD5118D5E0002A52CD754074E6E5C@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD754074E6E5C@zcard0k6.ca.nortel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 21 Oct 2003, Abbie Barbir wrote: > I could make it both a SHOULD. But does this result that tracing in > the system is not a MUST. OPES System MUST still trace itself, right? > > > Alex, if your ploicy trun all processor off, then u r not compliant. > > > > Why? I am not violating the "support" requirement above. > > > > Alex. > > > > If tracing is off for all, then u r not supporting tracing. What does it mean to support tracing, then? The way you wrote it, I interpret "support" as "having a feature in the code" (that can be configured to be enabled or disabled). Does it mean something else? This argument is exactly why I think the requirement in question is bogus (not well defined, unclear, or imprecise) and should be deleted. Alex. From owner-ietf-openproxy@mail.imc.org Wed Oct 22 13:34: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 NAA18845 for ; Wed, 22 Oct 2003 13:34:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACMsl-0000IR-00 for opes-archive@ietf.org; Wed, 22 Oct 2003 13:34:51 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ACMsj-0000IN-00 for opes-archive@ietf.org; Wed, 22 Oct 2003 13:34:49 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MHEkI7051795 for ; Wed, 22 Oct 2003 10:14:46 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MHEkmp051794 for ietf-openproxy-bks; Wed, 22 Oct 2003 10:14:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MHEjI7051769 for ; Wed, 22 Oct 2003 10:14:45 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9MHE7C19114; Wed, 22 Oct 2003 13:14:07 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Oct 2003 13:14:08 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD75407544F81@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: "'internet-drafts@ietf.org'" Cc: "'ietf-openproxy@imc.org'" , "Abbie Barbir" , Markus Hofmann , Alex Rousskov Subject: Request to publish :draft-ietf-opes-end-comm-05 Date: Wed, 22 Oct 2003 13:14:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C398BF.E2B003EC" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C398BF.E2B003EC Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C398BF.E2B003EC" ------_=_NextPart_001_01C398BF.E2B003EC Content-Type: text/plain Please publish the following draft-ietf-opes-end-comm-05 as a WG Draft. Thanks Abbie ------_=_NextPart_001_01C398BF.E2B003EC Content-Type: text/html Request to publish :draft-ietf-opes-end-comm-05

Please publish the following

draft-ietf-opes-end-comm-05

as a WG Draft.

Thanks
Abbie

  ------_=_NextPart_001_01C398BF.E2B003EC-- ------_=_NextPart_000_01C398BF.E2B003EC Content-Type: text/plain; name="draft-ietf-opes-end-comm-05.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-opes-end-comm-05.txt" Content-Transfer-Encoding: quoted-printable Network Working Group A. = Barbir Internet-Draft Nortel = Networks Expires: March 31, 2004 Oct. = 2003 OPES entities and end points communication draft-ietf-opes-end-comm-05 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that = other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six = months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 31, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This memo documents tracing and non-blocking (bypass) requirements for Open Pluggable Edge Services (OPES). Barbir Expires March 31, 2004 [Page = 1] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . = 3 2. OPES System . . . . . . . . . . . . . . . . . . . . . . . . . = 4 3. Requirements for OPES Tracing . . . . . . . . . . . . . . . . = 5 3.1 What is traceable in an OPES Flow? . . . . . . . . . . . . . . = 5 3.2 Requirements for OPES System . . . . . . . . . . . . . . . . . = 6 3.3 Requirements for OPES processors . . . . . . . . . . . . . . . = 7 3.4 Requirements for callout servers . . . . . . . . . . . . . . . = 7 4. Requirements for OPES System Bypass (Non-blocking feature) . . = 8 4.1 What can be bypassed in an OPES Flow? . . . . . . . . . . . . = 8 4.2 Bypass requirements for OPES System . . . . . . . . . . . . . = 9 4.3 Bypass requirements for OPES processors . . . . . . . . . . . = 10 4.4 Bypass requirements for callout servers . . . . . . . . . . . = 10 5. Protocol Binding . . . . . . . . . . . . . . . . . . . . . . . = 11 6. Compliance Considerations . . . . . . . . . . . . . . . . . . = 12 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . = 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . = 14 8.1 Tracing security considerations . . . . . . . . . . . . . . . = 14 8.2 Bypass security considerations . . . . . . . . . . . . . . . . = 15 Normative References . . . . . . . . . . . . . . . . . . . . . = 17 Informative References . . . . . . . . . . . . . . . . . . . . = 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . = 18 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . = 19 Intellectual Property and Copyright Statements . . . . . . . . = 20 Barbir Expires March 31, 2004 [Page = 2] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 1. Introduction The Open Pluggable Edge Services (OPES) architecture [8] enables cooperative application services (OPES services) between a data provider, a data consumer, and zero or more OPES processors. The application services under consideration analyze and possibly transform application-level messages exchanged between the data provider and the data consumer. This work specifies the requirements for providing tracing functionality for the OPES architecture [8]. Tracing functionality enables a data provider or a data consumer application to detect inappropriate actions that are performed by OPES entities. The work also develops requirements that can be used to fulfill IAB Notification and Bypass (Non-Blocking) requirements [2]. 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. In this document the key words that are used to signify requirements are based on RFC 2119 [3]. Barbir Expires March 31, 2004 [Page = 3] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 2. OPES System This sections provides a definition of OPES System. This is needed = in order to define what is traceable in an OPES Flow. 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. The nature of the authorization agreement determines if authority delegation is transitive (meaning an authorized entity is authorized to include other entities). If specific authority agreements allow for re-delegation, an OPES system can be formed by induction. In this case, an OPES system starts with entities directly authorized by a data provider (or a data consumer) application. The OPES system then includes any OPES entity authorized by an entity that is already in the OPES system. The authority delegation is always viewed in the context of a given application message. An OPES System is defined on an application message basis. Having an authority to process a message does not imply being involved in message processing. Thus, some OPES system members may not participate in processing of a message. Similarly, some members may process the same message several times. The above definition implies that there can be no more than two OPES systems [Client-side and server-side OPES systems can process the same message at the same time] processing the same message at a = given time. This is based on the assumption that there is a single data provider and a single data consumer as far as a given application message is concerned. For example, consider a Content Delivery Network (CDN) delivering an image on behalf of a busy web site. OPES processors and services = that the CDN uses to adapt and deliver the message comprise an OPES System. In a more complex example, an OPES System would contain CDN entries as well as 3rd-party OPES entities that CDN engages to perform adaptations (e.g., to adjust image quality). Barbir Expires March 31, 2004 [Page = 4] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 3. Requirements for OPES Tracing 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. A traceable entity can appear multiple times in a trace (every time it acts on a message). In an OPES System tracing is performed on per message basis. Trace format is dependent on the application protocol that is being = adapted by OPES. 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. In an OPES System, the task of providing tracing information, can depend on many factors. Some considerations are: o Providers may be hesitant to reveal information about their internal network infrastructure. o Within a service provider network, OPES processors may be configured to use non-routable, private IP addresses. o A data consumer applications would prefer to have a single point of contact regarding the trace information. 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. OPES providers require some freedom in the way they deliver tracing information to an end point. 3.1 What is traceable in an OPES Flow? This section focuses on identifying traceable entities in an OPES Flow. Tracing information provides a data consumer application (or a data provider 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 Barbir Expires March 31, 2004 [Page = 5] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 be able to see a trace entry, but does not need to be able to interpret it beyond identification of the OPES System. Second, the OPES System administrator is expected to be able to interpret the contents of an OPES trace. The trace can be relayed to the administrator by an end (data consumer or provider) without interpretation, as opaque data (e.g., a TCP packet or an HTTP = message snapshot). The administrator can use the trace information to identify the participating OPES entities. The administrator can use the trace to identify the applied adaptation services along with other message-specific information. 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 and how to format them. Trace records should be easy to extend beyond basic OPES requirements. Trace management algorithms should treat trace records as opaque data to the extent possible. 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. OPES entities have different levels of traceability requirements. Specifically, o An OPES processor MUST add its entry to the trace. o An OPES service MAY add its entry to the trace. 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). In an OPES context, a good tracing approach is similar to a trouble ticket ready for submission to a known address. The address is printed on the ticket. The trace in itself is not necessarily a detailed description of what has happened. It is the responsibility of the operator to resolve the problems. 3.2 Requirements for OPES System The following requirements apply for information as related to an OPES System: o An OPES System MUST trace itself. Barbir Expires March 31, 2004 [Page = 6] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 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. o An OPES System MUST include information pointing to a technical contact. o An OPES System MUST include information that identifies, to the technical contact, the OPES processors involved in processing = the message. o When providing required information, an OPES System MAY use a single URI to identify a resource containing several required items. For example, an OPES System can point to a single web page with a reference to System privacy policy and technical contact information. 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. Furthermore, an example of System identification would be something like = http://www.examplecompany.com/ opes/?client=3Dexample.com. 3.3 Requirements for OPES processors Tracing requirements for OPES processors are: o OPES processor MUST add its unique identification to the trace. Here, uniqueness scope is the OPES System containing the processor. o OPES processor MUST be able to trace it's own invocation and service(s) execution. 3.4 Requirements for callout servers 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. Barbir Expires March 31, 2004 [Page = 7] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 4. Requirements for OPES System Bypass (Non-blocking feature) IAB recommendation (3.3) [2] requires that the OPES architecture = does not prevent a data consumer application from retrieving non-OPES version of content from a data provider application, provided that the non-OPES content exists. IAB recommendation (3.3) suggests that the Non-blocking feature (Bypass) be used to bypass faulty OPES intermediaries (once they have been identified, by some method). In addressing IAB consideration (3.3), one need to specify what constitute non-OPES content. In this work the definition of "non-OPES" content is provider dependent. However, in some cases, = the availability of "non-OPES" content can also be a function of the internal policy of a given organization that has contracted the services of an OPES provider. For example, Company A has as contract with an OPES provider to perform virus checking on all e-mail attachments. An employee X of Company A can issue a non-blocking request for the virus scanning service. However, the request could = be ignored by the OPES provider since it contradicts its agreement with Company A. The above examples illustrates that the availability of non-OPES content can be a function of content providers (or consumers or = both) policy and deployment scenarios [1]. For this reason, this work does not attempt to define what is an OPES content as opposed to non-OPES content. The meaning of OPES versus non-OPES content is assumed to = be determined through various agreements between the OPES provider, = data provider and data consumer application. The agreement will also determine what OPES services can be bypassed and in what order (if applicable). In an OPES System a bypass request is defined as the 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. 4.1 What can be bypassed in an OPES Flow? In this work, the focus is on developing a bypass feature that allow a user to instruct the OPES System to bypass some or all of its services. The collection of OPES services that can be bypassed is a function of the agreement of the OPES provider with either (or both) the content provider or the content consumer applications. 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. An Barbir Expires March 31, 2004 [Page = 8] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 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). In an OPES Flow, a bypass request is processed in a local manner by 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. This may include the act of bypassing itself completely depending on what is specified in the URI. The request is then forwarded to the next OPES processor in the OPES Flow. The next OPES processor would then honor all bypass requests that are relevant to it provided that the non-OPES content is available. The processing chain continues throughout the whole processors that are involved in the OPES Flow. If an OPES processor does not know how to honor a bypass request it forwards the message to the next processor in the OPES Flow. 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). 4.2 Bypass requirements for OPES System In an OPES System bypass requests are generally client centric and = go in the opposite direction of tracing requests. Bypass can be performed out of band or in-band. This work requires that the Bypass feature be performed in-band as an extension to an application specific protocol. Non-OPES entities should be able to safely ignore these extensions. The work does not prevent OPES Systems from developing their own out of band protocols. The following requirements apply for Bypass feature as related to an OPES System (the availability of a non-OPES content is a precondition) : 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). In order to facilitate the debugging (or data consumer user experience) of the bypass feature in an OPES System, it would be beneficial if non-bypassed entities include information related to 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. Barbir Expires March 31, 2004 [Page = 9] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 4.3 Bypass requirements for OPES processors 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 processor that is calling the service(s) to handle the bypass request. 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. Bypass requirements for OPES processors are (the availability of a non-OPES content is a precondition): o OPES processor SHOULD be able to interpret and process a bypass instruction. This requirement applies to all bypass instructions, including those that identify known-to-recipient services. o OPES processors that do not know how to process a bypass request MUST forward the request to the next application hop provided = that the next hop speaks application protocol with OPES bypass = support. o OPES processor SHOULD be able to bypass it's service(s) = execution. Provided that non-OPES content is available, those OPES processors that know how to process and interpret a bypass instruction have the following requirements: o The recipient of a bypass instruction with a URI that does not identify any known-to-recipient OPES entity MUST treat that URI = as a wildcard identifier (meaning bypass all applicable local services). 4.4 Bypass requirements for callout servers In an OPES system, it is the task of an OPES processor to process bypass requests. However, in some cases, callout servers may be involved in processing Bypass requests. This should be done under = the control of the OPES System provider. Barbir Expires March 31, 2004 [Page = 10] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 5. Protocol Binding The task of encoding tracing and bypass features is application protocol specific. Separate documents will address HTTP and other protocols. Barbir Expires March 31, 2004 [Page = 11] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 6. Compliance Considerations This work specifies high level requirements for tracing and bypass. Protocol binding specifications MUST consider and follow all MUSTs = in this draft. Protocol binding specifications MUST be compliant to = this draft. As such any implementation compliant to the binding specification is also compliant to this draft. Barbir Expires March 31, 2004 [Page = 12] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 7. IANA considerations This specification contains no IANA considerations. Application bindings MAY contain application-specific IANA considerations. Barbir Expires March 31, 2004 [Page = 13] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 8. Security Considerations The security considerations for OPES are documented in [7]. This document is a requirement document for tracing and Bypass feature. The requirements that are stated in this document can be used to extend an application level protocol to support these features. As such, the work has security precautions. 8.1 Tracing security considerations The tracing facility for OPES architecture is implemented as a protocol extension. Inadequate implementations of the tracing facility may defeat safeguards built into the OPES architecture. The tracing facility by itself can become a target of malicious attacks or used to lunch attacks on an OPES System. Threats caused by or against the tracing facility can be viewed as threats at the application level in an OPES Flow. In this case, the threats can affect the data consumer and the data provider application. Since tracing information is a protocol extension, these traces can be injected in the data flow by non-OPES entities. In this case, there are risks that non-OPES entities can be compromised in a fashion that threat the overall integrity and effectiveness of an OPES System. For example, a non-OPES proxy can add fake tracing information into a trace. This can be done in the form of wrong, or unwanted, or non existent services. A non-OPES entity can inject large size traces that may cause buffer overflow in a data consumer application. The same threats can arise from compromised OPES entities. An attacker can control an OPES entity and inject wrong, = or very large trace information that can overwhelm an end or the next OPES entity in an OPES flow. Similar threats can result from bad implementations of the tracing facility in trusted OPES entities. Compromised tracing information can be used to launch attacks on an OPES System that give the impression that unwanted content transformation was performed on the data. This can be achieved by inserting wrong entity (such OPES processor) identifiers. A compromised trace can affect the overall message integrity = structure. This can affect entities that use message header information to perform services such as accounting, load balancing, or reference-based services. Compromised trace information can be used to launch DoS attacks that can overwhelm a data consumer application or an OPES entity in an OPES Flow. Inserting wrong tracing information can complicates the debugging tasks performed by system administrator during trouble Barbir Expires March 31, 2004 [Page = 14] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 shooting of OPES System behavior. As a precaution, OPES entities ought to be capable of verifying that the inserted traces are performed by legal OPES entities. This can = be done as part of the authorization and authentication face. Policy = can be used to indicate what trace information can be expected from a peer entity. Other application level related security concerns can = be found in [7]. 8.2 Bypass security considerations The bypass facility for OPES architecture is implemented as a protocol extension. Inadequate implementations of the bypass = facility may defeat safeguards built into the OPES architecture. The bypass facility by itself can become a target of malicious attacks or used to lunch attacks on an OPES System. Threats caused by or against the bypass facility can be viewed as threats at the application level in an OPES Flow. In this case, the threats can affect the data consumer and the data provider application. 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. 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 Barbir Expires March 31, 2004 [Page = 15] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 System. It may also affect the quality of content that is delivered to the data consumer applications. Similar threats can arise from = bad implementations of the bypass facility. Inconsistent or selective bypass is also a threat. Here, one end can try to bypass a subset of OPES entities so that the resulting = content is malformed and crashes or compromises entities that process that content (and expect that content to be complete and valid). Such exceptions are often not tested because implementers do not expect a vital service to disappear from the processing loop. Other threats can arise from configuring access control policies for OPES entities. It is possible that systems implementing access controls via OPES entities may be incorrectly configured to honor bypass and, hence, give unauthorized access to intruders. Tap bypass can also be a threat. This is because systems = implementing wiretaps via OPES entities may be incorrectly configured to honor bypass and, hence, ignore (leave undetected) traffic with bypass instructions that should have been tapped or logged. It is also possible for one end to bypass services such as virus scanning at = the receiving end. This threat can be used by hackers to inject viruses throughout the network. Other application level related security concerns can be found in [7]. Barbir Expires March 31, 2004 [Page = 16] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 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. Barbir Expires March 31, 2004 [Page = 17] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 Informative References [2] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [4] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [5] A. Barbir et al., "Policy, Authorization and Enforcement Requirements of OPES", Internet-Draft http://www.ietf.org/ internet-drafts/draft-ietf-opes-authorization-02.txt, February 2003. [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. [7] A. Barbir et al., "Security Threats and Risks for Open = Pluggable Edge Services", Internet-Draft http://www.ietf.org/ internet-drafts/draft-ietf-opes-threats-02.txt, February 2003. [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. [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. Author's Address Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean, Ontario K2H 8E9 Canada Phone: +1 613 763 5229 EMail: abbieb@nortelnetworks.com Barbir Expires March 31, 2004 [Page = 18] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 Appendix A. Acknowledgements Several people has contributed to this work. Many thanks to: Alex Rousskov, Hilarie Orman, Oscar Batuner, Markus Huffman, Martin Stecher, Marshall Rose and Reinaldo Penno. Barbir Expires March 31, 2004 [Page = 19] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances = of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification = can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph = are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Barbir Expires March 31, 2004 [Page = 20] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Barbir Expires March 31, 2004 [Page = 21] =0C ------_=_NextPart_000_01C398BF.E2B003EC-- From owner-ietf-openproxy@mail.imc.org Wed Oct 22 13:42:38 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19283 for ; Wed, 22 Oct 2003 13:42:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACN0Q-0000PS-00 for opes-archive@ietf.org; Wed, 22 Oct 2003 13:42:46 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ACN0O-0000PP-00 for opes-archive@ietf.org; Wed, 22 Oct 2003 13:42:44 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MHUMI7052348 for ; Wed, 22 Oct 2003 10:30:22 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MHUMX3052347 for ietf-openproxy-bks; Wed, 22 Oct 2003 10:30:22 -0700 (PDT) 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 h9MHUKI7052340 for ; Wed, 22 Oct 2003 10:30:21 -0700 (PDT) (envelope-from markus@mhof.com) Received: from mhof.com (unknown[135.104.20.75]) by comcast.net (sccrmhc11) with SMTP id <2003102217301501100qrt2te> (Authid: mhofmann); Wed, 22 Oct 2003 17:30:15 +0000 Message-ID: <3F96BEA8.4090400@mhof.com> Date: Wed, 22 Oct 2003 13:30:16 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: WG Last Call: draft-ietf-opes-end-comm-05 Content-Type: multipart/mixed; boundary="------------060408060505060101070404" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. --------------060408060505060101070404 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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. Thanks, Markus --------------060408060505060101070404 Content-Type: message/rfc822; name="Request to publish :draft-ietf-opes-end-comm-05" Content-Disposition: inline; filename="Request to publish :draft-ietf-opes-end-comm-05" Return-Path: Received: from frontend1.messagingengine.com (frontend1.internal [10.202.2.150]) by server2.fastmail.fm (Cyrus v2.1.9) with LMTP; Wed, 22 Oct 2003 13:14:55 -0400 X-Sieve: CMU Sieve 2.2 X-Spam-known-sender: yes X-Spam-score: 0.0 X-Spam-hits: BAYES_00, HTML_MESSAGE, MIME_MISSING_BOUNDARY X-Virus-checked: Yes X-Resolved-to: hofmann@fastmail.fm X-Mail-from: abbieb@nortelnetworks.com Received: from mail.messagingengine.com (localhost [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 6F738334E46 for ; Wed, 22 Oct 2003 13:14:47 -0400 (EDT) X-Attached: draft-ietf-opes-end-comm-05.txt Received: from 10.202.2.150 ([10.202.2.150] helo=mail.messagingengine.com) by messagingengine.com with SMTP; Wed, 22 Oct 2003 13:14:47 -0400 X-Mail-from: abbieb@nortelnetworks.com X-Delivered-to: Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by mail.messagingengine.com (Postfix) with ESMTP id BB446333B39 for ; Wed, 22 Oct 2003 13:14:46 -0400 (EDT) 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 h9MHE7C19114; Wed, 22 Oct 2003 13:14:07 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Oct 2003 13:14:08 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD75407544F81@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: "'internet-drafts@ietf.org'" Cc: "'ietf-openproxy@imc.org'" , "Abbie Barbir" , Markus Hofmann , Alex Rousskov Subject: Request to publish :draft-ietf-opes-end-comm-05 Date: Wed, 22 Oct 2003 13:14:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C398BF.E2B003EC" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C398BF.E2B003EC Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C398BF.E2B003EC" ------_=_NextPart_001_01C398BF.E2B003EC Content-Type: text/plain Please publish the following draft-ietf-opes-end-comm-05 as a WG Draft. Thanks Abbie ------_=_NextPart_001_01C398BF.E2B003EC Content-Type: text/html Request to publish :draft-ietf-opes-end-comm-05

Please publish the following

draft-ietf-opes-end-comm-05

as a WG Draft.

Thanks
Abbie

  ------_=_NextPart_001_01C398BF.E2B003EC-- ------_=_NextPart_000_01C398BF.E2B003EC Content-Type: text/plain; name="draft-ietf-opes-end-comm-05.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-opes-end-comm-05.txt" Content-Transfer-Encoding: quoted-printable Network Working Group A. = Barbir Internet-Draft Nortel = Networks Expires: March 31, 2004 Oct. = 2003 OPES entities and end points communication draft-ietf-opes-end-comm-05 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that = other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six = months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 31, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This memo documents tracing and non-blocking (bypass) requirements for Open Pluggable Edge Services (OPES). Barbir Expires March 31, 2004 [Page = 1] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . = 3 2. OPES System . . . . . . . . . . . . . . . . . . . . . . . . . = 4 3. Requirements for OPES Tracing . . . . . . . . . . . . . . . . = 5 3.1 What is traceable in an OPES Flow? . . . . . . . . . . . . . . = 5 3.2 Requirements for OPES System . . . . . . . . . . . . . . . . . = 6 3.3 Requirements for OPES processors . . . . . . . . . . . . . . . = 7 3.4 Requirements for callout servers . . . . . . . . . . . . . . . = 7 4. Requirements for OPES System Bypass (Non-blocking feature) . . = 8 4.1 What can be bypassed in an OPES Flow? . . . . . . . . . . . . = 8 4.2 Bypass requirements for OPES System . . . . . . . . . . . . . = 9 4.3 Bypass requirements for OPES processors . . . . . . . . . . . = 10 4.4 Bypass requirements for callout servers . . . . . . . . . . . = 10 5. Protocol Binding . . . . . . . . . . . . . . . . . . . . . . . = 11 6. Compliance Considerations . . . . . . . . . . . . . . . . . . = 12 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . = 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . = 14 8.1 Tracing security considerations . . . . . . . . . . . . . . . = 14 8.2 Bypass security considerations . . . . . . . . . . . . . . . . = 15 Normative References . . . . . . . . . . . . . . . . . . . . . = 17 Informative References . . . . . . . . . . . . . . . . . . . . = 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . = 18 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . = 19 Intellectual Property and Copyright Statements . . . . . . . . = 20 Barbir Expires March 31, 2004 [Page = 2] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 1. Introduction The Open Pluggable Edge Services (OPES) architecture [8] enables cooperative application services (OPES services) between a data provider, a data consumer, and zero or more OPES processors. The application services under consideration analyze and possibly transform application-level messages exchanged between the data provider and the data consumer. This work specifies the requirements for providing tracing functionality for the OPES architecture [8]. Tracing functionality enables a data provider or a data consumer application to detect inappropriate actions that are performed by OPES entities. The work also develops requirements that can be used to fulfill IAB Notification and Bypass (Non-Blocking) requirements [2]. 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. In this document the key words that are used to signify requirements are based on RFC 2119 [3]. Barbir Expires March 31, 2004 [Page = 3] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 2. OPES System This sections provides a definition of OPES System. This is needed = in order to define what is traceable in an OPES Flow. 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. The nature of the authorization agreement determines if authority delegation is transitive (meaning an authorized entity is authorized to include other entities). If specific authority agreements allow for re-delegation, an OPES system can be formed by induction. In this case, an OPES system starts with entities directly authorized by a data provider (or a data consumer) application. The OPES system then includes any OPES entity authorized by an entity that is already in the OPES system. The authority delegation is always viewed in the context of a given application message. An OPES System is defined on an application message basis. Having an authority to process a message does not imply being involved in message processing. Thus, some OPES system members may not participate in processing of a message. Similarly, some members may process the same message several times. The above definition implies that there can be no more than two OPES systems [Client-side and server-side OPES systems can process the same message at the same time] processing the same message at a = given time. This is based on the assumption that there is a single data provider and a single data consumer as far as a given application message is concerned. For example, consider a Content Delivery Network (CDN) delivering an image on behalf of a busy web site. OPES processors and services = that the CDN uses to adapt and deliver the message comprise an OPES System. In a more complex example, an OPES System would contain CDN entries as well as 3rd-party OPES entities that CDN engages to perform adaptations (e.g., to adjust image quality). Barbir Expires March 31, 2004 [Page = 4] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 3. Requirements for OPES Tracing 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. A traceable entity can appear multiple times in a trace (every time it acts on a message). In an OPES System tracing is performed on per message basis. Trace format is dependent on the application protocol that is being = adapted by OPES. 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. In an OPES System, the task of providing tracing information, can depend on many factors. Some considerations are: o Providers may be hesitant to reveal information about their internal network infrastructure. o Within a service provider network, OPES processors may be configured to use non-routable, private IP addresses. o A data consumer applications would prefer to have a single point of contact regarding the trace information. 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. OPES providers require some freedom in the way they deliver tracing information to an end point. 3.1 What is traceable in an OPES Flow? This section focuses on identifying traceable entities in an OPES Flow. Tracing information provides a data consumer application (or a data provider 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 Barbir Expires March 31, 2004 [Page = 5] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 be able to see a trace entry, but does not need to be able to interpret it beyond identification of the OPES System. Second, the OPES System administrator is expected to be able to interpret the contents of an OPES trace. The trace can be relayed to the administrator by an end (data consumer or provider) without interpretation, as opaque data (e.g., a TCP packet or an HTTP = message snapshot). The administrator can use the trace information to identify the participating OPES entities. The administrator can use the trace to identify the applied adaptation services along with other message-specific information. 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 and how to format them. Trace records should be easy to extend beyond basic OPES requirements. Trace management algorithms should treat trace records as opaque data to the extent possible. 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. OPES entities have different levels of traceability requirements. Specifically, o An OPES processor MUST add its entry to the trace. o An OPES service MAY add its entry to the trace. 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). In an OPES context, a good tracing approach is similar to a trouble ticket ready for submission to a known address. The address is printed on the ticket. The trace in itself is not necessarily a detailed description of what has happened. It is the responsibility of the operator to resolve the problems. 3.2 Requirements for OPES System The following requirements apply for information as related to an OPES System: o An OPES System MUST trace itself. Barbir Expires March 31, 2004 [Page = 6] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 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. o An OPES System MUST include information pointing to a technical contact. o An OPES System MUST include information that identifies, to the technical contact, the OPES processors involved in processing = the message. o When providing required information, an OPES System MAY use a single URI to identify a resource containing several required items. For example, an OPES System can point to a single web page with a reference to System privacy policy and technical contact information. 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. Furthermore, an example of System identification would be something like = http://www.examplecompany.com/ opes/?client=3Dexample.com. 3.3 Requirements for OPES processors Tracing requirements for OPES processors are: o OPES processor MUST add its unique identification to the trace. Here, uniqueness scope is the OPES System containing the processor. o OPES processor MUST be able to trace it's own invocation and service(s) execution. 3.4 Requirements for callout servers 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. Barbir Expires March 31, 2004 [Page = 7] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 4. Requirements for OPES System Bypass (Non-blocking feature) IAB recommendation (3.3) [2] requires that the OPES architecture = does not prevent a data consumer application from retrieving non-OPES version of content from a data provider application, provided that the non-OPES content exists. IAB recommendation (3.3) suggests that the Non-blocking feature (Bypass) be used to bypass faulty OPES intermediaries (once they have been identified, by some method). In addressing IAB consideration (3.3), one need to specify what constitute non-OPES content. In this work the definition of "non-OPES" content is provider dependent. However, in some cases, = the availability of "non-OPES" content can also be a function of the internal policy of a given organization that has contracted the services of an OPES provider. For example, Company A has as contract with an OPES provider to perform virus checking on all e-mail attachments. An employee X of Company A can issue a non-blocking request for the virus scanning service. However, the request could = be ignored by the OPES provider since it contradicts its agreement with Company A. The above examples illustrates that the availability of non-OPES content can be a function of content providers (or consumers or = both) policy and deployment scenarios [1]. For this reason, this work does not attempt to define what is an OPES content as opposed to non-OPES content. The meaning of OPES versus non-OPES content is assumed to = be determined through various agreements between the OPES provider, = data provider and data consumer application. The agreement will also determine what OPES services can be bypassed and in what order (if applicable). In an OPES System a bypass request is defined as the 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. 4.1 What can be bypassed in an OPES Flow? In this work, the focus is on developing a bypass feature that allow a user to instruct the OPES System to bypass some or all of its services. The collection of OPES services that can be bypassed is a function of the agreement of the OPES provider with either (or both) the content provider or the content consumer applications. 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. An Barbir Expires March 31, 2004 [Page = 8] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 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). In an OPES Flow, a bypass request is processed in a local manner by 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. This may include the act of bypassing itself completely depending on what is specified in the URI. The request is then forwarded to the next OPES processor in the OPES Flow. The next OPES processor would then honor all bypass requests that are relevant to it provided that the non-OPES content is available. The processing chain continues throughout the whole processors that are involved in the OPES Flow. If an OPES processor does not know how to honor a bypass request it forwards the message to the next processor in the OPES Flow. 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). 4.2 Bypass requirements for OPES System In an OPES System bypass requests are generally client centric and = go in the opposite direction of tracing requests. Bypass can be performed out of band or in-band. This work requires that the Bypass feature be performed in-band as an extension to an application specific protocol. Non-OPES entities should be able to safely ignore these extensions. The work does not prevent OPES Systems from developing their own out of band protocols. The following requirements apply for Bypass feature as related to an OPES System (the availability of a non-OPES content is a precondition) : 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). In order to facilitate the debugging (or data consumer user experience) of the bypass feature in an OPES System, it would be beneficial if non-bypassed entities include information related to 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. Barbir Expires March 31, 2004 [Page = 9] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 4.3 Bypass requirements for OPES processors 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 processor that is calling the service(s) to handle the bypass request. 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. Bypass requirements for OPES processors are (the availability of a non-OPES content is a precondition): o OPES processor SHOULD be able to interpret and process a bypass instruction. This requirement applies to all bypass instructions, including those that identify known-to-recipient services. o OPES processors that do not know how to process a bypass request MUST forward the request to the next application hop provided = that the next hop speaks application protocol with OPES bypass = support. o OPES processor SHOULD be able to bypass it's service(s) = execution. Provided that non-OPES content is available, those OPES processors that know how to process and interpret a bypass instruction have the following requirements: o The recipient of a bypass instruction with a URI that does not identify any known-to-recipient OPES entity MUST treat that URI = as a wildcard identifier (meaning bypass all applicable local services). 4.4 Bypass requirements for callout servers In an OPES system, it is the task of an OPES processor to process bypass requests. However, in some cases, callout servers may be involved in processing Bypass requests. This should be done under = the control of the OPES System provider. Barbir Expires March 31, 2004 [Page = 10] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 5. Protocol Binding The task of encoding tracing and bypass features is application protocol specific. Separate documents will address HTTP and other protocols. Barbir Expires March 31, 2004 [Page = 11] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 6. Compliance Considerations This work specifies high level requirements for tracing and bypass. Protocol binding specifications MUST consider and follow all MUSTs = in this draft. Protocol binding specifications MUST be compliant to = this draft. As such any implementation compliant to the binding specification is also compliant to this draft. Barbir Expires March 31, 2004 [Page = 12] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 7. IANA considerations This specification contains no IANA considerations. Application bindings MAY contain application-specific IANA considerations. Barbir Expires March 31, 2004 [Page = 13] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 8. Security Considerations The security considerations for OPES are documented in [7]. This document is a requirement document for tracing and Bypass feature. The requirements that are stated in this document can be used to extend an application level protocol to support these features. As such, the work has security precautions. 8.1 Tracing security considerations The tracing facility for OPES architecture is implemented as a protocol extension. Inadequate implementations of the tracing facility may defeat safeguards built into the OPES architecture. The tracing facility by itself can become a target of malicious attacks or used to lunch attacks on an OPES System. Threats caused by or against the tracing facility can be viewed as threats at the application level in an OPES Flow. In this case, the threats can affect the data consumer and the data provider application. Since tracing information is a protocol extension, these traces can be injected in the data flow by non-OPES entities. In this case, there are risks that non-OPES entities can be compromised in a fashion that threat the overall integrity and effectiveness of an OPES System. For example, a non-OPES proxy can add fake tracing information into a trace. This can be done in the form of wrong, or unwanted, or non existent services. A non-OPES entity can inject large size traces that may cause buffer overflow in a data consumer application. The same threats can arise from compromised OPES entities. An attacker can control an OPES entity and inject wrong, = or very large trace information that can overwhelm an end or the next OPES entity in an OPES flow. Similar threats can result from bad implementations of the tracing facility in trusted OPES entities. Compromised tracing information can be used to launch attacks on an OPES System that give the impression that unwanted content transformation was performed on the data. This can be achieved by inserting wrong entity (such OPES processor) identifiers. A compromised trace can affect the overall message integrity = structure. This can affect entities that use message header information to perform services such as accounting, load balancing, or reference-based services. Compromised trace information can be used to launch DoS attacks that can overwhelm a data consumer application or an OPES entity in an OPES Flow. Inserting wrong tracing information can complicates the debugging tasks performed by system administrator during trouble Barbir Expires March 31, 2004 [Page = 14] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 shooting of OPES System behavior. As a precaution, OPES entities ought to be capable of verifying that the inserted traces are performed by legal OPES entities. This can = be done as part of the authorization and authentication face. Policy = can be used to indicate what trace information can be expected from a peer entity. Other application level related security concerns can = be found in [7]. 8.2 Bypass security considerations The bypass facility for OPES architecture is implemented as a protocol extension. Inadequate implementations of the bypass = facility may defeat safeguards built into the OPES architecture. The bypass facility by itself can become a target of malicious attacks or used to lunch attacks on an OPES System. Threats caused by or against the bypass facility can be viewed as threats at the application level in an OPES Flow. In this case, the threats can affect the data consumer and the data provider application. 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. 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 Barbir Expires March 31, 2004 [Page = 15] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 System. It may also affect the quality of content that is delivered to the data consumer applications. Similar threats can arise from = bad implementations of the bypass facility. Inconsistent or selective bypass is also a threat. Here, one end can try to bypass a subset of OPES entities so that the resulting = content is malformed and crashes or compromises entities that process that content (and expect that content to be complete and valid). Such exceptions are often not tested because implementers do not expect a vital service to disappear from the processing loop. Other threats can arise from configuring access control policies for OPES entities. It is possible that systems implementing access controls via OPES entities may be incorrectly configured to honor bypass and, hence, give unauthorized access to intruders. Tap bypass can also be a threat. This is because systems = implementing wiretaps via OPES entities may be incorrectly configured to honor bypass and, hence, ignore (leave undetected) traffic with bypass instructions that should have been tapped or logged. It is also possible for one end to bypass services such as virus scanning at = the receiving end. This threat can be used by hackers to inject viruses throughout the network. Other application level related security concerns can be found in [7]. Barbir Expires March 31, 2004 [Page = 16] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 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. Barbir Expires March 31, 2004 [Page = 17] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 Informative References [2] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [4] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [5] A. Barbir et al., "Policy, Authorization and Enforcement Requirements of OPES", Internet-Draft http://www.ietf.org/ internet-drafts/draft-ietf-opes-authorization-02.txt, February 2003. [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. [7] A. Barbir et al., "Security Threats and Risks for Open = Pluggable Edge Services", Internet-Draft http://www.ietf.org/ internet-drafts/draft-ietf-opes-threats-02.txt, February 2003. [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. [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. Author's Address Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean, Ontario K2H 8E9 Canada Phone: +1 613 763 5229 EMail: abbieb@nortelnetworks.com Barbir Expires March 31, 2004 [Page = 18] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 Appendix A. Acknowledgements Several people has contributed to this work. Many thanks to: Alex Rousskov, Hilarie Orman, Oscar Batuner, Markus Huffman, Martin Stecher, Marshall Rose and Reinaldo Penno. Barbir Expires March 31, 2004 [Page = 19] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances = of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification = can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph = are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Barbir Expires March 31, 2004 [Page = 20] =0C Internet-Draft OPES entities and end points communication Oct. = 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Barbir Expires March 31, 2004 [Page = 21] =0C ------_=_NextPart_000_01C398BF.E2B003EC-- --------------060408060505060101070404-- From owner-ietf-openproxy@mail.imc.org Thu Oct 23 01:36: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 BAA20290 for ; Thu, 23 Oct 2003 01:36:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACY9Q-0001TJ-00 for opes-archive@ietf.org; Thu, 23 Oct 2003 01:36:48 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ACY9Q-0001TG-00 for opes-archive@ietf.org; Thu, 23 Oct 2003 01:36:48 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9N5QDI7085449 for ; Wed, 22 Oct 2003 22:26:13 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9N5QDSb085447 for ietf-openproxy-bks; Wed, 22 Oct 2003 22:26:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9N5QBI7085439 for ; Wed, 22 Oct 2003 22:26:11 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h9N5QEGh004762 for ; Wed, 22 Oct 2003 23:26:14 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9N5QEPD004761; Wed, 22 Oct 2003 23:26:14 -0600 (MDT) (envelope-from rousskov) Date: Wed, 22 Oct 2003 23:26:14 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: HTTP/OCP updates 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: Martin and I have been applying a lot of polishing touches to the HTTP Adaptation draft. The current version, along with the change log and a bunch of still-unresolved issues (marked with XXXs) is available at http://www.measurement-factory.com/tmp/opes/ We hope to have most issues resolved by October 26 GMT, the IETF submission cut-off date. Please comment and contribute. Your input on the big-scale issues such as the design of what-parts-to-send-or-skip and how-to-know-what-encodings-remain interfaces would be especially appreciated. Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Thu Oct 23 11:19:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28722 for ; Thu, 23 Oct 2003 11:19:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AChFt-0002Fb-00 for opes-archive@ietf.org; Thu, 23 Oct 2003 11:20:05 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AChFt-0002FY-00 for opes-archive@ietf.org; Thu, 23 Oct 2003 11:20:05 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NF4uI7066607 for ; Thu, 23 Oct 2003 08:04:56 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9NF4umm066606 for ietf-openproxy-bks; Thu, 23 Oct 2003 08:04:56 -0700 (PDT) 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 h9NF4sI7066601 for ; Thu, 23 Oct 2003 08:04:55 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id VN5PSDVWoutgoing id W2XUQ5L3; 23 Oct 2003 19:11:59 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: what-parts-to-send-or-skip Date: Thu, 23 Oct 2003 17:04:39 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D0E6624@mail.webwasher.com> Thread-Topic: what-parts-to-send-or-skip Thread-Index: AcOZdvs0X+QSGyHyRWGQXMx87LzLiA== From: "Martin Stecher" To: "OPES WG (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9NF4uI7066602 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi, Alex is right, the current message part handling is a mess. I do not understand why I could forget about request satisfaction mode (short circuits). I tried several ways to list the possibilities of message part sending, skipping, responding and found no easy way :-( First here are some thoughts about short-circuits in the request-profile. I think handling this one is not so complicated and can be added to the existing draft: Before the callout server sends back any application message part, it MUST decide whether it wants to adapt the request or to short-curcuit. It will either send back request-header, request-body, request-trailer parts or response-header, response-body, response-trailer parts. Some parts could be optional due to conditions defined below but it MUST NOT mix parts of these two lists; on violation client MUST terminate transaction. Then here some thoughts on parts in HTTP messages: A request header is always in HTTP messages. There are HTTP servers that do not send response headers. OPES processor MUST either create a dummy HTTP header part, or not use OCP/HTTP. Trailers are often not in messages. There is no difference between an empty trailer and a non-existing trailer. Bodies can or cannot exist. Empty but existing bodies are technically possible. Can an empty body be deleted without changing the meaning of the message? Then the best way to describe what needs to be done I found for me is a pseudo programming language style. I do not take the trailer parts in account, it's long enough without ;-) OCP_Client_Send_Routine { if ( NOT skip(request-header)) send (request-header) if (inMessage (request-body) AND NOT skip(request-body)) send (request-body) } OCP_Client_Receive_Routine { lastMessagePart = 0 while (read (newMessagePart)) { if (newMessagePart == request-header) { if (lastMessagePart != 0) goto terminate_transaction; buildHTTPMessage (newMessagePart); } else if (newMessagePart == request-body) { if (skip(request-header)) { // client has skipped part in send if (lastMessagePart != 0) goto terminate_transaction; buildHTTPMessage (original_request-header); } else { if (lastMessagePart != request-header) goto terminate_transaction; } buildHTTPMessage (newMessagePart); } else if (newMessagePart == response-header) { if (lastMessagePart != 0) goto terminate_transaction; buildHTTPMessage (newMessagePart); } else if (newMessagePart == response-body) { if (lastMessagePart != response-header) goto terminate_transaction; buildHTTPMessage (newMessagePart); } lastMessagePart = newMessagePart; } } OCP_Server_Receive_Routine { lastMessagePart = 0 while (read (newMessagePart)) { if (newMessagePart == request-header) { if (lastMessagePart != 0) goto terminate_transaction; filterHTTPMessage (newMessagePart); } else if (newMessagePart == request-body) { if (lastMessagePart != request-header) { if (lastMessagePart != 0) goto terminate_transaction; if (skip_requested(request-header)) goto terminate_transaction; } filterHTTPMessage (newMessagePart); } lastMessagePart = newMessagePart; } } OCP_Server_Send_Routine { if (short_circuit) { // do request satisfaction send (response-header) if (message_has_body()) send (response-body) } else { if (have_received (request-header)) { send (request-header) } else { if (have_own (request-header) send (request-header) } if (have_received (request-body)) { if ( NOT want_to_delete (request-body)) send (request-body) } else { if (have_own (request-body) send (request-body) } } } This is not trivial and describing this in a good way is not easy. Especially the problem that an OCP transaction that does not contain request-body parts in neither client nor server messages can mean multiple things: a) There was no body part in the HTTP message and there should not be one b) The body part has been skipped and should be used again in the adapted message c) The body part has been skipped and should be removed from the message b) and c) can only be solved if we require that the callout service MUST send an empty body part, if it wants to make sure that a skipped original part is not included in the adapted message. Is this the solution? If not, we should consider to either skip the Skip-Parts feature or to redefine it in another way. Please check this idea: ----------------------- Payload becomes optional in DUM messages. A new named parameter "Skipped-Payload" has a value which is the size of the payload but the payload itself is not sent. The Skip-Parts negotiation remains the same but the OPES processor must still send DUM messages including Kept parameter (becoming mandantory in this case). The callout server replies with normal DUM or DUY messages (DUM if it wants to replace the content it never saw, DUY if it wants the processor to re-use the original data as usual). If the part is not sent, it shall be deleted from the message. The overall message part handling becomes much easier. There are DUM/DUY messages for all message parts that are in the HTTP message and parts that are not in the HTTP message (or that shall be deleted) will not be sent. Does this solve the problems and does it simplify the draft and implementations? Regards Martin From owner-ietf-openproxy@mail.imc.org Thu Oct 23 13:34:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08429 for ; Thu, 23 Oct 2003 13:34:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACjLd-0005Iv-00 for opes-archive@ietf.org; Thu, 23 Oct 2003 13:34:09 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ACjLc-0005Is-00 for opes-archive@ietf.org; Thu, 23 Oct 2003 13:34:09 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NHEcI7071943 for ; Thu, 23 Oct 2003 10:14:38 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9NHEbIa071942 for ietf-openproxy-bks; Thu, 23 Oct 2003 10:14:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NHEaI7071935 for ; Thu, 23 Oct 2003 10:14:36 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h9NHEbGh021078; Thu, 23 Oct 2003 11:14:37 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9NHEbpt021077; Thu, 23 Oct 2003 11:14:37 -0600 (MDT) (envelope-from rousskov) Date: Thu, 23 Oct 2003 11:14:37 -0600 (MDT) From: Alex Rousskov To: "OPES WG (E-mail)" Subject: HTTP/OCP: short-circuit In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D0E6624@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D0E6624@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 23 Oct 2003, Martin Stecher wrote: > First here are some thoughts about short-circuits in the request-profile. I think handling this one is not so complicated and can be added to the existing draft: > > Before the callout server sends back any application message part, > it MUST decide whether it wants to adapt the request or to > short-curcuit. It will either send back request-header, > request-body, request-trailer parts or response-header, > response-body, response-trailer parts. Some parts could be > optional due to conditions defined below but it MUST NOT mix parts > of these two lists; on violation client MUST terminate > transaction. I agree with the above in principle. If we make any changes to the what-parts-to-send-or-skip mechanism, the above may need to reflect those changes, of course. As of now, the above together with adding adapted response-* parts to request profile should suffice. Alex. From owner-ietf-openproxy@mail.imc.org Thu Oct 23 16:54: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 QAA18347 for ; Thu, 23 Oct 2003 16:54:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACmU7-0000N0-00 for opes-archive@ietf.org; Thu, 23 Oct 2003 16:55:07 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ACmU6-0000Mw-00 for opes-archive@ietf.org; Thu, 23 Oct 2003 16:55:06 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NKdgI7079125 for ; Thu, 23 Oct 2003 13:39:42 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9NKdgCm079123 for ietf-openproxy-bks; Thu, 23 Oct 2003 13:39:42 -0700 (PDT) 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 h9NKddI7079115 for ; Thu, 23 Oct 2003 13:39:40 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id YHCTIREPoutgoing id 59J7X8BX; 24 Oct 2003 00:46:55 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: Rename Optional-Parts Date: Thu, 23 Oct 2003 22:39:35 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D01407E@mail.webwasher.com> Thread-Topic: Rename Optional-Parts Thread-Index: AcOZpcVPeOrv5wb3RS29ZyTWKQHm0g== From: "Martin Stecher" To: "OPES WG (E-Mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9NKdfI7079116 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Re: Second comment in section 2.2.3 Optional Parts of HTTP Adaptation: > (XXX: we should probably rename Optional to something like Auxiliary > or FYI because it is awkward/wrong that optional parts become mandatory/required). I agree, it is awkward that optional parts become mandantory after negotiation. "Auxiliary parts" sounds good to me. Shall we rename the named parameter "Optional-Parts" to "Aux-Parts"? Regards Martin From owner-ietf-openproxy@mail.imc.org Thu Oct 23 17:26: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 RAA19715 for ; Thu, 23 Oct 2003 17:26:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACmyL-0000s5-00 for opes-archive@ietf.org; Thu, 23 Oct 2003 17:26:21 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ACmyK-0000s2-00 for opes-archive@ietf.org; Thu, 23 Oct 2003 17:26:20 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NL8CI7080568 for ; Thu, 23 Oct 2003 14:08:12 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9NL8Bvg080567 for ietf-openproxy-bks; Thu, 23 Oct 2003 14:08:11 -0700 (PDT) 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 h9NL89I7080560 for ; Thu, 23 Oct 2003 14:08:10 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id I7A9FT9Koutgoing id FRPXNO57; 24 Oct 2003 01:15:26 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: Transfer-Encodings Date: Thu, 23 Oct 2003 23:08:06 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D014080@mail.webwasher.com> Thread-Topic: Transfer-Encodings Thread-Index: AcOZqcDYpYqJxup2Q72fF1wKXyLrvg== From: "Martin Stecher" To: "OPES WG (E-Mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9NL8BI7080563 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Re: section 2.5 Transfer Encodings of HTTP adaption draft > This is still ugly -- > the callout service has no way to know whether the OPES processor > removed encodings (and the Transfer-Encoding header) or did not > remove the encodings (but removed the header), etc. What problem do you see here? We defined: > In the absence of explicit transfer-encoding negotiations, an OCP > agent MUST NOT send transfer-encoded application messages. > Informally, this means that the agent or its environment have to make > sure that all transfer encodings are stripped before an application > message enters OCP scope. So, an OPES processor must assume that there is no encoding. Of course, it gets a problem if the processor violates this rule. How to detect? Very hard. But it is the same problem as applying a Transfer-Encoding in HTTP without setting the header. Or do you think it is to weak because it does not foresee what will happen if explicit transfer-encoding negotiation will be introduced in future? Shall we introduce a Transfer-Encoding parameter to AMS that MUST be set if a transfer encoding is (still) applied to the content? Implementations could be better prepared in this case and can at least terminate the transaction in this case. Regards Martin From owner-ietf-openproxy@mail.imc.org Thu Oct 23 17:32:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19973 for ; Thu, 23 Oct 2003 17:32:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACn4m-0000x9-00 for opes-archive@ietf.org; Thu, 23 Oct 2003 17:33:00 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ACn4m-0000x6-00 for opes-archive@ietf.org; Thu, 23 Oct 2003 17:33:00 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NLDhI7080782 for ; Thu, 23 Oct 2003 14:13:43 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9NLDhuQ080781 for ietf-openproxy-bks; Thu, 23 Oct 2003 14:13:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NLDfI7080776 for ; Thu, 23 Oct 2003 14:13:41 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h9NLDhGh027885; Thu, 23 Oct 2003 15:13:43 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9NLDhJf027884; Thu, 23 Oct 2003 15:13:43 -0600 (MDT) (envelope-from rousskov) Date: Thu, 23 Oct 2003 15:13:43 -0600 (MDT) From: Alex Rousskov To: Martin Stecher cc: "OPES WG (E-Mail)" Subject: Re: Rename Optional-Parts In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D01407E@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D01407E@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 23 Oct 2003, Martin Stecher wrote: > > Re: Second comment in section 2.2.3 Optional Parts of HTTP Adaptation: > > > (XXX: we should probably rename Optional to something like Auxiliary > > or FYI because it is awkward/wrong that optional parts become mandatory/required). > > I agree, it is awkward that optional parts become mandantory after negotiation. > "Auxiliary parts" sounds good to me. > > Shall we rename the named parameter "Optional-Parts" to "Aux-Parts"? Please do unless you get any objections or better ideas. Alex. From owner-ietf-openproxy@mail.imc.org Thu Oct 23 17:58: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 RAA20749 for ; Thu, 23 Oct 2003 17:58:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACnTb-0001Bb-00 for opes-archive@ietf.org; Thu, 23 Oct 2003 17:58:39 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ACnTa-0001BY-00 for opes-archive@ietf.org; Thu, 23 Oct 2003 17:58:38 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NLirI7081552 for ; Thu, 23 Oct 2003 14:44:53 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9NLiqJg081551 for ietf-openproxy-bks; Thu, 23 Oct 2003 14:44:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NLipI7081546 for ; Thu, 23 Oct 2003 14:44:51 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h9NLirGh028598; Thu, 23 Oct 2003 15:44:53 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9NLir0u028597; Thu, 23 Oct 2003 15:44:53 -0600 (MDT) (envelope-from rousskov) Date: Thu, 23 Oct 2003 15:44:53 -0600 (MDT) From: Alex Rousskov To: "OPES WG (E-Mail)" Subject: Re: Transfer-Encodings In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D014080@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D014080@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 think you are right. If we have a MUST that precludes any encodings, there is no point in documenting a header that describes encodings. I withdraw my comment. Let's add an informal sentence emphasizing the importance of both this MUST and the other MUST that says that an agent MUST terminate if it cannot remove transfer encoding. Violating either would lead to interoperability problems. Logging service would have to define and negotiate exceptions to the above if they want to get the message "as is" (whatever that means in an OCP context). Thanks, Alex. On Thu, 23 Oct 2003, Martin Stecher wrote: > > Re: section 2.5 Transfer Encodings of HTTP adaption draft > > > This is still ugly -- > > the callout service has no way to know whether the OPES processor > > removed encodings (and the Transfer-Encoding header) or did not > > remove the encodings (but removed the header), etc. > > What problem do you see here? > We defined: > > > In the absence of explicit transfer-encoding negotiations, an OCP > > agent MUST NOT send transfer-encoded application messages. > > Informally, this means that the agent or its environment have to make > > sure that all transfer encodings are stripped before an application > > message enters OCP scope. > > So, an OPES processor must assume that there is no encoding. > Of course, it gets a problem if the processor violates this rule. > How to detect? Very hard. But it is the same problem as applying a > Transfer-Encoding in HTTP without setting the header. > > Or do you think it is to weak because it does not foresee what will > happen if explicit transfer-encoding negotiation will be introduced > in future? > > Shall we introduce a Transfer-Encoding parameter to AMS that MUST be > set if a transfer encoding is (still) applied to the content? > Implementations could be better prepared in this case and can at least > terminate the transaction in this case. > > Regards > Martin > > From owner-ietf-openproxy@mail.imc.org Thu Oct 23 18:20:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22477 for ; Thu, 23 Oct 2003 18:20:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACnoP-0001NJ-00 for opes-archive@ietf.org; Thu, 23 Oct 2003 18:20:09 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ACnoP-0001NF-00 for opes-archive@ietf.org; Thu, 23 Oct 2003 18:20:09 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NM22I7082183 for ; Thu, 23 Oct 2003 15:02:02 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9NM215K082182 for ietf-openproxy-bks; Thu, 23 Oct 2003 15:02:01 -0700 (PDT) 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 h9NM1xI7082171 for ; Thu, 23 Oct 2003 15:02:00 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id DXGQ80A8outgoing id RAJY5C7Y; 24 Oct 2003 02:09:16 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: Incorrect incoming HTTP messages Date: Fri, 24 Oct 2003 00:01:56 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D014081@mail.webwasher.com> Thread-Topic: Incorrect incoming HTTP messages Thread-Index: AcOZsUXiQIlgNWQDT367nytiMZ16Nw== From: "Martin Stecher" To: "OPES WG (E-Mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9NM21I7082178 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Re: section 2.6 HTTP Header Correctness of HTTP adaptation draft > what if incoming HTTP message is already in violation of the > HTTP spec. Are we saying that OPES processor has to fix it? Should we > cover that case implicitly: "Assuming compliant input, ..." No, we should not force the OPES processor to fix HTTP headers before sending to the callout service. It makes no sense to put this extra burdon on the processor, because we define later: > An OPES processor MAY forward the response of a callout service to > other callout services without verifying HTTP header correctness. > Consequently, a callout service cannot assume that the HTTP headers > it receives are correct or final from an HTTP point of view. So, for a callout server it should not make a difference whether it sees incorrect incoming headers or incorrect headers from a previous callout service. What do you think about changing the beginning of section 2.6 from current "HTTP OPES processors MUST ensure..." to "When communicating with other HTTP applications, OPES processors MUST ensure..." On the other hand the OPES processor has a problem if it trusts an incorrect incoming Content-Length header and therefore sends an incorrect AM-EL size. Is there anything we could do against this? Should we document this in any way? Regards Martin From owner-ietf-openproxy@mail.imc.org Thu Oct 23 19:13:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23901 for ; Thu, 23 Oct 2003 19:13:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACodl-0001rT-00 for opes-archive@ietf.org; Thu, 23 Oct 2003 19:13:13 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ACodk-0001r5-00 for opes-archive@ietf.org; Thu, 23 Oct 2003 19:13:12 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NMxpI7084316 for ; Thu, 23 Oct 2003 15:59:51 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9NMxpTp084315 for ietf-openproxy-bks; Thu, 23 Oct 2003 15:59:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail.cs.utexas.edu (root@mail.cs.utexas.edu [128.83.139.10]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NMxoI7084310 for ; Thu, 23 Oct 2003 15:59:50 -0700 (PDT) (envelope-from dahlin@cs.utexas.edu) Received: from cs.utexas.edu (linksysd.csres.utexas.edu [128.83.143.129]) (authenticated bits=0) by mail.cs.utexas.edu (8.12.10/8.12.10) with ESMTP id h9NMxpNl005233 for ; Thu, 23 Oct 2003 17:59:51 -0500 (CDT) Message-ID: <3F985D62.3060809@cs.utexas.edu> Date: Thu, 23 Oct 2003 17:59:46 -0500 From: Mike Dahlin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES WG Subject: WWW 2004 -- Upcoming CFP deadline 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 Colleagues, Please consider submitting and encourage others to submit. Thanks. -mike WWW2004 CALL FOR PAPERS The Thirteenth International World Wide Web Conference May 17-22, 2004 New York City, NY USA http://www2004.org/ Paper submission deadline: November 14, 2003 The WWW2004 conference will be held in Manhattan at the Sheraton Hotel. The technical program will include refereed paper presentations, alternate track presentations, plenary sessions, panels, and poster sessions. Tutorials and workshops will precede the main program, and a Developers Day, devoted to in-depth technical sessions designed specifically for Web developers, will follow. IMPORTANT DATES Tutorial/workshop proposals deadline: October 15, 2003 Paper submission deadline: November 14, 2003 Panel proposals deadline: November 14, 2003 Poster submission starts: January 15, 2004 Poster submission deadline: February 7, 2004 Author notification (papers): January 31, 2004 Developers Day deadline: February 14, 2004 Final papers due: February 28, 2004 Author notification (posters): March 14, 2004 Industrial Practice track deadline: March 15, 2004 Conference:May 17-22, 2004 REFEREED PAPERS TRACK WWW2004 seeks original papers describing research in all areas of the Web. Papers should not have been published or be in submission at another conference or journal. Topics include but are not limited to: Applications Browsers and User Interfaces Data Mining Electronic Commerce (potential papers should be submitted to the EC'04 Conference, which is co-located with WWW2004) Mobility and Wireless Access Performance and Reliability Search Security and Privacy Semantic Web Web Engineering Submissions should present original reports of substantive new work. Papers should properly place the work within the field, cite related work, and clearly indicate the innovative aspects of the work and its contribution to the field. Papers will be peer-reviewed by at least 3 reviewers from an International Program Committee. Accepted papers will appear in the conference proceedings published by the Association for Computing Machinery (ACM), and will also be accessible to the general public via http://www2004.org/. Authors are not required to transfer copyright. Papers must be submitted electronically in PDF format, and must be formatted using the ACM proceedings format. Detailed formatting requirements will be available on http://www2004.org/. The official language of the conference is English. Inquiries can be sent to www2004-pc-chairs@cs.wpi.edu. ALTERNATE TRACKS Alternate tracks include a combination of peer-reviewed papers and invited presentations. Topics include: Education Web of Communities Web Services Industrial Practice Panels W3C Track (latest news and views from the World Wide Web Consortium) Invited papers only Inquiries can be sent to www2004-pc-chairs@cs.wpi.edu. PROGRAM COMMITTEE CO-CHAIRS Marc Najork, Microsoft Research Craig Wills, Worcester Polytechnic Institute POSTERS Posters provide a forum for late-breaking research, and facilitate feedback in an informal setting. Posters are peer-reviewed. Formatting and publication details will be available on http://www2004.org/. The poster area provides an opportunity for researchers and practitioners to present and demonstrate their recent Web-related research, and to obtain feedback from their peers in an informal setting. It gives conference attendees a way to learn about innovative works in progress in a timely and informal manner. TUTORIALS AND WORKSHOPS A program of tutorials will cover topics of current interest to Web design, development, services, operation, use, and evaluation. These half and full-day sessions will be led by internationally recognized experts and experienced instructors using prepared content. Workshops provide an opportunity for researchers, designers, leaders, and practitioners to explore current Web R&D issues through a more focused and in-depth manner than is possible in a traditional conference session. Participants typically present position statements and hold in-depth discussions with their peers within the workshop setting. DEVELOPERS DAY Developers Day (D-Day) will be devoted to the interests of Web developers, and will offer in-depth discussions of technologies and tools at the forefront of the Web. This day-long program will consist of several parallel streams focused on specific content areas. D-Day sessions are designed to be timely and state-of-the-art. REFEREED TRACK AREA CHAIRS Applications: Vice Chair: Corin Anderson, Google, USA Deputy Vice Chair: Prashant Shenoy, University of Massachusetts, USA Browsers and UI: Vice Chair: Andreas Paepcke, Stanford University, USA Deputy Vice Chair: Bay-Wei Chang, Google, USA Data Mining: Vice Chair: Krishna Bharat, Google, USA Deputy Vice Chair: Ramakrishnan Srikant, IBM Almaden, USA Electronic Commerce: WWW2004 Liason to EC2004 Conference: David Pennock, Overture Services, USA WWW2004 Liason to EC2004 Conference: Mark Manasse, Microsoft Research, USA Mobility and Wireless Access: Vice Chair: Yoelle Maarek, IBM Haifa, Israel Deputy Vice Chair: Jason Nieh, Columbia University, USA Performance and Reliability: Vice Chair: Mike Dahlin, University of Texas Austin, USA Deputy Vice Chair: Steve Gribble, University of Washington, USA Search: Vice Chair: Prabhakar Raghavan, Verity, USA Deputy Vice Chair: Jon Kleinberg, Cornell University, USA Security and Privacy: Vice Chair: Brian LaMacchia, Microsoft Research, USA Deputy Vice Chair: Patrick McDaniel, AT&T Research, USA Semantic Web: Vice Chair: Peter Patel-Schneider, Bell Labs, USA Deputy Vice Chair: Steffen Staab, University of Karlsruhe, Germany Web Engineering: Vice Chair: Daniel Schwabe, Pontifical Catholic University of Rio de Janeiro, Brazil Deputy Vice Chair: Martin Gaedke, University of Karlsruhe, Germany ALTERNATE TRACK CHAIRS Education: Co-Chair: Peter Brusilovsky, University of Pittsburgh, USA Co-Chair: Wolfgang Nejdl, University of Hannover, Germany Web of Communities: Co-Chair: David De Roure, University of Southampton, UK Co-Chair: Liddy Nevile, La Trobe University, Australia Industrial Practice: Chair: Raymie Stata, University of California Santa Cruz, USA Deputy Chair: William Cook, University of Texas Austin, USA Web Services: Chair: Francisco (Paco) Curbera, IBM Research, USA Deputy Chair: Mike Papazoglou, Tilburg University, Netherlands W3C: Chair: Marie-Claire Forgue, W3C, France Panels: Chair: Lloyd Rutledge, CWI Amsterdam, The Netherlands Deputy Chair: Mary Ellen Zurko, IBM, USA TUTORIALS AND WORKSHOPS CO-CHAIRS Arun Iyengar, IBM Research, USA Bebo White, Stanford Linear Accelerator Center, USA POSTER CO-CHAIRS Chair: Irwin King, The Chinese University of Hong Kong Deputy Chair: Weisong Shi, Wayne State University, USA DEVELOPERS DAY CO-CHAIRS: TBD CONFERENCE CO-CHAIRS Stuart Feldman, IBM Michael Uretsky, New York University IW3C2 Liason to WWW2004 Vincent Shen, W3C IW3C2 LIAISON TO THE PROGRAM COMMITTEE Arun Iyengar, IBM Research, USA CONFERENCE ORGANIZERS International World Wide Web Conference Committee (IW3C2) New York University Center For Advanced Technology General questions about WWW2004 may be sent to info@www2004.org From owner-ietf-openproxy@mail.imc.org Fri Oct 24 04:22: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 EAA20955 for ; Fri, 24 Oct 2003 04:22:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACxDO-0007YP-00 for opes-archive@ietf.org; Fri, 24 Oct 2003 04:22:34 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ACxDN-0007YM-00 for opes-archive@ietf.org; Fri, 24 Oct 2003 04:22:33 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9O8BlI7051398 for ; Fri, 24 Oct 2003 01:11:47 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9O8BkJh051397 for ietf-openproxy-bks; Fri, 24 Oct 2003 01:11:47 -0700 (PDT) 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 h9O8BiI7051351 for ; Fri, 24 Oct 2003 01:11:45 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id A273CKYAoutgoing id T4HYQLJN; 24 Oct 2003 12:18:53 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: Rename Optional-Parts Date: Fri, 24 Oct 2003 10:11:33 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D0E6632@mail.webwasher.com> Thread-Topic: Rename Optional-Parts Thread-Index: AcOZqotfIESZJmhwSSWSr9l3k4WDiQAWg/Iw From: "Martin Stecher" To: "OPES WG (E-Mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9O8BkI7051388 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Done. Optional-Parts is now Aux-parts. (The online example is already up-to-date). I also defined what to be done if the rules for Aux-Parts parameter handling are violated. I think that adding illegal parts to an Aux-Parts parameter in a negotiation offer does not endanger interoperability if the peer ignores these parameters. But requesting auxiliary parts that were not offered will lead to problems in message exchange so that a transaction must be terminated in this case: An OPES processor MUST NOT include any message part which is not marked as auxiliary part in the list of original parts for the given profile. The callout server MUST ignore non-auxiliary parts listed in the Aux-Parts parameter. The callout server MUST NOT include any message part that was not explicitly listed in the negotiation offer. In case of a violation of this rule the OPES processor MUST terminate the transaction. Regards Martin > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Thursday, October 23, 2003 11:14 PM > To: Martin Stecher > Cc: OPES WG (E-Mail) > Subject: Re: Rename Optional-Parts > > > On Thu, 23 Oct 2003, Martin Stecher wrote: > > > > > Re: Second comment in section 2.2.3 Optional Parts of HTTP > Adaptation: > > > > > (XXX: we should probably rename Optional to something > like Auxiliary > > > or FYI because it is awkward/wrong that optional parts > become mandatory/required). > > > > I agree, it is awkward that optional parts become > mandantory after negotiation. > > "Auxiliary parts" sounds good to me. > > > > Shall we rename the named parameter "Optional-Parts" to "Aux-Parts"? > > Please do unless you get any objections or better ideas. > > Alex. > > From owner-ietf-openproxy@mail.imc.org Fri Oct 24 04:35:25 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21293 for ; Fri, 24 Oct 2003 04:35:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACxPx-0007gM-00 for opes-archive@ietf.org; Fri, 24 Oct 2003 04:35:33 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ACxPw-0007gJ-00 for opes-archive@ietf.org; Fri, 24 Oct 2003 04:35:32 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9O8Q9I7055698 for ; Fri, 24 Oct 2003 01:26:09 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9O8Q9t2055697 for ietf-openproxy-bks; Fri, 24 Oct 2003 01:26:09 -0700 (PDT) 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 h9O8Q7I7055663 for ; Fri, 24 Oct 2003 01:26:08 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id YYIDA455outgoing id ED1XWC2S; 24 Oct 2003 12:33:22 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: Transfer-Encodings Date: Fri, 24 Oct 2003 10:26:02 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D0E6633@mail.webwasher.com> Thread-Topic: Transfer-Encodings Thread-Index: AcOZruiPNCKSUDUxTReTDYJjfkWtggAWYRjw From: "Martin Stecher" To: "OPES WG (E-Mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9O8Q8I7055688 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Done. > > > Martin, > > I think you are right. If we have a MUST that precludes any > encodings, there is no point in documenting a header that describes > encodings. I withdraw my comment. Let's add an informal sentence > emphasizing the importance of both this MUST and the other MUST that > says that an agent MUST terminate if it cannot remove transfer > encoding. Violating either would lead to interoperability problems. > > Logging service would have to define and negotiate exceptions > to the above if they want to get the message "as is" (whatever that > means in an OCP context). > > Thanks, > > Alex. > > > On Thu, 23 Oct 2003, Martin Stecher wrote: > > > > > Re: section 2.5 Transfer Encodings of HTTP adaption draft > > > > > This is still ugly -- > > > the callout service has no way to know whether the OPES processor > > > removed encodings (and the Transfer-Encoding header) or did not > > > remove the encodings (but removed the header), etc. > > > > What problem do you see here? > > We defined: > > > > > In the absence of explicit transfer-encoding negotiations, an OCP > > > agent MUST NOT send transfer-encoded application messages. > > > Informally, this means that the agent or its environment > have to make > > > sure that all transfer encodings are stripped before an > application > > > message enters OCP scope. > > > > So, an OPES processor must assume that there is no encoding. > > Of course, it gets a problem if the processor violates this rule. > > How to detect? Very hard. But it is the same problem as applying a > > Transfer-Encoding in HTTP without setting the header. > > > > Or do you think it is to weak because it does not foresee what will > > happen if explicit transfer-encoding negotiation will be introduced > > in future? > > > > Shall we introduce a Transfer-Encoding parameter to AMS that MUST be > > set if a transfer encoding is (still) applied to the content? > > Implementations could be better prepared in this case and > can at least > > terminate the transaction in this case. > > > > Regards > > Martin > > > > > From owner-ietf-openproxy@mail.imc.org Fri Oct 24 11:17: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 LAA08154 for ; Fri, 24 Oct 2003 11:17:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD3gn-0005Gq-00 for opes-archive@ietf.org; Fri, 24 Oct 2003 11:17:21 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AD3gm-0005Gd-00 for opes-archive@ietf.org; Fri, 24 Oct 2003 11:17:21 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OEpaI7081973 for ; Fri, 24 Oct 2003 07:51:36 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9OEpZ6m081972 for ietf-openproxy-bks; Fri, 24 Oct 2003 07:51:35 -0700 (PDT) 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 h9OEpTI7081962 for ; Fri, 24 Oct 2003 07:51:30 -0700 (PDT) (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 KAA05315; Fri, 24 Oct 2003 10:51:18 -0400 (EDT) Message-Id: <200310241451.KAA05315@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-end-comm-05.txt Date: Fri, 24 Oct 2003 10:51:18 -0400 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 processor and end points communications Author(s) : A. Barbir Filename : draft-ietf-opes-end-comm-05.txt Pages : 20 Date : 2003-10-23 This memo documents tracing requirements for Open Pluggable Edge Services (OPES) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opes-end-comm-05.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-end-comm-05.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-end-comm-05.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-10-24103707.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-opes-end-comm-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-opes-end-comm-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-24103707.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-openproxy@mail.imc.org Fri Oct 24 12:13: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 MAA13258 for ; Fri, 24 Oct 2003 12:13:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD4Z5-00076W-00 for opes-archive@ietf.org; Fri, 24 Oct 2003 12:13:27 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AD4Z2-00076P-00 for opes-archive@ietf.org; Fri, 24 Oct 2003 12:13:26 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OFu4I7084723 for ; Fri, 24 Oct 2003 08:56:04 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9OFu4a8084722 for ietf-openproxy-bks; Fri, 24 Oct 2003 08:56:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OFu2I7084717 for ; Fri, 24 Oct 2003 08:56:02 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h9OFu3Gh053563 for ; Fri, 24 Oct 2003 09:56:03 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9OFu3rr053562; Fri, 24 Oct 2003 09:56:03 -0600 (MDT) (envelope-from rousskov) Date: Fri, 24 Oct 2003 09:56:03 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: OCP Core: one service, two profiles Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: If a service works on message content (body), it would easily handle several application profiles by skipping or ignoring everything other than the message content. For example, a virus scanning service can handle both HTTP and SMTP content. Currently, profile result negotiation is attached to a Service Group, which is, essentially, a service. The following is not clear to me: - can two profiles be negotiated for the same group? - if yes, how can the agent distinguish which profile is being used for a given message? If we restrict the number of profiles per SG to one, the only way to support the above would be to create two identical SGs. In this case, we may want to support SG creation based on another SG rather than based on a raw list of services. If we allow multiple profiles per SG, we need a new identifier to specify which profile is being used. I think I prefer the former, to keep things simple. Thoughts, preferences? Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Fri Oct 24 13:03: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 NAA17900 for ; Fri, 24 Oct 2003 13:03:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD5Lr-0000sz-00 for opes-archive@ietf.org; Fri, 24 Oct 2003 13:03:51 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AD5Lq-0000sv-00 for opes-archive@ietf.org; Fri, 24 Oct 2003 13:03:51 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OGh4I7086850 for ; Fri, 24 Oct 2003 09:43:04 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9OGh4jx086849 for ietf-openproxy-bks; Fri, 24 Oct 2003 09:43:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OGh3I7086842 for ; Fri, 24 Oct 2003 09:43:03 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h9OGh4Gh054700; Fri, 24 Oct 2003 10:43:04 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9OGh4uX054699; Fri, 24 Oct 2003 10:43:04 -0600 (MDT) (envelope-from rousskov) Date: Fri, 24 Oct 2003 10:43:04 -0600 (MDT) From: Alex Rousskov To: "OPES WG (E-mail)" Subject: Re: what-parts-to-send-or-skip In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D0E6624@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D0E6624@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: I think we should step back a little and try to recall our primary goals here: A) parsing optimization: do not spend time isolating message parts twice B) bandwidth optimization: do not send data that is not needed by recipient C) accommodating HTTP-unaware services: just let them see/adapt the content part To start with, I think that a non-HTTP profile must be used for HTTP-unaware services. This leaves us with (A) and (B) above only. The following are facts to take into account (Martin mentioned most of them already): 1) HTTP messages have many parts, most of which may be absent, and some may have zero length 2) all HTTP messages we should care about have headers 3) most HTTP messages do not have trailers 4) HTTP message bodies are the only parts that can save "enough" bandwidth if skipped 5) Skipping bodies if there are no trailers is already supported by OCP Core 6) Most processors will not be able to skip HTTP message bodies if both headers and trailers need to be adopted (because they may have to cache the entire body while waiting for adaptations) 7) Adapting just HTTP headers is less common than adapting bodies. Moreover, adapting just HTTP headers may be done better via a dedicated profile 8) The interface to accommodate all possible combinations is rather complex and it is not very likely that implementations will get all corner cases right 9) While important, both (A) and (B) are "just" optimizations Given the above, I conclude that: - We should keep AM-Part and Aux-Part to accommodate (A), to have an interface for auxiliary parts in RESPMOD, and to support short-circuit operation. - We should rely on OCP Core "getting out of the loop" mechanisms to accommodate (B). That would let us terminate data transmission early enough, though not as early as with Skip-Part in some cases. We should delete the Skip-Part interface. - Optionally, we could add an optional Last-Needed-Part parameter to NR to allow specifying the _last_ original part needed by the service and being semantically equivalent to receiving (later) a corresponding Want-Use parameter with the actual size of all parts up to the last one. Processors MAY ignore Last-Needed-Part. With these rules, Last-Needed-Part does not introduce any new complicated requirements/dependencies. Martin, do you think the above would be sufficient to accommodate most of our needs? If yes, do you think adding Last-Needed-Part is worth the trouble? Any other comments or preferences? Alex. On Thu, 23 Oct 2003, Martin Stecher wrote: > Then here some thoughts on parts in HTTP messages: > A request header is always in HTTP messages. > > There are HTTP servers that do not send response headers. > > OPES processor MUST either create a dummy HTTP header part, or not > use OCP/HTTP. > > Trailers are often not in messages. There is no difference between > an empty trailer and a non-existing trailer. > > Bodies can or cannot exist. Empty but existing bodies are > technically possible. Can an empty body be deleted without > changing the meaning of the message? > > > Then the best way to describe what needs to be done I found for me > is a pseudo programming language style. I do not take the trailer > parts in account, it's long enough without ;-) > > OCP_Client_Send_Routine { > if ( NOT skip(request-header)) > send (request-header) > if (inMessage (request-body) AND NOT skip(request-body)) > send (request-body) > } > > OCP_Client_Receive_Routine { > lastMessagePart = 0 > while (read (newMessagePart)) { > if (newMessagePart == request-header) { > if (lastMessagePart != 0) > goto terminate_transaction; > buildHTTPMessage (newMessagePart); > } else if (newMessagePart == request-body) { > if (skip(request-header)) { // client has skipped part in send > if (lastMessagePart != 0) > goto terminate_transaction; > buildHTTPMessage (original_request-header); > } else { > if (lastMessagePart != request-header) > goto terminate_transaction; > } > buildHTTPMessage (newMessagePart); > } else if (newMessagePart == response-header) { > if (lastMessagePart != 0) > goto terminate_transaction; > buildHTTPMessage (newMessagePart); > } else if (newMessagePart == response-body) { > if (lastMessagePart != response-header) > goto terminate_transaction; > buildHTTPMessage (newMessagePart); > } > lastMessagePart = newMessagePart; > } > } > > OCP_Server_Receive_Routine { > lastMessagePart = 0 > while (read (newMessagePart)) { > if (newMessagePart == request-header) { > if (lastMessagePart != 0) > goto terminate_transaction; > filterHTTPMessage (newMessagePart); > } else if (newMessagePart == request-body) { > if (lastMessagePart != request-header) { > if (lastMessagePart != 0) > goto terminate_transaction; > if (skip_requested(request-header)) > goto terminate_transaction; > } > filterHTTPMessage (newMessagePart); > } > lastMessagePart = newMessagePart; > } > } > > OCP_Server_Send_Routine { > if (short_circuit) { // do request satisfaction > send (response-header) > if (message_has_body()) > send (response-body) > } else { > if (have_received (request-header)) { > send (request-header) > } else { > if (have_own (request-header) > send (request-header) > } > if (have_received (request-body)) { > if ( NOT want_to_delete (request-body)) > send (request-body) > } else { > if (have_own (request-body) > send (request-body) > } > } > } > > > This is not trivial and describing this in a good way is not easy. > Especially the problem that an OCP transaction that does not contain > request-body parts in neither client nor server messages can mean > multiple things: > a) There was no body part in the HTTP message and there should not be one > b) The body part has been skipped and should be used again in the > adapted message > c) The body part has been skipped and should be removed from the message > > b) and c) can only be solved if we require that the callout service > MUST send an empty body part, if it wants to make sure that a > skipped original part is not included in the adapted message. > > Is this the solution? > > If not, we should consider to either skip the Skip-Parts feature or > to redefine it in another way. > > > Please check this idea: > ----------------------- > > Payload becomes optional in DUM messages. A new named parameter > "Skipped-Payload" has a value which is the size of the payload but > the payload itself is not sent. > > The Skip-Parts negotiation remains the same but the OPES processor > must still send DUM messages including Kept parameter (becoming > mandantory in this case). > > The callout server replies with normal DUM or DUY messages (DUM if > it wants to replace the content it never saw, DUY if it wants the > processor to re-use the original data as usual). If the part is not > sent, it shall be deleted from the message. > > The overall message part handling becomes much easier. There are > DUM/DUY messages for all message parts that are in the HTTP message > and parts that are not in the HTTP message (or that shall be > deleted) will not be sent. > > Does this solve the problems and does it simplify the draft and > implementations? > > > Regards > Martin > > From owner-ietf-openproxy@mail.imc.org Fri Oct 24 13: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 NAA20076 for ; Fri, 24 Oct 2003 13:49:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD64D-0001gA-00 for opes-archive@ietf.org; Fri, 24 Oct 2003 13:49:41 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AD64C-0001g7-00 for opes-archive@ietf.org; Fri, 24 Oct 2003 13:49:40 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OHaPI7088678 for ; Fri, 24 Oct 2003 10:36:25 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9OHaPoK088677 for ietf-openproxy-bks; Fri, 24 Oct 2003 10:36:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OHaOI7088672 for ; Fri, 24 Oct 2003 10:36:24 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h9OHaPGh055962 for ; Fri, 24 Oct 2003 11:36:25 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9OHaP32055961; Fri, 24 Oct 2003 11:36:25 -0600 (MDT) (envelope-from rousskov) Date: Fri, 24 Oct 2003 11:36:25 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: documenting OCP parameters 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: HTTP Adaptations draft raised a concern that the only way to document a new OCP parameter is to describe it using low-level syntax BNF. Using BNFs for declarations is bad because it covers/hides the important information in syntax sugar and makes the reader think that a parameter may have some syntax features not already documented in the OCP Core. Moreover, if extension authors are not very careful, they could accidently introduce new syntax features which is a bad idea (unless explicitly negotiated first). Finally, since all BNFs look similar, using BNF makes OCP parameters look like HTTP headers (that have to be defined using BNF because there is nothing else available for HTTP) and vice versa, which is not that good since HTTP syntax is actually different from OCP syntax. If there are no objections, I am going to add a section to OCP that will describe a very simple/basic way to document any parameter without using a syntax BNF. The same interface will be used in OCP Core, of course. Here is a sketch/template of possible choices : atom; : list< >; : structure { []; // anonymous : ; // required named [: ]; // optional }; This is similar to C/C++ typedefs but uses more-intuitive Pascal-like declaration syntax (new type name first, followed by the definition). The declaration would be accompanied by semantic rules, of course. Note that we already use something like the above for OCP messages (defining an entire message using BNF would be tedious). Here are a few usage examples from OCP Core: Uri: atom; Service: structure { Uri; }; Services: list; And from the HTTP draft: Am-Part: atom; Am-Parts: list; Http-Profile: structure { Uri; [Aux-Parts: Am-Parts]; [Skip-Parts: Am-Parts]; }; And here is how NO message can be declared using the above declarations and current message declaration syntax: name: NO anonymous parameters: Services named parameters: [sg-id: Uni] payload: undefined Any objections or better ideas? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Fri Oct 24 14:11: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 OAA20785 for ; Fri, 24 Oct 2003 14:11:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD6Pi-0001w0-00 for opes-archive@ietf.org; Fri, 24 Oct 2003 14:11:54 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AD6Ph-0001vx-00 for opes-archive@ietf.org; Fri, 24 Oct 2003 14:11:53 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OHoPI7089343 for ; Fri, 24 Oct 2003 10:50:25 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9OHoPhG089342 for ietf-openproxy-bks; Fri, 24 Oct 2003 10:50:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OHoOI7089335 for ; Fri, 24 Oct 2003 10:50:24 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h9OHoPGh056217; Fri, 24 Oct 2003 11:50:25 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9OHoPbx056216; Fri, 24 Oct 2003 11:50:25 -0600 (MDT) (envelope-from rousskov) Date: Fri, 24 Oct 2003 11:50:25 -0600 (MDT) From: Alex Rousskov To: "OPES WG (E-Mail)" Subject: Re: Incorrect incoming HTTP messages In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D014081@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D014081@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 24 Oct 2003, Martin Stecher wrote: > Re: section 2.6 HTTP Header Correctness of HTTP adaptation draft > > What do you think about changing the beginning of section 2.6 from > current "HTTP OPES processors MUST ensure..." to "When communicating > with other HTTP applications, OPES processors MUST ensure..." Sounds OK, just delete the word "other". Ideally, I would prefer something that better reflects the diagram below, but cannot suggest a specific wording. > On the other hand the OPES processor has a problem if it trusts an > incorrect incoming Content-Length header and therefore sends an > incorrect AM-EL size. Is there anything we could do against this? > Should we document this in any way? Let's assume this is out of OCP scope and is only a concern for the "HTTP part" of the processor: HTTP <--> internal representation <--> OCP We should only be concerned with the right interface/link/logic, and we have to assume that we are getting valid information from the left part, I guess (i.e., that original internal representation is valid). Alex. From owner-ietf-openproxy@mail.imc.org Fri Oct 24 16:19: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 QAA27952 for ; Fri, 24 Oct 2003 16:19:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD8PD-0003oC-00 for opes-archive@ietf.org; Fri, 24 Oct 2003 16:19:31 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AD8PC-0003o9-00 for opes-archive@ietf.org; Fri, 24 Oct 2003 16:19:30 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OK85I7094171 for ; Fri, 24 Oct 2003 13:08:05 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9OK85wU094170 for ietf-openproxy-bks; Fri, 24 Oct 2003 13:08:05 -0700 (PDT) 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 h9OK83I7094164 for ; Fri, 24 Oct 2003 13:08:04 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id R8O1RJTBoutgoing id NBZMG1VW; 25 Oct 2003 00:15:15 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: OCP Core: one service, two profiles Date: Fri, 24 Oct 2003 22:07:53 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D014089@mail.webwasher.com> Thread-Topic: OCP Core: one service, two profiles Thread-Index: AcOaS08L5F8HtBIpREyTLsztwFFQUgAHV61g From: "Martin Stecher" To: "OPES WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9OK84I7094166 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi Alex, > > > If a service works on message content (body), it would easily handle > several application profiles by skipping or ignoring everything other > than the message content. For example, a virus scanning service can > handle both HTTP and SMTP content. > > Currently, profile result negotiation is attached to a Service Group, > which is, essentially, a service. The following is not clear to me: > > - can two profiles be negotiated for the same group? Currently not. > - if yes, how can the agent distinguish which profile > is being used for a given message? > > If we restrict the number of profiles per SG to one, the only way to > support the above would be to create two identical SGs. In this case, > we may want to support SG creation based on another SG rather than > based on a raw list of services. Creating SGs with identical set of services works and this solves the problem. Do you really think we need of a copy constructor of service groups? I think that since service groups only need to be created at the beginning of connections and these connections can then create any number of transactions, optimization in this area is not critical. > > If we allow multiple profiles per SG, we need a new identifier to > specify which profile is being used. > > I think I prefer the former, to keep things simple. Me too. > > Thoughts, preferences? > > Thank you, Regards Martin From owner-ietf-openproxy@mail.imc.org Fri Oct 24 17:01:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29704 for ; Fri, 24 Oct 2003 17:01:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD94M-0004PP-00 for opes-archive@ietf.org; Fri, 24 Oct 2003 17:02:02 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AD94L-0004PL-00 for opes-archive@ietf.org; Fri, 24 Oct 2003 17:02:01 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OKiXI7095195 for ; Fri, 24 Oct 2003 13:44:33 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9OKiXHB095194 for ietf-openproxy-bks; Fri, 24 Oct 2003 13:44:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OKiWI7095188 for ; Fri, 24 Oct 2003 13:44:32 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h9OKiXGh061826 for ; Fri, 24 Oct 2003 14:44:33 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9OKiXD6061825; Fri, 24 Oct 2003 14:44:33 -0600 (MDT) (envelope-from rousskov) Date: Fri, 24 Oct 2003 14:44:33 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: HTTP/OCP: OPES-Via to replace OPES-Processor and OPES-Service Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The 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 Fri Oct 24 17: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 RAA29994 for ; Fri, 24 Oct 2003 17:13:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD9FV-0004UY-00 for opes-archive@ietf.org; Fri, 24 Oct 2003 17:13:33 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AD9FV-0004UV-00 for opes-archive@ietf.org; Fri, 24 Oct 2003 17:13:33 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OKwbI7095691 for ; Fri, 24 Oct 2003 13:58:37 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9OKwbaN095690 for ietf-openproxy-bks; Fri, 24 Oct 2003 13:58:37 -0700 (PDT) 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 h9OKwZI7095681 for ; Fri, 24 Oct 2003 13:58:36 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id AHKW6GNZoutgoing id L5E6YE6K; 25 Oct 2003 01:05:52 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: what-parts-to-send-or-skip Date: Fri, 24 Oct 2003 22:58:32 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D01408B@mail.webwasher.com> Thread-Topic: what-parts-to-send-or-skip Thread-Index: AcOaTekshcJam1HERUuq3y+ExRtj3gAIAG+A From: "Martin Stecher" To: "OPES WG (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9OKwaI7095684 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi Alex, thank you for summarizing this so well. I agree to all facts but #7: > > 7) Adapting just HTTP headers is less common than > adapting bodies. Moreover, adapting just HTTP > headers may be done better via a dedicated > profile > There are many services that only deal with headers, especially in the request profile. Examples are privacy filters (delete Referer and Cookie headers) and URL blocker. > > Given the above, I conclude that: > > - We should keep AM-Part and Aux-Part to accommodate (A), > to have an interface for auxiliary parts in RESPMOD, > and to support short-circuit operation. Yes. > > - We should rely on OCP Core "getting out of the > loop" mechanisms to accommodate (B). That would > let us terminate data transmission early enough, > though not as early as with Skip-Part in some > cases. We should delete the Skip-Part interface. Probably yes. I have a little concern about the "early enough". Let's take a service in RESPMOD that deletes cookies from HTTP headers, nothing else. If that service is not fast in responding and sending the i-want-out message, the OPES processor will send much data of the body, wasting bandwidth. > > - Optionally, we could add an optional Last-Needed-Part > parameter to NR to allow specifying the _last_ > original part needed by the service and being semantically > equivalent to receiving (later) a corresponding Want-Use > parameter with the actual size of all parts up to the > last one. Processors MAY ignore Last-Needed-Part. > With these rules, Last-Needed-Part does not introduce > any new complicated requirements/dependencies. > > Martin, do you think the above would be sufficient to accommodate most > of our needs? If yes, do you think adding Last-Needed-Part is worth > the trouble? How do you see my concern above? Is it only valid for esoteric services? Last-Needed-Part would address this. But maybe we can add anoter parameter "Pause-Offset" to the feature which acts as a data-pause pre-request. It requests a first data-paused message after n bytes of the original body. As with data-pause, OPES processor SHOULD honor this request. This will be similar to the Preview feature of ICAP/1.0. I think this fits even better into OCP context and can also be used for other purposes (always where we have to assume that the callout service is not as fast as the OPES processor). Regards Martin From owner-ietf-openproxy@mail.imc.org Fri Oct 24 17:16: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 RAA00063 for ; Fri, 24 Oct 2003 17:16:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD9Ik-0004Wo-00 for opes-archive@ietf.org; Fri, 24 Oct 2003 17:16:54 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AD9Ij-0004Wl-00 for opes-archive@ietf.org; Fri, 24 Oct 2003 17:16:54 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OL6QI7096018 for ; Fri, 24 Oct 2003 14:06:26 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9OL6Qrd096017 for ietf-openproxy-bks; Fri, 24 Oct 2003 14:06:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OL6PI7096011 for ; Fri, 24 Oct 2003 14:06:25 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h9OL6RGh062531; Fri, 24 Oct 2003 15:06:27 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9OL6RbR062530; Fri, 24 Oct 2003 15:06:27 -0600 (MDT) (envelope-from rousskov) Date: Fri, 24 Oct 2003 15:06:27 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: RE: OCP Core: one service, two profiles In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D014089@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D014089@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 24 Oct 2003, Martin Stecher wrote: > > Currently, profile result negotiation is attached to a Service Group, > > which is, essentially, a service. The following is not clear to me: > > > > - can two profiles be negotiated for the same group? > > Currently not. We do not explicitly allow or prohibit this, right? Should I explicitly prohibit in the Core? > Do you really think we need of a copy constructor of service groups? > I think that since service groups only need to be created at the > beginning of connections and these connections can then create any > number of transactions, optimization in this area is not critical. Let's not optimize, then. The feature can be added later, if needed. Alex. From owner-ietf-openproxy@mail.imc.org Fri Oct 24 17:19: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 RAA00454 for ; Fri, 24 Oct 2003 17:19:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD9Le-0004dO-00 for opes-archive@ietf.org; Fri, 24 Oct 2003 17:19:54 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AD9Ld-0004dL-00 for opes-archive@ietf.org; Fri, 24 Oct 2003 17:19:53 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OL9iI7096118 for ; Fri, 24 Oct 2003 14:09:44 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9OL9iqJ096117 for ietf-openproxy-bks; Fri, 24 Oct 2003 14:09:44 -0700 (PDT) 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 h9OL9gI7096111 for ; Fri, 24 Oct 2003 14:09:43 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id 6KYR9JFZoutgoing id ILGVUROU; 25 Oct 2003 01:16:59 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: OCP Core: one service, two profiles Date: Fri, 24 Oct 2003 23:09:39 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D0E6643@mail.webwasher.com> Thread-Topic: OCP Core: one service, two profiles Thread-Index: AcOacrHtvjYYM4ONQLuW62qH6fgncwAADm1g From: "Martin Stecher" To: "OPES WG (E-Mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9OL9iI7096113 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > > > Currently, profile result negotiation is attached to a > Service Group, > > > which is, essentially, a service. The following is not > clear to me: > > > > > > - can two profiles be negotiated for the same group? > > > > Currently not. > > We do not explicitly allow or prohibit this, right? Should I > explicitly prohibit in the Core? Maybe we should add to OCP core that only the last negotiated profile for a service group is valid. > > > Do you really think we need of a copy constructor of service groups? > > I think that since service groups only need to be created at the > > beginning of connections and these connections can then create any > > number of transactions, optimization in this area is not critical. > > Let's not optimize, then. The feature can be added later, if needed. Agreed. Martin From owner-ietf-openproxy@mail.imc.org Fri Oct 24 17:46:36 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01536 for ; Fri, 24 Oct 2003 17:46:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD9ld-00052m-00 for opes-archive@ietf.org; Fri, 24 Oct 2003 17:46:45 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AD9ld-00052f-00 for opes-archive@ietf.org; Fri, 24 Oct 2003 17:46:45 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OLYJI7096970 for ; Fri, 24 Oct 2003 14:34:19 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9OLYJXf096969 for ietf-openproxy-bks; Fri, 24 Oct 2003 14:34:19 -0700 (PDT) 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 h9OLYHI7096962 for ; Fri, 24 Oct 2003 14:34:18 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id BU044B5Youtgoing id 6Y4FDDDY; 25 Oct 2003 01:41:31 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: documenting OCP parameters Date: Fri, 24 Oct 2003 23:34:11 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D01408C@mail.webwasher.com> Thread-Topic: documenting OCP parameters Thread-Index: AcOaWWI6kM13xC4iQ4Wvtoiu9VEO/wAHDbzA From: "Martin Stecher" To: "OPES WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9OLYII7096964 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi Alex, > > > HTTP Adaptations draft raised a concern that the only way to document > a new OCP parameter is to describe it using low-level syntax BNF. > > Using BNFs for declarations is bad because it covers/hides the > important information in syntax sugar and makes the reader think that > a parameter may have some syntax features not already documented in > the OCP Core. Moreover, if extension authors are not very careful, > they could accidently introduce new syntax features which is a bad > idea (unless explicitly negotiated first). Finally, since all BNFs > look similar, using BNF makes OCP parameters look like HTTP headers > (that have to be defined using BNF because there is nothing else > available for HTTP) and vice versa, which is not that good since HTTP > syntax is actually different from OCP syntax. > > If there are no objections, I am going to add a section to OCP that > will describe a very simple/basic way to document any parameter > without using a syntax BNF. The same interface will be used in OCP > Core, of course. Here is a sketch/template of possible choices > > : atom; > : list< >; > : structure { > []; // anonymous > : ; // required named > [: ]; // optional > }; > > This is similar to C/C++ typedefs but uses more-intuitive Pascal-like > declaration syntax (new type name first, followed by the definition). > The declaration would be accompanied by semantic rules, of course. > Note that we already use something like the above for OCP messages > (defining an entire message using BNF would be tedious). > > Here are a few usage examples from OCP Core: > > Uri: atom; > > Service: structure { > Uri; > }; > > Services: list; > > And from the HTTP draft: > > Am-Part: atom; > Am-Parts: list; > > Http-Profile: structure { > Uri; > [Aux-Parts: Am-Parts]; > [Skip-Parts: Am-Parts]; > }; > > And here is how NO message can be declared using the above > declarations and current message declaration syntax: > > name: > NO > anonymous parameters: > Services > named parameters: > [sg-id: Uni] > payload: > undefined > > > Any objections or better ideas? > Please add this to the core. I agree that such way of documentation will help. Could you even improve the Service declaration a little? Some way that allows to show that there are optional named parameters (none defined by core). So, that it will allow the HTTP draft to define that Http-Profile: Service and that Aux-Parts is a named parameter of that structure. Your proposed solution has the disadvantage that NO has Services parameter, defined as a list of Service and in HTTP there is no mapping from HTTP-Profile to Service and no hint that NO anonymous parameter is being changed from Services to Http-Profiles. Regards Martin From owner-ietf-openproxy@mail.imc.org Fri Oct 24 18:11: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 SAA03172 for ; Fri, 24 Oct 2003 18:11:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADA9V-0005PL-00 for opes-archive@ietf.org; Fri, 24 Oct 2003 18:11:25 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ADA9U-0005PI-00 for opes-archive@ietf.org; Fri, 24 Oct 2003 18:11:25 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OLxPI7097574 for ; Fri, 24 Oct 2003 14:59:25 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9OLxPrG097572 for ietf-openproxy-bks; Fri, 24 Oct 2003 14:59:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OLxOI7097567 for ; Fri, 24 Oct 2003 14:59:24 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h9OLxQGh063865; Fri, 24 Oct 2003 15:59:26 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9OLxQCK063864; Fri, 24 Oct 2003 15:59:26 -0600 (MDT) (envelope-from rousskov) Date: Fri, 24 Oct 2003 15:59:26 -0600 (MDT) From: Alex Rousskov To: "OPES WG (E-mail)" Subject: RE: what-parts-to-send-or-skip In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D01408B@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D01408B@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 24 Oct 2003, Martin Stecher wrote: > > 7) Adapting just HTTP headers is less common than > > adapting bodies. Moreover, adapting just HTTP > > headers may be done better via a dedicated > > profile > > > > There are many services that only deal with headers, especially in > the request profile. Examples are privacy filters (delete Referer > and Cookie headers) and URL blocker. You are right -- I forgot about URL blocking. 7) Adapting just HTTP headers of messages with large bodies is less common than adapting large bodies. > I have a little concern about the "early enough". Let's take a > service in RESPMOD that deletes cookies from HTTP headers, nothing > else. If that service is not fast in responding and sending the > i-want-out message, the OPES processor will send much data of the > body, wasting bandwidth. That was my concern as well. Note that the service may be "fast enough" but the processor itself may not read service responses "fast enough" or there could be a network problem. In a case of already congested network, we are more likely to run into problems, and hence are more likely to make the situation worse! > > - Optionally, we could add an optional Last-Needed-Part > > parameter to NR to allow specifying the _last_ > > original part needed by the service and being semantically > > equivalent to receiving (later) a corresponding Want-Use > > parameter with the actual size of all parts up to the > > last one. Processors MAY ignore Last-Needed-Part. > > With these rules, Last-Needed-Part does not introduce > > any new complicated requirements/dependencies. > > > How do you see my concern above? Is it only valid for esoteric services? URL filtering is not esoteric for sure. When done on requests, it is probably not a big deal because requests have no or small bodies. However, adapting based on MIME type or other response header information may not be that uncommon. It would be very nice to support that efficiently and Last-Needed-Part does not do that. > Last-Needed-Part would address this. But maybe we can add anoter > parameter "Pause-Offset" to the feature which acts as a data-pause > pre-request. It requests a first data-paused message after n bytes > of the original body. > As with data-pause, OPES processor SHOULD honor this request. > This will be similar to the Preview feature of ICAP/1.0. Good, except for the Offset part. Since the offset is not known a priory, services that need just headers will have to overprovision on average but will not get enough sometimes. I see two good options: Option A: - add Wont-Need-Part parameter to Profile in HTTP equivalent to Wont-Need, but uses parts, not offsets Meaning: I know for sure that I do not need anything starting with the given part - add Data-Pause parameter to Feature in Core equivalent to an a priory Data-Pause message Meaning: Let me tell you later wether I need anything starting with the given offset - add Data-Pause-Part parameter to Profile in HTTP equivalent to Data-Pause message, but uses parts Meaning: Let me tell you later wether I need starting with the given part - add Wont-Need parameter to Feature in Core? (for symmetry reasons) Option B: - add a new Offset parameter type to Core: Offset: structure { [Octet: size]; [AM-Part: atom]; } - add Wont-Need and Data-Pause parameters to Feature in Core; the sender can use Offset and/or Part members. Option A is more explicit/straight. Option B reduces the number of virtually identical parameters to deal with and lets other bindings reuse the Offset type. Both options do what we need and do not introduce any _new_ conflicts or concerns. They are equivalent to already existing messages/parameters. Which option would you prefer? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Fri Oct 24 18:12:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03366 for ; Fri, 24 Oct 2003 18:12:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADAB8-0005Qj-00 for opes-archive@ietf.org; Fri, 24 Oct 2003 18:13:06 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ADAB7-0005Qg-00 for opes-archive@ietf.org; Fri, 24 Oct 2003 18:13:05 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OM36I7097747 for ; Fri, 24 Oct 2003 15:03:06 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9OM36lQ097746 for ietf-openproxy-bks; Fri, 24 Oct 2003 15:03:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OM35I7097741 for ; Fri, 24 Oct 2003 15:03:05 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h9OM37Gh063997; Fri, 24 Oct 2003 16:03:07 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9OM37pv063996; Fri, 24 Oct 2003 16:03:07 -0600 (MDT) (envelope-from rousskov) Date: Fri, 24 Oct 2003 16:03:07 -0600 (MDT) From: Alex Rousskov To: Martin Stecher cc: "OPES WG (E-Mail)" Subject: RE: OCP Core: one service, two profiles In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D0E6643@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D0E6643@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 24 Oct 2003, Martin Stecher wrote: > > We do not explicitly allow or prohibit this, right? Should I > > explicitly prohibit in the Core? > > Maybe we should add to OCP core that only the last negotiated > profile for a service group is valid. Meaning that profile negotiation with SG parameter selects the current profile? That is, the profile can be changed later? I am not sure I like this because renegotiation would be messy when there are pending transactions using the same service group but with the old profile. The implementation would no longer be able to identify SG properties based on sg-id. Do you see what I am getting at? Alex. From owner-ietf-openproxy@mail.imc.org Fri Oct 24 18:30: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 SAA04282 for ; Fri, 24 Oct 2003 18:30:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADASR-0005dw-00 for opes-archive@ietf.org; Fri, 24 Oct 2003 18:30:59 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ADASQ-0005dt-00 for opes-archive@ietf.org; Fri, 24 Oct 2003 18:30:58 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OMG8I7098133 for ; Fri, 24 Oct 2003 15:16:09 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9OMG8M7098132 for ietf-openproxy-bks; Fri, 24 Oct 2003 15:16:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OMG7I7098127 for ; Fri, 24 Oct 2003 15:16:07 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h9OMG9Gh064377; Fri, 24 Oct 2003 16:16:09 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9OMG9jS064376; Fri, 24 Oct 2003 16:16:09 -0600 (MDT) (envelope-from rousskov) Date: Fri, 24 Oct 2003 16:16:09 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: RE: documenting OCP parameters In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D01408C@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D01408C@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 24 Oct 2003, Martin Stecher wrote: > > Here are a few usage examples from OCP Core: > > > > Uri: atom; > > > > Service: structure { > > Uri; > > }; > > > > Services: list; > > > > And here is how NO message can be declared using the above > > declarations and current message declaration syntax: > > > > name: > > NO > > anonymous parameters: > > Services > > named parameters: > > [sg-id: Uni] > > payload: > > undefined > Some way that allows to show that there are optional named > parameters (none defined by core). > So, that it will allow the HTTP draft to define that > Http-Profile: Service > and that Aux-Parts is a named parameter of that structure. > > Your proposed solution has the disadvantage that NO has Services > parameter, defined as a list of Service and in HTTP there is no > mapping from HTTP-Profile to Service and no hint that NO anonymous > parameter is being changed from Services to Http-Profiles. Yes, I noticed that problem too. In addition to what you mention above, it is bad that Http-Profile has to re-list Uri as a member. Note that documenting with BNF does not solve it since NO message definition still has Services. The only thing I could come up with is inheritance-like approach, which I hesitated to propose as a starting point. For example, in HTTP you would write: Profile: structure { [Aux-Parts: Am-Parts]; [Skip-Parts: Am-Parts]; }; Would that be clear enough? Or would you prefer: Profile: structure Service with { [Aux-Parts: Am-Parts]; [Skip-Parts: Am-Parts]; }; or Profile: extends Service with { [Aux-Parts: Am-Parts]; [Skip-Parts: Am-Parts]; }; Note that since there is only one way to merge anonymous parameters and the order of named parameters is not important, the "inheritance" is simply appending new params to old ones. No multiple inheritance is supported. Note that you can only extend structures, not atoms or lists. Which one would you prefer? Any better ideas? Alex. From owner-ietf-openproxy@mail.imc.org Sat Oct 25 02:04:15 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18609 for ; Sat, 25 Oct 2003 02:04:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADHXC-0001UT-00 for opes-archive@ietf.org; Sat, 25 Oct 2003 02:04:22 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ADHXB-0001UQ-00 for opes-archive@ietf.org; Sat, 25 Oct 2003 02:04:21 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9P5pbI7022397 for ; Fri, 24 Oct 2003 22:51:37 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9P5pbBJ022396 for ietf-openproxy-bks; Fri, 24 Oct 2003 22:51:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9P5pZI7022387 for ; Fri, 24 Oct 2003 22:51:36 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h9P5pdGh076085 for ; Fri, 24 Oct 2003 23:51:39 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9P5pdpn076084; Fri, 24 Oct 2003 23:51:39 -0600 (MDT) (envelope-from rousskov) Date: Fri, 24 Oct 2003 23:51:39 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: OCP: Getting Out Of The Loop optimization broken 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 used to think that Wont-Use parameter is sufficient for a callout server to get out of the loop safely. I now believe that it is not true because Wont-Use can be used to tell the processor that original data is no longer needed, but it does not tell the processor that the service is not going to _generate_ more adapted data. I tried to fix this logic in the new OCP Core section, quoted below. Please see it I am still missing something important or if the interface can be simplified again: 8. 'Out Of The Loop' Optimization Many services are applicable to a small percentage of application messages and yet have to see the beginning of every application message to decide on applicability (e.g., services that adapt based on declared or guessed MIME type). Many services adapt application message "headers" or "prefix" only and are not interested in the remaining parts of an application message (e.g., URL blocking and ad insertion services). 'Getting Out Of The Loop' optimization allows a callout server to get out of application message processing loop when the server is confident that it does not need to see remaining data. Two conditions are necessary for the callout server to get out of the loop nicely: No adaptation need: The callout server must finish its primary work. It should sent all adapted data to the processor and should require no more original data from the processor. Since adaptations and adaptation needs might not depend on original data, only the server can evaluate this condition. No copying need: The OPES processor must receive back all unpreserved data chunks that were sent to the callout server for adaptation. Note that data chunks that are not preserved and are not returned by the callout service would be lost. Since the server may not have seen all the original data sent, only the processor can evaluate this condition. Since no single agent can determine both conditions, the agents have to cooperate. The service has to tell the processor when the first condition is true. This is done via the Want-Out message (XXX: document Want-Out). The processor has to tell the service that there are no pending unpreserved data chunks. The latter is done by terminating the transaction with a 206 "Get Out" result (XXX: document 206). Between the above two conditions or messages, the callout server returns all original data unmodified back to the OPES processor, draining pending data queue (if any). Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Sat Oct 25 02:42: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 CAA27545 for ; Sat, 25 Oct 2003 02:42:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADI8O-0001th-00 for opes-archive@ietf.org; Sat, 25 Oct 2003 02:42:48 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ADI8O-0001te-00 for opes-archive@ietf.org; Sat, 25 Oct 2003 02:42:48 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9P6WoI7033702 for ; Fri, 24 Oct 2003 23:32:50 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9P6Wolo033700 for ietf-openproxy-bks; Fri, 24 Oct 2003 23:32:50 -0700 (PDT) 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 h9P6WmI7033670 for ; Fri, 24 Oct 2003 23:32:49 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id ZYNFI1QRoutgoing id 29BZMLQS; 25 Oct 2003 10:39:58 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: what-parts-to-send-or-skip Date: Sat, 25 Oct 2003 08:32:37 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D01408E@mail.webwasher.com> Thread-Topic: what-parts-to-send-or-skip Thread-Index: AcOaeh2rKjJIwRb2QA6XQQAq8dOITQARuvsA From: "Martin Stecher" To: "OPES WG (E-mail)" , "Alex Rousskov (E-Mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9P6WnI7033692 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi Alex, > > > Last-Needed-Part would address this. But maybe we can add anoter > > parameter "Pause-Offset" to the feature which acts as a data-pause > > pre-request. It requests a first data-paused message after n bytes > > of the original body. > > As with data-pause, OPES processor SHOULD honor this request. > > This will be similar to the Preview feature of ICAP/1.0. > > Good, except for the Offset part. Since the offset is not known a > priory, services that need just headers will have to overprovision on > average but will not get enough sometimes. I think there is a misunderstanding. I do not mean an offset that counts from the beginning of the application message but from the beginning of the body part (request-body in request profile, response-body in response profile). Services only interested in headers, can use Pause-Offset: 0. I see here an advantage for other services too, for example, a service dealing with GIFs may want not only want to check for the Content-Type header but also whether data starts with the three bytes "GIF". It could use Pause-Offset: 3 Martin From owner-ietf-openproxy@mail.imc.org Sat Oct 25 02:52: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 CAA27724 for ; Sat, 25 Oct 2003 02:52:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADIHx-0001y3-00 for opes-archive@ietf.org; Sat, 25 Oct 2003 02:52:41 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ADIHw-0001y0-00 for opes-archive@ietf.org; Sat, 25 Oct 2003 02:52:41 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9P6fMI7035489 for ; Fri, 24 Oct 2003 23:41:22 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9P6fMXi035488 for ietf-openproxy-bks; Fri, 24 Oct 2003 23:41:22 -0700 (PDT) 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 h9P6fKI7035441 for ; Fri, 24 Oct 2003 23:41:20 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id 6XH1ZCA9outgoing id 1CFVH7V9; 25 Oct 2003 10:48:35 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: OCP Core: one service, two profiles Date: Sat, 25 Oct 2003 08:41:14 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D01408F@mail.webwasher.com> Thread-Topic: OCP Core: one service, two profiles Thread-Index: AcOaepxq76WMBcSOROiuE3Ti8w1DWwAR5HMQ From: "Martin Stecher" To: "Alex Rousskov" Cc: "OPES WG (E-Mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9P6fLI7035481 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit You are right. It will produce problems. Highlander principle: There can only be one! > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Saturday, October 25, 2003 12:03 AM > To: Martin Stecher > Cc: OPES WG (E-Mail) > Subject: RE: OCP Core: one service, two profiles > > > On Fri, 24 Oct 2003, Martin Stecher wrote: > > > > We do not explicitly allow or prohibit this, right? Should I > > > explicitly prohibit in the Core? > > > > Maybe we should add to OCP core that only the last negotiated > > profile for a service group is valid. > > Meaning that profile negotiation with SG parameter selects the current > profile? That is, the profile can be changed later? I am not sure I > like this because renegotiation would be messy when there are pending > transactions using the same service group but with the old profile. > The implementation would no longer be able to identify SG properties > based on sg-id. Do you see what I am getting at? > > Alex. > > > ------------------------------------------------------------ > This mail has been scanned by debian3-smtp > (WebWasher 4.4.1 Build 688) > ------------------------------------------------------------ > From owner-ietf-openproxy@mail.imc.org Sat Oct 25 03:00: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 DAA27850 for ; Sat, 25 Oct 2003 03:00:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADIPn-00021s-00 for opes-archive@ietf.org; Sat, 25 Oct 2003 03:00:47 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ADIPn-00021p-00 for opes-archive@ietf.org; Sat, 25 Oct 2003 03:00:47 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9P6oPI7037369 for ; Fri, 24 Oct 2003 23:50:25 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9P6oPvh037367 for ietf-openproxy-bks; Fri, 24 Oct 2003 23:50:25 -0700 (PDT) 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 h9P6oNI7037335 for ; Fri, 24 Oct 2003 23:50:23 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id 6KADPYD2outgoing id T6FV80UT; 25 Oct 2003 10:57:38 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: documenting OCP parameters Date: Sat, 25 Oct 2003 08:50:17 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D0E6649@mail.webwasher.com> Thread-Topic: documenting OCP parameters Thread-Index: AcOafG8JXalje8sYR6O++ajaxrnzaAAR5VNg From: "Martin Stecher" To: "Alex Rousskov" , "OPES WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9P6oOI7037360 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Yes, I noticed that problem too. In addition to what you mention > above, it is bad that Http-Profile has to re-list Uri as a member. > > Note that documenting with BNF does not solve it since NO message > definition still has Services. The only thing I could come up with is > inheritance-like approach, which I hesitated to propose as a starting > point. For example, in HTTP you would write: > > Profile: structure { > [Aux-Parts: Am-Parts]; > [Skip-Parts: Am-Parts]; > }; > > Would that be clear enough? Or would you prefer: > > Profile: structure Service with { > [Aux-Parts: Am-Parts]; > [Skip-Parts: Am-Parts]; > }; > > or > > Profile: extends Service with { > [Aux-Parts: Am-Parts]; > [Skip-Parts: Am-Parts]; > }; > I think, this last option is easiest to understand. Martin From owner-ietf-openproxy@mail.imc.org Sat Oct 25 11:10: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 LAA07841 for ; Sat, 25 Oct 2003 11:10:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADQ3h-0005uk-00 for opes-archive@ietf.org; Sat, 25 Oct 2003 11:10:29 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ADQ3h-0005uh-00 for opes-archive@ietf.org; Sat, 25 Oct 2003 11:10:29 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9PEwLI7001161 for ; Sat, 25 Oct 2003 07:58:21 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9PEwLbA001160 for ietf-openproxy-bks; Sat, 25 Oct 2003 07:58:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9PEwJI7001155 for ; Sat, 25 Oct 2003 07:58:20 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h9PEwLGh091049; Sat, 25 Oct 2003 08:58:21 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9PEwKqw091048; Sat, 25 Oct 2003 08:58:20 -0600 (MDT) (envelope-from rousskov) Date: Sat, 25 Oct 2003 08:58:20 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: RE: documenting OCP parameters In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D0E6649@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D0E6649@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, 25 Oct 2003, Martin Stecher wrote: > > Profile: extends Service with { > > [Aux-Parts: Am-Parts]; > > [Skip-Parts: Am-Parts]; > > }; > > > > I think, this last option is easiest to understand. Agreed, documented, and pushed to the web site. Alex. From owner-ietf-openproxy@mail.imc.org Sat Oct 25 12:35: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 MAA09329 for ; Sat, 25 Oct 2003 12:35:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADRNg-0007E3-00 for opes-archive@ietf.org; Sat, 25 Oct 2003 12:35:12 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ADRNf-0007E0-00 for opes-archive@ietf.org; Sat, 25 Oct 2003 12:35:11 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9PGPcI7003844 for ; Sat, 25 Oct 2003 09:25:38 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9PGPcxK003843 for ietf-openproxy-bks; Sat, 25 Oct 2003 09:25:38 -0700 (PDT) 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 h9PGPXI7003836 for ; Sat, 25 Oct 2003 09:25:36 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id LBGWMJ5Houtgoing id WA7UCN11; 25 Oct 2003 20:32:50 +0200 Received: from jadzia ([217.238.45.14]) by mail.WEBWASHER.COM with Microsoft SMTPSVC(5.0.2195.6713); Sat, 25 Oct 2003 18:25:29 +0200 Message-ID: <005301c39b14$9a5d1ab0$0e2deed9@jadzia> From: "Martin Stecher" To: "Alex Rousskov" , "OPES WG" References: Subject: Re: Getting Out Of The Loop optimization broken Date: Sat, 25 Oct 2003 18:25:27 +0200 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: 25 Oct 2003 16:25:29.0178 (UTC) FILETIME=[9A978BA0:01C39B14] Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > > Hi, > > I used to think that Wont-Use parameter is sufficient for a > callout server to get out of the loop safely. I now believe that it is > not true because Wont-Use can be used to tell the processor that > original data is no longer needed, but it does not tell the processor > that the service is not going to _generate_ more adapted data. I tried > to fix this logic in the new OCP Core section, quoted below. > > Please see it I am still missing something important or if the > interface can be simplified again: > I agree that a Want-Out message is very needed and it's a good idea to have a special status code as result for transaction termination. Question here: Should it be the result of TE or better AME? I think AME fits better. Should the callout server confirm by sending also a special (the same 206) result code? There are three normal cases for transaction termination. We may want to discuss this together in one section of OCP core and define result codes for all three. What do you think? 1. Complete application message is sent to callout server and terminated with AME 200, callout server returns a complete message and also ends with AME 200. 2. At some time callout server decides to only echo the rest of the message. It sends a Want-Out message, echos all data until it receives an AME 206 and then responds also with an AME 206. 3. The callout server sends a response (e.g. an error message for the client). Sending is done before complete application message has been received. The callout server will send its AME message and by design does not longer care about DUM/DUY messages being transferred for this transaction. OPES processor can stop sending the application data when it sees the AME message. It will terminate the transaction. We should also have a special 2xx result for this case, I think. Note, that in cases 1 and 2 the OPES processor sends the AME message first and in case 3 it's the callout server sending AME first. Of course beside these three cases there are other scenarios, but I think they all deal with transaction terminations due to error conditions. Regards Martin From owner-ietf-openproxy@mail.imc.org Sat Oct 25 20:17: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 UAA20622 for ; Sat, 25 Oct 2003 20:17:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADYbZ-0004dU-00 for opes-archive@ietf.org; Sat, 25 Oct 2003 20:18:01 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ADYbY-0004dQ-00 for opes-archive@ietf.org; Sat, 25 Oct 2003 20:18:00 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9Q06nI7020826 for ; Sat, 25 Oct 2003 17:06:49 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9Q06nMP020825 for ietf-openproxy-bks; Sat, 25 Oct 2003 17:06:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9Q06mI7020820 for ; Sat, 25 Oct 2003 17:06:48 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h9Q06oGh004531; Sat, 25 Oct 2003 18:06:50 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9Q06owH004530; Sat, 25 Oct 2003 18:06:50 -0600 (MDT) (envelope-from rousskov) Date: Sat, 25 Oct 2003 18:06:50 -0600 (MDT) From: Alex Rousskov To: "OPES WG (E-mail)" Subject: RE: what-parts-to-send-or-skip In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D01408E@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D01408E@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, 25 Oct 2003, Martin Stecher wrote: > I think there is a misunderstanding. I do not mean an offset that > counts from the beginning of the application message but from the > beginning of the body part (request-body in request profile, > response-body in response profile). Services only interested in > headers, can use Pause-Offset: 0. Yes, I did misunderstood. What you propose is probably better, at least as far as HTTP and similar protocols are concerned. I just find the naming of the parameter misleading. So let's have two parameters: Wont-Use-Body: offset and Pause-At-Body: offset both using offsets from the beginning of a message body. These NR parameters are semantically equivalent to Wont-Use parameter and Data-Pause message already documented in OCP Core (and you should refer to that documentation from the HTTP draft as much as possible instead of repeating it, IMO). From processor implementation point of view, the above parameters become meaningful when the size of headers is known. At that time, the processor should behave as if it received a corresponding Wont-Use parameter and/or Data-Pause message. Alex. From owner-ietf-openproxy@mail.imc.org Sat Oct 25 21:11: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 VAA21847 for ; Sat, 25 Oct 2003 21:11:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADZRm-00059q-00 for opes-archive@ietf.org; Sat, 25 Oct 2003 21:11:58 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ADZRm-00059n-00 for opes-archive@ietf.org; Sat, 25 Oct 2003 21:11:58 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9Q11LI7022153 for ; Sat, 25 Oct 2003 18:01:21 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9Q11Lmi022152 for ietf-openproxy-bks; Sat, 25 Oct 2003 18:01:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9Q11KI7022147 for ; Sat, 25 Oct 2003 18:01:20 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h9Q11MGh005805; Sat, 25 Oct 2003 19:01:22 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9Q11M0m005804; Sat, 25 Oct 2003 19:01:22 -0600 (MDT) (envelope-from rousskov) Date: Sat, 25 Oct 2003 19:01:22 -0600 (MDT) From: Alex Rousskov To: "OPES WG (E-Mail)" Subject: RE: OCP Core: one service, two profiles In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D01408F@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D01408F@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, 25 Oct 2003, Martin Stecher wrote: > You are right. It will produce problems. > Highlander principle: There can only be one! While trying to explicitly fix this, I realized that it is not possible for the Core to say which negotiated features are in conflict (and so only one can be selected for a given service group). For example, HTTP profile does not conflict with support-for-huge-sizes but does conflict with FTP profile. I also realized that we said nothing about conflict resolution between group-scoped and global negotiations. For example, can a connection have HTTP profile while a given group has an SMTP profile? My current answer is no. Specific rules from the draft are quoted below. Negotiating OCP agents have to take into account prior negotiated (i.e., already enabled) features. OCP agents MUST NOT make and MUST reject offers that would lead to a conflict with already negotiated features. For example, an agent cannot offer an HTTP application profile for a connection that already has SMTP application profile enabled because there would be no way to resolve the conflict for a given transaction. Similarly, once TLSv1 connection encryption is negotiated, an agent must not offer and must reject offers for SSLv2 connection encryption. ... An optional "SG" parameter is used to narrow the scope of negotiations to the specified service group. If SG is present, the negotiated features are negotiated and enabled only for transactions that use the specified service group ID. Globally negotiated features are negotiated and enabled for all service groups. When negotiating global features, an agent MUST check for conflicts within each existing service group. When negotiating group-scoped features, an agent MUST check for conflicts with globally negotiated features. For example, it must not be possible to negotiate a global HTTP application profile if one service group has an SMTP application profile and vice versa. OCP agents SHOULD NOT send offers with service groups used by pending transactions. Unless explicitly noted otherwise in a feature documentation, OCP agents MUST NOT apply any negotiations to pending transactions. In other words, negotiated features take effect with the new OCP transaction. We should probably avoid the term "global" in the above. Connection-scoped is probably better. Alex. From owner-ietf-openproxy@mail.imc.org Sat Oct 25 22:11: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 WAA22716 for ; Sat, 25 Oct 2003 22:11:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADaNi-0005Zg-00 for opes-archive@ietf.org; Sat, 25 Oct 2003 22:11:50 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ADaNh-0005Zd-00 for opes-archive@ietf.org; Sat, 25 Oct 2003 22:11:49 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9Q21VI7023905 for ; Sat, 25 Oct 2003 19:01:31 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9Q21VDI023904 for ietf-openproxy-bks; Sat, 25 Oct 2003 19:01:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9Q21TI7023898 for ; Sat, 25 Oct 2003 19:01:30 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h9Q21WGh007164; Sat, 25 Oct 2003 20:01:32 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9Q21WOs007163; Sat, 25 Oct 2003 20:01:32 -0600 (MDT) (envelope-from rousskov) Date: Sat, 25 Oct 2003 20:01:32 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: Re: Getting Out Of The Loop optimization broken In-Reply-To: <005301c39b14$9a5d1ab0$0e2deed9@jadzia> Message-ID: References: <005301c39b14$9a5d1ab0$0e2deed9@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 Sat, 25 Oct 2003, Martin Stecher wrote: > I agree that a Want-Out message is very needed and it's a good idea > to have a special status code as result for transaction termination. > > Question here: Should it be the result of TE or better AME? I think > AME fits better. I agree and will fix the current wording to imply "AME". The following TE will have a "normal" 200 code. However, please note that "I want out of the loop" has a transaction scope, not application message scope. It is not possible to continue the transaction once the server is out of the loop. Proof by contradiction: If it were an application message-scoped mechanism it would be possible to get one application message out of the loop while still processing remaining application messages within the same transaction as usual. The latter is only possible for profiles that support multiple adapted AMs per single original AM (e.g., SMTP). To support such a mode, the processor would have to maintain at least two original data flows: one short-circuited due to Want-Out and one to feed remaining adapted flows. That is probably too much complexity and goes way beyond the current "one transaction, one original data flow" approach. > Should the callout server confirm by sending also a special (the > same 206) result code? Yes, I believe so. Both agents send AMEs/206 and TE/200. If the callout server sends AME/200, it means the adapted application message should stop at that point instead of being continued from the original data flow (i.e, once processor gets AME/200, the loop is over). In other words, "I want out of the loop" does not mean "I am not going to adapt starting now". Imagine a situation where an overloaded non-essential service wants to get out of the loop, but does not mind keeping adaptation algorithms alive (or cannot disable them) and those algorithms decide to terminate the message "early" for reasons unrelated to the overload condition. If you agree with the rationale, I should document the above caveat. > There are three normal cases for transaction termination. We may > want to discuss this together in one section of OCP core and define > result codes for all three. What do you think? > 1. Complete application message is sent to callout server and > terminated with AME 200, callout server returns a complete message > and also ends with AME 200. > > 2. At some time callout server decides to only echo the rest of the > message. It sends a Want-Out message, echos all data until it > receives an AME 206 and then responds also with an AME 206. > > 3. The callout server sends a response (e.g. an error message for > the client). Sending is done before complete application message has > been received. The callout server will send its AME message and by > design does not longer care about DUM/DUY messages being transferred > for this transaction. OPES processor can stop sending the > application data when it sees the AME message. It will terminate the > transaction. In #3, the server will terminate the transaction first: it will send TE right after AME. > We should also have a special 2xx result for this case, I think. Could you explain why a special 2xx result would be needed for #3? To ease statistics collection? Requests, responses, and short-circuiting is application specific. Do you propose to add a special status code to HTTP Adaptations draft? > Note, that in cases 1 and 2 the OPES processor sends the AME message first > and in case 3 it's the callout server sending AME first. > > Of course beside these three cases there are other scenarios, but I > think they all deal with transaction terminations due to error > conditions. If I have time, I will enumerate the above scenarios in a informative (non-normative) way. I have a related question: Do you think a callout server may send AME if it thinks that the message is completed (e.g., the original body has been received and processed, and no trailers are expected)? Or should the server wait for AME from the processor before sending its own AME, under normal conditions? In other words, do we want to support concurrent close optimization OR do we want to allow for larger-than-expected messages to be adapted successfully? In yet other words, what does constitute application message end (AME from the other agent only OR that and some other information like AM-EL)? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Sun Oct 26 14:55: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 OAA25663 for ; Sun, 26 Oct 2003 14:55:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADqzB-0000DP-00 for opes-archive@ietf.org; Sun, 26 Oct 2003 14:55:37 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ADqzA-0000DM-00 for opes-archive@ietf.org; Sun, 26 Oct 2003 14:55: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 h9QJg7I7031222 for ; Sun, 26 Oct 2003 11:42: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 h9QJg7su031221 for ietf-openproxy-bks; Sun, 26 Oct 2003 11:42:07 -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 h9QJg4I7031194 for ; Sun, 26 Oct 2003 11:42:06 -0800 (PST) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id F1YY3ZT4outgoing id FBZOVUTD; 26 Oct 2003 22:49:12 +0100 Received: from jadzia ([10.2.0.70]) by mail.WEBWASHER.COM with Microsoft SMTPSVC(5.0.2195.6713); Sun, 26 Oct 2003 20:41:51 +0100 Message-ID: <001101c39bf0$d1f92bd0$3d23eed9@jadzia> From: "Martin Stecher" To: "Alex Rousskov" , "OPES WG" References: <005301c39b14$9a5d1ab0$0e2deed9@jadzia> Subject: Re: Getting Out Of The Loop optimization broken Date: Sun, 26 Oct 2003 19:41: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: 26 Oct 2003 19:41:51.0220 (UTC) FILETIME=[33A63B40:01C39BF9] Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > > I agree and will fix the current wording to imply "AME". The following > TE will have a "normal" 200 code. > > However, please note that "I want out of the loop" has a transaction > scope, not application message scope. It is not possible to continue > the transaction once the server is out of the loop. > > Proof by contradiction: If it were an application message-scoped > mechanism it would be possible to get one application message out of > the loop while still processing remaining application messages within > the same transaction as usual. The latter is only possible for > profiles that support multiple adapted AMs per single original AM > (e.g., SMTP). To support such a mode, the processor would have to > maintain at least two original data flows: one short-circuited due to > Want-Out and one to feed remaining adapted flows. That is probably too > much complexity and goes way beyond the current "one transaction, one > original data flow" approach. > Correct. But in future we may have a message that could be sent between AME and TE, maybe a message with which the OPES processor informs the callout service about the shutdown procedure on the application message size. In this case the callout server wants to get out of the loop for the application message but keeps the transaction alive until it receives the additional meta info. Therefore, as we already ageed upon, put the result code to AME and we are better prepared for future extensions. > > Should the callout server confirm by sending also a special (the > > same 206) result code? > > Yes, I believe so. Both agents send AMEs/206 and TE/200. If the > callout server sends AME/200, it means the adapted application message > should stop at that point instead of being continued from the original > data flow (i.e, once processor gets AME/200, the loop is over). > Agreed. > In other words, "I want out of the loop" does not mean "I am not going > to adapt starting now". Imagine a situation where an overloaded > non-essential service wants to get out of the loop, but does not mind > keeping adaptation algorithms alive (or cannot disable them) and those > algorithms decide to terminate the message "early" for reasons > unrelated to the overload condition. > > If you agree with the rationale, I should document the above caveat. > > > There are three normal cases for transaction termination. We may > > want to discuss this together in one section of OCP core and define > > result codes for all three. What do you think? > > > 1. Complete application message is sent to callout server and > > terminated with AME 200, callout server returns a complete message > > and also ends with AME 200. > > > > 2. At some time callout server decides to only echo the rest of the > > message. It sends a Want-Out message, echos all data until it > > receives an AME 206 and then responds also with an AME 206. > > > > 3. The callout server sends a response (e.g. an error message for > > the client). Sending is done before complete application message has > > been received. The callout server will send its AME message and by > > design does not longer care about DUM/DUY messages being transferred > > for this transaction. OPES processor can stop sending the > > application data when it sees the AME message. It will terminate the > > transaction. > > In #3, the server will terminate the transaction first: it will send > TE right after AME. For SMTP maybe not immediatly. See below. > > > We should also have a special 2xx result for this case, I think. > > Could you explain why a special 2xx result would be needed for #3? > To ease statistics collection? Requests, responses, > and short-circuiting is application specific. Do you propose to add > a special status code to HTTP Adaptations draft? For HTTP this special code is not needed for direct functionality but for better statisticy and debugging possibilities: If the OPES processor wants to count for cases #3 a special result code will even count then for the case in which both AMEs are sent simultaniously. If in a debugging session someone checks the data sent by the OPES processor (not seeing the data sent by the callout server), he may wonder that an application message is not sent completly. A result code other than 200 with the AME message, will help to understand why. For other application protocols, such as SMTP, the special code sent by the callout service can even make functional sense. A service may want to send several error messages, all not longer depending on the rest of the application data, to multiple recipient and therefore it will send several application messages. By indicating with the first AME that the OPES processor can stop sending more application data it helps to increase performance. This case will be different from an error message which is sent in the first application message but another application message which builds on the complete original message will follow; in that case, the callout server will send a result 200 with the first AME. If you agree in all this, I would prefer to have some general status codes for the three cases in OCP core. > > > Note, that in cases 1 and 2 the OPES processor sends the AME message first > > and in case 3 it's the callout server sending AME first. > > > > Of course beside these three cases there are other scenarios, but I > > think they all deal with transaction terminations due to error > > conditions. > > If I have time, I will enumerate the above scenarios in a informative > (non-normative) way. > > I have a related question: Do you think a callout server may send AME > if it thinks that the message is completed (e.g., the original body > has been received and processed, and no trailers are expected)? Or > should the server wait for AME from the processor before sending its > own AME, under normal conditions? In other words, do we want to > support concurrent close optimization OR do we want to allow for > larger-than-expected messages to be adapted successfully? In yet other > words, what does constitute application message end (AME from the > other agent only OR that and some other information like AM-EL)? Simulatanious AMEs are possible as you discribe but I would like to discourage their usage. Implementations that want to have max performance can probably add the AME and TE messages to the same TCP frame that contains the last DUM in most cases (unless the few bytes for AME/TE do not fit). In this case we have no extra waiting after the last DUM message has been received and there is no need for clever counting which may sometimes lead to problems. The length of an application message SHOULD only be determined by the length of the DUM message's payload (and the DUY message's size param) and terminated by the AME message. AM-EL values are important for better HTTP adaption but they SHOULD NOT be used for message length counting for OCP purposes, IMO. Regards Martin > From owner-ietf-openproxy@mail.imc.org Sun Oct 26 15:40:11 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27868 for ; Sun, 26 Oct 2003 15:40:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADrgT-0000ZV-00 for opes-archive@ietf.org; Sun, 26 Oct 2003 15:40:22 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ADrgT-0000ZR-00 for opes-archive@ietf.org; Sun, 26 Oct 2003 15:40: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 h9QKTRI7033236 for ; Sun, 26 Oct 2003 12:29: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 h9QKTRXv033235 for ietf-openproxy-bks; Sun, 26 Oct 2003 12:29:27 -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 h9QKTPI7033223 for ; Sun, 26 Oct 2003 12:29:25 -0800 (PST) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id SQJQR286outgoing id HA6Y2L7C; 26 Oct 2003 23:36:43 +0100 Received: from jadzia ([10.2.0.70]) by mail.WEBWASHER.COM with Microsoft SMTPSVC(5.0.2195.6713); Sun, 26 Oct 2003 21:29:21 +0100 Message-ID: <002701c39bff$d9f31c60$3d23eed9@jadzia> From: "Martin Stecher" To: "Alex Rousskov" , "OPES WG \(E-mail\)" References: <75F7E67FC45F6744A7D328D41E35376D01408E@mail.webwasher.com> Subject: Re: what-parts-to-send-or-skip Date: Sun, 26 Oct 2003 21:29:26 +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: 26 Oct 2003 20:29:21.0504 (UTC) FILETIME=[D68D0E00:01C39BFF] Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > > > I think there is a misunderstanding. I do not mean an offset that > > counts from the beginning of the application message but from the > > beginning of the body part (request-body in request profile, > > response-body in response profile). Services only interested in > > headers, can use Pause-Offset: 0. > > Yes, I did misunderstood. What you propose is probably better, at > least as far as HTTP and similar protocols are concerned. I just find > the naming of the parameter misleading. So let's have two parameters: > Wont-Use-Body: offset > and > Pause-At-Body: offset > both using offsets from the beginning of a message body. These NR > parameters are semantically equivalent to Wont-Use parameter and > Data-Pause message already documented in OCP Core (and you should > refer to that documentation from the HTTP draft as much as possible > instead of repeating it, IMO). Agreed. > > From processor implementation point of view, the above parameters > become meaningful when the size of headers is known. At that time, the > processor should behave as if it received a corresponding Wont-Use > parameter and/or Data-Pause message. That seems to work for the Pause-At-Body parameter but makes less sense for Wont-Use-Body. This parameter is not like a DUY/DUM message that comes with Won-Use after the n bytes of a body but can be seen as a DUM message with empty payload but Wont-Use parameter that is sent at the very beginning of the application message to indicate that it will not send a DUY message for the first n bytes. It does not terminate the preservation commitment, but it tells the OPES processor that it does not need to preserve the first n bytes of the message. I expect to see only one value in real life: Wont-Use-Body: 2147483647 to indicate that the callout service will never send DUY messages. But maybe other scenarios can be found. Martin From owner-ietf-openproxy@mail.imc.org Sun Oct 26 16:41:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28929 for ; Sun, 26 Oct 2003 16:41:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADsdL-00011Q-00 for opes-archive@ietf.org; Sun, 26 Oct 2003 16:41:11 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ADsdK-00011N-00 for opes-archive@ietf.org; Sun, 26 Oct 2003 16:41: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 h9QLUrI7035638 for ; Sun, 26 Oct 2003 13:30: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 h9QLUrmx035637 for ietf-openproxy-bks; Sun, 26 Oct 2003 13:30: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 h9QLUpI7035632 for ; Sun, 26 Oct 2003 13:30: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 h9QLUrGh033789; Sun, 26 Oct 2003 14:30: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 h9QLUrqo033788; Sun, 26 Oct 2003 14:30:53 -0700 (MST) (envelope-from rousskov) Date: Sun, 26 Oct 2003 14:30:53 -0700 (MST) From: Alex Rousskov To: Martin Stecher cc: OPES WG Subject: Re: Getting Out Of The Loop optimization broken In-Reply-To: <001101c39bf0$d1f92bd0$3d23eed9@jadzia> Message-ID: References: <005301c39b14$9a5d1ab0$0e2deed9@jadzia> <001101c39bf0$d1f92bd0$3d23eed9@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 Sun, 26 Oct 2003, Martin Stecher wrote: > > > There are three normal cases for transaction termination. We may > > > want to discuss this together in one section of OCP core and > > > define result codes for all three. What do you think? > > > > > 1. Complete application message is sent to callout server and > > > terminated with AME 200, callout server returns a complete > > > message and also ends with AME 200. > > > > > > 2. At some time callout server decides to only echo the rest of > > > the message. It sends a Want-Out message, echos all data until > > > it receives an AME 206 and then responds also with an AME 206. > > > > > > 3. The callout server sends a response (e.g. an error message > > > for the client). Sending is done before complete application > > > message has been received. The callout server will send its AME > > > message and by design does not longer care about DUM/DUY > > > messages being transferred for this transaction. OPES processor > > > can stop sending the application data when it sees the AME > > > message. It will terminate the transaction. > > > > In #3, the server will terminate the transaction first: it will > > send TE right after AME. > > For SMTP maybe not immediatly. See below. Yes, I assumed single adapted AM above. > For HTTP this special code is not needed for direct functionality > but for better statisticy and debugging possibilities: If the OPES > processor wants to count for cases #3 a special result code will > even count then for the case in which both AMEs are sent > simultaniously. If in a debugging session someone checks the data > sent by the OPES processor (not seeing the data sent by the callout > server), he may wonder that an application message is not sent > completly. A result code other than 200 with the AME message, will > help to understand why. Agreed. > For other application protocols, such as SMTP, the special code sent > by the callout service can even make functional sense. A service may > want to send several error messages, all not longer depending on the > rest of the application data, to multiple recipient and therefore it > will send several application messages. By indicating with the first > AME that the OPES processor can stop sending more application data > it helps to increase performance. It looks like you want one adapted AME status code affect behavior of other adapted application messages (whether they are going to receive more original data). I think a better interface would be to have a special "Wont-Use" message with a transaction scope, to indicate that more original data is not needed. Hmm... It looks like we really do not have a good enough interface to control original data flow in the case of multiple adapted messages. It is currently not clear whether a single adapted flow statement like Wont-Use parameter applies to original data flow (and hence affects other adapted messages) or just to the adapted flow making a statement. If we ever end up supporting multiple adapted application messages, we would have to make all of that clear and consistent. For now, it looks like we assume that there is always a single original flow, regardless of the number of adapted flows. Perhaps it is the right decision (because it is simple), but it is hard to say without digging into SMTP specifics. On the other hand, we stick parameters like Wont-Use into am-id-dependent messages as if we imply that two adapted flows may have different Wont-Use statements. Do you think we should move all parameters that apply to the original flow from am-id-specific messages to xid-specific messages? For consistency reasons? Or do you think we will eventually require processor to merge all such parameters together before deciding what to do with the original flow? In other words, who is responsible for merging adapted flows' interests into one statement affecting original flow, the server or the processor? > This case will be different from an error message which is sent in > the first application message but another application message which > builds on the complete original message will follow; in that case, > the callout server will send a result 200 with the first AME. Agreed. > If you agree in all this, I would prefer to have some general status codes > for the three cases in OCP core. I think I can and should document 206 code in Core. However, I am not sure how to document the "short circuit" code in the Core. The Core cannot assume that an application protocol has requests/responses and, hence, cannot document something like a "Respond with this response instead of forwarding original request" code. If I try to be generic and document the code as something like "adapted message is not intended for the original message recipient", we might raise red flags for those who think that IAB "OPES must not resolve URIs" concern applies in this case. Suggestions? Also, should we use 207 as the value for this short-circuit code? Or does some HTTP extension use that code? We do not have to avoid all conflicts with HTTP, but it would be nice to avoid same codes naming very different things. > The length of an application message SHOULD only be determined by > the length of the DUM message's payload (and the DUY message's size > param) and terminated by the AME message. AM-EL values are important > for better HTTP adaption but they SHOULD NOT be used for message > length counting for OCP purposes, IMO. I agree in principle, and we already have a MUST that instructs agents to send AMEs immediately. Alex. From owner-ietf-openproxy@mail.imc.org Sun Oct 26 17:11:06 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29672 for ; Sun, 26 Oct 2003 17:11:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADt6T-0001KU-00 for opes-archive@ietf.org; Sun, 26 Oct 2003 17:11:17 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ADt6S-0001KP-00 for opes-archive@ietf.org; Sun, 26 Oct 2003 17:11: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 h9QLxgI7036823 for ; Sun, 26 Oct 2003 13:59:42 -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 h9QLxgjk036822 for ietf-openproxy-bks; Sun, 26 Oct 2003 13:59:42 -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 h9QLxeI7036817 for ; Sun, 26 Oct 2003 13:59:41 -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 h9QLxhGh034448; Sun, 26 Oct 2003 14:59:43 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9QLxg1Z034447; Sun, 26 Oct 2003 14:59:42 -0700 (MST) (envelope-from rousskov) Date: Sun, 26 Oct 2003 14:59:42 -0700 (MST) From: Alex Rousskov To: Martin Stecher cc: "OPES WG (E-mail)" Subject: Re: what-parts-to-send-or-skip In-Reply-To: <002701c39bff$d9f31c60$3d23eed9@jadzia> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D01408E@mail.webwasher.com> <002701c39bff$d9f31c60$3d23eed9@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 Sun, 26 Oct 2003, Martin Stecher wrote: > That seems to work for the Pause-At-Body parameter but makes less > sense for Wont-Use-Body. This parameter is not like a DUY/DUM > message that comes with Won-Use after the n bytes of a body but can > be seen as a DUM message with empty payload but Wont-Use parameter Agreed up to this point. > that is sent at the very beginning of the application message I would think it can be sent only after the original headers were sent so that header size is known. > to indicate that it will not send a DUY message for the first n > bytes. and here we have a problem: I thought that Wont-Use in NR indicates that the server does not want to see those body bytes at all! Otherwise, it should use Pause-After. Not only Wont-Use tells the processor that preserving those bytes for this service is a waste, but that _sending_ those bytes is a waste. The processor SHOULD terminate the message with AME/206 after sending all original bytes up to the Wont-Use point. Right? In other words, does "will not use" mean "will not even look at" OR "will not send back as-is"? Hmm... I think it means the former when sent as a part of a NR response (a Wont-Use-Body parameter) and it means the latter when sent as a part of a Wont-Use message! That's bad. We should rename. How about: Wont-Send (to stop preservation commitment, former Wont-Use) Wont-Look (to stop original data flow) I would propose to call the first one "Dont-Keep" but I prefer to state the sending agent state/decision rather than instruct the other agent on want to do. There may be external reasons for processor to continue to keep that data. Do you agree that we need one semantics for NR and another for preservation commitment management? If you do, I would rename Wont-Use and add Wont-Look to OCP Core so that you can refer to them from the HTTP draft. > It does not terminate the preservation commitment, but it tells the > OPES processor that it does not need to preserve the first n bytes > of the message. I expect to see only one value in real life: > Wont-Use-Body: 2147483647 > to indicate that the callout service will never send DUY messages. > But maybe other scenarios can be found. I think the most common scenario for URL blocking services would be to send (in NR) Wont-Look-Body: 2147483647 rather than Wont-Send-Body: 2147483647 While services that rewrite content in a significant way would use Wont-Send 2147483647 OCP message or Wont-Send-Body NR parameter. Alex. From owner-ietf-openproxy@mail.imc.org Sun Oct 26 17:19: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 RAA29982 for ; Sun, 26 Oct 2003 17:19:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADtEI-0001Ps-00 for opes-archive@ietf.org; Sun, 26 Oct 2003 17:19:23 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ADtEI-0001Pp-00 for opes-archive@ietf.org; Sun, 26 Oct 2003 17:19:22 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9QMAuI7037382 for ; Sun, 26 Oct 2003 14:10:56 -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 h9QMAuia037381 for ietf-openproxy-bks; Sun, 26 Oct 2003 14:10:56 -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 h9QMAtI7037375 for ; Sun, 26 Oct 2003 14:10:55 -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 h9QMAvGh034671 for ; Sun, 26 Oct 2003 15:10:57 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9QMAvZ4034670; Sun, 26 Oct 2003 15:10:57 -0700 (MST) (envelope-from rousskov) Date: Sun, 26 Oct 2003 15:10:57 -0700 (MST) From: Alex Rousskov To: OPES WG Subject: OCP: maximum size 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: OCP limits various sizes to 2147483647 which is the maximum signed "native" integer on most systems. This is done to simplify parsing and to reduce the number of size-related vulnerabilities. Implementations can negotiate support for larger sizes, of course. Is some situations, an agent may want to say "until the end" or "maximum supported size" when sending a size- or an offset-related parameter value. Is it worth introducing a "max" syntax token so that implementations would not have to resort to using 2147483647 constant and risk of running into interoperability problems with implementations that unilaterally enable support for larger sizes (or implementations that silently support smaller sizes only)? A "max" token would mean "maximum supported size", essentially. This will complicate parsing a little because parsers would have to handle "max" as a special case, of course: size = "max" / 1*DIGIT Are any protocols using a similar mechanism? Alex. From owner-ietf-openproxy@mail.imc.org Sun Oct 26 17: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 RAA01802 for ; Sun, 26 Oct 2003 17:33:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADtSI-0001oa-00 for opes-archive@ietf.org; Sun, 26 Oct 2003 17:33:51 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ADtSF-0001oX-00 for opes-archive@ietf.org; Sun, 26 Oct 2003 17:33: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 h9QMM8I7037968 for ; Sun, 26 Oct 2003 14:22:08 -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 h9QMM8tO037967 for ietf-openproxy-bks; Sun, 26 Oct 2003 14:22:08 -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 h9QMM6I7037958 for ; Sun, 26 Oct 2003 14:22:06 -0800 (PST) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id WF1OGQA8outgoing id 0OZ3J12B; 27 Oct 2003 01:29:24 +0100 Received: from jadzia ([10.2.0.70]) by mail.WEBWASHER.COM with Microsoft SMTPSVC(5.0.2195.6713); Sun, 26 Oct 2003 23:22:02 +0100 Message-ID: <003301c39c0f$983b9530$3d23eed9@jadzia> From: "Martin Stecher" To: "Alex Rousskov" , "OPES WG" References: <75F7E67FC45F6744A7D328D41E35376D0E6649@mail.webwasher.com> Subject: Re: documenting OCP parameters Date: Sun, 26 Oct 2003 23:22:07 +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: 26 Oct 2003 22:22:02.0875 (UTC) FILETIME=[94A464B0:01C39C0F] Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Alex, I am changing parameter definitions to TDM. This is what I have so far: am-part: extends atom; am-parts: extends list am-part; HTTP-Profile: extends Feature with { [Aux-Parts: am-parts]; [Wont-Use-Body: size]; [Pause-At-Body: size]; [Content-Encodings: codings]; }; Is this correct? In order to define which tokens are defined as the am-part atoms, may I still write: am-part = "request-header" / "request-body" / "request-trailer" / "response-header" / "response-body" / "response-trailer" in addition to the above? And what is codings now? Is it actually a list of tokens, as we used it so far or a list of quoted-values? Or is it just a list of atoms and implementations decide whether bare-values work here? Regards Martin ----- Original Message ----- From: "Alex Rousskov" To: "OPES WG" Sent: Saturday, October 25, 2003 3:58 PM Subject: RE: documenting OCP parameters > > On Sat, 25 Oct 2003, Martin Stecher wrote: > > > > Profile: extends Service with { > > > [Aux-Parts: Am-Parts]; > > > [Skip-Parts: Am-Parts]; > > > }; > > > > > > > I think, this last option is easiest to understand. > > Agreed, documented, and pushed to the web site. > > Alex. > > ------------------------------------------------------------ > This mail has been scanned by debian3-smtp > (WebWasher 4.4.1 Build 688) > ------------------------------------------------------------ > From owner-ietf-openproxy@mail.imc.org Sun Oct 26 17:46: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 RAA02618 for ; Sun, 26 Oct 2003 17:46:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADtem-00022g-00 for opes-archive@ietf.org; Sun, 26 Oct 2003 17:46:45 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ADtem-00022d-00 for opes-archive@ietf.org; Sun, 26 Oct 2003 17:46:44 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9QMaRI7038313 for ; Sun, 26 Oct 2003 14:36: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 h9QMaRAo038312 for ietf-openproxy-bks; Sun, 26 Oct 2003 14:36: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 h9QMaPI7038307 for ; Sun, 26 Oct 2003 14:36: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 h9QMaRGh035327; Sun, 26 Oct 2003 15:36:27 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9QMaRom035326; Sun, 26 Oct 2003 15:36:27 -0700 (MST) (envelope-from rousskov) Date: Sun, 26 Oct 2003 15:36:27 -0700 (MST) From: Alex Rousskov To: Martin Stecher cc: OPES WG Subject: Re: documenting OCP parameters In-Reply-To: <003301c39c0f$983b9530$3d23eed9@jadzia> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D0E6649@mail.webwasher.com> <003301c39c0f$983b9530$3d23eed9@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 Sun, 26 Oct 2003, Martin Stecher wrote: > I am changing parameter definitions to TDM. This is what I have so far: > > am-part: extends atom; Yes. > am-parts: extends list am-part; This looks awkward, does not it? How about: am-parts: extends list of am-part; > HTTP-Profile: extends Feature with { > [Aux-Parts: am-parts]; > [Wont-Use-Body: size]; > [Pause-At-Body: size]; > [Content-Encodings: codings]; > }; Yes. Should we use capital letters for types (Am-Parts rather than am-part)? I do in OCP Core (e.g., "Feature" not "feature") but can change to small letters if you prefer. > In order to define which tokens are defined as the am-part atoms, may I > still write: > am-part = "request-header" > / "request-body" > / "request-trailer" > / "response-header" > / "response-body" > / "response-trailer" > in addition to the above? I would render the above as a list in the text: This specification documents the following am-part values: HTTP request headers including ... as defined in ... ... Or you can use a table (see texttable in P draft). It is a semantic requirement, and the type can support extensions (or not, depending on how you document it). > And what is codings now? Is it actually a list of tokens, as we used > it so far or a list of quoted-values? Or is it just a list of atoms > and implementations decide whether bare-values work here? A list of atoms. Or a list of "coding", where coding extends atom with some semantic properties. OCP does not distinguish quoted and unquoted values on a semantical level. HTH, Alex. From owner-ietf-openproxy@mail.imc.org Sun Oct 26 17:56:14 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02815 for ; Sun, 26 Oct 2003 17:56:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADto8-00025o-00 for opes-archive@ietf.org; Sun, 26 Oct 2003 17:56:24 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ADto8-00025l-00 for opes-archive@ietf.org; Sun, 26 Oct 2003 17:56:24 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9QMffI7038512 for ; Sun, 26 Oct 2003 14:41: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 h9QMff2F038511 for ietf-openproxy-bks; Sun, 26 Oct 2003 14:41: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 h9QMfcI7038506 for ; Sun, 26 Oct 2003 14:41:39 -0800 (PST) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id Y61LSOJCoutgoing id 2TPYNTHA; 27 Oct 2003 01:48:57 +0100 Received: from jadzia ([10.2.0.70]) by mail.WEBWASHER.COM with Microsoft SMTPSVC(5.0.2195.6713); Sun, 26 Oct 2003 23:41:35 +0100 Message-ID: <004201c39c12$534f34b0$3d23eed9@jadzia> From: "Martin Stecher" To: "Alex Rousskov" Cc: "OPES WG \(E-mail\)" References: <75F7E67FC45F6744A7D328D41E35376D01408E@mail.webwasher.com> <002701c39bff$d9f31c60$3d23eed9@jadzia> Subject: Re: what-parts-to-send-or-skip Date: Sun, 26 Oct 2003 23:41:40 +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: 26 Oct 2003 22:41:35.0664 (UTC) FILETIME=[4FADCB00:01C39C12] Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > > > That seems to work for the Pause-At-Body parameter but makes less > > sense for Wont-Use-Body. This parameter is not like a DUY/DUM > > message that comes with Won-Use after the n bytes of a body but can > > be seen as a DUM message with empty payload but Wont-Use parameter > > Agreed up to this point. > > > that is sent at the very beginning of the application message > > I would think it can be sent only after the original headers were sent > so that header size is known. > > > to indicate that it will not send a DUY message for the first n > > bytes. > > and here we have a problem: > > I thought that Wont-Use in NR indicates that the server does not want > to see those body bytes at all! Otherwise, it should use Pause-After. > Not only Wont-Use tells the processor that preserving those bytes for > this service is a waste, but that _sending_ those bytes is a waste. > The processor SHOULD terminate the message with AME/206 after sending > all original bytes up to the Wont-Use point. Right? > Great, you had one feature in mind but the name and the "does the same as the corresponding name of the core" brought me to create a different feature ;-) It's also nice, because it could allow for preservation commitment optimization. > In other words, does "will not use" mean "will not even look at" OR > "will not send back as-is"? > > Hmm... I think it means the former when sent as a part of a NR > response (a Wont-Use-Body parameter) and it means the latter when sent > as a part of a Wont-Use message! That's bad. We should rename. How > about: > > Wont-Send (to stop preservation commitment, former Wont-Use) > Wont-Look (to stop original data flow) > > I would propose to call the first one "Dont-Keep" but I prefer to > state the sending agent state/decision rather than instruct the other > agent on want to do. There may be external reasons for processor to > continue to keep that data. Yes. It just allows for optimizations but it does not enforce it. > > Do you agree that we need one semantics for NR and another for > preservation commitment management? If you do, I would rename > Wont-Use and add Wont-Look to OCP Core so that you can refer to them > from the HTTP draft. It's not yet too late to do these changes ;-) Wont-Use will become Wont-Send and Wont-Look will be new. BTW: Can I make a XML xref to the section in core (without hard coding the section number) so that possible changes in ordering are reflected? > > > It does not terminate the preservation commitment, but it tells the > > OPES processor that it does not need to preserve the first n bytes > > of the message. I expect to see only one value in real life: > > Wont-Use-Body: 2147483647 > > to indicate that the callout service will never send DUY messages. > > But maybe other scenarios can be found. > > I think the most common scenario for URL blocking services would be > to send (in NR) > > Wont-Look-Body: 2147483647 > rather than > Wont-Send-Body: 2147483647 Yes! > > While services that rewrite content in a significant way would use > Wont-Send 2147483647 > OCP message or Wont-Send-Body NR parameter. What is now the Wont-Send OCP message? You mean Wont-Send parameter in DUM message, right? Regards Martin From owner-ietf-openproxy@mail.imc.org Sun Oct 26 18:09: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 SAA03654 for ; Sun, 26 Oct 2003 18:09:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADu11-0002Cg-00 for opes-archive@ietf.org; Sun, 26 Oct 2003 18:09:43 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ADu10-0002Cc-00 for opes-archive@ietf.org; Sun, 26 Oct 2003 18:09:42 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9QMurI7039470 for ; Sun, 26 Oct 2003 14:56: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 h9QMurhg039469 for ietf-openproxy-bks; Sun, 26 Oct 2003 14:56:53 -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 h9QMupI7039436 for ; Sun, 26 Oct 2003 14:56:51 -0800 (PST) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id ICL7Y00Eoutgoing id ALXNGB4Q; 27 Oct 2003 02:04:09 +0100 Received: from jadzia ([10.2.0.70]) by mail.WEBWASHER.COM with Microsoft SMTPSVC(5.0.2195.6713); Sun, 26 Oct 2003 23:56:47 +0100 Message-ID: <004901c39c14$7330e8d0$3d23eed9@jadzia> From: "Martin Stecher" To: "Alex Rousskov" Cc: "OPES WG" References: <75F7E67FC45F6744A7D328D41E35376D0E6649@mail.webwasher.com> <003301c39c0f$983b9530$3d23eed9@jadzia> Subject: Re: documenting OCP parameters Date: Sun, 26 Oct 2003 23:56:53 +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: 26 Oct 2003 22:56:48.0107 (UTC) FILETIME=[6F898BB0:01C39C14] Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > > > am-parts: extends list am-part; > > This looks awkward, does not it? How about: > > am-parts: extends list of am-part; ok. > > Should we use capital letters for types (Am-Parts rather than > am-part)? I do in OCP Core (e.g., "Feature" not "feature") but can > change to small letters if you prefer. In 3.1 everything is lowercase. In section 9 we have uppercase and in section 10 we have a mixture (bad that section title and text differ). I think it looks well, if named parameter's names start with a capital letter but type names are lowercase; then you know that the lowercase things will be replaced by s.th. else while the capital words stay. > > > > In order to define which tokens are defined as the am-part atoms, may I > > still write: > > am-part = "request-header" > > / "request-body" > > / "request-trailer" > > / "response-header" > > / "response-body" > > / "response-trailer" > > in addition to the above? > > I would render the above as a list in the text: > > This specification documents the following am-part > values: > > > HTTP request headers > including ... as defined in ... > ... > > ok. Thanks. > > Or you can use a table (see texttable in P draft). > > It is a semantic requirement, and the type can support extensions (or > not, depending on how you document it). > > > And what is codings now? Is it actually a list of tokens, as we used > > it so far or a list of quoted-values? Or is it just a list of atoms > > and implementations decide whether bare-values work here? > > A list of atoms. Or a list of "coding", where coding extends atom with > some semantic properties. I will then use: content-coding: extends atom; content-codings: extends list of content-coding; The semantics of content-coding is defined in section 3.5 of Thank you Martin From owner-ietf-openproxy@mail.imc.org Sun Oct 26 18:38:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04920 for ; Sun, 26 Oct 2003 18:38:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADuSZ-0002Wb-00 for opes-archive@ietf.org; Sun, 26 Oct 2003 18:38:12 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ADuSY-0002WY-00 for opes-archive@ietf.org; Sun, 26 Oct 2003 18:38: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 h9QNRTI7041840 for ; Sun, 26 Oct 2003 15:27:29 -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 h9QNRTkM041838 for ietf-openproxy-bks; Sun, 26 Oct 2003 15:27:29 -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 h9QNRRI7041831 for ; Sun, 26 Oct 2003 15:27:27 -0800 (PST) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id IZ27J1UYoutgoing id 0BMTBEHG; 27 Oct 2003 02:34:45 +0100 Received: from jadzia ([10.2.0.70]) by mail.WEBWASHER.COM with Microsoft SMTPSVC(5.0.2195.6713); Mon, 27 Oct 2003 00:27:23 +0100 Message-ID: <006001c39c18$b90c8720$3d23eed9@jadzia> From: "Martin Stecher" To: "Martin Stecher" , "Alex Rousskov" Cc: "OPES WG \(E-mail\)" References: <75F7E67FC45F6744A7D328D41E35376D01408E@mail.webwasher.com> <002701c39bff$d9f31c60$3d23eed9@jadzia> <004201c39c12$534f34b0$3d23eed9@jadzia> Subject: Re: what-parts-to-send-or-skip Date: Mon, 27 Oct 2003 00:27:28 +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: 26 Oct 2003 23:27:23.0213 (UTC) FILETIME=[B5587FD0:01C39C18] Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > > > > While services that rewrite content in a significant way would use > > Wont-Send 2147483647 > > OCP message or Wont-Send-Body NR parameter. > > What is now the Wont-Send OCP message? Aaah, just found it in your other message (didn't read it before). I will respond to that mail (Wont-Send message is a good idea). Martin From owner-ietf-openproxy@mail.imc.org Sun Oct 26 18:52: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 SAA05252 for ; Sun, 26 Oct 2003 18:52:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADuh1-0002lx-00 for opes-archive@ietf.org; Sun, 26 Oct 2003 18:53:07 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ADuh0-0002ln-00 for opes-archive@ietf.org; Sun, 26 Oct 2003 18:53: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 h9QNeCI7042969 for ; Sun, 26 Oct 2003 15:40: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 h9QNeCDH042968 for ietf-openproxy-bks; Sun, 26 Oct 2003 15:40:12 -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 h9QNe9I7042959 for ; Sun, 26 Oct 2003 15:40:10 -0800 (PST) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id CS3Q1582outgoing id 16FZI6TG; 27 Oct 2003 02:47:28 +0100 Received: from jadzia ([10.2.0.70]) by mail.WEBWASHER.COM with Microsoft SMTPSVC(5.0.2195.6713); Mon, 27 Oct 2003 00:40:06 +0100 Message-ID: <006701c39c1a$80072320$3d23eed9@jadzia> From: "Martin Stecher" To: "Alex Rousskov" Cc: "OPES WG" References: <005301c39b14$9a5d1ab0$0e2deed9@jadzia> <001101c39bf0$d1f92bd0$3d23eed9@jadzia> Subject: Re: Getting Out Of The Loop optimization broken Date: Mon, 27 Oct 2003 00:40:11 +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: 26 Oct 2003 23:40:06.0499 (UTC) FILETIME=[7C4CB330:01C39C1A] Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > > For other application protocols, such as SMTP, the special code sent > > by the callout service can even make functional sense. A service may > > want to send several error messages, all not longer depending on the > > rest of the application data, to multiple recipient and therefore it > > will send several application messages. By indicating with the first > > AME that the OPES processor can stop sending more application data > > it helps to increase performance. > > It looks like you want one adapted AME status code affect behavior of > other adapted application messages (whether they are going to receive > more original data). I think a better interface would be to have a > special "Wont-Use" message with a transaction scope, to indicate that > more original data is not needed. Here is the new message. I found it :-) > Hmm... It looks like we really do > not have a good enough interface to control original data flow in the > case of multiple adapted messages. It is currently not clear whether a > single adapted flow statement like Wont-Use parameter applies to > original data flow (and hence affects other adapted messages) or just > to the adapted flow making a statement. If we ever end up supporting > multiple adapted application messages, we would have to make all of > that clear and consistent. > > For now, it looks like we assume that there is always a single > original flow, regardless of the number of adapted flows. Perhaps it > is the right decision (because it is simple), but it is hard to say > without digging into SMTP specifics. On the other hand, we stick > parameters like Wont-Use into am-id-dependent messages as if we imply > that two adapted flows may have different Wont-Use statements. > > Do you think we should move all parameters that apply to the original > flow from am-id-specific messages to xid-specific messages? For > consistency reasons? Yes, it makes a lot of sense. Please introduce Wont-Send message and remove the parameter from DUM/DUY. >Or do you think we will eventually require > processor to merge all such parameters together before deciding what > to do with the original flow? Will be a night-mare and probably end with interop-problems as expectations at OPES processor side will probably be too easy. >In other words, who is responsible for > merging adapted flows' interests into one statement affecting original > flow, the server or the processor? If a server thinks, it must create multiple messages and wants to use Wont-Send information it is responsible to get this done correctly. > > However, I am not sure how to document the "short circuit" code in the > Core. The Core cannot assume that an application protocol has > requests/responses and, hence, cannot document something like a > "Respond with this response instead of forwarding original request" > code. > > If I try to be generic and document the code as something like > "adapted message is not intended for the original message recipient", > we might raise red flags for those who think that IAB "OPES must not > resolve URIs" concern applies in this case. > > Suggestions? I do not see that you have to document a generic short-circuit thing. In OCP core it is simply about receiving application messages back from the service that are (not longer) depending on the original message. Sending HTTP error messages in REQMOD is a prominent example and real request satisfaction another but there are more examples, even for RESPMOD and in real life: 1. Removing animations from GIF images are possible by changing few bytes in the beginning of the image and the cropping the image data after the first picture. A callout service can return such adapted GIF and instruct the OPES processor that it finished filtering even before it has seen the rest of the GIF. Further transmission is not necessary. 2. Very similar from AntiVirus area: There are BMPs known to contain malicious code after the real image data. A security service could delete them and use the 207 result for best performance. Do you now think, you can document that feature in core? Martin From owner-ietf-openproxy@mail.imc.org Sun Oct 26 19:40:30 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06466 for ; Sun, 26 Oct 2003 19:40:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADvR1-0003S8-00 for opes-archive@ietf.org; Sun, 26 Oct 2003 19:40:39 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ADvR1-0003S3-00 for opes-archive@ietf.org; Sun, 26 Oct 2003 19:40:39 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9R0TdI7045782 for ; Sun, 26 Oct 2003 16:29: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 h9R0Tder045781 for ietf-openproxy-bks; Sun, 26 Oct 2003 16:29:39 -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 h9R0TbI7045772 for ; Sun, 26 Oct 2003 16:29:38 -0800 (PST) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id DF1H0O97outgoing id OV09N9DB; 27 Oct 2003 03:36:55 +0100 Received: from jadzia ([10.2.0.70]) by mail.WEBWASHER.COM with Microsoft SMTPSVC(5.0.2195.6713); Mon, 27 Oct 2003 01:29:33 +0100 Message-ID: <00a401c39c21$68e9c330$3d23eed9@jadzia> From: "Martin Stecher" To: "Alex Rousskov" Cc: "OPES WG \(E-mail\)" References: <75F7E67FC45F6744A7D328D41E35376D01408E@mail.webwasher.com> <002701c39bff$d9f31c60$3d23eed9@jadzia> Subject: Re: what-parts-to-send-or-skip Date: Mon, 27 Oct 2003 01:29:39 +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: 27 Oct 2003 00:29:34.0065 (UTC) FILETIME=[651B5610:01C39C21] Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > > I think the most common scenario for URL blocking services would be > to send (in NR) > > Wont-Look-Body: 2147483647 > rather than > Wont-Send-Body: 2147483647 It will be Wont-Look-Body: 0 because as you said before: > Not only Wont-Use tells the processor that preserving those bytes for > this service is a waste, but that _sending_ those bytes is a waste. > The processor SHOULD terminate the message with AME/206 after sending > all original bytes up to the Wont-Use point. Right? I described now: An OPES processor SHOULD behave as if it receives a Wont-Look message at the time that it will have sent the given number of OCTETs of the application message body part, for example, if the Wont-Look-Body value is zero in an HTTP response profile, the OPES processor SHOULD send an AME message with result code 206 after sending the response-header message part and before starting with the response-body message part. Martin From owner-ietf-openproxy@mail.imc.org Sun Oct 26 21:53: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 VAA09347 for ; Sun, 26 Oct 2003 21:53:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADxWB-00051z-00 for opes-archive@ietf.org; Sun, 26 Oct 2003 21:54:07 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ADxWA-00051w-00 for opes-archive@ietf.org; Sun, 26 Oct 2003 21:54: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 h9R2fEI7051890 for ; Sun, 26 Oct 2003 18:41: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 h9R2fE7N051889 for ietf-openproxy-bks; Sun, 26 Oct 2003 18:41:14 -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 h9R2fDI7051884 for ; Sun, 26 Oct 2003 18:41:13 -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 h9R2fFGh040711 for ; Sun, 26 Oct 2003 19:41:15 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9R2fFC5040710; Sun, 26 Oct 2003 19:41:15 -0700 (MST) (envelope-from rousskov) Date: Sun, 26 Oct 2003 19:41:15 -0700 (MST) From: Alex Rousskov To: OPES WG Subject: Re: documenting OCP parameters In-Reply-To: <004901c39c14$7330e8d0$3d23eed9@jadzia> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D0E6649@mail.webwasher.com> <003301c39c0f$983b9530$3d23eed9@jadzia> <004901c39c14$7330e8d0$3d23eed9@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 Sun, 26 Oct 2003, Martin Stecher wrote: > I think it looks well, if named parameter's names start with a capital > letter but type names are lowercase; then you know that the lowercase things > will be replaced by s.th. else while the capital words stay. OK. I will try to be consistent with the above when editing Core. Alex. From owner-ietf-openproxy@mail.imc.org Sun Oct 26 21:56: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 VAA09435 for ; Sun, 26 Oct 2003 21:56:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADxYy-00053e-00 for opes-archive@ietf.org; Sun, 26 Oct 2003 21:57:00 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ADxYx-00053b-00 for opes-archive@ietf.org; Sun, 26 Oct 2003 21:56:59 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9R2kbI7052166 for ; Sun, 26 Oct 2003 18:46:37 -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 h9R2kbW3052165 for ietf-openproxy-bks; Sun, 26 Oct 2003 18:46:37 -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 h9R2kXI7052158 for ; Sun, 26 Oct 2003 18:46: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 h9R2kaGh040822 for ; Sun, 26 Oct 2003 19:46: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 h9R2kafV040821; Sun, 26 Oct 2003 19:46:36 -0700 (MST) (envelope-from rousskov) Date: Sun, 26 Oct 2003 19:46:36 -0700 (MST) From: Alex Rousskov To: "OPES WG (E-mail)" Subject: Re: what-parts-to-send-or-skip In-Reply-To: <00a401c39c21$68e9c330$3d23eed9@jadzia> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D01408E@mail.webwasher.com> <002701c39bff$d9f31c60$3d23eed9@jadzia> <00a401c39c21$68e9c330$3d23eed9@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 Mon, 27 Oct 2003, Martin Stecher wrote: > > Wont-Look-Body: 2147483647 > > rather than > > Wont-Send-Body: 2147483647 > > It will be > > Wont-Look-Body: 0 Agreed. Wont-Send offset semantics (will not send anything up to the specified point) is going to be different from the Wont-Look semantics (will not look at anything beyond the specified point). Right? I hope that is OK. If not, we can have more explicit names: Wont-Look-Body-After: Wont-Send-Body-Before: or something of that kind. Alex. From owner-ietf-openproxy@mail.imc.org Sun Oct 26 22:10: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 WAA09678 for ; Sun, 26 Oct 2003 22:10:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADxmR-0005A6-00 for opes-archive@ietf.org; Sun, 26 Oct 2003 22:10:55 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ADxmQ-0005A3-00 for opes-archive@ietf.org; Sun, 26 Oct 2003 22:10: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 h9R31OI7052985 for ; Sun, 26 Oct 2003 19:01: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 h9R31OV1052984 for ietf-openproxy-bks; Sun, 26 Oct 2003 19:01:24 -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 h9R31MI7052978 for ; Sun, 26 Oct 2003 19:01: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 h9R31PGh041153 for ; Sun, 26 Oct 2003 20:01: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 h9R31Psb041152; Sun, 26 Oct 2003 20:01:25 -0700 (MST) (envelope-from rousskov) Date: Sun, 26 Oct 2003 20:01:25 -0700 (MST) From: Alex Rousskov To: OPES WG Subject: Re: Getting Out Of The Loop optimization broken In-Reply-To: <006701c39c1a$80072320$3d23eed9@jadzia> Message-ID: References: <005301c39b14$9a5d1ab0$0e2deed9@jadzia> <001101c39bf0$d1f92bd0$3d23eed9@jadzia> <006701c39c1a$80072320$3d23eed9@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 Mon, 27 Oct 2003, Martin Stecher wrote: > > Do you think we should move all parameters that apply to the original > > flow from am-id-specific messages to xid-specific messages? For > > consistency reasons? > > Yes, it makes a lot of sense. > Please introduce Wont-Send message and remove the parameter from DUM/DUY. Will do. Alex. From owner-ietf-openproxy@mail.imc.org Sun Oct 26 22:24:15 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10133 for ; Sun, 26 Oct 2003 22:24:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADxzU-0005M0-00 for opes-archive@ietf.org; Sun, 26 Oct 2003 22:24:24 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ADxzU-0005Lx-00 for opes-archive@ietf.org; Sun, 26 Oct 2003 22:24:24 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9R3AEI7053401 for ; Sun, 26 Oct 2003 19:10: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 h9R3AE3r053400 for ietf-openproxy-bks; Sun, 26 Oct 2003 19:10:14 -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 h9R3ADI7053395 for ; Sun, 26 Oct 2003 19:10:13 -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 h9R3AGGh041290 for ; Sun, 26 Oct 2003 20:10:16 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9R3AGP9041289; Sun, 26 Oct 2003 20:10:16 -0700 (MST) (envelope-from rousskov) Date: Sun, 26 Oct 2003 20:10:16 -0700 (MST) From: Alex Rousskov To: OPES WG Subject: Re: Getting Out Of The Loop optimization broken In-Reply-To: <006701c39c1a$80072320$3d23eed9@jadzia> Message-ID: References: <005301c39b14$9a5d1ab0$0e2deed9@jadzia> <001101c39bf0$d1f92bd0$3d23eed9@jadzia> <006701c39c1a$80072320$3d23eed9@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 Mon, 27 Oct 2003, Martin Stecher wrote: > > However, I am not sure how to document the "short circuit" code in > > the Core. The Core cannot assume that an application protocol has > > requests/responses and, hence, cannot document something like a > > "Respond with this response instead of forwarding original > > request" code. > > > > If I try to be generic and document the code as something like > > "adapted message is not intended for the original message > > recipient", we might raise red flags for those who think that IAB > > "OPES must not resolve URIs" concern applies in this case. > > > > Suggestions? > > I do not see that you have to document a generic short-circuit > thing. In OCP core it is simply about receiving application messages > back from the service that are (not longer) depending on the > original message. A "no longer depending on (derived from?) the original" seems too vague to me. Even in your examples, you have cases (non-animated GIF and garbage-free BMP) that hardly fit this category because those adapted objects are derived directly from the original ones. I cannot think of a rule that will tell implementors exactly when to use 207 response code. It may help if you can give two _similar_ examples: one with 200 code and one with 207. Or, perhaps you can propose a better 207 code definition/rule? > Sending HTTP error messages in REQMOD is a prominent example and > real request satisfaction another but there are more examples, even > for RESPMOD and in real life: > > 1. Removing animations from GIF images are possible by changing few > bytes in the beginning of the image and the cropping the image data > after the first picture. A callout service can return such adapted > GIF and instruct the OPES processor that it finished filtering even > before it has seen the rest of the GIF. Further transmission is not > necessary. Why not return a 200 OK status code in this case? > 2. Very similar from AntiVirus area: There are BMPs known to contain > malicious code after the real image data. A security service could > delete them and use the 207 result for best performance. Why not return a 200 OK status code in this case? What are the performance differences that you are implying above? My understanding is that a regular 200 OK response will result in appropriate truncation of the forwarded image. 200 OK does not imply that the adapted length is the same as original length, does it? > Do you now think, you can document that feature in core? Sorry, I need to better understand how is 207 different from 200 first. Please see the questions above. Alex. From owner-ietf-openproxy@mail.imc.org Mon Oct 27 04:22: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 EAA02904 for ; Mon, 27 Oct 2003 04:22:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE3aJ-0001fW-00 for opes-archive@ietf.org; Mon, 27 Oct 2003 04:22:48 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AE3aJ-0001fS-00 for opes-archive@ietf.org; Mon, 27 Oct 2003 04:22: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 h9R98dI7021814 for ; Mon, 27 Oct 2003 01:08: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 h9R98d6u021813 for ietf-openproxy-bks; Mon, 27 Oct 2003 01:08:39 -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 h9R98aI7021764 for ; Mon, 27 Oct 2003 01:08:37 -0800 (PST) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id 53FKGL98outgoing id 0ZV8J0PT; 27 Oct 2003 12:15:47 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: what-parts-to-send-or-skip Date: Mon, 27 Oct 2003 10:08:25 +0100 Message-ID: <75F7E67FC45F6744A7D328D41E35376D0E664D@mail.webwasher.com> Thread-Topic: what-parts-to-send-or-skip Thread-Index: AcOcN/oHl2mBjAz8TLC2Yv+Q2CRlpgAL8mpg From: "Martin Stecher" To: "Alex Rousskov" , "OPES WG (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9R98cI7021804 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > > > Wont-Look-Body: 2147483647 > > > rather than > > > Wont-Send-Body: 2147483647 > > > > It will be > > > > Wont-Look-Body: 0 > > Agreed. Wont-Send offset semantics (will not send anything up to the > specified point) is going to be different from the Wont-Look semantics > (will not look at anything beyond the specified point). Right? > Yes. > I hope that is OK. If not, we can have more explicit names: > > Wont-Look-Body-After: > Wont-Send-Body-Before: > > or something of that kind. Not needed I think. For clarification: Wont-Look-Body: 0 is NOT a good value for URL blocking tools. Actually the Wont-Look-Body parameter for NR cannot be used by URL blocking servies at all (unless they block all requests). Reason: Depending on the URL, the service will either send the request back unchanged or it will short-circuit and send back an error message. Thus, it will need to wait for the request-header part and then decide whether it sends a DWO message or a DWLY message. Because Wont-Look-Body: 0 means to behave as if DWLY is sent for all transactions, it cannot be used here. Right? Martin From owner-ietf-openproxy@mail.imc.org Mon Oct 27 04:25: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 EAA03019 for ; Mon, 27 Oct 2003 04:25:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE3dC-0001iK-00 for opes-archive@ietf.org; Mon, 27 Oct 2003 04:25:46 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AE3dB-0001iF-00 for opes-archive@ietf.org; Mon, 27 Oct 2003 04:25:45 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9R9B6I7022642 for ; Mon, 27 Oct 2003 01:11: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 h9R9B6Cb022641 for ietf-openproxy-bks; Mon, 27 Oct 2003 01:11:06 -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 h9R9B4I7022589 for ; Mon, 27 Oct 2003 01:11:05 -0800 (PST) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id HD5I5N5Ooutgoing id 068RI8YT; 27 Oct 2003 12:18:20 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: Getting Out Of The Loop optimization broken Date: Mon, 27 Oct 2003 10:10:59 +0100 Message-ID: <75F7E67FC45F6744A7D328D41E35376D0E664E@mail.webwasher.com> Thread-Topic: Getting Out Of The Loop optimization broken Thread-Index: AcOcO8hq/OsxuXGhT0uRewlZjuhL0AALiQ6g From: "Martin Stecher" To: "Alex Rousskov" , "OPES WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9R9B6I7022632 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > > > However, I am not sure how to document the "short circuit" code in > > > the Core. The Core cannot assume that an application protocol has > > > requests/responses and, hence, cannot document something like a > > > "Respond with this response instead of forwarding original > > > request" code. > > > > > > If I try to be generic and document the code as something like > > > "adapted message is not intended for the original message > > > recipient", we might raise red flags for those who think that IAB > > > "OPES must not resolve URIs" concern applies in this case. > > > > > > Suggestions? > > > > I do not see that you have to document a generic short-circuit > > thing. In OCP core it is simply about receiving application messages > > back from the service that are (not longer) depending on the > > original message. > > A "no longer depending on (derived from?) the original" seems too > vague to me. Even in your examples, you have cases (non-animated GIF > and garbage-free BMP) that hardly fit this category because those > adapted objects are derived directly from the original ones. I cannot > think of a rule that will tell implementors exactly when to use 207 > response code. > > It may help if you can give two _similar_ examples: one with 200 code > and one with 207. Or, perhaps you can propose a better 207 code > definition/rule? > > > Sending HTTP error messages in REQMOD is a prominent example and > > real request satisfaction another but there are more examples, even > > for RESPMOD and in real life: > > > > 1. Removing animations from GIF images are possible by changing few > > bytes in the beginning of the image and the cropping the image data > > after the first picture. A callout service can return such adapted > > GIF and instruct the OPES processor that it finished filtering even > > before it has seen the rest of the GIF. Further transmission is not > > necessary. > > Why not return a 200 OK status code in this case? > > > 2. Very similar from AntiVirus area: There are BMPs known to contain > > malicious code after the real image data. A security service could > > delete them and use the 207 result for best performance. > > Why not return a 200 OK status code in this case? What are the > performance differences that you are implying above? My understanding > is that a regular 200 OK response will result in appropriate > truncation of the forwarded image. 200 OK does not imply that the > adapted length is the same as original length, does it? > > > Do you now think, you can document that feature in core? > > Sorry, I need to better understand how is 207 different from 200 > first. Please see the questions above. > I think 207 is not longer needed. I wanted to use 207 in AME to achieve the same as with DWLY messages. Since we found that a transaction wide message (DWLY) works better than something bound to am-id, we do not longer need to distinguish 206 and 207. I am fine with what we have in OCP core now. Regards Martin From owner-ietf-openproxy@mail.imc.org Mon Oct 27 04:26: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 EAA03102 for ; Mon, 27 Oct 2003 04:26:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE3eI-0001kA-00 for opes-archive@ietf.org; Mon, 27 Oct 2003 04:26:54 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AE3eI-0001k7-00 for opes-archive@ietf.org; Mon, 27 Oct 2003 04:26: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 h9R9G9I7024390 for ; Mon, 27 Oct 2003 01:16: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 h9R9G8HA024389 for ietf-openproxy-bks; Mon, 27 Oct 2003 01:16:08 -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 h9R9G7I7024379 for ; Mon, 27 Oct 2003 01:16: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 h9R9G7Gh049541; Mon, 27 Oct 2003 02:16:07 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9R9G7gN049540; Mon, 27 Oct 2003 02:16:07 -0700 (MST) (envelope-from rousskov) Date: Mon, 27 Oct 2003 02:16:07 -0700 (MST) From: Alex Rousskov To: Martin Stecher cc: "OPES WG (E-mail)" Subject: RE: what-parts-to-send-or-skip In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D0E664D@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D0E664D@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 27 Oct 2003, Martin Stecher wrote: > For clarification: > > Wont-Look-Body: 0 is NOT a good value for URL blocking tools. > Actually the Wont-Look-Body parameter for NR cannot be used by URL > blocking servies at all (unless they block all requests). > > Reason: Depending on the URL, the service will either send the > request back unchanged or it will short-circuit and send back an > error message. Thus, it will need to wait for the request-header > part and then decide whether it sends a DWO message or a DWLY > message. Because Wont-Look-Body: 0 means to behave as if DWLY is > sent for all transactions, it cannot be used here. The above looks correct to me. It looks like Wont-Look-Body in NR is only useful for services that generate responses from scratch, possibly based on header and meta info. Such services may be useful if they are activated based on some dynamic conditions (errors, blocked pages, overload, etc.). For example, perhaps the service that blocks is different from the service that generates the final "your transaction has been blocked" response in a user-friendly language. Alex. From owner-ietf-openproxy@mail.imc.org Mon Oct 27 05:44: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 FAA05580 for ; Mon, 27 Oct 2003 05:44:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE4rJ-0002bk-00 for opes-archive@ietf.org; Mon, 27 Oct 2003 05:44:25 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AE4rI-0002bY-00 for opes-archive@ietf.org; Mon, 27 Oct 2003 05:44:24 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RAVTI7040995 for ; Mon, 27 Oct 2003 02:31:29 -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 h9RAVTgh040994 for ietf-openproxy-bks; Mon, 27 Oct 2003 02:31:29 -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 h9RAVPI7040980 for ; Mon, 27 Oct 2003 02:31:26 -0800 (PST) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id G3MWTMKUoutgoing id HXYWDZXO; 27 Oct 2003 13:38:42 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C39C75.75617495" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: Request to publish: draft-ietf-opes-http-01 Date: Mon, 27 Oct 2003 11:31:19 +0100 Message-ID: <75F7E67FC45F6744A7D328D41E35376D0E6654@mail.webwasher.com> X-MS-Has-Attach: yes Thread-Topic: draft-ietf-opes-http-00 Thread-Index: AcNadGgkW98l8zePR7WcFfcmOa0pBg== From: "Martin Stecher" To: Cc: "Alex Rousskov (E-mail)" , "Markus Hofmann (E-mail)" , "Marshall Rose" , "OPES WG (E-mail)" 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_001_01C39C75.75617495 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, please publish the attached document as an Internet Draft of the OPES WG draft-ietf-opes-http-01 Thank you. Regards Martin Stecher ------_=_NextPart_001_01C39C75.75617495 Content-Type: text/plain; name="draft-ietf-opes-http-01.txt" Content-Description: draft-ietf-opes-http-01.txt Content-Disposition: attachment; filename="draft-ietf-opes-http-01.txt" Content-Transfer-Encoding: base64 DQoNCk9wZW4gUGx1Z2dhYmxlIEVkZ2UgU2VydmljZXMgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBBLiBSb3Vzc2tvdg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFRoZSBNZWFzdXJlbWVudCBGYWN0b3J5DQpFeHBpcmVzOiBBcHJpbCAyNiwg MjAwNCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE0uIFN0ZWNoZXINCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHdlYndhc2hlciBBRw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBPY3RvYmVyIDI3LCAyMDAzDQoNCg0KICAgICAgICAgICAgICAgICAgICAg ICBIVFRQIGFkYXB0YXRpb24gd2l0aCBPUEVTDQogICAgICAgICAgICAgICAgICAgICAgICBkcmFm dC1pZXRmLW9wZXMtaHR0cC0wMQ0KDQpTdGF0dXMgb2YgdGhpcyBNZW1vDQoNCiAgIFRoaXMgZG9j dW1lbnQgaXMgYW4gSW50ZXJuZXQtRHJhZnQgYW5kIGlzIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0 aA0KICAgYWxsIHByb3Zpc2lvbnMgb2YgU2VjdGlvbiAxMCBvZiBSRkMyMDI2Lg0KDQogICBJbnRl cm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVl cmluZw0KICAgVGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdy b3Vwcy4gTm90ZSB0aGF0IG90aGVyDQogICBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3Jr aW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuDQoNCiAgIEludGVybmV0LURyYWZ0cyBh cmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocw0KICAg YW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3Vt ZW50cyBhdCBhbnkNCiAgIHRpbWUuIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0 LURyYWZ0cyBhcyByZWZlcmVuY2UNCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0 aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiINCg0KICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRl cm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0IGh0dHA6Ly8NCiAgIHd3dy5pZXRmLm9yZy9p ZXRmLzFpZC1hYnN0cmFjdHMudHh0Lg0KDQogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBT aGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICBodHRwOi8vd3d3LmlldGYu b3JnL3NoYWRvdy5odG1sLg0KDQogICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9u IEFwcmlsIDI2LCAyMDA0Lg0KDQpDb3B5cmlnaHQgTm90aWNlDQoNCiAgIENvcHlyaWdodCAoQykg VGhlIEludGVybmV0IFNvY2lldHkgKDIwMDMpLiBBbGwgUmlnaHRzIFJlc2VydmVkLg0KDQpBYnN0 cmFjdA0KDQogICBPcGVuIFBsdWdnYWJsZSBFZGdlIFNlcnZpY2VzIChPUEVTKSBmcmFtZXdvcmsg ZG9jdW1lbnRzIHNldmVyYWwNCiAgIGFwcGxpY2F0aW9uLWFnbm9zdGljIG1lY2hhbmlzbXMgc3Vj aCBhcyBPUEVTIHRyYWNpbmcsIE9QRVMgYnlwYXNzLA0KICAgYW5kIE9QRVMgY2FsbG91dCBwcm90 b2NvbC4gVGhpcyBkb2N1bWVudCBiaW5kcyB0aGVzZSBtZWNoYW5pc21zIHRvDQogICB0aGUgSHlw ZXJ0ZXh0IFRyYW5zZmVyIFByb3RvY29sIChIVFRQKS4gIFRvZ2V0aGVyLA0KICAgYXBwbGljYXRp b24tYWdub3N0aWMgT1BFUyBkb2N1bWVudHMgYW5kIHRoaXMgSFRUUCBiaW5kaW5nIGNvbnN0aXR1 dGUNCiAgIGEgY29tcGxldGUgc3BlY2lmaWNhdGlvbiBmb3IgSFRUUCBhZGFwdGF0aW9uIHdpdGgg T1BFUy4NCg0KDQoNCg0KDQoNCg0KDQpSb3Vzc2tvdiAmIFN0ZWNoZXIgICAgICAgRXhwaXJlcyBB cHJpbCAyNiwgMjAwNCAgICAgICAgICAgICAgICAgW1BhZ2UgMV0NCgwNCkludGVybmV0LURyYWZ0 ICAgICAgICAgSFRUUCBhZGFwdGF0aW9uIHdpdGggT1BFUyAgICAgICAgICAgIE9jdG9iZXIgMjAw Mw0KDQoNClRhYmxlIG9mIENvbnRlbnRzDQoNCiAgIDEuICAgIEludHJvZHVjdGlvbiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMw0KICAgMi4gICAgQ2Fs bG91dCBQcm90b2NvbCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICA0DQogICAyLjEgICBBcHBsaWNhdGlvbiBNZXNzYWdlIFBhcnRzICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDQNCiAgIDIuMiAgIEFwcGxpY2F0aW9uIFByb2ZpbGUgRmVhdHVy ZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQ0KICAgMi4yLjEgUHJvZmlsZSBQ YXJ0cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA2DQog ICAyLjIuMiBQcm9maWxlIFN0cnVjdHVyZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gIDYNCiAgIDIuMi4zIEF1eC1QYXJ0cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNw0KICAgMi4yLjQgUGF1c2UtQXQtQm9keSAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA4DQogICAyLjIu NSBXb250LUxvb2stQm9keSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gIDgNCiAgIDIuMi42IFdvbnQtU2VuZC1Cb2R5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOQ0KICAgMi4yLjcgQ29udGVudC1FbmNvZGluZ3MgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA5DQogICAyLjIuOCBQcm9m aWxlIE5lZ290aWF0aW9uIEV4YW1wbGUgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g MTANCiAgIDIuMyAgIEFwcGxpY2F0aW9uIE1lc3NhZ2UgU3RhcnQgTWVzc2FnZSAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAxMQ0KICAgMi40ICAgRGF0YSBVc2UgTWluZSBNZXNzYWdlICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExDQogICAyLjUgICBUcmFuc2ZlciBF bmNvZGluZ3MgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTINCiAg IDIuNiAgIEhUVFAgSGVhZGVyIENvcnJlY3RuZXNzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAxMw0KICAgMi42LjEgTWVzc2FnZSBTaXplIFJlY2FsY3VsYXRpb24gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEzDQogICAyLjYuMiBDb250ZW50LU1ENSBIZWFk ZXIgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTQNCiAgIDMuICAg IFRyYWNpbmcgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAxNQ0KICAgNC4gICAgQnlwYXNzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE3DQogICA1LiAgICBJQUIgQ29uc2lkZXJhdGlvbnMgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTgNCiAgIDYuICAgIFNlY3Vy aXR5IENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAx OQ0KICAgNy4gICAgQ29tcGxpYW5jZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDIwDQogICA4LiAgICBUby1kbyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjENCiAgIEEuICAgIEFja25vd2xlZGdl bWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyMg0KICAg Qi4gICAgQ2hhbmdlIExvZyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDIzDQogICAgICAgICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjcNCiAgICAgICAgIEluZm9ybWF0aXZlIFJlZmVy ZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyOA0KICAgICAgICAg QXV0aG9ycycgQWRkcmVzc2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDI4DQogICAgICAgICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgYW5kIENvcHlyaWdodCBTdGF0 ZW1lbnRzIC4gLiAuIC4gLiAuIC4gMjkNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KUm91c3Nrb3YgJiBTdGVjaGVyICAgICAgIEV4cGlyZXMgQXByaWwgMjYsIDIwMDQgICAg ICAgICAgICAgICAgIFtQYWdlIDJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgIEhUVFAgYWRh cHRhdGlvbiB3aXRoIE9QRVMgICAgICAgICAgICBPY3RvYmVyIDIwMDMNCg0KDQoxLiBJbnRyb2R1 Y3Rpb24NCg0KICAgVGhlIE9wZW4gUGx1Z2dhYmxlIEVkZ2UgU2VydmljZXMgKE9QRVMpIGZyYW1l d29yayBkb2N1bWVudHMgc2V2ZXJhbA0KICAgYXBwbGljYXRpb24tYWdub3N0aWMgbWVjaGFuaXNt cyBzdWNoIGFzIE9QRVMgcHJvY2Vzc29yIGFuZCBlbmRwb2ludHMNCiAgIGNvbW11bmljYXRpb25z IFtJLUQuaWV0Zi1vcGVzLWVuZC1jb21tXSBvciBPUEVTIGNhbGxvdXQgcHJvdG9jb2wNCiAgIFtJ LUQuaWV0Zi1vcGVzLW9jcC1jb3JlXS4gVGhpcyBkb2N1bWVudCBiaW5kcyB0aGVzZSBtZWNoYW5p c21zIHRvIGENCiAgIHNwZWNpZmljIGFwcGxpY2F0aW9uIHByb3RvY29sLCBIVFRQIFtSRkMyNjE2 XS4gVG9nZXRoZXIsDQogICBhcHBsaWNhdGlvbi1hZ25vc3RpYyBPUEVTIGRvY3VtZW50cyBhbmQg dGhpcyBIVFRQIGJpbmRpbmcgY29uc3RpdHV0ZQ0KICAgYSBjb21wbGV0ZSBzcGVjaWZpY2F0aW9u IGZvciBIVFRQIGFkYXB0YXRpb24gd2l0aCBPUEVTLg0KDQogICBUaGUgcHJpbWFyeSBzZWN0aW9u cyBvZiB0aGlzIGRvY3VtZW50IHNwZWNpZnkgSFRUUCBiaW5kaW5ncyBmb3IgdGhlDQogICBjb3Jy ZXNwb25kaW5nIGFwcGxpY2F0aW9uLWFnbm9zdGljIG1lY2hhbmlzbXMgZG9jdW1lbnRlZCBlbHNl d2hlcmUuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpSb3Vzc2tvdiAmIFN0ZWNoZXIgICAgICAgRXhw aXJlcyBBcHJpbCAyNiwgMjAwNCAgICAgICAgICAgICAgICAgW1BhZ2UgM10NCgwNCkludGVybmV0 LURyYWZ0ICAgICAgICAgSFRUUCBhZGFwdGF0aW9uIHdpdGggT1BFUyAgICAgICAgICAgIE9jdG9i ZXIgMjAwMw0KDQoNCjIuIENhbGxvdXQgUHJvdG9jb2wNCg0KICAgVGhpcyBzZWN0aW9uIGRvY3Vt ZW50cyBIVFRQIGJpbmRpbmdzIGZvciB0aGUgT1BFUyBjYWxsb3V0IHByb3RvY29sDQogICAoT0NQ KSBbSS1ELmlldGYtb3Blcy1vY3AtY29yZV0uDQoNCjIuMSBBcHBsaWNhdGlvbiBNZXNzYWdlIFBh cnRzDQoNCiAgIFNpeCBwYXJ0cyBvZiBIVFRQIG1lc3NhZ2VzIGFyZSBkZWZpbmVkIGFzIGFwcGxp Y2F0aW9uIG1lc3NhZ2UgcGFydHMNCiAgIGZvciBPQ1A6DQoNCiAgIFRoaXMgc3BlY2lmaWNhdGlv biBkb2N1bWVudHMgdGhlIGZvbGxvd2luZyBzaXggYXBwbGljYXRpb24gbWVzc2FnZQ0KICAgcGFy dHMgKGFtLXBhcnQpIHZhbHVlczoNCg0KICAgcmVxdWVzdC1oZWFkZXI6IFRoZSBzdGFydC1saW5l IG9mIGFuIEhUVFAgcmVxdWVzdCBtZXNzYWdlLCBhbGwNCiAgICAgIHJlcXVlc3QgbWVzc2FnZSBo ZWFkZXJzLCBhbmQgdGhlIENSTEYgc2VwYXJhdG9yIGF0IHRoZSBlbmQgb2YgSFRUUA0KICAgICAg aGVhZGVycyAoY29tcGFyZSB3aXRoIHNlY3Rpb24gNC4xIG9mIFtSRkMyNjE2XSkNCg0KICAgcmVx dWVzdC1ib2R5OiBUaGUgbWVzc2FnZSBib2R5IG9mIGFuIEhUVFAgcmVxdWVzdCBtZXNzYWdlIGFz IGRlZmluZWQNCiAgICAgIGluIHNlY3Rpb24gNC4zIG9mIFtSRkMyNjE2XSBidXQgbm90IGluY2x1 ZGluZyB0aGUgdHJhaWxlcg0KDQogICByZXF1ZXN0LXRyYWlsZXI6IFRoZSBlbnRpdHkgaGVhZGVy cyBvZiB0aGUgdHJhaWxlciBvZiBhbiBIVFRQIHJlcXVlc3QNCiAgICAgIG1lc3NhZ2UgaW4gY2h1 bmtlZCB0cmFuc2ZlciBlbmNvZGluZy4gVGhpcyBwYXJ0IGZvbGxvd3MgdGhlIHNhbWUNCiAgICAg IHN5bnRheCBhcyB0aGUgdHJhaWxlciBkZWZpbmVkIGluIHNlY3Rpb24gMy42LjEgb2YgW1JGQzI2 MTZdDQoNCiAgIHJlc3BvbnNlLWhlYWRlcjogVGhlIHN0YXJ0LWxpbmUgb2YgYW4gSFRUUCByZXNw b25zZSBtZXNzYWdlLCBhbGwNCiAgICAgIHJlc3BvbnNlIG1lc3NhZ2UgaGVhZGVycywgYW5kIHRo ZSBDUkxGIHNlcGFyYXRvciBhdCB0aGUgZW5kIG9mDQogICAgICBIVFRQIGhlYWRlcnMgKGNvbXBh cmUgd2l0aCBzZWN0aW9uIDQuMSBvZiBbUkZDMjYxNl0pDQoNCiAgIHJlc3BvbnNlLWJvZHk6IFRo ZSBtZXNzYWdlIGJvZHkgb2YgYW4gSFRUUCByZXNwb25zZSBtZXNzYWdlIGFzDQogICAgICBkZWZp bmVkIGluIHNlY3Rpb24gNC4zIG9mIFtSRkMyNjE2XSBidXQgbm90IGluY2x1ZGluZyB0aGUgdHJh aWxlcg0KDQogICByZXNwb25zZS10cmFpbGVyOiBUaGUgZW50aXR5IGhlYWRlcnMgb2YgdGhlIHRy YWlsZXIgb2YgYW4gSFRUUA0KICAgICAgcmVzcG9uc2UgbWVzc2FnZSBpbiBjaHVua2VkIHRyYW5z ZmVyIGVuY29kaW5nLiBUaGlzIHBhcnQgZm9sbG93cw0KICAgICAgdGhlIHNhbWUgc3ludGF4IGFz IHRoZSB0cmFpbGVyIGRlZmluZWQgaW4gc2VjdGlvbiAzLjYuMSBvZg0KICAgICAgW1JGQzI2MTZd DQoNCiAgIFRoaXMgaXMgdGhlIGRlZmluaXRpb24gb2YgYW0tcGFydCB1c2luZyBURE06DQoNCg0K ICAgCQlhbS1wYXJ0OiBleHRlbmRzIGF0b207DQogICAJCWFtLXBhcnRzOiBleHRlbmRzIGxpc3Qg b2YgYW0tcGFydDsNCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAx DQoNCg0KDQoNCg0KDQoNClJvdXNza292ICYgU3RlY2hlciAgICAgICBFeHBpcmVzIEFwcmlsIDI2 LCAyMDA0ICAgICAgICAgICAgICAgICBbUGFnZSA0XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAg ICBIVFRQIGFkYXB0YXRpb24gd2l0aCBPUEVTICAgICAgICAgICAgT2N0b2JlciAyMDAzDQoNCg0K Mi4yIEFwcGxpY2F0aW9uIFByb2ZpbGUgRmVhdHVyZXMNCg0KICAgVGhpcyBkb2N1bWVudCBkZWZp bmVzIHR3byBIVFRQIHByb2ZpbGVzIGZvciBPQ1AsIGRlcGVuZGluZyBvbiB0aGUNCiAgIG9yaWdp bmFsIGFuZCBhZGFwdGVkIHBhcnRzIGV4Y2hhbmdlZCBiZXR3ZWVuIE9DUCBhZ2VudHMuIFRoZXNl DQogICBwcm9maWxlcyBhcmUgZGVzY3JpYmVkIGJlbG93LiBGb3IgZWFjaCBvZiB0aGUgcHJvZmls ZXMsIHRoZSBmZWF0dXJlDQogICBpZGVudGlmaWVyIGFzIHdlbGwgYXMgb3JpZ2luYWwgYW5kIGFk YXB0ZWQgbWVzc2FnZSBwYXJ0cyBpcw0KICAgZG9jdW1lbnRlZC4gU29tZSBvcmlnaW5hbCBwYXJ0 cyBhcmUgYXV4aWxpYXJ5IHBhcnRzIGFuZCB3aWxsIG9ubHkgYmUNCiAgIHVzZWQgaWYgZXhwbGlj aXRseSBuZWdvdGlhdGVkIGZvciBhIHByb2ZpbGU7IHRoZXNlIHBhcnRzIGFyZSBtYXJrZWQNCiAg IHdpdGggIihhdXgpIi4NCg0KICAgaHR0cDovL2lhbmEub3JnL29wZXMvb2NwL0hUVFAvcmVxdWVz dA0KDQogICAgICBvcmlnaW5hbCBwYXJ0czogcmVxdWVzdC1oZWFkZXIsIHJlcXVlc3QtYm9keSwg cmVxdWVzdC10cmFpbGVyDQoNCiAgICAgIGFkYXB0ZWQgcGFydHMgdmFyaWFudCAxOiByZXF1ZXN0 LWhlYWRlciwgcmVxdWVzdC1ib2R5LA0KICAgICAgICAgcmVxdWVzdC10cmFpbGVyDQoNCiAgICAg IGFkYXB0ZWQgcGFydHMgdmFyaWFudCAyOiByZXNwb25zZS1oZWFkZXIsIHJlc3BvbnNlLWJvZHks DQogICAgICAgICByZXNwb25zZS10cmFpbGVyDQoNCiAgIGh0dHA6Ly9pYW5hLm9yZy9vcGVzL29j cC9IVFRQL3Jlc3BvbnNlDQoNCiAgICAgIG9yaWdpbmFsIHBhcnRzOiByZXF1ZXN0LWhlYWRlciAo YXV4KSwgcmVxdWVzdC1ib2R5IChhdXgpLA0KICAgICAgICAgcmVxdWVzdC10cmFpbGVyIChhdXgp LCByZXNwb25zZS1oZWFkZXIsDQogICAgICAgICByZXNwb25zZS1ib2R5LAlyZXNwb25zZS10cmFp bGVyDQoNCiAgICAgIGFkYXB0ZWQgcGFydHM6IHJlc3BvbnNlLWhlYWRlciwgcmVzcG9uc2UtYm9k eSwgcmVzcG9uc2UtdHJhaWxlcg0KDQogICBUaGUgc2NvcGUgb2YgYSBuZWdvdGlhdGVkIHByb2Zp bGUgaXMgdGhlIE9DUCBjb25uZWN0aW9uLg0KDQogICBBbiBPQ1AgYWdlbnQgTVVTVCBzZW5kIGFw cGxpY2F0aW9uIG1lc3NhZ2UgcGFydHMgaW4gdGhlIG9yZGVyDQogICBzcGVjaWZpZWQgYWJvdmUu IEFuIE9DUCBhZ2VudCByZWNlaXZpbmcgYW4gb3V0LW9mLW9yZGVyIHBhcnQgTUFZDQogICB0ZXJt aW5hdGUgdGhlIHRyYW5zYWN0aW9uIHdpdGggYW4gZXJyb3IuDQoNCiAgIEFuIE9QRVMgcHJvY2Vz c29yIE1VU1QgTk9UIHNlbmQgcGFydHMgdGhhdCBhcmUgbm90IGxpc3RlZCBhcw0KICAgIm9yaWdp bmFsIiBpbiB0aGUgbmVnb3RpYXRlZCBwcm9maWxlLiBBbiBjYWxsb3V0IHNlcnZlciBNVVNUIE5P VCBzZW5kDQogICBwYXJ0cyB0aGF0IGFyZSBub3QgbGlzdGVkIGFzICJhZGFwdGVkIiBpbiB0aGUg bmVnb3RpYXRlZCBwcm9maWxlLiAgQW4NCiAgIE9DUCBhZ2VudCByZWNlaXZpbmcgYW4gbm90LWxp c3RlZCBwYXJ0IE1VU1QgdGVybWluYXRlIHRoZSB0cmFuc2FjdGlvbg0KICAgd2l0aCBhbiBlcnJv ci4gVGhlIGluZm9ybWFsIHJhdGlvbmFsZSBmb3IgdGhlIGxhc3QgcmVxdWlyZW1lbnQgaXMgdG8N CiAgIHJlZHVjZSB0aGUgbnVtYmVyIG9mIHN1YnRsZSBpbnRlcm9wZXJhYmlsaXR5IHByb2JsZW1z IHdoZXJlIGFuIGFnZW50DQogICB0aGlua3MgdGhhdCB0aGUgcGFydHMgaXQgaXMgc2VuZGluZyBh cmUgdW5kZXJzdG9vZC91c2VkIGJ5IHRoZSBvdGhlcg0KICAgYWdlbnQgd2hlbiwgaW4gZmFjdCwg dGhleSBhcmUgYmVpbmcgaWdub3JlZCBvciBza2lwcGVkIGJlY2F1c2UgdGhleQ0KICAgYXJlIG5v dCBleHBlY3RlZC4NCg0KICAgSW4gdGhlIHJlcXVlc3QgcHJvZmlsZSB0aGUgY2FsbG91dCBzZXJ2 ZXIgY2FuIGNob29zZSBmcm9tIHR3bw0KICAgdmFyaWFudHMuIEVpdGhlciBpdCBjYW4gYWRhcHQg dGhlIG9yaWdpbmFsIHBhcnRzIG9yIHNlbmQgInJlc3BvbnNlLSINCiAgIG1lc3NhZ2UgcGFydHMu IEluZm9ybWFsbHksIGl0IHdpbGwgY2hvb3NlIHRoZSBzZWNvbmQgdmFyaWFudCBpZiBpdA0KICAg d2FudHMgdG8gInNob3J0LWNpcmN1aXQiIGFuZCByZXR1cm4gYW4gSFRUUCBtZXNzYWdlIGluc3Rl YWQgb2YNCg0KDQoNClJvdXNza292ICYgU3RlY2hlciAgICAgICBFeHBpcmVzIEFwcmlsIDI2LCAy MDA0ICAgICAgICAgICAgICAgICBbUGFnZSA1XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICBI VFRQIGFkYXB0YXRpb24gd2l0aCBPUEVTICAgICAgICAgICAgT2N0b2JlciAyMDAzDQoNCg0KICAg bW9kaWZ5aW5nIHRoZSBIVFRQIHJlcXVlc3QsIGZvciBleGFtcGxlIGluIG9yZGVyIHRvIHNlbmQg YW4gSFRUUA0KICAgZXJyb3IgbWVzc2FnZSBpbiByZXNwb25zZSB0byBhbiBIVFRQIHJlcXVlc3Qg dGhhdCB0aGUgY2FsbG91dCBzZXJ2aWNlDQogICBkZWZpbmVzIGFzIGZvcmJpZGRlbi4NCg0KICAg VGhlIGNhbGxvdXQgc2VydmVyIE1VU1QgTk9UIHNlbmQgbWVzc2FnZSBwYXJ0cyBmcm9tIG9uZSB2 YXJpYW50J3MNCiAgIGxpc3QgaWYgaXQgaGFzIGFscmVhZHkgc2VudCBtZXNzYWdlIHBhcnRzIG9m IHRoZSBvdGhlciB2YXJpYW50IGZvcg0KICAgdGhlIHNhbWUgdHJhbnNhY3Rpb24gKGluZm9ybWFs bHksIGl0IE1VU1QgZGVjaWRlIG9uIHdoaWNoIHZhcmlhbnQgdG8NCiAgIHVzZSBiZWZvcmUgaXQg c2VuZHMJdGhlIGZpcnN0IGFwcGxpY2F0aW9uIG1lc3NhZ2UgcGFydCkuIEFuIE9QRVMNCiAgIHBy b2Nlc3NvciByZWNlaXZpbmcgbWVzc2FnZSBwYXJ0cyBmcm9tIGJvdGggdmFyaWFudHMgTVVTVCB0 ZXJtaW5hdGUNCiAgIHRoZSB0cmFuc2FjdGlvbiB3aXRoIGFuIGVycm9yLg0KDQogICAoWFhYOiBJ cyBpdCBvayB0byBjYWxsIHRoZSBzZWNvbmQgdmFyaWFudCBzdGlsbCBhZGFwdGVkIHBhcnRzPw0K ICAgQWN0dWFsbHkgdGhlcmUgaXMgbm8gYWRhcHRhdGlvbiBvZiBhbnl0aGluZyB0aGF0IGhhcyBl eGlzdGVkIGJlZm9yZS4pDQoNCjIuMi4xIFByb2ZpbGUgUGFydHMNCg0KICAgU29tZSBIVFRQIG1l c3NhZ2VzIGxhY2sgY2VydGFpbiBwYXJ0cy4gRm9yIGV4YW1wbGUsIG1hbnkgSFRUUA0KICAgcmVx dWVzdHMgZG8gbm90IGhhdmUgYm9kaWVzLCBhbmQgbW9zdCBIVFRQIG1lc3NhZ2VzIGRvIG5vdCBo YXZlDQogICB0cmFpbGVycy4gQW4gT0NQIGFnZW50IE1VU1QgTk9UIHNlbmQgKGkuZS4sIG11c3Qg c2tpcCkgYWJzZW50IG1lc3NhZ2UNCiAgIHBhcnRzLg0KDQogICBBbiBPQ1AgYWdlbnQgTVVTVCBz ZW5kIHByZXNlbnQgbm9uLWF1eGlsaWFyeSBtZXNzYWdlIHBhcnRzIGFuZCBpdA0KICAgTVVTVCBz ZW5kIHRob3NlIGF1eGlsaWFyeSBtZXNzYWdlIHBhcnRzIHRoYXQgd2VyZSBuZWdvdGlhdGVkIHZp YSB0aGUNCiAgIEF1eC1QYXJ0cyAoU2VjdGlvbiAyLjIuMykgcGFyYW1ldGVyLiBPQ1AgYWdlbnRz IE1VU1QgTk9UIHNlbmQNCiAgIGF1eGlsaWFyeSBwYXJ0cyB0aGF0IHdlcmUgbm90IG5lZ290aWF0 ZWQgdmlhIHRoZSBBdXgtUGFydHMgKFNlY3Rpb24NCiAgIDIuMi4zKSBwYXJhbWV0ZXIuDQoNCiAg IEFuIE9DUCBhZ2VudCByZWNlaXZpbmcgYSBtZXNzYWdlIHBhcnQgaW4gdmlvbGF0aW9uIG9mIHRo ZSBhYm92ZQ0KICAgcmVxdWlyZW1lbnRzIE1BWSB0ZXJtaW5hdGUgdGhlIGNvcnJlc3BvbmRpbmcg dHJhbnNhY3Rpb24gd2l0aCBhbg0KICAgZXJyb3IuDQoNCiAgIEJ5IGRlc2lnbiwgb3JpZ2luYWwg cGFydHMgbm90IGluY2x1ZGVkIGluIHRoZSBhZGFwdGVkIHBhcnRzIGxpc3QNCiAgIGNhbm5vdCBi ZSBhZGFwdGVkLiBJbiBvdGhlciB3b3JkcywgYSBjYWxsb3V0IHNlcnZpY2UgY2FuIG9ubHkgYWRh cHQNCiAgIHBhcnRzIGluIHRoZSBhZGFwdGVkIHBhcnRzIGxpc3QgZXZlbiB0aG91Z2ggaXQgbWF5 IGhhdmUgYWNjZXNzIHRvDQogICBvdGhlciBwYXJ0cy4gKFhYWDogVGhlcmUgaXMgbm8gd2F5IGZv ciBhIHByb2Nlc3NvciB0byB0ZWxsIHRoZQ0KICAgc2VydmljZSAibG9vayBhdCB0aGlzIHBhcnQs IGJ1dCBkbyBub3QgYWRhcHQgaXQiOyBXZSBkbyBub3QgbmVlZCBzdWNoDQogICBhIGZlYXR1cmUs IGRvIHdlPykNCg0KMi4yLjIgUHJvZmlsZSBTdHJ1Y3R1cmUNCg0KICAgQW4gSFRUUCBhcHBsaWNh dGlvbiBwcm9maWxlIGZlYXR1cmUgZXh0ZW5kcyB0aGUgRmVhdHVyZSB0eXBlIG9mIE9DUA0KICAg Y29yZSBhbmQgYWRkcyBhZGRpdGlvbmFsIG5hbWVkIHBhcmFtZXRlcnMuIEhUVFAtUHJvZmlsZXMg Y2FuIGJlIHVzZWQNCiAgIGluIGZlYXR1cmUgbGlzdHMgb2YgTmVnb3RpYXRpb24gT2ZmZXIgKE5P KSBtZXNzYWdlcyBhbmQgYW4NCiAgIEhUVFAtUG9maWxlIGNhbiBiZSB1c2VkIGluIHRoZSBOZWdv dGlhdGlvbiBSZXNwb25zZSAoTlIpIG1lc3NhZ2UuDQoNCiAgIG8gIEF1eC1QYXJ0cyAoU2VjdGlv biAyLjIuMykNCg0KICAgbyAgUGF1c2UtQXQtQm9keSAoU2VjdGlvbiAyLjIuNCkNCg0KDQoNClJv dXNza292ICYgU3RlY2hlciAgICAgICBFeHBpcmVzIEFwcmlsIDI2LCAyMDA0ICAgICAgICAgICAg ICAgICBbUGFnZSA2XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICBIVFRQIGFkYXB0YXRpb24g d2l0aCBPUEVTICAgICAgICAgICAgT2N0b2JlciAyMDAzDQoNCg0KICAgbyAgV29udC1Mb29rLUJv ZHkgKFNlY3Rpb24gMi4yLjUpDQoNCiAgIG8gIFdvbnQtU2VuZC1Cb2R5IChTZWN0aW9uIDIuMi42 KQ0KDQogICBvICBDb250ZW50LUVuY29kaW5ncyAoU2VjdGlvbiAyLjIuNykNCg0KICAgVGhpcyBp cyB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgSFRUUCBwcm9maWxlIGZlYXR1cmUgc3RydWN0dXJlIHVz aW5nDQogICBURE06DQoNCiAgIAkJSFRUUC1Qcm9maWxlOiBleHRlbmRzIEZlYXR1cmUgd2l0aCB7 DQogICAJCVtBdXgtUGFydHM6IGFtLXBhcnRzXTsNCiAgIAkJW1BhdXNlLUF0LUJvZHk6IHNpemVd Ow0KICAgCQlbV29udC1Mb29rLUJvZHk6IHNpemVdOw0KICAgCQlbV29udC1TZW5kLUJvZHk6IHNp emVdOw0KICAgCQlbQ29udGVudC1FbmNvZGluZ3M6IGNvZGluZ3NdOw0KICAgCQl9Ow0KDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAyDQoNCg0KMi4yLjMgQXV4LVBhcnRz DQoNCiAgIFRoZSBBdXgtUGFydHMgcGFyYW1ldGVyIG9mIGFuIEhUVFAgcmVzcG9uc2UgcHJvZmls ZSBjYW4gYmUgdXNlZCB0bw0KICAgbmVnb3RpYXRlIHRoZSBpbmNsdXNpb24gb2YgYXV4aWxpYXJ5 IGFwcGxpY2F0aW9uIG1lc3NhZ2UgcGFydHMgaW50bw0KICAgdGhlIG9yaWdpbmFsIGRhdGEgZmxv dy4gVGhlIHBhcmFtZXRlciBpcyBhIHBvc3NpYmx5IGVtcHR5IGxpc3Qgb2YNCiAgIGFtLXBhcnQg dG9rZW5zLiBBbiBPUEVTIHByb2Nlc3NvciBNQVkgc2VuZCBhbiBBdXgtUGFydHMgcGFyYW1ldGVy IHRvDQogICBhZHZlcnRpc2UgYXZhaWxhYmlsaXR5IG9mIGF1eGlsaWFyeSBhcHBsaWNhdGlvbiBt ZXNzYWdlIHBhcnRzLiBBDQogICBjYWxsb3V0IHNlcnZlciBNQVkgcmVzcG9uZCB3aXRoIGEgcG9z c2libHkgZW1wdHkgc3Vic2V0IG9mIHRoZSBwYXJ0cw0KICAgaXQgbmVlZHMuIFRoZSBjYWxsb3V0 IHNlcnZlciByZXNwb25zZSBkZWZpbmVzIHRoZSBzdWJzZXQgb2YNCiAgIHN1Y2Nlc3NmdWxseSBu ZWdvdGlhdGVkIGF1eGlsaWFyeSBtZXNzYWdlIHBhcnRzLg0KDQogICBBbiBPUEVTIHByb2Nlc3Nv ciBNVVNUIE5PVCBpbmNsdWRlIGFueSBtZXNzYWdlIHBhcnQgd2hpY2ggaXMgbm90DQogICBtYXJr ZWQgYXMgYXV4aWxpYXJ5IHBhcnQgaW4gdGhlIGxpc3Qgb2Ygb3JpZ2luYWwgcGFydHMgZm9yIHRo ZSBnaXZlbg0KICAgcHJvZmlsZS4gVGhlIGNhbGxvdXQgc2VydmVyIE1VU1QgaWdub3JlIG5vbi1h dXhpbGlhcnkgcGFydHMgbGlzdGVkIGluDQogICB0aGUgQXV4LVBhcnRzIHBhcmFtZXRlci4gVGhl IGNhbGxvdXQgc2VydmVyIE1VU1QgTk9UIGluY2x1ZGUgYW55DQogICBtZXNzYWdlIHBhcnQgdGhh dCB3YXMgbm90IGV4cGxpY2l0bHkgbGlzdGVkIGluIHRoZSBuZWdvdGlhdGlvbiBvZmZlci4NCiAg IEluIGNhc2Ugb2YgYSB2aW9sYXRpb24gb2YgdGhpcyBydWxlIHRoZSBPUEVTIHByb2Nlc3NvciBN VVNUIHRlcm1pbmF0ZQ0KICAgdGhlIHRyYW5zYWN0aW9uLg0KDQogICBBbiBPUEVTIHByb2Nlc3Nv ciBNVVNUIHNlbmQgZWFjaCBuZWdvdGlhdGVkIGF1eGlsaWFyeSBwYXJ0IHRvIHRoZQ0KICAgY2Fs bG91dCBzZXJ2ZXIsIHVubGVzcyB0aGUgcGFydCBpcyBhYnNlbnQuDQoNCiAgIAkJRXhhbXBsZToN CiAgIAkJICAgICBBdXgtUGFydHM6IChyZXF1ZXN0LWhlYWRlcixyZXF1ZXN0LWJvZHkpDQoNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDMNCg0KDQoNCg0KDQpSb3Vzc2tv diAmIFN0ZWNoZXIgICAgICAgRXhwaXJlcyBBcHJpbCAyNiwgMjAwNCAgICAgICAgICAgICAgICAg W1BhZ2UgN10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgSFRUUCBhZGFwdGF0aW9uIHdpdGgg T1BFUyAgICAgICAgICAgIE9jdG9iZXIgMjAwMw0KDQoNCjIuMi40IFBhdXNlLUF0LUJvZHkNCg0K ICAgVGhlIHBhcmFtZXRlciBQYXVzZS1BdC1Cb2R5IGNhbiBiZSB1c2VkIHRvIHByZS1yZXF1ZXN0 IGEgcGF1c2UgaW4NCiAgIGFwcGxpY2F0aW9uIG1lc3NhZ2UgYm9keSBwYXJ0IHRyYW5zbWlzc2lv bi4gVGhlIHBhcmFtZXRlcidzIHZhbHVlIGlzDQogICBvZiB0eXBlICJzaXplIiBhbmQgZGVub21p bmF0ZXMgYW4gb2Zmc2V0IGludG8gdGhlIG9yaWdpbmFsLA0KICAgbm9uLWF1eGlsaWFyeSBtZXNz YWdlIGJvZHkgcGFydCAocmVxdWVzdC1ib2R5IGluIEhUVFAgcmVxdWVzdCBwcm9maWxlDQogICBh bmQgcmVzcG9uc2UtYm9keSBpbiByZXNwb25zZSBwcm9maWxlKS4NCg0KICAgQSBjYWxsb3V0IHNl cnZpY2UgTUFZIHNlbmQgYSBQYXVzZS1BdC1Cb2R5IHBhcmFtZXRlciB0byByZXF1ZXN0IHRoZQ0K ICAgcGF1c2UuIEFuIE9QRVMgcHJvY2Vzc29yIFNIT1VMRCBiZWhhdmUgYXMgaWYgaXQgcmVjZWl2 ZXMgYSBkYXRhLXBhdXNlDQogICBtZXNzYWdlIGF0IHRoZSB0aW1lIHRoYXQgaXQgd2lsbCBoYXZl IHNlbnQgdGhlIGdpdmVuIG51bWJlciBvZiBPQ1RFVHMNCiAgIG9mIHRoZSBhcHBsaWNhdGlvbiBt ZXNzYWdlIGJvZHkgcGFydC4NCg0KICAgRm9yIGV4YW1wbGUsIGlmIHRoZSBQYXVzZS1BdC1Cb2R5 IHZhbHVlIGlzIHplcm8sIHRoZSBPUEVTIHByb2Nlc3Nvcg0KICAgU0hPVUxEIHNlbmQgYSBkYXRh LXBhdXNlZCBtZXNzYWdlIGp1c3QgYmVmb3JlIGl0IHNlbmRzIHRoZSBmaXJzdCBEVU0NCiAgIG1l c3NhZ2Ugd2l0aCB0aGUgcmVzcG9uc2UtYm9keSBwYXJ0IGluIHRoZSBIVFRQIHJlc3BvbnNlIHBy b2ZpbGUsIGFuZA0KICAgaWYgdGhlIHBhcmFtZXRlcidzIHZhbHVlIGlzIDMwMCwgdGhlIE9QRVMg cHJvY2Vzc29yIFNIT1VMRCBzZW5kIGENCiAgIGRhdGEtcGF1c2VkIG1lc3NhZ2UgYWZ0ZXIgdHJh bnNtaXR0aW5nIDMwMCBPQ1RFVHMgZm9yIHRoYXQNCiAgIGFwcGxpY2F0aW9uIG1lc3NhZ2UgcGFy dC4NCg0KICAgCQlFeGFtcGxlOg0KICAgCQkgICAgIFBhdXNlLUF0LUJvZHk6IDANCg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgNA0KDQoNCjIuMi41IFdvbnQtTG9vay1C b2R5DQoNCiAgIFRoZSBwYXJhbWV0ZXIgV29udC1Mb29rLUJvZHkgY2FuIGJlIHVzZWQgdG8gZ2Vu ZXJhbGl6ZSBXb250LUxvb2sNCiAgIG1lc3NhZ2UgYmVoYXZpb3IgZm9yIGFsbCB0cmFuc2FjdGlv bnMgb2YgYSBwcm9maWxlLiBUaGUgcGFyYW1ldGVyJ3MNCiAgIHZhbHVlIGlzIG9mIHR5cGUgInNp emUiIGFuZCBkZW5vbWluYXRlcyBhbiBvZmZzZXQgaW50byB0aGUgb3JpZ2luYWwsDQogICBub24t YXV4aWxpYXJ5IG1lc3NhZ2UgYm9keSBwYXJ0IChyZXF1ZXN0LWJvZHkgaW4gSFRUUCByZXF1ZXN0 IHByb2ZpbGUNCiAgIGFuZCByZXNwb25zZS1ib2R5IGluIHJlc3BvbnNlIHByb2ZpbGUpLg0KDQog ICBBIGNhbGxvdXQgc2VydmljZSBNQVkgc2VuZCBhIFdvbnQtTG9vay1Cb2R5IHBhcmFtZXRlciB3 aXRoIGl0cw0KICAgbmVnb3RpYXRpb24gcmVzcG9uc2UgaWYgdGhlcmUgaXMgYSBmaXhlZCBvZmZz ZXQgaW50byB0aGUgbWVzc2FnZSBib2R5DQogICBmb3IgYWxsIHRyYW5zYWN0aW9ucyBvZiBhIHBy b2ZpbGUgYXQgd2hpY2ggYSBEYXRhIFdvbid0IExvb2sgQXQgWW91cnMNCiAgIChEV0xZKSBtZXNz YWdlIHdvdWxkIGJlIHNlbnQuIEFuIE9QRVMgcHJvY2Vzc29yIFNIT1VMRCBiZWhhdmUgYXMgaWYN CiAgIGl0IHJlY2VpdmVzIGEgRFdMWSBtZXNzYWdlIGF0IHRoZSB0aW1lIHRoYXQgaXQgd2lsbCBo YXZlIHNlbnQgdGhlDQogICBnaXZlbiBudW1iZXIgb2YgT0NURVRzIG9mIHRoZSBhcHBsaWNhdGlv biBtZXNzYWdlIGJvZHkgcGFydC4NCg0KICAgRm9yIGV4YW1wbGUsIGlmIHRoZSBXb250LUxvb2st Qm9keSB2YWx1ZSBpcyB6ZXJvIGluIGFuIEhUVFAgcmVzcG9uc2UNCiAgIHByb2ZpbGUsIHRoZSBP UEVTIHByb2Nlc3NvciBTSE9VTEQgc2VuZCBhbiBBTUUgbWVzc2FnZSB3aXRoIHJlc3VsdA0KICAg Y29kZSAyMDYgYWZ0ZXIgc2VuZGluZyB0aGUgcmVzcG9uc2UtaGVhZGVyIG1lc3NhZ2UgcGFydCBh bmQgYmVmb3JlDQogICBzdGFydGluZyB3aXRoIHRoZSByZXNwb25zZS1ib2R5IG1lc3NhZ2UgcGFy dC4NCg0KICAgCQlFeGFtcGxlOg0KICAgCQkgICAgIFdvbnQtTG9vay1Cb2R5OiAwDQoNCg0KDQpS b3Vzc2tvdiAmIFN0ZWNoZXIgICAgICAgRXhwaXJlcyBBcHJpbCAyNiwgMjAwNCAgICAgICAgICAg ICAgICAgW1BhZ2UgOF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgSFRUUCBhZGFwdGF0aW9u IHdpdGggT1BFUyAgICAgICAgICAgIE9jdG9iZXIgMjAwMw0KDQoNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgRmlndXJlIDUNCg0KDQoyLjIuNiBXb250LVNlbmQtQm9keQ0KDQogICBU aGUgcGFyYW1ldGVyIFdvbnQtU2VuZC1Cb2R5IGNhbiBiZSB1c2VkIHRvIG9wdGltaXplIHRoZSBk YXRhDQogICBwcmVzZXJ2YXRpb24gY29tbWl0bWVudCBvZiB0aGUgT1BFUyBwcm9jZXNzb3IuIFRo ZSBwYXJhbWV0ZXIncyB2YWx1ZQ0KICAgaXMgb2YgdHlwZSAic2l6ZSIgYW5kIGRlbm9taW5hdGVz IGFuIG9mZnNldCBpbnRvIHRoZSBvcmlnaW5hbCwNCiAgIG5vbi1hdXhpbGlhcnkgbWVzc2FnZSBi b2R5IHBhcnQgKHJlcXVlc3QtYm9keSBpbiBIVFRQIHJlcXVlc3QgcHJvZmlsZQ0KICAgYW5kIHJl c3BvbnNlLWJvZHkgaW4gcmVzcG9uc2UgcHJvZmlsZSkuDQoNCiAgIEEgY2FsbG91dCBzZXJ2aWNl IE1BWSBzZW5kIGEgV29udC1TZW5kLUJvZHkgcGFyYW1ldGVyIHdpdGggaXRzDQogICBuZWdvdGlh dGlvbiByZXNwb25zZSBpZiB0aGVyZSBpcyBhIGZpeGVkIG9mZnNldCBpbnRvIHRoZSBtZXNzYWdl IGJvZHkNCiAgIGZvciBhbGwgdHJhbnNhY3Rpb25zIG9mIGEgcHJvZmlsZSBhdCB3aGljaCBhIERh dGEgV29uJ3QgU2VuZCBZb3Vycw0KICAgKERXU1kpIG1lc3NhZ2Ugd291bGQgYmUgc2VudC4gQW4g T1BFUyBwcm9jZXNzb3IgU0hPVUxEIGJlaGF2ZSBhcyBpZg0KICAgaXQgcmVjZWl2ZXMgYSBEV1NZ IG1lc3NhZ2UgYXQgdGhlIHRpbWUgdGhhdCBpdCB3aWxsIGhhdmUgc2VudCB0aGUNCiAgIGdpdmVu IG51bWJlciBvZiBPQ1RFVHMgb2YgdGhlIGFwcGxpY2F0aW9uIG1lc3NhZ2UgYm9keSBwYXJ0Lg0K DQogICBGb3IgZXhhbXBsZSwgaWYgdGhlIFdvbnQtU2VuZC1Cb2R5IHZhbHVlIGlzIDIxNDc0ODM2 NDcgaW4gYW4gSFRUUA0KICAgcmVzcG9uc2UgcHJvZmlsZSwgdGhlIGNhbGxvdXQgc2VydmVyIE1V U1QgTk9UIHNlbmQgYW55IERVWSBtZXNzYWdlDQogICBmb3IgdGhlIHJlc3BvbnNlLWJvZHkgcGFy dDsgdGhlIE9QRVMgcHJvY2Vzc29yIE1BWSB1c2UgdGhpcyB0bw0KICAgb3B0aW1pemUgaXRzIGRh dGEgcHJlc2VydmF0aW9uIGJlaGF2aW9yLg0KDQogICAJCUV4YW1wbGU6DQogICAJCSAgICAgV29u dC1TZW5kLUJvZHk6IDIxNDc0ODM2NDcNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBGaWd1cmUgNg0KDQoNCjIuMi43IENvbnRlbnQtRW5jb2RpbmdzDQoNCiAgIEEgY2FsbG91dCBz ZXJ2ZXIgTUFZIHNlbmQgYSBDb250ZW50LUVuY29kaW5ncyBsaXN0IHRvIGluZGljYXRlIGl0cw0K ICAgcHJlZmVyZW5jZXMgaW4gY29udGVudCBlbmNvZGluZ3MuIEVuY29kaW5ncyBsaXN0ZWQgZmly c3QgYXJlDQogICBwcmVmZXJyZWQgdG8gb3RoZXIgZW5jb2RpbmdzLiBBbiBPUEVTIHByb2Nlc3Nv ciBNQVkgdXNlIGFueSBjb250ZW50DQogICBlbmNvZGluZyB3aGVuIHNlbmRpbmcgYXBwbGljYXRp b24gbWVzc2FnZXMgdG8gYSBjYWxsb3V0IHNlcnZlci4NCg0KICAgVGhlIGxpc3Qgb2YgcHJlZmVy cmVkIGNvbnRlbnQgZW5jb2RpbmdzIGRvZXMgbm90IGltcGx5IGxhY2sgb2YNCiAgIHN1cHBvcnQg Zm9yIG90aGVyIGVuY29kaW5ncy4gVGhlIE9QRVMgcHJvY2Vzc29yIE1VU1QgTk9UIGJ5cGFzcyBh DQogICBzZXJ2aWNlIGp1c3QgYmVjYXVzZSB0aGUgYWN0dWFsIGNvbnRlbnQgZW5jb2RpbmcgZG9l cyBub3QgbWF0Y2ggdGhlDQogICBzZXJ2aWNlJ3MgcHJlZmVyZW5jZXMuDQoNCiAgIElmIGFuIE9D UCBhZ2VudCByZWNlaXZlcyBhbiBhcHBsaWNhdGlvbiBtZXNzYWdlIHRoYXQgaXQgY2Fubm90IGhh bmRsZQ0KICAgZHVlIHRvIHNwZWNpZmljIGNvbnRlbnQgZW5jb2RpbmcsIHRoZSB1c3VhbCB0cmFu c2FjdGlvbiB0ZXJtaW5hdGlvbg0KICAgcnVsZXMgYXBwbHkuDQoNCiAgIAkJY29udGVudC1jb2Rp bmc6IGV4dGVuZHMgYXRvbTsNCiAgIAkJY29udGVudC1jb2RpbmdzOiBleHRlbmRzIGxpc3Qgb2Yg Y29udGVudC1jb2Rpbmc7DQoNCg0KDQoNClJvdXNza292ICYgU3RlY2hlciAgICAgICBFeHBpcmVz IEFwcmlsIDI2LCAyMDA0ICAgICAgICAgICAgICAgICBbUGFnZSA5XQ0KDA0KSW50ZXJuZXQtRHJh ZnQgICAgICAgICBIVFRQIGFkYXB0YXRpb24gd2l0aCBPUEVTICAgICAgICAgICAgT2N0b2JlciAy MDAzDQoNCg0KICAgCQlFeGFtcGxlOg0KICAgCQkgICAgIENvbnRlbnQtRW5jb2RpbmdzOiAoZ3pp cCkNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgNw0KDQogICBUaGUg c2VtYW50aWNzIG9mIGNvbnRlbnQtY29kaW5nIGlzIGRlZmluZWQgaW4gc2VjdGlvbiAzLjUgb2YN CiAgIFtSRkMyNjE2XS4NCg0KMi4yLjggUHJvZmlsZSBOZWdvdGlhdGlvbiBFeGFtcGxlDQoNCiAg IAkJRXhhbXBsZToNCiAgIAkJCSBOTyAoeyIzODpodHRwOi8vaWFuYS5vcmcvb3Blcy9vY3AvSFRU UC9yZXNwb25zZSINCiAgIAkJCSBBdXgtUGFydHM6IChyZXF1ZXN0LWhlYWRlcixyZXF1ZXN0LWJv ZHkpDQogICAJCQkgfSkNCiAgIAkJCSBTRzogNTsNCiAgIAkJCSBOUiB7IjM4Omh0dHA6Ly9pYW5h Lm9yZy9vcGVzL29jcC9IVFRQL3Jlc3BvbnNlIg0KICAgCQkJIEF1eC1QYXJ0czogKHJlcXVlc3Qt aGVhZGVyKQ0KICAgCQkJIFBhdXNlLUF0LUJvZHk6IDMwDQogICAJCQkgV29udC1TZW5kLUJvZHk6 IDIxNDc0ODM2NDcNCiAgIAkJCSBDb250ZW50LUVuY29kaW5nczogKGd6aXApDQogICAJCQkgfQ0K ICAgCQkJIFNHOiA1Ow0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSA4 DQoNCiAgIFRoaXMgZXhhbXBsZSBzaG93cyBhIG5lZ290aWF0aW9uIG9mZmVyIG1hZGUgYnkgYW4g T1BFUyBwcm9jZXNzb3IgZm9yDQogICBhIHNlcnZpY2UgZ3JvdXAgKGlkIDUpIHRoYXQgaGFzIGFs cmVhZHkgYmVlbiBjcmVhdGVkOyB0aGUgY2FsbG91dA0KICAgc2VydmVyIHNlbmRzIGFuIGFkZXF1 YXRlIG5lZ290aWF0aW9uIHJlc3BvbnNlLg0KDQogICBUaGUgT1BFUyBwcm9jZXNzb3Igb2ZmZXJz IG9uZSBwcm9maWxlIGZlYXR1cmUgZm9yIEhUVFAgcmVzcG9uc2UNCiAgIG1lc3NhZ2VzLiAgQmVz aWRlcyB0aGUgc3RhbmRhcmQgbWVzc2FnZSBwYXJ0cywgdGhlIE9QRVMgcHJvY2Vzc29yIGlzDQog ICBhYmxlIHRvIGFkZCB0aGUgaGVhZGVyIGFuZCBib2R5IG9mIHRoZSBvcmlnaW5hbCBIVFRQIHJl cXVlc3QgYXMNCiAgIGF1eGlsaWFyeSBtZXNzYWdlIHBhcnRzLg0KDQogICBUaGUgY2FsbG91dCBz ZXJ2ZXIgcmVxdWVzdHMgdGhlIGF1eGlsaWFyeSByZXF1ZXN0LWhlYWRlciBtZXNzYWdlDQogICBw YXJ0OyBpdCBpcyBub3QgaW50ZXJlc3RlZCBpbiBlaXRoZXIgdGhlIGF1eGlsaWFyeSByZXF1ZXN0 LWJvZHkgb3IgaW4NCiAgIHRoZSByZXNwb25zZS1ib2R5IHBhcnQgdGhhdCBpdCByZXF1ZXN0cyB0 byBza2lwLg0KDQogICBUaGUgT1BFUyBwcm9jZXNzb3Igc2VuZHMgdGhlIGZvbGxvd2luZyBtZXNz YWdlIHBhcnRzLCBpbiB0aGUNCiAgIHNwZWNpZmllZCBvcmRlciwgZm9yIGFsbCB0cmFuc2FjdGlv bnMgaW4gc2VydmljZSBncm91cCA1Og0KICAgcmVxdWVzdC1oZWFkZXIsIHJlc3BvbnNlLWhlYWRl ciwgcmVzcG9uc2UtYm9keSwgcmVzcG9uc2UtdHJhaWxlci4NCiAgIE5vdGUgdGhhdCB0aGUgcmVx dWVzdC1ib2R5IHBhcnQgaXMgbm90IGluY2x1ZGVkIChiZWNhdXNlIGl0IGlzIGFuDQogICBhdXhp bGlhcnkgcGFydHMgYW5kIG5vdCBleHBsaWNpdGx5IHJlcXVlc3RlZCkuDQoNCiAgIFRoZSBjYWxs b3V0IHNlcnZlciBpbmRpY2F0ZXMgdGhyb3VnaCB0aGUgV29udC1TZW5kLUJvZHkgcGFyYW1ldGVy DQogICB3aXRoIHRoZSBtYXhpbXVtIHNpemUgdmFsdWUgdGhhdCBpdCB3aWxsIG5vdCBzZW5kIGFu eSBEVVkgbWVzc2FnZXMuDQogICBUaGUgT1BFUyBwcm9jZXNzb3IgbWF5IHRoZXJlZm9yZSByZXNp Z24gZnJvbSBkYXRhIHByZXNlcnZhdGlvbiBmb3INCiAgIGFsbCB0cmFuc2FjdGlvbiBvZiB0aGlz IHByb2ZpbGU7IG5vbmUgb2YgaXRzIERVTSBtZXNzYWdlcyB3aWxsIGhhdmUgYQ0KDQoNCg0KUm91 c3Nrb3YgJiBTdGVjaGVyICAgICAgIEV4cGlyZXMgQXByaWwgMjYsIDIwMDQgICAgICAgICAgICAg ICAgW1BhZ2UgMTBdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgIEhUVFAgYWRhcHRhdGlvbiB3 aXRoIE9QRVMgICAgICAgICAgICBPY3RvYmVyIDIwMDMNCg0KDQogICBLZXB0IHBhcmFtZXRlci4N Cg0KICAgQnkgc2VuZGluZyBhIFBhdXNlLUF0LUJvZHkgdmFsdWUgb2YgMzAsIHRoZSBjYWxsb3V0 IHNlcnZpY2UgcmVxdWVzdHMNCiAgIGEgZGF0YS1wYXVzZWQgbWVzc2FnZSB0aGF0IHRoZSBPUEVT IHByb2Nlc3NvciB3aWxsIHNlbmQgYWZ0ZXIgc2VuZGluZw0KICAgMzAgT0NURVRzIG9mIHRoZSBy ZXNwb25zZS1ib2R5IHBhcnQgb2YgYW55IHRyYW5zYWN0aW9uIGZvciB0aGlzDQogICBwcm9maWxl LiBUaGVyZWFmdGVyLCB0aGUgT1BFUyBwcm9jZXNzb3Igd2lsbCB3YWl0IGZvciBkYXRhLW5lZWQN CiAgIG1lc3NhZ2Ugb2YgdGhlIGNhbGxvdXQgc2VydmljZS4NCg0KMi4zIEFwcGxpY2F0aW9uIE1l c3NhZ2UgU3RhcnQgTWVzc2FnZQ0KDQogICBBIG5ldyBuYW1lZCBwYXJhbWV0ZXIgZm9yIEFwcGxp Y2F0aW9uIE1lc3NhZ2UgU3RhcnQgKEFNUykgbWVzc2FnZXMgaXMNCiAgIGludHJvZHVjZWQuDQoN Cg0KICAgCQlBTS1FTDogc2l6ZQ0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg RmlndXJlIDkNCg0KICAgQW4gT0NQIEFnZW50IHRoYXQga25vd3MgdGhlIGV4YWN0IGxlbmd0aCBv ZiB0aGUgSFRUUCBtZXNzYWdlIGVudGl0eQ0KICAgKFNlY3Rpb24gNy4yLjIgRW50aXR5IExlbmd0 aCBpbiBbUkZDMjYxNl0pIGF0IHRoZSB0aW1lIGl0IHNlbmRzIHRoZQ0KICAgQU1TIG1lc3NhZ2Us IFNIT1VMRCBhbm5vdW5jZSB0aGlzIGxlbmd0aCB1c2luZyB0aGUgQU0tRUwgbmFtZWQNCiAgIHBh cmFtZXRlciBvZiBhbiBBTVMgbWVzc2FnZS4gSWYgdGhlIGVudGl0eSBsZW5ndGggaXMgbm90IGtu b3duLCB0aGUNCiAgIEFNLUVMIHBhcmFtZXRlciBNVVNUIGJlIG9taXR0ZWQuIFJlcG9ydGluZyBj b3JyZWN0IGVudGl0eSBsZW5ndGggY2FuDQogICBoYXZlIHNpZ25pZmljYW50IHBlcmZvcm1hbmNl IGFkdmFudGFnZXMgZm9yIHRoZSByZWNpcGllbnRzLCBhbmQNCiAgIGltcGxlbWVudGF0aW9ucyBh cmUgc3Ryb25nbHkgZW5jb3VyYWdlZCB0byBzdXBwb3J0IHRoaXMgcnVsZS4NCiAgIFNpbWlsYXJs eSwgcmVwb3J0aW5nIGluY29ycmVjdCBlbnRpdHkgbGVuZ3RoIGNhbiBoYXZlIGRyYXN0aWMNCiAg IGNvcnJlY3RuZXNzIGNvbnNlcXVlbmNlcyBmb3IgdGhlIHJlY2lwaWVudHMsIGFuZCBpbXBsZW1l bnRhdGlvbnMgYXJlDQogICB1cmdlZCB0byBleGVyY2lzZSBncmVhdCBjYXJlIHdoZW4gcmVwb3J0 aW5nIGVudGl0eSBsZW5ndGguDQoNCiAgIEFzIGRlZmluZWQgYnkgSFRUUCwgQU0tRUwgaXMgdGhl IGxlbmd0aCBvZiB0aGUgcmVxdWVzdC1ib2R5IHBhcnQgaW4NCiAgIHRoZSBIVFRQIHJlcXVlc3Qg cHJvZmlsZSwgYW5kIGlzIHRoZSBsZW5ndGggb2YgdGhlIHJlc3BvbnNlLWJvZHkgcGFydA0KICAg aW4gdGhlIEhUVFAgcmVzcG9uc2UgcHJvZmlsZSwgYmVmb3JlIGFueSB0cmFuc2ZlciBjb2Rpbmdz IGhhdmUgYmVlbg0KICAgYXBwbGllZC4NCg0KICAgQW4gT1BFUyBwcm9jZXNzb3IgcmVjZWl2aW5n IGFuIEFNLUVMIHBhcmFtZXRlciBTSE9VTEQgdXNlIHRoZQ0KICAgcGFyYW1ldGVyJ3MgdmFsdWUg aW4gYSBDb250ZW50LUxlbmd0aCBIVFRQIGVudGl0eSBoZWFkZXIgd2hlbg0KICAgY29uc3RydWN0 aW5nIGFuIEhUVFAgbWVzc2FnZSwgcHJvdmlkZWQgYSBDb250ZW50LUxlbmd0aCBIVFRQIGVudGl0 eQ0KICAgaGVhZGVyIGlzIGFsbG93ZWQgZm9yIHRoZSBnaXZlbiBhcHBsaWNhdGlvbiBtZXNzYWdl IGJ5IEhUVFAgKHNlZQ0KICAgIk1lc3NhZ2UgU2l6ZSBSZWNhbGN1bGF0aW9uIiAoU2VjdGlvbiAy LjYuMSkpLg0KDQoyLjQgRGF0YSBVc2UgTWluZSBNZXNzYWdlDQoNCiAgIEEgbmV3IG5hbWVkIHBh cmFtZXRlciBmb3IgRGF0YSBVc2UgTWluZSAoRFVNKSBtZXNzYWdlcyBpcyBpbnRyb2R1Y2VkLg0K DQoNCiAgIAkJQU0tUGFydDogYW0tcGFydA0KDQoNCg0KDQpSb3Vzc2tvdiAmIFN0ZWNoZXIgICAg ICAgRXhwaXJlcyBBcHJpbCAyNiwgMjAwNCAgICAgICAgICAgICAgICBbUGFnZSAxMV0NCgwNCklu dGVybmV0LURyYWZ0ICAgICAgICAgSFRUUCBhZGFwdGF0aW9uIHdpdGggT1BFUyAgICAgICAgICAg IE9jdG9iZXIgMjAwMw0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUg MTANCg0KICAgQW4gT0NQIGFnZW50IE1VU1QgdXNlIGFuIEFNLVBhcnQgcGFyYW1ldGVyIHdpdGgg ZXZlcnkgRFVNIG1lc3NhZ2UNCiAgIHRoYXQgaXMgYSBwYXJ0IG9mIGFuIE9DUCB0cmFuc2FjdGlv biB3aXRoIGFuIEhUVFAgcHJvZmlsZS4gVGhlDQogICBBTS1QYXJ0IHBhcmFtZXRlciB2YWx1ZSBp cyBhIHNpbmdsZSBhbS1wYXJ0IHRva2VuLiBBcyBpbXBsaWVkIGJ5IHRoZQ0KICAgc3ludGF4LCBh IERVTSBtZXNzYWdlIGNhbiBvbmx5IGNvbnRhaW4gZGF0YSBvZiBhIHNpbmdsZSBhcHBsaWNhdGlv bg0KICAgbWVzc2FnZSBwYXJ0LiBPbmUgbWVzc2FnZSBwYXJ0IGNhbiBiZSBmcmFnbWVudGVkIGlu dG8gYW55IG51bWJlciBvZg0KICAgRFVNIG1lc3NhZ2VzIHdpdGggdGhlIHNhbWUgQU0tUGFydCBw YXJhbWV0ZXIuDQoNCiAgIFRoZSBmb2xsb3dpbmcgZXhhbXBsZSBzaG93cyB0aHJlZSBEVU0gbWVz c2FnZXMgY29udGFpbmluZyBhIHZlcnkNCiAgIHNpbXBsZSBhbmQgcmVkdWNlZCBIVFRQIHJlc3Bv bnNlIG1lc3NhZ2UuIFRoZSByZXNwb25zZS1ib2R5IHBhcnQgaXMNCiAgIGZyYWdtZW50ZWQgYW5k IHNlbnQgd2l0aGluIHR3byBEVU0gbWVzc2FnZXMuDQoNCg0KICAgCQlEVU0gODggMSAwDQogICAJ CUtlcHQ6IDANCiAgIAkJQU0tUGFydDogcmVzcG9uc2UtaGVhZGVyDQoNCiAgIAkJNjQ6SFRUUC8x LjEgMjAwIE9LDQogICAJCUNvbnRlbnQtVHlwZTogdGV4dC9odG1sDQogICAJCUNvbnRlbnQtTGVu Z3RoOiA1MQ0KDQogICAJCTsNCiAgIAkJRFVNIDg4IDEgNjQNCiAgIAkJS2VwdDogNjQNCiAgIAkJ QU0tUGFydDogcmVzcG9uc2UtYm9keQ0KDQogICAJCTE5OjxodG1sPjxib2R5PlRoaXMgaXM7DQog ICAJCURVTSA4OCAxIDgzDQogICAJCUtlcHQ6IDgzDQogICAJCUFNLVBhcnQ6IHJlc3BvbnNlLWJv ZHkNCg0KICAgCQkzMjogYSBzaW1wbGUgbWVzc2FnZS48L2JvZHk+PC9odG1sPjsNCg0KDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDExDQoNCg0KMi41IFRyYW5zZmVyIEVu Y29kaW5ncw0KDQogICBBZGFwdGF0aW9ucyB0aGF0IHVzZSBIVFRQIHRyYW5zZmVyIGVuY29kaW5n cyBNVVNUIGJlIGV4cGxpY2l0bHkNCiAgIG5lZ290aWF0ZWQuIFRoaXMgc3BlY2lmaWNhdGlvbiBk b2VzIG5vdCBkb2N1bWVudCBzdWNoIG5lZ290aWF0aW9ucy4NCg0KICAgSW4gdGhlIGFic2VuY2Ug b2YgZXhwbGljaXQgdHJhbnNmZXItZW5jb2RpbmcgbmVnb3RpYXRpb25zLCBhbiBPQ1ANCiAgIGFn ZW50IE1VU1QgTk9UIHNlbmQgdHJhbnNmZXItZW5jb2RlZCBhcHBsaWNhdGlvbiBtZXNzYWdlcy4N CiAgIEluZm9ybWFsbHksIHRoaXMgbWVhbnMgdGhhdCB0aGUgYWdlbnQgb3IgaXRzIGVudmlyb25t ZW50IGhhdmUgdG8gbWFrZQ0KICAgc3VyZSB0aGF0IGFsbCB0cmFuc2ZlciBlbmNvZGluZ3MgYXJl IHN0cmlwcGVkIGJlZm9yZSBhbiBhcHBsaWNhdGlvbg0KICAgbWVzc2FnZSBlbnRlcnMgT0NQIHNj b3BlLiBBbiBhZ2VudCBNVVNUIHRlcm1pbmF0ZSBhbiBPQ1AgdHJhbnNhY3Rpb24NCg0KDQoNClJv dXNza292ICYgU3RlY2hlciAgICAgICBFeHBpcmVzIEFwcmlsIDI2LCAyMDA0ICAgICAgICAgICAg ICAgIFtQYWdlIDEyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICBIVFRQIGFkYXB0YXRpb24g d2l0aCBPUEVTICAgICAgICAgICAgT2N0b2JlciAyMDAzDQoNCg0KICAgaWYgaXQgY2Fubm90IHJl bW92ZSBhbGwgdHJhbnNmZXIgZW5jb2RpbmdzLiBWaW9sYXRpb25zIG9mIHRoZXNlIHJ1bGVzDQog ICB3b3VsZCBsZWFkIHRvIGludGVyb3BlcmFiaWxpdHkgcHJvYmxlbXMuDQoNCiAgIElmIGFuIE9D UCBhZ2VudCByZWNlaXZlcyB0cmFuc2Zlci1lbmNvZGVkIGFwcGxpY2F0aW9uIGRhdGEgaW4NCiAg IHZpb2xhdGlvbiBvZiB0aGUgYWJvdmUgcmVxdWlyZW1lbnQsIHRoZSBhZ2VudCBNQVkgdGVybWlu YXRlIHRoZQ0KICAgY29ycmVzcG9uZGluZyBPQ1AgdHJhbnNhY3Rpb24uDQoNCiAgIEFuIE9QRVMg cHJvY2Vzc29yIHJlbW92aW5nIHRyYW5zZmVyIGVuY29kaW5ncyBTSE9VTEQgTk9UIHJlbW92ZSB0 aGUNCiAgIFRyYW5zZmVyLUVuY29kaW5nIGhlYWRlciBiZWZvcmUgc2VuZGluZyB0aGUgaGVhZGVy IHBhcnQgdG8gdGhlDQogICBjYWxsb3V0IHNlcnZpY2UuIFRoZSBPUEVTIHByb2Nlc3NvciBNVVNU IHNlbmQgYSBjb3JyZWN0DQogICBUcmFuc2Zlci1FbmNvZGluZyBoZWFkZXIgdG8gdGhlIG5leHQg SFRUUCByZWNpcGllbnQgaW5kZXBlbmRlbnQgb2YNCiAgIHdoYXQgaGVhZGVyIHRoZSBjYWxsb3V0 IHNlcnZlciByZXR1cm5lZC4NCg0KMi42IEhUVFAgSGVhZGVyIENvcnJlY3RuZXNzDQoNCiAgIFdo ZW4gY29tbXVuaWNhdGluZyB3aXRoIEhUVFAgYXBwbGljYXRpb25zLCBPUEVTIHByb2Nlc3NvcnMg TVVTVA0KICAgZW5zdXJlIGNvcnJlY3RuZXNzIG9mIGFsbCBjb21wdXRhYmxlIEhUVFAgaGVhZGVy cyBkb2N1bWVudGVkIGluDQogICBzcGVjaWZpY2F0aW9ucyB0aGF0IHRoZSBwcm9jZXNzb3JzIGlu dGVuZCB0byBiZSBjb21wbGlhbnQgd2l0aC4gQQ0KICAgY29tcHV0YWJsZSBoZWFkZXIgaXMgZGVm aW5lZCBhcyBhIGhlYWRlciB3aGljaCB2YWx1ZSBjYW4gYmUgY29tcHV0ZWQNCiAgIGJhc2VkIG9u IHRoZSBtZXNzYWdlIGJvZHkgYWxvbmUuIEZvciBleGFtcGxlLCB0aGUgY29ycmVjdG5lc3Mgb2YN CiAgIENvbnRlbnQtTGVuZ3RoIGFuZCBDb250ZW50LU1ENSBoZWFkZXJzIGhhcyB0byBiZSBlbnN1 cmVkIGJ5DQogICBwcm9jZXNzb3JzIGNsYWltaW5nIGNvbXBsaWFuY2Ugd2l0aCBIVFRQLzEuMSAo W1JGQzI2MTZdKS4NCg0KICAgSW5mb3JtYWxseSwgdGhlIE9QRVMgcHJvY2Vzc29yIGJ5IGRlZmF1 bHQgaGFzIHRvIHZhbGlkYXRlIGFuZA0KICAgZXZlbnR1YWxseSByZWNhbGN1bGF0ZSwgYWRkLCBv ciByZW1vdmUgY29tcHV0YWJsZSBIVFRQIGhlYWRlcnMgaW4NCiAgIG9yZGVyIHRvIHJlY3JlYXRl IGEgY29tcGxpYW50IEhUVFAgbWVzc2FnZS4gSWYgYSBwYXJ0aWN1bGFyIE9QRVMNCiAgIHByb2Nl c3NvciB0cnVzdHMgY2VydGFpbiBIVFRQIGhlYWRlcnMgdGhhdCBhIGNhbGxvdXQgc2VydmljZSBz ZW5kcywNCiAgIGl0IGNhbiB1c2UgdGhvc2UgaGVhZGVycyAiYXMgaXMiLg0KDQogICBBbiBPUEVT IHByb2Nlc3NvciBNQVkgZm9yd2FyZCB0aGUgcmVzcG9uc2Ugb2YgYSBjYWxsb3V0IHNlcnZpY2Ug dG8NCiAgIG90aGVyIGNhbGxvdXQgc2VydmljZXMgd2l0aG91dCB2ZXJpZnlpbmcgSFRUUCBoZWFk ZXIgY29ycmVjdG5lc3MuDQogICBDb25zZXF1ZW50bHksIGEgY2FsbG91dCBzZXJ2aWNlIGNhbm5v dCBhc3N1bWUgdGhhdCB0aGUgSFRUUCBoZWFkZXJzDQogICBpdCByZWNlaXZlcyBhcmUgY29ycmVj dCBvciBmaW5hbCBmcm9tIGFuIEhUVFAgcG9pbnQgb2Ygdmlldy4NCg0KICAgVGhlIGZvbGxvd2lu ZyBzdWJzZWN0aW9ucyBwcmVzZW50IGd1aWRlbGluZXMgZm9yIHRoZSByZWNhbGN1bGF0aW9uIG9m DQogICBzb21lIEhUVFAgaGVhZGVycy4NCg0KMi42LjEgTWVzc2FnZSBTaXplIFJlY2FsY3VsYXRp b24NCg0KICAgQnkgZGVmYXVsdCBhbiBPQ1AgYWdlbnQgTVVTVCBOT1QgdHJ1c3QgdGhlIENvbnRl bnQtTGVuZ3RoIGhlYWRlciB0aGF0DQogICBpcyBzZW50IHdpdGhpbiBhbiBIVFRQIGhlYWRlciBt ZXNzYWdlIHBhcnQuIFRoZSBtZXNzYWdlIGxlbmd0aCBjb3VsZA0KICAgYmUgbW9kaWZpZWQgYnkg YSBjYWxsb3V0IHNlcnZpY2Ugd2l0aG91dCBhZGFwdGF0aW9uIG9mIHRoZSBIVFRQDQogICBtZXNz YWdlIGhlYWRlcnMuDQoNCiAgIEJlZm9yZSBzZW5kaW5nIHRoZSBIVFRQIG1lc3NhZ2UgdG8gdGhl IEhUVFAgcGVlciwgdGhlIE9QRVMgcHJvY2Vzc29yDQogICBNVVNUIGVuc3VyZSBjb3JyZWN0bmVz cyBvZiB0aGUgbWVzc2FnZSBsZW5ndGggaW5kaWNhdGlvbiBhY2NvcmRpbmcgdG8NCiAgIHNlY3Rp b24gNC40IG9mIFtSRkMyNjE2XS4NCg0KDQoNCg0KUm91c3Nrb3YgJiBTdGVjaGVyICAgICAgIEV4 cGlyZXMgQXByaWwgMjYsIDIwMDQgICAgICAgICAgICAgICAgW1BhZ2UgMTNdDQoMDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgIEhUVFAgYWRhcHRhdGlvbiB3aXRoIE9QRVMgICAgICAgICAgICBPY3Rv YmVyIDIwMDMNCg0KDQogICBCZXNpZGVzIG1lc3NhZ2UgY29ycmVjdG5lc3MsIHRoZSBPUEVTIHBy b2Nlc3NvciBTSE9VTEQgc2V0IHVwIHRoZQ0KICAgbWVzc2FnZSBpbiBhIHdheSB0aGF0IGd1YXJh bnRlZXMgZ29vZCBwZXJmb3JtYW5jZSBhbmQgbG93IGxhdGVuY3kuDQogICBFbmQgb2YgbWVzc2Fn ZSBpbmRpY2F0aW9uLCBieSBzaW1wbHkgY2xvc2luZyB0aGUgY29ubmVjdGlvbiwgU0hPVUxEDQog ICBiZSB0aGUgbGFzdCBjaG9pY2Ugb25seS4NCg0KICAgKFhYWDogYWxsIHRoZXNlIHJlcXVpcmVt ZW50cyBzZWVtIHRvIGJlIG91dCBvZiBvdXIgc2NvcGUuICBTaG91bGQgd2UNCiAgIG1ha2UgdGhl bSBpbmZvcm1hbD8pDQoNCiAgIG8gIElmIHRoZSBjYWxsb3V0IHNlcnZlciBzZW5kcyBhbiBBTS1F TCBwYXJhbWV0ZXIgd2l0aCBpdHMgQU1TDQogICAgICBtZXNzYWdlLCB0aGUgT1BFUyBwcm9jZXNz b3IgU0hPVUxEIHVzZSB0aGlzIHZhbHVlIHRvIGNyZWF0ZSBhDQogICAgICBDb250ZW50LUxlbmd0 aCBoZWFkZXIgdG8gYmUgYWJsZSB0byBrZWVwIGEgcGVyc2lzdGVudCBIVFRQDQogICAgICBjb25u ZWN0aW9uLiBOb3RlIHRoYXQgYSBDb250ZW50LUxlbmd0aCBoZWFkZXIgTVVTVCBOT1QgYmUgdXNl ZCBpZg0KICAgICAgYSB0cmFuc2ZlciBjb2RpbmcgaXMgdG8gYmUgYXBwbGllZC4NCg0KICAgbyAg SWYgdGhlcmUgaXMgbm8gQU0tRUwgcGFyYW1ldGVyLCB0aGUgT1BFUyBwcm9jZXNzb3IgU0hPVUxE IGNvbnNpZGVyDQogICAgICB1c2luZyBjaHVua2VkIHRyYW5zZmVyIGVuY29kaW5nIGZvciB0aGUg SFRUUCBtZXNzYWdlIGlmIGJvdGggdGhlDQogICAgICBPUEVTIHByb2Nlc3NvciBhbmQgdGhlIG5l eHQgSFRUUCByZWNpcGllbnQgYXJlIEhUVFAvMS4xDQogICAgICAoW1JGQzI2MTZdKSBhcHBsaWNh dGlvbnMuIE5vdGUgdGhhdCBhbnkgQ29udGVudC1MZW5ndGggaGVhZGVyIE1VU1QNCiAgICAgIGJl IHJlbW92ZWQgaW4gdGhpcyBjYXNlLg0KDQogICBvICBJZiB0aGUgbWVzc2FnZSBzaXplIGlzIG5v dCBrbm93biBhIHByaW9yaSBhbmQgY2h1bmtlZCB0cmFuc2Zlcg0KICAgICAgY29kaW5nIGNhbm5v dCBiZSB1c2VkLCB0aGUgT1BFUyBwcm9jZXNzb3IgaGFzIHRvIGRlY2lkZSB3aGV0aGVyIGl0DQog ICAgICBpcyBzdWl0YWJsZSB0byB3YWl0IGZvciB0aGUgT0NQIHRyYW5zYWN0aW9uIHRvIGZpbmlz aCBhbmQgY29sbGVjdA0KICAgICAgYWxsIEhUVFAgbWVzc2FnZSBkYXRhLCB0aHVzIGJlaW5nIGFi bGUgdG8gY2FsY3VsYXRlIGFuZCBhZGQgYQ0KICAgICAgQ29udGVudC1MZW5ndGggaGVhZGVyIHRv IHRoZSBtZXNzYWdlIGJ1dCBpbmNyZWFzaW5nIHRoZSBsYXRlbmN5DQogICAgICB0aW1lLCBvciBk ZWxldGUgYW55IENvbnRlbnQtTGVuZ3RoIGhlYWRlciwgZm9yd2FyZGluZyB0aGUgZGF0YQ0KICAg ICAgaW1tZWRpYXRlbHkgYW5kIGluZGljYXRpbmcgdGhlIG1lc3NhZ2UgZW5kIGJ5IGNsb3Npbmcg dGhlDQogICAgICBjb25uZWN0aW9uLCB0aHVzIGRlc3Ryb3lpbmcgY29ubmVjdGlvbiBwZXJzaXN0 ZW5jeS4gVGhlIGxhdHRlcg0KICAgICAgU0hPVUxEIGJlIHRoZSBjaG9pY2UgaWYgdGhlIGNvbm5l Y3Rpb24gY2Fubm90IGJlIHBlcnNpc3RlbnQgaW4gdGhlDQogICAgICBmaXJzdCBwbGFjZSBkdWUg dG8gb3RoZXIgcmVhc29ucywgZm9yIGV4YW1wbGUgYmVjYXVzZSBhDQogICAgICAiQ29ubmVjdGlv bjogY2xvc2UiIGhlYWRlciBoYXMgYmVlbiBzZW50IHdpdGggdGhlIEhUVFAgcmVxdWVzdC4NCg0K DQoyLjYuMiBDb250ZW50LU1ENSBIZWFkZXINCg0KICAgQnkgZGVmYXVsdCB0aGUgT1BFUyBwcm9j ZXNzb3IgTVVTVCBhc3N1bWUgdGhhdCB0aGUgY2FsbG91dCBzZXJ2aWNlDQogICB3aWxsIG1vZGlm eSB0aGUgY29udGVudCBpbiBhIHdheSB0aGF0IHRoZSBNRDUgY2hlY2tzdW0gb2YgdGhlIG1lc3Nh Z2UNCiAgIGJvZHkgd2lsbCBiZWNvbWUgaW52YWxpZC4NCg0KICAgQWNjb3JkaW5nIHRvIHNlY3Rp b24gMTQuMTUgb2YgW1JGQzI2MTZdLCB0aGUgQ29udGVudC1NRDUgaGVhZGVyIE1VU1QNCiAgIE5P VCBiZSBnZW5lcmF0ZWQgYnkgcHJveGllcy4gQSByZWNhbGN1bGF0aW9uIGlzIHRoZXJlZm9yZSBw b3NzaWJsZQ0KICAgb25seSBpZiB0aGUgT1BFUyBwcm9jZXNzb3IgaXMgY29uc2lkZXJlZCBhdXRo b3JpdGF0aXZlIGZvciB0aGUgZW50aXR5DQogICBiZWluZyBhZGFwdGVkLiBBbiB1bi1hdXRob3Jp dGF0aXZlIE9QRVMgcHJvY2Vzc29yIE1VU1QgcmVtb3ZlIHRoZQ0KICAgQ29udGVudC1NRDUgaGVh ZGVyIHVubGVzcyBpdCBjYW4gZGV0ZWN0IHRoYXQgdGhlIG1lc3NhZ2Ugd2FzIG5vdA0KICAgbW9k aWZpZWQ7IGluIHRoaXMgY2FzZSBpdCBNQVkgbGVhdmUgdGhlIENvbnRlbnQtTUQ1IGhlYWRlciBp biB0aGUNCiAgIG1lc3NhZ2UuICBJZiBzdWNoIGRldGVjdGlvbiBzaWduaWZpY2FudGx5IGluY3Jl YXNlcyBtZXNzYWdlIGxhdGVuY3ksDQogICBkZWxldGluZyB0aGUgQ29udGVudC1NRDUgaGVhZGVy IGNvdWxkIGJlIGEgYmV0dGVyIG9wdGlvbi4NCg0KDQoNCg0KUm91c3Nrb3YgJiBTdGVjaGVyICAg ICAgIEV4cGlyZXMgQXByaWwgMjYsIDIwMDQgICAgICAgICAgICAgICAgW1BhZ2UgMTRdDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgICAgIEhUVFAgYWRhcHRhdGlvbiB3aXRoIE9QRVMgICAgICAgICAg ICBPY3RvYmVyIDIwMDMNCg0KDQozLiBUcmFjaW5nDQoNCiAgIFtJLUQuaWV0Zi1vcGVzLWVuZC1j b21tXSBkZWZpbmVzIGFwcGxpY2F0aW9uLWFnbm9zdGljIHRyYWNpbmcNCiAgIGZhY2lsaXRpZXMg aW4gT1BFUy4gV2hlbiBhZGFwdGluZyBIVFRQLCB0cmFjZSBlbnRyaWVzIGFyZSBzdXBwbGllZA0K ICAgdXNpbmcgSFRUUCBtZXNzYWdlIGhlYWRlcnMuIFRoZSBmb2xsb3dpbmcgSFRUUCBleHRlbnNp b24gaGVhZGVycyBhcmUNCiAgIGRlZmluZWQgdG8gY2FycnkgdHJhY2UgZW50cmllcy4gVGhlaXIg ZGVmaW5pdGlvbnMgYXJlIGdpdmVuIHVzaW5nIEJORg0KICAgbm90YXRpb24gYW5kIGVsZW1lbnRz IGRlZmluZWQgaW4gW1JGQzI2MTZdLg0KDQogICAJT1BFUy1TeXN0ZW0gPSAiT1BFUy1TeXN0ZW0i ICI6IiAjdHJhY2UtZW50cnkNCiAgIAlPUEVTLVByb2Nlc3NvciA9ICJPUEVTLVByb2Nlc3NvciIg IjoiICN0cmFjZS1lbnRyeQ0KICAgCU9QRVMtU2VydmljZSA9ICJPUEVTLVNlcnZpY2UiICI6IiAj dHJhY2UtZW50cnkNCg0KICAgCXRyYWNlLWVudHJ5ID0gb3Blcy1hZ2VudC1pZCAqKCAiOyIgcGFy YW1ldGVyICkNCiAgIAlvcGVzLWFnZW50LWlkID0gYWJzb2x1dGVVUkkNCg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAxMg0KDQogICBPUEVTIGFnZW50cyBNVVNUIHVzZSBj b3JyZXNwb25kaW5nIGhlYWRlcnMgdG8gcmVwcmVzZW50IHRoZWlyIHRyYWNlDQogICBlbnRyaWVz LiBOb3RlIHRoYXQgYWxsIG9mIHRoZXNlIGhlYWRlcnMgYXJlIGRlZmluZWQgdXNpbmcgI2xpc3QN CiAgIGNvbnN0cnVjdHMgYW5kLCBoZW5jZSwgYSB2YWxpZCBIVFRQIG1lc3NhZ2UgbWF5IGNvbnRh aW4gbXVsdGlwbGUNCiAgIGVudHJpZXMgb2YgZWFjaCBoZWFkZXIuDQoNCiAgIEZvciBleGFtcGxl LCBoZXJlIGlzIGFuIEhUVFAgcmVzcG9uc2UgbWVzc2FnZSBoZWFkZXIgYWZ0ZXIgT1BFUw0KICAg YWRhcHRhdGlvbnMgaGF2ZSBiZWVuIGFwcGxpZWQgYnkgYSBzaW5nbGUgT1BFUyBwcm9jZXNzb3Ig ZXhlY3V0aW5nIDEwDQogICBPUEVTIHNlcnZpY2VzOg0KDQogICAJSFRUUC8xLjEgMjAwIE9LDQog ICAJRGF0ZTogVGh1LCAxOCBTZXAgMjAwMyAwNjoyNToyNCBHTVQNCiAgIAlMYXN0LU1vZGlmaWVk OiBXZWQsIDE3IFNlcCAyMDAzIDE4OjI0OjI1IEdNVA0KICAgCUNvbnRlbnQtdHlwZTogYXBwbGlj YXRpb24vb2N0ZXQtc3RyZWFtDQogICAJT1BFUy1TZXJ2aWNlOiBodHRwOi8vd3d3Lm9wZXMtc2Vy dmljZXMtNHUuY29tL2NhdC8/c2lkPTEyMw0KICAgCU9QRVMtU3lzdGVtOiBodHRwOi8vd3d3LmV4 YW1wbGUtY2RuLmNvbS9vcGVzP3Nlc3Npb249YWM3OWE3OTAxNTQ5ZjU2DQogICAJT1BFUy1TZXJ2 aWNlOiBodHRwOi8vd3d3Lm9wZXMtc2VydmljZXMtNHUuY29tL2NhdC8/c2lkPTEyNCwNCiAgIAkg ICAgICAgICAgICAgIGh0dHA6Ly93d3cub3Blcy1zZXJ2aWNlcy00dS5jb20vY2F0Lz9zaWQ9MTI1 IDsgbW9kZT1BDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMTMNCg0K ICAgSW4gdGhlIGFib3ZlIGV4YW1wbGUsIHRoZSBPUEVTIHByb2Nlc3NvciBoYXMgbm90IGluY2x1 ZGVkIGl0cyB0cmFjZQ0KICAgZW50cnkgb3IgaXRzIHRyYWNlIGVudHJ5IHdhcyByZXBsYWNlZCBi eSBhbiBPUEVTIHN5c3RlbSB0cmFjZSBlbnRyeS4NCiAgIE9ubHkgMyBvdXQgb2YgMTAgc2Vydmlj ZXMgYXJlIHRyYWNlZC4gVGhlIHJlbWFpbmluZyBzZXJ2aWNlcyBkaWQgbm90DQogICBpbmNsdWRl IHRoZWlyIGVudHJpZXMgb3IgdGhlaXIgZW50cmllcyB3ZXJlIHJlbW92ZWQgYnkgT1BFUyBzeXN0 ZW0gb3INCiAgIHByb2Nlc3Nvci4gVGhlIGxhc3QgdHJhY2VkIHNlcnZpY2UgaW5jbHVkZWQgYSAi bW9kZSIgcGFyYW1ldGVyLg0KICAgVmFyaW91cyBpZGVudGlmaWVycyBpbiB0cmFjZSBlbnRyaWVz IHdpbGwgcHJvYmFibHkgaGF2ZSBubyBtZWFuaW5nIHRvDQogICB0aGUgcmVjaXBpZW50IG9mIHRo ZSBtZXNzYWdlLCBidXQgbWF5IGJlIGRlY29kZWQgYnkgT1BFUyBzZXJ2aWNlDQogICBzb2Z0d2Fy ZS4NCg0KICAgU2VlIFtJLUQuaWV0Zi1vcGVzLWVuZC1jb21tXSBmb3IgYWxsIHZhbGlkIG1hcHBp bmdzIG9mIE9QRVMgYWdlbnRzIHRvDQogICB0cmFjZSBlbnRyaWVzIGFuZCBmb3IgZGlzY3Vzc2lv biBvbiB2YWxpZCBPUEVTIGFnZW50IGlkZW50aWZpZXJzLg0KDQoNCg0KUm91c3Nrb3YgJiBTdGVj aGVyICAgICAgIEV4cGlyZXMgQXByaWwgMjYsIDIwMDQgICAgICAgICAgICAgICAgW1BhZ2UgMTVd DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgIEhUVFAgYWRhcHRhdGlvbiB3aXRoIE9QRVMgICAg ICAgICAgICBPY3RvYmVyIDIwMDMNCg0KDQogICBJbXBsZW1lbnRhdGlvbnMgTUFZIHBsYWNlIG9w dGlvbmFsIHRyYWNpbmcgZW50cmllcyBpbiBhIG1lc3NhZ2UNCiAgIHRyYWlsZXIgKGkuZS4sIGVu dGl0eS1oZWFkZXJzIGF0IHRoZSBlbmQgb2YgYSBDaHVua2VkLUJvZHkgb2YgYQ0KICAgY2h1bmtl ZC1lbmNvZGVkIG1lc3NhZ2UpLCBwcm92aWRlZCB0cmFpbGVyIHByZXNlbmNlIGRvZXMgbm90IHZp b2xhdGUNCiAgIEhUVFAgcHJvdG9jb2wuIFNlZSBbSS1ELmlldGYtb3Blcy1lbmQtY29tbV0gZm9y IGEgZGVmaW5pdGlvbiBvZiB3aGF0DQogICB0cmFjaW5nIGVudHJpZXMgYXJlIG9wdGlvbmFsLiBJ bXBsZW1lbnRhdGlvbnMgTVVTVCBOT1QgcGxhY2UgcmVxdWlyZWQNCiAgIHRyYWNpbmcgZW50cmll cyBpbiBhIG1lc3NhZ2UgdHJhaWxlci4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN ClJvdXNza292ICYgU3RlY2hlciAgICAgICBFeHBpcmVzIEFwcmlsIDI2LCAyMDA0ICAgICAgICAg ICAgICAgIFtQYWdlIDE2XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICBIVFRQIGFkYXB0YXRp b24gd2l0aCBPUEVTICAgICAgICAgICAgT2N0b2JlciAyMDAzDQoNCg0KNC4gQnlwYXNzDQoNCiAg IEFuIEhUVFAgZXh0ZW5zaW9uIGhlYWRlciBpcyBpbnRyb2R1Y2VkIHRvIGFsbG93IGZvciBPUEVT IHN5c3RlbQ0KICAgYnlwYXNzIGFzIGRlZmluZWQgaW4gW0ktRC5pZXRmLW9wZXMtZW5kLWNvbW1d Lg0KDQogICAJT1BFUy1CeXBhc3MgID0gIk9QRVMtQnlwYXNzIiAiOiIgKCAiKiIgfCAxI2J5cGFz cy1lbnRyeSApDQogICAJYnlwYXNzLWVudHJ5ID0gb3Blcy1hZ2VudC1pZA0KDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDE0DQoNCiAgIFRoaXMgaGVhZGVyIGNhbiBiZSBh ZGRlZCB0byBIVFRQIHJlcXVlc3RzIHRvIHJlcXVlc3QgT1BFUyBzeXN0ZW0NCiAgIGJ5cGFzcyBm b3IgdGhlIGxpc3RlZCBPUEVTIGFnZW50cy4gVGhlIGFzdGVyaXNrICIqIiBjaGFyYWN0ZXIgaXMg dXNlZA0KICAgdG8gcmVwcmVzZW50IGFsbCBwb3NzaWJsZSBPUEVTIGFnZW50cy4NCg0KICAgU2Vl IFtJLUQuaWV0Zi1vcGVzLWVuZC1jb21tXSBmb3Igd2hhdCBjYW4gYmUgYnlwYXNzZWQgYW5kIGJ5 cGFzcw0KICAgcmVxdWlyZW1lbnRzLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClJvdXNza292ICYgU3RlY2hlciAg ICAgICBFeHBpcmVzIEFwcmlsIDI2LCAyMDA0ICAgICAgICAgICAgICAgIFtQYWdlIDE3XQ0KDA0K SW50ZXJuZXQtRHJhZnQgICAgICAgICBIVFRQIGFkYXB0YXRpb24gd2l0aCBPUEVTICAgICAgICAg ICAgT2N0b2JlciAyMDAzDQoNCg0KNS4gSUFCIENvbnNpZGVyYXRpb25zDQoNCiAgIE9QRVMgdHJl YXRtZW50IG9mIElFVEYgSW50ZXJuZXQgQXJjaGl0ZWN0dXJlIEJvYXJkIChJQUIpDQogICBjb25z aWRlcmF0aW9ucyBbUkZDMzIzOF0gYXJlIGRvY3VtZW50ZWQgaW4gIk9QRVMgVHJlYXRtZW50IG9m IElBQg0KICAgQ29uc2lkZXJhdGlvbnMiIFtJLUQuaWV0Zi1vcGVzLWlhYl0uDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClJvdXNza292ICYgU3RlY2hlciAgICAgICBFeHBpcmVz IEFwcmlsIDI2LCAyMDA0ICAgICAgICAgICAgICAgIFtQYWdlIDE4XQ0KDA0KSW50ZXJuZXQtRHJh ZnQgICAgICAgICBIVFRQIGFkYXB0YXRpb24gd2l0aCBPUEVTICAgICAgICAgICAgT2N0b2JlciAy MDAzDQoNCg0KNi4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0KICAgQXBwbGljYXRpb24taW5k ZXBlbmRlbnQgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgYXJlIGRvY3VtZW50ZWQgaW4NCiAgIGFw cGxpY2F0aW9uLWFnbm9zdGljIE9QRVMgc3BlY2lmaWNhdGlvbnMuIEhUVFAgYmluZGluZyBkb2Vz IG5vdA0KICAgaW50cm9kdWNlIGFueSBIVFRQLXNwZWNpZmljIHNlY3VyaXR5IGNvbnNpZGVyYXRp b25zLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpSb3Vzc2tvdiAmIFN0ZWNo ZXIgICAgICAgRXhwaXJlcyBBcHJpbCAyNiwgMjAwNCAgICAgICAgICAgICAgICBbUGFnZSAxOV0N CgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgSFRUUCBhZGFwdGF0aW9uIHdpdGggT1BFUyAgICAg ICAgICAgIE9jdG9iZXIgMjAwMw0KDQoNCjcuIENvbXBsaWFuY2UNCg0KICAgQ29tcGxpYW5jZSB3 aXRoIE9QRVMgbWVjaGFuaXNtcyBpcyBkZWZpbmVkIGluIGNvcnJlc3BvbmRpbmcNCiAgIGFwcGxp Y2F0aW9uLWFnbm9zdGljIHNwZWNpZmljYXRpb25zLiAgSFRUUC1zcGVjaWZpYyBiaW5kaW5ncyBm b3INCiAgIHRoZXNlIG1lY2hhbmlzbXMgdXNlIGNvcnJlc3BvbmRpbmcgY29tcGxpYW5jZSBkZWZp bml0aW9ucyBmcm9tIHRoZXNlDQogICBzcGVjaWZpY2F0aW9ucywgYXMgaWYgZWFjaCBiaW5kaW5n IHdhcyBpbmNvcnBvcmF0ZWQgaW50byB0aGUNCiAgIGFwcGxpY2F0aW9uLWFnbm9zdGljIHNwZWNp ZmljYXRpb24gaXQgYmluZHMgdG8uDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUm91 c3Nrb3YgJiBTdGVjaGVyICAgICAgIEV4cGlyZXMgQXByaWwgMjYsIDIwMDQgICAgICAgICAgICAg ICAgW1BhZ2UgMjBdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgIEhUVFAgYWRhcHRhdGlvbiB3 aXRoIE9QRVMgICAgICAgICAgICBPY3RvYmVyIDIwMDMNCg0KDQo4LiBUby1kbw0KDQogICBYWFg6 IEZpeCBhbGwgWFhYcy4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClJv dXNza292ICYgU3RlY2hlciAgICAgICBFeHBpcmVzIEFwcmlsIDI2LCAyMDA0ICAgICAgICAgICAg ICAgIFtQYWdlIDIxXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICBIVFRQIGFkYXB0YXRpb24g d2l0aCBPUEVTICAgICAgICAgICAgT2N0b2JlciAyMDAzDQoNCg0KQXBwZW5kaXggQS4gQWNrbm93 bGVkZ2VtZW50cw0KDQogICBTcGVjaWFsIHRoYW5rcyB0byBNYXJzaGFsbCBSb3NlIGZvciBoaXMg eG1sMnJmYyB0b29sLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUm91 c3Nrb3YgJiBTdGVjaGVyICAgICAgIEV4cGlyZXMgQXByaWwgMjYsIDIwMDQgICAgICAgICAgICAg ICAgW1BhZ2UgMjJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgIEhUVFAgYWRhcHRhdGlvbiB3 aXRoIE9QRVMgICAgICAgICAgICBPY3RvYmVyIDIwMDMNCg0KDQpBcHBlbmRpeCBCLiBDaGFuZ2Ug TG9nDQoNCiAgIEludGVybmFsIFdHIHJldmlzaW9uIGNvbnRyb2wgSUQ6ICRJZDogaHR0cC54bWws diAxLjUzIDIwMDMvMTAvMjcNCiAgIDEwOjI0OjM3IHN0ZWNoZXIgRXhwICQNCg0KICAgMjAwMy8x MC8yNw0KDQogICAgICAqICBQcm9vZiByZWFkaW5nLg0KDQogICAgICAqICBSZW5hbWVkIGRvY3Vt ZW50IHRvIGRyYWZ0LWlldGYtb3Blcy1odHRwLTAxLg0KDQogICAgICAqICBXb250LVNlbmQtQm9k eSBwYXJhbWV0ZXIgcmVmZXJzIHRvIERXU1kgbWVzc2FnZSBhbmQNCiAgICAgICAgIFdvbnQtTG9v ay1Cb2R5IHBhcmFtZXRlciByZWZlcnMgdG8gRFdMWSBtZXNzYWdlcyBvZiBPQ1AgY29yZS4NCg0K ICAgMjAwMy8xMC8yNg0KDQogICAgICAqICBEZWxldGVkIHJlc29sdmVkIFhYWGVzLg0KDQogICAg ICAqICBTZWN0aW9uICJQcm9maWxlIFBhcnRzIjogQ2xlYW5lZC11cCBhbmQgcmVtb3ZlZCBhbWJp Z3VpdGllcy4NCg0KICAgICAgKiAgUmVuYW1lZCBXb250LVVzZS1Cb2R5IHRvIFdvbnQtU2VuZC1C b2R5IGFuZCBhZGRlZA0KICAgICAgICAgV29udC1Mb29rLUJvZHkNCg0KICAgICAgKiAgRG9jdW1l bnRlZCBPQ1AgcGFyYW1ldGVycyBpbiBURE0gYXMgcmVxdWlyZWQgYnkgT0NQIGNvcmUuDQoNCiAg ICAgICogIEFkanVzdGVkIHRoZSBQcm9maWxlIE5lZ290aWF0aW9uIGV4YW1wbGUNCg0KICAgICAg KiAgUmVtb3ZlIFNraXAtUGFydHMgYW5kIGFkZGVkIFdvbnQtVXNlLUJvZHkgYW5kIFBhdXNlLUF0 LUJvZHkuIFdlDQogICAgICAgICBhZ3JlZWQgdGhhdCB0aGVzZSBwYXJhbWV0ZXJzIHNvbHZlIHRo ZQ0KICAgICAgICAgd2hhdC1wYXJ0cy10by1zZW5kLW9yLXNraXAgcHJvYmxlbSB0aGF0IFNraXAt UGFydHMgaW50cm9kdWNlZC4NCg0KICAgMjAwMy8xMC8yNA0KDQogICAgICAqICBDaGFuZ2VkIGJl Z2lubmluZyBvZiBzZWN0aW9uIEhUVFAgSGVhZGVyIENvcnJlY3RuZXNzIHRvICJXaGVuDQogICAg ICAgICBjb21tdW5pY2F0aW5nIHdpdGggSFRUUCBhcHBsaWNhdGlvbnMsIE9QRVMgcHJvY2Vzc29y cyBNVVNULi4uIg0KDQogICAgICAqICBBZGRlZCBzZWNvbmQgdmFyaWFudCBvZiBhZGFwdGVkIHBh cnRzIGZvciByZXF1ZXN0IHByb2ZpbGUgYW5kDQogICAgICAgICBzbyBpbnRyb2R1Y2VkIHNob3J0 LWNpcmN1aXQgcG9zc2liaWxpdHkgZm9yIGNhbGxvdXQgc2VydmljZXMuDQoNCiAgICAgICogIFJl bW92ZWQgdGhlIGNvbW1lbnQgYWJvdXQgVHJhbnNmZXItRW5jb2RpbmcgcHJvYmxlbXM7IHRoZXJl IGlzDQogICAgICAgICBubyBwcm9ibGVtIGlmIHdlIGhhdmUgYSBNVVNUIHRoYXQgcHJlY2x1ZGVz IGFueSBlbmNvZGluZ3MgYW5kIGENCiAgICAgICAgIE1VU1QgdGhhdCB0ZXJtaW5hdGVzIHRoZSB0 cmFuc2FjdGlvbiBpZiBub3QgYWxsIGVuY29kaW5ncyBjYW4NCiAgICAgICAgIGJlIHJlbW92ZWQu IEFkZGVkIDJuZCBNVVNUIGFuZCBhbiBpbmZvcm1hbCBzZW50ZW5jZSB0aGF0IHdhcm5zDQogICAg ICAgICBmb3IgaW50ZXJvcGVyYWJpbGl0eSBwcm9ibGVtcyBpZiB0aGVzZSBydWxlcyBhcmUgdmlv bGF0ZWQuDQoNCiAgICAgICogIFJlbmFtZWQgb3B0aW9uYWwgcGFydHMgdG8gYXV4aWxpYXJ5IHBh cnRzOyBPcHRpb25hbC1QYXJ0cw0KICAgICAgICAgcGFyYW1ldGVyIGJlY29tZXMgQXV4LVBhcnRz DQoNCg0KDQoNClJvdXNza292ICYgU3RlY2hlciAgICAgICBFeHBpcmVzIEFwcmlsIDI2LCAyMDA0 ICAgICAgICAgICAgICAgIFtQYWdlIDIzXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICBIVFRQ IGFkYXB0YXRpb24gd2l0aCBPUEVTICAgICAgICAgICAgT2N0b2JlciAyMDAzDQoNCg0KICAgMjAw My8xMC8yMg0KDQogICAgICAqICBGaXhlZCB0aGUgYWZ0ZXItbmVnb3RpYXRpb24gcGFydCBvZiB0 aGUgcHJvZmlsZSBuZWdvdGlhdGlvbg0KICAgICAgICAgZXhhbXBsZS4NCg0KICAgICAgKiAgQW4g T1BFUyBwcm9jZXNzb3IgaGFzIHRvIHVzZSB0aGUgYWRhcHRlZCB2ZXJzaW9uIG9mIHRoZSBza2lw cGVkDQogICAgICAgICBwYXJ0IGlmIGl0IGlzIGF2YWlsYWJsZSBvciBwcm9jZXNzb3IncyBvd24g KG9yaWdpbmFsKSB2ZXJzaW9uDQogICAgICAgICBvZiB0aGUgcGFydCBpZiB0aGUgY2FsbG91dCBz ZXJ2ZXIgZGlkIG5vdCBzZW5kIGFuIGFkYXB0ZWQNCiAgICAgICAgIHZlcnNpb24uDQoNCiAgICAg ICogIEFNLVBhcnRzIG5vdCBsaXN0ZWQgaW4gdGhlIGNvcnJlc3BvbmRpbmcgc2VjdGlvbiBvZiBh DQogICAgICAgICBuZWdvdGlhdGVkIHByb2ZpbGUgTVVTVCBOT1QgYmUgc2VudC4NCg0KICAgICAg KiAgRGVsZXRlZCByZXNvbHZlZCBYWFhlcy4NCg0KICAgICAgKiAgUmVzdXJyZWN0ZWQgYW5kIHBv bGlzaGVkIGEgbm90ZSB0aGF0IG9yaWdpbmFsIHBhcnRzIG5vdA0KICAgICAgICAgaW5jbHVkZWQg aW4gdGhlIGFkYXB0ZWQgcGFydHMgbGlzdCBjYW5ub3QgYmUgYWRhcHRlZC4NCg0KICAgICAgKiAg U2tpcHBlZCBwYXJ0cyBNQVkgYmUgc2VudCBieSBwcm9jZXNzb3IgYmVjYXVzZSBhIE1VU1QgTk9U IHNlbmQNCiAgICAgICAgIHJlcXVpcmVtZW50IHdvdWxkIGVzc2VudGlhbGx5IHJlcXVpcmUgYnVm ZmVyaW5nIGEgcG90ZW50aWFsbHkNCiAgICAgICAgIGxhcmdlIHBhcnQgYXQgdGhlIHByb2Nlc3Nv ci4gVGhlIE1BWSByZXF1aXJlbWVudCBtb3ZlcyB0aGUNCiAgICAgICAgIGJ1cmRlbiB0byB0aGUg c2VydmljZSwgd2hpY2ggaXMgbGlrZWx5IHRvIGJlIGluIGEgYmV0dGVyDQogICAgICAgICBwb3Np dGlvbiB0aGFuIHByb2Nlc3NvciB0byBvcHRpbWl6ZS4NCg0KICAgICAgKiAgRG8gbm90IHN1cHBv cnQgZXh0ZW5zaW9uIGFtLXBhcnRzIGV4cGxpY2l0bHk7IGV4dGVuc2lvbi9uZXcNCiAgICAgICAg IHByb2ZpbGVzIGNhbiBkZWZpbmVkIHRoZW0gZXhwbGljaXRseSBhcyBuZWVkZWQgYW5kIGEgZGlm ZmVyZW50DQogICAgICAgICBwcm9maWxlIHdvdWxkIG1vc3QgY2VydGFpbmx5IGJlIHJlcXVpcmVk IHRvIGFkZCBhIG1lYW5pbmdmdWwNCiAgICAgICAgIG5ldyBwYXJ0IGFueXdheS4NCg0KICAgICAg KiAgUHJvb2YgcmVhZGluZw0KDQogICAyMDAzLzEwLzIxDQoNCiAgICAgICogIEFkZGVkIGZldyBt b3JlIFhYWHMgYW5kIGNvbW1lbnRlZCBvdGhlcnMuIEFsbCBuZXcgY29tbWVudHMgYXJlDQogICAg ICAgICBtYXJrZWQgd2l0aCAoTVMpLg0KDQogICAgICAqICBSZXBsYWNlZCAiYW0tcGFydCBzdHJp bmciIHdpdGggImFtLXBhcnQgdG9rZW5zIg0KDQogICAyMDAzLzEwLzIwDQoNCiAgICAgICogIE1h ZGUgc3VyZSB0aGF0IG1vc3QgUkZDMjExOSByZXF1aXJlbWVudHMgaGF2ZSBhIHN1YmplY3QuDQoN CiAgICAgICogIEFkZGVkIFhYWHMgdG8gaWRlbnRpZnkgcGxhY2VzIHRoYXQgbmVlZCBtb3JlIHdv cmsuDQoNCiAgICAgICogIEFkZGVkIHNlY3Rpb24gQXBwbGljYXRpb24gTWVzc2FnZSBTdGFydCBp bnRyb2R1Y2luZyBBTS1FTCBuYW1lZA0KICAgICAgICAgcGFyYW1ldGVyDQoNCiAgICAgICogIFJl bW92ZWQgc2l6ZXAgcGFyYW1ldGVyIHJlZmVyZW5jZQ0KDQoNCg0KUm91c3Nrb3YgJiBTdGVjaGVy ICAgICAgIEV4cGlyZXMgQXByaWwgMjYsIDIwMDQgICAgICAgICAgICAgICAgW1BhZ2UgMjRdDQoM DQpJbnRlcm5ldC1EcmFmdCAgICAgICAgIEhUVFAgYWRhcHRhdGlvbiB3aXRoIE9QRVMgICAgICAg ICAgICBPY3RvYmVyIDIwMDMNCg0KDQogICAgICAqICBVcGRhdGVkIE1lc3NhZ2UgU2l6ZSBSZWNh bGN1bGF0aW9uIHNlY3Rpb24NCg0KICAgICAgKiAgQWRkZWQgcmVmZXJlbmNlcyB0byBvdGhlciBk b2N1bWVudHMNCg0KICAgICAgKiAgRmlsbGVkIGJ5cGFzcyBzZWN0aW9uDQoNCiAgICAgICogIExp dHRsZSBmaXJzdCBwcm9vZnJlYWRpbmcNCg0KICAgMjAwMy8xMC8xNw0KDQogICAgICAqICBDb21w bGV0ZWQgc2VjdGlvbiBIVFRQIEhlYWRlciBDb3JyZWN0bmVzcw0KDQogICAgICAqICBOb3RlIGFi b3V0IGhlYWRlciBjb3JyZWN0bmVzcyBpbiBUcmFuc2Zlci1FbmNvZGluZ3Mgc2VjdGlvbg0KDQog ICAyMDAzLzEwLzE2DQoNCiAgICAgICogIFJlbW92ZWQgVHJhbnNmZXItRW5jb2RpbmdzIGFzIGEg bmFtZWQgcGFyYW1ldGVyIG9mIHByb2ZpbGUNCiAgICAgICAgIGZlYXR1cmUNCg0KICAgICAgKiAg TW92ZWQgVHJhbnNmZXItRW5jb2RpbmdzIHNlY3Rpb24NCg0KICAgICAgKiAgQWRkZWQgc2VjdGlv biBIVFRQIEhlYWRlciBDb3JyZWN0bmVzcw0KDQogICAyMDAzLzEwLzEzDQoNCiAgICAgICogIEZp bGxlZCB0cmFuc2Zlci0gYW5kIGNvbnRlbnQtZW5jb2RpbmdzIHBhcmFncmFwaHMNCg0KICAgICAg KiAgRml4ZWQgbmVnb3RpYXRpb24gZXhhbXBsZQ0KDQogICAyMDAzLzEwLzEwDQoNCiAgICAgICog IEZpbGxlZCBhcHBsaWNhdGlvbiBtZXNzYWdlIHBhcnQgc2VjdGlvbi4NCg0KICAgICAgKiAgQWRk ZWQgRGF0YSBVc2UgTWluZSBNZXNzYWdlIHNlY3Rpb24uDQoNCiAgICAgICogIFJlc3RydWN0dXJl ZCwgY2hhbmdlZCBhbmQgZW5oYW5jZWQgQ2FsbG91dCBQcm90b2NvbCBzZWN0aW9uIGFuZA0KICAg ICAgICAgc3Vic2VjdGlvbnMuDQoNCiAgIDIwMDMvMDkvMjQNCg0KICAgICAgKiAgUmVtb3ZlZCBk dXBsaWNhdGUgYW5kIGVtcHR5IFRyYWNpbmcgc2VjdGlvbi4NCg0KICAgICAgKiAgTW92ZWQgdGhl IEJ5cGFzcyBzZWN0aW9uIGJlaGluZCB0aGUgVHJhY2luZyBzZWN0aW9uLg0KDQogICBoZWFkLXNp ZDEzDQoNCiAgICAgICogIFJlbW92ZWQgSFRUUC10cmFuc2FjdGlvbiBwcm9maWxlLCBhZGRlZCBv cHRpb25hbCBwYXJ0cyBhcw0KICAgICAgICAgZmVhdHVyZSBwYXJhbWV0ZXJzLCBhZGRlZCBleGFt cGxlLg0KDQoNCg0KUm91c3Nrb3YgJiBTdGVjaGVyICAgICAgIEV4cGlyZXMgQXByaWwgMjYsIDIw MDQgICAgICAgICAgICAgICAgW1BhZ2UgMjVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgIEhU VFAgYWRhcHRhdGlvbiB3aXRoIE9QRVMgICAgICAgICAgICBPY3RvYmVyIDIwMDMNCg0KDQogICBo ZWFkLXNpZDEyDQoNCiAgICAgICogIEluaXRpYWwgcmV2aXNpb24uDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpSb3Vzc2tvdiAmIFN0ZWNoZXIgICAgICAgRXhwaXJlcyBB cHJpbCAyNiwgMjAwNCAgICAgICAgICAgICAgICBbUGFnZSAyNl0NCgwNCkludGVybmV0LURyYWZ0 ICAgICAgICAgSFRUUCBhZGFwdGF0aW9uIHdpdGggT1BFUyAgICAgICAgICAgIE9jdG9iZXIgMjAw Mw0KDQoNCk5vcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCiAgIFtSRkMyNjE2XSAgRmllbGRpbmcsIFIu LCBHZXR0eXMsIEouLCBNb2d1bCwgSi4sIE5pZWxzZW4sIEguLA0KICAgICAgICAgICAgICBNYXNp bnRlciwgTC4sIExlYWNoLCBQLiBhbmQgVC4gQmVybmVycy1MZWUsICJIeXBlcnRleHQNCiAgICAg ICAgICAgICAgVHJhbnNmZXIgUHJvdG9jb2wgLS0gSFRUUC8xLjEiLCBSRkMgMjYxNiwgSnVuZSAx OTk5Lg0KDQogICBbSS1ELmlldGYtb3Blcy1lbmQtY29tbV0NCiAgICAgICAgICAgICAgQmFyYmly LCBBLiwgIk9QRVMgcHJvY2Vzc29yIGFuZCBlbmQgcG9pbnRzDQogICAgICAgICAgICAgIGNvbW11 bmljYXRpb25zIiwgZHJhZnQtaWV0Zi1vcGVzLWVuZC1jb21tLTAzICh3b3JrIGluDQogICAgICAg ICAgICAgIHByb2dyZXNzKSwgT2N0b2JlciAyMDAzLg0KDQogICBbSS1ELmlldGYtb3Blcy1vY3At Y29yZV0NCiAgICAgICAgICAgICAgUm91c3Nrb3YsIEEuLCAiT1BFUyBDYWxsb3V0IFByb3RvY29s IENvcmUiLA0KICAgICAgICAgICAgICBkcmFmdC1pZXRmLW9wZXMtb2NwLWNvcmUtMDEgKHdvcmsg aW4gcHJvZ3Jlc3MpLCBBdWd1c3QNCiAgICAgICAgICAgICAgMjAwMy4NCg0KICAgW0ktRC5pZXRm LW9wZXMtaWFiXQ0KICAgICAgICAgICAgICBCYXJiaXIsIEEuIGFuZCBBLiBSb3Vzc2tvdiwgIk9Q RVMgVHJlYXRtZW50IG9mIElBQg0KICAgICAgICAgICAgICBDb25zaWRlcmF0aW9ucyIsIGRyYWZ0 LWlldGYtb3Blcy1pYWItMDIgKHdvcmsgaW4NCiAgICAgICAgICAgICAgcHJvZ3Jlc3MpLCBTZXB0 ZW1iZXIgMjAwMy4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KUm91c3Nrb3YgJiBTdGVjaGVyICAgICAgIEV4cGlyZXMgQXByaWwg MjYsIDIwMDQgICAgICAgICAgICAgICAgW1BhZ2UgMjddDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg ICAgIEhUVFAgYWRhcHRhdGlvbiB3aXRoIE9QRVMgICAgICAgICAgICBPY3RvYmVyIDIwMDMNCg0K DQpJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCiAgIFtSRkMzMjM4XSAgRmxveWQsIFMuIGFuZCBM LiBEYWlnbGUsICJJQUIgQXJjaGl0ZWN0dXJhbCBhbmQgUG9saWN5DQogICAgICAgICAgICAgIENv bnNpZGVyYXRpb25zIGZvciBPcGVuIFBsdWdnYWJsZSBFZGdlIFNlcnZpY2VzIiwgUkZDDQogICAg ICAgICAgICAgIDMyMzgsIEphbnVhcnkgMjAwMi4NCg0KDQpBdXRob3JzJyBBZGRyZXNzZXMNCg0K ICAgQWxleCBSb3Vzc2tvdg0KICAgVGhlIE1lYXN1cmVtZW50IEZhY3RvcnkNCg0KICAgRU1haWw6 IHJvdXNza292QG1lYXN1cmVtZW50LWZhY3RvcnkuY29tDQogICBVUkk6ICAgaHR0cDovL3d3dy5t ZWFzdXJlbWVudC1mYWN0b3J5LmNvbS8NCg0KDQogICBNYXJ0aW4gU3RlY2hlcg0KICAgd2Vid2Fz aGVyIEFHDQogICBWYXR0bWFubnN0ci4gMw0KICAgUGFkZXJib3JuICAzMzEwMA0KICAgREUNCg0K ICAgRU1haWw6IG1hcnRpbi5zdGVjaGVyQHdlYndhc2hlci5jb20NCiAgIFVSSTogICBodHRwOi8v d3d3LndlYndhc2hlci5jb20vDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQpSb3Vzc2tvdiAmIFN0ZWNoZXIgICAgICAgRXhwaXJlcyBBcHJpbCAy NiwgMjAwNCAgICAgICAgICAgICAgICBbUGFnZSAyOF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAg ICAgSFRUUCBhZGFwdGF0aW9uIHdpdGggT1BFUyAgICAgICAgICAgIE9jdG9iZXIgMjAwMw0KDQoN CkludGVsbGVjdHVhbCBQcm9wZXJ0eSBTdGF0ZW1lbnQNCg0KICAgVGhlIElFVEYgdGFrZXMgbm8g cG9zaXRpb24gcmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBvciBzY29wZSBvZiBhbnkNCiAgIGludGVs bGVjdHVhbCBwcm9wZXJ0eSBvciBvdGhlciByaWdodHMgdGhhdCBtaWdodCBiZSBjbGFpbWVkIHRv DQogICBwZXJ0YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBvciB1c2Ugb2YgdGhlIHRlY2hub2xv Z3kgZGVzY3JpYmVkIGluDQogICB0aGlzIGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8gd2hpY2gg YW55IGxpY2Vuc2UgdW5kZXIgc3VjaCByaWdodHMNCiAgIG1pZ2h0IG9yIG1pZ2h0IG5vdCBiZSBh dmFpbGFibGU7IG5laXRoZXIgZG9lcyBpdCByZXByZXNlbnQgdGhhdCBpdA0KICAgaGFzIG1hZGUg YW55IGVmZm9ydCB0byBpZGVudGlmeSBhbnkgc3VjaCByaWdodHMuIEluZm9ybWF0aW9uIG9uIHRo ZQ0KICAgSUVURidzIHByb2NlZHVyZXMgd2l0aCByZXNwZWN0IHRvIHJpZ2h0cyBpbiBzdGFuZGFy ZHMtdHJhY2sgYW5kDQogICBzdGFuZGFyZHMtcmVsYXRlZCBkb2N1bWVudGF0aW9uIGNhbiBiZSBm b3VuZCBpbiBCQ1AtMTEuIENvcGllcyBvZg0KICAgY2xhaW1zIG9mIHJpZ2h0cyBtYWRlIGF2YWls YWJsZSBmb3IgcHVibGljYXRpb24gYW5kIGFueSBhc3N1cmFuY2VzIG9mDQogICBsaWNlbnNlcyB0 byBiZSBtYWRlIGF2YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBhbiBhdHRlbXB0IG1hZGUgdG8N CiAgIG9idGFpbiBhIGdlbmVyYWwgbGljZW5zZSBvciBwZXJtaXNzaW9uIGZvciB0aGUgdXNlIG9m IHN1Y2gNCiAgIHByb3ByaWV0YXJ5IHJpZ2h0cyBieSBpbXBsZW1lbnRvcnMgb3IgdXNlcnMgb2Yg dGhpcyBzcGVjaWZpY2F0aW9uIGNhbg0KICAgYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBTZWNy ZXRhcmlhdC4NCg0KICAgVGhlIElFVEYgaW52aXRlcyBhbnkgaW50ZXJlc3RlZCBwYXJ0eSB0byBi cmluZyB0byBpdHMgYXR0ZW50aW9uIGFueQ0KICAgY29weXJpZ2h0cywgcGF0ZW50cyBvciBwYXRl bnQgYXBwbGljYXRpb25zLCBvciBvdGhlciBwcm9wcmlldGFyeQ0KICAgcmlnaHRzIHdoaWNoIG1h eSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5IGJlIHJlcXVpcmVkIHRvIHByYWN0aWNlDQogICB0 aGlzIHN0YW5kYXJkLiBQbGVhc2UgYWRkcmVzcyB0aGUgaW5mb3JtYXRpb24gdG8gdGhlIElFVEYg RXhlY3V0aXZlDQogICBEaXJlY3Rvci4NCg0KDQpGdWxsIENvcHlyaWdodCBTdGF0ZW1lbnQNCg0K ICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwMykuIEFsbCBSaWdodHMg UmVzZXJ2ZWQuDQoNCiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRyYW5zbGF0aW9ucyBvZiBpdCBtYXkg YmUgY29waWVkIGFuZCBmdXJuaXNoZWQgdG8NCiAgIG90aGVycywgYW5kIGRlcml2YXRpdmUgd29y a3MgdGhhdCBjb21tZW50IG9uIG9yIG90aGVyd2lzZSBleHBsYWluIGl0DQogICBvciBhc3Npc3Qg aW4gaXRzIGltcGxlbWVudGF0aW9uIG1heSBiZSBwcmVwYXJlZCwgY29waWVkLCBwdWJsaXNoZWQN CiAgIGFuZCBkaXN0cmlidXRlZCwgaW4gd2hvbGUgb3IgaW4gcGFydCwgd2l0aG91dCByZXN0cmlj dGlvbiBvZiBhbnkNCiAgIGtpbmQsIHByb3ZpZGVkIHRoYXQgdGhlIGFib3ZlIGNvcHlyaWdodCBu b3RpY2UgYW5kIHRoaXMgcGFyYWdyYXBoIGFyZQ0KICAgaW5jbHVkZWQgb24gYWxsIHN1Y2ggY29w aWVzIGFuZCBkZXJpdmF0aXZlIHdvcmtzLiBIb3dldmVyLCB0aGlzDQogICBkb2N1bWVudCBpdHNl bGYgbWF5IG5vdCBiZSBtb2RpZmllZCBpbiBhbnkgd2F5LCBzdWNoIGFzIGJ5IHJlbW92aW5nDQog ICB0aGUgY29weXJpZ2h0IG5vdGljZSBvciByZWZlcmVuY2VzIHRvIHRoZSBJbnRlcm5ldCBTb2Np ZXR5IG9yIG90aGVyDQogICBJbnRlcm5ldCBvcmdhbml6YXRpb25zLCBleGNlcHQgYXMgbmVlZGVk IGZvciB0aGUgcHVycG9zZSBvZg0KICAgZGV2ZWxvcGluZyBJbnRlcm5ldCBzdGFuZGFyZHMgaW4g d2hpY2ggY2FzZSB0aGUgcHJvY2VkdXJlcyBmb3INCiAgIGNvcHlyaWdodHMgZGVmaW5lZCBpbiB0 aGUgSW50ZXJuZXQgU3RhbmRhcmRzIHByb2Nlc3MgbXVzdCBiZQ0KICAgZm9sbG93ZWQsIG9yIGFz IHJlcXVpcmVkIHRvIHRyYW5zbGF0ZSBpdCBpbnRvIGxhbmd1YWdlcyBvdGhlciB0aGFuDQogICBF bmdsaXNoLg0KDQogICBUaGUgbGltaXRlZCBwZXJtaXNzaW9ucyBncmFudGVkIGFib3ZlIGFyZSBw ZXJwZXR1YWwgYW5kIHdpbGwgbm90IGJlDQogICByZXZva2VkIGJ5IHRoZSBJbnRlcm5ldCBTb2Np ZXR5IG9yIGl0cyBzdWNjZXNzb3JzIG9yIGFzc2lnbmVlcy4NCg0KICAgVGhpcyBkb2N1bWVudCBh bmQgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaXMgcHJvdmlkZWQgb24gYW4NCiAg ICJBUyBJUyIgYmFzaXMgYW5kIFRIRSBJTlRFUk5FVCBTT0NJRVRZIEFORCBUSEUgSU5URVJORVQg RU5HSU5FRVJJTkcNCiAgIFRBU0sgRk9SQ0UgRElTQ0xBSU1TIEFMTCBXQVJSQU5USUVTLCBFWFBS RVNTIE9SIElNUExJRUQsIElOQ0xVRElORw0KICAgQlVUIE5PVCBMSU1JVEVEIFRPIEFOWSBXQVJS QU5UWSBUSEFUIFRIRSBVU0UgT0YgVEhFIElORk9STUFUSU9ODQoNCg0KDQpSb3Vzc2tvdiAmIFN0 ZWNoZXIgICAgICAgRXhwaXJlcyBBcHJpbCAyNiwgMjAwNCAgICAgICAgICAgICAgICBbUGFnZSAy OV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgSFRUUCBhZGFwdGF0aW9uIHdpdGggT1BFUyAg ICAgICAgICAgIE9jdG9iZXIgMjAwMw0KDQoNCiAgIEhFUkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBB TlkgUklHSFRTIE9SIEFOWSBJTVBMSUVEIFdBUlJBTlRJRVMgT0YNCiAgIE1FUkNIQU5UQUJJTElU WSBPUiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4NCg0KDQpBY2tub3dsZWRnZW1l bnQNCg0KICAgRnVuZGluZyBmb3IgdGhlIFJGQyBFZGl0b3IgZnVuY3Rpb24gaXMgY3VycmVudGx5 IHByb3ZpZGVkIGJ5IHRoZQ0KICAgSW50ZXJuZXQgU29jaWV0eS4NCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KUm91c3Nrb3YgJiBTdGVjaGVyICAgICAgIEV4cGlyZXMgQXByaWwgMjYsIDIw MDQgICAgICAgICAgICAgICAgW1BhZ2UgMzBdDQoMDQo= ------_=_NextPart_001_01C39C75.75617495-- From owner-ietf-openproxy@mail.imc.org Mon Oct 27 07:05: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 HAA08450 for ; Mon, 27 Oct 2003 07:05:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE67p-0003j1-00 for opes-archive@ietf.org; Mon, 27 Oct 2003 07:05:33 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AE67o-0003iy-00 for opes-archive@ietf.org; Mon, 27 Oct 2003 07:05:32 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RBmsI7045547 for ; Mon, 27 Oct 2003 03:48: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 h9RBmsO1045546 for ietf-openproxy-bks; Mon, 27 Oct 2003 03:48: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 h9RBmrI7045540 for ; Mon, 27 Oct 2003 03:48: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 h9RBmqGh053376; Mon, 27 Oct 2003 04:48:52 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9RBmqg1053375; Mon, 27 Oct 2003 04:48:52 -0700 (MST) (envelope-from rousskov) Date: Mon, 27 Oct 2003 04:48:52 -0700 (MST) From: Alex Rousskov To: internet-drafts@ietf.org cc: OPES WG , Abbie Barbir Subject: Request To Publish: draft-ietf-opes-iab-03 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-303409057-1067255122=:32906" Content-ID: Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-303409057-1067255122=:32906 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Please publish the attached draft-ietf-opes-iab-03.txt as an OPES working group Internet Draft. Thank you, Alex. --0-303409057-1067255122=:32906 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="draft-ietf-opes-iab-03.txt" Content-ID: Content-Description: draft-ietf-opes-iab-03.txt Content-Disposition: ATTACHMENT; FILENAME="draft-ietf-opes-iab-03.txt" Content-Transfer-Encoding: BASE64 DQoNCk9wZW4gUGx1Z2dhYmxlIEVkZ2UgU2VydmljZXMgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEEuIEJhcmJpcg0KSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Tm9ydGVsIE5ldHdvcmtzDQpFeHBpcmVzOiBBcHJpbCAyNiwgMjAwNCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQS4gUm91c3Nrb3YN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBUaGUgTWVhc3VyZW1lbnQgRmFjdG9yeQ0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBPY3Rv YmVyIDI3LCAyMDAzDQoNCg0KICAgICAgICAgICAgICAgICAgT1BFUyBUcmVh dG1lbnQgb2YgSUFCIENvbnNpZGVyYXRpb25zDQogICAgICAgICAgICAgICAg ICAgICAgICAgZHJhZnQtaWV0Zi1vcGVzLWlhYi0wMw0KDQpTdGF0dXMgb2Yg dGhpcyBNZW1vDQoNCiAgIFRoaXMgZG9jdW1lbnQgaXMgYW4gSW50ZXJuZXQt RHJhZnQgYW5kIGlzIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aA0KICAgYWxs IHByb3Zpc2lvbnMgb2YgU2VjdGlvbiAxMCBvZiBSRkMyMDI2Lg0KDQogICBJ bnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJ bnRlcm5ldCBFbmdpbmVlcmluZw0KICAgVGFzayBGb3JjZSAoSUVURiksIGl0 cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gTm90ZSB0aGF0IG90 aGVyDQogICBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRv Y3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuDQoNCiAgIEludGVybmV0LURy YWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0g b2Ygc2l4IG1vbnRocw0KICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNl ZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkNCiAg IHRpbWUuIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURy YWZ0cyBhcyByZWZlcmVuY2UNCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhl bSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiINCg0KICAgVGhl IGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vz c2VkIGF0IGh0dHA6Ly8NCiAgIHd3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0 cmFjdHMudHh0Lg0KDQogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBT aGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICBodHRw Oi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sLg0KDQogICBUaGlzIEludGVy bmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIEFwcmlsIDI2LCAyMDA0Lg0KDQpD b3B5cmlnaHQgTm90aWNlDQoNCiAgIENvcHlyaWdodCAoQykgVGhlIEludGVy bmV0IFNvY2lldHkgKDIwMDMpLiBBbGwgUmlnaHRzIFJlc2VydmVkLg0KDQpB YnN0cmFjdA0KDQogICBJRVRGIEludGVybmV0IEFyY2hpdGVjdHVyZSBCb2Fy ZCAoSUFCKSBleHByZXNzZWQgbmluZQ0KICAgYXJjaGl0ZWN0dXJlLWxldmVs IGNvbnNpZGVyYXRpb25zIGZvciB0aGUgT3BlbiBQbHVnZ2FibGUgRWRnZQ0K ICAgU2VydmljZXMgKE9QRVMpIGZyYW1ld29yay4gIFRoaXMgZG9jdW1lbnQg ZGVzY3JpYmVzIGhvdyBPUEVTDQogICBhZGRyZXNzZXMgdGhvc2UgY29uc2lk ZXJhdGlvbnMuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkJhcmJpciAmIFJvdXNz a292ICAgICAgICBFeHBpcmVzIEFwcmlsIDI2LCAyMDA0ICAgICAgICAgICAg ICAgICBbUGFnZSAxXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgT1BFUyBUcmVh dG1lbnQgb2YgSUFCIENvbnNpZGVyYXRpb25zICAgICAgT2N0b2JlciAyMDAz DQoNCg0KVGFibGUgb2YgQ29udGVudHMNCg0KICAgMS4gIEludHJvZHVjdGlv biAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAzDQogICAyLiAgVGVybWlub2xvZ3kgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQNCiAgIDMu ICBDb25zaWRlcmF0aW9uICgyLjEpICdPbmUtcGFydHkgY29uc2VudCcgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgNQ0KICAgNC4gIENvbnNpZGVyYXRpb24g KDIuMikgJ0lQLWxheWVyIGNvbW11bmljYXRpb25zJyAgLiAuIC4gLiAuIC4g LiAuICA2DQogICA1LiAgTm90aWZpY2F0aW9uIENvbnNpZGVyYXRpb25zICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDgNCiAgIDUuMSBO b3RpZmljYXRpb24gdmVyc3VzIHRyYWNlICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgOA0KICAgNS4yIEFuIGV4YW1wbGUgb2YgYW4g T1BFUyB0cmFjZSBmb3IgSFRUUCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICA5DQogICA1LjMgQ29uc2lkZXJhdGlvbiAoMy4xKSAnTm90aWZpY2F0aW9u JyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTANCiAgIDUuNCBDb25z aWRlcmF0aW9uICgzLjIpICdOb3RpZmljYXRpb24nIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAxMg0KICAgNi4gIENvbnNpZGVyYXRpb24gKDMuMykg J05vbi1ibG9ja2luZycgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEz DQogICA3LiAgQ29uc2lkZXJhdGlvbiAoNC4xKSAnVVJJIHJlc29sdXRpb24n IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTQNCiAgIDguICBDb25zaWRl cmF0aW9uICg0LjIpICdSZWZlcmVuY2UgdmFsaWRpdHknIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAxNQ0KICAgOS4gIENvbnNpZGVyYXRpb24gKDQuMykgJ0Fk ZHJlc3NpbmcgZXh0ZW5zaW9ucycgIC4gLiAuIC4gLiAuIC4gLiAuIDE2DQog ICAxMC4gQ29uc2lkZXJhdGlvbiAoNS4xKSAnUHJpdmFjeScgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTcNCiAgIDExLiBDb25zaWRlcmF0 aW9uICdFbmNyeXB0aW9uJyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAxOA0KICAgMTIuIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE5DQogICAx My4gQ29tcGxpYW5jZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gMjANCiAgIEEuICBDaGFuZ2UgTG9nIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAyMQ0KICAgICAgIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIzDQogICAgICAg SW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gMjQNCiAgICAgICBBdXRob3JzJyBBZGRyZXNz ZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAyNA0KICAgICAgIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBhbmQgQ29weXJp Z2h0IFN0YXRlbWVudHMgLiAuIC4gLiAuIC4gLiAuIDI1DQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpC YXJiaXIgJiBSb3Vzc2tvdiAgICAgICAgRXhwaXJlcyBBcHJpbCAyNiwgMjAw NCAgICAgICAgICAgICAgICAgW1BhZ2UgMl0NCgwNCkludGVybmV0LURyYWZ0 ICAgIE9QRVMgVHJlYXRtZW50IG9mIElBQiBDb25zaWRlcmF0aW9ucyAgICAg IE9jdG9iZXIgMjAwMw0KDQoNCjEuIEludHJvZHVjdGlvbg0KDQogICBUaGUg T3BlbiBQbHVnZ2FibGUgRWRnZSBTZXJ2aWNlcyAoT1BFUykgYXJjaGl0ZWN0 dXJlDQogICBbSS1ELmlldGYtb3Blcy1hcmNoaXRlY3R1cmVdLCBlbmFibGVz IGNvb3BlcmF0aXZlIGFwcGxpY2F0aW9uDQogICBzZXJ2aWNlcyAoT1BFUyBz ZXJ2aWNlcykgYmV0d2VlbiBhIGRhdGEgcHJvdmlkZXIsIGEgZGF0YSBjb25z dW1lciwNCiAgIGFuZCB6ZXJvIG9yIG1vcmUgT1BFUyBwcm9jZXNzb3JzLiAg VGhlIGFwcGxpY2F0aW9uIHNlcnZpY2VzIHVuZGVyDQogICBjb25zaWRlcmF0 aW9uIGFuYWx5emUgYW5kIHBvc3NpYmx5IHRyYW5zZm9ybSBhcHBsaWNhdGlv bi1sZXZlbA0KICAgbWVzc2FnZXMgZXhjaGFuZ2VkIGJldHdlZW4gdGhlIGRh dGEgcHJvdmlkZXIgYW5kIHRoZSBkYXRhIGNvbnN1bWVyLg0KDQogICBJbiB0 aGUgcHJvY2VzcyBvZiBjaGFydGVyaW5nIE9QRVMsIHRoZSBJQUIgbWFkZSBy ZWNvbW1lbmRhdGlvbnMgb24NCiAgIGlzc3VlcyB0aGF0IE9QRVMgc29sdXRp b25zIHNob3VsZCBiZSByZXF1aXJlZCB0byBhZGRyZXNzLiBUaGVzZQ0KICAg cmVjb21tZW5kYXRpb25zIHdlcmUgZm9ybXVsYXRlZCBpbiB0aGUgZm9ybSBv ZiBhIHNwZWNpZmljIElBQg0KICAgY29uc2lkZXJhdGlvbnMgZG9jdW1lbnQg W1JGQzMyMzhdLiAgSW4gdGhhdCBkb2N1bWVudCwgSUFCIGVtcGhhc2l6ZWQN CiAgIHRoYXQgaXRzIGNvbnNpZGVyYXRpb25zIGRpZCBub3QgcmVjb21tZW5k IHNwZWNpZmljIHNvbHV0aW9ucyBhbmQgZGlkDQogICBub3QgbWFuZGF0ZSBz cGVjaWZpYyBmdW5jdGlvbmFsIHJlcXVpcmVtZW50cy4gQWRkcmVzc2luZyBh biBJQUINCiAgIGNvbnNpZGVyYXRpb24gbWF5IGludm9sdmUgc2hvd2luZyBh cHByb3ByaWF0ZSBwcm90b2NvbCBtZWNoYW5pc21zIG9yDQogICBkZW1vbnN0 cmF0aW5nIHRoYXQgdGhlIGlzc3VlIGRvZXMgbm90IGFwcGx5LiBBZGRyZXNz aW5nIGENCiAgIGNvbnNpZGVyYXRpb24gZG9lcyBub3QgbmVjZXNzYXJpbHkg bWVhbiBzdXBwb3J0aW5nIHRlY2hub2xvZ3kgaW1wbGllZA0KICAgYnkgdGhl IGNvbnNpZGVyYXRpb24gd29yZGluZy4NCg0KICAgVGhlIHByaW1hcnkgZ29h bCBvZiB0aGlzIGRvY3VtZW50IGlzIHRvIHNob3cgdGhhdCBhbGwgSUFCDQog ICByZWNvbW1lbmRhdGlvbnMgYXJlIGFkZHJlc3NlZCBieSBPUEVTLCB0byB0 aGUgZXh0ZW50IHRoYXQgdGhvc2UNCiAgIGNvbnNpZGVyYXRpb25zIGNhbiBi ZSBhZGRyZXNzZWQgYnkgYW4gSUVURiB3b3JraW5nIGdyb3VwLiBUaGUNCiAg IGxpbWl0YXRpb25zIG9mIE9QRVMgd29ya2luZyBncm91cCB0byBhZGRyZXNz IGNlcnRhaW4gYXNwZWN0cyBvZiBJQUINCiAgIGNvbnNpZGVyYXRpb25zIGFy ZSBhbHNvIGV4cGxpY2l0bHkgZG9jdW1lbnRlZC4NCg0KICAgVGhlcmUgYXJl IG5pbmUgSUFCIGNvbnNpZGVyYXRpb25zIFtSRkMzMjM4XSB0aGF0IE9QRVMg aGFzIHRvIGFkZHJlc3MuDQogICBJbiB0aGUgY29yZSBvZiB0aGlzIGRvY3Vt ZW50IGFyZSB0aGUgY29ycmVzcG9uZGluZyBuaW5lDQogICAiQ29uc2lkZXJh dGlvbiIgc2VjdGlvbnMuIEZvciBlYWNoIElBQiBjb25zaWRlcmF0aW9uLCBp dHMgc2VjdGlvbg0KICAgY29udGFpbnMgZ2VuZXJhbCBkaXNjdXNzaW9uIGFz IHdlbGwgYXMgcmVmZXJlbmNlcyB0byBzcGVjaWZpYyBPUEVTDQogICBtZWNo YW5pc21zIHJlbGV2YW50IHRvIHRoZSBjb25zaWRlcmF0aW9uLg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkJhcmJpciAmIFJv dXNza292ICAgICAgICBFeHBpcmVzIEFwcmlsIDI2LCAyMDA0ICAgICAgICAg ICAgICAgICBbUGFnZSAzXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgT1BFUyBU cmVhdG1lbnQgb2YgSUFCIENvbnNpZGVyYXRpb25zICAgICAgT2N0b2JlciAy MDAzDQoNCg0KMi4gVGVybWlub2xvZ3kNCg0KICAgVGhpcyBkb2N1bWVudCBk b2VzIG5vdCBpbnRyb2R1Y2UgYW55IG5ldyB0ZXJtaW5vbG9neSBidXQgdXNl cw0KICAgdGVybWlub2xvZ3kgZnJvbSBvdGhlciBPUEVTIGRvY3VtZW50cyBp dCBxdW90ZXMuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KQmFyYmlyICYgUm91c3Nrb3YgICAgICAgIEV4cGly ZXMgQXByaWwgMjYsIDIwMDQgICAgICAgICAgICAgICAgIFtQYWdlIDRdDQoM DQpJbnRlcm5ldC1EcmFmdCAgICBPUEVTIFRyZWF0bWVudCBvZiBJQUIgQ29u c2lkZXJhdGlvbnMgICAgICBPY3RvYmVyIDIwMDMNCg0KDQozLiBDb25zaWRl cmF0aW9uICgyLjEpICdPbmUtcGFydHkgY29uc2VudCcNCg0KICAgIkFuIE9Q RVMgZnJhbWV3b3JrIHN0YW5kYXJkaXplZCBpbiB0aGUgSUVURiBtdXN0IHJl cXVpcmUgdGhhdCB0aGUgdXNlDQogICBvZiBhbnkgT1BFUyBzZXJ2aWNlIGJl IGV4cGxpY2l0bHkgYXV0aG9yaXplZCBieSBvbmUgb2YgdGhlDQogICBhcHBs aWNhdGlvbi1sYXllciBlbmQtaG9zdHMgKHRoYXQgaXMsIGVpdGhlciB0aGUg Y29udGVudCBwcm92aWRlciBvcg0KICAgdGhlIGNsaWVudCkuIltSRkMzMjM4 XQ0KDQogICBPUEVTIGFyY2hpdGVjdHVyZSByZXF1aXJlcyB0aGF0ICJPUEVT IHByb2Nlc3NvcnMgTVVTVCBiZSBjb25zZW50ZWQgdG8NCiAgIGJ5IGVpdGhl ciB0aGUgZGF0YSBjb25zdW1lciBvciBkYXRhIHByb3ZpZGVyIGFwcGxpY2F0 aW9uIg0KICAgW0ktRC5pZXRmLW9wZXMtYXJjaGl0ZWN0dXJlXS4gVGhpcyBy ZXF1aXJlbWVudCBhbG9uZSBjYW5ub3QgcHJldmVudA0KICAgY29uc2VudC1s ZXNzIGludHJvZHVjdGlvbiBvZiBPUEVTIHByb2Nlc3NvcnMuIEluDQogICBb SS1ELmlldGYtb3Blcy1lbmQtY29tbV0sIHRoZSBPUEVTIGFyY2hpdGVjdHVy ZSBlbmFibGVzIGNvbmNlcm5lZA0KICAgcGFydGllcyB0byBkZXRlY3QgdW53 YW50ZWQgT1BFUyBwcm9jZXNzb3JzIGJ5IGV4YW1pbmluZyBPUEVTIHRyYWNl cy4NCiAgIFRoZSB1c2Ugb2YgdHJhY2VzIGluIE9QRVMgaXMgbWFuZGF0b3J5 Lg0KDQogICBBIHRyYWNpbmcgbWVjaGFuaXNtIG9uIGl0cyBvd24gY2Fubm90 IGRldGVjdCBwcm9jZXNzb3JzIHRoYXQgYXJlIGluDQogICB2aW9sYXRpb24g b2YgT1BFUyBzcGVjaWZpY2F0aW9ucy4gIEV4YW1wbGVzIGluY2x1ZGUgT1BF UyBwcm9jZXNzb3JzDQogICBvcGVyYXRpbmcgaW4gc3RlYWx0aCBtb2RlLiAg SG93ZXZlciwgdGhlIE9QRVMgYXJjaGl0ZWN0dXJlIGFsbG93cyB0aGUNCiAg IHVzZSBvZiBjb250ZW50IHNpZ25hdHVyZSB0byB2ZXJpZnkgdGhlIGF1dGhl bnRpY2l0eSBvZiBwZXJmb3JtZWQNCiAgIGFkYXB0YXRpb25zLiBDb250ZW50 IHNpZ25hdHVyZXMgaXMgYSBzdHJvbmcgYnV0IGV4cGVuc2l2ZSBtZWNoYW5p c20NCiAgIHRoYXQgY2FuIGRldGVjdCBhbnkgbW9kaWZpY2F0aW9ucyBvZiBz aWduZWQgY29udGVudCBwcm92aWRlZCB0aGF0IHRoZQ0KICAgY29udGVudCBw cm92aWRlciBpcyB3aWxsaW5nIHRvIHNpZ24gdGhlIGRhdGEgYW5kIHRoYXQg dGhlIGNsaWVudCBpcw0KICAgd2lsbGluZyB0byBlaXRoZXIgY2hlY2sgdGhl IHNpZ25hdHVyZSBvciByZWxheSByZWNlaXZlZCBjb250ZW50IHRvDQogICB0 aGUgY29udGVudCBwcm92aWRlciBmb3Igc2lnbmF0dXJlIHZlcmlmaWNhdGlv bi4NCg0KICAgT1BFUyBhZGFwdGF0aW9ucyBtYXkgaW5jbHVkZSBjb3B5aW5n IGFuZCBvdGhlciBmb3JtcyBvZiBub24tbW9kaWZ5aW5nDQogICBhY2Nlc3Mg dG8gY29udGVudC4gVGhlc2Uga2luZHMgb2YgYWRhcHRhdGlvbnMgY2Fubm90 IGJlIGRldGVjdGVkIGJ5DQogICB0aGUgYWJvdmUgbWVudGlvbmVkIG1lY2hh bmlzbXMuIFRodXMsICJwYXNzaXZlIiBPUEVTIHByb2Nlc3NvcnMgY2FuDQog ICBvcGVyYXRlIG9uIHRoZSBjb250ZW50IHdpdGhvdXQgdGhlIGRhdGEgY29u c3VtZXIgb3IgcHJvdmlkZXIgY29uc2VudC4NCiAgIElmIHByZXNlbmNlIG9m IHN1Y2ggcHJvY2Vzc29ycyBpcyBhIGNvbmNlcm4sIHRoZW4gY29udGVudCBl bmNyeXB0aW9uDQogICBjYW4gYmUgdXNlZC4gQSBwYXNzaXZlIHByb2Nlc3Nv ciBpcyBubyBkaWZmZXJlbnQgZnJvbSBhIHByb3h5IG9yIGFuDQogICBpbnRl cm1lZGlhcnkgb3BlcmF0aW5nIG91dHNpZGUgb2YgT1BFUyBmcmFtZXdvcmsu ICBObyBPUEVTIG1lY2hhbmlzbQ0KICAgKGV4aXN0aW5nIG9yIGZvcmVzZWVh YmxlKSBjYW4gcHJldmVudCBub24tbW9kaWZ5aW5nIGFjY2VzcyB0bw0KICAg Y29udGVudC4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpC YXJiaXIgJiBSb3Vzc2tvdiAgICAgICAgRXhwaXJlcyBBcHJpbCAyNiwgMjAw NCAgICAgICAgICAgICAgICAgW1BhZ2UgNV0NCgwNCkludGVybmV0LURyYWZ0 ICAgIE9QRVMgVHJlYXRtZW50IG9mIElBQiBDb25zaWRlcmF0aW9ucyAgICAg IE9jdG9iZXIgMjAwMw0KDQoNCjQuIENvbnNpZGVyYXRpb24gKDIuMikgJ0lQ LWxheWVyIGNvbW11bmljYXRpb25zJw0KDQogICAiRm9yIGFuIE9QRVMgZnJh bWV3b3JrIHN0YW5kYXJkaXplZCBpbiB0aGUgSUVURiwgdGhlIE9QRVMNCiAg IGludGVybWVkaWFyeSBtdXN0IGJlIGV4cGxpY2l0bHkgYWRkcmVzc2VkIGF0 IHRoZSBJUCBsYXllciBieSB0aGUgZW5kDQogICB1c2VyLiJbUkZDMzIzOF0N Cg0KICAgVGhlIE9QRVMgYXJjaGl0ZWN0dXJlIHJlcXVpcmVzIHRoYXQgIk9Q RVMgcHJvY2Vzc29ycyBNVVNUIGJlDQogICBhZGRyZXNzYWJsZSBhdCB0aGUg SVAgbGF5ZXIgYnkgdGhlIGVuZCB1c2VyIChkYXRhIGNvbnN1bWVyDQogICBh cHBsaWNhdGlvbikiIFtJLUQuaWV0Zi1vcGVzLWFyY2hpdGVjdHVyZV0uIFRo ZSBJQUIgYW5kIHRoZQ0KICAgYXJjaGl0ZWN0dXJlIGRvY3VtZW50cyBtZW50 aW9uIGFuIGltcG9ydGFudCBleGNlcHRpb246IGFkZHJlc3NpbmcgdGhlDQog ICBmaXJzdCBPUEVTIHByb2Nlc3NvciBpbiBhIGNoYWluIG9mIHByb2Nlc3Nv cnMgaXMgc3VmZmljaWVudC4gVGhhdCBpcywNCiAgIGEgY2hhaW4gb2YgT1BF UyBwcm9jZXNzb3JzIGlzIHZpZXdlZCBhcyBhIHNpbmdsZSBPUEVTICJzeXN0 ZW0iIGF0IHRoZQ0KICAgYWRkcmVzcyBvZiB0aGUgZmlyc3QgY2hhaW4gZWxl bWVudC4NCg0KICAgVGhlIG5vdGlvbiBvZiBhIGNoYWluIGlzIG5vdCBzdHJp Y3RseSBkZWZpbmVkIGJ5IElBQi4gRm9yIHRoZSBwdXJwb3NlDQogICBvZiBh ZGRyZXNzaW5nIHRoaXMgY29uc2lkZXJhdGlvbiwgYSBncm91cCBvZiBPUEVT IHByb2Nlc3NvcnMgd29ya2luZw0KICAgb24gYSBnaXZlbiBhcHBsaWNhdGlv biB0cmFuc2FjdGlvbiBpcyBjb25zaWRlcmVkLiBTdWNoIGEgZ3JvdXAgd291 bGQNCiAgIG5lY2Vzc2FyaWx5IGZvcm0gYSBzaW5nbGUgcHJvY2Vzc2luZyBj aGFpbiwgd2l0aCBhIHNpbmdsZSAiZXhpdCIgT1BFUw0KICAgcHJvY2Vzc29y IChpLmUuLCB0aGUgcHJvY2Vzc29yIHRoYXQgYWRhcHRlZCB0aGUgZ2l2ZW4g bWVzc2FnZSBsYXN0KS4NCiAgIFRoZSBPUEVTIGFyY2hpdGVjdHVyZSBlc3Nl bnRpYWxseSByZXF1aXJlcyB0aGF0IGxhc3QgT1BFUyBwcm9jZXNzb3INCiAg IHRvIGJlIGV4cGxpY2l0bHkgYWRkcmVzc2FibGUgYXQgdGhlIElQIGxheWVy IGJ5IHRoZSBkYXRhIGNvbnN1bWVyDQogICBhcHBsaWNhdGlvbi4gVGhlIGNo YWluIGZvcm1hdGlvbiwgaW5jbHVkaW5nIGl0cyBleGl0IHBvaW50IG1heSBk ZXBlbmQNCiAgIG9uIGFuIGFwcGxpY2F0aW9uIG1lc3NhZ2UgYW5kIG90aGVy IGR5bmFtaWMgZmFjdG9ycyBzdWNoIGFzIHRpbWUgb2YNCiAgIHRoZSBkYXkg b3Igc3lzdGVtIGxvYWQuDQoNCiAgIEZ1cnRoZXJtb3JlLCBpZiBPUEVTIHBy b2Nlc3NpbmcgaXMgYW4gaW50ZXJuYWwgcHJvY2Vzc2luZyBzdGVwIGF0IGEN CiAgIGRhdGEgY29uc3VtZXIgb3IgYSBkYXRhIHByb3ZpZGVyIGFwcGxpY2F0 aW9uIHNpZGUsIHRoZW4gdGhlIGxhc3QgT1BFUw0KICAgcHJvY2Vzc29yIG1h eSByZXNpZGUgaW4gYSBwcml2YXRlIGFkZHJlc3Mgc3BhY2UgYW5kIG1heSBu b3QgYmUNCiAgIGV4cGxpY2l0bHkgYWRkcmVzc2FibGUgZnJvbSB0aGUgb3V0 c2lkZS4gSW4gc3VjaCBzaXR1YXRpb25zLCB0aGUNCiAgIHByb2Nlc3Npbmcg c2lkZSBtdXN0IGRlc2lnbmF0ZSBhbiBhZGRyZXNzYWJsZSBwb2ludCBvbiB0 aGUgc2FtZQ0KICAgcHJvY2Vzc2luZyBjaGFpbi4gVGhhdCBkZXNpZ25hdGVk IHBvaW50IG1heSBub3QgYmUsIHN0cmljdGx5DQogICBzcGVha2luZywgYW4g T1BFUyBwcm9jZXNzb3IsIGJ1dCBpdCB3aWxsIHN1ZmZpY2UgYXMgc3VjaCBh cyBmYXIgYXMNCiAgIElBQiBjb25zaWRlcmF0aW9ucyBhcmUgY29uY2VybmVk IC0tIHRoZSBkYXRhIGNvbnN1bWVyIGFwcGxpY2F0aW9uDQogICB3aWxsIGJl IGFibGUgdG8gYWRkcmVzcyBpdCBleHBsaWNpdGx5IGF0IHRoZSBJUCBsYXll ciBhbmQgaXQgd2lsbA0KICAgcmVwcmVzZW50IHRoZSBPUEVTIHByb2Nlc3Np bmcgY2hhaW4gdG8gdGhlIG91dHNpZGUgd29ybGQuDQoNCiAgIERlc2lnbmF0 aW5nIGFuIGFkZHJlc3NhYmxlIHByb2Nlc3NpbmcgcG9pbnQgYXZvaWRzIHRo ZSBjb25mbGljdA0KICAgYmV0d2VlbiBuYXJyb3cgaW50ZXJwcmV0YXRpb24g b2YgdGhlIElBQiBjb25zaWRlcmF0aW9uIGFuZCByZWFsDQogICBzeXN0ZW0g ZGVzaWducy4gSXQgaXMgaXJyYXRpb25hbCB0byBleHBlY3QgYSBjb250ZW50 IHByb3ZpZGVyIHRvDQogICBwcm92aWRlIGFjY2VzcyB0byBpbnRlcm5hbCBo b3N0cyBwYXJ0aWNpcGF0aW5nIGluIGNvbnRlbnQgZ2VuZXJhdGlvbiwNCiAg IHdoZXRoZXIgT1BFUyBwcm9jZXNzb3JzIGFyZSBpbnZvbHZlZCBvciBub3Qu IE1vcmVvdmVyLCBwcm92aWRpbmcgc3VjaA0KICAgYWNjZXNzIHdvdWxkIHNl cnZlIGxpdHRsZSBwcmFjdGljYWwgcHVycG9zZSBiZWNhdXNlIGludGVybmFs IE9QRVMNCiAgIHByb2Nlc3NvcnMgYXJlIG5vdCBsaWtlbHkgdG8gYmUgYWJs ZSB0byBhbnN3ZXIgYW55IGRhdGEgY29uc3VtZXINCiAgIHF1ZXJpZXMsIGJl aW5nIGNvbXBsZXRlbHkgb3V0IG9mIGNvbnRlbnQgZ2VuZXJhdGlvbiBjb250 ZXh0LiBGb3INCiAgIGV4YW1wbGUsIGFuIE9QRVMgcHJvY2Vzc29yIGFkZGlu ZyBjdXN0b21lci1zcGVjaWZpYyBpbmZvcm1hdGlvbiB0bw0KICAgWE1MIHBh Z2VzIG1heSBub3QgdW5kZXJzdGFuZCBvciBiZSBhd2FyZSBvZiBhbnkgZmlu YWwgSFRNTCBjb250ZW50DQogICB0aGF0IHRoZSBkYXRhIGNvbnN1bWVyIGFw cGxpY2F0aW9uIHJlY2VpdmVzIGFuZCBtYXkgbm90IGJlIGFibGUgdG8NCiAg IG1hcCBlbmQgdXNlciByZXF1ZXN0IHRvIGFueSBpbnRlcm5hbCB1c2VyIGlk ZW50aWZpY2F0aW9uLiBTaW5jZSBPUEVTDQoNCg0KDQpCYXJiaXIgJiBSb3Vz c2tvdiAgICAgICAgRXhwaXJlcyBBcHJpbCAyNiwgMjAwNCAgICAgICAgICAg ICAgICAgW1BhZ2UgNl0NCgwNCkludGVybmV0LURyYWZ0ICAgIE9QRVMgVHJl YXRtZW50IG9mIElBQiBDb25zaWRlcmF0aW9ucyAgICAgIE9jdG9iZXIgMjAw Mw0KDQoNCiAgIHJlcXVpcmVzIHRoZSBlbmQgb2YgdGhlIG1lc3NhZ2UgcHJv Y2Vzc2luZyBjaGFpbiB0byBiZSBhZGRyZXNzYWJsZSwNCiAgIHRoZSBjb25m bGljdCBkb2VzIG5vdCBleGlzdC4gT1BFUyBwbGFjZXMgbm8gcmVxdWlyZW1l bnRzIG9uIHRoZQ0KICAgaW50ZXJuYWwgYXJjaGl0ZWN0dXJlIG9mIGRhdGEg cHJvZHVjZXIgc3lzdGVtcyB3aGlsZSByZXF1aXJpbmcgdGhlDQogICBlbnRp cmUgT1BFUy1yZWxhdGVkIGNvbnRlbnQgcHJvZHVjdGlvbiAic3lzdGVtIiB0 byBiZSBhZGRyZXNzYWJsZSBhdA0KICAgdGhlIElQIGxheWVyLg0KDQogICBQ cml2YXRlIERvbWFpbiAgICB8IFB1YmxpYyBEb21haW4gICAgIHwgUHJpdmF0 ZSBEb21haW4NCiAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgfA0KICAgKy0tLS0tLS0tLS0tLS0tKyAgfCAgICAgICAgICAgICAr LS0tLS0tLS0tLS0tLSsgICAgICArLS0tLS0tLS0rDQogICB8IERhdGEgICAg ICAgICB8ICB8ICAgICAgICAgICAgIHwgT1BFUyBTeXN0ZW0gfCAgICAgIHxE YXRhICAgIHwNCiAgIHwgQ29uc3VtZXIgICAgIHw8LS0tIG5ldHdvcmsgLS0+ fCB3aXRoIHB1YmxpYyB8PC0tLS0+fFByb3ZpZGVyfA0KICAgfCBBcHBsaWNh dGlvbiAgfCAgfCAgICAgICAgICAgICB8IElQIGFkZHJlc3MgIHwgICAgICB8 QXBwICAgICB8DQogICArLS0tLS0tLS0tLS0tLS0rICB8ICAgICAgICAgICAg ICstLS0tLS0tLS0tLS0tKyAgICAgICstLS0tLS0tLSsNCiAgICAgICAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICB8DQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDENCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KQmFyYmlyICYgUm91c3Nrb3YgICAgICAgIEV4cGlyZXMgQXBy aWwgMjYsIDIwMDQgICAgICAgICAgICAgICAgIFtQYWdlIDddDQoMDQpJbnRl cm5ldC1EcmFmdCAgICBPUEVTIFRyZWF0bWVudCBvZiBJQUIgQ29uc2lkZXJh dGlvbnMgICAgICBPY3RvYmVyIDIwMDMNCg0KDQo1LiBOb3RpZmljYXRpb24g Q29uc2lkZXJhdGlvbnMNCg0KICAgVGhpcyBzZWN0aW9uIGRpc2N1c3NlcyBo b3cgT1BFUyBmcmFtZXdvcmsgYWRkcmVzc2VzIElBQiBOb3RpZmljYXRpb24N CiAgIGNvbnNpZGVyYXRpb25zIDMuMSBhbmQgMy4yLg0KDQo1LjEgTm90aWZp Y2F0aW9uIHZlcnN1cyB0cmFjZQ0KDQogICBCZWZvcmUgc3BlY2lmaWMgY29u c2lkZXJhdGlvbnMgYXJlIGRpc2N1c3NlZCwgdGhlIHJlbGF0aW9uc2hpcA0K ICAgYmV0d2VlbiBJQUIgbm90aWZpY2F0aW9ucyBhbmQgT1BFUyB0cmFjaW5n IGhhcyB0byBiZSBleHBsYWluZWQuIE9QRVMNCiAgIGZyYW1ld29yayBjb25j ZW50cmF0ZXMgb24gdHJhY2luZyByYXRoZXIgdGhhbiBub3RpZmljYXRpb24u IFRoZSBPUEVTDQogICBDb21tdW5pY2F0aW9ucyBzcGVjaWZpY2F0aW9uIFtJ LUQuaWV0Zi1vcGVzLWVuZC1jb21tXSBkZWZpbmVzICJPUEVTDQogICB0cmFj ZSIgYXMgaW5mb3JtYXRpb24gYWJvdXQgT1BFUyBhZGFwdGF0aW9ucyB0aGF0 IGlzIGVtYmVkZGVkIGluIGFuDQogICBhcHBsaWNhdGlvbiBtZXNzYWdlLiBU aHVzLCBPUEVTIHRyYWNlIGZvbGxvd3MgdGhlIGFwcGxpY2F0aW9uIG1lc3Nh Z2UNCiAgIGl0IHRyYWNlcy4gVGhlIHRyYWNlIGlzIGZvciB0aGUgcmVjaXBp ZW50IG9mIHRoZSBhcHBsaWNhdGlvbiBtZXNzYWdlLg0KICAgVHJhY2VzIGFy ZSBpbXBsZW1lbnRlZCBhcyBleHRlbnNpb25zIG9mIGFwcGxpY2F0aW9uIHBy b3RvY29scyBiZWluZw0KICAgYWRhcHRlZCBhbmQgdHJhY2VkLg0KDQogICBB cyBvcHBvc2VkIHRvIGFuIE9QRVMgdHJhY2UsIHByb3ZpZGVyIG5vdGlmaWNh dGlvbiAoYXMgaW1wbGllZCBieQ0KICAgSUFCKSBub3RpZmllcyB0aGUgc2Vu ZGVyIG9mIHRoZSBhcHBsaWNhdGlvbiBtZXNzYWdlIHJhdGhlciB0aGFuIHRo ZQ0KICAgcmVjaXBpZW50LiBUaHVzLCBub3RpZmljYXRpb25zIHByb3BhZ2F0 ZSBpbiB0aGUgb3Bwb3NpdGUgZGlyZWN0aW9uIG9mDQogICB0cmFjZXMuIFN1 cHBvcnRpbmcgbm90aWZpY2F0aW9ucyBkaXJlY3RseSB3b3VsZCByZXF1aXJl IGEgbmV3DQogICBwcm90b2NvbC4gRmlndXJlIDIgaWxsdXN0cmF0ZXMgdGhl IGRpZmZlcmVuY2VzIGJldHdlZW4gYSB0cmFjZSBhbmQNCiAgIG5vdGlmaWNh dGlvbiBmcm9tIGEgc2luZ2xlIGFwcGxpY2F0aW9uIG1lc3NhZ2UgcG9pbnQg b2Ygdmlldy4NCiAgIHNlbmRlciAtLVttZXNzYWdlIEFdLS0+IE9QRVMgLS1b bWVzc2FnZSBBJ10tLT4gcmVjaXBpZW50DQogICAgICBeICAgICAgICAgICAg ICAgICAgICAgICBWICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbd2l0 aCB0cmFjZV0NCiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgIHwNCiAg ICAgICstPC0tIFtub3RpZmljYXRpb25dIC0tLSsNCg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMg0KDQogICBTaW5jZSBub3Rp ZmljYXRpb25zIGNhbm5vdCBiZSBwaWdneS1iYWNrZWQgdG8gYXBwbGljYXRp b24gbWVzc2FnZXMsDQogICB0aGV5IGNyZWF0ZSBuZXcgbWVzc2FnZXMgYW5k IG1heSBkb3VibGUgdGhlIG51bWJlciBvZiBtZXNzYWdlcyB0aGUNCiAgIHNl bmRlciBoYXMgdG8gcHJvY2Vzcy4gVGhlIG51bWJlciBvZiBtZXNzYWdlcyB0 aGF0IG5lZWQgdG8gYmUgcHJvY2VlZA0KICAgaXMgbGFyZ2VyIGlmIHNldmVy YWwgaW50ZXJtZWRpYXJpZXMgb24gdGhlIG1lc3NhZ2UgcGF0aCBnZW5lcmF0 ZQ0KICAgbm90aWZpY2F0aW9ucykuIEFzc29jaWF0aW5nIG5vdGlmaWNhdGlv bnMgd2l0aCBhcHBsaWNhdGlvbiBtZXNzYWdlcw0KICAgbWF5IHJlcXVpcmUg ZHVwbGljYXRpbmcgYXBwbGljYXRpb24gbWVzc2FnZSBpbmZvcm1hdGlvbiBp bg0KICAgbm90aWZpY2F0aW9ucyBhbmQgbWF5IHJlcXVpcmUgbWFpbnRhaW5p bmcgYSBzZW5kZXIgc3RhdGUgdW50aWwNCiAgIG5vdGlmaWNhdGlvbiBpcyBy ZWNlaXZlZC4gVGhlc2UgYWN0aW9ucyBpbmNyZWFzZSB0aGUgcGVyZm9ybWFu Y2UNCiAgIG92ZXJoZWFkIG9mIG5vdGlmaWNhdGlvbnMuDQoNCiAgIFRoZSBs ZXZlbCBvZiBhdmFpbGFibGUgZGV0YWlscyBpbiBub3RpZmljYXRpb25zIHZl cnN1cyBwcm92aWRlcg0KICAgaW50ZXJlc3QgaW4gc3VwcG9ydGluZyBub3Rp ZmljYXRpb24gaXMgYW5vdGhlciBjb25jZXJuLiAgRXhwZXJpZW5jZQ0KICAg c2hvd3MgdGhhdCBjb250ZW50IHByb3ZpZGVycyBvZnRlbiByZXF1aXJlIHZl cnkgZGV0YWlsZWQgaW5mb3JtYXRpb24NCiAgIGFib3V0IHVzZXIgYWN0aW9u cyB0byBiZSBpbnRlcmVzdGVkIGluIG5vdGlmaWNhdGlvbnMgYXQgYWxsLiBG b3INCiAgIGV4YW1wbGUsIEhpdCBNZXRlcmluZyBwcm90b2NvbCBbUkZDMjIy N10gaGFzIGJlZW4gZGVzaWduZWQgdG8gc3VwcGx5DQogICBjb250ZW50IHBy b3ZpZGVycyB3aXRoIHByb3h5IGNhY2hlIGhpdCBjb3VudHMsIGluIGFuIGVm Zm9ydCB0byByZWR1Y2UNCiAgIGNhY2hlIGJ1c3RpbmcgYmVoYXZpb3Igd2hp Y2ggd2FzIGNhdXNlZCBieSBjb250ZW50IHByb3ZpZGVycyBkZXNpcmUNCiAg IHRvIGdldCBhY2N1cmF0ZSBzaXRlICJhY2Nlc3MgY291bnRzIi4gSG93ZXZl ciwgdGhlIEhpdCBNZXRlcmluZw0KDQoNCg0KQmFyYmlyICYgUm91c3Nrb3Yg ICAgICAgIEV4cGlyZXMgQXByaWwgMjYsIDIwMDQgICAgICAgICAgICAgICAg IFtQYWdlIDhdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICBPUEVTIFRyZWF0bWVu dCBvZiBJQUIgQ29uc2lkZXJhdGlvbnMgICAgICBPY3RvYmVyIDIwMDMNCg0K DQogICBwcm90b2NvbCBpcyBjdXJyZW50bHkgbm90IHdpZGVseSBkZXBsb3ll ZCBiZWNhdXNlIHRoZSBwcm90b2NvbCBkb2VzDQogICBub3Qgc3VwcGx5IGNv bnRlbnQgcHJvdmlkZXJzIHdpdGggaW5mb3JtYXRpb24gc3VjaCBhcyBjbGll bnQgSVANCiAgIGFkZHJlc3NlcywgYnJvd3NlciB2ZXJzaW9ucywgb3IgY29v a2llcy4NCg0KICAgSGl0IE1ldGVyaW5nIGV4cGVyaWVuY2UgaXMgcmVsZXZh bnQgYmVjYXVzZSBIaXQgTWV0ZXJpbmcgcHJvdG9jb2wgd2FzDQogICBkZXNp Z25lZCB0byBkbyBmb3IgSFRUUCBjYWNoaW5nIGludGVybWVkaWFyaWVzIHdo YXQgT1BFUw0KICAgbm90aWZpY2F0aW9ucyBhcmUgbWVhbnQgdG8gZG8gZm9y IE9QRVMgaW50ZXJtZWRpYXJpZXMuIFBlcmZvcm1hbmNlDQogICByZXF1aXJl bWVudHMgY2FsbCBmb3Igc3RhdGUgcmVkdWN0aW9uIHZpYSBhZ2dyZWdhdGlv biBvZg0KICAgbm90aWZpY2F0aW9ucyB3aGlsZSBwcm92aWRlciBwcmVmZXJl bmNlcyBjYWxsIGZvciBzdGF0ZSBwcmVzZXJ2YXRpb24NCiAgIG9yIGR1cGxp Y2F0aW9uLiBBY2hpZXZpbmcgdGhlIHJpZ2h0IGJhbGFuY2Ugd2hlbiB0d28g c2lkZXMgYmVsb25nIHRvDQogICBkaWZmZXJlbnQgb3JnYW5pemF0aW9ucyBh bmQgaGF2ZSBkaWZmZXJlbnQgb3B0aW1pemF0aW9uIHByaW9yaXRpZXMNCiAg IG1heSBiZSBpbXBvc3NpYmxlLg0KDQogICBUaHVzLCBpbnN0ZWFkIG9mIGV4 cGxpY2l0bHkgc3VwcG9ydGluZyBub3RpZmljYXRpb25zIGF0IHRoZSBwcm90 b2NvbA0KICAgbGV2ZWwsIE9QRVMgY29uY2VudHJhdGVzIG9uIHRyYWNpbmcg ZmFjaWxpdGllcy4gSW4gZXNzZW5jZSwgT1BFUw0KICAgc3VwcG9ydHMgbm90 aWZpY2F0aW9ucyBpbmRpcmVjdGx5LCB1c2luZyB0cmFjaW5nIGZhY2lsaXRp ZXMuIEluIG90aGVyDQogICB3b3JkcywgdGhlIElBQiBjaG9pY2Ugb2YgIk5v dGlmaWNhdGlvbiIgbGFiZWwgaXMgaW50ZXJwcmV0ZWQgYXMNCiAgICJOb3Rp ZmljYXRpb24gYXNzaXN0YW5jZSIgKGkuZS4gIG1ha2luZyBub3RpZmljYXRp b25zIG1lYW5pbmdmdWwpIGFuZA0KICAgaXMgbm90IGludGVycHJldGVkIGFz IGEgIk5vdGlmaWNhdGlvbiBwcm90b2NvbCIuDQoNCiAgIFRoZSBhYm92ZSBj b25jZXJucyBjYWxsIGZvciBtYWtpbmcgbm90aWZpY2F0aW9uIG9wdGlvbmFs LiBUaGUgT1BFUw0KICAgYXJjaGl0ZWN0dXJlIGFsbG93cyBmb3IgYW4gZWZm aWNpZW50IGFuZCBtZWFuaW5nZnVsIG5vdGlmaWNhdGlvbg0KICAgcHJvdG9j b2wgdG8gYmUgaW1wbGVtZW50ZWQgaW4gY2VydGFpbiBPUEVTIGVudmlyb25t ZW50cy4gIEZvcg0KICAgc3BlY2lmaWMgZXhhbXBsZXMsIHNlZSB0aGUgIk9w dGlvbmFsIE5vdGlmaWNhdGlvbiIgc2VjdGlvbiBpbg0KICAgW0ktRC5pZXRm LW9wZXMtZW5kLWNvbW1dLg0KDQo1LjIgQW4gZXhhbXBsZSBvZiBhbiBPUEVT IHRyYWNlIGZvciBIVFRQDQoNCiAgIFRoZSBleGFtcGxlIGJlbG93IGlsbHVz dHJhdGVzIGFkYXB0YXRpb25zIGRvbmUgdG8gSFRUUCByZXF1ZXN0IGF0IGFu DQogICBPUEVTIHByb2Nlc3NvciBvcGVyYXRlZCBieSB0aGUgY2xpZW50IElT UC4gQm90aCBvcmlnaW5hbCAoYXMgc2VudCBieQ0KICAgYW4gZW5kIHVzZXIp IGFuZCBhZGFwdGVkIChhcyByZWNlaXZlZCBieSB0aGUgb3JpZ2luIHdlYiBz ZXJ2ZXIpDQogICByZXF1ZXN0cyBhcmUgc2hvd24uIFRoZSBwcmltYXJ5IGFk YXB0YXRpb24gaXMgdGhlIG1vZGlmaWNhdGlvbiBvZg0KICAgSFRUUCAiQWNj ZXB0IiBoZWFkZXIuICBUaGUgc2Vjb25kYXJ5IGFkYXB0YXRpb24gaXMgdGhl IGFkZGl0aW9uIG9mIGFuDQogICAiT1BFUy1WaWEiIEhUVFAgZXh0ZW5zaW9u IGhlYWRlciBbSS1ELmlldGYtb3Blcy1odHRwXSAoWFhYOiBidXQgaXQgaXMN CiAgIG5vdCBPUEVTLVZpYSwgaXQgaXMgT1BFUy1TeXN0ZW0gZm9yIG5vdzsg T1BFUy1WaWEgaXMgcHJvYmFibHkgYmV0dGVyDQogICBmb3IgYSBmZXcgcmVh c29ucyB0aG91Z2gpLg0KDQogICBHRVQgL3B1Yi9XV1cvIEhUVFAvMS4xDQog ICBIb3N0OiB3d3cudzMub3JnDQogICBBY2NlcHQ6IHRleHQvcGxhaW4NCg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMw0KDQog ICAuLi4gbWF5IGJlIGFkYXB0ZWQgYnkgYW4gSVNQIE9QRVMgc3lzdGVtIHRv IGJlY29tZToNCg0KICAgR0VUIC9wdWIvV1dXLyBIVFRQLzEuMQ0KICAgSG9z dDogd3d3LnczLm9yZw0KICAgQWNjZXB0OiB0ZXh0L3BsYWluOyBxPTAuNSwg dGV4dC9odG1sLCB0ZXh0L3gtZHZpOyBxPTAuOA0KDQoNCg0KQmFyYmlyICYg Um91c3Nrb3YgICAgICAgIEV4cGlyZXMgQXByaWwgMjYsIDIwMDQgICAgICAg ICAgICAgICAgIFtQYWdlIDldDQoMDQpJbnRlcm5ldC1EcmFmdCAgICBPUEVT IFRyZWF0bWVudCBvZiBJQUIgQ29uc2lkZXJhdGlvbnMgICAgICBPY3RvYmVy IDIwMDMNCg0KDQogICBPUEVTLVZpYTogaHR0cDovL3d3dy5pc3AtZXhhbXBs ZS5jb20vb3Blcy8/Y2xpZW50LWhhc2g9MTIzNDU2Nw0KDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSA0DQoNCiAgIFRoZSBleGFt cGxlIGJlbG93IGlsbHVzdHJhdGVzIGFkYXB0YXRpb25zIGRvbmUgdG8gSFRU UCByZXNwb25zZSBhdCBhbg0KICAgT1BFUyBpbnRlcm1lZGlhcnkgb3BlcmF0 ZWQgYnkgYSBDb250ZW50IERpc3RyaWJ1dGlvbiBOZXR3b3JrIChDRE4pLg0K ICAgQm90aCBvcmlnaW5hbCAoYXMgc2VudCBieSB0aGUgb3JpZ2luIHdlYiBz ZXJ2ZXIpIGFuZCBhZGFwdGVkIChhcw0KICAgcmVjZWl2ZWQgYnkgdGhlIGVu ZCB1c2VyKSByZXNwb25zZXMgYXJlIHNob3duLiBUaGUgcHJpbWFyeSBhZGFw dGF0aW9uDQogICBpcyB0aGUgY29udmVyc2lvbiBmcm9tIEhUTUwgbWFya3Vw IHRvIHBsYWluIHRleHQuIFRoZSBzZWNvbmRhcnkNCiAgIGFkYXB0YXRpb24g aXMgdGhlIGFkZGl0aW9uIG9mIGFuICJPUEVTLVZpYSIgSFRUUCBleHRlbnNp b24gaGVhZGVyLg0KDQogICBIVFRQLzEuMSAyMDAgT0sNCiAgIENvbnRlbnQt TGVuZ3RoOiAxMjM0NQ0KICAgQ29udGVudC1FbmNvZGluZzogdGV4dC9odG1s DQoNCiAgIDxodG1sPjxoZWFkPjxoMT5BdmFpbGFibGUgRG9jdW1lbnRhLi4u DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDUN Cg0KICAgLi4uIG1heSBiZSBhZGFwdGVkIGJ5IGEgQ0ROIE9QRVMgc3lzdGVt IHRvIGJlY29tZToNCg0KICAgSFRUUC8xLjEgMjAwIE9LDQogICBDb250ZW50 LUxlbmd0aDogMjM0NQ0KICAgQ29udGVudC1FbmNvZGluZzogdGV4dC9wbGFp bg0KICAgT1BFUy1WaWE6IGh0dHA6Ly93d3cuY2RuLWV4YW1wbGUuY29tL29w ZXMvP3NpdGU9NzY1NDMyMSZzZXJ2aWNlPWgydA0KDQogICBBVkFJTEFCTEUg RE9DVU1FTlRBLi4uDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgRmlndXJlIDYNCg0KICAgSW4gdGhlIGFib3ZlIGV4YW1wbGVzLCAiT1BF Uy1WaWEiIGhlYWRlciB2YWx1ZXMgY29udGFpbiBVUkxzIHRoYXQgbWF5DQog ICBwb2ludCB0byBPUEVTLXNwZWNpZmljIGRvY3VtZW50cyBzdWNoIGFzIGRl c2NyaXB0aW9uIG9mIHRoZSBPUEVTDQogICBvcGVyYXRvciBhbmQgaXRzIHBy aXZhY3kgcG9saWN5LiAgVGhvc2UgZG9jdW1lbnRzIG1heSBiZQ0KICAgcGFy YW1ldGVyaXplZCB0byBhbGxvdyBmb3IgY3VzdG9taXphdGlvbnMgc3BlY2lm aWMgdG8gdGhlIHRyYW5zYWN0aW9uDQogICBiZWluZyB0cmFjZWQgKGUuZy4s IGNsaWVudCBvciBldmVuIHRyYW5zYWN0aW9uIGlkZW50aWZpZXIgbWF5IGJl IHVzZWQNCiAgIHRvIHByb3ZpZGUgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBw ZXJmb3JtZWQgYWRhcHRhdGlvbnMpLiBUcmFjZWQgT1BFUw0KICAgVVJMcyBt YXkgYmUgbGF0ZXIgdXNlZCB0byByZXF1ZXN0IE9QRVMgYnlwYXNzDQogICBb SS1ELmlldGYtb3Blcy1lbmQtY29tbV0uDQoNCjUuMyBDb25zaWRlcmF0aW9u ICgzLjEpICdOb3RpZmljYXRpb24nDQoNCiAgICJUaGUgb3ZlcmFsbCBPUEVT IGZyYW1ld29yayBuZWVkcyB0byBhc3Npc3QgY29udGVudCBwcm92aWRlcnMg aW4NCiAgIGRldGVjdGluZyBhbmQgcmVzcG9uZGluZyB0byBjbGllbnQtY2Vu dHJpYyBhY3Rpb25zIGJ5IE9QRVMNCiAgIGludGVybWVkaWFyaWVzIHRoYXQg YXJlIGRlZW1lZCBpbmFwcHJvcHJpYXRlIGJ5IHRoZSBjb250ZW50DQogICBw cm92aWRlci4iW1JGQzMyMzhdDQoNCiAgIE9QRVMgdHJhY2luZyBtZWNoYW5p c21zIGFzc2lzdCBjb250ZW50IHByb3ZpZGVycyBpbiBkZXRlY3RpbmcNCiAg IGNsaWVudC1jZW50cmljIGFjdGlvbnMgYnkgT1BFUyBpbnRlcm1lZGlhcmll cy4gU3BlY2lmaWNhbGx5LCBhDQoNCg0KDQpCYXJiaXIgJiBSb3Vzc2tvdiAg ICAgICAgRXhwaXJlcyBBcHJpbCAyNiwgMjAwNCAgICAgICAgICAgICAgICBb UGFnZSAxMF0NCgwNCkludGVybmV0LURyYWZ0ICAgIE9QRVMgVHJlYXRtZW50 IG9mIElBQiBDb25zaWRlcmF0aW9ucyAgICAgIE9jdG9iZXIgMjAwMw0KDQoN CiAgIGNvbXBsaWFudCBPUEVTIGludGVybWVkaWFyeSBvciBzeXN0ZW0gbm90 aWZpZXMgYSBjb250ZW50IHByb3ZpZGVyIG9mDQogICBpdHMgcHJlc2VuY2Ug YnkgaW5jbHVkaW5nIGl0cyB0cmFjaW5nIGluZm9ybWF0aW9uIGluIHRoZSBh cHBsaWNhdGlvbg0KICAgcHJvdG9jb2wgcmVxdWVzdHMuIEFuIE9QRVMgc3lz dGVtIE1VU1QgbGVhdmUgaXRzIHRyYWNlDQogICBbSS1ELmlldGYtb3Blcy1l bmQtY29tbV0uICBEZXRlY3Rpb24gYXNzaXN0YW5jZSBoYXMgaXRzIGxpbWl0 YXRpb25zLg0KICAgU29tZSBPUEVTIGludGVybWVkaWFyaWVzIG1heSB3b3Jr IGV4Y2x1c2l2ZWx5IG9uIHJlc3BvbnNlcyBhbmQgbWF5DQogICBub3QgaGF2 ZSBhIGNoYW5jZSB0byB0cmFjZSB0aGUgcmVxdWVzdC4gTW9yZW92ZXIsIHNv bWUgYXBwbGljYXRpb24NCiAgIHByb3RvY29scyBtYXkgbm90IGhhdmUgZXhw bGljaXQgcmVxdWVzdHMgKGUuZy4sIGEgY29udGVudCBwdXNoDQogICBzZXJ2 aWNlKS4NCg0KICAgT1BFUyB0cmFjaW5nIG1lY2hhbmlzbXMgYXNzaXN0IGNv bnRlbnQgcHJvdmlkZXJzIGluIHJlc3BvbmRpbmcgdG8NCiAgIGNsaWVudC1j ZW50cmljIGFjdGlvbnMgYnkgT1BFUyBpbnRlcm1lZGlhcmllcy4gU3BlY2lm aWNhbGx5LCBPUEVTDQogICB0cmFjZXMgTVVTVCBpbmNsdWRlIGlkZW50aWZp Y2F0aW9uIG9mIE9QRVMgc3lzdGVtcyBhbmQgU0hPVUxEIGluY2x1ZGUNCiAg IGEgbGlzdCBvZiBhZGFwdGF0aW9uIGFjdGlvbnMgcGVyZm9ybWVkIG9uIHBy b3ZpZGVyJ3MgY29udGVudC4gVGhpcw0KICAgdHJhY2luZyBpbmZvcm1hdGlv biBtYXkgYmUgaW5jbHVkZWQgaW4gdGhlIGFwcGxpY2F0aW9uIHJlcXVlc3Qu DQogICBVc3VhbGx5LCBob3dldmVyLCB0aGlzIGluZm9ybWF0aW9uIHdpbGwg YmUgaW5jbHVkZWQgaW4gdGhlDQogICBhcHBsaWNhdGlvbiByZXNwb25zZSwg YW4gYWRhcHRlZCB2ZXJzaW9uIG9mIHdoaWNoIGRvZXMgbm90IHJlYWNoIHRo ZQ0KICAgY29udGVudCBwcm92aWRlci4gSWYgT1BFUyBlbmQgcG9pbnRzIGNv b3BlcmF0ZSwgdGhlbiBub3RpZmljYXRpb24gY2FuDQogICBiZSBhc3Npc3Rl ZCB3aXRoIHRyYWNlcy4gQ29udGVudCBwcm92aWRlcnMgdGhhdCBzdXNwZWN0 IG9yIGV4cGVyaWVuY2UNCiAgIGRpZmZpY3VsdGllcyBjYW4gZG8gYW55IG9m IHRoZSBmb2xsb3dpbmc6DQoNCiAgIG8gIENoZWNrIHdoZXRoZXIgcmVxdWVz dHMgdGhleSByZWNlaXZlIHBhc3MgdGhyb3VnaCBPUEVTDQogICAgICBpbnRl cm1lZGlhcmllcy4gUHJlc2VuY2Ugb2YgT1BFUyB0cmFjaW5nIGluZm8gd2ls bCBkZXRlcm1pbmUgdGhhdC4NCiAgICAgIFRoaXMgY2hlY2sgaXMgb25seSBw b3NzaWJsZSBmb3IgcmVxdWVzdC9yZXNwb25zZSBwcm90b2NvbHMuIEZvcg0K ICAgICAgb3RoZXIgcHJvdG9jb2xzIChlLmcuLCBicm9hZGNhc3Qgb3IgcHVz aCksIHRoZSBwcm92aWRlciB3b3VsZCBoYXZlDQogICAgICB0byBhc3N1bWUg dGhhdCBPUEVTIGludGVybWVkaWFyaWVzIGFyZSBpbnZvbHZlZCB1bnRpbCBw cm92ZW4NCiAgICAgIG90aGVyd2lzZS4NCg0KICAgbyAgSWYgT1BFUyBpbnRl cm1lZGlhcmllcyBhcmUgc3VzcGVjdGVkLCByZXF1ZXN0IE9QRVMgdHJhY2Vz IGZyb20NCiAgICAgIHBvdGVudGlhbGx5IGFmZmVjdGVkIHVzZXIocykuIFRo ZSB0cmFjZSB3aWxsIGJlIGEgcGFydCBvZiB0aGUNCiAgICAgIGFwcGxpY2F0 aW9uIG1lc3NhZ2UgcmVjZWl2ZWQgYnkgdGhlIHVzZXIgc29mdHdhcmUuIElm IGludm9sdmVkDQogICAgICBwYXJ0aWVzIGNvb3BlcmF0ZSwgdGhlIHByb3Zp ZGVyKHMpIG1heSBoYXZlIGFjY2VzcyB0byBhbGwgdGhlDQogICAgICBuZWVk ZWQgaW5mb3JtYXRpb24uICBDZXJ0YWlubHksIGxhY2sgb2YgY29vcGVyYXRp b24gbWF5IGhpbmRlcg0KICAgICAgYWNjZXNzIHRvIHRyYWNpbmcgaW5mb3Jt YXRpb24uIFRvIGVuY291cmFnZSBjb29wZXJhdGlvbiwgZGF0YQ0KICAgICAg cHJvdmlkZXJzIG1pZ2h0IGJlIGFibGUgdG8gZGVueSBzZXJ2aWNlIHRvIHVu Y29vcGVyYXRpdmUgdXNlcnMuDQoNCiAgIG8gIFNvbWUgdHJhY2VzIG1heSBp bmRpY2F0ZSB0aGF0IG1vcmUgaW5mb3JtYXRpb24gaXMgYXZhaWxhYmxlIGJ5 DQogICAgICBhY2Nlc3NpbmcgY2VydGFpbiByZXNvdXJjZXMgb24gdGhlIHNw ZWNpZmllZCBPUEVTIGludGVybWVkaWFyeSBvcg0KICAgICAgZWxzZXdoZXJl LiBDb250ZW50IHByb3ZpZGVycyBtYXkgcXVlcnkgZm9yIG1vcmUgaW5mb3Jt YXRpb24gaW4NCiAgICAgIHRoaXMgY2FzZS4NCg0KICAgbyAgSWYgZXZlcnl0 aGluZyBlbHNlIGZhaWxzLCBwcm92aWRlcnMgY2FuIGVuZm9yY2Ugbm8tYWRh cHRhdGlvbg0KICAgICAgcG9saWN5IHVzaW5nIGFwcHJvcHJpYXRlIE9QRVMg YnlwYXNzIG1lY2hhbmlzbXMgYW5kL29yIGVuZC10by1lbmQNCiAgICAgIGVu Y3J5cHRpb24gbWVjaGFuaXNtcy4NCg0KICAgT1BFUyBkZXRlY3Rpb24gYW5k IHJlc3BvbnNlIGFzc2lzdGFuY2UgaXMgbGltaXRlZCB0byBhcHBsaWNhdGlv bg0KICAgcHJvdG9jb2xzIHdpdGggc3VwcG9ydCBmb3IgdHJhY2luZyBleHRl bnNpb25zLiBGb3IgZXhhbXBsZSwgSFRUUA0KICAgW1JGQzI2MTZdIGhhcyBz dWNoIHN1cHBvcnQgd2hpbGUgRE5TIG92ZXIgVURQIGRvZXMgbm90Lg0KDQoN Cg0KDQpCYXJiaXIgJiBSb3Vzc2tvdiAgICAgICAgRXhwaXJlcyBBcHJpbCAy NiwgMjAwNCAgICAgICAgICAgICAgICBbUGFnZSAxMV0NCgwNCkludGVybmV0 LURyYWZ0ICAgIE9QRVMgVHJlYXRtZW50IG9mIElBQiBDb25zaWRlcmF0aW9u cyAgICAgIE9jdG9iZXIgMjAwMw0KDQoNCjUuNCBDb25zaWRlcmF0aW9uICgz LjIpICdOb3RpZmljYXRpb24nDQoNCiAgICJUaGUgb3ZlcmFsbCBPUEVTIGZy YW1ld29yayBzaG91bGQgYXNzaXN0IGVuZCB1c2VycyBpbiBkZXRlY3Rpbmcg dGhlDQogICBiZWhhdmlvciBvZiBPUEVTIGludGVybWVkaWFyaWVzLCBwb3Rl bnRpYWxseSBhbGxvd2luZyB0aGVtIHRvDQogICBpZGVudGlmeSBpbXBlcmZl Y3Qgb3IgY29tcHJvbWlzZWQgaW50ZXJtZWRpYXJpZXMuIltSRkMzMjM4XQ0K DQogICBPUEVTIHRyYWNpbmcgbWVjaGFuaXNtcyBhc3Npc3QgZW5kIHVzZXJz IGluIGRldGVjdGluZyBPUEVTDQogICBpbnRlcm1lZGlhcmllcy4gU3BlY2lm aWNhbGx5LCBhIGNvbXBsaWFudCBPUEVTIGludGVybWVkaWFyeSBvciBzeXN0 ZW0NCiAgIG5vdGlmaWVzIGFuIGVuZCB1c2VyIG9mIGl0cyBwcmVzZW5jZSBi eSBpbmNsdWRpbmcgaXRzIHRyYWNpbmcNCiAgIGluZm9ybWF0aW9uIGluIHRo ZSBhcHBsaWNhdGlvbiBwcm90b2NvbCBtZXNzYWdlcyBzZW50IHRvIHRoZSBj bGllbnQuDQogICBBbiBPUEVTIHN5c3RlbSBNVVNUIGxlYXZlIGl0cyB0cmFj ZSBbSS1ELmlldGYtb3Blcy1lbmQtY29tbV0uDQogICBIb3dldmVyLCBkZXRl Y3Rpb24gYXNzaXN0YW5jZSBoYXMgaXRzIGxpbWl0YXRpb25zLiBTb21lIE9Q RVMgc3lzdGVtcw0KICAgbWF5IHdvcmsgZXhjbHVzaXZlbHkgb24gcmVxdWVz dHMgYW5kIG1heSBub3QgaGF2ZSBhIGNoYW5jZSB0byB0cmFjZQ0KICAgdGhl IHJlc3BvbnNlLiAgTW9yZW92ZXIsIHNvbWUgYXBwbGljYXRpb24gcHJvdG9j b2xzIG1heSBub3QgaGF2ZQ0KICAgZXhwbGljaXQgcmVzcG9uc2VzIChlLmcu LCBldmVudCBsb2dnaW5nIHNlcnZpY2UpLg0KDQogICBPUEVTIGRldGVjdGlv biBhc3Npc3RhbmNlIGlzIGxpbWl0ZWQgdG8gYXBwbGljYXRpb24gcHJvdG9j b2xzIHdpdGgNCiAgIHN1cHBvcnQgZm9yIHRyYWNpbmcgZXh0ZW5zaW9ucy4g Rm9yIGV4YW1wbGUsIEhUVFAgW1JGQzI2MTZdIGhhcyBzdWNoDQogICBzdXBw b3J0IHdoaWxlIEROUyBvdmVyIFVEUCBkb2VzIG5vdC4NCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQpCYXJiaXIgJiBSb3Vzc2tvdiAgICAgICAgRXhwaXJlcyBBcHJp bCAyNiwgMjAwNCAgICAgICAgICAgICAgICBbUGFnZSAxMl0NCgwNCkludGVy bmV0LURyYWZ0ICAgIE9QRVMgVHJlYXRtZW50IG9mIElBQiBDb25zaWRlcmF0 aW9ucyAgICAgIE9jdG9iZXIgMjAwMw0KDQoNCjYuIENvbnNpZGVyYXRpb24g KDMuMykgJ05vbi1ibG9ja2luZycNCg0KICAgIklmIHRoZXJlIGV4aXN0cyBh ICJub24tT1BFUyIgdmVyc2lvbiBvZiBjb250ZW50IGF2YWlsYWJsZSBmcm9t IHRoZQ0KICAgY29udGVudCBwcm92aWRlciwgdGhlIE9QRVMgYXJjaGl0ZWN0 dXJlIG11c3Qgbm90IHByZXZlbnQgdXNlcnMgZnJvbQ0KICAgcmV0cmlldmlu ZyB0aGlzICJub24tT1BFUyIgdmVyc2lvbiBmcm9tIHRoZSBjb250ZW50DQog ICBwcm92aWRlci4iW1JGQzMyMzhdDQoNCiAgICJPUEVTIGVudGl0aWVzIE1V U1Qgc3VwcG9ydCBhIGJ5cGFzcyBmZWF0dXJlIg0KICAgW0ktRC5pZXRmLW9w ZXMtZW5kLWNvbW1dLiBJZiBhbiBhcHBsaWNhdGlvbiBtZXNzYWdlIGluY2x1 ZGVzIGJ5cGFzcw0KICAgaW5zdHJ1Y3Rpb25zIGFuZCBhbiBPUEVTIGludGVy bWVkaWFyeSBpcyBub3QgY29uZmlndXJlZCB0byBpZ25vcmUNCiAgIHRoZW0s IHRoZSBtYXRjaGluZyBPUEVTIGludGVybWVkaWFyeSB3aWxsIG5vdCBwcm9j ZXNzIHRoZSBtZXNzYWdlLiBBbg0KICAgT1BFUyBpbnRlcm1lZGlhcnkgbWF5 IGJlIGNvbmZpZ3VyZWQgdG8gaWdub3JlIGJ5cGFzcyBpbnN0cnVjdGlvbnMN CiAgIG9ubHkgaWYgbm8gbm9uLU9QRVMgdmVyc2lvbiBvZiBjb250ZW50IGlz IGF2YWlsYWJsZS4gIEJ5cGFzcyBtYXkNCiAgIGdlbmVyYXRlIGNvbnRlbnQg ZXJyb3JzIHNpbmNlIHNvbWUgT1BFUyBzZXJ2aWNlcyBtYXkgYmUgZXNzZW50 aWFsIGJ1dA0KICAgbWF5IG5vdCBiZSBjb25maWd1cmVkIGFzIHN1Y2guDQoN CiAgIEJ5cGFzcyBzdXBwb3J0IGhhcyBsaW1pdGF0aW9ucyBzaW1pbGFyIHRv IHRoZSB0d28NCiAgIG5vdGlmaWNhdGlvbi1yZWxhdGVkIGNvbnNpZGVyYXRp b25zIGFib3ZlLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KQmFyYmlyICYgUm91 c3Nrb3YgICAgICAgIEV4cGlyZXMgQXByaWwgMjYsIDIwMDQgICAgICAgICAg ICAgICAgW1BhZ2UgMTNdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICBPUEVTIFRy ZWF0bWVudCBvZiBJQUIgQ29uc2lkZXJhdGlvbnMgICAgICBPY3RvYmVyIDIw MDMNCg0KDQo3LiBDb25zaWRlcmF0aW9uICg0LjEpICdVUkkgcmVzb2x1dGlv bicNCg0KICAgIk9QRVMgZG9jdW1lbnRhdGlvbiBtdXN0IGJlIGNsZWFyIGlu IGRlc2NyaWJpbmcgdGhlc2Ugc2VydmljZXMgYXMNCiAgIGJlaW5nIGFwcGxp ZWQgdG8gdGhlIHJlc3VsdCBvZiBVUkkgcmVzb2x1dGlvbiwgbm90IGFzIFVS SSByZXNvbHV0aW9uDQogICBpdHNlbGYuIltSRkMzMjM4XQ0KDQogICAiT1BF UyBTY2VuYXJpb3MgYW5kIFVzZSBDYXNlcyIgc3BlY2lmaWNhdGlvbg0KICAg W0ktRC5pZXRmLW9wZXMtc2NlbmFyaW9zXSBkb2N1bWVudHMgY29udGVudCBh ZGFwdGF0aW9ucyB0aGF0IGFyZSBpbg0KICAgc2NvcGUgb2YgdGhlIE9QRVMg ZnJhbWV3b3JrLiBTY2VuYXJpb3MgaW5jbHVkZSBhZGFwdGF0aW9ucyBvZg0K ICAgcmVxdWVzdHMgYW5kIHJlc3BvbnNlcy4gVGhlc2UgYWRhcHRhdGlvbnMg ZG8gbm90IGluY2x1ZGUgVVJJDQogICByZXNvbHV0aW9uIGFkYXB0YXRpb25z LiBJbiBzb21lIGVudmlyb25tZW50cywgaXQgaXMgdGVjaG5pY2FsbHkNCiAg IHBvc3NpYmxlIHRvIGFkYXB0IFVSSXMgKGFuZCBvdGhlciBraW5kcyBvZiBp ZGVudGlmaWVycyBvciBhZGRyZXNzZXMpDQogICB1c2luZyBkb2N1bWVudGVk IE9QRVMgbWVjaGFuaXNtcy4gVGhlIE9QRVMgZnJhbWV3b3JrIGNhbm5vdA0K ICAgZWZmZWN0aXZlbHkgcHJvaGliaXQgYW55IHNwZWNpZmljIGFkYXB0YXRp b25zLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpCYXJiaXIgJiBS b3Vzc2tvdiAgICAgICAgRXhwaXJlcyBBcHJpbCAyNiwgMjAwNCAgICAgICAg ICAgICAgICBbUGFnZSAxNF0NCgwNCkludGVybmV0LURyYWZ0ICAgIE9QRVMg VHJlYXRtZW50IG9mIElBQiBDb25zaWRlcmF0aW9ucyAgICAgIE9jdG9iZXIg MjAwMw0KDQoNCjguIENvbnNpZGVyYXRpb24gKDQuMikgJ1JlZmVyZW5jZSB2 YWxpZGl0eScNCg0KICAgIkFsbCBwcm9wb3NlZCBzZXJ2aWNlcyBtdXN0IGRl ZmluZSB0aGVpciBpbXBhY3Qgb24gaW50ZXItIGFuZA0KICAgaW50cmEtZG9j dW1lbnQgcmVmZXJlbmNlIHZhbGlkaXR5LiJbUkZDMzIzOF0NCg0KICAgVGhl IE9QRVMgZnJhbWV3b3JrIGRvZXMgbm90IHByb3Bvc2UgYWRhcHRhdGlvbiBz ZXJ2aWNlcy4gSG93ZXZlciwNCiAgIE9QRVMgdHJhY2luZyByZXF1aXJlbWVu dHMgaW5jbHVkZSBpZGVudGlmaWNhdGlvbiBvZiBPUEVTDQogICBpbnRlcm1l ZGlhcmllcyBhbmQgc2VydmljZXMgKGZvciBkZXRhaWxzLCBzZWUgIk5vdGlm aWNhdGlvbiINCiAgIGNvbnNpZGVyYXRpb24gc2VjdGlvbnMgaW4gdGhpcyBk b2N1bWVudCkuIEl0IGlzIHJlcXVpcmVkIHRoYXQNCiAgIHByb3ZpZGVkIGlk ZW50aWZpY2F0aW9uIGNhbiBiZSB1c2VkIHRvIGxvY2F0ZSBpbmZvcm1hdGlv biBhYm91dCB0aGUNCiAgIE9QRVMgaW50ZXJtZWRpYXJpZXMsIGluY2x1ZGlu ZyB0aGUgZGVzY3JpcHRpb24gb2YgaW1wYWN0IG9uIHJlZmVyZW5jZQ0KICAg dmFsaWRpdHkgW0ktRC5pZXRmLW9wZXMtZW5kLWNvbW1dIChYWFg6IGNoZWNr IHRyYWNpbmcgZHJhZnQgZm9yIHRoaXMNCiAgIHJlcXVpcmVtZW50KS4NCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpCYXJiaXIgJiBSb3Vzc2tv diAgICAgICAgRXhwaXJlcyBBcHJpbCAyNiwgMjAwNCAgICAgICAgICAgICAg ICBbUGFnZSAxNV0NCgwNCkludGVybmV0LURyYWZ0ICAgIE9QRVMgVHJlYXRt ZW50IG9mIElBQiBDb25zaWRlcmF0aW9ucyAgICAgIE9jdG9iZXIgMjAwMw0K DQoNCjkuIENvbnNpZGVyYXRpb24gKDQuMykgJ0FkZHJlc3NpbmcgZXh0ZW5z aW9ucycNCg0KICAgIkFueSBzZXJ2aWNlcyB0aGF0IGNhbm5vdCBiZSBhY2hp ZXZlZCB3aGlsZSByZXNwZWN0aW5nIHRoZSBhYm92ZSB0d28NCiAgIGNvbnNp ZGVyYXRpb25zIG1heSBiZSByZXZpZXdlZCBhcyBwb3RlbnRpYWwgcmVxdWly ZW1lbnRzIGZvciBJbnRlcm5ldA0KICAgYXBwbGljYXRpb24gYWRkcmVzc2lu ZyBhcmNoaXRlY3R1cmUgZXh0ZW5zaW9ucywgYnV0IG11c3Qgbm90IGJlDQog ICB1bmRlcnRha2VuIGFzIGFkIGhvYyBmaXhlcy4iW1JGQzMyMzhdDQoNCiAg IE9QRVMgZnJhbWV3b3JrIGRvZXMgbm90IGNvbnRhaW4gYWQgaG9jIGZpeGVz LiBUaGlzIGRvY3VtZW50IGluDQogICBjb21iaW5hdGlvbiB3aXRoIGFuZCBv dGhlciBPUEVTIGRvY3VtZW50cyBzaG91bGQgYmUgc3VmZmljaWVudCB0bw0K ICAgaW5mb3JtIHNlcnZpY2UgY3JlYXRvcnMgb2YgSUFCIGNvbnNpZGVyYXRp b25zLiBJZiBhIHNlcnZpY2UgZG9lcyBVUkkNCiAgIHJlc29sdXRpb24gb3Ig c2lsZW50bHkgYWZmZWN0cyBkb2N1bWVudCByZWZlcmVuY2UgdmFsaWRpdHks IHRoZQ0KICAgYXV0aG9ycyBhcmUgcmVxdWVzdGVkIHRvIHJldmlldyBzZXJ2 aWNlIGltcGFjdCBvbiBJbnRlcm5ldA0KICAgYXBwbGljYXRpb24gYWRkcmVz c2luZyBhcmNoaXRlY3R1cmUgYW5kIHdvcmsgd2l0aGluIElFVEYgb24gcG90 ZW50aWFsDQogICBleHRlbnNpb24gcmVxdWlyZW1lbnRzLiBTdWNoIGFjdGlv bnMgd291bGQgYmUgb3V0c2lkZSBvZiB0aGUgY3VycmVudA0KICAgT1BFUyBm cmFtZXdvcmsuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpCYXJiaXIg JiBSb3Vzc2tvdiAgICAgICAgRXhwaXJlcyBBcHJpbCAyNiwgMjAwNCAgICAg ICAgICAgICAgICBbUGFnZSAxNl0NCgwNCkludGVybmV0LURyYWZ0ICAgIE9Q RVMgVHJlYXRtZW50IG9mIElBQiBDb25zaWRlcmF0aW9ucyAgICAgIE9jdG9i ZXIgMjAwMw0KDQoNCjEwLiBDb25zaWRlcmF0aW9uICg1LjEpICdQcml2YWN5 Jw0KDQogICAiVGhlIG92ZXJhbGwgT1BFUyBmcmFtZXdvcmsgbXVzdCBwcm92 aWRlIGZvciBtZWNoYW5pc21zIGZvciBlbmQgdXNlcnMNCiAgIHRvIGRldGVy bWluZSB0aGUgcHJpdmFjeSBwb2xpY2llcyBvZiBPUEVTIGludGVybWVkaWFy aWVzLiJbUkZDMzIzOF0NCg0KICAgT1BFUyB0cmFjaW5nIG1lY2hhbmlzbXMg YWxsb3cgZW5kIHVzZXJzIHRvIGlkZW50aWZ5IE9QRVMNCiAgIGludGVybWVk aWFyaWVzIChmb3IgZGV0YWlscywgc2VlICJOb3RpZmljYXRpb24iIGNvbnNp ZGVyYXRpb24NCiAgIHNlY3Rpb25zIGluIHRoaXMgZG9jdW1lbnQpLiBJdCBp cyByZXF1aXJlZCB0aGF0IHByb3ZpZGVkDQogICBpZGVudGlmaWNhdGlvbiBj YW4gYmUgdXNlZCB0byBsb2NhdGUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIE9Q RVMNCiAgIGludGVybWVkaWFyaWVzLCBpbmNsdWRpbmcgdGhlaXIgcHJpdmFj eSBwb2xpY2llcy4NCg0KICAgVGhlIHRlcm0gInByaXZhY3kgcG9saWN5IiBp cyBub3QgZGVmaW5lZCBpbiB0aGlzIGNvbnRleHQgKGJ5IElBQiBvcg0KICAg T1BFUyB3b3JraW5nIGdyb3VwKS4gT1BFUyB0cmFjaW5nIG1lY2hhbmlzbXMg YWxsb3cgZW5kIHVzZXJzIGFuZA0KICAgY29udGVudCBwcm92aWRlcnMgdG8g aWRlbnRpZnkgYW4gT1BFUyBzeXN0ZW0gYW5kL29yIGludGVybWVkaWFyaWVz Lg0KICAgSXQgaXMgYmVsaWV2ZWQgdGhhdCBvbmNlIGFuIE9QRVMgc3lzdGVt IGlzIGlkZW50aWZpZWQsIGl0IHdvdWxkIGJlDQogICBwb3NzaWJsZSB0byBs b2NhdGUgcmVsZXZhbnQgaW5mb3JtYXRpb24gYWJvdXQgdGhhdCBzeXN0ZW0s IGluY2x1ZGluZw0KICAgaW5mb3JtYXRpb24gcmVsZXZhbnQgdG8gcmVxdWVz dGVycyBwZXJjZXB0aW9uIG9mIHByaXZhY3kgcG9saWN5IG9yDQogICByZWZl cmVuY2UgdmFsaWRpdHkuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpCYXJiaXIg JiBSb3Vzc2tvdiAgICAgICAgRXhwaXJlcyBBcHJpbCAyNiwgMjAwNCAgICAg ICAgICAgICAgICBbUGFnZSAxN10NCgwNCkludGVybmV0LURyYWZ0ICAgIE9Q RVMgVHJlYXRtZW50IG9mIElBQiBDb25zaWRlcmF0aW9ucyAgICAgIE9jdG9i ZXIgMjAwMw0KDQoNCjExLiBDb25zaWRlcmF0aW9uICdFbmNyeXB0aW9uJw0K DQogICAiSWYgT1BFUyBpcyBjaGFydGVyZWQsIHRoZSBPUEVTIHdvcmtpbmcg Z3JvdXAgd2lsbCBhbHNvIGhhdmUgdG8NCiAgIGV4cGxpY2l0bHkgZGVjaWRl IGFuZCBkb2N1bWVudCB3aGV0aGVyIHRoZSBPUEVTIGFyY2hpdGVjdHVyZSBt dXN0IGJlDQogICBjb21wYXRpYmxlIHdpdGggdGhlIHVzZSBvZiBlbmQtdG8t ZW5kIGVuY3J5cHRpb24gYnkgb25lIG9yIG1vcmUgZW5kcw0KICAgb2YgYW4g T1BFUy1pbnZvbHZlZCBzZXNzaW9uLiBJZiBPUEVTIHdhcyBjb21wYXRpYmxl IHdpdGggZW5kLXRvLWVuZA0KICAgZW5jcnlwdGlvbiwgdGhpcyB3b3VsZCBl ZmZlY3RpdmVseSBlbnN1cmUgdGhhdCBPUEVTIGJveGVzIHdvdWxkIGJlDQog ICByZXN0cmljdGVkIHRvIG9uZXMgdGhhdCBhcmUga25vd24sIHRydXN0ZWQs IGV4cGxpY2l0bHkgYWRkcmVzc2VkIGF0DQogICB0aGUgSVAgbGF5ZXIsIGFu ZCBhdXRob3JpemVkIChieSB0aGUgcHJvdmlzaW9uIG9mIGRlY3J5cHRpb24g a2V5cykgYnkNCiAgIGF0IGxlYXN0IG9uZSBvZiB0aGUgZW5kcy4iW1JGQzMy MzhdDQoNCiAgIFRoZSBhYm92ZSBxdW90ZWQgcmVxdWlyZW1lbnQgd2FzIG5v dCBleHBsaWNpdGx5IGxpc3RlZCBhcyBvbiBvZiB0aGUNCiAgIElBQiBjb25z aWRlcmF0aW9ucywgYnV0IHN0aWxsIG5lZWRzIHRvIGJlIGFkZHJlc3NlZC4g VGhlIGNvbnRleHQgb2YNCiAgIHRoZSBxdW90ZSBpbXBsaWVzIHRoYXQgdGhl IHBocmFzZSAiZW5kLXRvLWVuZCBlbmNyeXB0aW9uIiByZWZlcnMgdG8NCiAg IGVuY3J5cHRpb24gYWxvbmcgYWxsIGxpbmtzIG9mIHRoZSBlbmQtdG8tZW5k IHBhdGgsIHdpdGggdGhlIE9QRVMNCiAgIGludGVybWVkaWFyaWVzIGFzIGVu Y3J5cHRpbmcvZGVjcnlwdGluZyBwYXJ0aWNpcGFudHMgb3IgaG9wcyAoZS5n LiwNCiAgIGVuY3J5cHRpb24gYmV0d2VlbiB0aGUgcHJvdmlkZXIgYW5kIHRo ZSBPUEVTIGludGVybWVkaWFyaWVzLCBhbmQNCiAgIGJldHdlZW4gdGhlIE9Q RVMgaW50ZXJtZWRpYXJpZXMgYW5kIHRoZSBjbGllbnQpLg0KDQogICBTaW5j ZSBPUEVTIHByb2Nlc3NvcnMgYXJlIHJlZ3VsYXIgaG9wcyBvbiB0aGUgYXBw bGljYXRpb24gcHJvdG9jb2wNCiAgIHBhdGgsIE9QRVMgYXJjaGl0ZWN0dXJl IGFsbG93cyBmb3Igc3VjaCBlbmNyeXB0aW9uLCBwcm92aWRlZCB0aGUNCiAg IGFwcGxpY2F0aW9uIHByb3RvY29sIGJlaW5nIGFkYXB0ZWQgc3VwcG9ydHMg aXQuIEhvcC1ieS1ob3AgZW5jcnlwdGlvbg0KICAgd291bGQgZG8gbGl0dGxl IGdvb2QgZm9yIHRoZSBvdmVyYWxsIGFwcGxpY2F0aW9uIG1lc3NhZ2UgcGF0 aA0KICAgcHJvdGVjdGlvbiBpZiBjYWxsb3V0IHNlcnZpY2VzIGhhdmUgdG8g cmVjZWl2ZSB1bmVuY3J5cHRlZCBjb250ZW50Lg0KICAgVG8gYWxsb3cgZm9y IGNvbXBsZXRlIGxpbmsgZW5jcnlwdGlvbiBjb3ZlcmFnZSwgT1BFUyBjYWxs b3V0IHByb3RvY29sDQogICAoT0NQKSBzdXBwb3J0cyBlbmNyeXB0aW9uIG9m IE9DUCBjb25uZWN0aW9ucyBiZXR3ZWVuIGFuIE9QRVMNCiAgIHByb2Nlc3Nv ciBhbmQgYSBjYWxsb3V0IHNlcnZlciB2aWEgb3B0aW9uYWwgKG5lZ290aWF0 ZWQpIHRyYW5zcG9ydA0KICAgZW5jcnlwdGlvbiBtZWNoYW5pc21zIFtJLUQu aWV0Zi1vcGVzLW9jcC1jb3JlXS4NCg0KICAgRm9yIGV4YW1wbGUsIFRMUyBl bmNyeXB0aW9uIFtSRkMyODE3XSBjYW4gYmUgdXNlZCBhbW9uZyBIVFRQIGhv cHMNCiAgIChzb21lIG9mIHdoaWNoIGNvdWxkIGJlIE9QRVMgcHJvY2Vzc29y cykgYW5kIGJldHdlZW4gZWFjaCBPUEVTDQogICBwcm9jZXNzb3IgYW5kIGEg Y2FsbG91dCBzZXJ2ZXIuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCkJhcmJpciAmIFJvdXNza292ICAgICAgICBFeHBpcmVzIEFw cmlsIDI2LCAyMDA0ICAgICAgICAgICAgICAgIFtQYWdlIDE4XQ0KDA0KSW50 ZXJuZXQtRHJhZnQgICAgT1BFUyBUcmVhdG1lbnQgb2YgSUFCIENvbnNpZGVy YXRpb25zICAgICAgT2N0b2JlciAyMDAzDQoNCg0KMTIuIFNlY3VyaXR5IENv bnNpZGVyYXRpb25zDQoNCiAgIFRoaXMgZG9jdW1lbnQgZG9lcyBub3QgZGVm aW5lIGFueSBtZWNoYW5pc21zIHRoYXQgbWF5IGJlIHN1YmplY3QgdG8NCiAg IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLiBTZWN1cml0eSBjb25zaWRlcmF0 aW9ucyBmb3IgT1BFUyBtZWNoYW5pc21zDQogICBhcmUgZGlzY3Vzc2VkIGlu IGNvcnJlc3BvbmRpbmcgT1BFUyBmcmFtZXdvcmsgZG9jdW1lbnRzLg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpC YXJiaXIgJiBSb3Vzc2tvdiAgICAgICAgRXhwaXJlcyBBcHJpbCAyNiwgMjAw NCAgICAgICAgICAgICAgICBbUGFnZSAxOV0NCgwNCkludGVybmV0LURyYWZ0 ICAgIE9QRVMgVHJlYXRtZW50IG9mIElBQiBDb25zaWRlcmF0aW9ucyAgICAg IE9jdG9iZXIgMjAwMw0KDQoNCjEzLiBDb21wbGlhbmNlDQoNCiAgIFRoaXMg ZG9jdW1lbnQgbWF5IGJlIHBlcmNlaXZlZCBhcyBhIHByb29mIG9mIE9QRVMg Y29tcGxpYW5jZSB3aXRoIElBQg0KICAgaW1wbGllZCByZWNvbW1lbmRhdGlv bnMuIEhvd2V2ZXIsIHRoaXMgZG9jdW1lbnQgZG9lcyBub3QgaW50cm9kdWNl DQogICBhbnkgY29tcGxpYW5jZSBzdWJqZWN0cy4gQ29tcGxpYW5jZSBvZiBP UEVTIGltcGxlbWVudGF0aW9ucyBpcw0KICAgZGVmaW5lZCBpbiBvdGhlciBP UEVTIGRvY3VtZW50cyBkaXNjdXNzZWQgYWJvdmUuDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpCYXJiaXIgJiBSb3Vz c2tvdiAgICAgICAgRXhwaXJlcyBBcHJpbCAyNiwgMjAwNCAgICAgICAgICAg ICAgICBbUGFnZSAyMF0NCgwNCkludGVybmV0LURyYWZ0ICAgIE9QRVMgVHJl YXRtZW50IG9mIElBQiBDb25zaWRlcmF0aW9ucyAgICAgIE9jdG9iZXIgMjAw Mw0KDQoNCkFwcGVuZGl4IEEuIENoYW5nZSBMb2cNCg0KICAgSW50ZXJuYWwg V0cgcmV2aXNpb24gY29udHJvbCBJRDogJElkOiBpYWItY29ucy54bWwsdiAx LjI2IDIwMDMvMTAvMjcNCiAgIDExOjQwOjMzIHJvdXNza292IEV4cCAkDQoN CiAgIDIwMDMvMTAvMjQNCg0KICAgICAgKiAgQWRkcmVzc2VkIGhvcC1ieS1o b3AgZW5jcnlwdGlvbiBjb25jZXJucyBtZW50aW9uZWQgaW4gdGhlIElBQg0K ICAgICAgICAgZHJhZnQuDQoNCiAgICAgICogIFBvbGlzaGVkIElQIGFkZHJl c3NpbmcgZmlndXJlLg0KDQogICAgICAqICBSZW1vdmVkIHJlc29sdmVkIFhY WHMuDQoNCiAgIDIwMDMvMTAvMDENCg0KICAgICAgKiAgUG9saXNoaW5nIChB YmJpZSBCYXJiaXIpLg0KDQogICAyMDAzLzA5LzIzDQoNCiAgICAgICogIEFk ZGVkIGEgcmVmZXJlbmNlIHRvIE9wdGlvbmFsIE5vdGlmaWNhdGlvbiBzZWN0 aW9uIG9mIHRoZQ0KICAgICAgICAgaWV0Zi1vcGVzLWVuZC1jb21tIGRyYWZ0 Lg0KDQogICAgICAqICBGaXhlZCAiQ29uc2lkZXJhdGlvbiAoMy4zKSBOb24t YmxvY2tpbmciIHNlY3Rpb24gcG9zaXRpb24uDQoNCiAgIGhlYWQtc2lkMTUN Cg0KICAgICAgKiAgQWRkZWQgYSBmaWd1cmUgc2hvd2luZyBhIGNoYWluIG9m IGludGVybmFsIE9QRVMgaW50ZXJtZWRpYXJpZXMNCiAgICAgICAgIGJlaGlu ZCBhIHB1YmxpYyBJUCBhZGRyZXNzLiBOZWVkcyBtb3JlIHdvcmsuIE1vcmUg Y2FzZXM/DQoNCiAgIGhlYWQtc2lkMTQNCg0KICAgICAgKiAgUmV3cm90ZSB0 aGUgSW50cm9kdWN0aW9uIHRvIHRoZSBJUCBhZGRyZXNzaW5nIGNvbnNpZGVy YXRpb24uDQogICAgICAgICBEbyBOT1QgZXhwbGFpbiBob3cgSUFCIGNvbnNp ZGVyYXRpb25zLCBpZiBpbnRlcnByZXRlZCBsaXRlcmFyeSwNCiAgICAgICAg IGRvIG5vdCBzYXRpc2Z5IGltcG9ydGFudCByZWFsLXdvcmxkIGNvbnN0cmFp bnRzLiBJbnN0ZWFkLCB1c2UNCiAgICAgICAgIHRoZSAiY2hhaW4gb2YgT1BF UyBpbnRlcm1lZGlhcmllcyIgZXhjZXB0aW9uIGludHJvZHVjZWQgYnkgSUFC DQogICAgICAgICBpdHNlbGYgdG8gc2hvdyB0aGF0IE9QRVMgYXJjaGl0ZWN0 dXJlIGFkZHJlc3NlcyBJQUIgY29uY2VybnMgYXMNCiAgICAgICAgIGxvbmcg YXMgdGhlICJjaGFpbiIgaXMgZGVmaW5lZC9mb3JtZWQgZm9yIGEgZ2l2ZW4g YXBwbGljYXRpb24NCiAgICAgICAgIG1lc3NhZ2UgcmF0aGVyIHRoYW4gYmVp bmcgYSBzdGF0aWNhbGx5IGNvbmZpZ3VyZWQgYXBwbGljYXRpb24NCiAgICAg ICAgIHJvdXRpbmcgdGFibGUgb2Ygc29ydHMuIElBQiBoYWQgdG8gYWRkIHRo ZSAiY2hhaW4iIGV4Y2VwdGlvbiB0bw0KICAgICAgICAgY292ZXIgb25lIG9m IHRoZSBtb3N0IG9idmlvdXMgcmVhbC13b3JsZCB1c2FnZSBzY2VuYXJpby4g V2UgdXNlDQogICAgICAgICB0aGUgdmVyeSBzYW1lIGV4Y2VwdGlvbiB0byBj b3ZlciBhbGwgdXNhZ2Ugc2NlbmFyaW9zIHdlIGNhcmUNCiAgICAgICAgIGFi b3V0Lg0KDQogICAgICAqICBQb2xpc2hlZCB0ZXh0IGV4cGxhaW5pbmcgdGhl IGRpZmZlcmVuY2VzIGJldHdlZW4gdHJhY2luZyBhbmQNCiAgICAgICAgIG5v dGlmaWNhdGlvbiBtZWNoYW5pc21zLg0KDQogICAgICAqICBBZGRlZCBleGFt cGxlcyBvZiBPUEVTL0hUVFAgdHJhY2VzLg0KDQoNCg0KQmFyYmlyICYgUm91 c3Nrb3YgICAgICAgIEV4cGlyZXMgQXByaWwgMjYsIDIwMDQgICAgICAgICAg ICAgICAgW1BhZ2UgMjFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICBPUEVTIFRy ZWF0bWVudCBvZiBJQUIgQ29uc2lkZXJhdGlvbnMgICAgICBPY3RvYmVyIDIw MDMNCg0KDQogICAgICAqICBCZSBjYXJlZnVsIG5vdCB0byBpbXBseSB0aGF0 IGFsbCBPUEVTIGludGVybWVkaWFyaWVzIG11c3Qgb2JleQ0KICAgICAgICAg YnlwYXNzIGluc3RydWN0aW9ucy4gQnlwYXNzIHNob3VsZCBiZSBpZ25vcmVk IHdoZW4gbm8gbm9uLU9QRVMNCiAgICAgICAgIHZlcnNpb24gb2YgdGhlIGNv bnRlbnQgZXhpc3RzLiBJZGVhbGx5LCB0aGlzIG1heSBuZWVkIHRvIGJlDQog ICAgICAgICBwb2xpc2hlZCBmdXJ0aGVyIC0tIGlmIHRoZXJlIGlzIG5vIG5v bi1PUEVTIHZlcnNpb24gb2YgdGhlDQogICAgICAgICBjb250ZW50LCBtb3N0 IElBQiBjb25zaWRlcmF0aW9ucyBwcm9iYWJseSBkbyBub3QgYXBwbHkgYmVj YXVzZQ0KICAgICAgICAgdGhlcmUgaXMgcmVhbGx5IG5vIGFkYXB0YXRpb24s IG9ubHkgY3JlYXRpb24gb2YgY29udGVudCAoYW5kIHdlDQogICAgICAgICBz aG91bGQgbm90IHJlc3RyaWN0IGNvbnRlbnQgY3JlYXRpb24pLg0KDQogICAg ICAqICBBZGRlZCByZWZlcmVuY2VzIHRvIE9QRVMgIkNvbW11bmljYXRpb25z IiBkcmFmdA0KICAgICAgICAgW0ktRC5pZXRmLW9wZXMtZW5kLWNvbW1dLg0K DQogICBoZWFkLXNpZDkNCg0KICAgICAgKiAgUG9saXNoZWQgdG8gbWVldCBu ZXcgeG1sMnJmYyBzdHJpY3QgcmVxdWlyZW1lbnRzLg0KDQogICBoZWFkLXNp ZDgNCg0KICAgICAgKiAgQWRkZWQgdW5wb2xpc2hlZCBtZWF0IGZvciBhbGwg bmluZSBjb25zaWRlcmF0aW9ucy4NCg0KICAgICAgKiAgQWRkZWQgQWJiaWUg QmFyYmlyIGFzIGFuIGF1dGhvci4NCg0KICAgaGVhZC1zaWQ3DQoNCiAgICAg ICogIEluaXRpYWwgcmV2aXNpb24NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkJhcmJpciAmIFJvdXNz a292ICAgICAgICBFeHBpcmVzIEFwcmlsIDI2LCAyMDA0ICAgICAgICAgICAg ICAgIFtQYWdlIDIyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgT1BFUyBUcmVh dG1lbnQgb2YgSUFCIENvbnNpZGVyYXRpb25zICAgICAgT2N0b2JlciAyMDAz DQoNCg0KTm9ybWF0aXZlIFJlZmVyZW5jZXMNCg0KICAgW0ktRC5pZXRmLW9w ZXMtZW5kLWNvbW1dDQogICAgICAgICAgICAgIEJhcmJpciwgQS4sICJPUEVT IHByb2Nlc3NvciBhbmQgZW5kIHBvaW50cw0KICAgICAgICAgICAgICBjb21t dW5pY2F0aW9ucyIsIGRyYWZ0LWlldGYtb3Blcy1lbmQtY29tbS0wNCAod29y ayBpbg0KICAgICAgICAgICAgICBwcm9ncmVzcyksIE9jdG9iZXIgMjAwMy4N Cg0KICAgW0ktRC5pZXRmLW9wZXMtYXJjaGl0ZWN0dXJlXQ0KICAgICAgICAg ICAgICBCYXJiaXIsIEEuLCAiQW4gQXJjaGl0ZWN0dXJlIGZvciBPcGVuIFBs dWdnYWJsZSBFZGdlDQogICAgICAgICAgICAgIFNlcnZpY2VzIChPUEVTKSIs IGRyYWZ0LWlldGYtb3Blcy1hcmNoaXRlY3R1cmUtMDQgKHdvcmsgaW4NCiAg ICAgICAgICAgICAgcHJvZ3Jlc3MpLCBEZWNlbWJlciAyMDAyLg0KDQogICBb SS1ELmlldGYtb3Blcy1zY2VuYXJpb3NdDQogICAgICAgICAgICAgIEJhcmJp ciwgQS4sICJPUEVTIFVzZSBDYXNlcyBhbmQgRGVwbG95bWVudCBTY2VuYXJp b3MiLA0KICAgICAgICAgICAgICBkcmFmdC1pZXRmLW9wZXMtc2NlbmFyaW9z LTAxICh3b3JrIGluIHByb2dyZXNzKSwgQXVndXN0DQogICAgICAgICAgICAg IDIwMDIuDQoNCiAgIFtSRkMzMjM4XSAgRmxveWQsIFMuIGFuZCBMLiBEYWln bGUsICJJQUIgQXJjaGl0ZWN0dXJhbCBhbmQgUG9saWN5DQogICAgICAgICAg ICAgIENvbnNpZGVyYXRpb25zIGZvciBPcGVuIFBsdWdnYWJsZSBFZGdlIFNl cnZpY2VzIiwgUkZDDQogICAgICAgICAgICAgIDMyMzgsIEphbnVhcnkgMjAw Mi4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KQmFyYmlyICYgUm91c3Nrb3YgICAgICAg IEV4cGlyZXMgQXByaWwgMjYsIDIwMDQgICAgICAgICAgICAgICAgW1BhZ2Ug MjNdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICBPUEVTIFRyZWF0bWVudCBvZiBJ QUIgQ29uc2lkZXJhdGlvbnMgICAgICBPY3RvYmVyIDIwMDMNCg0KDQpJbmZv cm1hdGl2ZSBSZWZlcmVuY2VzDQoNCiAgIFtSRkMyMjI3XSAgTW9ndWwsIEou IGFuZCBQLiBMZWFjaCwgIlNpbXBsZSBIaXQtTWV0ZXJpbmcgYW5kDQogICAg ICAgICAgICAgIFVzYWdlLUxpbWl0aW5nIGZvciBIVFRQIiwgUkZDIDIyMjcs IE9jdG9iZXIgMTk5Ny4NCg0KICAgW1JGQzI2MTZdICBGaWVsZGluZywgUi4s IEdldHR5cywgSi4sIE1vZ3VsLCBKLiwgTmllbHNlbiwgSC4sDQogICAgICAg ICAgICAgIE1hc2ludGVyLCBMLiwgTGVhY2gsIFAuIGFuZCBULiBCZXJuZXJz LUxlZSwgIkh5cGVydGV4dA0KICAgICAgICAgICAgICBUcmFuc2ZlciBQcm90 b2NvbCAtLSBIVFRQLzEuMSIsIFJGQyAyNjE2LCBKdW5lIDE5OTkuDQoNCiAg IFtSRkMyODE3XSAgS2hhcmUsIFIuIGFuZCBTLiBMYXdyZW5jZSwgIlVwZ3Jh ZGluZyB0byBUTFMgV2l0aGluIEhUVFAvDQogICAgICAgICAgICAgIDEuMSIs IFJGQyAyODE3LCBNYXkgMjAwMC4NCg0KICAgW0ktRC5pZXRmLW9wZXMtaHR0 cF0NCiAgICAgICAgICAgICAgUm91c3Nrb3YsIEEuIGFuZCBNLiBTdGVjaGVy LCAiSFRUUCBhZGFwdGF0aW9uIHdpdGggT1BFUyIsDQogICAgICAgICAgICAg IGRyYWZ0LWlldGYtb3Blcy1odHRwLTAwICh3b3JrIGluIHByb2dyZXNzKSwg QXVndXN0IDIwMDMuDQoNCiAgIFtJLUQuaWV0Zi1vcGVzLW9jcC1jb3JlXQ0K ICAgICAgICAgICAgICBSb3Vzc2tvdiwgQS4sICJPUEVTIENhbGxvdXQgUHJv dG9jb2wgQ29yZSIsDQogICAgICAgICAgICAgIGRyYWZ0LWlldGYtb3Blcy1v Y3AtY29yZS0wMSAod29yayBpbiBwcm9ncmVzcyksIEF1Z3VzdA0KICAgICAg ICAgICAgICAyMDAzLg0KDQoNCkF1dGhvcnMnIEFkZHJlc3Nlcw0KDQogICBB YmJpZSBCYXJiaXINCiAgIE5vcnRlbCBOZXR3b3Jrcw0KICAgMzUwMCBDYXJs aW5nIEF2ZW51ZQ0KICAgTmVwZWFuLCBPbnRhcmlvDQogICBDQQ0KDQogICBQ aG9uZTogKzEgNjEzIDc2MyA1MjI5DQogICBFTWFpbDogYWJiaWViQG5vcnRl bG5ldHdvcmtzLmNvbQ0KDQoNCiAgIEFsZXggUm91c3Nrb3YNCiAgIFRoZSBN ZWFzdXJlbWVudCBGYWN0b3J5DQoNCiAgIEVNYWlsOiByb3Vzc2tvdkBtZWFz dXJlbWVudC1mYWN0b3J5LmNvbQ0KICAgVVJJOiAgIGh0dHA6Ly93d3cubWVh c3VyZW1lbnQtZmFjdG9yeS5jb20vDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQpCYXJiaXIgJiBSb3Vzc2tvdiAgICAgICAgRXhwaXJlcyBBcHJpbCAyNiwg MjAwNCAgICAgICAgICAgICAgICBbUGFnZSAyNF0NCgwNCkludGVybmV0LURy YWZ0ICAgIE9QRVMgVHJlYXRtZW50IG9mIElBQiBDb25zaWRlcmF0aW9ucyAg ICAgIE9jdG9iZXIgMjAwMw0KDQoNCkludGVsbGVjdHVhbCBQcm9wZXJ0eSBT dGF0ZW1lbnQNCg0KICAgVGhlIElFVEYgdGFrZXMgbm8gcG9zaXRpb24gcmVn YXJkaW5nIHRoZSB2YWxpZGl0eSBvciBzY29wZSBvZiBhbnkNCiAgIGludGVs bGVjdHVhbCBwcm9wZXJ0eSBvciBvdGhlciByaWdodHMgdGhhdCBtaWdodCBi ZSBjbGFpbWVkIHRvDQogICBwZXJ0YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlv biBvciB1c2Ugb2YgdGhlIHRlY2hub2xvZ3kgZGVzY3JpYmVkIGluDQogICB0 aGlzIGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vu c2UgdW5kZXIgc3VjaCByaWdodHMNCiAgIG1pZ2h0IG9yIG1pZ2h0IG5vdCBi ZSBhdmFpbGFibGU7IG5laXRoZXIgZG9lcyBpdCByZXByZXNlbnQgdGhhdCBp dA0KICAgaGFzIG1hZGUgYW55IGVmZm9ydCB0byBpZGVudGlmeSBhbnkgc3Vj aCByaWdodHMuIEluZm9ybWF0aW9uIG9uIHRoZQ0KICAgSUVURidzIHByb2Nl ZHVyZXMgd2l0aCByZXNwZWN0IHRvIHJpZ2h0cyBpbiBzdGFuZGFyZHMtdHJh Y2sgYW5kDQogICBzdGFuZGFyZHMtcmVsYXRlZCBkb2N1bWVudGF0aW9uIGNh biBiZSBmb3VuZCBpbiBCQ1AtMTEuIENvcGllcyBvZg0KICAgY2xhaW1zIG9m IHJpZ2h0cyBtYWRlIGF2YWlsYWJsZSBmb3IgcHVibGljYXRpb24gYW5kIGFu eSBhc3N1cmFuY2VzIG9mDQogICBsaWNlbnNlcyB0byBiZSBtYWRlIGF2YWls YWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBhbiBhdHRlbXB0IG1hZGUgdG8NCiAg IG9idGFpbiBhIGdlbmVyYWwgbGljZW5zZSBvciBwZXJtaXNzaW9uIGZvciB0 aGUgdXNlIG9mIHN1Y2gNCiAgIHByb3ByaWV0YXJ5IHJpZ2h0cyBieSBpbXBs ZW1lbnRvcnMgb3IgdXNlcnMgb2YgdGhpcyBzcGVjaWZpY2F0aW9uIGNhbg0K ICAgYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBTZWNyZXRhcmlhdC4NCg0K ICAgVGhlIElFVEYgaW52aXRlcyBhbnkgaW50ZXJlc3RlZCBwYXJ0eSB0byBi cmluZyB0byBpdHMgYXR0ZW50aW9uIGFueQ0KICAgY29weXJpZ2h0cywgcGF0 ZW50cyBvciBwYXRlbnQgYXBwbGljYXRpb25zLCBvciBvdGhlciBwcm9wcmll dGFyeQ0KICAgcmlnaHRzIHdoaWNoIG1heSBjb3ZlciB0ZWNobm9sb2d5IHRo YXQgbWF5IGJlIHJlcXVpcmVkIHRvIHByYWN0aWNlDQogICB0aGlzIHN0YW5k YXJkLiBQbGVhc2UgYWRkcmVzcyB0aGUgaW5mb3JtYXRpb24gdG8gdGhlIElF VEYgRXhlY3V0aXZlDQogICBEaXJlY3Rvci4NCg0KDQpGdWxsIENvcHlyaWdo dCBTdGF0ZW1lbnQNCg0KICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQg U29jaWV0eSAoMjAwMykuIEFsbCBSaWdodHMgUmVzZXJ2ZWQuDQoNCiAgIFRo aXMgZG9jdW1lbnQgYW5kIHRyYW5zbGF0aW9ucyBvZiBpdCBtYXkgYmUgY29w aWVkIGFuZCBmdXJuaXNoZWQgdG8NCiAgIG90aGVycywgYW5kIGRlcml2YXRp dmUgd29ya3MgdGhhdCBjb21tZW50IG9uIG9yIG90aGVyd2lzZSBleHBsYWlu IGl0DQogICBvciBhc3Npc3QgaW4gaXRzIGltcGxlbWVudGF0aW9uIG1heSBi ZSBwcmVwYXJlZCwgY29waWVkLCBwdWJsaXNoZWQNCiAgIGFuZCBkaXN0cmli dXRlZCwgaW4gd2hvbGUgb3IgaW4gcGFydCwgd2l0aG91dCByZXN0cmljdGlv biBvZiBhbnkNCiAgIGtpbmQsIHByb3ZpZGVkIHRoYXQgdGhlIGFib3ZlIGNv cHlyaWdodCBub3RpY2UgYW5kIHRoaXMgcGFyYWdyYXBoIGFyZQ0KICAgaW5j bHVkZWQgb24gYWxsIHN1Y2ggY29waWVzIGFuZCBkZXJpdmF0aXZlIHdvcmtz LiBIb3dldmVyLCB0aGlzDQogICBkb2N1bWVudCBpdHNlbGYgbWF5IG5vdCBi ZSBtb2RpZmllZCBpbiBhbnkgd2F5LCBzdWNoIGFzIGJ5IHJlbW92aW5nDQog ICB0aGUgY29weXJpZ2h0IG5vdGljZSBvciByZWZlcmVuY2VzIHRvIHRoZSBJ bnRlcm5ldCBTb2NpZXR5IG9yIG90aGVyDQogICBJbnRlcm5ldCBvcmdhbml6 YXRpb25zLCBleGNlcHQgYXMgbmVlZGVkIGZvciB0aGUgcHVycG9zZSBvZg0K ICAgZGV2ZWxvcGluZyBJbnRlcm5ldCBzdGFuZGFyZHMgaW4gd2hpY2ggY2Fz ZSB0aGUgcHJvY2VkdXJlcyBmb3INCiAgIGNvcHlyaWdodHMgZGVmaW5lZCBp biB0aGUgSW50ZXJuZXQgU3RhbmRhcmRzIHByb2Nlc3MgbXVzdCBiZQ0KICAg Zm9sbG93ZWQsIG9yIGFzIHJlcXVpcmVkIHRvIHRyYW5zbGF0ZSBpdCBpbnRv IGxhbmd1YWdlcyBvdGhlciB0aGFuDQogICBFbmdsaXNoLg0KDQogICBUaGUg bGltaXRlZCBwZXJtaXNzaW9ucyBncmFudGVkIGFib3ZlIGFyZSBwZXJwZXR1 YWwgYW5kIHdpbGwgbm90IGJlDQogICByZXZva2VkIGJ5IHRoZSBJbnRlcm5l dCBTb2NpZXR5IG9yIGl0cyBzdWNjZXNzb3JzIG9yIGFzc2lnbmVlcy4NCg0K ICAgVGhpcyBkb2N1bWVudCBhbmQgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l ZCBoZXJlaW4gaXMgcHJvdmlkZWQgb24gYW4NCiAgICJBUyBJUyIgYmFzaXMg YW5kIFRIRSBJTlRFUk5FVCBTT0NJRVRZIEFORCBUSEUgSU5URVJORVQgRU5H SU5FRVJJTkcNCiAgIFRBU0sgRk9SQ0UgRElTQ0xBSU1TIEFMTCBXQVJSQU5U SUVTLCBFWFBSRVNTIE9SIElNUExJRUQsIElOQ0xVRElORw0KICAgQlVUIE5P VCBMSU1JVEVEIFRPIEFOWSBXQVJSQU5UWSBUSEFUIFRIRSBVU0UgT0YgVEhF IElORk9STUFUSU9ODQoNCg0KDQpCYXJiaXIgJiBSb3Vzc2tvdiAgICAgICAg RXhwaXJlcyBBcHJpbCAyNiwgMjAwNCAgICAgICAgICAgICAgICBbUGFnZSAy NV0NCgwNCkludGVybmV0LURyYWZ0ICAgIE9QRVMgVHJlYXRtZW50IG9mIElB QiBDb25zaWRlcmF0aW9ucyAgICAgIE9jdG9iZXIgMjAwMw0KDQoNCiAgIEhF UkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBBTlkgUklHSFRTIE9SIEFOWSBJTVBM SUVEIFdBUlJBTlRJRVMgT0YNCiAgIE1FUkNIQU5UQUJJTElUWSBPUiBGSVRO RVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4NCg0KDQpBY2tub3dsZWRn bWVudA0KDQogICBGdW5kaW5nIGZvciB0aGUgUkZDIEVkaXRvciBmdW5jdGlv biBpcyBjdXJyZW50bHkgcHJvdmlkZWQgYnkgdGhlDQogICBJbnRlcm5ldCBT b2NpZXR5Lg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQpCYXJiaXIgJiBSb3Vzc2tvdiAgICAgICAgRXhwaXJlcyBBcHJpbCAy NiwgMjAwNCAgICAgICAgICAgICAgICBbUGFnZSAyNl0NCgwNCg== --0-303409057-1067255122=:32906-- From owner-ietf-openproxy@mail.imc.org Mon Oct 27 07:30:36 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09507 for ; Mon, 27 Oct 2003 07:30:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE6WE-000489-00 for opes-archive@ietf.org; Mon, 27 Oct 2003 07:30:46 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AE6WC-000485-00 for opes-archive@ietf.org; Mon, 27 Oct 2003 07:30:44 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RCHoI7046568 for ; Mon, 27 Oct 2003 04:17: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 h9RCHooY046567 for ietf-openproxy-bks; Mon, 27 Oct 2003 04:17: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 h9RCHmI7046561 for ; Mon, 27 Oct 2003 04:17: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 h9RCHjGh054185; Mon, 27 Oct 2003 05:17:45 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9RCHjE7054184; Mon, 27 Oct 2003 05:17:45 -0700 (MST) (envelope-from rousskov) Date: Mon, 27 Oct 2003 05:17:45 -0700 (MST) From: Alex Rousskov To: internet-drafts@ietf.org cc: OPES WG , abeck@bell-labs.com Subject: Request to Publish: draft-ietf-opes-rules-p-02 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-351245835-1067257041=:53872" Content-ID: Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-351245835-1067257041=:53872 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Please publish the attached draft-ietf-opes-rules-p-02.txt as an OPES working group draft. Thank you, Alex. --0-351245835-1067257041=:53872 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="draft-ietf-opes-rules-p-02.txt" Content-ID: Content-Description: draft-ietf-opes-rules-p-02.txt Content-Disposition: ATTACHMENT; FILENAME="draft-ietf-opes-rules-p-02.txt" Content-Transfer-Encoding: BASE64 DQoNCk9wZW4gUGx1Z2dhYmxlIEVkZ2UgU2VydmljZXMgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgQS4gQmVjaw0KSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBMdWNl bnQgVGVjaG5vbG9naWVzDQpFeHBpcmVzOiBBcHJpbCAyNiwgMjAwNCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQS4gUm91c3Nrb3YN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBUaGUgTWVhc3VyZW1lbnQgRmFjdG9yeQ0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBPY3Rv YmVyIDI3LCAyMDAzDQoNCg0KICAgICAgICAgICAgICAgICAgICAgUDogTWVz c2FnZSBQcm9jZXNzaW5nIExhbmd1YWdlDQogICAgICAgICAgICAgICAgICAg ICAgIGRyYWZ0LWlldGYtb3Blcy1ydWxlcy1wLTAyDQoNClN0YXR1cyBvZiB0 aGlzIE1lbW8NCg0KICAgVGhpcyBkb2N1bWVudCBpcyBhbiBJbnRlcm5ldC1E cmFmdCBhbmQgaXMgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoDQogICBhbGwg cHJvdmlzaW9ucyBvZiBTZWN0aW9uIDEwIG9mIFJGQzIwMjYuDQoNCiAgIElu dGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIElu dGVybmV0IEVuZ2luZWVyaW5nDQogICBUYXNrIEZvcmNlIChJRVRGKSwgaXRz IGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiBOb3RlIHRoYXQgb3Ro ZXINCiAgIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgZG9j dW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4NCg0KICAgSW50ZXJuZXQtRHJh ZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBv ZiBzaXggbW9udGhzDQogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2Vk LCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQ0KICAg dGltZS4gSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJh ZnRzIGFzIHJlZmVyZW5jZQ0KICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVt IG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQogICBUaGUg bGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNz ZWQgYXQgaHR0cDovLw0KICAgd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3Ry YWN0cy50eHQuDQoNCiAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNo YWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6 Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuDQoNCiAgIFRoaXMgSW50ZXJu ZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gQXByaWwgMjYsIDIwMDQuDQoNCkNv cHlyaWdodCBOb3RpY2UNCg0KICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJu ZXQgU29jaWV0eSAoMjAwMykuIEFsbCBSaWdodHMgUmVzZXJ2ZWQuDQoNCkFi c3RyYWN0DQoNCiAgIFAgaXMgYSBzaW1wbGUgY29uZmlndXJhdGlvbiBsYW5n dWFnZSBkZXNpZ25lZCBmb3Igc3BlY2lmaWNhdGlvbiBvZg0KICAgbWVzc2Fn ZSBwcm9jZXNzaW5nIGluc3RydWN0aW9ucyBhdCBhcHBsaWNhdGlvbiBwcm94 aWVzLiBQIGNhbiBiZSB1c2VkDQogICB0byBpbnN0cnVjdCBhbiBpbnRlcm1l ZGlhcnkgaG93IHRvIG1hbmlwdWxhdGUgdGhlIGFwcGxpY2F0aW9uIG1lc3Nh Z2UNCiAgIGJlaW5nIHByb3hpZWQuIFN1Y2ggaW5zdHJ1Y3Rpb25zIGFyZSBu ZWVkZWQgaW4gYW4gT3BlbiBQbHVnZ2FibGUgRWRnZQ0KICAgU2VydmljZXMg KE9QRVMpIGNvbnRleHQuDQoNCg0KDQoNCg0KDQoNCg0KDQpCZWNrICYgUm91 c3Nrb3YgICAgICAgICAgRXhwaXJlcyBBcHJpbCAyNiwgMjAwNCAgICAgICAg ICAgICAgICAgW1BhZ2UgMV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgIFA6 IE1lc3NhZ2UgUHJvY2Vzc2luZyBMYW5ndWFnZSAgICAgICAgIE9jdG9iZXIg MjAwMw0KDQoNClRhYmxlIG9mIENvbnRlbnRzDQoNCiAgIDEuICBJbnRyb2R1 Y3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgMw0KICAgMi4gIFN5bnRheCAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1DQog ICAzLiAgTGFuZ3VhZ2UgZWxlbWVudHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcNCiAgIDMuMSBPYmplY3RzICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgNw0KICAgMy4yIFR5cGUgY29udmVyc2lvbiAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA4DQogICAz LjMgT3BlcmF0b3JzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDgNCiAgIDMuNCBFeHByZXNzaW9ucyAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAxMQ0KICAgMy41IFN0YXRlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExDQogICAzLjYg QXNzaWdubWVudHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gMTINCiAgIDQuICBNb2R1bGVzICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAxNA0KICAgNC4xIEludGVycHJldGVyLW1vZHVsZSBpbnRlcmZhY2UgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE1DQogICA0LjIgTW9k dWxlcyBhbmQgbmFtZXNwYWNlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gMTUNCiAgIDUuICBPUEVTIFNlcnZpY2VzICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAx Nw0KICAgNi4gIEZhaWx1cmVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE4DQogICA3LiAgU2VjdXJp dHkgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMjANCiAgIDguICBDb21wbGlhbmNlIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyMQ0K ICAgQS4gIEV4YW1wbGVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIyDQogICBCLiAgVG8tZG8gIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gMjMNCiAgIEMuICBBY2tub3dsZWRnbWVudHMgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyNQ0KICAg RC4gIENoYW5nZSBMb2cgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI2DQogICAgICAgTm9ybWF0aXZlIFJl ZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMjgNCiAgICAgICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyOQ0KICAgICAg IEF1dGhvcnMnIEFkZHJlc3NlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDI5DQogICAgICAgSW50ZWxsZWN0dWFsIFBy b3BlcnR5IGFuZCBDb3B5cmlnaHQgU3RhdGVtZW50cyAuIC4gLiAuIC4gLiAu IC4gMzANCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KQmVjayAmIFJvdXNza292ICAgICAgICAgIEV4cGlyZXMg QXByaWwgMjYsIDIwMDQgICAgICAgICAgICAgICAgIFtQYWdlIDJdDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgICBQOiBNZXNzYWdlIFByb2Nlc3NpbmcgTGFu Z3VhZ2UgICAgICAgICBPY3RvYmVyIDIwMDMNCg0KDQoxLiBJbnRyb2R1Y3Rp b24NCg0KICAgVGhlIE9wZW4gUGx1Z2dhYmxlIEVkZ2UgU2VydmljZXMgKE9Q RVMpIGFyY2hpdGVjdHVyZQ0KICAgW0ktRC5pZXRmLW9wZXMtYXJjaGl0ZWN0 dXJlXSwgZW5hYmxlcyBjb29wZXJhdGl2ZSBhcHBsaWNhdGlvbg0KICAgc2Vy dmljZXMgKE9QRVMgc2VydmljZXMpIGJldHdlZW4gYSBkYXRhIHByb3ZpZGVy LCBhIGRhdGEgY29uc3VtZXIsDQogICBhbmQgemVybyBvciBtb3JlIE9QRVMg cHJvY2Vzc29ycy4gIFRoZSBhcHBsaWNhdGlvbiBzZXJ2aWNlcyB1bmRlcg0K ICAgY29uc2lkZXJhdGlvbiBhbmFseXplIGFuZCBwb3NzaWJseSB0cmFuc2Zv cm0gYXBwbGljYXRpb24tbGV2ZWwNCiAgIG1lc3NhZ2VzIGV4Y2hhbmdlZCBi ZXR3ZWVuIHRoZSBkYXRhIHByb3ZpZGVyIGFuZCB0aGUgZGF0YSBjb25zdW1l ci4NCiAgIE9QRVMgcHJvY2Vzc29ycyBuZWVkIHRvIGJlIHRvbGQgd2hhdCBz ZXJ2aWNlcyBhcmUgdG8gYmUgYXBwbGllZCB0bw0KICAgd2hhdCBhcHBsaWNh dGlvbiBtZXNzYWdlcy4gUCBsYW5ndWFnZSBjYW4gYmUgdXNlZCBmb3IgdGhp cw0KICAgY29uZmlndXJhdGlvbiB0YXNrLg0KDQogICBJbiBvdGhlciB3b3Jk cywgUCBsYW5ndWFnZSBwcmltYXJ5IG9iamVjdGl2ZSBpcyB0byBleHByZXNz IHN0YXRlbWVudHMNCiAgIHNpbWlsYXIgdG86DQoNCiAgIAkJaWYgbWVzc2Fn ZSBtZWV0cyBjcml0ZXJpYSBDLA0KICAgCQl0aGVuIGFwcGx5IHNlcnZpY2Ug UzsNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUg MQ0KDQogICBUaHVzLCBQIHByb2dyYW1zIG1vc3RseSBkZWFsIHdpdGggZm9y bXVsYXRpbmcgbWVzc2FnZS1kZXBlbmRlbnQNCiAgIGNvbmRpdGlvbnMgYW5k IGV4ZWN1dGluZyBzZXJ2aWNlcy4NCg0KICAgUCBkZXNpZ24gYXR0ZW1wdHMg dG8gc2F0aXNmeSBzZXZlcmFsIGNvbmZsaWN0aW5nIGdvYWxzOg0KDQogICBm bGV4aWJpbGl0eTogQXBwbGljYXRpb24gaW50ZXJtZWRpYXJpZXMgZGVhbCB3 aXRoIGEgd2lkZSByYW5nZSBvZg0KICAgICAgYXBwbGljYXRpb25zIGFuZCBw cm90b2NvbHMgKFNNVFAsIEhUVFAsIFJUU1AsIElNLCBldGMuKS4gVGhlDQog ICAgICBsYW5ndWFnZSBtdXN0IGJlIGFibGUgdG8gYWNjb21tb2RhdGUgdmly dHVhbGx5IGFsbCBrbm93biB0YXNrcyBpbg0KICAgICAgc2VsZWN0aW5nIGEg ZGVzaXJlZCBhZGFwdGF0aW9uIHNlcnZpY2UgZm9yIGEgbWVzc2FnZSBvZiBh IGtub3duDQogICAgICBhcHBsaWNhdGlvbiBwcm90b2NvbCAoYW5kIGNvbmNl aXZhYmxlIGZ1dHVyZSBhcHBsaWNhdGlvbnMpLg0KDQogICBlZmZpY2llbmN5 OiBMYW5ndWFnZSBpbnRlcnByZXRhdGlvbiBtdXN0IGJlIGVmZmljaWVudCBl bm91Z2ggdG8gYmUNCiAgICAgIGNvbXBhcmFibGUgd2l0aCBvdGhlciBtZXNz YWdlIHByb2Nlc3Npbmcgb3ZlcmhlYWRzIGF0IGEgdHlwaWNhbA0KICAgICAg YXBwbGljYXRpb24gcHJveHkgKGUuZy4sIGludGVycHJldGluZyBIVFRQIGhl YWRlcnMgdG8gZGV0ZXJtaW5lDQogICAgICByZXNwb25zZSBjYWNoYWJpbGl0 eSkuDQoNCiAgIHNpbXBsaWNpdHk6IFR5cGljYWwgY29uZmlndXJhdGlvbnMg bXVzdCBiZSBlYXN5IHRvIHdyaXRlIGFuZA0KICAgICAgdW5kZXJzdGFuZCBm b3IgYSB0eXBpY2FsIE9QRVMgc3lzdGVtIGFkbWluaXN0cmF0b3IuDQoNCiAg IGNvcnJlY3RuZXNzOiBNYW55IG1lc3NhZ2UgaGFuZGxpbmcgY29uZmlndXJh dGlvbnMgYXJlIHdyaXR0ZW4gd2l0aG91dA0KICAgICAgZGlyZWN0IGFjY2Vz cyB0byBpbnRlcm1lZGlhcmllcyB0aGF0IHdpbGwgdXNlIHRob3NlDQogICAg ICBjb25maWd1cmF0aW9ucy4gIFRoZSBleHRlbnQgb2Ygb2ZmLWxpbmUgKGNv bXBpbGUtdGltZSkgY29ycmVjdG5lc3MNCiAgICAgIGNoZWNrcyBzaG91bGQg Y2F0Y2ggYWxsIHN5bnRheCBlcnJvcnMgYW5kIG1hbnkgY29tbW9uIHNlbWFu dGljDQogICAgICBlcnJvcnMgc3VjaCBhcyB1bmRlZmluZWQgdmFsdWVzIGFu ZCB0eXBlIGNvbmZsaWN0cy4NCg0KICAgY29tcGFjdG5lc3M6IEl0IGlzIHBv c3NpYmxlIHRoYXQgc29tZSBwcm9jZXNzaW5nIGluc3RydWN0aW9ucyB3aWxs IGJlDQogICAgICBwaWdneWJhY2tlZCBhcyBoZWFkZXJzL21ldGFkYXRhIHRv IG1lc3NhZ2VzIHRoZXkgcmVmZXIgdG8sIHBsYWNpbmcNCiAgICAgIHN0cmlu Z2VudCBzaXplIHJlcXVpcmVtZW50cyBvbiBsYW5ndWFnZSBjb2RlLg0KDQoN Cg0KQmVjayAmIFJvdXNza292ICAgICAgICAgIEV4cGlyZXMgQXByaWwgMjYs IDIwMDQgICAgICAgICAgICAgICAgIFtQYWdlIDNdDQoMDQpJbnRlcm5ldC1E cmFmdCAgICAgICBQOiBNZXNzYWdlIFByb2Nlc3NpbmcgTGFuZ3VhZ2UgICAg ICAgICBPY3RvYmVyIDIwMDMNCg0KDQogICBzZWN1cml0eTogSXQgc2hvdWxk IGJlIGRpZmZpY3VsdCBpZiBub3QgaW1wb3NzaWJsZSB0byB3cml0ZSBtYWxp Y2lvdXMNCiAgICAgIGNvZGUgdGhhdCB3b3VsZCByZXN1bHQgaW4gc2VjdXJp dHkgdnVsbmVyYWJpbGl0eSBvZiBjb21wbGlhbnQNCiAgICAgIGxhbmd1YWdl IGludGVycHJldGVyLg0KDQogICBXaGlsZSBQIGFkZHJlc3NlcyBPUEVTIG5l ZWRzLCBpdHMgZGVzaWduIGlzIG1lYW50IHRvIGJlIGFwcGxpY2FibGUNCiAg IGZvciBhIHZhcmlldHkgb2Ygc2ltaWxhciBpbnRlcm1lZGlhcnkgY29uZmln dXJhdGlvbiB0YXNrcyBzdWNoIGFzDQogICBhY2Nlc3MgY29udHJvbCBsaXN0 IChBQ0wpIHNwZWNpZmljYXRpb24gYW5kIG1lc3NhZ2Ugcm91dGluZyBpbiBw cm94eQ0KICAgbWVzaGVzIG9yIGxvYWQtYmFsYW5jaW5nIGVudmlyb25tZW50 cy4NCg0KICAgUCBkZXNpZ24gaXMgYmFzZWQgb24gYSBtaW5pbWFsIHVzZWZ1 bCBzdWJzZXQgb2YgZmVhdHVyZXMgZnJvbSBzZXZlcmFsDQogICBwcm9ncmFt bWluZyBsYW5ndWFnZXMgc3VjaCBhcyBSIChTKSwgU21hbGx0YWxrLCBhbmQg QysrLiBUZWNobmljYWxseQ0KICAgc3BlYWtpbmcsIFAgaXMgYSBzaW5nbGUt YXNzaWdubWVudCwgbGF6eSBldmFsdWF0aW9uLCBzdHJvbmdseSB0eXBlZA0K ICAgZnVuY3Rpb25hbCBwcm9ncmFtbWluZyBsYW5ndWFnZS4NCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpCZWNrICYgUm91c3Nrb3YgICAgICAg ICAgRXhwaXJlcyBBcHJpbCAyNiwgMjAwNCAgICAgICAgICAgICAgICAgW1Bh Z2UgNF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgIFA6IE1lc3NhZ2UgUHJv Y2Vzc2luZyBMYW5ndWFnZSAgICAgICAgIE9jdG9iZXIgMjAwMw0KDQoNCjIu IFN5bnRheA0KDQogICBQIHN5bnRheCBpcyBkZWZpbmVkIGJ5IHRoZSBmb2xs b3dpbmcgQXVnbWVudGVkIEJhY2t1cy1OYXVyIEZvcm0NCiAgIChBQk5GKSBb UkZDMjIzNF06DQoNCiAgIGNvZGUgPSAqc3RhdGVtZW50DQoNCiAgIHN0YXRl bWVudCA9DQogICAJZXhwcmVzc2lvbi1zdGF0ZW1lbnQgLw0KICAgCWFzc2ln bm1lbnQtc3RhdGVtZW50IC8NCiAgIAljb21wb3VuZC1zdGF0ZW1lbnQgLw0K ICAgCWlmLXN0YXRlbWVudCAvDQogICAJY29tbWVudCAvDQogICAJIjsiDQoN CiAgIGlmLXN0YXRlbWVudCA9IGlmLWhlYWQgKmlmLWFsdCBbaWYtdGFpbF0N CiAgIGlmLWhlYWQgICAgICA9ICJpZiIgIigiIGV4cHJlc3Npb24gIikiICJ7 IiBjb2RlICJ9Ig0KICAgaWYtYWx0ICAgICAgID0gImVsc2lmIiAiKCIgZXhw cmVzc2lvbiAiKSIgInsiIGNvZGUgIn0iDQogICBpZi10YWlsICAgICAgPSAi ZWxzZSIgInsiIGNvZGUgIn0iDQoNCiAgIGNvbXBvdW5kLXN0YXRlbWVudCA9 ICJ7IiBjb2RlICJ9Ig0KDQogICBhc3NpZ25tZW50ID0gaWRlbnRpZmllciAi Oj0iIGV4cHJlc3Npb24gIjsiDQoNCiAgIGV4cHJlc3Npb24tc3RhdGVtZW50 ID0gZXhwcmVzc2lvbiAiOyINCg0KICAgZXhwcmVzc2lvbiA9DQogICAJY29u c3RhbnQtZXhwcmVzc2lvbiAvDQogICAJbmFtZSAvDQogICAJZnVuY3Rpb24t Y2FsbCAvDQogICAJIigiIGV4cHJlc3Npb24gIikiIC8NCiAgIAkieyIgY29k ZSAifSIgLw0KICAgCXVuYXJ5LW9wIGV4cHJlc3Npb24gLw0KICAgCWV4cHJl c3Npb24gYmluYXJ5LW9wIGV4cHJlc3Npb24NCg0KICAgY29uc3RhbnQtZXhw cmVzc2lvbiA9IGJvb2xlYW4gLyBudW1iZXIgLyBzdHJpbmcNCg0KICAgbmFt ZSA9IGlkZW50aWZpZXIgKiggIi4iIGlkZW50aWZpZXIpDQoNCiAgIGZ1bmN0 aW9uLWNhbGwgPSBuYW1lICIoIiBbY2FsbC1wYXJhbWV0ZXJzXSAiKSINCg0K ICAgY2FsbC1wYXJhbWV0ZXJzID0gZXhwcmVzc2lvbiAqKCAiLCIgZXhwcmVz c2lvbikNCg0KICAgaWRlbnRpZmllciA9IChBTFBIQSAvICJfIikgKihBTFBI QSAvIERJR0lUIC8gIl8iKQ0KDQogICB1bmFyeS1vcCA9DQogICAJIisiIC8g Ii0iIC8NCiAgIAlpZGVudGlmaWVyDQoNCg0KDQpCZWNrICYgUm91c3Nrb3Yg ICAgICAgICAgRXhwaXJlcyBBcHJpbCAyNiwgMjAwNCAgICAgICAgICAgICAg ICAgW1BhZ2UgNV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgIFA6IE1lc3Nh Z2UgUHJvY2Vzc2luZyBMYW5ndWFnZSAgICAgICAgIE9jdG9iZXIgMjAwMw0K DQoNCiAgIGJpbmFyeS1vcCA9DQogICAJIj09IiAvICIhPSIgLw0KICAgCSI8 IiAvICI+IiAvICI+PSIgLyAiPD0iIC8NCiAgIAkiKyIgLyAiLSIgLyAiKiIg LyAiLyIgLyAiJSIgLw0KICAgCWlkZW50aWZpZXINCg0KICAgY29tbWVudCA9 ICIvKiIgT0NURVQgIiovIiAgICAgICAgICAgICA7IG5vIG5lc3RpbmcgYWxs b3dlZA0KDQogICBib29sZWFuID0gInRydWUiIC8gImZhbHNlIg0KDQogICBu dW1iZXIgPSAxKkRJR0lUIDsgbm8gbGVhZGluZyB6ZXJvcw0KDQogICBzdHJp bmcgPSBEUVVPVEUgKnN0cmluZy1jaGFyIERRVU9URQ0KDQogICBzdHJpbmct Y2hhciA9DQogICAJJXgwMC0yMSAvICV4MjMtNUIgLyAleDVELUZGIC8gOyBh bnkgYnV0IHF1b3RlIGFuZCBiYWNrc2xhc2gNCiAgIAllc2NhcGUtc2VxdWVu Y2UgICAgICAgICAgICAgICA7IEMrKyBvciBYTUwgZXNjYXBlIHNlcXVlbmNl PyBYWFgNCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZp Z3VyZSAyDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkJlY2sgJiBSb3Vzc2tvdiAgICAg ICAgICBFeHBpcmVzIEFwcmlsIDI2LCAyMDA0ICAgICAgICAgICAgICAgICBb UGFnZSA2XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgUDogTWVzc2FnZSBQ cm9jZXNzaW5nIExhbmd1YWdlICAgICAgICAgT2N0b2JlciAyMDAzDQoNCg0K My4gTGFuZ3VhZ2UgZWxlbWVudHMNCg0KMy4xIE9iamVjdHMNCg0KICAgUCBp cyBjZW50ZXJlZCBhcm91bmQgdGhlIGNvbmNlcHQgb2YgYW4gIm9iamVjdCIg dGhhdCBpcyBzaW1pbGFyIHRvDQogICBvYmplY3RzIGZyb20gb3RoZXIgb2Jq ZWN0LW9yaWVudGVkIGxhbmd1YWdlcy4gQW4gb2JqZWN0IGlzLA0KICAgZXNz ZW50aWFsbHksIGEgcGllY2Ugb2YgZGF0YSBvciBpbmZvcm1hdGlvbi4gVGhl IHZhbHVlIG9mIGFuIG9iamVjdA0KICAgaXMgaW5kaXN0aW5ndWlzaGFibGUg ZnJvbSB0aGUgb2JqZWN0IGl0c2VsZi4gT2JqZWN0IHR5cGUgaXMgZGVmaW5l ZA0KICAgYnkgdGhlIHNlbWFudGljcyBvZiBhcHBsaWNhYmxlIG9wZXJhdGlv bnMgYW5kIG1hbmlwdWxhdGlvbnMuICBBbG1vc3QNCiAgIGV2ZXJ5dGhpbmcg aW4gUCBpcyBhbiBvYmplY3QsIGV2ZW4gYSBwaWVjZSBvZiBjb2RlLiBIZXJl IGFyZSBhIGZldyBQDQogICBvYmplY3RzLCBsaXN0ZWQgb25lIHBlciBsaW5l Og0KDQogICAJMA0KICAgCSJodHRwOi8vd3d3LmlldGYub3JnLyINCiAgIAlD b3JlDQogICAJeyBhIDo9IDEvMDsgfQ0KDQogICBNYW55IG9iamVjdHMgY29u dGFpbiBvdGhlciBvYmplY3RzLCBvZnRlbiBjYWxsZWQgbWVtYmVycy4gIE1l bWJlcnMNCiAgIGFyZSBhY2Nlc3NpYmxlIGJ5IHRoZWlyIG5hbWUsIHVzaW5n IHRoZSBtZW1iZXIgYWNjZXNzIG9wZXJhdG9yICgiLiIpLg0KICAgTWVtYmVy IGFjY2VzcyBvcGVyYXRvciBoYXMgYSBzaW5nbGUgcGFyYW1ldGVyOiB0aGUg bmFtZSBvZiB0aGUgbWVtYmVyDQogICB0byBhY2Nlc3MuIEFsbCBQIG9iamVj dHMgc3VwcG9ydCAiLiIgb3BlcmF0b3IsIGJ1dCBub3QgYWxsIG9iamVjdHMN CiAgIGhhdmUgbWVtYmVycy4gSGVyZSBhcmUgYSBmZXcgZXhhbXBsZXM6DQoN CiAgIAlIdHRwLm1lc3NhZ2UuaGVhZGVycw0KICAgCUNvcmUuaW50ZXJwcmV0 ZXIuc3RvcA0KICAgCSJzdHJpbmciLm5vc3VjaG1lbWJlcg0KDQogICBNYW55 IG9iamVjdHMgc3VwcG9ydCBvcGVyYXRvcnMgb3RoZXIgdGhhbiBtZW1iZXIg YWNjZXNzLiBGb3IgZXhhbXBsZSwNCiAgIG1lbWJlciBvYmplY3RzIHRoYXQg c3VwcG9ydCBmdW5jdGlvbiBjYWxsICIoKSIgb3BlcmF0b3IgYXJlIG9mdGVu DQogICBjYWxsIG1ldGhvZHMuDQoNCiAgIAlIdHRwLm1lc3NhZ2UuaGVhZGVy cy5oYXZlKGhlYWRlcikNCiAgIAlDb3JlLmludGVycHJldGVyLnN0b3AoKQ0K ICAgCTEgLyAwDQogICAJInN0cmluZyIgKyAic3RyaW5nIg0KDQogICBQIG9w ZXJhdG9ycyBhcmUgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy4zLiBiZWxvdy4N Cg0KICAgUCBkb2VzIG5vdCBoYXZlIGJ1aWx0LWluIGZhY2lsaXRpZXMgZm9y IGRlc2NyaWJpbmcgb2JqZWN0IHR5cGVzLiBXaGVuDQogICB3cml0aW5nIGEg UCBwcm9ncmFtLCBvbmx5IG9iamVjdHMga25vd24gdG8gaW50ZXJwcmV0ZXIg KGUuZy4sIENvcmUpDQogICBhbmQgb2JqZWN0cyBnZW5lcmF0ZWQgYnkga25v d24gb2JqZWN0cyAoZS5nLiwgSHR0cC5tZXNzYWdlLmhlYWRlcnMpDQogICBj YW4gYmUgdXNlZC4gUCBzdXBwb3J0cyBsb2FkYWJsZSBtb2R1bGVzIHRoYXQg Y2FuIGJlIHVzZWQgdG8gYWRkDQogICBvYmplY3RzIHRvIHN1cHBvcnQgbmV3 IGFwcGxpY2F0aW9uIHByb3RvY29scy4gIEluIGZhY3QsIFAgY29yZQ0KICAg c3VwcG9ydHMgbm8gYXBwbGljYXRpb24gcHJvdG9jb2xzIGRpcmVjdGx5LiBJ bnN0ZWFkLCBtb2R1bGVzIGxpa2UNCiAgICJIVFRQIiBjYW4gYmUgdXNlZCB0 byBwcm9jZXNzIG1lc3NhZ2VzIGRlcGVuZGluZyBvbiBhcHBsaWNhdGlvbg0K ICAgcHJvdG9jb2wgYmVpbmcgcHJveGllZC4NCg0KDQoNCg0KDQpCZWNrICYg Um91c3Nrb3YgICAgICAgICAgRXhwaXJlcyBBcHJpbCAyNiwgMjAwNCAgICAg ICAgICAgICAgICAgW1BhZ2UgN10NCgwNCkludGVybmV0LURyYWZ0ICAgICAg IFA6IE1lc3NhZ2UgUHJvY2Vzc2luZyBMYW5ndWFnZSAgICAgICAgIE9jdG9i ZXIgMjAwMw0KDQoNCjMuMiBUeXBlIGNvbnZlcnNpb24NCg0KICAgSW50ZXJw cmV0ZXJzIE1VU1QgTk9UIHNpbGVudGx5IGNvbnZlcnQgKGNhc3QpIG9iamVj dCB0eXBlcy4gIFdoZW4NCiAgIGV4cGxpY2l0IGNvbnZlcnNpb24gKGNhc3Rp bmcpIGlzIG5lZWRlZCBvYmplY3RzIHNob3VsZCBwcm92aWRlDQogICBwb2x5 bW9ycGhpYyBtZXRob2RzIChtZXRob2RzIHdpdGggdGhlIHNhbWUgbmFtZSBi dXQgZGlmZmVyZW50IGZvcm1hbA0KICAgcGFyYW1ldGVyIHR5cGVzKS4NCg0K My4zIE9wZXJhdG9ycw0KDQogICBPcGVyYXRvcnMgYXJlIHVzZWQgaW4gUCB0 byBkZW5vdGUgY29tbW9uIG9wZXJhdGlvbnMgb24gYnVpbHQtaW4NCiAgIG9i amVjdCB0eXBlcyBhbmQgbGFuZ3VhZ2UgY29uc3RydWN0cy4gTm8gb3BlcmF0 b3JzIGFyZSBkZWZpbmVkIGZvcg0KICAgb2JqZWN0cyBwcm92aWRlZCBieSBt b2R1bGVzLiBQIG9wZXJhdG9ycyBkbyBub3QgbW9kaWZ5IHRoZWlyDQogICBv cGVyYW5kcy4gTm90ZSB0aGF0IGFsbCBvcGVyYXRvcnMgbWF5IHJlc3VsdCBh IGZhaWx1cmUuDQoNCiAgIFVuYXJ5IE9wZXJhdG9ycw0KDQogICArLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSsNCiAgIHwgICBvcGVyYXRvciAgIHwgICBvcGVy YW5kICAgfCByZXN1bHQgdHlwZSB8IHNlbWFudGljcyAgICAgICAgICAgICAg fA0KICAgfCAgICAgICAgICAgICAgfCAgICAgdHlwZSAgICB8ICAgICAgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8DQogICArLS0tLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSsNCiAgIHwgICAgICAgKyAgICAgIHwgICAgbnVtYmVy ICAgfCAgICBudW1iZXIgICB8IHJldHVybnMgb3BlcmFuZCAgICAgICAgfA0K ICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAg IHwgICAgICAgICAgICAgICAgICAgICAgICB8DQogICB8ICAgICAgIC0gICAg ICB8ICAgIG51bWJlciAgIHwgICAgbnVtYmVyICAgfCByZXR1cm5zIHplcm8g bWludXMgICAgIHwNCiAgIHwgICAgICAgICAgICAgIHwgICAgICAgICAgICAg fCAgICAgICAgICAgICB8IG9wZXJhbmQgICAgICAgICAgICAgICAgfA0KICAg fCAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICB8DQogICB8ICAgIGltcG9ydCAgICB8 ICAgIHN0cmluZyAgIHwgICAgbW9kdWxlICAgfCBpbXBvcnRzIG1vZHVsZSBt ZW1iZXJzIHwNCiAgIHwgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAg ICAgICAgICAgICB8IGludG8gZ2xvYmFsIG5hbWVzcGFjZSAgfA0KICAgfCAg ICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwgYW5k IHJldHVybnMgYSBtb2R1bGUgICB8DQogICB8ICAgICAgICAgICAgICB8ICAg ICAgICAgICAgIHwgICAgICAgICAgICAgfCBvYmplY3QgdGhhdCBjYW4gYmUg ICAgIHwNCiAgIHwgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAg ICAgICAgICB8IHVzZWQgdG8gYWNjZXNzIHRoaXMgICAgfA0KICAgfCAgICAg ICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwgbW9kdWxl IG1lbWJlcnMgICAgICAgICB8DQogICB8ICAgICAgICAgICAgICB8ICAgICAg ICAgICAgIHwgICAgICAgICAgICAgfCBleHBsaWNpdGx5OyBvcGVyYW5kIGlz IHwNCiAgIHwgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAg ICAgICB8IG1vZHVsZSBpZGVudGlmaWVyLCBhICAgfA0KICAgfCAgICAgICAg ICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwgVVJJOyBmYWls cyBvbiBhbnkgICAgICB8DQogICB8ICAgICAgICAgICAgICB8ICAgICAgICAg ICAgIHwgICAgICAgICAgICAgfCBlcnJvciAgICAgICAgICAgICAgICAgIHwN CiAgIHwgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgfCAgICAgIG5vdCAg ICAgfCAgIGJvb2xlYW4gICB8ICAgYm9vbGVhbiAgIHwgbG9naWNhbCBuZWdh dGlvbiAgICAgICB8DQogICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICAg IHwgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAg IHwgICAgICB0cnkgICAgIHwgICAgIGNvZGUgICAgfCAgIGJvb2xlYW4gICB8 IGludGVycHJldCBvcGVyYW5kIGFuZCAgfA0KICAgfCAgICAgICAgICAgICAg fCAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwgcmV0dXJuIHRydWUgb3Ig ZmFpbDsgICB8DQogICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwg ICAgICAgICAgICAgfCB0cnkgaXMgdGhlIG9ubHkgICAgICAgIHwNCiAgIHwg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICB8IG9w ZXJhdG9yIGRlZmluZWQgZm9yICAgfA0KICAgfCAgICAgICAgICAgICAgfCAg ICAgICAgICAgICB8ICAgICAgICAgICAgIHwgY29kZTsgdHJ5IG5ldmVyICAg ICAgICB8DQogICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwgICAg ICAgICAgICAgfCByZXR1cm5zIGZhbHNlICAgICAgICAgIHwNCiAgICstLS0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKw0KDQoNCg0KDQoNCg0KQmVjayAmIFJvdXNz a292ICAgICAgICAgIEV4cGlyZXMgQXByaWwgMjYsIDIwMDQgICAgICAgICAg ICAgICAgIFtQYWdlIDhdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICBQOiBN ZXNzYWdlIFByb2Nlc3NpbmcgTGFuZ3VhZ2UgICAgICAgICBPY3RvYmVyIDIw MDMNCg0KDQogICBCaW5hcnkgT3BlcmF0b3JzDQoNCiAgICstLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKw0KICAgfCAgIG9wZXJhdG9yICB8ICBvcGVyYW5kcyB8 ICByZXN1bHQgIHwgc2VtYW50aWNzICAgICAgICAgICAgICAgICAgICB8DQog ICB8ICAgICAgICAgICAgIHwgICAgdHlwZSAgIHwgICB0eXBlICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICstLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tKw0KICAgfCAgICAgID09ICAgICB8ICBib29sZWFuICB8ICBi b29sZWFuIHwgc2ltcGxlIHZhbHVlIGVxdWFsaXR5ICAgICAgICB8DQogICB8 ICAgICAgICAgICAgIHwgICAgIG9yICAgIHwgICAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwNCiAgIHwgICAgICAgICAgICAgfCAg aW50ZWdlciAgfCAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfA0KICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICB8ICAgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICB8ICAg ICAgIT0gICAgIHwgIGJvb2xlYW4gIHwgIGJvb2xlYW4gfCBzaW1wbGUgdmFs dWUgaW5lcXVhbGl0eSAgICAgIHwNCiAgIHwgICAgICAgICAgICAgfCBvciBu dW1iZXIgfCAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfA0KICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICB8ICAgICAgICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICB8ICAgICAg PCAgICAgIHwgICBudW1iZXIgIHwgIGJvb2xlYW4gfCBsZXNzIHRoYW47ICI+ IiwgIjw9IiBhbmQgICAgIHwNCiAgIHwgICAgICAgICAgICAgfCAgICAgICAg ICAgfCAgICAgICAgICB8ICI+PSIgYXJlIGRlZmluZWQgc2ltaWxhcmx5ICAg fA0KICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICB8ICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICB8ICAgIGVxdWFs ICAgIHwgICBzdHJpbmcgIHwgIGJvb2xlYW4gfCBsZWZ0IHN0cmluZyBlcXVh bHMgcmlnaHQgICAgIHwNCiAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAg fCAgICAgICAgICB8IHN0cmluZyAgICAgICAgICAgICAgICAgICAgICAgfA0K ICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICB8ICAgICAgICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICB8ICAgY29udGFpbnMg IHwgICBzdHJpbmcgIHwgIGJvb2xlYW4gfCBsZWZ0IGNvbnRhaW5zIHJpZ2h0 ICAgICAgICAgIHwNCiAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgfCAg ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAg fCBiZWdpbnNfd2l0aCB8ICAgc3RyaW5nICB8ICBib29sZWFuIHwgbGVmdCBz dHJpbmcgYmVnaW5zIHdpdGggdGhlICB8DQogICB8ICAgICAgICAgICAgIHwg ICAgICAgICAgIHwgICAgICAgICAgfCByaWdodCBzdHJpbmcgICAgICAgICAg ICAgICAgIHwNCiAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgfCAgICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgfCAg ZW5kc193aXRoICB8ICAgc3RyaW5nICB8ICBib29sZWFuIHwgbGVmdCBzdHJp bmcgZW5kcyB3aXRoIHRoZSAgICB8DQogICB8ICAgICAgICAgICAgIHwgICAg ICAgICAgIHwgICAgICAgICAgfCByaWdodCBzdHJpbmcgICAgICAgICAgICAg ICAgIHwNCiAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgfCAgICAgICAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgfCAgICAg YW5kICAgICB8ICBib29sZWFuICB8ICBib29sZWFuIHwgc2hvcnQtY2lyY3Vp dGVkIGxvZ2ljYWwgICAgICB8DQogICB8ICAgICAgICAgICAgIHwgICAgICAg ICAgIHwgICAgICAgICAgfCBjb25qdW5jdGlvbjogdGhlIHJpZ2h0ICAgICAg IHwNCiAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgfCAgICAgICAgICB8 IGV4cHJlc3Npb24gaXMgZXZhbHVhdGVkIG9ubHkgfA0KICAgfCAgICAgICAg ICAgICB8ICAgICAgICAgICB8ICAgICAgICAgIHwgaWYgdGhlIGxlZnQgZXhw cmVzc2lvbiBpcyAgICB8DQogICB8ICAgICAgICAgICAgIHwgICAgICAgICAg IHwgICAgICAgICAgfCB0cnVlICAgICAgICAgICAgICAgICAgICAgICAgIHwN CiAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgfCAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgfCAgICAgIG9yICAg ICB8ICBib29sZWFuICB8ICBib29sZWFuIHwgc2hvcnQtY2lyY3VpdGVkIGxv Z2ljYWwgICAgICB8DQogICB8ICAgICAgICAgICAgIHwgICAgICAgICAgIHwg ICAgICAgICAgfCBkaXNqdW5jdGlvbjogdGhlIHJpZ2h0ICAgICAgIHwNCiAg IHwgICAgICAgICAgICAgfCAgICAgICAgICAgfCAgICAgICAgICB8IGV4cHJl c3Npb24gaXMgZXZhbHVhdGVkIG9ubHkgfA0KICAgfCAgICAgICAgICAgICB8 ICAgICAgICAgICB8ICAgICAgICAgIHwgaWYgdGhlIGxlZnQgZXhwcmVzc2lv biBpcyAgICB8DQogICB8ICAgICAgICAgICAgIHwgICAgICAgICAgIHwgICAg ICAgICAgfCBmYWxzZSAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgIHwg ICAgICAgICAgICAgfCAgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfA0KICAgfCAgICAgeG9yICAgICB8ICBi b29sZWFuICB8ICBib29sZWFuIHwgZXhjbHVzaXZlIGxvZ2ljYWwgICAgICAg ICAgICB8DQogICB8ICAgICAgICAgICAgIHwgICAgICAgICAgIHwgICAgICAg ICAgfCBjb25qdW5jdGlvbjsgY2Fubm90IGJlICAgICAgIHwNCiAgIHwgICAg ICAgICAgICAgfCAgICAgICAgICAgfCAgICAgICAgICB8IHNob3J0LWNpcmN1 aXRlZDogYm90aCAgICAgICAgfA0KICAgfCAgICAgICAgICAgICB8ICAgICAg ICAgICB8ICAgICAgICAgIHwgb3BlcmFuZHMgYXJlIGV2YWx1YXRlZCAgICAg ICB8DQogICB8ICAgICAgICAgICAgIHwgICAgICAgICAgIHwgICAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgIHwgIG90aGVy d2lzZSAgfCBzdGF0ZW1lbnQgfCAgICBhbnkgICB8IHNob3J0LWNpcmN1aXRl ZCBmYWlsdXJlICAgICAgfA0KICAgfCAgICAgICAgICAgICB8ICAgICAgICAg ICB8ICAgICAgICAgIHwgZGV0ZWN0aW9uOiB0aGUgcmlnaHQgICAgICAgICB8 DQogICB8ICAgICAgICAgICAgIHwgICAgICAgICAgIHwgICAgICAgICAgfCBl eHByZXNzaW9uIGlzIGV2YWx1YXRlZCBvbmx5IHwNCiAgIHwgICAgICAgICAg ICAgfCAgICAgICAgICAgfCAgICAgICAgICB8IGlmIHRoZSBsZWZ0IGV4cHJl c3Npb24gICAgICAgfA0KDQoNCg0KQmVjayAmIFJvdXNza292ICAgICAgICAg IEV4cGlyZXMgQXByaWwgMjYsIDIwMDQgICAgICAgICAgICAgICAgIFtQYWdl IDldDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICBQOiBNZXNzYWdlIFByb2Nl c3NpbmcgTGFuZ3VhZ2UgICAgICAgICBPY3RvYmVyIDIwMDMNCg0KDQogICB8 ICAgICAgICAgICAgIHwgICAgICAgICAgIHwgICAgICAgICAgfCBmYWlsczsg cmV0dXJucyB0aGUgdmFsdWUgb2YgIHwNCiAgIHwgICAgICAgICAgICAgfCAg ICAgICAgICAgfCAgICAgICAgICB8IHRoZSBsYXN0IGV4cHJlc3Npb24gICAg ICAgICAgfA0KICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICB8ICAgICAg ICAgIHwgZXZhbHVhdGVkICAgICAgICAgICAgICAgICAgICB8DQogICB8ICAg ICAgICAgICAgIHwgICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwNCiAgIHwgICAgICAtICAgICAgfCAgIG51 bWJlciAgfCAgbnVtYmVyICB8IGFyaXRobWV0aWMgZGlmZmVyZW5jZSAgICAg ICAgfA0KICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICB8ICAgICAgICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICB8ICAgICAg KyAgICAgIHwgICBudW1iZXIgIHwgIG51bWJlciAgfCBhcml0aG1ldGljIHN1 bSAgICAgICAgICAgICAgIHwNCiAgIHwgICAgICAgICAgICAgfCAgICAgICAg ICAgfCAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fA0KICAgfCAgICAgICsgICAgICB8ICAgc3RyaW5nICB8ICBzdHJpbmcgIHwg Y29uY2F0ZW5hdGlvbiAgICAgICAgICAgICAgICB8DQogICB8ICAgICAgICAg ICAgIHwgICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwNCiAgIHwgICAgICAqICAgICAgfCAgIG51bWJlciAg fCAgbnVtYmVyICB8IGFyaXRobWV0aWMgcHJvZHVjdCAgICAgICAgICAgfA0K ICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICB8ICAgICAgICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICB8ICAgICAgLyAgICAg IHwgICBudW1iZXIgIHwgIG51bWJlciAgfCBhcml0aG1ldGljIHJhdGlvOyBy b3VuZGVkIHRvIHwNCiAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgfCAg ICAgICAgICB8IHRoZSBjbG9zZXN0IGludGVnZXIgKFhYWD8pICAgfA0KICAg fCAgICAgICAgICAgICB8ICAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8DQogICB8ICAgICAgJSAgICAgIHwg ICBudW1iZXIgIHwgIG51bWJlciAgfCBhcml0aG1ldGljIG1vZHVsbyAgICAg ICAgICAgIHwNCiAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgfCAgICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgfCAg ICAgIC4gICAgICB8ICAgIG5hbWUgICB8ICBvYmplY3QgIHwgb2JqZWN0IG1l bWJlciBhY2Nlc3M7IGZhaWxzICB8DQogICB8ICAgICAgICAgICAgIHwgICAg ICAgICAgIHwgIG1lbWJlciAgfCBpZiB0aGUgb2JqZWN0IHByb2R1Y2VkIGJ5 ICAgIHwNCiAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgfCAgICAgICAg ICB8IGV4cHJlc3Npb24gb24gdGhlIHJpZ2h0IGRvZXMgfA0KICAgfCAgICAg ICAgICAgICB8ICAgICAgICAgICB8ICAgICAgICAgIHwgbm90IGhhdmUgdGhl IG1lbWJlciBuYW1lZCBieSB8DQogICB8ICAgICAgICAgICAgIHwgICAgICAg ICAgIHwgICAgICAgICAgfCB0aGUgZXhwcmVzc2lvbiBvbiB0aGUgbGVmdC4g IHwNCiAgICstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KDQogICBBIGZ1bmN0 aW9uIGNhbGwgaXMgYW4gbi1hcnkgb3BlcmF0b3IuIEJlc2lkZXMgdGhlIGZ1 bmN0aW9uIG5hbWUsIGl0DQogICB0YWtlcyB6ZXJvIG9yIG1vcmUgYWN0dWFs IHBhcmFtZXRlcnMgYXMgb3BlcmFuZHMuDQoNCiAgIEFsbCBzdHJpbmcgb3Bl cmF0b3JzIGRlc2NyaWJlZCBhYm92ZSBhcmUgY2FzZS1zZW5zaXRpdmUgYW5k IGNvbWUgd2l0aA0KICAgdGhlIGNvcnJlc3BvbmRpbmcgY2FzZS1pbnNlbnNp dGl2ZSBvcGVyYXRvcnM6IEVxdWFsUywgQ29udGFpblMsDQogICBCZWdpbnNf d2l0SCwgYW5kIEVuZHNfd2l0SCAoWFhYOiBiYWQgaWRlYSB0byBuYW1lIHVz aW5nIGNhc2U/KSAoWFhYOg0KICAgc2hvdWxkIHdlIGZvcmNlIHByb2dyYW1t ZXJzIHRvIHBpY2sgdGhlIHJpZ2h0IHZhcmlhbnQgaW5zdGVhZCBvZg0KICAg cHJvdmlkaW5nIGVmZmljaWVudCwgYnV0IHVzdWFsbHkgd3JvbmcgZGVmYXVs dDogY29udGFpbnNfcyBhbmQNCiAgIGNvbnRhaW5zX2k/KQ0KDQogICBPcGVy YXRvciBwcmVjZWRlbmNlIGRlZmluZXMgbmF0dXJhbCBldmFsdWF0aW9uIG9y ZGVyIHVzZWQgaW4NCiAgIG1hdGhlbWF0aWNzIGFuZCBtYW55IHByb2dyYW1t aW5nIGxhbmd1YWdlcy4gSW4gdGhlIGZvbGxvd2luZyBsaXN0LA0KICAgb3Bl cmF0b3JzIGFyZSBvcmRlcmVkIGJhc2VkIG9uIHRoZWlyIHByZWNlZGVuY2Uu IE9wZXJhdG9ycyB3aXRoDQogICBzbWFsbGVyIHByZWNlZGVuY2UgaW5kZXgg YXJlIGV2YWx1YXRlZCBmaXJzdC4gT3BlcmF0b3JzIHdpdGggdGhlIHNhbWUN CiAgIHByZWNlZGVuY2UgaW5kZXggYXJlIGV2YWx1YXRlZCBpbiB0aGUgbGVm dC10by1yaWdodCBvcmRlciBvZg0KICAgb2NjdXJyZW5jZSBpbiBhbiBleHBy ZXNzaW9uLg0KDQogICAxLiAgIC4NCg0KICAgMi4gICAoKQ0KDQogICAzLiAg IG5vdA0KDQogICA0LiAgICogLw0KDQoNCg0KQmVjayAmIFJvdXNza292ICAg ICAgICAgIEV4cGlyZXMgQXByaWwgMjYsIDIwMDQgICAgICAgICAgICAgICAg W1BhZ2UgMTBdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICBQOiBNZXNzYWdl IFByb2Nlc3NpbmcgTGFuZ3VhZ2UgICAgICAgICBPY3RvYmVyIDIwMDMNCg0K DQogICA1LiAgICsgLQ0KDQogICA2LiAgIGFsbCBiaW5hcnkgb3BlcmF0b3Jz IG9uIHN0cmluZzogZXF1YWxzLCBjb250YWlucywgLi4uDQoNCiAgIDcuICAg aW1wb3J0DQoNCiAgIDguICAgPT0gIT0gPCA8PSA+ID49DQoNCiAgIDkuICAg YW5kDQoNCiAgIDEwLiAgb3INCg0KICAgMTEuICB4b3IgKFhYWDogbWlzcGxh Y2VkPykNCg0KICAgMTIuICB0cnkgKFhYWDogbWlzcGxhY2VkPykNCg0KICAg MTMuICBvdGhlcndpc2UNCg0KDQozLjQgRXhwcmVzc2lvbnMNCg0KICAgUCBl eHByZXNzaW9ucyBhcmUgdXNlZCBpbiBpZi1zdGF0ZW1lbnRzIHRvIHNwZWNp ZnkgdGhlIGNvbmRpdGlvbiBmb3INCiAgIHRoZSBpZi1zdGF0ZW1lbnQgYm9k eSB0byBiZSBpbnRlcnByZXRlZC4NCg0KICAgCWlmIChIdHRwLnJlcXVlc3Qu bWV0aG9kID09ICJHRVQiIGFuZCB0aW1lLmN1cnJlbnQoKSA+IHRpbWUubm9v bikgew0KICAgCQkuLi4NCiAgIAl9DQoNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgRmlndXJlIDYNCg0KICAgRXZhbHVhdGlvbiBvZiBhbiBl eHByZXNzaW9uIHN0b3BzIHdoZW4gdGhlIHZhbHVlIG9mIGFuIGV4cHJlc3Np b24gaXMNCiAgIGtub3duIGFuZCBjYW5ub3QgYmUgY2hhbmdlZCBieSBmdXJ0 aGVyIGV2YWx1YXRpb24uIFRoaXMNCiAgIHNob3J0LWNpcmN1aXRpbmcgb3B0 aW1pemF0aW9uIHRlY2huaXF1ZSBpcyBjb21tb24gdG8gbWFueSBwcm9ncmFt bWluZw0KICAgbGFuZ3VhZ2VzLiBJbiB0aGUgZm9sbG93aW5nIGV4YW1wbGUs IHRoZSB2YWx1ZSBvZiBBIHdpbGwgbmV2ZXIgYmUNCiAgIGludGVycHJldGVk IHdoZW4gQyBpcyBpbnRlcnByZXRlZCwgcmVnYXJkbGVzcyBvZiB0aGUgY29u dGV4dCB3aGVyZSBDDQogICBpcyB1c2VkOg0KDQogICAJQyA6PSBmYWxzZSBh bmQgQTsNCiAgIAlpZiAoQykgeyAuLi4gfTsNCiAgIAlpZiAoIUMpIHsgLi4u IH07DQogICAJLi4uDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgRmlndXJlIDcNCg0KDQozLjUgU3RhdGVtZW50cw0KDQogICBPYmplY3Rz IGFyZSBtYW5pcHVsYXRlZCB1c2luZyBpZi1zdGF0ZW1lbnRzIGFuZCBmdW5j dGlvbi1jYWxscy4NCg0KDQoNCkJlY2sgJiBSb3Vzc2tvdiAgICAgICAgICBF eHBpcmVzIEFwcmlsIDI2LCAyMDA0ICAgICAgICAgICAgICAgIFtQYWdlIDEx XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgUDogTWVzc2FnZSBQcm9jZXNz aW5nIExhbmd1YWdlICAgICAgICAgT2N0b2JlciAyMDAzDQoNCg0KICAgCWlm IChIdHRwLnJlcXVlc3QubWV0aG9kID09ICJHRVQiKSB7DQogICAJCVNlcnZp Y2VzLmFwcGx5T25lKHNlcnZpY2VGb28pOw0KICAgCX0NCg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgOA0KDQoNCjMuNiBBc3Np Z25tZW50cw0KDQogICBNb3N0IHByb2NlZHVyYWwgcHJvZ3JhbW1pbmcgbGFu Z3VhZ2VzIHVzZSB2YXJpYWJsZXMgdG8gc3RvcmUNCiAgIGludGVybWVkaWF0 ZSBwcm9jZXNzaW5nIHJlc3VsdHMuIEluIHN1Y2ggbGFuZ3VhZ2VzLCBhIHZh cmlhYmxlIGlzDQogICBlc3NlbnRpYWxseSBhIG5hbWVkIHBpZWNlIG9mIG1l bW9yeSB0aGF0IGNhbiBiZSBhc3NpZ25lZCBhIHZhbHVlIGFuZA0KICAgY2Fu IGJlIHVwZGF0ZWQgd2l0aCBuZXcgdmFsdWVzIGFzIG5lZWRlZC4gUCBkb2Vz IG5vdCBoYXZlIHN1Y2gNCiAgIHZhcmlhYmxlcy4gSW5zdGVhZCwgUCB1c2Vz IGEgInNpbmdsZSBhc3NpZ25tZW50IiBhcHByb2FjaDogYW4NCiAgIGV4cHJl c3Npb24gY2FuIGJlIHRhZ2dlZCB3aXRoIGEgbmFtZSBhbmQgdGhhdCBuYW1l IGNhbiBiZSByZXVzZWQgbWFueQ0KICAgdGltZXMgaW4gdGhlIHByb2dyYW0u IE9uIHRoZSBzdXJmYWNlLCB0aGlzIGlzIGVxdWl2YWxlbnQgdG8gaGF2aW5n DQogICBhbGwgInRyYWRpdGlvbmFsIiB2YXJpYWJsZXMgZGVjbGFyZWQgYXMg ImNvbnN0YW50Ii4gVGhlIGZvbGxvd2luZyB0d28NCiAgIGlmLXN0YXRlbWVu dHMgYXJlIHNlbWFudGljYWxseSBlcXVpdmFsZW50IGluIFA6DQoNCiAgIAlp ZiAoSHR0cC5yZXF1ZXN0LmhlYWRlcnMuaGF2ZShIdHRwLm1ha2VIZWFkZXIo IkNsaWVudC1JUCIpKSkgey4uLn0NCg0KICAgCWggOj0gSHR0cC5tYWtlSGVh ZGVyKCJDbGllbnQtSVAiKTsNCiAgIAlocyA6PSBIdHRwLnJlcXVlc3QuaGVh ZGVycygpOw0KICAgCWlmIChocy5oYXZlKGgpKSB7Li4ufQ0KDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSA5DQoNCiAgIElmIHRo ZSBleHByZXNzaW9uIGNoYW5nZXMsIGEgbmV3IG5hbWUgbXVzdCBiZSB1c2Vk IHRvIHRhZyB0aGUgbmV3DQogICBleHByZXNzaW9uLiBBZnRlciBhbiBhc3Np Z25tZW50IHN0YXRlbWVudCwgdGhlIHZhbHVlIG9mIHRoZSBuYW1lIGlzDQog ICBub3QgdGhlIHZhbHVlIG9mIHRoZSBleHByZXNzaW9uLCBidXQgdGhlIGV4 cHJlc3Npb24gaXRzZWxmLiAgVGh1cywNCiAgIHRoZSBmb2xsb3dpbmcgdHdv IGNvZGUgZnJhZ21lbnRzIGFyZSBlcXVpdmFsZW50IGFuZCBtYWtlIG5vIHNl bnNlIGluDQogICBQICh0aGUgZmlyc3QgZnJhZ21lbnQgd291bGQgbWFrZSBz ZW5zZSBpbiBsYW5ndWFnZXMgc3VjaCBhcyBDKyspOg0KDQogICAJaCA6PSBI dHRwLm1ha2VIZWFkZXIoIkNsaWVudC1JUCIpOw0KICAgCWggOj0gSHR0cC5t YWtlSGVhZGVyKCJTZXJ2ZXItSVAiKTsNCg0KICAgCWggOj0gSHR0cC5tYWtl SGVhZGVyKCJDbGllbnQtSVAiKTsNCiAgIAlIdHRwLm1ha2VIZWFkZXIoIkNs aWVudC1JUCIpIDo9IEh0dHAubWFrZUhlYWRlcigiU2VydmVyLUlQIik7DQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMTANCg0K ICAgVGhlIGludGVycHJldGVyIGNhbiBidXQgZG9lcyBub3QgaGF2ZSB0byBl dmFsdWF0ZSB0aGUgZXhwcmVzc2lvbg0KICAgbmFtZWQgaW4gdGhlIGFzc2ln bm1lbnQgc3RhdGVtZW50IHVudGlsIHRoZSBuYW1lIGlzIGFjdHVhbGx5IHVz ZWQgaW4NCiAgIGFuIGV4cHJlc3Npb24gdGhhdCByZXF1aXJlcyBldmFsdWF0 aW9uIChlLmcuLCBhcyBhIHBhcmFtZXRlciBvZiBhDQogICBmdW5jdGlvbiBj YWxsIHN0YXRlbWVudCkuIFRoaXMgYWxsb3dzIGZvciBvcHRpb25hbCBwZXJm b3JtYW5jZQ0KICAgb3B0aW1pemF0aW9ucyB3aGVyZSBvbmx5IHVzZWQgZXhw cmVzc2lvbnMgYXJlIGV2YWx1YXRlZC4NCg0KICAgUCBkb2VzIG5vdCBoYXZl IHVzZXItZGVmaW5lZCBmdW5jdGlvbnMuIEhvd2V2ZXIsIHNvbWUgY29kZSBy ZXVzZSBpcw0KDQoNCg0KQmVjayAmIFJvdXNza292ICAgICAgICAgIEV4cGly ZXMgQXByaWwgMjYsIDIwMDQgICAgICAgICAgICAgICAgW1BhZ2UgMTJdDQoM DQpJbnRlcm5ldC1EcmFmdCAgICAgICBQOiBNZXNzYWdlIFByb2Nlc3Npbmcg TGFuZ3VhZ2UgICAgICAgICBPY3RvYmVyIDIwMDMNCg0KDQogICBwb3NzaWJs ZSBiZWNhdXNlIFAgY29kZSBpcyBhIHZhbGlkIGV4cHJlc3Npb24gYW5kLCBo ZW5jZSwgY2FuIGJlDQogICBuYW1lZCBhbmQgcmV1c2VkOg0KDQogICAJY29k ZSA6PSB7IC4uLiBjb21wbGljYXRlZCBzZXJ2aWNlIGFjdGlvbiAuLi4gfTsN CiAgIAlpZiAoY29uZGl0aW9uMSkgeyBjb2RlOyB9Ow0KICAgCS4uLg0KICAg CWlmIChjb25kaXRpb24yKSB7IGNvZGU7IH07DQoNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBGaWd1cmUgMTENCg0KICAgWFhYOiBkb2N1bWVu dCB3aGV0aGVyIGV4cHJlc3Npb24gaGFzIHRvIGJlIGV2YWx1YXRlZCBpbiB0 aGUNCiAgIGFzc2lnbm1lbnQgY29udGV4dCBvciB1c2UgY29udGV4dC4NCg0K ICAgTmFtZXMgaW50cm9kdWNlZCB1c2luZyBhc3NpZ25tZW50cyBoYXZlIGds b2JhbCBzY29wZS4gR2xvYmFsIHNjb3BlDQogICBtYWtlcyBpdCBwb3NzaWJs ZSB0byBzZWxlY3QgYW1vbmcgYWx0ZXJuYXRpdmUgdmFsdWVzIHdpdGhvdXQN CiAgIHVzZXItZGVmaW5lZCBmdW5jdGlvbnMgb3IgdHJ1ZSB2YXJpYWJsZXM6 DQoNCiAgIAlpZiAoY29uZGl0aW9uKSB7DQogICAJCS8qIG5vICJzZXJ2aWNl IiBuYW1lIGV4aXN0cyBhdCB0aGlzIHBvaW50ICovDQogICAJCXNlcnZpY2Ug Oj0gU2VydmljZXMuZmluZE9uZSh1cmkxKTsNCiAgIAl9IGVsc2Ugew0KICAg CQkvKiBubyAic2VydmljZSIgbmFtZSBleGlzdHMgYXQgdGhpcyBwb2ludCAq Lw0KICAgCQlzZXJ2aWNlIDo9IFNlcnZpY2VzLmZpbmRPbmUodXJpMik7DQog ICAJCXNlcnZpY2UuYXV0aG9yaXphdGlvbihteUF1dGgpOw0KICAgCX0NCiAg IAlTZXJ2aWNlcy5hcHBseU9uZShzZXJ2aWNlKTsgLyogc2VydmljZSBuYW1l IGlzIHN0aWxsIHZpc2libGUgKi8NCg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEZpZ3VyZSAxMg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCkJlY2sgJiBSb3Vzc2tvdiAgICAgICAg ICBFeHBpcmVzIEFwcmlsIDI2LCAyMDA0ICAgICAgICAgICAgICAgIFtQYWdl IDEzXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgUDogTWVzc2FnZSBQcm9j ZXNzaW5nIExhbmd1YWdlICAgICAgICAgT2N0b2JlciAyMDAzDQoNCg0KNC4g TW9kdWxlcw0KDQogICBBcHBsaWNhdGlvbi1zcGVjaWZpYyBzdXBwb3J0IGlz IGF2YWlsYWJsZSBpbiBQIHZpYSBtb2R1bGVzLiBNb2R1bGUgaXMNCiAgIGFu IG9iamVjdC4gSW50ZXJwcmV0ZXJzIE1VU1Qgc3VwcGx5IHR3byBtb2R1bGVz IG5hbWVkIENvcmUgYW5kDQogICBTZXJ2aWNlcy4gVGhlIENvcmUgbW9kdWxl IGNvbnRhaW5zIG1lbWJlcnMgZm9yIG1hbmlwdWxhdGluZyBidWlsdC1pbg0K ICAgUCBvYmplY3QgdHlwZXMgc3VjaCBhcyBpbnRlZ2VycyBhbmQgc3RyaW5n cy4gVGhlIFNlcnZpY2VzIG1vZHVsZQ0KICAgbWFuYWdlcyBPUEVTIHNlcnZp Y2VzLiBBcHBsaWNhdGlvbiBzcGVjaWZpYyBtb2R1bGVzIGNhbiBiZSBsb2Fk ZWQNCiAgIGludG8gdGhlIG5hbWVzcGFjZSBvZiBhIFAgcHJvZ3JhbSB2aWEg dGhlIGltcG9ydCBvcGVyYXRvciAoc2VlDQogICBTZWN0aW9uIDMuMykuIEZv ciBleGFtcGxlLCB0aGUgZm9sbG93aW5nIFAgY29kZSBpbXBvcnRzIGFuIEhU VFANCiAgIG1vZHVsZSwgbmFtZXMgdGhlIHJlc3VsdCAodGhlIG1vZHVsZSBp dHNlbGYpICJIdHRwIiwgYW5kIGNoZWNrcyBmb3INCiAgIHRoZSBwcmVzZW5j ZSBvZiBhIGNlcnRhaW4gSFRUUCBtZXNzYWdlIGhlYWRlcjoNCg0KICAgCUh0 dHAgOj0gaW1wb3J0ICJodHRwOi8vaWV0Zi5vcmcvb3Blcy9ydWxlcy9wL0hU VFAiOw0KICAgCWlmIChIdHRwLm1lc3NhZ2UuaGVhZGVycy5oYXZlKCJBY2Nl cHQiKSkgeyAuLi4gfQ0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgRmlndXJlIDEzDQoNCiAgIEl0IGlzIG5vdCBwb3NzaWJsZSB0byBpbXBv cnQgYSBDb3JlIG9yIFNlcnZpY2VzIG1vZHVsZSBleHBsaWNpdGx5Lg0KICAg SW5zdGVhZCwgaW50ZXJwcmV0ZXJzIE1VU1QgcHJvdmlkZSBhY2Nlc3MgdG8g Q29yZSBhbmQgU2VydmljZXMNCiAgIG1lbWJlcnMgYXMgaWYgdGhvc2UgbW9k dWxlcyB3ZXJlIGltcG9ydGVkIGp1c3QgYmVmb3JlIHRoZSBwcm9ncmFtDQog ICB0ZXh0Lg0KDQogICBNb2R1bGVzIGFyZSBpZGVudGlmaWVkIGJ5IHRoZWly IFVSSXMgW1JGQzIzOTZdLiBBIG1vZHVsZQ0KICAgc3BlY2lmaWNhdGlvbiBT SE9VTEQgY29udGFpbiBhIGdsb2JhbGx5IHVuaXF1ZSBVUkkgZm9yIHRoYXQg bW9kdWxlLg0KICAgTW9kdWxlIFVSSXMgYXJlIHVzdWFsbHkgbm90IHVzZWQg dG8gZmV0Y2ggbW9kdWxlIGltcGxlbWVudGF0aW9uDQogICByZW1vdGVseSwg YnV0IHRvIGlkZW50aWZ5IGEgc3VpdGFibGUgbG9jYWwgY29weSBvZiBhIG1v ZHVsZTsgdGhleSBhcmUNCiAgIGlkZW50aWZpZXJzLCBub3QgbG9jYXRvcnMu IEludGVycHJldGVycyBtYWludGFpbiBhIGRpcmVjdG9yeSBvZg0KICAga25v d24tdG8tdGhlbSBtb2R1bGUgVVJJcy4gV2hlbiBhIG1vZHVsZSBuZWVkcyB0 byBiZSBpbXBvcnRlZCwgdGhlDQogICBpbnRlcnByZXRlciBjaGVja3MgaW50 ZXJuYWwgbWV0YWRhdGEgYW5kIGxvYWRzIHRoZSByZXF1ZXN0ZWQgbW9kdWxl DQogICB1c2luZyBtb2R1bGUtc3BlY2lmaWMgaW50ZXJmYWNlLiBJZiB0aGUg bW9kdWxlIGlzIG5vdCBrbm93biBvcg0KICAgbG9hZGluZyBmYWlscywgdGhl IGltcG9ydCBvcGVyYXRvciBmYWlscyBhbmQgdGhlIGZhaWx1cmUgaXMNCiAg IHByb3BhZ2F0ZWQgdXNpbmcgc3RhbmRhcmQgZmFpbHVyZSBwcm9wYWdhdGlv biBydWxlcyAoc2VlIFNlY3Rpb24gNikuDQogICBUaGUgZm9sbG93aW5nIGV4 YW1wbGUgYXR0ZW1wdHMgdG8gaW1wb3J0IG9uZSBvZiB0aGUgU01UUCBtb2R1 bGVzLg0KDQogICAJLyogbG9hZCBvbmUgb2YgdGhlIGF2YWlsYWJsZSBTTVRQ IG1vZHVsZXMgKi8NCiAgIAlTbXRwIDo9IGltcG9ydCAiaHR0cDovL2lldGYu b3JnL29wZXMvcnVsZXMvcC9TTVRQIiBvdGhlcndpc2UNCiAgIAkJaW1wb3J0 ICJodHRwOi8vZXhhbWxlLm9yZy9vcGVzL29wdGltaXplZC9TTVRQdjMiOw0K DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDE0DQoN CiAgIEltcG9ydCBvcGVyYXRpb24gaGFzIHByb2dyYW0gc2NvcGUuIEl0IGlz IG5vdCBwb3NzaWJsZSB0byAidW5sb2FkIiBhbg0KICAgaW1wb3J0ZWQgbW9k dWxlLg0KDQogICAJew0KICAgCQlNIDo9IGltcG9ydCAiaHR0cDovL2lldGYu b3JnL29wZXMvcnVsZXMvcC9IVFRQIjsNCiAgIAkJLi4uDQogICAJfQ0KICAg CS8qIE0gYW5kIE0gbWVtYmVycyBhcmUgc3RpbGwgdmlzaWJsZSBoZXJlICov DQoNCg0KDQpCZWNrICYgUm91c3Nrb3YgICAgICAgICAgRXhwaXJlcyBBcHJp bCAyNiwgMjAwNCAgICAgICAgICAgICAgICBbUGFnZSAxNF0NCgwNCkludGVy bmV0LURyYWZ0ICAgICAgIFA6IE1lc3NhZ2UgUHJvY2Vzc2luZyBMYW5ndWFn ZSAgICAgICAgIE9jdG9iZXIgMjAwMw0KDQoNCiAgIAlpZiAoTS5jb25uZWN0 aW9uLmlzX3BlcnNpc3RlbnQoKSkgeyAuLi4gfQ0KDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgRmlndXJlIDE1DQoNCg0KNC4xIEludGVycHJl dGVyLW1vZHVsZSBpbnRlcmZhY2UNCg0KICAgTW9zdCBtb2R1bGVzIGFyZSBu b3Qgd3JpdHRlbiBpbiBQIHNpbmNlIHRoZSBsYW5ndWFnZSBsYWNrcyBuYXRp dmUNCiAgIG1lY2hhbmlzbXMgZm9yIGRlZmluaW5nIG1vZHVsZSBvciBmdW5j dGlvbiBpbnRlcmZhY2UuIE1vc3QgbW9kdWxlcw0KICAgYXJlIHRpZ2h0bHkg aW50ZWdyYXRlZCB3aXRoIE9QRVMgcHJvY2Vzc29ycyBiZWNhdXNlIGFwcGxp Y2F0aW9uDQogICBhZGFwdGF0aW9uIHJlcXVpcmVzIGFjY2VzcyB0byBwcm9j ZXNzb3IncyBpbnRlcm5hbCBzdGF0ZS4gRm9yDQogICBleGFtcGxlLCBhbiBI VFRQIGludGVybWVkaWFyeSBpbXBsZW1lbnRlZCBpbiBDKysgY2FuIHVzZSBt b2R1bGVzDQogICB3cml0dGVuIGluIEMrKyBhbmQgbWF5IHJlcXVpcmUgdGhh dCBpbXBsZW1lbnRvcnMgaW5oZXJpdCB0aGVpcg0KICAgbW9kdWxlcyBmcm9t IGEgZ2l2ZW4gQysrIGNsYXNzLiAgU3VjaCBtb2R1bGVzIG1heSBiZSBsb2Fk ZWQgdXNpbmcsDQogICBmb3IgZXhhbXBsZSwgYSAiZHluYW1pY2FsbHkgbG9h ZGFibGUgbW9kdWxlIiBtZWNoYW5pc20gc3VwcG9ydGVkIGJ5DQogICBtb3N0 IG1vZGVybiBvcGVyYXRpbmcgc3lzdGVtcy4gU2ltaWxhcmx5LCBhIEphdmEg T1BFUyBwcm9jZXNzb3IgbWF5DQogICByZXF1aXJlIHRoYXQgYWxsIG1vZHVs ZXMgaW1wbGVtZW50IGEgZ2l2ZW4gSmF2YSBpbnRlcmZhY2UgYW5kIHVzZQ0K ICAgSmF2YSBpbXBvcnRpbmcgbWVjaGFuaXNtLiBUaGlzIHNwZWNpZmljYXRp b24gZG9lcyBub3QgZG9jdW1lbnQgYW55DQogICBzcGVjaWZpYyBpbnRlcmZh Y2UgYmV0d2VlbiBhbiBpbnRlcnByZXRlciBhbmQgdGhpcmQtcGFydHkgbW9k dWxlcy4NCg0KICAgTmV2ZXJ0aGVsZXNzLCBhbiBpbnRlcnByZXRlciBNQVkg c3VwcG9ydCBsb2FkaW5nIG9mIG1vZHVsZXMgd3JpdHRlbg0KICAgaW4gUCAo c2ltaWxhciB0byBDKysgI2luY2x1ZGUgZGlyZWN0aXZlcykuIFRoZSBpbnRl cmZhY2UgZm9yDQogICBkaXN0aW5ndWlzaGluZyBVUklzIG9mIFAgcHJvZ3Jh bXMgZnJvbSBpbnRlZ3JhdGVkIG1vZHVsZXMgaXMNCiAgIGltcGxlbWVudGF0 aW9uLWRlcGVuZGVudCBhbmQgaXMgbm90IGRlc2NyaWJlZCBoZXJlLiAgRm9y IGV4YW1wbGUsIGFuDQogICBpbnRlcnByZXRlciBtYXkgYXNzdW1lIHRoYXQg YWxsIHVua25vd24gbW9kdWxlIFVSSXMgY29ycmVzcG9uZCB0byByYXcNCiAg IFAgcHJvZ3JhbXMgYW5kIGF0dGVtcHQgdG8gaW5jbHVkZSBzdWNoIGEgcHJv Z3JhbSBpZiB0aGUgVVJJIHNjaGVtZSBpcw0KICAga25vd24gdG8gdGhlIGlu dGVycHJldGVyOg0KDQogICAJTXlMaWJyYXJ5IDo9IGltcG9ydCAiZmlsZTov L3Vzci9sb2NhbC9saWIvZ2xvYmFscnVsZXMucCI7DQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMTYNCg0KDQo0LjIgTW9kdWxl cyBhbmQgbmFtZXNwYWNlDQoNCiAgIE1lbWJlcnMgb2YgaW1wb3J0ZWQgbW9k dWxlcyBiZWxvbmcgdG8gdGhlIGdsb2JhbCBuYW1lc3BhY2UgYW5kIGFyZQ0K ICAgZGlyZWN0bHkgYWNjZXNzaWJsZSAodmlzaWJsZSkgd2l0aG91dCB0aGUg bW9kdWxlIG5hbWUgcHJlZml4LiBUaGlzDQogICBzaW1wbGUgcnVsZSBtYXkg bGVhZCB0byBjb25mbGljdHMgd2hlbiB0d28gaW1wb3J0ZWQgbW9kdWxlcyBj b250YWluIGENCiAgIG1lbWJlciB3aXRoIHRoZSBzYW1lIG5hbWUuIEludGVy cHJldGVycyBNVVNUIGZhaWwgaWYgYW55IG5hbWUNCiAgIHJlc29sdXRpb24g aXMgYW1iaWd1b3VzLiBJbnRlcnByZXRlcnMgTVVTVCBOT1QgdXNlIGhldXJp c3RpY3MgdG8NCiAgIGd1ZXNzIHByb2dyYW1tZXIncyBpbnRlbnQuIFByb2dy YW1tZXJzIGhhdmUgdG8gdXNlIGZ1bGx5IHF1YWxpZmllZA0KICAgbmFtZXMg dG8gcmVzb2x2ZSBhbWJpZ3VpdGllcy4NCg0KICAgRm9yIGV4YW1wbGUsIGFs bCBvZiB0aGUgaW1wb3J0IHN0YXRlbWVudHMgYmVsb3cgcG9sbHV0ZSBnbG9i YWwgbmFtZQ0KICAgc3BhY2UsIGJ1dCB0aGUgZmlyc3QgdHdvIHByb3ZpZGUg YSB3YXkgZm9yIGEgcHJvZ3JhbW1lciB0byByZXNvbHZlDQogICBjb25mbGlj dHMsIGlmIGFueToNCg0KDQoNCg0KDQpCZWNrICYgUm91c3Nrb3YgICAgICAg ICAgRXhwaXJlcyBBcHJpbCAyNiwgMjAwNCAgICAgICAgICAgICAgICBbUGFn ZSAxNV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgIFA6IE1lc3NhZ2UgUHJv Y2Vzc2luZyBMYW5ndWFnZSAgICAgICAgIE9jdG9iZXIgMjAwMw0KDQoNCiAg IAkvKiBpbXBvcnQgSFRUUCBtb2R1bGUgKi8NCiAgIAlIdHRwIDo9IGltcG9y dCAiaHR0cDovL2lldGYub3JnL29wZXMvcnVsZXMvcC9IVFRQIjsNCg0KICAg CS8qIGltcG9ydCBTTVRQIG1vZHVsZSAqLw0KICAgCVNtdHAgOj0gaW1wb3J0 ICJodHRwOi8vaWV0Zi5vcmcvb3Blcy9ydWxlcy9wL1NNVFAiOw0KDQogICAJ LyogaW1wb3J0IGEgbG9jYWwgZmlsZSB3aXRob3V0IG5hbWluZyBpdCAqLw0K ICAgCWltcG9ydCAiZmlsZTovLy91c3IvbG9jYWwvZ2xvYmFscnVsZXMucCI7 DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMTcN Cg0KICAgSW4gdGhlIGZvbGxvd2luZyBleGFtcGxlLCBib3RoIHRoZSBIdHRw IGFuZCBTbXRwIG1vZHVsZXMgaGF2ZSB0aGUNCiAgIHNhbWUgbWVtYmVyIG5h bWVkICJtZXNzYWdlIiwgYW5kIHRoZSBjb2RlIGxlYWRzIHRvIGFuIGFtYmln dWl0eSwgZXZlbg0KICAgdGhvdWdoIFNtdHAgbW9kdWxlJ3MgbWVzc2FnZSBk b2VzIG5vdCBoYXZlIGEgIm1ldGhvZCIgbWVtYmVyOg0KDQogICAJU210cCA6 PSBpbXBvcnQgImh0dHA6Ly9pZXRmLm9yZy9vcGVzL3J1bGVzL3AvU01UUCI7 DQogICAJSHR0cCA6PSBpbXBvcnQgImh0dHA6Ly9pZXRmLm9yZy9vcGVzL3J1 bGVzL3AvSFRUUCI7DQoNCiAgIAltZXRob2QxIDo9IG1lc3NhZ2UubWV0aG9k OyAgICAgIC8qIGVycm9yOiBIVFRQIG9yIFNNVFAgIm1lc3NhZ2UiPyAqLw0K ICAgCW1ldGhvZDIgOj0gSHR0cC5tZXNzYWdlLm1ldGhvZDsgLyogT0s6IEhU VFAgIm1lc3NhZ2UiICovDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBGaWd1cmUgMTgNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpCZWNrICYgUm91c3Nrb3Yg ICAgICAgICAgRXhwaXJlcyBBcHJpbCAyNiwgMjAwNCAgICAgICAgICAgICAg ICBbUGFnZSAxNl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgIFA6IE1lc3Nh Z2UgUHJvY2Vzc2luZyBMYW5ndWFnZSAgICAgICAgIE9jdG9iZXIgMjAwMw0K DQoNCjUuIE9QRVMgU2VydmljZXMNCg0KICAgU2VydmljZXMgbW9kdWxlIGNv bnRhaW5zIGJhc2ljIGF0dHJpYnV0ZXMgYW5kIG1ldGhvZHMgZm9yIHNlYXJj aGluZw0KICAgYW5kIGV4ZWN1dGluZyBPUEVTIHNlcnZpY2VzOg0KDQogICBT ZXJ2aWNlcy5maW5kT25lKFVSSSk6IHJldHVybnMgYSBzZXJ2aWNlIG9iamVj dCB0aGF0IGNvcnJlc3BvbmRzIHRvDQogICAgICB0aGUgc3BlY2lmaWVkIFVS SS4gRmFpbHMgaWYgbm8gY29ycmVzcG9uZGluZyBvYmplY3QgZXhpc3RzLg0K DQogICBTZXJ2aWNlcy5hcHBseU9uZShzZXJ2aWNlLCAuLi4pOiBhcHBsaWVz IHRoZSBzcGVjaWZpZWQgc2VydmljZSB0byB0aGUNCiAgICAgIGN1cnJlbnQg YXBwbGljYXRpb24gbWVzc2FnZSBhbmQgb3B0aW9uYWxseSBzdXBwbGllcw0K ICAgICAgc2VydmljZS1zcGVjaWZpYyBhcHBsaWNhdGlvbiBwYXJhbWV0ZXJz LiBYWFg6IHNob3VsZCBwYXJhbWV0ZXJzDQogICAgICBpbmNsdWRlIHRoZSBw YXJ0IG9mIHRoZSBtZXNzYWdlIHRvIGJlIG1vZGlmaWVkIG9yIGp1c3Qgc2Vy dmljZXMNCiAgICAgIG1ldGFkYXRhPw0KDQogICBIZXJlIGlzIGEgc2Vydmlj ZSBhcHBsaWNhdGlvbiBleGFtcGxlIGZvciBhIEdlcm1hbiB0byBGcmVuY2gN CiAgIHRyYW5zbGF0aW9uIHNlcnZpY2U6DQoNCiAgIAlIdHRwIDo9IGltcG9y dCgiSHR0cCIpOw0KICAgCWlmIChIdHRwLnJlc3BvbnNlLmxhbmd1YWdlX2lz KCJnZXJtYW4iKSkgew0KICAgCQlzZXJ2aWNlIDo9IFNlcnZpY2VzLmZpbmRP bmUoIm9wZXM6Ly9zdnMvdHJhbi9nZXJtYW4vZnJlbmNoIik7DQogICAJCXNl cnZpY2UudG9EaWFsZWN0KCJzb3V0aGVybiIpOw0KICAgCQlTZXJ2aWNlcy5h cHBseU9uZShzZXJ2aWNlLCBIdHRwLnJlcXVlc3QuaGVhZGVycyk7DQogICAJ fQ0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDE5 DQoNCiAgIFhYWDogZXhwbGFpbiBob3cgZmFpbHVyZXMgYXJlIHByb3BhZ2F0 ZWQgYW5kIGNhbiBiZSBoYW5kbGVkDQoNCiAgIFhYWDogYWRkIENvcmUuaW50 ZXJwcmV0ZXIuc3RvcCBhbmQgQ29yZS5pbnRlcnByZXRlci5yZXN0YXJ0IG1l dGhvZHMuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCkJlY2sgJiBSb3Vzc2tvdiAgICAgICAgICBFeHBpcmVzIEFwcmls IDI2LCAyMDA0ICAgICAgICAgICAgICAgIFtQYWdlIDE3XQ0KDA0KSW50ZXJu ZXQtRHJhZnQgICAgICAgUDogTWVzc2FnZSBQcm9jZXNzaW5nIExhbmd1YWdl ICAgICAgICAgT2N0b2JlciAyMDAzDQoNCg0KNi4gRmFpbHVyZXMNCg0KICAg VmlydHVhbGx5IGFueSBQIHN0YXRlbWVudCBtYXkgZmFpbDogZXhwcmVzc2lv biBkZW5vbWluYXRvciBtYXkgYmUNCiAgIHplcm8sIG5hbWVkIG1lbWJlcnMg bWF5IG5vdCBleGlzdCwgZnVuY3Rpb25zIG1heSBub3Qgc3VwcG9ydCBzdXBw bGllZA0KICAgcGFyYW1ldGVycywgc2VydmljZSBleGVjdXRpb24gbWF5IGZh aWwsIGludGVycHJldGVyIG1heSByYW4gb3V0IG9mDQogICByZXNvdXJjZXMg ZHVyaW5nIGFuIGFzc2lnbm1lbnQsIGV0Yy4gQSBmYWlsdXJlIGltbWVkaWF0 ZWx5IHN0b3BzDQogICBpbnRlcnByZXRhdGlvbiBvZiB0aGUgZXhwcmVzc2lv biB0aGF0IGNhdXNlZCBpdC4NCg0KICAgRmFpbHVyZSBpcyBwcm9wYWdhdGVk IHVwIHRoZSBleHByZXNzaW9uIGFuZCBzdGF0ZW1lbnQgc3RhY2sgdW50aWwg dGhlDQogICBzdGFjayBpcyBlbXB0eSBvciBhbiAib3RoZXJ3aXNlIiBhbHRl cm5hdGl2ZSBpcyByZWFjaGVkIChzZWUgU2VjdGlvbg0KICAgMy4zKS4gSWYg dGhlIHN0YWNrIGlzIGVtcHR5LCB0aGUgZW50aXJlIFAgcHJvZ3JhbSBpbnRl cnByZXRhdGlvbg0KICAgdGVybWluYXRlcyB3aXRoIGEgZmFpbHVyZS4gSWYg YW4gIm90aGVyd2lzZSIgYWx0ZXJuYXRpdmUgaXMNCiAgIGVuY291bnRlcmVk LCB0aGUgZmFpbHVyZSBpcyBmb3Jnb3R0ZW4gYW5kIGludGVycHJldGF0aW9u IHJlc3VtZXMgd2l0aA0KICAgdGhhdCBhbHRlcm5hdGl2ZS4NCg0KICAgRmFp bHVyZSBwcm9wYWdhdGlvbiBydWxlcyBhbGxvdyB0byBjYXRjaCBmYWlsdXJl cywgc2ltaWxhciB0byBhbg0KICAgZXhjZXB0aW9uIG1lY2hhbmlzbXMgaW4g bGFuZ3VhZ2VzIGxpa2UgQysrIG9yIEphdmEsIGV4Y2VwdCB0aGF0IFANCiAg IGV4Y2VwdGlvbnMgYXJlIG5vdCBvYmplY3RzICh0aGV5IGNhcnJ5IG5vIGlu Zm9ybWF0aW9uKS4gRm9yIGV4YW1wbGUsDQogICBoZXJlIGlzIGEgc2ltcGxl IHdheSB0byBpbnRyb2R1Y2UgYSBiYWNrdXAvZmFpbG92ZXIgc2VydmljZToN Cg0KICAgCXsNCiAgIAkJLi4uDQogICAJCVNlcnZpY2VzLmFwcGx5T25lKHVu c2FmZVNlcnZpY2UpOw0KICAgCX0gb3RoZXJ3aXNlIHsNCiAgIAkJLi4uDQog ICAJCVNlcnZpY2VzLmFwcGx5T25lKGZhaWxvdmVyU2VydmljZSk7DQogICAJ fTsNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAy MA0KDQogICBUaGUgIm90aGVyd2lzZSIgb3BlcmF0b3IgbWFrZXMgaXQgc2lt cGxlIHRvIHNlbGVjdCBhbW9uZw0KICAgZmFpbHVyZS1wcm9uZSBhbHRlcm5h dGl2ZXM6DQoNCiAgIAlzZXJ2aWNlIDo9IGZpbmRPbmUodXJpMSkgb3RoZXJ3 aXNlIGZpbmRPbmUodXJpMik7DQoNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBGaWd1cmUgMjENCg0KICAgVGhlIGZvbGxvd2luZyBleGFtcGxl IGlsbHVzdHJhdGVzIGhvdyBhIGZhaWx1cmUtcHJvbmUgc2VydmljZSBjYW4g YmUNCiAgIHJldHJpZWQgdHdpY2UgaWYgbmVlZGVkOg0KDQogICAJY29kZSA6 PSB7DQogICAJCS8qIGNvZGUgZXhlY3V0aW5nIHRoZSBzZXJ2aWNlICovDQog ICAJfTsNCiAgIAl0cnkgY29kZSBvdGhlcndpc2UgdHJ5IGNvZGUgb3RoZXJ3 aXNlIHRyeSBjb2RlOw0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgRmlndXJlIDIyDQoNCiAgIEl0IGlzIHBvc3NpYmxlIHRvIGZvcmNlIHRo ZSBpbnRlcnByZXRlciB0byBmYWlsIHVzaW5nIHRoZQ0KDQoNCg0KQmVjayAm IFJvdXNza292ICAgICAgICAgIEV4cGlyZXMgQXByaWwgMjYsIDIwMDQgICAg ICAgICAgICAgICAgW1BhZ2UgMThdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg ICBQOiBNZXNzYWdlIFByb2Nlc3NpbmcgTGFuZ3VhZ2UgICAgICAgICBPY3Rv YmVyIDIwMDMNCg0KDQogICAiQ29yZS5pbnRlcnByZXRlci5mYWlsKHJlYXNv bikiIGNhbGwuIFRoaXMgaXMgaGFuZHkgd2hlbiB0aGVyZSBpcyBhDQogICBs b2dpY2FsIGZhaWx1cmUgdGhhdCB0aGUgaW50ZXJwcmV0ZXIgY2Fubm90IGRl dGVjdCBvbiBpdHMgb3duOg0KDQogICAJew0KICAgCQkvKiBsYXJnZSBwaWVj ZSBvZiBjb2RlIGV4ZWN1dGluZyBzZXZlcmFsIHNlcnZpY2VzLA0KICAgCQkg ICBlYWNoIG1hbmlwdWxhdGluZyB0aGUgY3VycmVudCBIVFRQIG1lc3NhZ2Ug Li4uICovDQoNCiAgIAkJLyogY2hlY2twb2ludCAqLw0KICAgCQlpZiAoIUh0 dHAubWVzc2FnZS5oZWFkZXJzLmhhdmUoIkNvbnRlbnQtTGVuZ3RoIikpIHsN CiAgIAkJCUNvcmUuaW50ZXJwcmV0ZXIuZmFpbCgic2VydmljZXMgZGlkIG5v dCBzZXQgQ0wiKTsNCiAgIAkJfQ0KDQogICAJCS8qIE9LLCBjb250aW51ZSBt ZXNzYWdlIG1hbmlwdWxhdGlvbiAuLi4gKi8NCiAgIAl9IG90aGVyd2lzZSB7 DQogICAJCS8qIHJlY292ZXIgZnJvbSBmYWlsdXJlIC4uLiAqLw0KICAgCX0N Cg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAyMw0K DQogICBUaGlzIHNwZWNpZmljYXRpb24gaGFzIG5vIGZhaWx1cmUgcmVwb3J0 aW5nIHJlcXVpcmVtZW50cy4gIFRoZSBleHRlbnQNCiAgIGFuZCBmb3JtIG9m IGZhaWx1cmUgcmVwb3J0aW5nIGRlcGVuZHMgb24gdGhlIGVudmlyb25tZW50 OiBEZXZlbG9wZXINCiAgIGVudmlyb25tZW50cyB3b3VsZCBiZW5lZml0IGZy b20gZXh0ZW5zaXZlIGFuZCBkZXRhaWxlZCByZXBvcnRpbmcgb2YNCiAgIGZh aWx1cmVzLiBTdGFuZC1hbG9uZSBpbnRlcm1lZGlhcmllcyBwcm9jZXNzaW5n IFAgaW5zdHJ1Y3Rpb25zIG1heQ0KICAgYmVuZWZpdCBmcm9tIHNvbWUgcmVw b3J0aW5nLCBhcHByb3ByaWF0ZWx5IGltcGxlbWVudGVkIG5vdCB0byBicmlu Zw0KICAgZG93biB0aGUgcHJveHkgZHVlIHRvIGhpZ2ggdm9sdW1lIG9mIGZh aWx1cmVzLiBVc2VyIGVudmlyb25tZW50cywNCiAgIGVzcGVjaWFsbHkgbW9i aWxlIGFuZCBzaW1pbGFybHkgcmVzb3VyY2UtY29uc3RyYWludCBhcHBsaWNh dGlvbnMNCiAgIHNob3VsZCBwcm9iYWJseSBjb25zZXJ2ZSBzY2FyY2UgcmVz b3VyY2VzIGFuZCBwcm9kdWNlIG5vIHJlcG9ydHMgYnkNCiAgIGRlZmF1bHQu DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KQmVjayAmIFJvdXNza292ICAgICAgICAgIEV4cGlyZXMgQXByaWwgMjYs IDIwMDQgICAgICAgICAgICAgICAgW1BhZ2UgMTldDQoMDQpJbnRlcm5ldC1E cmFmdCAgICAgICBQOiBNZXNzYWdlIFByb2Nlc3NpbmcgTGFuZ3VhZ2UgICAg ICAgICBPY3RvYmVyIDIwMDMNCg0KDQo3LiBTZWN1cml0eSBDb25zaWRlcmF0 aW9ucw0KDQogICBYWFg6IGRvY3VtZW50IG5vbi1vYnZpb3VzIHZ1bG5lcmFi aWxpdGllczogdG9vIG1hbnkgbmFtZXMsIHRvbyBkZWVwDQogICBuZXN0aW5n LCBpbnZhbGlkIG1hdGgsIHRvbyBtdWNoIGVycm9yIGxvZ2dpbmc7IGV4ZWN1 dGlvbiBvZg0KICAgdW5hdXRob3JpemVkIHNlcnZpY2VzLCB1bmF1dGhvcml6 ZWQgZXhwb3N1cmUgb2Ygc2Vuc2l0aXZlIGluZm9ybWF0aW9uDQogICB0byBh dXRob3JpemVkIHNlcnZpY2VzLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KQmVjayAmIFJvdXNza292ICAgICAgICAg IEV4cGlyZXMgQXByaWwgMjYsIDIwMDQgICAgICAgICAgICAgICAgW1BhZ2Ug MjBdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICBQOiBNZXNzYWdlIFByb2Nl c3NpbmcgTGFuZ3VhZ2UgICAgICAgICBPY3RvYmVyIDIwMDMNCg0KDQo4LiBD b21wbGlhbmNlDQoNCiAgIFhYWDogZGVmaW5lIHdoYXQgYSBjb21wbGlhbnQg aW50ZXJwcmV0ZXIgaXMuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpCZWNrICYgUm91c3Nrb3YgICAgICAg ICAgRXhwaXJlcyBBcHJpbCAyNiwgMjAwNCAgICAgICAgICAgICAgICBbUGFn ZSAyMV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgIFA6IE1lc3NhZ2UgUHJv Y2Vzc2luZyBMYW5ndWFnZSAgICAgICAgIE9jdG9iZXIgMjAwMw0KDQoNCkFw cGVuZGl4IEEuIEV4YW1wbGVzDQoNCiAgIFRoaXMgYXBwZW5kaXggY29udGFp bnMgaGFsZi1iYWtlZCBleGFtcGxlcyB0byBpbGx1c3RyYXRlIFAgdXNhZ2Ug aW4NCiAgIGNvbW1vbiBPUEVTIGVudmlyb25tZW50cy4gRXhhbXBsZSB0aGVt ZXMgYXJlIHRha2VuIGZyb20NCiAgIFtJLUQuYmVjay1vcGVzLWlybWxdIHRv IGVhc2UgdGhlIGNvbXBhcmlzb24gd2l0aCBJUk1MLg0KDQogICBIZXJlIGlz IGEgZGF0YSBwcm92aWRlciBleGFtcGxlOg0KDQogICAJaW50ZXJwcmV0ZXIu bGFuZ3VhZ2VWZXJzaW9uKCIxLjAiKTsgLy8gZmFpbHMgaWYgaW5jb21wYXRp YmxlDQoNCiAgIAlIdHRwIDo9IGltcG9ydCgiSHR0cCIpOw0KICAgCWxvb2t1 cChIdHRwKTsNCg0KICAgCS8vIElzIHRoZSByZXF1ZXN0ZWQgd2ViIGRvY3Vt ZW50IG91ciBob21lIHBhZ2U/DQogICAJaXNIb21lIDo9IHJlcXVlc3QudXJp Lmxvb2tzTGlrZUhvbWUoKTsNCg0KICAgCS8vIERvZXMgdGhlIHVzZXIgc2Vu ZCB1cyBhIHNwZWNpZmljIGNvb2tpZT8NCiAgIAljb29raWUgOj0gbWFrZUhl YWRlcigiQ29va2llIiwgInNldz0yMyIpOw0KICAgCWhhdmVDb29raWUgOj0g cmVxdWVzdC5oZWFkZXJzLmhhdmUoY29va2llKTsNCg0KICAgCWlmIChpc0hv bWUgYW5kIGhhdmVDb29raWUpIHsNCiAgIAkJU2VydmljZXMgOj0gaW1wb3J0 KCJTZXJ2aWNlcyIpOw0KICAgCQlzZXJ2aWNlIDo9IFNlcnZpY2VzLmZpbmRP bmUoIm9wZXM6Ly9sb2NhbC5uZXQvYWRkLWxjbC1jb250ZW50Iik7DQogICAJ CXNlcnZpY2UuY2xpZW50SXAocmVxdWVzdC5jbGllbnRJcCk7DQogICAJCVNl cnZpY2VzLmFwcGx5T25lKHNlcnZpY2UpOw0KICAgCX0NCg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAyNA0KDQogICBIZXJlIGlz IGEgZGF0YSBjb25zdW1lciBleGFtcGxlOg0KDQogICAJU2VydmljZXMgOj0g aW1wb3J0KCJTZXJ2aWNlcyIpOw0KICAgCXNlcnZpY2UgOj0gU2VydmljZXMu ZmluZE9uZSgib3BlczovL3ByaXZhY3kubmV0L3ByaXYtc2VydiIpOw0KICAg CXNlcnZpY2UuYWN0aW9uKCJyZW1vdmUtcmVmZXJlciIpOw0KICAgCVNlcnZp Y2VzLmFwcGx5T25lKHNlcnZpY2UpOw0KDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgRmlndXJlIDI1DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KQmVjayAmIFJvdXNza292ICAgICAgICAgIEV4cGlyZXMgQXByaWwg MjYsIDIwMDQgICAgICAgICAgICAgICAgW1BhZ2UgMjJdDQoMDQpJbnRlcm5l dC1EcmFmdCAgICAgICBQOiBNZXNzYWdlIFByb2Nlc3NpbmcgTGFuZ3VhZ2Ug ICAgICAgICBPY3RvYmVyIDIwMDMNCg0KDQpBcHBlbmRpeCBCLiBUby1kbw0K DQogICBpMThuOiBXaGF0IGFyZSBJRVRGIGFuZCByZWFsLXdvcmxkIGludGVy bmF0aW9uYWxpemF0aW9uIHJlcXVpcmVtZW50cw0KICAgICAgZm9yIGxhbmd1 YWdlcz8gIENhbiB3ZSBzYXkgdGhhdCBldmVyeXRoaW5nIGlzIFVuaWNvZGUg VVRGLTggYW5kIGJlDQogICAgICBkb25lIHdpdGggaXQ/IERvZXMgVVRGIGhh dmUgYSBub3Rpb24gb2Ygc3BhY2UgY2hhcmFjdGVycyBsaWtlDQogICAgICBB U0NJSSBkb2VzPyBJZiBub3QsIGhvdyBjYW4gd2Ugc2VwYXJhdGUgZ3JhbW1h ciB0b2tlbnMgd2l0aG91dA0KICAgICAgcmVxdWlyaW5nIHRoZW0gdG8gYmUg QVNDSUk/DQoNCiAgIG5hbWVzcGFjZXM6IE1vZHVsZSBsb29rdXAgZmFjaWxp dHkgbGVhZHMgdG8gcG90ZW50aWFsIGNvbmZsaWN0cyBhbW9uZw0KICAgICAg aWRlbnRpY2FsIG5hbWVzIGZyb20gZGlmZmVyZW50IG1vZHVsZXMuIFdoYXQg aXMgdGhlIGJlc3Qgd2F5IHRvDQogICAgICByZXNvbHZlIHRoZXNlIGNvbmZs aWN0cz8gSG93IG90aGVyIGxhbmd1YWdlcyBkbyBpdD8NCg0KICAgc2VjdXJp dHk6IFdyaXRlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24uICBB IGxvdCBjYW4gYmUgbW92ZWQNCiAgICAgIGZyb20gdGhlIElSTUwgc2VjdXJp dHkgc2VjdGlvbi4gU29tZSBjYW4gYmUgYm9ycm93ZWQgZnJvbSBPQ1ANCiAg ICAgIENvcmUuDQoNCiAgIG1vZHVsZSBVUkk6IElzIHRoZXJlIGFuIElFVEYg ZG9jdW1lbnQgdGhhdCB0ZWxscyB1cyBob3cgdG8gYXNzaWduLw0KICAgICAg bWFuYWdlIFVSSXMgZm9yIG5ldyAidGhpbmdzIiBsaWtlIG1vZHVsZXM/IEZv ciBleGFtcGxlLCBkbyB3ZSB1c2UNCiAgICAgIGh0dHA6Ly9pZXRmLm9yZy9v cGVzL2h0dHAgZm9yIEhUVFAgbW9kdWxlPyBPciBkbyB3ZSB1c2UgaWFuYS5v cmcNCiAgICAgIGRvbWFpbiBuYW1lIGluc3RlYWQ/ICBJcyBodHRwOi8vIGEg Z29vZCBjaG9pY2UgZm9yIHRoZSBzY2hlbWUgb3INCiAgICAgIHNob3VsZCB3 ZSB1c2Ugb3BlczovLyBvciBldmVuIHA6Ly8/IS4gRG8gd2UgdXNlIGRlLWZh Y3RvIGZpbGU6Ly8NCiAgICAgIGZvciBsb2NhbCBmaWxlbmFtZXMgZnJvbSB3 aGVyZSByYXcgUCBjb2RlIGNhbiBiZSBpbmNsdWRlZA0KICAgICAgZGlyZWN0 bHk/IE5vdGUgdGhhdCBtb2R1bGVzIGxpa2UgSFRUUCBhcmUgbm90IHdyaXR0 ZW4gaW4gUCENCg0KICAgZXhhbXBsZXM6IEFkZCBtb3JlIHNpbXBsZSBidXQg cmVhbGlzdGljIGFuZCBpbGx1c3RyYXRpdmUgZXhhbXBsZXM6DQogICAgICBI VFRQIGhlYWRlciBhbm9ueW1pemF0aW9uLCBPUEVTL0hUVFAgdHJhY2UgZW50 cnkgbWFuYWdlbWVudCAoZS5nLiwNCiAgICAgIHJlbW92aW5nIHRyYWNlIGVu dHJpZXMgb2YgYSBnaXZlbiBPUEVTIHNlcnZpY2UpLCByZW1vdmluZyBhIHZp cnVzDQogICAgICBhdHRhY2htZW50IGZyb20gYW4gU01UUCBtZXNzYWdlLiBB c2sgZmlsdGVyaW5nL0lDQVAgcGVvcGxlIHRvDQogICAgICBzdXBwbHkgdXNl IGNhc2VzLg0KDQogICBpbnRlcnByZXRlciBBUEk6IERvY3VtZW50IHRoYXQg d2UgZG8gbm90IGRvY3VtZW50IGludGVycHJldGVyIEFQSSAtLQ0KICAgICAg aG93LCBmb3IgZXhhbXBsZSwgYW4gaW1wbGVtZW50ZWQgSFRUUCBtb2R1bGUg aXMgYWN0dWFsbHkgImxvYWRlZCIuDQogICAgICBNZW50aW9uIHRoYXQgdGhl IHNvbHV0aW9uIHdvdWxkIGRlcGVuZCBvbiB0aGUgaW50ZXJwcmV0ZXINCiAg ICAgIGltcGxlbWVudGF0aW9uIGFuZCB0aGUgc2FtZSBIVFRQIG1vZHVsZSBp cyB1bmxpa2VseSB0byBiZQ0KICAgICAgY29tcGF0aWJsZSB3aXRoIGRpZmZl cmVudCBpbnRlcnByZXRlcnMuDQoNCiAgIGRlZmluZSBpbnRlcnByZXRlcjog QWRkIHRlcm1pbm9sb2d5IHNlY3Rpb24uIERlZmluZSBpbnRlcnByZXRlciB0 bw0KICAgICAgbWVhbiBjb21waWxlciwgb3IgcnVuLXRpbWUgaW50ZXJwcmV0 ZXIsIG9yIGJ5dGVjb2RlIGdlbmVyYXRvciwgb3INCiAgICAgIGFueXRoaW5n IG9mIHRoYXQga2luZC4NCg0KICAgb3Aga2V5d29yZHM6IERvY3VtZW50IHRo YXQgb3BlcmF0b3IgbmFtZXMgKHZpYSBpZGVudGlmaWVyIEJORiBlbnRyeSkN CiAgICAgIGFyZSBub3Qga2V5d29yZHM6IG9iamVjdCBtZW1iZXJzIGNhbiB1 c2UgaWRlbnRpZmllcnMgdGhhdCBjbGFzaA0KICAgICAgd2l0aCBvcGVyYXRv ciBuYW1lcyBzaW5jZSB0aGVyZSBjYW4gYmUgbm8gYW1iaWd1aXR5Lg0KDQog ICBzdGF0ZW1lbnQgdmFsdWU6IERvY3VtZW50IHZhbHVlcyBvZiBhbGwgc3Rh dGVtZW50cyAoZS5nLiwNCiAgICAgIGNvbXBvdW5kLXN0YXRlbWVudCB2YWx1 ZSBpcyB0aGUgdmFsdWUgb2YgdGhlIGxhc3Qgc3RhdGVtZW50IGluIGENCiAg ICAgIGNvbXBvdW5kKT8NCg0KDQoNCg0KQmVjayAmIFJvdXNza292ICAgICAg ICAgIEV4cGlyZXMgQXByaWwgMjYsIDIwMDQgICAgICAgICAgICAgICAgW1Bh Z2UgMjNdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICBQOiBNZXNzYWdlIFBy b2Nlc3NpbmcgTGFuZ3VhZ2UgICAgICAgICBPY3RvYmVyIDIwMDMNCg0KDQog ICBSRTogRGVjaWRlIHdoZXRoZXIgd2Ugc2hvdWxkIHN1cHBvcnQgcmVndWxh ciBleHByZXNzaW9uIG1hdGNoaW5nDQogICAgICBuYXRpdmVseS4NCg0KICAg aWYtZWxzZS1pZjogTWFrZSBpZi1lbHNlLWlmIHN5bnRheCBjb21wYWN0Lg0K DQogICBzdHIgPT06IFJlbW92ZSAiPT0iIGZvciBzdHJpbmdzIGluIGV4YW1w bGVzLiBUaGVyZSBpcyBubyBzdWNoDQogICAgICBvcGVyYXRvciBmb3Igc3Ry aW5ncyBhbnltb3JlLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCkJlY2sgJiBSb3Vzc2tvdiAgICAgICAgICBFeHBpcmVz IEFwcmlsIDI2LCAyMDA0ICAgICAgICAgICAgICAgIFtQYWdlIDI0XQ0KDA0K SW50ZXJuZXQtRHJhZnQgICAgICAgUDogTWVzc2FnZSBQcm9jZXNzaW5nIExh bmd1YWdlICAgICAgICAgT2N0b2JlciAyMDAzDQoNCg0KQXBwZW5kaXggQy4g QWNrbm93bGVkZ21lbnRzDQoNCiAgIFRoZSBhdXRob3JzIGdyYXRlZnVsbHkg YWNrbm93bGVkZ2UgY29udHJpYnV0aW9ucyBvZjogIEFud2FyIE0uIEhhbmVl Zg0KICAgKE1vdG9yb2xhKSBhbmQgR2VldGhhIE1hbmp1bmF0aCAoSGV3bGV0 dCBQYWNrYXJkKS4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQpCZWNrICYgUm91c3Nrb3YgICAgICAgICAgRXhw aXJlcyBBcHJpbCAyNiwgMjAwNCAgICAgICAgICAgICAgICBbUGFnZSAyNV0N CgwNCkludGVybmV0LURyYWZ0ICAgICAgIFA6IE1lc3NhZ2UgUHJvY2Vzc2lu ZyBMYW5ndWFnZSAgICAgICAgIE9jdG9iZXIgMjAwMw0KDQoNCkFwcGVuZGl4 IEQuIENoYW5nZSBMb2cNCg0KICAgSW50ZXJuYWwgV0cgcmV2aXNpb24gY29u dHJvbCBJRHM6ICRSQ1NmaWxlOiBydWxlcy1sYW5nLnhtbCx2ICQNCiAgICRS ZXZpc2lvbjogMS4yMyAkLg0KDQogICAyMDAzLzEwLzA4DQoNCiAgICAgICog IEFkZGVkIChleHByZXNzaW9uKSBleHByZXNzaW9uIHRvIEJORi4NCg0KICAg MjAwMy8wOS8yMg0KDQogICAgICAqICBBZGRlZCBtaXNzaW5nIGNvbmNhdGVu YXRpb24gb3BlcmF0b3IgZm9yIHN0cmluZ3MuDQoNCiAgIDIwMDMvMDkvMjEN Cg0KICAgICAgKiAgRXhwbGFpbmVkIHVuZG9jdW1lbnRlZCByZWxhdGlvbnNo aXAgYmV0d2VlbiBpbnRlcnByZXRlcnMgYW5kDQogICAgICAgICB0aGlyZC1w YXJ0eSBtb2R1bGVzLg0KDQogICAyMDAzLzA5LzE5DQoNCiAgICAgICogIFNp bXBsaWZpZWQgbW9kdWxlIGltcG9ydGluZyBhbmQgbG9va3VwIGZhY2lsaXRp ZXMuICBJbXBvcnQgaXMNCiAgICAgICAgIG5vdyBhIGJ1aWx0LWluIG9wZXJh dG9yIGFuZCBub3QgYSBDb3JlIG1ldGhvZC4gIEV4cGxpY2l0IGxvb2t1cA0K ICAgICAgICAgY29udHJvbCBpcyBnb25lIGluIGZhdm9yIG9mIGFsd2F5cy1s b29rdXAgZGVmYXVsdC4NCg0KICAgMjAwMy8wOS8xOA0KDQogICAgICAqICBD b21wbGV0ZWQgc3ludGF4IEJORiBleGNlcHQgZm9yIGVzY2FwZSBzZXF1ZW5j ZXMuDQoNCiAgICAgICogIERpc3Rpbmd1aXNoIGludGVycHJldGF0aW9uIGZh aWx1cmUgZnJvbSBib29sZWFuIGZhbHNlOiB1c2UNCiAgICAgICAgICJvdGhl cndpc2UiIGFuZCAib3IiIG9wZXJhdG9ycyByZXNwZWN0aXZlbHkuIFdpdGgg anVzdCAib3IiIGl0DQogICAgICAgICB3YXMgaW1wb3NzaWJsZSB0byBzYXkg d2hldGhlciwgc2F5LCAiaC5oYXMoZm9vKSIgZmFpbGVkIG9yICJoIg0KICAg ICAgICAganVzdCBkb2VzIG5vdCBoYXZlICJmb28iLg0KDQogICAgICAqICBV c2UgUGVybCBzZW1hbnRpY3MgZm9yICJvdGhlcndpc2UiIC0tIHJldHVybiB0 aGUgdmFsdWUgb2YgbGFzdA0KICAgICAgICAgZXZhbHVhdGVkIGV4cHJlc3Np b24sIG5vdCB0cnVlL2ZhbHNlLg0KDQogICAgICAqICBOZWFybHkgY29tcGxl dGVkIGEgc2V0IG9mIHN1cHBvcnRlZCBvcGVyYXRvcnMsIGluY2x1ZGluZw0K ICAgICAgICAgb3BlcmF0b3JzIGZvciBzdHJpbmdzLg0KDQogICAgICAqICBP cGVyYXRvcnMgc2hvdWxkIG9ubHkgYmUgc3VwcG9ydGVkIGZvciBidWlsdC1p biBvYmplY3RzIGJlY2F1c2UNCiAgICAgICAgIGl0IGlzIGRpZmZpY3VsdCB0 byBkZWZpbmUgaG93ICI1ICsgb2JqZWN0IiBpcyBpbnRlcnByZXRlZA0KICAg ICAgICAgd2l0aG91dCBydW5uaW5nIGludG8gcHJvYmxlbXMgd2l0aCAib2Jq ZWN0ICsgb2JqZWN0IiAoIm9iamVjdCArDQogICAgICAgICA1IiBpcyBlYXN5 IGJ1dCB3ZSBuZWVkIHN5bW1ldHJ5KS4gSXQgaXMgdW5saWtlbHkgdGhhdCB3 ZSBhcmUNCiAgICAgICAgIGxvc2luZyBtdWNoIHdpdGggdGhpcyBsaW1pdGF0 aW9uIGFueXdheSAtLSBwcm90b2NvbCBvYmplY3RzDQogICAgICAgICB3b3Vs ZCByYXJlbHkgaGF2ZSBnb29kIHNlbWFudGljcyBmb3Igb3BlcmF0b3JzLg0K DQogICAgICAqICBEZWZpbmVkIHNjb3BlIHJ1bGVzIGZvciBuZXcgbmFtZXMg aW50cm9kdWNlZCBieSBhc3NpZ25tZW50cy4NCg0KDQoNCg0KQmVjayAmIFJv dXNza292ICAgICAgICAgIEV4cGlyZXMgQXByaWwgMjYsIDIwMDQgICAgICAg ICAgICAgICAgW1BhZ2UgMjZdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICBQ OiBNZXNzYWdlIFByb2Nlc3NpbmcgTGFuZ3VhZ2UgICAgICAgICBPY3RvYmVy IDIwMDMNCg0KDQogICAgICAqICBBZGRlZCBBY2tub3dsZWRnbWVudHMgc2Vj dGlvbi4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQpCZWNrICYgUm91c3Nrb3YgICAgICAgICAgRXhw aXJlcyBBcHJpbCAyNiwgMjAwNCAgICAgICAgICAgICAgICBbUGFnZSAyN10N CgwNCkludGVybmV0LURyYWZ0ICAgICAgIFA6IE1lc3NhZ2UgUHJvY2Vzc2lu ZyBMYW5ndWFnZSAgICAgICAgIE9jdG9iZXIgMjAwMw0KDQoNCk5vcm1hdGl2 ZSBSZWZlcmVuY2VzDQoNCiAgIFtSRkMyMjM0XSAgQ3JvY2tlciwgRC4gYW5k IFAuIE92ZXJlbGwsICJBdWdtZW50ZWQgQk5GIGZvciBTeW50YXgNCiAgICAg ICAgICAgICAgU3BlY2lmaWNhdGlvbnM6IEFCTkYiLCBSRkMgMjIzNCwgTm92 ZW1iZXIgMTk5Ny4NCg0KICAgW1JGQzIzOTZdICBCZXJuZXJzLUxlZSwgVC4s IEZpZWxkaW5nLCBSLiBhbmQgTC4gTWFzaW50ZXIsICJVbmlmb3JtDQogICAg ICAgICAgICAgIFJlc291cmNlIElkZW50aWZpZXJzIChVUkkpOiBHZW5lcmlj IFN5bnRheCIsIFJGQyAyMzk2LA0KICAgICAgICAgICAgICBBdWd1c3QgMTk5 OC4NCg0KICAgW0ktRC5pZXRmLW9wZXMtYXJjaGl0ZWN0dXJlXQ0KICAgICAg ICAgICAgICBCYXJiaXIsIEEuLCAiQW4gQXJjaGl0ZWN0dXJlIGZvciBPcGVu IFBsdWdnYWJsZSBFZGdlDQogICAgICAgICAgICAgIFNlcnZpY2VzIChPUEVT KSIsIGRyYWZ0LWlldGYtb3Blcy1hcmNoaXRlY3R1cmUtMDQgKHdvcmsgaW4N CiAgICAgICAgICAgICAgcHJvZ3Jlc3MpLCBEZWNlbWJlciAyMDAyLg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkJlY2sgJiBSb3Vzc2tvdiAg ICAgICAgICBFeHBpcmVzIEFwcmlsIDI2LCAyMDA0ICAgICAgICAgICAgICAg IFtQYWdlIDI4XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgUDogTWVzc2Fn ZSBQcm9jZXNzaW5nIExhbmd1YWdlICAgICAgICAgT2N0b2JlciAyMDAzDQoN Cg0KSW5mb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQogICBbUkZDMjYxNl0gIEZp ZWxkaW5nLCBSLiwgR2V0dHlzLCBKLiwgTW9ndWwsIEouLCBOaWVsc2VuLCBI LiwNCiAgICAgICAgICAgICAgTWFzaW50ZXIsIEwuLCBMZWFjaCwgUC4gYW5k IFQuIEJlcm5lcnMtTGVlLCAiSHlwZXJ0ZXh0DQogICAgICAgICAgICAgIFRy YW5zZmVyIFByb3RvY29sIC0tIEhUVFAvMS4xIiwgUkZDIDI2MTYsIEp1bmUg MTk5OS4NCg0KICAgW0ktRC5iZWNrLW9wZXMtaXJtbF0NCiAgICAgICAgICAg ICAgQmVjaywgQS4gYW5kIE0uIEhvZm1hbm4sICJJUk1MOiBBIFJ1bGUgU3Bl Y2lmaWNhdGlvbg0KICAgICAgICAgICAgICBMYW5ndWFnZSBmb3IgSW50ZXJt ZWRpYXJ5IFNlcnZpY2VzIiwNCiAgICAgICAgICAgICAgZHJhZnQtYmVjay1v cGVzLWlybWwtMDMgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBKdW5lIDIwMDMuDQoN Cg0KQXV0aG9ycycgQWRkcmVzc2VzDQoNCiAgIEFuZHJlIEJlY2sNCiAgIEx1 Y2VudCBUZWNobm9sb2dpZXMNCiAgIDEwMSBDcmF3Zm9yZHMgQ29ybmVyIFJk Lg0KICAgSG9sbWRlbCwgTkoNCiAgIFVTDQoNCiAgIFBob25lOiArMSA3MzIg MzMyLTU5ODMNCiAgIEVNYWlsOiBhYmVja0BiZWxsLWxhYnMuY29tDQoNCg0K ICAgQWxleCBSb3Vzc2tvdg0KICAgVGhlIE1lYXN1cmVtZW50IEZhY3RvcnkN Cg0KICAgRU1haWw6IHJvdXNza292QG1lYXN1cmVtZW50LWZhY3RvcnkuY29t DQogICBVUkk6ICAgaHR0cDovL3d3dy5tZWFzdXJlbWVudC1mYWN0b3J5LmNv bS8NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KQmVjayAmIFJvdXNza292ICAgICAgICAgIEV4cGlyZXMgQXByaWwgMjYs IDIwMDQgICAgICAgICAgICAgICAgW1BhZ2UgMjldDQoMDQpJbnRlcm5ldC1E cmFmdCAgICAgICBQOiBNZXNzYWdlIFByb2Nlc3NpbmcgTGFuZ3VhZ2UgICAg ICAgICBPY3RvYmVyIDIwMDMNCg0KDQpJbnRlbGxlY3R1YWwgUHJvcGVydHkg U3RhdGVtZW50DQoNCiAgIFRoZSBJRVRGIHRha2VzIG5vIHBvc2l0aW9uIHJl Z2FyZGluZyB0aGUgdmFsaWRpdHkgb3Igc2NvcGUgb2YgYW55DQogICBpbnRl bGxlY3R1YWwgcHJvcGVydHkgb3Igb3RoZXIgcmlnaHRzIHRoYXQgbWlnaHQg YmUgY2xhaW1lZCB0bw0KICAgcGVydGFpbiB0byB0aGUgaW1wbGVtZW50YXRp b24gb3IgdXNlIG9mIHRoZSB0ZWNobm9sb2d5IGRlc2NyaWJlZCBpbg0KICAg dGhpcyBkb2N1bWVudCBvciB0aGUgZXh0ZW50IHRvIHdoaWNoIGFueSBsaWNl bnNlIHVuZGVyIHN1Y2ggcmlnaHRzDQogICBtaWdodCBvciBtaWdodCBub3Qg YmUgYXZhaWxhYmxlOyBuZWl0aGVyIGRvZXMgaXQgcmVwcmVzZW50IHRoYXQg aXQNCiAgIGhhcyBtYWRlIGFueSBlZmZvcnQgdG8gaWRlbnRpZnkgYW55IHN1 Y2ggcmlnaHRzLiBJbmZvcm1hdGlvbiBvbiB0aGUNCiAgIElFVEYncyBwcm9j ZWR1cmVzIHdpdGggcmVzcGVjdCB0byByaWdodHMgaW4gc3RhbmRhcmRzLXRy YWNrIGFuZA0KICAgc3RhbmRhcmRzLXJlbGF0ZWQgZG9jdW1lbnRhdGlvbiBj YW4gYmUgZm91bmQgaW4gQkNQLTExLiBDb3BpZXMgb2YNCiAgIGNsYWltcyBv ZiByaWdodHMgbWFkZSBhdmFpbGFibGUgZm9yIHB1YmxpY2F0aW9uIGFuZCBh bnkgYXNzdXJhbmNlcyBvZg0KICAgbGljZW5zZXMgdG8gYmUgbWFkZSBhdmFp bGFibGUsIG9yIHRoZSByZXN1bHQgb2YgYW4gYXR0ZW1wdCBtYWRlIHRvDQog ICBvYnRhaW4gYSBnZW5lcmFsIGxpY2Vuc2Ugb3IgcGVybWlzc2lvbiBmb3Ig dGhlIHVzZSBvZiBzdWNoDQogICBwcm9wcmlldGFyeSByaWdodHMgYnkgaW1w bGVtZW50b3JzIG9yIHVzZXJzIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiBjYW4N CiAgIGJlIG9idGFpbmVkIGZyb20gdGhlIElFVEYgU2VjcmV0YXJpYXQuDQoN CiAgIFRoZSBJRVRGIGludml0ZXMgYW55IGludGVyZXN0ZWQgcGFydHkgdG8g YnJpbmcgdG8gaXRzIGF0dGVudGlvbiBhbnkNCiAgIGNvcHlyaWdodHMsIHBh dGVudHMgb3IgcGF0ZW50IGFwcGxpY2F0aW9ucywgb3Igb3RoZXIgcHJvcHJp ZXRhcnkNCiAgIHJpZ2h0cyB3aGljaCBtYXkgY292ZXIgdGVjaG5vbG9neSB0 aGF0IG1heSBiZSByZXF1aXJlZCB0byBwcmFjdGljZQ0KICAgdGhpcyBzdGFu ZGFyZC4gUGxlYXNlIGFkZHJlc3MgdGhlIGluZm9ybWF0aW9uIHRvIHRoZSBJ RVRGIEV4ZWN1dGl2ZQ0KICAgRGlyZWN0b3IuDQoNCg0KRnVsbCBDb3B5cmln aHQgU3RhdGVtZW50DQoNCiAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0 IFNvY2lldHkgKDIwMDMpLiBBbGwgUmlnaHRzIFJlc2VydmVkLg0KDQogICBU aGlzIGRvY3VtZW50IGFuZCB0cmFuc2xhdGlvbnMgb2YgaXQgbWF5IGJlIGNv cGllZCBhbmQgZnVybmlzaGVkIHRvDQogICBvdGhlcnMsIGFuZCBkZXJpdmF0 aXZlIHdvcmtzIHRoYXQgY29tbWVudCBvbiBvciBvdGhlcndpc2UgZXhwbGFp biBpdA0KICAgb3IgYXNzaXN0IGluIGl0cyBpbXBsZW1lbnRhdGlvbiBtYXkg YmUgcHJlcGFyZWQsIGNvcGllZCwgcHVibGlzaGVkDQogICBhbmQgZGlzdHJp YnV0ZWQsIGluIHdob2xlIG9yIGluIHBhcnQsIHdpdGhvdXQgcmVzdHJpY3Rp b24gb2YgYW55DQogICBraW5kLCBwcm92aWRlZCB0aGF0IHRoZSBhYm92ZSBj b3B5cmlnaHQgbm90aWNlIGFuZCB0aGlzIHBhcmFncmFwaCBhcmUNCiAgIGlu Y2x1ZGVkIG9uIGFsbCBzdWNoIGNvcGllcyBhbmQgZGVyaXZhdGl2ZSB3b3Jr cy4gSG93ZXZlciwgdGhpcw0KICAgZG9jdW1lbnQgaXRzZWxmIG1heSBub3Qg YmUgbW9kaWZpZWQgaW4gYW55IHdheSwgc3VjaCBhcyBieSByZW1vdmluZw0K ICAgdGhlIGNvcHlyaWdodCBub3RpY2Ugb3IgcmVmZXJlbmNlcyB0byB0aGUg SW50ZXJuZXQgU29jaWV0eSBvciBvdGhlcg0KICAgSW50ZXJuZXQgb3JnYW5p emF0aW9ucywgZXhjZXB0IGFzIG5lZWRlZCBmb3IgdGhlIHB1cnBvc2Ugb2YN CiAgIGRldmVsb3BpbmcgSW50ZXJuZXQgc3RhbmRhcmRzIGluIHdoaWNoIGNh c2UgdGhlIHByb2NlZHVyZXMgZm9yDQogICBjb3B5cmlnaHRzIGRlZmluZWQg aW4gdGhlIEludGVybmV0IFN0YW5kYXJkcyBwcm9jZXNzIG11c3QgYmUNCiAg IGZvbGxvd2VkLCBvciBhcyByZXF1aXJlZCB0byB0cmFuc2xhdGUgaXQgaW50 byBsYW5ndWFnZXMgb3RoZXIgdGhhbg0KICAgRW5nbGlzaC4NCg0KICAgVGhl IGxpbWl0ZWQgcGVybWlzc2lvbnMgZ3JhbnRlZCBhYm92ZSBhcmUgcGVycGV0 dWFsIGFuZCB3aWxsIG5vdCBiZQ0KICAgcmV2b2tlZCBieSB0aGUgSW50ZXJu ZXQgU29jaWV0eSBvciBpdHMgc3VjY2Vzc29ycyBvciBhc3NpZ25lZXMuDQoN CiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBjb250YWlu ZWQgaGVyZWluIGlzIHByb3ZpZGVkIG9uIGFuDQogICAiQVMgSVMiIGJhc2lz IGFuZCBUSEUgSU5URVJORVQgU09DSUVUWSBBTkQgVEhFIElOVEVSTkVUIEVO R0lORUVSSU5HDQogICBUQVNLIEZPUkNFIERJU0NMQUlNUyBBTEwgV0FSUkFO VElFUywgRVhQUkVTUyBPUiBJTVBMSUVELCBJTkNMVURJTkcNCiAgIEJVVCBO T1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GIFRI RSBJTkZPUk1BVElPTg0KDQoNCg0KQmVjayAmIFJvdXNza292ICAgICAgICAg IEV4cGlyZXMgQXByaWwgMjYsIDIwMDQgICAgICAgICAgICAgICAgW1BhZ2Ug MzBdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICBQOiBNZXNzYWdlIFByb2Nl c3NpbmcgTGFuZ3VhZ2UgICAgICAgICBPY3RvYmVyIDIwMDMNCg0KDQogICBI RVJFSU4gV0lMTCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1Q TElFRCBXQVJSQU5USUVTIE9GDQogICBNRVJDSEFOVEFCSUxJVFkgT1IgRklU TkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuDQoNCg0KQWNrbm93bGVk Z21lbnQNCg0KICAgRnVuZGluZyBmb3IgdGhlIFJGQyBFZGl0b3IgZnVuY3Rp b24gaXMgY3VycmVudGx5IHByb3ZpZGVkIGJ5IHRoZQ0KICAgSW50ZXJuZXQg U29jaWV0eS4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KQmVjayAmIFJvdXNza292ICAgICAgICAgIEV4cGlyZXMgQXByaWwg MjYsIDIwMDQgICAgICAgICAgICAgICAgW1BhZ2UgMzFdDQoMDQo= --0-351245835-1067257041=:53872-- From owner-ietf-openproxy@mail.imc.org Mon Oct 27 08:46: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 IAA12384 for ; Mon, 27 Oct 2003 08:46:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE7hR-00054f-00 for opes-archive@ietf.org; Mon, 27 Oct 2003 08:46:25 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AE7hQ-00054c-00 for opes-archive@ietf.org; Mon, 27 Oct 2003 08:46:24 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RDVWI7049521 for ; Mon, 27 Oct 2003 05:31:32 -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 h9RDVWt5049520 for ietf-openproxy-bks; Mon, 27 Oct 2003 05:31:32 -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 h9RDVUI7049514 for ; Mon, 27 Oct 2003 05:31:30 -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 h9RDVSnl008921 for ; Mon, 27 Oct 2003 08:31:28 -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 h9RDVM0C027946 for ; Mon, 27 Oct 2003 08:31:22 -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 h9RDVLFU016651 for ; Mon, 27 Oct 2003 08:31:22 -0500 (EST) Message-ID: <3F9D1E9B.4040505@mhof.com> Date: Mon, 27 Oct 2003 08:33:15 -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: Request To Publish: draft-ietf-opes-iab-03 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Folks, please take a very, very careful look at this version of the draft (draft-ietf-opes-iab-03). In particular, please check out the two issues marked with 'XXX') THIS IS THE FINAL DOCUMENT CANDIDATE. Please post your comments to the mailing before the IETF meeting in Minneapolis (i.e. before 11/9), so that we can close on the draft in Minneapolis and issue WGLC shortly after. I'd expect that open issues get resolved beforehand, so please check it out NOW!! Thanks, Markus Alex Rousskov wrote: > Please publish the attached draft-ietf-opes-iab-03.txt as an OPES > working group Internet Draft. > > Thank you, > > Alex. > > > ------------------------------------------------------------------------ > > > > Open Pluggable Edge Services A. Barbir > Internet-Draft Nortel Networks > Expires: April 26, 2004 A. Rousskov > The Measurement Factory > October 27, 2003 > > > OPES Treatment of IAB Considerations > draft-ietf-opes-iab-03 > > Status of this Memo > > This document is an Internet-Draft and is in full conformance with > all provisions of Section 10 of RFC2026. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that other > groups may also distribute working documents as Internet-Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at http:// > www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on April 26, 2004. > > Copyright Notice > > Copyright (C) The Internet Society (2003). All Rights Reserved. > > Abstract > > IETF Internet Architecture Board (IAB) expressed nine > architecture-level considerations for the Open Pluggable Edge > Services (OPES) framework. This document describes how OPES > addresses those considerations. > > > > > > > > > > > Barbir & Rousskov Expires April 26, 2004 [Page 1] > > Internet-Draft OPES Treatment of IAB Considerations October 2003 > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 3. Consideration (2.1) 'One-party consent' . . . . . . . . . . . 5 > 4. Consideration (2.2) 'IP-layer communications' . . . . . . . . 6 > 5. Notification Considerations . . . . . . . . . . . . . . . . . 8 > 5.1 Notification versus trace . . . . . . . . . . . . . . . . . . 8 > 5.2 An example of an OPES trace for HTTP . . . . . . . . . . . . . 9 > 5.3 Consideration (3.1) 'Notification' . . . . . . . . . . . . . . 10 > 5.4 Consideration (3.2) 'Notification' . . . . . . . . . . . . . . 12 > 6. Consideration (3.3) 'Non-blocking' . . . . . . . . . . . . . . 13 > 7. Consideration (4.1) 'URI resolution' . . . . . . . . . . . . . 14 > 8. Consideration (4.2) 'Reference validity' . . . . . . . . . . . 15 > 9. Consideration (4.3) 'Addressing extensions' . . . . . . . . . 16 > 10. Consideration (5.1) 'Privacy' . . . . . . . . . . . . . . . . 17 > 11. Consideration 'Encryption' . . . . . . . . . . . . . . . . . . 18 > 12. Security Considerations . . . . . . . . . . . . . . . . . . . 19 > 13. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 20 > A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 21 > Normative References . . . . . . . . . . . . . . . . . . . . . 23 > Informative References . . . . . . . . . . . . . . . . . . . . 24 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 > Intellectual Property and Copyright Statements . . . . . . . . 25 > > > > > > > > > > > > > > > > > > > > > > > > > > > > Barbir & Rousskov Expires April 26, 2004 [Page 2] > > Internet-Draft OPES Treatment of IAB Considerations October 2003 > > > 1. Introduction > > The Open Pluggable Edge Services (OPES) architecture > [I-D.ietf-opes-architecture], enables cooperative application > services (OPES services) between a data provider, a data consumer, > and zero or more OPES processors. The application services under > consideration analyze and possibly transform application-level > messages exchanged between the data provider and the data consumer. > > In the process of chartering OPES, the IAB made recommendations on > issues that OPES solutions should be required to address. These > recommendations were formulated in the form of a specific IAB > considerations document [RFC3238]. In that document, IAB emphasized > that its considerations did not recommend specific solutions and did > not mandate specific functional requirements. Addressing an IAB > consideration may involve showing appropriate protocol mechanisms or > demonstrating that the issue does not apply. Addressing a > consideration does not necessarily mean supporting technology implied > by the consideration wording. > > The primary goal of this document is to show that all IAB > recommendations are addressed by OPES, to the extent that those > considerations can be addressed by an IETF working group. The > limitations of OPES working group to address certain aspects of IAB > considerations are also explicitly documented. > > There are nine IAB considerations [RFC3238] that OPES has to address. > In the core of this document are the corresponding nine > "Consideration" sections. For each IAB consideration, its section > contains general discussion as well as references to specific OPES > mechanisms relevant to the consideration. > > > > > > > > > > > > > > > > > > > > > Barbir & Rousskov Expires April 26, 2004 [Page 3] > > Internet-Draft OPES Treatment of IAB Considerations October 2003 > > > 2. Terminology > > This document does not introduce any new terminology but uses > terminology from other OPES documents it quotes. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Barbir & Rousskov Expires April 26, 2004 [Page 4] > > Internet-Draft OPES Treatment of IAB Considerations October 2003 > > > 3. Consideration (2.1) 'One-party consent' > > "An OPES framework standardized in the IETF must require that the use > of any OPES service be explicitly authorized by one of the > application-layer end-hosts (that is, either the content provider or > the client)."[RFC3238] > > OPES architecture requires that "OPES processors MUST be consented to > by either the data consumer or data provider application" > [I-D.ietf-opes-architecture]. This requirement alone cannot prevent > consent-less introduction of OPES processors. In > [I-D.ietf-opes-end-comm], the OPES architecture enables concerned > parties to detect unwanted OPES processors by examining OPES traces. > The use of traces in OPES is mandatory. > > A tracing mechanism on its own cannot detect processors that are in > violation of OPES specifications. Examples include OPES processors > operating in stealth mode. However, the OPES architecture allows the > use of content signature to verify the authenticity of performed > adaptations. Content signatures is a strong but expensive mechanism > that can detect any modifications of signed content provided that the > content provider is willing to sign the data and that the client is > willing to either check the signature or relay received content to > the content provider for signature verification. > > OPES adaptations may include copying and other forms of non-modifying > access to content. These kinds of adaptations cannot be detected by > the above mentioned mechanisms. Thus, "passive" OPES processors can > operate on the content without the data consumer or provider consent. > If presence of such processors is a concern, then content encryption > can be used. A passive processor is no different from a proxy or an > intermediary operating outside of OPES framework. No OPES mechanism > (existing or foreseeable) can prevent non-modifying access to > content. > > > > > > > > > > > > > > > > > > Barbir & Rousskov Expires April 26, 2004 [Page 5] > > Internet-Draft OPES Treatment of IAB Considerations October 2003 > > > 4. Consideration (2.2) 'IP-layer communications' > > "For an OPES framework standardized in the IETF, the OPES > intermediary must be explicitly addressed at the IP layer by the end > user."[RFC3238] > > The OPES architecture requires that "OPES processors MUST be > addressable at the IP layer by the end user (data consumer > application)" [I-D.ietf-opes-architecture]. The IAB and the > architecture documents mention an important exception: addressing the > first OPES processor in a chain of processors is sufficient. That is, > a chain of OPES processors is viewed as a single OPES "system" at the > address of the first chain element. > > The notion of a chain is not strictly defined by IAB. For the purpose > of addressing this consideration, a group of OPES processors working > on a given application transaction is considered. Such a group would > necessarily form a single processing chain, with a single "exit" OPES > processor (i.e., the processor that adapted the given message last). > The OPES architecture essentially requires that last OPES processor > to be explicitly addressable at the IP layer by the data consumer > application. The chain formation, including its exit point may depend > on an application message and other dynamic factors such as time of > the day or system load. > > Furthermore, if OPES processing is an internal processing step at a > data consumer or a data provider application side, then the last OPES > processor may reside in a private address space and may not be > explicitly addressable from the outside. In such situations, the > processing side must designate an addressable point on the same > processing chain. That designated point may not be, strictly > speaking, an OPES processor, but it will suffice as such as far as > IAB considerations are concerned -- the data consumer application > will be able to address it explicitly at the IP layer and it will > represent the OPES processing chain to the outside world. > > Designating an addressable processing point avoids the conflict > between narrow interpretation of the IAB consideration and real > system designs. It is irrational to expect a content provider to > provide access to internal hosts participating in content generation, > whether OPES processors are involved or not. Moreover, providing such > access would serve little practical purpose because internal OPES > processors are not likely to be able to answer any data consumer > queries, being completely out of content generation context. For > example, an OPES processor adding customer-specific information to > XML pages may not understand or be aware of any final HTML content > that the data consumer application receives and may not be able to > map end user request to any internal user identification. Since OPES > > > > Barbir & Rousskov Expires April 26, 2004 [Page 6] > > Internet-Draft OPES Treatment of IAB Considerations October 2003 > > > requires the end of the message processing chain to be addressable, > the conflict does not exist. OPES places no requirements on the > internal architecture of data producer systems while requiring the > entire OPES-related content production "system" to be addressable at > the IP layer. > > Private Domain | Public Domain | Private Domain > | | > +--------------+ | +-------------+ +--------+ > | Data | | | OPES System | |Data | > | Consumer |<--- network -->| with public |<---->|Provider| > | Application | | | IP address | |App | > +--------------+ | +-------------+ +--------+ > | | > | | > > Figure 1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Barbir & Rousskov Expires April 26, 2004 [Page 7] > > Internet-Draft OPES Treatment of IAB Considerations October 2003 > > > 5. Notification Considerations > > This section discusses how OPES framework addresses IAB Notification > considerations 3.1 and 3.2. > > 5.1 Notification versus trace > > Before specific considerations are discussed, the relationship > between IAB notifications and OPES tracing has to be explained. OPES > framework concentrates on tracing rather than notification. The OPES > Communications specification [I-D.ietf-opes-end-comm] defines "OPES > trace" as information about OPES adaptations that is embedded in an > application message. Thus, OPES trace follows the application message > it traces. The trace is for the recipient of the application message. > Traces are implemented as extensions of application protocols being > adapted and traced. > > As opposed to an OPES trace, provider notification (as implied by > IAB) notifies the sender of the application message rather than the > recipient. Thus, notifications propagate in the opposite direction of > traces. Supporting notifications directly would require a new > protocol. Figure 2 illustrates the differences between a trace and > notification from a single application message point of view. > sender --[message A]--> OPES --[message A']--> recipient > ^ V [with trace] > | | > +-<-- [notification] ---+ > > Figure 2 > > Since notifications cannot be piggy-backed to application messages, > they create new messages and may double the number of messages the > sender has to process. The number of messages that need to be proceed > is larger if several intermediaries on the message path generate > notifications). Associating notifications with application messages > may require duplicating application message information in > notifications and may require maintaining a sender state until > notification is received. These actions increase the performance > overhead of notifications. > > The level of available details in notifications versus provider > interest in supporting notification is another concern. Experience > shows that content providers often require very detailed information > about user actions to be interested in notifications at all. For > example, Hit Metering protocol [RFC2227] has been designed to supply > content providers with proxy cache hit counts, in an effort to reduce > cache busting behavior which was caused by content providers desire > to get accurate site "access counts". However, the Hit Metering > > > > Barbir & Rousskov Expires April 26, 2004 [Page 8] > > Internet-Draft OPES Treatment of IAB Considerations October 2003 > > > protocol is currently not widely deployed because the protocol does > not supply content providers with information such as client IP > addresses, browser versions, or cookies. > > Hit Metering experience is relevant because Hit Metering protocol was > designed to do for HTTP caching intermediaries what OPES > notifications are meant to do for OPES intermediaries. Performance > requirements call for state reduction via aggregation of > notifications while provider preferences call for state preservation > or duplication. Achieving the right balance when two sides belong to > different organizations and have different optimization priorities > may be impossible. > > Thus, instead of explicitly supporting notifications at the protocol > level, OPES concentrates on tracing facilities. In essence, OPES > supports notifications indirectly, using tracing facilities. In other > words, the IAB choice of "Notification" label is interpreted as > "Notification assistance" (i.e. making notifications meaningful) and > is not interpreted as a "Notification protocol". > > The above concerns call for making notification optional. The OPES > architecture allows for an efficient and meaningful notification > protocol to be implemented in certain OPES environments. For > specific examples, see the "Optional Notification" section in > [I-D.ietf-opes-end-comm]. > > 5.2 An example of an OPES trace for HTTP > > The example below illustrates adaptations done to HTTP request at an > OPES processor operated by the client ISP. Both original (as sent by > an end user) and adapted (as received by the origin web server) > requests are shown. The primary adaptation is the modification of > HTTP "Accept" header. The secondary adaptation is the addition of an > "OPES-Via" HTTP extension header [I-D.ietf-opes-http] (XXX: but it is > not OPES-Via, it is OPES-System for now; OPES-Via is probably better > for a few reasons though). > > GET /pub/WWW/ HTTP/1.1 > Host: www.w3.org > Accept: text/plain > > Figure 3 > > ... may be adapted by an ISP OPES system to become: > > GET /pub/WWW/ HTTP/1.1 > Host: www.w3.org > Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8 > > > > Barbir & Rousskov Expires April 26, 2004 [Page 9] > > Internet-Draft OPES Treatment of IAB Considerations October 2003 > > > OPES-Via: http://www.isp-example.com/opes/?client-hash=1234567 > > Figure 4 > > The example below illustrates adaptations done to HTTP response at an > OPES intermediary operated by a Content Distribution Network (CDN). > Both original (as sent by the origin web server) and adapted (as > received by the end user) responses are shown. The primary adaptation > is the conversion from HTML markup to plain text. The secondary > adaptation is the addition of an "OPES-Via" HTTP extension header. > > HTTP/1.1 200 OK > Content-Length: 12345 > Content-Encoding: text/html > >

Available Documenta... > > Figure 5 > > ... may be adapted by a CDN OPES system to become: > > HTTP/1.1 200 OK > Content-Length: 2345 > Content-Encoding: text/plain > OPES-Via: http://www.cdn-example.com/opes/?site=7654321&service=h2t > > AVAILABLE DOCUMENTA... > > Figure 6 > > In the above examples, "OPES-Via" header values contain URLs that may > point to OPES-specific documents such as description of the OPES > operator and its privacy policy. Those documents may be > parameterized to allow for customizations specific to the transaction > being traced (e.g., client or even transaction identifier may be used > to provide more information about performed adaptations). Traced OPES > URLs may be later used to request OPES bypass > [I-D.ietf-opes-end-comm]. > > 5.3 Consideration (3.1) 'Notification' > > "The overall OPES framework needs to assist content providers in > detecting and responding to client-centric actions by OPES > intermediaries that are deemed inappropriate by the content > provider."[RFC3238] > > OPES tracing mechanisms assist content providers in detecting > client-centric actions by OPES intermediaries. Specifically, a > > > > Barbir & Rousskov Expires April 26, 2004 [Page 10] > > Internet-Draft OPES Treatment of IAB Considerations October 2003 > > > compliant OPES intermediary or system notifies a content provider of > its presence by including its tracing information in the application > protocol requests. An OPES system MUST leave its trace > [I-D.ietf-opes-end-comm]. Detection assistance has its limitations. > Some OPES intermediaries may work exclusively on responses and may > not have a chance to trace the request. Moreover, some application > protocols may not have explicit requests (e.g., a content push > service). > > OPES tracing mechanisms assist content providers in responding to > client-centric actions by OPES intermediaries. Specifically, OPES > traces MUST include identification of OPES systems and SHOULD include > a list of adaptation actions performed on provider's content. This > tracing information may be included in the application request. > Usually, however, this information will be included in the > application response, an adapted version of which does not reach the > content provider. If OPES end points cooperate, then notification can > be assisted with traces. Content providers that suspect or experience > difficulties can do any of the following: > > o Check whether requests they receive pass through OPES > intermediaries. Presence of OPES tracing info will determine that. > This check is only possible for request/response protocols. For > other protocols (e.g., broadcast or push), the provider would have > to assume that OPES intermediaries are involved until proven > otherwise. > > o If OPES intermediaries are suspected, request OPES traces from > potentially affected user(s). The trace will be a part of the > application message received by the user software. If involved > parties cooperate, the provider(s) may have access to all the > needed information. Certainly, lack of cooperation may hinder > access to tracing information. To encourage cooperation, data > providers might be able to deny service to uncooperative users. > > o Some traces may indicate that more information is available by > accessing certain resources on the specified OPES intermediary or > elsewhere. Content providers may query for more information in > this case. > > o If everything else fails, providers can enforce no-adaptation > policy using appropriate OPES bypass mechanisms and/or end-to-end > encryption mechanisms. > > OPES detection and response assistance is limited to application > protocols with support for tracing extensions. For example, HTTP > [RFC2616] has such support while DNS over UDP does not. > > > > > Barbir & Rousskov Expires April 26, 2004 [Page 11] > > Internet-Draft OPES Treatment of IAB Considerations October 2003 > > > 5.4 Consideration (3.2) 'Notification' > > "The overall OPES framework should assist end users in detecting the > behavior of OPES intermediaries, potentially allowing them to > identify imperfect or compromised intermediaries."[RFC3238] > > OPES tracing mechanisms assist end users in detecting OPES > intermediaries. Specifically, a compliant OPES intermediary or system > notifies an end user of its presence by including its tracing > information in the application protocol messages sent to the client. > An OPES system MUST leave its trace [I-D.ietf-opes-end-comm]. > However, detection assistance has its limitations. Some OPES systems > may work exclusively on requests and may not have a chance to trace > the response. Moreover, some application protocols may not have > explicit responses (e.g., event logging service). > > OPES detection assistance is limited to application protocols with > support for tracing extensions. For example, HTTP [RFC2616] has such > support while DNS over UDP does not. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Barbir & Rousskov Expires April 26, 2004 [Page 12] > > Internet-Draft OPES Treatment of IAB Considerations October 2003 > > > 6. Consideration (3.3) 'Non-blocking' > > "If there exists a "non-OPES" version of content available from the > content provider, the OPES architecture must not prevent users from > retrieving this "non-OPES" version from the content > provider."[RFC3238] > > "OPES entities MUST support a bypass feature" > [I-D.ietf-opes-end-comm]. If an application message includes bypass > instructions and an OPES intermediary is not configured to ignore > them, the matching OPES intermediary will not process the message. An > OPES intermediary may be configured to ignore bypass instructions > only if no non-OPES version of content is available. Bypass may > generate content errors since some OPES services may be essential but > may not be configured as such. > > Bypass support has limitations similar to the two > notification-related considerations above. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Barbir & Rousskov Expires April 26, 2004 [Page 13] > > Internet-Draft OPES Treatment of IAB Considerations October 2003 > > > 7. Consideration (4.1) 'URI resolution' > > "OPES documentation must be clear in describing these services as > being applied to the result of URI resolution, not as URI resolution > itself."[RFC3238] > > "OPES Scenarios and Use Cases" specification > [I-D.ietf-opes-scenarios] documents content adaptations that are in > scope of the OPES framework. Scenarios include adaptations of > requests and responses. These adaptations do not include URI > resolution adaptations. In some environments, it is technically > possible to adapt URIs (and other kinds of identifiers or addresses) > using documented OPES mechanisms. The OPES framework cannot > effectively prohibit any specific adaptations. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Barbir & Rousskov Expires April 26, 2004 [Page 14] > > Internet-Draft OPES Treatment of IAB Considerations October 2003 > > > 8. Consideration (4.2) 'Reference validity' > > "All proposed services must define their impact on inter- and > intra-document reference validity."[RFC3238] > > The OPES framework does not propose adaptation services. However, > OPES tracing requirements include identification of OPES > intermediaries and services (for details, see "Notification" > consideration sections in this document). It is required that > provided identification can be used to locate information about the > OPES intermediaries, including the description of impact on reference > validity [I-D.ietf-opes-end-comm] (XXX: check tracing draft for this > requirement). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Barbir & Rousskov Expires April 26, 2004 [Page 15] > > Internet-Draft OPES Treatment of IAB Considerations October 2003 > > > 9. Consideration (4.3) 'Addressing extensions' > > "Any services that cannot be achieved while respecting the above two > considerations may be reviewed as potential requirements for Internet > application addressing architecture extensions, but must not be > undertaken as ad hoc fixes."[RFC3238] > > OPES framework does not contain ad hoc fixes. This document in > combination with and other OPES documents should be sufficient to > inform service creators of IAB considerations. If a service does URI > resolution or silently affects document reference validity, the > authors are requested to review service impact on Internet > application addressing architecture and work within IETF on potential > extension requirements. Such actions would be outside of the current > OPES framework. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Barbir & Rousskov Expires April 26, 2004 [Page 16] > > Internet-Draft OPES Treatment of IAB Considerations October 2003 > > > 10. Consideration (5.1) 'Privacy' > > "The overall OPES framework must provide for mechanisms for end users > to determine the privacy policies of OPES intermediaries."[RFC3238] > > OPES tracing mechanisms allow end users to identify OPES > intermediaries (for details, see "Notification" consideration > sections in this document). It is required that provided > identification can be used to locate information about the OPES > intermediaries, including their privacy policies. > > The term "privacy policy" is not defined in this context (by IAB or > OPES working group). OPES tracing mechanisms allow end users and > content providers to identify an OPES system and/or intermediaries. > It is believed that once an OPES system is identified, it would be > possible to locate relevant information about that system, including > information relevant to requesters perception of privacy policy or > reference validity. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Barbir & Rousskov Expires April 26, 2004 [Page 17] > > Internet-Draft OPES Treatment of IAB Considerations October 2003 > > > 11. Consideration 'Encryption' > > "If OPES is chartered, the OPES working group will also have to > explicitly decide and document whether the OPES architecture must be > compatible with the use of end-to-end encryption by one or more ends > of an OPES-involved session. If OPES was compatible with end-to-end > encryption, this would effectively ensure that OPES boxes would be > restricted to ones that are known, trusted, explicitly addressed at > the IP layer, and authorized (by the provision of decryption keys) by > at least one of the ends."[RFC3238] > > The above quoted requirement was not explicitly listed as on of the > IAB considerations, but still needs to be addressed. The context of > the quote implies that the phrase "end-to-end encryption" refers to > encryption along all links of the end-to-end path, with the OPES > intermediaries as encrypting/decrypting participants or hops (e.g., > encryption between the provider and the OPES intermediaries, and > between the OPES intermediaries and the client). > > Since OPES processors are regular hops on the application protocol > path, OPES architecture allows for such encryption, provided the > application protocol being adapted supports it. Hop-by-hop encryption > would do little good for the overall application message path > protection if callout services have to receive unencrypted content. > To allow for complete link encryption coverage, OPES callout protocol > (OCP) supports encryption of OCP connections between an OPES > processor and a callout server via optional (negotiated) transport > encryption mechanisms [I-D.ietf-opes-ocp-core]. > > For example, TLS encryption [RFC2817] can be used among HTTP hops > (some of which could be OPES processors) and between each OPES > processor and a callout server. > > > > > > > > > > > > > > > > > > > > Barbir & Rousskov Expires April 26, 2004 [Page 18] > > Internet-Draft OPES Treatment of IAB Considerations October 2003 > > > 12. Security Considerations > > This document does not define any mechanisms that may be subject to > security considerations. Security considerations for OPES mechanisms > are discussed in corresponding OPES framework documents. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Barbir & Rousskov Expires April 26, 2004 [Page 19] > > Internet-Draft OPES Treatment of IAB Considerations October 2003 > > > 13. Compliance > > This document may be perceived as a proof of OPES compliance with IAB > implied recommendations. However, this document does not introduce > any compliance subjects. Compliance of OPES implementations is > defined in other OPES documents discussed above. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Barbir & Rousskov Expires April 26, 2004 [Page 20] > > Internet-Draft OPES Treatment of IAB Considerations October 2003 > > > Appendix A. Change Log > > Internal WG revision control ID: $Id: iab-cons.xml,v 1.26 2003/10/27 > 11:40:33 rousskov Exp $ > > 2003/10/24 > > * Addressed hop-by-hop encryption concerns mentioned in the IAB > draft. > > * Polished IP addressing figure. > > * Removed resolved XXXs. > > 2003/10/01 > > * Polishing (Abbie Barbir). > > 2003/09/23 > > * Added a reference to Optional Notification section of the > ietf-opes-end-comm draft. > > * Fixed "Consideration (3.3) Non-blocking" section position. > > head-sid15 > > * Added a figure showing a chain of internal OPES intermediaries > behind a public IP address. Needs more work. More cases? > > head-sid14 > > * Rewrote the Introduction to the IP addressing consideration. > Do NOT explain how IAB considerations, if interpreted literary, > do not satisfy important real-world constraints. Instead, use > the "chain of OPES intermediaries" exception introduced by IAB > itself to show that OPES architecture addresses IAB concerns as > long as the "chain" is defined/formed for a given application > message rather than being a statically configured application > routing table of sorts. IAB had to add the "chain" exception to > cover one of the most obvious real-world usage scenario. We use > the very same exception to cover all usage scenarios we care > about. > > * Polished text explaining the differences between tracing and > notification mechanisms. > > * Added examples of OPES/HTTP traces. > > > > Barbir & Rousskov Expires April 26, 2004 [Page 21] > > Internet-Draft OPES Treatment of IAB Considerations October 2003 > > > * Be careful not to imply that all OPES intermediaries must obey > bypass instructions. Bypass should be ignored when no non-OPES > version of the content exists. Ideally, this may need to be > polished further -- if there is no non-OPES version of the > content, most IAB considerations probably do not apply because > there is really no adaptation, only creation of content (and we > should not restrict content creation). > > * Added references to OPES "Communications" draft > [I-D.ietf-opes-end-comm]. > > head-sid9 > > * Polished to meet new xml2rfc strict requirements. > > head-sid8 > > * Added unpolished meat for all nine considerations. > > * Added Abbie Barbir as an author. > > head-sid7 > > * Initial revision > > > > > > > > > > > > > > > > > > > > > > > > > > > > Barbir & Rousskov Expires April 26, 2004 [Page 22] > > Internet-Draft OPES Treatment of IAB Considerations October 2003 > > > Normative References > > [I-D.ietf-opes-end-comm] > Barbir, A., "OPES processor and end points > communications", draft-ietf-opes-end-comm-04 (work in > progress), October 2003. > > [I-D.ietf-opes-architecture] > Barbir, A., "An Architecture for Open Pluggable Edge > Services (OPES)", draft-ietf-opes-architecture-04 (work in > progress), December 2002. > > [I-D.ietf-opes-scenarios] > Barbir, A., "OPES Use Cases and Deployment Scenarios", > draft-ietf-opes-scenarios-01 (work in progress), August > 2002. > > [RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy > Considerations for Open Pluggable Edge Services", RFC > 3238, January 2002. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Barbir & Rousskov Expires April 26, 2004 [Page 23] > > Internet-Draft OPES Treatment of IAB Considerations October 2003 > > > Informative References > > [RFC2227] Mogul, J. and P. Leach, "Simple Hit-Metering and > Usage-Limiting for HTTP", RFC 2227, October 1997. > > [RFC2616] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., > Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext > Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. > > [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/ > 1.1", RFC 2817, May 2000. > > [I-D.ietf-opes-http] > Rousskov, A. and M. Stecher, "HTTP adaptation with OPES", > draft-ietf-opes-http-00 (work in progress), August 2003. > > [I-D.ietf-opes-ocp-core] > Rousskov, A., "OPES Callout Protocol Core", > draft-ietf-opes-ocp-core-01 (work in progress), August > 2003. > > > Authors' Addresses > > Abbie Barbir > Nortel Networks > 3500 Carling Avenue > Nepean, Ontario > CA > > Phone: +1 613 763 5229 > EMail: abbieb@nortelnetworks.com > > > Alex Rousskov > The Measurement Factory > > EMail: rousskov@measurement-factory.com > URI: http://www.measurement-factory.com/ > > > > > > > > > > > > > Barbir & Rousskov Expires April 26, 2004 [Page 24] > > Internet-Draft OPES Treatment of IAB Considerations October 2003 > > > Intellectual Property Statement > > The IETF takes no position regarding the validity or scope of any > intellectual property or other rights that might be claimed to > pertain to the implementation or use of the technology described in > this document or the extent to which any license under such rights > might or might not be available; neither does it represent that it > has made any effort to identify any such rights. Information on the > IETF's procedures with respect to rights in standards-track and > standards-related documentation can be found in BCP-11. Copies of > claims of rights made available for publication and any assurances of > licenses to be made available, or the result of an attempt made to > obtain a general license or permission for the use of such > proprietary rights by implementors or users of this specification can > be obtained from the IETF Secretariat. > > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary > rights which may cover technology that may be required to practice > this standard. Please address the information to the IETF Executive > Director. > > > Full Copyright Statement > > Copyright (C) The Internet Society (2003). All Rights Reserved. > > This document and translations of it may be copied and furnished to > others, and derivative works that comment on or otherwise explain it > or assist in its implementation may be prepared, copied, published > and distributed, in whole or in part, without restriction of any > kind, provided that the above copyright notice and this paragraph are > included on all such copies and derivative works. However, this > document itself may not be modified in any way, such as by removing > the copyright notice or references to the Internet Society or other > Internet organizations, except as needed for the purpose of > developing Internet standards in which case the procedures for > copyrights defined in the Internet Standards process must be > followed, or as required to translate it into languages other than > English. > > The limited permissions granted above are perpetual and will not be > revoked by the Internet Society or its successors or assignees. > > This document and the information contained herein is provided on an > "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING > TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING > BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION > > > > Barbir & Rousskov Expires April 26, 2004 [Page 25] > > Internet-Draft OPES Treatment of IAB Considerations October 2003 > > > HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF > MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > Acknowledgment > > Funding for the RFC Editor function is currently provided by the > Internet Society. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Barbir & Rousskov Expires April 26, 2004 [Page 26] > From owner-ietf-openproxy@mail.imc.org Mon Oct 27 16:52: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 QAA16245 for ; Mon, 27 Oct 2003 16:52:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEFIT-0006Fu-00 for opes-archive@ietf.org; Mon, 27 Oct 2003 16:53:09 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AEFIS-0006Fr-00 for opes-archive@ietf.org; Mon, 27 Oct 2003 16:53: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 h9RLfiI7076046 for ; Mon, 27 Oct 2003 13:41: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 h9RLfiPV076045 for ietf-openproxy-bks; Mon, 27 Oct 2003 13:41:44 -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 h9RLfhI7076040 for ; Mon, 27 Oct 2003 13:41:43 -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 h9RLfjGh067955 for ; Mon, 27 Oct 2003 14:41:45 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9RLfjKI067954; Mon, 27 Oct 2003 14:41:45 -0700 (MST) (envelope-from rousskov) Date: Mon, 27 Oct 2003 14:41:45 -0700 (MST) From: Alex Rousskov To: OPES WG Subject: P: single assignment semantics Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'd like to discuss a problem with assignment semantics in P. I am curious what specific solutions other languages in similar domains, including IRML, provide (if any). IIRC, Geetha Manjunath spotted an important issue with P: Current draft says that assignment is, essentially a macro. The value of a name is a value of an expression and the time of use, not at the time of assignment: name := foo(bar); if (name) { // A } ... if (not name) { // B } Using the macro semantics, both A and B code pieces may be executed if foo(bar) changes its value between the two if-statements. This macro semantics allows for simple and/or efficient implementation. The interpreter (in a broad sense) does not have to keep the value of foo(bar) around between the if-statements. If that value is large (e.g., a response body) such optimizations could be crucial. On the other hand, macros are confusing for programmers, especially because it is often difficult to know whether the named expression can be changed. Assume, for example, that name is a response body-dependent expression and code A above executes a callout service on the response headers. By the time the service call completes, the processor may read a few more chunks of that response body and the value of the named expression can change. A simpler example would be: current_time := Time.now(); // interpreted in the morning ... if (current_time.isEvening()) { // can this become true? ... } A different option (let's call it "immediate constant assignment") exists: We can require the value of the expression at the time of the assignment to be stored under the provided name and never change. This means that some unused expressions would be computed and [very] large values would have to be stored. A yet another option (let's call it "lazy constant assignment") exists: We can require the value of the expression at the time of the first use (rather than first assignment) to be stored under the provided name and never change after that. This option has an advantage over immediate constant assignment in that unused expressions are not evaluated, but it still has to store [very] large values if an expression is used more than once. While IRML does not have assignments, it does evaluate expressions. I wonder if there is an implicit or explicit guarantee that the same property is evaluated to the same value before and after a delay (such as service execution). Does IRML assume that all properties are known and "constant" just before the script is interpreted? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Tue Oct 28 09:42:25 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25192 for ; Tue, 28 Oct 2003 09:42:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEV3K-0004JO-00 for opes-archive@ietf.org; Tue, 28 Oct 2003 09:42:35 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AEV3J-0004Ie-00 for opes-archive@ietf.org; Tue, 28 Oct 2003 09:42: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 h9SEQBI7083787 for ; Tue, 28 Oct 2003 06:26:11 -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 h9SEQBC5083786 for ietf-openproxy-bks; Tue, 28 Oct 2003 06:26:11 -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 h9SEQ9I7083780 for ; Tue, 28 Oct 2003 06:26:10 -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 JAA23045; Tue, 28 Oct 2003 09:25:59 -0500 (EST) Message-Id: <200310281425.JAA23045@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-02.txt Date: Tue, 28 Oct 2003 09:25:58 -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-02.txt Pages : 64 Date : 2003-10-27 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-02.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-02.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-02.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-10-28094606.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-opes-ocp-core-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-opes-ocp-core-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28094606.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-openproxy@mail.imc.org Tue Oct 28 09:43: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 JAA25269 for ; Tue, 28 Oct 2003 09:43:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEV4T-0004LR-00 for opes-archive@ietf.org; Tue, 28 Oct 2003 09:43:45 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AEV4S-0004LN-00 for opes-archive@ietf.org; Tue, 28 Oct 2003 09:43:44 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SEQGI7083814 for ; Tue, 28 Oct 2003 06:26: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 h9SEQGSW083813 for ietf-openproxy-bks; Tue, 28 Oct 2003 06:26:16 -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 h9SEQEI7083796 for ; Tue, 28 Oct 2003 06:26:15 -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 JAA23059; Tue, 28 Oct 2003 09:26:04 -0500 (EST) Message-Id: <200310281426.JAA23059@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-rules-p-02.txt Date: Tue, 28 Oct 2003 09:26:04 -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 : P: Message Processing Language Author(s) : A. Beck, A. Rousskov Filename : draft-ietf-opes-rules-p-02.txt Pages : 30 Date : 2003-10-27 P is a simple configuration language designed for specification of message processing instructions at application proxies. P can be used to instruct an intermediary how to manipulate the application message being proxied. Such instructions are needed in an Open Pluggable Edge Services (OPES) context. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opes-rules-p-02.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-rules-p-02.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-rules-p-02.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-10-28094634.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-opes-rules-p-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-opes-rules-p-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28094634.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-openproxy@mail.imc.org Tue Oct 28 11:29: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 LAA05877 for ; Tue, 28 Oct 2003 11:29:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEWjE-0000GZ-00 for opes-archive@ietf.org; Tue, 28 Oct 2003 11:29:56 -0500 Received: from sausage.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AEWhn-0007lv-00 for opes-archive@ietf.org; Tue, 28 Oct 2003 11:28:27 -0500 Received: from above.proper.com ([208.184.76.39]) by manatick with esmtp (Exim 4.24) id 1AEWBg-00088q-DP for opes-archive@ietf.org; Tue, 28 Oct 2003 10:55: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 h9SFhVI7088215 for ; Tue, 28 Oct 2003 07:43: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 h9SFhVoi088214 for ietf-openproxy-bks; Tue, 28 Oct 2003 07:43:31 -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 h9SFhUI7088209 for ; Tue, 28 Oct 2003 07:43:30 -0800 (PST) (envelope-from abeck@bell-labs.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id h9SFhUnl021669; Tue, 28 Oct 2003 10:43:30 -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 h9SFhNJl041075; Tue, 28 Oct 2003 10:43:24 -0500 (EST) Received: from bell-labs.com (abeck-hopc [135.180.240.202]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h9SFhNFU024743; Tue, 28 Oct 2003 10:43:23 -0500 (EST) Message-ID: <3F9E8E92.4010907@bell-labs.com> Date: Tue, 28 Oct 2003 10:43:14 -0500 From: Andre Beck User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Rousskov CC: OPES WG Subject: Re: P: single assignment semantics 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: > While IRML does not have assignments, it does evaluate expressions. I > wonder if there is an implicit or explicit guarantee that the same > property is evaluated to the same value before and after a delay (such > as service execution). Does IRML assume that all properties are known > and "constant" just before the script is interpreted? In the current IRML draft we require that IRML interpreters re-evaluate rule conditions and the referenced message property values after each service execution. As you pointed out, message properties and in particular message header values can change as a result of service executions. A content adaptation service, for example, may modify the content type and subsequent service operations may not make sense any more once the content type of a message has changed. So I don't believe we can assume that all properties are constant while we evaluate a set of rules for a given message. On the other hand, such a requirement would rule out certain performance optimizations. When we discussed this issue a while ago, somebody proposed to divide OPES services into those that may modify message header values (e.g. a content adaptation service) and those that won't (e.g. a logging service) and optimize the rule processing based on this knowledge. -Andre From owner-ietf-openproxy@mail.imc.org Tue Oct 28 12:12:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09016 for ; Tue, 28 Oct 2003 12:12:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEXO6-0001Yf-00 for opes-archive@ietf.org; Tue, 28 Oct 2003 12:12:10 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AEXO6-0001YA-00 for opes-archive@ietf.org; Tue, 28 Oct 2003 12:12: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 h9SH0HI7094251 for ; Tue, 28 Oct 2003 09:00:17 -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 h9SH0HEr094249 for ietf-openproxy-bks; Tue, 28 Oct 2003 09:00:17 -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 h9SH0FI7094239 for ; Tue, 28 Oct 2003 09:00:15 -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 h9SH0DGh094425; Tue, 28 Oct 2003 10:00:13 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9SH0Dh8094424; Tue, 28 Oct 2003 10:00:13 -0700 (MST) (envelope-from rousskov) Date: Tue, 28 Oct 2003 10:00:13 -0700 (MST) From: Alex Rousskov To: OPES WG Subject: Re: P: single assignment semantics In-Reply-To: <3F9E8E92.4010907@bell-labs.com> Message-ID: References: <3F9E8E92.4010907@bell-labs.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, 28 Oct 2003, Andre Beck wrote: > In the current IRML draft we require that IRML interpreters re-evaluate > rule conditions and the referenced message property values after each > service execution. Re-evaluation is essentially a loop, right? Does this re-evaluation open a possibility for an infinite loop? How can we be sure that both of the cases below are covered: - a service that needs to be applied more than once (e.g., after each header X change) is applied as many times as necessary - a [misconfigured] set of rules does not lead to infinite loops Should we simply rely on timeouts and other external measures to break loops? Or should we try to prevent loops on a language level? Or am I seeing loops when none exist? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Tue Oct 28 14:24:15 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17963 for ; Tue, 28 Oct 2003 14:24:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEZS5-0004vu-00 for opes-archive@ietf.org; Tue, 28 Oct 2003 14:24:25 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AEZS4-0004vn-00 for opes-archive@ietf.org; Tue, 28 Oct 2003 14:24:24 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SJDDI7099938 for ; Tue, 28 Oct 2003 11:13: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 h9SJDDgh099937 for ietf-openproxy-bks; Tue, 28 Oct 2003 11:13:13 -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 h9SJDBI7099930 for ; Tue, 28 Oct 2003 11:13:13 -0800 (PST) (envelope-from abeck@bell-labs.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id h9SJDDfO025596 for ; Tue, 28 Oct 2003 14:13:13 -0500 (EST) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h9SJD6Jl061749 for ; Tue, 28 Oct 2003 14:13:06 -0500 (EST) Received: from bell-labs.com (abeck-hopc [135.180.240.202]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h9SJD6FU002585 for ; Tue, 28 Oct 2003 14:13:06 -0500 (EST) Message-ID: <3F9EBF98.8030005@bell-labs.com> Date: Tue, 28 Oct 2003 14:12:24 -0500 From: Andre Beck User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES WG Subject: Re: P: single assignment semantics References: <3F9E8E92.4010907@bell-labs.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: > Should we simply rely on timeouts and other external measures to break > loops? Or should we try to prevent loops on a language level? Or am I > seeing loops when none exist? I think the latter is the case. ;-) At least IRML does not allow such loops. When I talked about the re-evaluation of rule conditions I did not mean that a single rule can or should be evaluated more than once for a given message. Rather what I meant was that if the same message property is referenced in two different rules, then the rule processor must not assume that the property value will be the same for both rules. I don't think it's a good idea to get into the business of loops and loop prevention by allowing the rule processor to evaluate a rule a second time if a message propery value changes. In fact, I think such behavior would potentially lead to very unintended results because the order in which rules (and services for that matter) are processed can make a big difference. The order in which rules are processed should be determined before they are evaluatated. -Andre From owner-ietf-openproxy@mail.imc.org Tue Oct 28 15:51: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 PAA26101 for ; Tue, 28 Oct 2003 15:51:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEaoT-0006u6-00 for opes-archive@ietf.org; Tue, 28 Oct 2003 15:51:37 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AEaoS-0006tw-00 for opes-archive@ietf.org; Tue, 28 Oct 2003 15:51: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 h9SKcsI7003714 for ; Tue, 28 Oct 2003 12:38: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 h9SKcsAD003713 for ietf-openproxy-bks; Tue, 28 Oct 2003 12:38: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 h9SKcqI7003708 for ; Tue, 28 Oct 2003 12:38: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 h9SKcpGh000666; Tue, 28 Oct 2003 13:38: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 h9SKcpSx000665; Tue, 28 Oct 2003 13:38:51 -0700 (MST) (envelope-from rousskov) Date: Tue, 28 Oct 2003 13:38:50 -0700 (MST) From: Alex Rousskov To: OPES WG Subject: Re: P: single assignment semantics In-Reply-To: <3F9EBF98.8030005@bell-labs.com> Message-ID: References: <3F9E8E92.4010907@bell-labs.com> <3F9EBF98.8030005@bell-labs.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, 28 Oct 2003, Andre Beck wrote: > I think the latter is the case. ;-) At least IRML does not allow > such loops. When I talked about the re-evaluation of rule conditions > I did not mean that a single rule can or should be evaluated more > than once for a given message. Rather what I meant was that if the > same message property is referenced in two different rules, then the > rule processor must not assume that the property value will be the > same for both rules. Ah, I see. In P, since it has variables, the same caveat becomes even more confusing for rule writers, I think. In IRML, the rule writer should assume that every external property may change between service invocations (at least). In P, the rule writer may have to assume that even local variables change between service invocations (at least). It would be nice to either avoid variable changes or at least make them less transparent. In your opinion, what is more important: - optimizing performance when storing potentially large expression values in a variable - optimizing programmer understanding when using variables (i.e., making the interface more natural so that programmer's expectations match reality) I wonder if it make sense to offload the above decision to programmer? We could give rule writers explicit control over macro-versus-constant choice by introducing references (parameter-less macros) in addition to constant variables. For example, /* no performance penalty, natural/expected results */ constant name := small_value; /* no performance penalty, possibly confusing results */ reference name := huge_value; /* no performance penalty, possibly confusing results */ reference name := small_value; /* performance penalty, natural/expected results */ constant name := huge_value; What do you think? Is it worth the trouble supporting the above interface? Or should we make this decision for the programmer, in P Core? Or would it be possible to delegate the decision to module writers, like I proposed for string case sensitivity support? Each object would be either copied or referenced, depending on objects type, as defined by object creator (a module): /* no performance penalty, natural/expected results */ name := small_object.cheap_operation(small_value) /* no performance penalty, possibly confusing results */ /* copy small_* and cheap_operation, */ /* reference huge_object and expensive_operation */ name := huge_object.cheap_operation(small_value); name := huge_object.expensive_operation(small_value); name := huge_object.expensive_operation(huge_value); name := small_object.expensive_operation(small_value); name := small_object.expensive_operation(huge_value); ... The latter approach puts the optimization burden on module writers, which is good. Should we combine the two: /* rely on expression's module(s) to copy or reference */ name := expression; /* force copying: performance penalty but expected results */ constant name := expression; Comments? Better ideas? > I don't think it's a good idea to get into the business of loops and > loop prevention by allowing the rule processor to evaluate a rule a > second time if a message propery value changes. In fact, I think > such behavior would potentially lead to very unintended results > because the order in which rules (and services for that matter) are > processed can make a big difference. The order in which rules are > processed should be determined before they are evaluatated. I agree. Alex. From owner-ietf-openproxy@mail.imc.org Tue Oct 28 15:55: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 PAA26236 for ; Tue, 28 Oct 2003 15:55:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEasf-0006wX-00 for opes-archive@ietf.org; Tue, 28 Oct 2003 15:55:57 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AEase-0006wU-00 for opes-archive@ietf.org; Tue, 28 Oct 2003 15:55: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 h9SKhsI7004046 for ; Tue, 28 Oct 2003 12:43: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 h9SKhsHs004045 for ietf-openproxy-bks; Tue, 28 Oct 2003 12:43:54 -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 h9SKhpI7004038 for ; Tue, 28 Oct 2003 12:43:53 -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 PAA25259; Tue, 28 Oct 2003 15:43:42 -0500 (EST) Message-Id: <200310282043.PAA25259@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-http-01.txt Date: Tue, 28 Oct 2003 15:43:41 -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 : HTTP adaptation with OPES Author(s) : A. Rousskov, M. Stecher Filename : draft-ietf-opes-http-01.txt Pages : 30 Date : 2003-10-28 Open Pluggable Edge Services (OPES) framework documents several application-agnostic mechanisms such as OPES tracing, OPES bypass, and OPES callout protocol. This document binds those mechanisms to a specific application protocol, HTTP. Together, application-agnostic OPES documents and this HTTP binding constitute a complete specification for HTTP adaptation with OPES. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opes-http-01.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-http-01.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-http-01.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-10-28155756.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-opes-http-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-opes-http-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28155756.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-openproxy@mail.imc.org Tue Oct 28 18:12:36 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05905 for ; Tue, 28 Oct 2003 18:12:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEd14-0002K6-00 for opes-archive@ietf.org; Tue, 28 Oct 2003 18:12:46 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AEd13-0002K3-00 for opes-archive@ietf.org; Tue, 28 Oct 2003 18:12:45 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SMx3I7010491 for ; Tue, 28 Oct 2003 14:59: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 h9SMx3J8010490 for ietf-openproxy-bks; Tue, 28 Oct 2003 14:59: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 h9SMx1I7010485 for ; Tue, 28 Oct 2003 14:59: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 h9SMx3Gh004055 for ; Tue, 28 Oct 2003 15:59: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 h9SMx3eR004054; Tue, 28 Oct 2003 15:59:03 -0700 (MST) (envelope-from rousskov) Date: Tue, 28 Oct 2003 15:59:03 -0700 (MST) From: Alex Rousskov To: OPES WG Subject: HTTP auxiliary parts and OCP Core 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: HTTP Adaptation draft defines auxiliary parts. They are used to deliver an HTTP request to the service that adapts an HTTP response. Auxiliary parts are not meant to be adapted, of course (it is too late, the request has already been sent). Yet, they use the same original dataflow. OCP Core defines several mechanisms that allow OCP agents to manipulate original dataflow. Original data can be preserved and reused by the processor at the server request. Original dataflow can be paused and resumed by OPES processor at the service request. Finally, a callout server may get out of the loop and instruct the OPES processor to send all original data on the server behalf. It is not clear from the current HTTP draft whether all, none, or some original dataflow mechanisms apply to auxiliary parts. It seems to me that data preservation and getting out of the loop is usually useless when it comes to auxiliary data. However, a low-level pause/resume features can be useful. Moreover, I am not sure it would be clear to implementers whether all OCP Core offsets start with auxiliary data or adaptable data. From Core point of view, they start with auxiliary data because it was sent first. Should we add specific rules that clarify the above? Or should we just say that from OCP point of view "auxiliary data" is "data" and all Core mechanisms apply "as is"? If we use the former approach, it is not clear what Core mechanisms need to be included in this clarification. If we use the latter approach, it is not clear what to do when a callout server decides to adapt auxiliary parts. My current preference is to say that from OCP point of view "auxiliary data" is "data" and absolutely all Core mechanisms apply "as is". And then add that the OPES processor MAY terminate a transaction if adapted flow includes an auxiliary part. The latter can be determined by looking at AM-Parts parameter of the adapted DU* message. Comments? Alex. From owner-ietf-openproxy@mail.imc.org Tue Oct 28 23:41: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 XAA23638 for ; Tue, 28 Oct 2003 23:41:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEi8w-00011A-00 for opes-archive@ietf.org; Tue, 28 Oct 2003 23:41:14 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AEi8u-00010z-00 for opes-archive@ietf.org; Tue, 28 Oct 2003 23:41:13 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T4SHI7023766 for ; Tue, 28 Oct 2003 20:28:17 -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 h9T4SHRH023765 for ietf-openproxy-bks; Tue, 28 Oct 2003 20:28:17 -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 h9T4SGI7023760 for ; Tue, 28 Oct 2003 20:28:16 -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 1CC681C016C2; Tue, 28 Oct 2003 20:28:17 -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 KAA08671; Wed, 29 Oct 2003 10:09:26 +0530 (IST) Message-ID: <3F9F41DE.D110E294@india.hp.com> Date: Wed, 29 Oct 2003 09:58:14 +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 WG Subject: Re: P: single assignment semantics References: <3F9E8E92.4010907@bell-labs.com> <3F9EBF98.8030005@bell-labs.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 How about having a new reserved member for every variable? Access to this member triggers an evaluation of the expression and returns the result. name := expression; const := name.value; Now the programmer has the benefit of both the alternatives. Ofcourse, the compiler/runtime can also optimize and avoid any reevaluation wherever possible. regards Geetha Alex Rousskov wrote: > > On Tue, 28 Oct 2003, Andre Beck wrote: > > > I think the latter is the case. ;-) At least IRML does not allow > > such loops. When I talked about the re-evaluation of rule conditions > > I did not mean that a single rule can or should be evaluated more > > than once for a given message. Rather what I meant was that if the > > same message property is referenced in two different rules, then the > > rule processor must not assume that the property value will be the > > same for both rules. > > Ah, I see. In P, since it has variables, the same caveat becomes even > more confusing for rule writers, I think. In IRML, the rule writer > should assume that every external property may change between service > invocations (at least). In P, the rule writer may have to assume that > even local variables change between service invocations (at least). > > It would be nice to either avoid variable changes or at least make > them less transparent. In your opinion, what is more important: > > - optimizing performance when storing potentially > large expression values in a variable > > - optimizing programmer understanding when using > variables (i.e., making the interface more natural > so that programmer's expectations match reality) > > I wonder if it make sense to offload the above decision to programmer? > We could give rule writers explicit control over macro-versus-constant > choice by introducing references (parameter-less macros) in addition > to constant variables. For example, > > /* no performance penalty, natural/expected results */ > constant name := small_value; > > /* no performance penalty, possibly confusing results */ > reference name := huge_value; > > /* no performance penalty, possibly confusing results */ > reference name := small_value; > > /* performance penalty, natural/expected results */ > constant name := huge_value; > > What do you think? Is it worth the trouble supporting the above > interface? Or should we make this decision for the programmer, in P > Core? > > Or would it be possible to delegate the decision to module writers, > like I proposed for string case sensitivity support? Each object would > be either copied or referenced, depending on objects type, as defined > by object creator (a module): > > /* no performance penalty, natural/expected results */ > name := small_object.cheap_operation(small_value) > > /* no performance penalty, possibly confusing results */ > /* copy small_* and cheap_operation, */ > /* reference huge_object and expensive_operation */ > name := huge_object.cheap_operation(small_value); > name := huge_object.expensive_operation(small_value); > name := huge_object.expensive_operation(huge_value); > name := small_object.expensive_operation(small_value); > name := small_object.expensive_operation(huge_value); > ... > > The latter approach puts the optimization burden on module writers, > which is good. Should we combine the two: > > /* rely on expression's module(s) to copy or reference */ > name := expression; > > /* force copying: performance penalty but expected results */ > constant name := expression; > > Comments? Better ideas? > > > I don't think it's a good idea to get into the business of loops and > > loop prevention by allowing the rule processor to evaluate a rule a > > second time if a message propery value changes. In fact, I think > > such behavior would potentially lead to very unintended results > > because the order in which rules (and services for that matter) are > > processed can make a big difference. The order in which rules are > > processed should be determined before they are evaluatated. > > I agree. > > Alex. From owner-ietf-openproxy@mail.imc.org Wed Oct 29 00:02: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 AAA24460 for ; Wed, 29 Oct 2003 00:02:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEiTY-0001Mb-00 for opes-archive@ietf.org; Wed, 29 Oct 2003 00:02:32 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AEiTX-0001MY-00 for opes-archive@ietf.org; Wed, 29 Oct 2003 00:02: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 h9T4nmI7024581 for ; Tue, 28 Oct 2003 20:49:48 -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 h9T4nmHZ024580 for ietf-openproxy-bks; Tue, 28 Oct 2003 20:49:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T4nlI7024574 for ; Tue, 28 Oct 2003 20:49:47 -0800 (PST) (envelope-from geetham@india.hp.com) Received: from observer.india.hp.com (observer.india.hp.com [15.76.122.45]) by palrel11.hp.com (Postfix) with ESMTP id 947A81C00BF9; Tue, 28 Oct 2003 20:49:48 -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 KAA08870; Wed, 29 Oct 2003 10:30:52 +0530 (IST) Message-ID: <3F9F46E5.E459D3F9@india.hp.com> Date: Wed, 29 Oct 2003 10:19:41 +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: Andre Beck Cc: Alex Rousskov , OPES WG Subject: Re: P: single assignment semantics References: <3F9E8E92.4010907@bell-labs.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 Andre Beck wrote: > In the current IRML draft we require that IRML interpreters re-evaluate > rule conditions and the referenced message property values after each > service execution. As you pointed out, message properties and in > particular message header values can change as a result of service > executions. A content adaptation service, for example, may modify the > content type and subsequent service operations may not make sense any > more once the content type of a message has changed. Under this condition, I think, it may be cumbersome to actually nest the rest of the code under another IF.. How does P handle this? You may want to introduce a new statement in 'P' that just 'ends' the rule processing and returns.. Alternatively you may want to specify a method in core to do so , core.end(), core.exit() or something like that. regards Geetha From owner-ietf-openproxy@mail.imc.org Wed Oct 29 00:09: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 AAA24651 for ; Wed, 29 Oct 2003 00:09:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEiah-0001RV-00 for opes-archive@ietf.org; Wed, 29 Oct 2003 00:09:55 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AEiah-0001RS-00 for opes-archive@ietf.org; Wed, 29 Oct 2003 00:09: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 h9T4xFI7025403 for ; Tue, 28 Oct 2003 20: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 h9T4xEhj025402 for ietf-openproxy-bks; Tue, 28 Oct 2003 20:59:14 -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 h9T4xEI7025394 for ; Tue, 28 Oct 2003 20:59:14 -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 A81BF1C01061; Thu, 30 Oct 2003 20:12:24 -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 KAA08963; Wed, 29 Oct 2003 10:40:24 +0530 (IST) Message-ID: <3F9F4920.75DB0652@india.hp.com> Date: Wed, 29 Oct 2003 10:29:12 +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 WG Subject: Re: P: single assignment semantics References: 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 Alex, While I do strongly agree about the possibility of different values of the same expression at different points in a P program (due to adaptation and so on), this example of yours confused me... > Assume, for example, that name is a response > body-dependent expression and code A above executes a callout service > on the response headers. By the time the service call completes, the > processor may read a few more chunks of that response body and the > value of the named expression can change. A simpler example would be: > > current_time := Time.now(); // interpreted in the morning > ... > if (current_time.isEvening()) { // can this become true? > ... > } How can the processor read a few more chunks while performing the rule processing ? If this is so, then I suppose, we would end up in a non deterministic behaviour! In other words, my question is probably about the vectoring point.. what are options for vectoring point for a non-HTTP protocol, for example? Sorry - if this is already specified in a different draft, pl give me a pointer to that... regards geetha From owner-ietf-openproxy@mail.imc.org Wed Oct 29 04:33: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 EAA00026 for ; Wed, 29 Oct 2003 04:33:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEmiL-00050s-00 for opes-archive@ietf.org; Wed, 29 Oct 2003 04:34:05 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AEmiK-00050p-00 for opes-archive@ietf.org; Wed, 29 Oct 2003 04:34: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 h9T9OLI7001607 for ; Wed, 29 Oct 2003 01:24:21 -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 h9T9OKq7001606 for ietf-openproxy-bks; Wed, 29 Oct 2003 01:24: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 h9T9OII7001525 for ; Wed, 29 Oct 2003 01:24:19 -0800 (PST) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id GJMSU1O2outgoing id 8HUG99EE; 29 Oct 2003 12:31:25 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: HTTP auxiliary parts and OCP Core Date: Wed, 29 Oct 2003 10:24:03 +0100 Message-ID: <75F7E67FC45F6744A7D328D41E35376D0E666B@mail.webwasher.com> Thread-Topic: HTTP auxiliary parts and OCP Core Thread-Index: AcOdtDMrlF5Uds/tQ4GxolWkLdgHLgASYuZA From: "Martin Stecher" To: "OPES WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9T9OJI7001591 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > My current preference is to say that from OCP point of view "auxiliary > data" is "data" and absolutely all Core mechanisms apply "as is". Mine as well. > And > then add that the OPES processor MAY terminate a transaction if > adapted flow includes an auxiliary part. HTTP draft says in section 2.2: An OPES processor MUST NOT send parts that are not listed as "original" in the negotiated profile. An callout server MUST NOT send parts that are not listed as "adapted" in the negotiated profile. An OCP agent receiving an not-listed part MUST terminate the transaction with an error. Beside that we used a MUST rather than MAY, is there something missing in the current draft that needs to be added? Regards Martin From owner-ietf-openproxy@mail.imc.org Wed Oct 29 04:35: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 EAA00095 for ; Wed, 29 Oct 2003 04:35:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEmkG-00051u-00 for opes-archive@ietf.org; Wed, 29 Oct 2003 04:36:04 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AEmkG-00051r-00 for opes-archive@ietf.org; Wed, 29 Oct 2003 04:36: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 h9T9R7I7002559 for ; Wed, 29 Oct 2003 01:27: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 h9T9R6r3002557 for ietf-openproxy-bks; Wed, 29 Oct 2003 01:27:06 -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 h9T9R4I7002511 for ; Wed, 29 Oct 2003 01:27:05 -0800 (PST) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] by mail2.webwasher.com id 5LDQ6KYNoutgoing id XQIROERQ; 29 Oct 2003 12:34:22 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: OCP/HTTP example updated Date: Wed, 29 Oct 2003 10:26:59 +0100 Message-ID: <75F7E67FC45F6744A7D328D41E35376D0E666C@mail.webwasher.com> Thread-Topic: OCP/HTTP example updated Thread-Index: AcOd/s2KIg6xsLVBTi6ldhiE1IpaLQ== From: "Martin Stecher" To: "OPES WG (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9T9R6I7002548 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi, I updated the OCP/HTTP example at http://www.martin-stecher.de/opes/sample1.html. It should now be compliant to the new drafts we published. Latest change was to replace Wont-Use paramter with DWSY message. Regards Martin From owner-ietf-openproxy@mail.imc.org Wed Oct 29 11:04: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 LAA15862 for ; Wed, 29 Oct 2003 11:04:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEsom-0003kZ-00 for opes-archive@ietf.org; Wed, 29 Oct 2003 11:05:08 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AEsom-0003kS-00 for opes-archive@ietf.org; Wed, 29 Oct 2003 11:05: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 h9TFpDkT025646 for ; Wed, 29 Oct 2003 07:51:13 -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 h9TFpDAS025645 for ietf-openproxy-bks; Wed, 29 Oct 2003 07:51:13 -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 h9TFpBkT025638 for ; Wed, 29 Oct 2003 07:51:12 -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 h9TFpCGh027733 for ; Wed, 29 Oct 2003 08:51:12 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9TFpC39027732; Wed, 29 Oct 2003 08:51:12 -0700 (MST) (envelope-from rousskov) Date: Wed, 29 Oct 2003 08:51:12 -0700 (MST) From: Alex Rousskov To: OPES WG Subject: Re: P: single assignment semantics In-Reply-To: <3F9F46E5.E459D3F9@india.hp.com> Message-ID: References: <3F9E8E92.4010907@bell-labs.com> <3F9F46E5.E459D3F9@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 Wed, 29 Oct 2003, Geetha Manjunath wrote: > Andre Beck wrote: > > > In the current IRML draft we require that IRML interpreters > > re-evaluate rule conditions and the referenced message property > > values after each service execution. As you pointed out, message > > properties and in particular message header values can change as a > > result of service executions. A content adaptation service, for > > example, may modify the content type and subsequent service > > operations may not make sense any more once the content type of a > > message has changed. > > Under this condition, I think, it may be cumbersome to actually nest > the rest of the code under another IF.. > > How does P handle this? It is up to the programmer or IDE to handle any inter-rule dependencies. Semantic dependencies among rules are to complex for P to check/enforce them, IMO. > You may want to introduce a new statement in 'P' that just 'ends' the > rule processing and returns.. Alternatively you may want to specify a > method in core to do so , core.end(), core.exit() or something like > that. Yes, that's already on the todo list. Section 5 of the draft says: XXX: add Core.interpreter.stop and Core.interpreter.restart methods. Alex. From owner-ietf-openproxy@mail.imc.org Wed Oct 29 11:17: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 LAA16784 for ; Wed, 29 Oct 2003 11:17:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEt0b-00048c-00 for opes-archive@ietf.org; Wed, 29 Oct 2003 11:17:21 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AEt0a-00048R-00 for opes-archive@ietf.org; Wed, 29 Oct 2003 11:17: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 h9TG6MkT026561 for ; Wed, 29 Oct 2003 08:06:22 -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 h9TG6Mw7026560 for ietf-openproxy-bks; Wed, 29 Oct 2003 08:06:22 -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 h9TG6KkT026553 for ; Wed, 29 Oct 2003 08:06:20 -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 h9TG6LGh028076; Wed, 29 Oct 2003 09:06:21 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9TG6Lac028075; Wed, 29 Oct 2003 09:06:21 -0700 (MST) (envelope-from rousskov) Date: Wed, 29 Oct 2003 09:06:21 -0700 (MST) From: Alex Rousskov To: OPES WG Subject: Re: P: single assignment semantics In-Reply-To: <3F9F4920.75DB0652@india.hp.com> Message-ID: References: <3F9F4920.75DB0652@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 Wed, 29 Oct 2003, Geetha Manjunath wrote: > While I do strongly agree about the possibility of different values of > the same expression at different points in a P program (due to > adaptation and so on), this example of yours confused me... > > > Assume, for example, that name is a response body-dependent > > expression and code A above executes a callout service on the > > response headers. By the time the service call completes, the > > processor may read a few more chunks of that response body and the > > value of the named expression can change. > > How can the processor read a few more chunks while performing the > rule processing ? The P interpreter instance serving this particular transaction will block, but the proxy executing that interpreter instance does not have to block. All production proxies I know do not block on external operations such as a callout service call. They continue to work on other items. These "other items" usually include network I/O for pending transactions, possibly including the ones for which the rules are being interpreted. Thus, depending on the design, a proxy may continue to read response body while the service is doing its thing and the interpreter instance is waiting. In fact, in most cases, a complete body will _not_ be available at any single time -- it is just too big to cache (the service can cache the body if it needs to, but the proxy may not). > If this is so, then I suppose, we would end up in a non > deterministic behaviour! Depends on what you mean by "non-determinism" in this case, I guess. You agree above that adaptations can cause the same expression to have different values. "Reading a few more chunks" is just another adaptation, if you will. There is no difference from P point of view. We can (and probably should) demand that interpreters do not block except for a few known points like service executions. While writing ruleset with adaptation rules is close to programming with threads, we want to avoid parallel processing surprises as much as possible. P "threads" can (and probably should) have well-documented preemption points. > In other words, my question is probably about the vectoring point.. > what are options for vectoring point for a non-HTTP protocol, for > example? I do not think the above is related to vectoring points. The problem exists even if there is a single vectoring point. Multiple vectoring points just introduce more opportunities for something to be changed while the rules are interpreted. Did my response clarified the problem enough? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Wed Oct 29 11:40: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 LAA18016 for ; Wed, 29 Oct 2003 11:40:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEtNK-0004Zm-00 for opes-archive@ietf.org; Wed, 29 Oct 2003 11:40:50 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AEtNJ-0004Zj-00 for opes-archive@ietf.org; Wed, 29 Oct 2003 11:40: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 h9TGT1kT027994 for ; Wed, 29 Oct 2003 08:29: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 h9TGT1fK027993 for ietf-openproxy-bks; Wed, 29 Oct 2003 08:29:01 -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 h9TGSxkT027983 for ; Wed, 29 Oct 2003 08:28: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 h9TGT0Gh028572; Wed, 29 Oct 2003 09:29:00 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9TGSxTX028571; Wed, 29 Oct 2003 09:28:59 -0700 (MST) (envelope-from rousskov) Date: Wed, 29 Oct 2003 09:28:59 -0700 (MST) From: Alex Rousskov To: OPES WG Subject: RE: HTTP auxiliary parts and OCP Core In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D0E666B@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D0E666B@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 29 Oct 2003, Martin Stecher wrote: > > And then add that the OPES processor MAY terminate a transaction > > if adapted flow includes an auxiliary part. > > HTTP draft says in section 2.2: > > An OPES processor MUST NOT send parts that are not listed as > "original" in the negotiated profile. An callout server MUST NOT send > parts that are not listed as "adapted" in the negotiated profile. An > OCP agent receiving an not-listed part MUST terminate the transaction > with an error. > > Beside that we used a MUST rather than MAY, is there something > missing in the current draft that needs to be added? Let's keep a MUST there. I am convinced by the rationale in the draft (did I write it?) :-). Obviously, I overlooked the requirement you quote when looking for it. I would suggest to move all part-specific after-negotiation requirements from Section 2.2's introduction to Section 2.2.1 Profile Parts. Alex. From owner-ietf-openproxy@mail.imc.org Wed Oct 29 15:47: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 PAA05373 for ; Wed, 29 Oct 2003 15:47:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AExEJ-00037A-00 for opes-archive@ietf.org; Wed, 29 Oct 2003 15:47:47 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AExEJ-000377-00 for opes-archive@ietf.org; Wed, 29 Oct 2003 15:47: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 h9TKV4kT042700 for ; Wed, 29 Oct 2003 12:31:04 -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 h9TKV4FT042699 for ietf-openproxy-bks; Wed, 29 Oct 2003 12:31:04 -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 h9TKV3kT042694 for ; Wed, 29 Oct 2003 12:31:04 -0800 (PST) (envelope-from abeck@bell-labs.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 h9TKV5fO037192 for ; Wed, 29 Oct 2003 15:31:05 -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 h9TKUw0C072153 for ; Wed, 29 Oct 2003 15:30:58 -0500 (EST) Received: from bell-labs.com (abeck-hopc [135.180.240.202]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h9TKUvFU028881 for ; Wed, 29 Oct 2003 15:30:58 -0500 (EST) Message-ID: <3FA02373.1030504@bell-labs.com> Date: Wed, 29 Oct 2003 15:30:43 -0500 From: Andre Beck User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES WG Subject: Re: P: single assignment semantics References: <3F9F4920.75DB0652@india.hp.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: > Thus, depending on the design, a proxy may continue to read response > body while the service is doing its thing and the interpreter instance > is waiting. > > In fact, in most cases, a complete body will _not_ be available at any > single time -- it is just too big to cache (the service can cache the > body if it needs to, but the proxy may not). I agree and that's in fact why I think P programs should not be allowed to reference message bodies. In my opinion, P programs should only serve as high-level filters that invoke OPES services based on message header values (e.g. HTTP content-type) and maybe system and environment variables (e.g. system time). If a P program triggers the execution of a service, then the service logic within that service can evaluate all message properties including the message body to determine if there is a need to process the message. I don't think it's a good idea to move that kind of service logic into P programs. By restricting P programs in this way we would also render the copy vs. reference question essentially a non-issue simply because we can assume that message header values are always small and copy operations would not have a significant performance impact. I would therefore favor the 'programmer-friendly' constant approach over the macro approach or any combination thereof. -Andre From owner-ietf-openproxy@mail.imc.org Wed Oct 29 16:50: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 QAA08805 for ; Wed, 29 Oct 2003 16:50:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEyDX-0004MT-00 for opes-archive@ietf.org; Wed, 29 Oct 2003 16:51:03 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AEyDX-0004MQ-00 for opes-archive@ietf.org; Wed, 29 Oct 2003 16:51: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 h9TLbekT046044 for ; Wed, 29 Oct 2003 13:37: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 h9TLbeIK046043 for ietf-openproxy-bks; Wed, 29 Oct 2003 13:37:40 -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 h9TLbdkT046036 for ; Wed, 29 Oct 2003 13:37: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 h9TLbbGh036960; Wed, 29 Oct 2003 14:37: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 h9TLbb9V036959; Wed, 29 Oct 2003 14:37:37 -0700 (MST) (envelope-from rousskov) Date: Wed, 29 Oct 2003 14:37:37 -0700 (MST) From: Alex Rousskov To: OPES WG Subject: Re: P: single assignment semantics In-Reply-To: <3FA02373.1030504@bell-labs.com> Message-ID: References: <3F9F4920.75DB0652@india.hp.com> <3FA02373.1030504@bell-labs.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, 29 Oct 2003, Andre Beck wrote: > I agree and that's in fact why I think P programs should not be > allowed to reference message bodies. In my opinion, P programs > should only serve as high-level filters that invoke OPES services > based on message header values (e.g. HTTP content-type) and maybe > system and environment variables (e.g. system time). If a P program > triggers the execution of a service, then the service logic within > that service can evaluate all message properties including the > message body to determine if there is a need to process the message. > I don't think it's a good idea to move that kind of service logic > into P programs. I agree that P primary objective is to pre-select good candidates for adaptation (service application). It is up to the service to make the final call and perform adaptations or get out of the loop. There is a fine line here, of course. In may cases, selecting a good candidate would require looking at the body. For example, a P module that guesses content type would do that. Without such a module, one would have to pass virtually everything to the content-type-specific service because Content-Type headers are often missing or wrong. Note that the said P module would only need to look at a few first bytes of the content. > By restricting P programs in this way we would also render the copy > vs. reference question essentially a non-issue simply because we can > assume that message header values are always small and copy > operations would not have a significant performance impact. I would > therefore favor the 'programmer-friendly' constant approach over the > macro approach or any combination thereof. True. I am not ready to cast my vote here. I think we need to consider more use cases. How, for example, do you propose to handle a case where a callout service wants to adapt all GIF images. and only them? We can assume HTTP application protocol for now. Also, it seems that your suggestion is based on an assumption that bodies are large and headers are small. This is usually true for HTTP, but may not be true for other application protocols. If we go down this path, how would you define X in "P programs should not be allowed to reference X"? Would it be application binding specific? Finally, is size of the data the only concern here? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Wed Oct 29 18:19:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14346 for ; Wed, 29 Oct 2003 18:19:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEzbc-0006on-00 for opes-archive@ietf.org; Wed, 29 Oct 2003 18:20:00 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AEzbb-0006oT-00 for opes-archive@ietf.org; Wed, 29 Oct 2003 18:19:59 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TN4DkT050315 for ; Wed, 29 Oct 2003 15:04:13 -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 h9TN4Dpe050314 for ietf-openproxy-bks; Wed, 29 Oct 2003 15:04:13 -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 h9TN4CkT050309 for ; Wed, 29 Oct 2003 15:04:12 -0800 (PST) (envelope-from abeck@bell-labs.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 h9TN4Enl036872 for ; Wed, 29 Oct 2003 18:04:14 -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 h9TN470C084551 for ; Wed, 29 Oct 2003 18:04:07 -0500 (EST) Received: from bell-labs.com (abeck-hopc [135.180.240.202]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h9TN47FU002097 for ; Wed, 29 Oct 2003 18:04:07 -0500 (EST) Message-ID: <3FA04708.9060603@bell-labs.com> Date: Wed, 29 Oct 2003 18:02:32 -0500 From: Andre Beck User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES WG Subject: Re: P: single assignment semantics References: <3F9F4920.75DB0652@india.hp.com> <3FA02373.1030504@bell-labs.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > > There is a fine line here, of course. In may cases, selecting a good > candidate would require looking at the body. For example, a P module > that guesses content type would do that. Without such a module, one > would have to pass virtually everything to the content-type-specific > service because Content-Type headers are often missing or wrong. Note > that the said P module would only need to look at a few first bytes of > the content. > I am not ready to cast my vote here. I think we need to consider more > use cases. How, for example, do you propose to handle a case where a > callout service wants to adapt all GIF images. and only them? We can > assume HTTP application protocol for now. One approach would be to write a P program that forwards only those HTTP responses to the service that do not have a content type of "text/*". This should significantly reduce the number of unnecessary service invocations. But I agree that in this example it may make sense to give a P program access to the first few bytes of the message body. This would still be a small object, though. Do you have an example that would require the handling of large objects? > Also, it seems that your suggestion is based on an assumption that > bodies are large and headers are small. This is usually true for HTTP, > but may not be true for other application protocols. If we go down > this path, how would you define X in "P programs should not be allowed > to reference X"? Would it be application binding specific? Generally speaking, I would say that P programs should be restricted to the evaluation of signaling/control and meta data which is all typically contained in message headers. I also think that it's safe to assume that signaling/control/meta data is typically smaller than the data it is assciated with. In practice, I think we should look at those message properties that OPES processors need to inspect for their normal operation anyway. For example, do Web caches typically look at HTTP bodies in order to decide whether or not to cache an object? If not, then maybe this would be a message property that should rather be inspected by an OPES service application running on a dedicated and specialized callout server. I think whenever the evaluation of a property is likely to be expensive and could therefore interfere with the normal operation of an OPES processor, then we should disallow this operation in P. -Andre From owner-ietf-openproxy@mail.imc.org Thu Oct 30 11:47: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 LAA00193 for ; Thu, 30 Oct 2003 11:47:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFFxC-0006EL-00 for opes-archive@ietf.org; Thu, 30 Oct 2003 11:47:22 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AFFxB-0006EG-00 for opes-archive@ietf.org; Thu, 30 Oct 2003 11:47: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 h9UGXikT071149 for ; Thu, 30 Oct 2003 08:33: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 h9UGXiZS071148 for ietf-openproxy-bks; Thu, 30 Oct 2003 08:33:44 -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 h9UGXgkT071143 for ; Thu, 30 Oct 2003 08:33:42 -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 h9UGXeGh062789; Thu, 30 Oct 2003 09:33:40 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9UGXedB062788; Thu, 30 Oct 2003 09:33:40 -0700 (MST) (envelope-from rousskov) Date: Thu, 30 Oct 2003 09:33:40 -0700 (MST) From: Alex Rousskov To: OPES WG Subject: Re: P: single assignment semantics In-Reply-To: <3FA04708.9060603@bell-labs.com> Message-ID: References: <3F9F4920.75DB0652@india.hp.com> <3FA02373.1030504@bell-labs.com> <3FA04708.9060603@bell-labs.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, 29 Oct 2003, Andre Beck wrote: > > I am not ready to cast my vote here. I think we need to consider > > more use cases. How, for example, do you propose to handle a case > > where a callout service wants to adapt all GIF images. and only > > them? We can assume HTTP application protocol for now. > > One approach would be to write a P program that forwards only those > HTTP responses to the service that do not have a content type of > "text/*". This should significantly reduce the number of > unnecessary service invocations. Text/* files are not that common, relatively speaking. The actual reduction with the above technique would be less than 20% (by count) and less than 10% (by volume). Here is a daily stats snapshot taken at our IRCache proxies (www.ircache.net), for example: Top 20 Object Types: 3173614 61% Image 9501602 kbytes 19% 3065 bytes/obj 1035836 20% Other 22461506 kbytes 45% 22204 bytes/obj 413219 8% Query 2264820 kbytes 5% 5612 bytes/obj 185256 4% HTML 1666142 kbytes 3% 9209 bytes/obj 184296 4% Directory 1993028 kbytes 4% 11073 bytes/obj 115932 2% Lookup 1036971 kbytes 2% 9159 bytes/obj 26990 1% Executable 5469681 kbytes 11% 207519 bytes/obj 14140 0% Bundle 1735770 kbytes 3% 125702 bytes/obj 10733 0% Text 68388 kbytes 0% 6524 bytes/obj 10548 0% SHTML 152145 kbytes 0% 14770 bytes/obj 10315 0% PDF 1355587 kbytes 3% 134573 bytes/obj 6374 0% Audio 193083 kbytes 0% 31019 bytes/obj 5746 0% Movie 1897433 kbytes 4% 338143 bytes/obj 4407 0% Applet 21822 kbytes 0% 5070 bytes/obj 981 0% Software 15537 kbytes 0% 16218 bytes/obj 59 0% PostScript 9698 kbytes 0% 168324 bytes/obj 14 0% ISMAP 15 kbytes 0% 1108 bytes/obj 6 0% Drawing 518 kbytes 0% 88512 bytes/obj But we may be getting too specific here... One could, of course, come up with a set of nested rules that guess most images correctly based on just HTTP headers. My concern is that if we simply prohibit body-related functionality, there will be "too many" corner cases where that functionality is essential. For example, should P be able to block viruses that spread via simple 10KB HTTP POST requests? If yes, we give network operators a powerful tool. If not, we tell network operators to rely on 3rd party modules being available "soon enough" for each new virus. > But I agree that in this example it may make sense to give a P > program access to the first few bytes of the message body. This > would still be a small object, though. Do you have an example that > would require the handling of large objects? I do not have a good one. If an example handles something very large, you would say that a service should be used instead of a module. For example, why do we think it is appropriate to prohibit support for this kind of module/function in P: if (VirusVendorModule.findVirus(message.body)) { ... } I think it is possible to support the above in P, but I am not sure it is a good idea to do so. More precisely, I do not know where to draw the line: VirusVendorModule.findVirus(message.body) VirusVendorModule.virusProbability(message.bodyprefix) > 30% ImageVendorModule.isGif(message.body) ImageVendorModule.gifProbability(message.bodyprefix) > 30% ... > Generally speaking, I would say that P programs should be restricted > to the evaluation of signaling/control and meta data which is all > typically contained in message headers. I also think that it's safe > to assume that signaling/control/meta data is typically smaller than > the data it is assciated with. And yet you did agree that allowing P modules to peek at small parts of the body might be useful for things like content type determination or, perhaps, blocking viruses in POST queries. I do share your concerns about the overheads and complexities of body handling in P. I am trying to find a flexible scheme that will cover most cases with ease and leave some freedom for accommodating some corner cases with effort. One answer could be that something like findVirus(message.body) or isGif(message.body) MUST be implemented as a service but may have a function-call interface to P. We already have to deal with service execution (something that is not well documented in P or IRML yet) so we would not be adding much more complexity; we would just need to document an interface where a service can return a value for P interpreter to use. Instead of writing a bunch of sequential calls to services that would ignore most of the content: apply(service1); apply(service2); apply(service3); the programmer would be able to optimize: if (apply(service1) returns FooBar) { apply(service2); } else { apply(service3); } The latter is then no different (on a conceptual level) from if (service1() == FooBar) { service2(); } else { service3(); } Do you see what I am getting at? > In practice, I think we should look at those message properties that > OPES processors need to inspect for their normal operation anyway. > For example, do Web caches typically look at HTTP bodies in order to > decide whether or not to cache an object? If not, then maybe this > would be a message property that should rather be inspected by an > OPES service application running on a dedicated and specialized > callout server. "Straight" web caches look at bodies only if they need to handle transfer encodings and such. However, there are some HTTP proxies that adapt bodies. We can say that those proxies are out of scope; they should be using services instead. > I think whenever the evaluation of a property is likely to be > expensive and could therefore interfere with the normal operation of > an OPES processor, then we should disallow this operation in P. If we try to do something like that, we are still faced with the same specification problem: How do you define "likely to be expensive"? Is it expensive for 10% of use cases? 90%? Is looking at the first 100 bytes of a body expensive? Is looking at all already available bytes of a body expensive? What if the entire 10MB body is available because it is cached or pre-positioned on the proxy? Alex. From owner-ietf-openproxy@mail.imc.org Thu Oct 30 12:56:16 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02904 for ; Thu, 30 Oct 2003 12:56:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFH22-0007Df-00 for opes-archive@ietf.org; Thu, 30 Oct 2003 12:56:26 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AFH21-0007Db-00 for opes-archive@ietf.org; Thu, 30 Oct 2003 12:56: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 h9UHhokT075632 for ; Thu, 30 Oct 2003 09:43: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 h9UHhoJe075631 for ietf-openproxy-bks; Thu, 30 Oct 2003 09:43: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 h9UHhnkT075625 for ; Thu, 30 Oct 2003 09:43: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 h9UHhoGh064320 for ; Thu, 30 Oct 2003 10:43:50 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9UHhocO064319; Thu, 30 Oct 2003 10:43:50 -0700 (MST) (envelope-from rousskov) Date: Thu, 30 Oct 2003 10:43:50 -0700 (MST) From: Alex Rousskov To: OPES WG Subject: OCP: identifier uniqness and lifetime 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: Many OCP messages use identifiers: transaction identifier, application message identifier, service group identifier. To work, those integer IDs must be unique within some scope. For example, transaction identifiers must be unique within an OCP connection while application message identifiers must be unique within a transaction. The question is whether object ID uniqueness is preserved and guaranteed after the corresponding object disappears. For example, can an agent reuse transaction ID on the same connection once the old transaction is over? A simple answer would be that IDs must not be reused within a given scope, ever. That is, the "scope" is defined as a "lifetime" rather than "at any given time" instance. For example, a transaction ID must be unique across all transactions ever present within an OCP connection. This rule is convenient: Agents can use IDs to log events and cross-reference different logs without much work. However, to enforce this rule, a receiving agent would have to remember all IDs it has seen. That is too much overhead, of course. Thus, if we follow this "convenient" path, we are likely to end up with undetected violations that will hinder interoperability. Another simple answer would be that object IDs can be reused after object death. That is, the "scope" is defined as a "at any given time" instance or a snapshot rather than a "lifetime". For example, a transaction ID can be reused once the old transaction is closed. This rule does not allow for effortless logging and cross-correlation. An agent would have to maintain its own map of IDs if the agent wants long-term uniqueness. The last option is to prohibit object ID reuse _and_ prohibit ID value decrease. The latter artificial restriction would make it cheap to check for violations at the recipient: if a supposedly new ID is smaller than the last identifier seen, it is not really new and must be rejected. Generating IDs is as easy as it is with the first option. This rule assumes that OCP messages introducing new identifiers are received in the order they were sent, which seems to be the case. I intend to document the last option unless you have better ideas or objections. Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Thu Oct 30 17:34:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17475 for ; Thu, 30 Oct 2003 17:34:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFLMn-0003th-00 for opes-archive@ietf.org; Thu, 30 Oct 2003 17:34:09 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AFLMm-0003td-00 for opes-archive@ietf.org; Thu, 30 Oct 2003 17:34: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 h9UMMPkT089074 for ; Thu, 30 Oct 2003 14:22: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 h9UMMP59089073 for ietf-openproxy-bks; Thu, 30 Oct 2003 14:22:25 -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 (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UMMOkT089068 for ; Thu, 30 Oct 2003 14:22:25 -0800 (PST) (envelope-from abeck@bell-labs.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 h9UMMQnl046903 for ; Thu, 30 Oct 2003 17:22:26 -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 h9UMMK0C077604 for ; Thu, 30 Oct 2003 17:22:20 -0500 (EST) Received: from bell-labs.com (abeck-hopc [135.180.240.202]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h9UMMJFU022911 for ; Thu, 30 Oct 2003 17:22:19 -0500 (EST) Message-ID: <3FA18EE5.4040307@bell-labs.com> Date: Thu, 30 Oct 2003 17:21:25 -0500 From: Andre Beck User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES WG Subject: Re: P: single assignment semantics References: <3F9F4920.75DB0652@india.hp.com> <3FA02373.1030504@bell-labs.com> <3FA04708.9060603@bell-labs.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: > Text/* files are not that common, relatively speaking. The actual > reduction with the above technique would be less than 20% (by count) > and less than 10% (by volume). Here is a daily stats snapshot taken at > our IRCache proxies (www.ircache.net), for example: Interesting. > For example, should P be able to block viruses that spread via simple > 10KB HTTP POST requests? If yes, we give network operators a powerful > tool. If not, we tell network operators to rely on 3rd party modules > being available "soon enough" for each new virus. I am not sure I understand this scenario. Are you suggesting that there should be P module that provides a function to do the virus scanning? > And yet you did agree that allowing P modules to peek at small parts > of the body might be useful for things like content type determination > or, perhaps, blocking viruses in POST queries. > > I do share your concerns about the overheads and complexities of body > handling in P. I am trying to find a flexible scheme that will cover > most cases with ease and leave some freedom for accommodating some > corner cases with effort. > > One answer could be that something like findVirus(message.body) or > isGif(message.body) MUST be implemented as a service but may have a > function-call interface to P. We already have to deal with service > execution (something that is not well documented in P or IRML yet) so > we would not be adding much more complexity; we would just need to > document an interface where a service can return a value for P > interpreter to use. Yes, I like that idea a lot. Conceptually, there is really not much of a difference between a P module and an OPES service. But since we are trying to define a framework for OPES services I think it makes a lot of sense to provide functions such as isGIF or findVirus as OPES services. Plus, this would also allow an OPES domain administrator to make a local decision as to whether a service like isGIF should run locally on the OPES processor or on a remote callout server. This should be transparent to P programs, of course. I think if we decide to go down this route, then it would be a natural choice to restrict P module access to message headers while OPES services can access the entire message. Of course, a utility service like isGIF would only need to see the first few bytes of the message body and would therefore be less expensive to invoke than a service that needs to operate on larger parts of the message body. This could be one criteria that determines whether or not a service is a good candidate for local execution. -Andre From owner-ietf-openproxy@mail.imc.org Thu Oct 30 19:17:35 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21824 for ; Thu, 30 Oct 2003 19:17:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFMz2-0005Kx-00 for opes-archive@ietf.org; Thu, 30 Oct 2003 19:17:44 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AFMz1-0005Kt-00 for opes-archive@ietf.org; Thu, 30 Oct 2003 19:17: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 h9V03dkT092422 for ; Thu, 30 Oct 2003 16:03: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 h9V03dDs092421 for ietf-openproxy-bks; Thu, 30 Oct 2003 16:03: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 h9V03bkT092415 for ; Thu, 30 Oct 2003 16:03: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 h9V03aGh073871; Thu, 30 Oct 2003 17:03: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 h9V03Zle073870; Thu, 30 Oct 2003 17:03:35 -0700 (MST) (envelope-from rousskov) Date: Thu, 30 Oct 2003 17:03:35 -0700 (MST) From: Alex Rousskov To: OPES WG Subject: Re: P: single assignment semantics In-Reply-To: <3FA18EE5.4040307@bell-labs.com> Message-ID: References: <3F9F4920.75DB0652@india.hp.com> <3FA02373.1030504@bell-labs.com> <3FA04708.9060603@bell-labs.com> <3FA18EE5.4040307@bell-labs.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, 30 Oct 2003, Andre Beck wrote: > > For example, should P be able to block viruses that spread via > > simple 10KB HTTP POST requests? If yes, we give network operators > > a powerful tool. If not, we tell network operators to rely on 3rd > > party modules being available "soon enough" for each new virus. > > I am not sure I understand this scenario. Are you suggesting that > there should be P module that provides a function to do the virus > scanning? Not exactly, sorry for being so cryptic. I try to think in more general terms while having specific applications in mind. In this particular case, the application is, essentially, a virus scanner that supports a single virus that spreads via POST requests. The general mechanism in P would be something like a string search within a message body and response generation (something many proxies already support in one way or another): if (request.body contains "virus_signature") { generateResponse("request_blocked.html"); Core.interpreter.stop(); } We already know about killer viruses that spread via GET requests. Our web server logs still get a lot of those requests, years after the viruses were released. The above interface can filter out GET-based viruses too, of course. I am sure POST-based viruses either already exist or will exist. They are more difficult to deal with because routers and even L7 switches have trouble looking at POST bodies. Here we concentrate on the ability of a network administrator to block something like that immediately after reading about it on slashdot, not via virus scanner upgrades (which is the correct long-term way of doing it). > > One answer could be that something like findVirus(message.body) or > > isGif(message.body) MUST be implemented as a service but may have > > a function-call interface to P. We already have to deal with > > service execution (something that is not well documented in P or > > IRML yet) so we would not be adding much more complexity; we would > > just need to document an interface where a service can return a > > value for P interpreter to use. > > Yes, I like that idea a lot. Conceptually, there is really not much > of a difference between a P module and an OPES service. But since we > are trying to define a framework for OPES services I think it makes > a lot of sense to provide functions such as isGIF or findVirus as > OPES services. Plus, this would also allow an OPES domain > administrator to make a local decision as to whether a service like > isGIF should run locally on the OPES processor or on a remote > callout server. This should be transparent to P programs, of course. > > I think if we decide to go down this route, then it would be a > natural choice to restrict P module access to message headers while > OPES services can access the entire message. Of course, a utility > service like isGIF would only need to see the first few bytes of the > message body and would therefore be less expensive to invoke than a > service that needs to operate on larger parts of the message body. > This could be one criteria that determines whether or not a service > is a good candidate for local execution. I am glad we seem to be making progress here. It seems to me that if we make service interface identical to a function call interface, then there will be no reason to distinguish the two in P! It would be up to the module writer and service provider to decide which way to go and when. Thus, we "solve" the problem by offloading all these optimization decisions to those who have more information at hand. The question is, then, how we can make a service invocation to look identical to a module method invocation from P user point of view? There are many similarities here: - both modules and services need to be selected and "loaded" (imported) by a programmer - both module methods and services need to be executed - interface to get method execution results or service execution results is still undocumented The difference is that a module may have many methods while service is, essentially one method (perhaps complex). That is, a module may have many entry points while the service has only one. The remaining difference is a perception that a function call "returns fast" while a service execution may "take a while". Clearly, this is not a perception worth supporting explicitly because both assumptions may not be true. So, how about the following short-term approach? Use import command to load both modules and services. State that P Core does not define how loaded modules or services provide P interpreter with a list of their available entry points (this is currently the case as well, but services are not loaded the way modules do). Essentially, make no distinction between a module and a service. Everything is a module. Service is a module, usually with a single method. Long-term, decide whether we should document either a one-for-all "list-of-entry-points-with-their-profiles" interface or one possible "list-of-entry-points-with-their-profiles" interface, as a separate draft. Note that this interface is internal to P interpreter; programmers do not need to be aware of it. Will something like that work? Alex. From owner-ietf-openproxy@mail.imc.org Fri Oct 31 19:10:22 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26255 for ; Fri, 31 Oct 2003 19:10:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFjLe-0001jE-00 for opes-archive@ietf.org; Fri, 31 Oct 2003 19:10:34 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AFjLd-0001j5-00 for opes-archive@ietf.org; Fri, 31 Oct 2003 19:10: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 h9VNvkkT013313 for ; Fri, 31 Oct 2003 15:57:46 -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 h9VNvkW7013312 for ietf-openproxy-bks; Fri, 31 Oct 2003 15:57:46 -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 h9VNvjkT013307 for ; Fri, 31 Oct 2003 15:57:45 -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 h9VNvlGh007748 for ; Fri, 31 Oct 2003 16:57:47 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h9VNvlhO007747; Fri, 31 Oct 2003 16:57:47 -0700 (MST) (envelope-from rousskov) Date: Fri, 31 Oct 2003 16:57:47 -0700 (MST) From: Alex Rousskov To: OPES WG Subject: OCP Core updates 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: 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.