From owner-ietf-openproxy@mail.imc.org  Mon Jun  2 04:42: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 EAA28201
	for <opes-archive@ietf.org>; Mon, 2 Jun 2003 04:42:39 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19MksB-000133-00
	for opes-archive@ietf.org; Mon, 02 Jun 2003 04:40:55 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19MksA-00012z-00
	for opes-archive@ietf.org; Mon, 02 Jun 2003 04:40:54 -0400
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h528TcAF016826
	for <ietf-openproxy-bks@above.proper.com>; Mon, 2 Jun 2003 01:29:38 -0700 (PDT)
	(envelope-from owner-ietf-openproxy@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h528TcIx016825
	for ietf-openproxy-bks; Mon, 2 Jun 2003 01:29:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f
Received: from wwsmtp.webwasher.com ([217.146.159.49])
	by above.proper.com (8.12.9/8.12.8) with SMTP id h528TXAF016818
	for <ietf-openproxy@imc.org>; Mon, 2 Jun 2003 01:29:36 -0700 (PDT)
	(envelope-from martin.stecher@WEBWASHER.com)
Received: from mail.WEBWASHER.COM [192.168.0.251] id EL9TT6OJ; 02 Jun 2003 10:29:25 +0200
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: HTTP/OCP protocol binding
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Date: Mon, 2 Jun 2003 10:29:17 +0200
Message-ID: <75F7E67FC45F6744A7D328D41E35376D013EED@mail.webwasher.com>
Thread-Topic: HTTP/OCP protocol binding
Thread-Index: AcMm/IZrndR7sIrCR8i/5JZXDcBW6QB3hvdA
From: "Martin Stecher" <martin.stecher@webwasher.com>
To: "OPES WG (E-mail)" <ietf-openproxy@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h528TbAF016821
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 8bit


> > > I would use some very simple encoding to pass HTTP
> > > messages in OCP payload. Something along these lines:
> > >
> > > 	<chunk-type> <chunk-length> <chunk-data>
> > >
> > > where "chunk-type" can be either of
> > > 	"headers":  HTTP headers including the first line and the last
> > > 	            CRLF terminator
> > > 	"trailers": HTTP trailers including the last CRLF terminator
> > > 	"body":     raw HTTP message payload
> > > 	"all":      raw HTTP message
> > > and one OCP payload may contain several chunks in the 
> above format.
> > >
> >
> > For a HTTP response we need the original HTTP request as additional
> > meta data. That needs to be added somehow.
> 
> Indeed, I forgot about that requirement. Will having both "request-*"
> and "response-*" chunk types be too complicated?
> 
> 	request-headers, response-headers
> 	request-trailers, response-trailers
> 	request-body, response-body
> 	request-all, response-all
> 
> (or the other way around: *-request and *-response).

First, I am not so sure about the "all" chunks. Do we really need them?
While having multiple options and being able to negotiate things is great, especially for OCP core, I think that the application protocol bindings should define a single way how to vector the data to the callout server.
If both OPES processor and callout server agree on HTTP/OCP they have to understand at least the basics of that protocol and so being able to differ between headers and bodies.
If actors in the OPES scenario cannot find a matching protocol binding that both support, there could/should be a File/OCP and Raw-TCP/OCP that may work out sometimes as fallback.


Second, is it necessary that the application procotol chunks encoding is another abstraction layer on top of the data-have messages?
Why do we not just introduce a named parameter (Content-Type or Payload-Type) for data-have and use this core message type to send the chunks? Chunk length is then without additional cost and no extra encoding needs to be parsed.

The protocol binding will then define which payload types exist, whether there is a given order and whether multiple data-have messages per payload type are allowed.


> 
> We will also have to explicitly document what to do with 1xx HTTP/1.1
> responses. It would be nice if we can adapt them, but I do not know
> yet whether they have to be treated specially from HTTP binding point
> of view.

Good point.
It probably makes no sense to handle a 1xx as its own transaction. It could be another response header but we will need to explain this clearly in the draft otherwise we will get interop problems because many implementations will probably oversee this point.


Regarding the transfer encoding:

Seems that we agree that OPES processor and callout server will negotiate which is supported; identity MUST be supported. OPES processor MAY/SHOULD have some pre-processing to remove a transfer encoding that it supports but the callout server doesn't.



Regarding content length and persistency:

We agree that the OPES processor is responsible to handle HTTP persistency and that it is impossible to have a protocol which is so robust that it overcomes all buggy implementations.

But I think that we can reduce the problem and enforce the OPES processor responsibility by defining:
 - the OPES processor MUST ignore the Content-Length header returned in the response header chunk from the callout server
 - a callout server SHOULD indicate the application message length via the sizep parameter in the start-app-message if it is known at that time.
 - the OPES processor SHOULD honor the sizep parameter and use it to adjust the Content-Length header; otherwise it MUST remove the Content-Length header; it MAY then switch to chunked transfer encoding if supported by the client for being able to keep the HTTP connection alive.

With this approach many callout services that only concentrate on the HTTP body can ignore the header and use data-as-is rather than parsing the header, finding and adjusting the ContentLength header, reassembing the header and sending it back.

What do you think about this?


Regards
Martin




From owner-ietf-openproxy@mail.imc.org  Mon Jun  2 12:27: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 MAA14178
	for <opes-archive@ietf.org>; Mon, 2 Jun 2003 12:27:46 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Ms8I-0004XK-00
	for opes-archive@ietf.org; Mon, 02 Jun 2003 12:26:02 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Ms8H-0004XH-00
	for opes-archive@ietf.org; Mon, 02 Jun 2003 12:26: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 h52GD2AF052268
	for <ietf-openproxy-bks@above.proper.com>; Mon, 2 Jun 2003 09:13: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 h52GD2SE052267
	for ietf-openproxy-bks; Mon, 2 Jun 2003 09:13: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 h52GCmAF052255
	for <ietf-openproxy@imc.org>; Mon, 2 Jun 2003 09:13:00 -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 h52GCn2R069630;
	Mon, 2 Jun 2003 10:12:49 -0600 (MDT)
	(envelope-from rousskov@measurement-factory.com)
Received: (from rousskov@localhost)
	by measurement-factory.com (8.12.9/8.12.5/Submit) id h52GCmS3069629;
	Mon, 2 Jun 2003 10:12:48 -0600 (MDT)
	(envelope-from rousskov)
Date: Mon, 2 Jun 2003 10:12:48 -0600 (MDT)
From: Alex Rousskov <rousskov@measurement-factory.com>
To: "OPES WG (E-mail)" <ietf-openproxy@imc.org>
Subject: RE: HTTP/OCP protocol binding
In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D013EED@mail.webwasher.com>
Message-ID: <Pine.BSF.4.53.0306021010240.68030@measurement-factory.com>
References: <75F7E67FC45F6744A7D328D41E35376D013EED@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: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>



On Mon, 2 Jun 2003, Martin Stecher wrote:

> First, I am not so sure about the "all" chunks. Do we really need
> them? While having multiple options and being able to negotiate
> things is great, especially for OCP core, I think that the
> application protocol bindings should define a single way how to
> vector the data to the callout server. If both OPES processor and
> callout server agree on HTTP/OCP they have to understand at least
> the basics of that protocol and so being able to differ between
> headers and bodies. If actors in the OPES scenario cannot find a
> matching protocol binding that both support, there could/should be a
> File/OCP and Raw-TCP/OCP that may work out sometimes as fallback.

Good point. The reason to keep "all" chunks could be OPES processor
performance. In many cases, it may be more efficient for the processor
to send data as it received it (raw), even though it had parsed it
internally. Nevertheless, I agree that "all" chunks should be removed
from HTTP binding until we have a better HTTP-specific justification for
them.

On the other hand, I think we should define HTTP binding in such a way
that it would be possible to use data (OCP payload) encodings from other
bindings. It should be possible to negotiate data encoding after
negotiating HTTP binding (HTTP binding comes with a default encoding, of
course). This will make it simple to use "raw" and other useful
encodings for HTTP adaptations. We should try to make data encoding (and
other things) reusable across application bindings.

> Second, is it necessary that the application procotol chunks
> encoding is another abstraction layer on top of the data-have
> messages? Why do we not just introduce a named parameter
> (Content-Type or Payload-Type) for data-have and use this core
> message type to send the chunks? Chunk length is then without
> additional cost and no extra encoding needs to be parsed.

It is possible to move the data type field to OCP. Doing so will limit
you to one chunk per OCP message, but that is probably not such a big
deal if we keep data-have messages efficient. It certainly simplifies
the protocol so we should try to do that, I guess.

> The protocol binding will then define which payload types exist,
> whether there is a given order and whether multiple data-have
> messages per payload type are allowed.

I suggest that we keep the App-Message-Part parameter HTTP-specific for
now. Not all application protocols will have different "parts" of
messages to be concerned about or will be able to describe those parts
with a simple parameter value.

> It probably makes no sense to handle a 1xx as its own transaction.
> It could be another response header but we will need to explain this
> clearly in the draft otherwise we will get interop problems because
> many implementations will probably oversee this point.

Treating 1xx as headers is a kludge that may break services, especially
those that mingle with headers. Moreover, you would still need some way
to distinguish 1xx and "normal" headers unless you want the callout
server to rely on response lines as separators. Finally, some callout
servers might _generate_ 1xx responses and, hence, may prefer a more
"direct" approach (but response generation is a much bigger problem, of
course).

Overall, I suspect we should treat a 1xx response as an application
message it is, just like a 200 OK response, but we can postpone this
debate.

> Regarding the transfer encoding:
>
> Seems that we agree that OPES processor and callout server will
> negotiate which is supported; identity MUST be supported. OPES
> processor MAY/SHOULD have some pre-processing to remove a transfer
> encoding that it supports but the callout server doesn't.

Yes.

> Regarding content length and persistency:
>
> We agree that the OPES processor is responsible to handle HTTP
> persistency and that it is impossible to have a protocol which is so
> robust that it overcomes all buggy implementations.

Yes.

> But I think that we can reduce the problem and enforce the OPES
> processor responsibility by defining:
>
>  - the OPES processor MUST ignore the Content-Length header returned
>    in the response header chunk from the callout server

This seems too restrictive to me. If, for example, the same company
makes the OPES processor and the callout server, they would want to
avoid extra work and would prefer to honor the Content-Length header
generated by the callout server they trust as much as the processor.

Perhaps you mean that sizep parameter should be used in this case, and
the Content-Length header should still be ignored.

>  - a callout server SHOULD indicate the application message length
>    via the sizep parameter in the start-app-message if it is known at
>    that time.

Why not a MUST? If something so important is known, why not report it?

>  - the OPES processor SHOULD honor the sizep parameter and use it to
>    adjust the Content-Length header;

OK.

> otherwise it MUST remove the Content-Length header; it MAY then
> switch to chunked transfer encoding if supported by the client for
> being able to keep the HTTP connection alive.

Or it can try to buffer the entire response first to calculate the
true Content-Length value.

> With this approach many callout services that only concentrate on
> the HTTP body can ignore the header and use data-as-is rather than
> parsing the header, finding and adjusting the ContentLength header,
> reassembing the header and sending it back.

True, but it seems we are building a very specific/rigid/low-level
solution to the part of the problem where a more general and flexible
solution is possible. What you describe in the above paragraph hints at
the true problem at hand. Some (many?) services have these
characteristics:

    - they need to know message "headers" (processor must send them)
    - they modify "content" or "body"
    - their modifications bring original "header" out of sync
    - they would prefer not to sync message "headers"
    - we think it may be safer for OPES processor to sync the headers

What we may need is a mechanism for the callout server to tell OPES
processor to [re]compute the adapted headers while still providing
original ones:

    * data-i-have
      I tell you what to send;
      I believe the data I have is accurate
      (this is the current data-have message)

    * data-you-have
      I tell you what to send, but I modified nothing, so just
      use your own copy you told me you have;
      I believe the data I have is accurate
      (this is the current data-as-is message)

    * data-you-check
      I tell you what to send;
      I believe the data I have is not accurate enough so please
      check and recompute everything you can as needed

An application binding can use the above mechanism in addition to sizep
and other features to require OPES processor to recompute "headers" when
a callout server sends then via data-you-check OCP message.

The above "content length" thoughts are very unpolished. We need to work
more on this...


Thank you,

Alex.




From owner-ietf-openproxy@mail.imc.org  Mon Jun  2 14:53: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 OAA18830
	for <opes-archive@ietf.org>; Mon, 2 Jun 2003 14:53:20 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19MuP8-0005VE-00
	for opes-archive@ietf.org; Mon, 02 Jun 2003 14:51:35 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19MuP8-0005V7-00
	for opes-archive@ietf.org; Mon, 02 Jun 2003 14:51:34 -0400
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h52IdlAF059221
	for <ietf-openproxy-bks@above.proper.com>; Mon, 2 Jun 2003 11:39: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 h52Idlff059220
	for ietf-openproxy-bks; Mon, 2 Jun 2003 11:39: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 h52IdjAF059215
	for <ietf-openproxy@imc.org>; Mon, 2 Jun 2003 11:39:46 -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 h52Idk2R074009;
	Mon, 2 Jun 2003 12:39:46 -0600 (MDT)
	(envelope-from rousskov@measurement-factory.com)
Received: (from rousskov@localhost)
	by measurement-factory.com (8.12.9/8.12.5/Submit) id h52IdkVl074008;
	Mon, 2 Jun 2003 12:39:46 -0600 (MDT)
	(envelope-from rousskov)
Date: Mon, 2 Jun 2003 12:39:46 -0600 (MDT)
From: Alex Rousskov <rousskov@measurement-factory.com>
To: OPES WG <ietf-openproxy@imc.org>
Subject: Re: Capability Negotiation for OCP
In-Reply-To: <200304172215.h3HMFFY01277@localhost.localdomain>
Message-ID: <Pine.BSF.4.53.0306021130070.68030@measurement-factory.com>
References: <200304172215.h3HMFFY01277@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>



On Thu, 17 Apr 2003, The Purple Streak, Hilarie Orman wrote:

> PPP, IPSec and IKE use "offer, select".  The trick is to spell out
> the complete set of selections at offer time.  Don't say (A1 or A2)
> and (B1 or B2) if (A1 and B2) is not permitted - say instead
>
> 	{ A2 and (B1 or B2) } or { A1 and B1}

I am adding negotiation mechanisms to the OCP draft. While describing
how negotiation works, I realized that providing a _complete_
selection "menu" in one offer would require very deep nesting of OCP
data structures or very long OR lists for some negotiations. I was
surprised that a protocol like PPP (RFC 1661) could handle that
(something the above examples imply) and read the PPP specs.

My current understanding is that PPP does not spell out all possible
selections in each offer.  Instead, it spells out one selection (e.g.,
"A2 and B1"). If that selection is rejected, a different selection is
provided (e.g., "A2 and B2"). There may be better places to quote, but
here is one direct quote from "6.2. Authentication-Protocol"

    An implementation MUST NOT include multiple Authentication-
    Protocol Configuration Options in its Configure-Request packets.
    Instead, it SHOULD attempt to configure the most desirable
    protocol first.  If that protocol is Configure-Nak'd, then the
    implementation SHOULD attempt the next most desirable protocol in
    the next Configure-Request.

I am sending this message to provide an example where multiple offer
messages are used. I am not, at this point, advocating either approach
(a single complex and complete offer versus a series of simple
incomplete offers, each requiring immediate response). If you have any
preferences or suggestions, please voice them!

Thank you,

Alex.

P.S. I did not have enough energy/time to understand whether IKE and
     IPSec support multiple offer messages within the same negotiation
     phase. They do support multiple OR choices within one message.


From owner-ietf-openproxy@mail.imc.org  Mon Jun  2 23:30: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 XAA05697
	for <opes-archive@ietf.org>; Mon, 2 Jun 2003 23:30:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19N2U6-0001Io-00
	for opes-archive@ietf.org; Mon, 02 Jun 2003 23:29:14 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19N2U5-0001Il-00
	for opes-archive@ietf.org; Mon, 02 Jun 2003 23:29: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 h533K0AF084574
	for <ietf-openproxy-bks@above.proper.com>; Mon, 2 Jun 2003 20:20:00 -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 h533K0LB084573
	for ietf-openproxy-bks; Mon, 2 Jun 2003 20:20:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f
Received: from smtp-out.comcast.net (smtp-out.comcast.net [24.153.64.116])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h533JwAF084564
	for <ietf-openproxy@imc.org>; Mon, 2 Jun 2003 20:19:58 -0700 (PDT)
	(envelope-from markus@mhof.com)
Received: from mhof.com ([135.104.20.71])
 by mtaout01.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May
 14 2003)) with ESMTPA id <0HFV00KO9YGZFX@mtaout01.icomcast.net> for
 ietf-openproxy@imc.org; Mon, 02 Jun 2003 23:17:26 -0400 (EDT)
Date: Mon, 02 Jun 2003 23:17:24 -0400
From: Markus Hofmann <markus@mhof.com>
Subject: Draft Agenda for IETF 57
To: OPES Group <ietf-openproxy@imc.org>
Message-id: <3EDC1344.3040209@mhof.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4)
 Gecko/20030529
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7BIT


Hi,

we're starting to put together an agenda for the upcoming WG meeting 
in Vienna.

Main focus will be on the protocol work, and some time will be spent 
on the "IAB consideration" document and on the "Tracing/bypass" document.

For a tentive agenda please see below. Let us know if you've any comments.

Thanks,
   Markus

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

Open Pluggable Edge Services WG (opes)
======================================

DRAFT AGENDA:
    - Introduction, minutes taker, blue sheets
    - Agenda bashing
    - Work on "Tracing/Bypass" document
    - Work on callout protocol
    - Work on "IAB considerations" document



From owner-ietf-openproxy@mail.imc.org  Tue Jun  3 07:49: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 HAA27635
	for <opes-archive@ietf.org>; Tue, 3 Jun 2003 07:49:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19NAG9-0004D7-00
	for opes-archive@ietf.org; Tue, 03 Jun 2003 07:47:21 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19NAG8-0004D2-00
	for opes-archive@ietf.org; Tue, 03 Jun 2003 07:47: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 h53BZLAF036551
	for <ietf-openproxy-bks@above.proper.com>; Tue, 3 Jun 2003 04:37:51 -0700 (PDT)
	(envelope-from owner-ietf-openproxy@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h53BZLZA036550
	for ietf-openproxy-bks; Tue, 3 Jun 2003 04:35:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f
Received: from jay.songbird.com (208.184.79.253.songbird.com [208.184.79.253] (may be forged))
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h53BWoAF036489
	for <ietf-openproxy@imc.org>; Tue, 3 Jun 2003 04:35:20 -0700 (PDT)
	(envelope-from GK-lists@ninebynine.org)
Received: from Rincewind.ninebynine.org (jay.songbird.com [208.184.79.253])
	(authenticated)
	by jay.songbird.com (8.11.6/8.11.3) with ESMTP id h53BWj004173;
	Tue, 3 Jun 2003 04:32:45 -0700
Message-Id: <5.1.0.14.2.20030603095445.02af7258@127.0.0.1>
X-Sender: gk-lists@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 03 Jun 2003 10:05:01 +0100
To: Alex Rousskov <rousskov@measurement-factory.com>,
        OPES WG <ietf-openproxy@imc.org>
From: Graham Klyne <GK-lists@ninebynine.org>
Subject: Re: Capability Negotiation for OCP
In-Reply-To: <Pine.BSF.4.53.0306021130070.68030@measurement-factory.com>
References: <200304172215.h3HMFFY01277@localhost.localdomain>
 <200304172215.h3HMFFY01277@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


I don't know if it helps, but some similar issues to those you mention were 
addressed in the content negotiation work I did a while back (RFC2533).

One of my goals was to avoid the kind of ordering-dependency you describe 
for PPP -- in my view, although that makes implementation easier, it also 
increases the scope for unintended outcomes.  But, then, the RFC2533 
algorithm doesn't really provide for selecting a preferred feature among 
available alternatives, even though the format used has a rudimentary 
mechanism to express such preferences.  There are some theoretical problems 
in doing this in a completely general fashion.

FWIW, there's also an implementation, in Java, of the RFC2533 algorithm 
available at:
   http://www.ninebynine.org/Software/Intro.html#RFC2533FeatureSetMatching
to demonstrate that the RFC2533 matching algorithm is reasonably realizable.

One of the things I noticed when playing with the algorithm, which involves 
automatically converting the feature expression to "disjunctive normal 
form", is that one can easily end up with long lists of ANDed 
conditions.  Similar applies to "conjunctive normal form", where one ends 
up with long lists of ORed conditions.  But at least, using this kind of 
framework, one isn't forced to actually *transmit* these long lists.

#g
--

At 12:39 02/06/03 -0600, Alex Rousskov wrote:


>On Thu, 17 Apr 2003, The Purple Streak, Hilarie Orman wrote:
>
> > PPP, IPSec and IKE use "offer, select".  The trick is to spell out
> > the complete set of selections at offer time.  Don't say (A1 or A2)
> > and (B1 or B2) if (A1 and B2) is not permitted - say instead
> >
> >       { A2 and (B1 or B2) } or { A1 and B1}
>
>I am adding negotiation mechanisms to the OCP draft. While describing
>how negotiation works, I realized that providing a _complete_
>selection "menu" in one offer would require very deep nesting of OCP
>data structures or very long OR lists for some negotiations. I was
>surprised that a protocol like PPP (RFC 1661) could handle that
>(something the above examples imply) and read the PPP specs.
>
>My current understanding is that PPP does not spell out all possible
>selections in each offer.  Instead, it spells out one selection (e.g.,
>"A2 and B1"). If that selection is rejected, a different selection is
>provided (e.g., "A2 and B2"). There may be better places to quote, but
>here is one direct quote from "6.2. Authentication-Protocol"
>
>     An implementation MUST NOT include multiple Authentication-
>     Protocol Configuration Options in its Configure-Request packets.
>     Instead, it SHOULD attempt to configure the most desirable
>     protocol first.  If that protocol is Configure-Nak'd, then the
>     implementation SHOULD attempt the next most desirable protocol in
>     the next Configure-Request.
>
>I am sending this message to provide an example where multiple offer
>messages are used. I am not, at this point, advocating either approach
>(a single complex and complete offer versus a series of simple
>incomplete offers, each requiring immediate response). If you have any
>preferences or suggestions, please voice them!
>
>Thank you,
>
>Alex.
>
>P.S. I did not have enough energy/time to understand whether IKE and
>      IPSec support multiple offer messages within the same negotiation
>      phase. They do support multiple OR choices within one message.

-------------------
Graham Klyne
<GK@NineByNine.org>
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E



From owner-ietf-openproxy@mail.imc.org  Tue Jun  3 12:26: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 MAA13278
	for <opes-archive@ietf.org>; Tue, 3 Jun 2003 12:26:56 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19NEb0-0000GF-00
	for opes-archive@ietf.org; Tue, 03 Jun 2003 12:25:10 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19NEaz-0000GA-00
	for opes-archive@ietf.org; Tue, 03 Jun 2003 12:25: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 h53Fp2AF051603
	for <ietf-openproxy-bks@above.proper.com>; Tue, 3 Jun 2003 08:53: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 h53Fp20C051601
	for ietf-openproxy-bks; Tue, 3 Jun 2003 08:51: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 h53FmUAF051510
	for <ietf-openproxy@imc.org>; Tue, 3 Jun 2003 08:51:00 -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 h53FmV2R004105;
	Tue, 3 Jun 2003 09:48:31 -0600 (MDT)
	(envelope-from rousskov@measurement-factory.com)
Received: (from rousskov@localhost)
	by measurement-factory.com (8.12.9/8.12.5/Submit) id h53FmVvH004104;
	Tue, 3 Jun 2003 09:48:31 -0600 (MDT)
	(envelope-from rousskov)
Date: Tue, 3 Jun 2003 09:48:31 -0600 (MDT)
From: Alex Rousskov <rousskov@measurement-factory.com>
To: Graham Klyne <GK-lists@ninebynine.org>
cc: OPES WG <ietf-openproxy@imc.org>
Subject: Re: Capability Negotiation for OCP
In-Reply-To: <5.1.0.14.2.20030603095445.02af7258@127.0.0.1>
Message-ID: <Pine.BSF.4.53.0306030925020.2479@measurement-factory.com>
References: <200304172215.h3HMFFY01277@localhost.localdomain>
 <200304172215.h3HMFFY01277@localhost.localdomain> <5.1.0.14.2.20030603095445.02af7258@127.0.0.1>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>



On Tue, 3 Jun 2003, Graham Klyne wrote:

> I don't know if it helps, but some similar issues to those you
> mention were addressed in the content negotiation work I did a while
> back (RFC2533).

Thanks for the pointer! It looks like your RFC may be very useful to
OCP implementors, especially if we decide to support complex feature
expressions like "(A2 and (B1 or B2)) or (A1 and B1)" as opposed to
simple (but, as you note, potentially very long) "normal" AND/OR
lists. My undestanding is that RFC 2533 outlines a way to
pragmatically match [complex] feature expressions in negotiation
offers with available/desired capabilities, also a [complex] feature
expression. A how-to document replacing a dry book on boolean algebra,
sort of.


My current intention is to use very simple expressions. I convinced
myself that it is the right starting point after looking at what
negotiation mechanisms are offered by a few existing protocols that
are somewhat similar to OCP (BEEP, PPP, IKE*, etc). I did not find
anything that supports negotiation using really complicated feature
expressions. Yet, these protocols "work". Thus, I decided it would be
OK to start with something simple and extend the interface only of
actual need is detected.

I also agree that ordering dependency may lead to suboptimal
negotiations. However, again, it looks like our environment is simple
and structured enough to marginalize that risk.

Your application domain is probably different -- it already has a
pressing need for complicated content descriptions.

Thank you,

Alex.

P.S. RFC 2533 is the first RFC I have seen that mentions Prolog,
     nice work!


From owner-ietf-openproxy@mail.imc.org  Tue Jun  3 14:47: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 OAA19226
	for <opes-archive@ietf.org>; Tue, 3 Jun 2003 14:47:32 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19NGn2-0001j3-00
	for opes-archive@ietf.org; Tue, 03 Jun 2003 14:45:44 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19NGn1-0001j0-00
	for opes-archive@ietf.org; Tue, 03 Jun 2003 14:45:43 -0400
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h53IWUAF058575
	for <ietf-openproxy-bks@above.proper.com>; Tue, 3 Jun 2003 11:35:00 -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 h53IWU1v058574
	for ietf-openproxy-bks; Tue, 3 Jun 2003 11:32: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.9/8.12.8) with ESMTP id h53ITwAF058542
	for <ietf-openproxy@imc.org>; Tue, 3 Jun 2003 11:32:28 -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 h53ITx2R009207
	for <ietf-openproxy@imc.org>; Tue, 3 Jun 2003 12:29:59 -0600 (MDT)
	(envelope-from rousskov@measurement-factory.com)
Received: (from rousskov@localhost)
	by measurement-factory.com (8.12.9/8.12.5/Submit) id h53ITxaa009206;
	Tue, 3 Jun 2003 12:29:59 -0600 (MDT)
	(envelope-from rousskov)
Date: Tue, 3 Jun 2003 12:29:59 -0600 (MDT)
From: Alex Rousskov <rousskov@measurement-factory.com>
To: OPES WG <ietf-openproxy@imc.org>
Subject: OCP Core version head_sid9 available
Message-ID: <Pine.BSF.4.53.0306031222220.2479@measurement-factory.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>



The log of major changes is quoted below. The latest snapshot,
including XML sources for those doing hands-on modifications, is
available at

	http://www.measurement-factory.com/tmp/opes/

Please continue to comment and work on the to-do list.

Thank you,

Alex.

-------------- change log ----------------

head-sid9

      *  Added Negotiation and Capability Inquiry sections

      *  Deleted data-end message because AME (Application Message End)
         already does the same thing and because there is no data-start
         message.

      *  Deleted meta-* messages. Data-* messages are now used for both
         metadata and data since OCP does not know the difference, but
         must provide the same exchange mechanism for both.

      *  Use a single message name (short or long, depending on the
         message) instead of using full and abbreviated versions and
         trying to enforce abbreviations on the wire. Be more consistent
         in creating short message names.

      *  Resurrected OCP scope figure based on popular demand.

      *  Applied Martin Stecher comments dated 2003/05/30.


From owner-ietf-openproxy@mail.imc.org  Wed Jun  4 04:23: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 EAA07705
	for <opes-archive@ietf.org>; Wed, 4 Jun 2003 04:23:27 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19NTWd-0007Ug-00
	for opes-archive@ietf.org; Wed, 04 Jun 2003 04:21:39 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19NTWc-0007Ud-00
	for opes-archive@ietf.org; Wed, 04 Jun 2003 04:21:38 -0400
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h5489hAF008450
	for <ietf-openproxy-bks@above.proper.com>; Wed, 4 Jun 2003 01:12: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 h5489hxM008449
	for ietf-openproxy-bks; Wed, 4 Jun 2003 01:09:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f
Received: from jay.songbird.com (208.184.79.253.songbird.com [208.184.79.253] (may be forged))
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h5487CAF008001
	for <ietf-openproxy@imc.org>; Wed, 4 Jun 2003 01:09:42 -0700 (PDT)
	(envelope-from GK-lists@ninebynine.org)
Received: from Rincewind.ninebynine.org (jay.songbird.com [208.184.79.253])
	(authenticated)
	by jay.songbird.com (8.11.6/8.11.3) with ESMTP id h54878005739;
	Wed, 4 Jun 2003 01:07:09 -0700
Message-Id: <5.1.0.14.2.20030604000828.00b9dde0@127.0.0.1>
X-Sender: gk-lists@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 04 Jun 2003 00:24:04 +0100
To: Alex Rousskov <rousskov@measurement-factory.com>
From: Graham Klyne <GK-lists@ninebynine.org>
Subject: Re: Capability Negotiation for OCP
Cc: OPES WG <ietf-openproxy@imc.org>
In-Reply-To: <Pine.BSF.4.53.0306030925020.2479@measurement-factory.com>
References: <5.1.0.14.2.20030603095445.02af7258@127.0.0.1>
 <200304172215.h3HMFFY01277@localhost.localdomain>
 <200304172215.h3HMFFY01277@localhost.localdomain>
 <5.1.0.14.2.20030603095445.02af7258@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


Some other data points to maybe consider...

I believe some sip/sdp-related work on content negotiation looked at this 
(RFC2533) and decided that they did not want to go with the full algebraic 
complexity.  So (I think) they took an approach of profiling the structure 
to use a normal-form subset which is inherently easier to process.  A 
possible advantage of this approach is that it leaves a clear path to 
introduce more general forms of expression of they are later found to be 
needed.  Sorry, I have no specific references for this.

On ordering, that may be a difficult dependency to evolve away from once it 
has been introduced.

And finally, having some similarities with the RFC2533 approach, there has 
been research into a topic known as "description logics" over the past 
(approx) 15 years that takes a slightly different slice on the use of 
logical expressions to describe things.  The goal of this work has been to 
balance expressive power with computational tractability.  (It can be shown 
that a fully generalized solution based on first order predicate logic is 
not always decideable.)  The key idea is being able to perform a 
subsumption computation,  finding a description that minimally subsumes two 
or more given descriptions.  I found a paper by Alex Borgida was a useful 
introduction, though there are many others:
   http://citeseer.nj.nec.com/borgida95description.html
or:
   http://www.cs.rutgers.edu/~borgida/
   (Look for "Description Logics in Data Management (1995)")

#g
--

At 09:48 03/06/03 -0600, Alex Rousskov wrote:

>On Tue, 3 Jun 2003, Graham Klyne wrote:
>
> > I don't know if it helps, but some similar issues to those you
> > mention were addressed in the content negotiation work I did a while
> > back (RFC2533).
>
>Thanks for the pointer! It looks like your RFC may be very useful to
>OCP implementors, especially if we decide to support complex feature
>expressions like "(A2 and (B1 or B2)) or (A1 and B1)" as opposed to
>simple (but, as you note, potentially very long) "normal" AND/OR
>lists. My undestanding is that RFC 2533 outlines a way to
>pragmatically match [complex] feature expressions in negotiation
>offers with available/desired capabilities, also a [complex] feature
>expression. A how-to document replacing a dry book on boolean algebra,
>sort of.
>
>
>My current intention is to use very simple expressions. I convinced
>myself that it is the right starting point after looking at what
>negotiation mechanisms are offered by a few existing protocols that
>are somewhat similar to OCP (BEEP, PPP, IKE*, etc). I did not find
>anything that supports negotiation using really complicated feature
>expressions. Yet, these protocols "work". Thus, I decided it would be
>OK to start with something simple and extend the interface only of
>actual need is detected.
>
>I also agree that ordering dependency may lead to suboptimal
>negotiations. However, again, it looks like our environment is simple
>and structured enough to marginalize that risk.
>
>Your application domain is probably different -- it already has a
>pressing need for complicated content descriptions.
>
>Thank you,
>
>Alex.
>
>P.S. RFC 2533 is the first RFC I have seen that mentions Prolog,
>      nice work!

-------------------
Graham Klyne
<GK@NineByNine.org>
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E



From owner-ietf-openproxy@mail.imc.org  Wed Jun  4 11:38: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 LAA27300
	for <opes-archive@ietf.org>; Wed, 4 Jun 2003 11:38:05 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19NaJF-0004XH-00
	for opes-archive@ietf.org; Wed, 04 Jun 2003 11:36:17 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19NaJE-0004XD-00
	for opes-archive@ietf.org; Wed, 04 Jun 2003 11:36: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 h54FLhAF037007
	for <ietf-openproxy-bks@above.proper.com>; Wed, 4 Jun 2003 08:21: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 h54FLhsv037006
	for ietf-openproxy-bks; Wed, 4 Jun 2003 08:21: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.9/8.12.8) with ESMTP id h54FLfAF036999
	for <ietf-openproxy@imc.org>; Wed, 4 Jun 2003 08:21: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 h54FLg2R039770;
	Wed, 4 Jun 2003 09:21:42 -0600 (MDT)
	(envelope-from rousskov@measurement-factory.com)
Received: (from rousskov@localhost)
	by measurement-factory.com (8.12.9/8.12.5/Submit) id h54FLVGb039769;
	Wed, 4 Jun 2003 09:21:31 -0600 (MDT)
	(envelope-from rousskov)
Date: Wed, 4 Jun 2003 09:21:31 -0600 (MDT)
From: Alex Rousskov <rousskov@measurement-factory.com>
To: Graham Klyne <GK-lists@ninebynine.org>
cc: OPES WG <ietf-openproxy@imc.org>
Subject: Re: Capability Negotiation for OCP
In-Reply-To: <5.1.0.14.2.20030604000828.00b9dde0@127.0.0.1>
Message-ID: <Pine.BSF.4.53.0306040907460.38923@measurement-factory.com>
References: <5.1.0.14.2.20030603095445.02af7258@127.0.0.1>
 <200304172215.h3HMFFY01277@localhost.localdomain>
 <200304172215.h3HMFFY01277@localhost.localdomain> <5.1.0.14.2.20030603095445.02af7258@127.0.0.1>
 <5.1.0.14.2.20030604000828.00b9dde0@127.0.0.1>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


On Wed, 4 Jun 2003, Graham Klyne wrote:

> I believe some sip/sdp-related work on content negotiation looked at
> this (RFC2533) and decided that they did not want to go with the
> full algebraic complexity.  So (I think) they took an approach of
> profiling the structure to use a normal-form subset which is
> inherently easier to process.  A possible advantage of this approach
> is that it leaves a clear path to introduce more general forms of
> expression of they are later found to be needed.  Sorry, I have no
> specific references for this.

I think this is what we are doing right now as well. We use a
normalized disjunction, essentially. It is simple and can be extended
if we need something more complex.

> On ordering, that may be a difficult dependency to evolve away from
> once it has been introduced.

I agree, but some ordering is impossible to avoid. For example, one
may want to encrypt connection before talking about _anything_ else.
That introduces an order dependency: negotiate encryption first and
everything else later. Authentication has a similar side-effect (I
will not negotiate with you about anything else until I know who you
are).

Also, one of our requirements is that some features can be
[re]negotiated in the middle of a transaction. Supporting this in a
sane way requires partial negotiation (negotiation of a subset of
features) which is very similar to ordering.

> And finally, having some similarities with the RFC2533 approach,
> there has been research into a topic known as "description logics"
> over the past (approx) 15 years that takes a slightly different
> slice on the use of logical expressions to describe things.  The
> goal of this work has been to balance expressive power with
> computational tractability.  (It can be shown that a fully
> generalized solution based on first order predicate logic is not
> always decideable.)  The key idea is being able to perform a
> subsumption computation, finding a description that minimally
> subsumes two or more given descriptions.  I found a paper by Alex
> Borgida was a useful introduction, though there are many others:
>    http://citeseer.nj.nec.com/borgida95description.html
> or:
>    http://www.cs.rutgers.edu/~borgida/
>    (Look for "Description Logics in Data Management (1995)")

Hmm... Looks interesting. I think we may need to investigate all these
options if we decide to increase the current level of complexity
to express more complicated configuration dependencies. I remain
hopeful that our current simple scheme is enough for OPES needs, but
I would not be surprised if I am proven wrong by real-world demands.

Thank you,

Alex.


> At 09:48 03/06/03 -0600, Alex Rousskov wrote:
>
> >On Tue, 3 Jun 2003, Graham Klyne wrote:
> >
> > > I don't know if it helps, but some similar issues to those you
> > > mention were addressed in the content negotiation work I did a while
> > > back (RFC2533).
> >
> >Thanks for the pointer! It looks like your RFC may be very useful to
> >OCP implementors, especially if we decide to support complex feature
> >expressions like "(A2 and (B1 or B2)) or (A1 and B1)" as opposed to
> >simple (but, as you note, potentially very long) "normal" AND/OR
> >lists. My undestanding is that RFC 2533 outlines a way to
> >pragmatically match [complex] feature expressions in negotiation
> >offers with available/desired capabilities, also a [complex] feature
> >expression. A how-to document replacing a dry book on boolean algebra,
> >sort of.
> >
> >
> >My current intention is to use very simple expressions. I convinced
> >myself that it is the right starting point after looking at what
> >negotiation mechanisms are offered by a few existing protocols that
> >are somewhat similar to OCP (BEEP, PPP, IKE*, etc). I did not find
> >anything that supports negotiation using really complicated feature
> >expressions. Yet, these protocols "work". Thus, I decided it would be
> >OK to start with something simple and extend the interface only of
> >actual need is detected.
> >
> >I also agree that ordering dependency may lead to suboptimal
> >negotiations. However, again, it looks like our environment is simple
> >and structured enough to marginalize that risk.
> >
> >Your application domain is probably different -- it already has a
> >pressing need for complicated content descriptions.
> >
> >Thank you,
> >
> >Alex.
> >
> >P.S. RFC 2533 is the first RFC I have seen that mentions Prolog,
> >      nice work!


From owner-ietf-openproxy@mail.imc.org  Wed Jun  4 13: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 NAA02478
	for <opes-archive@ietf.org>; Wed, 4 Jun 2003 13:26:03 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Nbzj-0005vJ-00
	for opes-archive@ietf.org; Wed, 04 Jun 2003 13:24:15 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Nbzj-0005vG-00
	for opes-archive@ietf.org; Wed, 04 Jun 2003 13:24: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 h54HERAF045267
	for <ietf-openproxy-bks@above.proper.com>; Wed, 4 Jun 2003 10:14:27 -0700 (PDT)
	(envelope-from owner-ietf-openproxy@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h54HERX7045266
	for ietf-openproxy-bks; Wed, 4 Jun 2003 10:14: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.9/8.12.8) with ESMTP id h54HEPAF045260
	for <ietf-openproxy@imc.org>; Wed, 4 Jun 2003 10:14: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 h54HER2R042402;
	Wed, 4 Jun 2003 11:14:27 -0600 (MDT)
	(envelope-from rousskov@measurement-factory.com)
Received: (from rousskov@localhost)
	by measurement-factory.com (8.12.9/8.12.5/Submit) id h54HERot042401;
	Wed, 4 Jun 2003 11:14:27 -0600 (MDT)
	(envelope-from rousskov)
Date: Wed, 4 Jun 2003 11:14:27 -0600 (MDT)
From: Alex Rousskov <rousskov@measurement-factory.com>
To: OPES WG <ietf-openproxy@imc.org>
Subject: RE: OCP Core version head_sid6 available
In-Reply-To: <17CD205CE8D7E24BBE16E4FEE22526CB38DB66@hermes.webwasher.com>
Message-ID: <Pine.BSF.4.53.0306041047210.38923@measurement-factory.com>
References: <17CD205CE8D7E24BBE16E4FEE22526CB38DB66@hermes.webwasher.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>



On Wed, 21 May 2003, Martin Stecher wrote:

> > > If services is an optional xaction-start parameter, why not also
> > > make it an optional parameter of connection-start? If OPES
> > > processor wants to use the default service for a connection
> > > feature, it could set it already with the connection-start
> > > message rather than sending an extra connection-services
> > > message. Same for connection-priority?
> >
> > I agree that the current specs are inconsistent. I am not sure
> > what the right fix is though. We can limit support to a dedicated
> > message for each state change (e.g., connection-priority) or we
> > can have both dedicated messages and message parameters (e.g.,
> > priority parameter in a connection-start message). Note that
> > dedicated messages are required because sometimes you want to
> > change the state in the middle of a "process" (e.g., change
> > priority or default services of an existing connection).
>
> Can you give me an example where changing of priority or default
> service is required?

Changing priority:

	A processor establishes a connection with a callout server.
	Uses default priority for a while. Then the processor
	receives a message from an "important" client. The processor
	raises the priority to speed up processing of the
	transaction. An alternative is to open another connection,
	or to keep an idle high-priority connection around, waiting
	for VIP messages.

	This is not a very convincing example; perhaps a time-based
	example I used below would be better. However, I am not even
	sure the whole priority concept needs to be supported. Do you
	think we should yank priorities out of the Core?

	Do you expect many implementations support priority/QoS
	optimizations?

Changing service:

	A processor establishes a connection with a callout server
	and sets a default service to filter viruses. Then the
	processor receives a message that can contain a virus, but
	that also needs translation. The processor adds translation
	service ID to the list of default services, for this
	transaction only.

	Another example where the default for the connection is
	changed: From 8-17, employees are prohibited to surf porn.
	From 17-8, employees (working over time) are allowed to
	surf porn as a stimulus or whatever. Viruses should
	be checked for at any time. The default connection
	services will change at 8 and 17 hours. An alternative
	would be to open a new connection, of course.

	Also, keep in mind that connection is not encrypted
	when Connection Start message is sent. A list of services
	may be confidential and would need to be exchanged after
	the transport is encrypted, via a designated message.
	An alternative is to re-send a Connection Start message
	after the transport is encrypted (BEEP does that, I think),
	but it feels like a kludge to me.

Overall, I think that overwriting default connection services on
transaction basis is an important feature. Changing connection
defaults is not an important feature, but having a separate message
allows us to keep a list of services private.

To keep things symmetric we can do this:
	- no dedicated Connection Services (CSvcs) message
	- Connection Start (CS) and Transaction Start (TS)
	  messages have a Services parameter
	- transport negotiations MAY happen before
	  Connection Start (CS) message

Would you prefer this? I think I would. The last item may sound
strange, but I think it is actually the right thing to do because, in
theory, a single transport connection can carry multiple OCP
connections and so transport negotiations are one level above OCP
connections.

Thanks,

Alex.


From owner-ietf-openproxy@mail.imc.org  Wed Jun  4 14:23: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 OAA04816
	for <opes-archive@ietf.org>; Wed, 4 Jun 2003 14:23:36 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19NctO-0006VN-00
	for opes-archive@ietf.org; Wed, 04 Jun 2003 14:21:46 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19NctN-0006VK-00
	for opes-archive@ietf.org; Wed, 04 Jun 2003 14:21:45 -0400
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h54I8rAF047124
	for <ietf-openproxy-bks@above.proper.com>; Wed, 4 Jun 2003 11:11:23 -0700 (PDT)
	(envelope-from owner-ietf-openproxy@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h54I8rLo047123
	for ietf-openproxy-bks; Wed, 4 Jun 2003 11:08:53 -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 h54I6LAF046771
	for <ietf-openproxy@imc.org>; Wed, 4 Jun 2003 11:08:52 -0700 (PDT)
	(envelope-from markus@mhof.com)
Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10])
	by dirty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h54I6NHa097794
	for <ietf-openproxy@imc.org>; Wed, 4 Jun 2003 14:06:23 -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 h54I6GUf050510
	for <ietf-openproxy@imc.org>; Wed, 4 Jun 2003 14:06:16 -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 h54I6GQ4025227
	for <ietf-openproxy@imc.org>; Wed, 4 Jun 2003 14:06:16 -0400 (EDT)
Message-ID: <3EDE3557.7060508@mhof.com>
Date: Wed, 04 Jun 2003 14:07:19 -0400
From: Markus Hofmann <markus@mhof.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: OPES Group <ietf-openproxy@imc.org>
Subject: Re: Publishing OCP Draft as WG Document
References: <3ED65032.1020901@mhof.com>
In-Reply-To: <3ED65032.1020901@mhof.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit


Alex,

since no one objected.. Alex, could you please go ahead and publish 
the current version of the draft as WG document?

Thanks,
   Markus

Markus Hofmann wrote:

> 
> Hi,
> 
> I suggest that the current OCP document gets adopted and published as WG 
> Internet Draft, from which the WG will continue to work on.
> 
> We already discussed this a while back. Unless someone objects by 
> beginning of next week, I'd ask Alex to submit the OCP document for 
> publication as WG document.
> 
> Note that this is still work in progress, and that the WG will continue 
> to work on the protocol and on the document.
> 
> -Markus
> 
> 



From owner-ietf-openproxy@mail.imc.org  Wed Jun  4 17:27: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 RAA13232
	for <opes-archive@ietf.org>; Wed, 4 Jun 2003 17:27:18 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19NflB-0000Zy-00
	for opes-archive@ietf.org; Wed, 04 Jun 2003 17:25:29 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19NflA-0000Zv-00
	for opes-archive@ietf.org; Wed, 04 Jun 2003 17:25:28 -0400
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h54LFHAF056381
	for <ietf-openproxy-bks@above.proper.com>; Wed, 4 Jun 2003 14:15: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 h54LFHhC056380
	for ietf-openproxy-bks; Wed, 4 Jun 2003 14:15:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f
Received: from jay.songbird.com (jay.songbird.com [208.184.79.253])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h54LFGAF056374
	for <ietf-openproxy@imc.org>; Wed, 4 Jun 2003 14:15:16 -0700 (PDT)
	(envelope-from GK-lists@ninebynine.org)
Received: from Rincewind.ninebynine.org (jay.songbird.com [208.184.79.253])
	(authenticated)
	by jay.songbird.com (8.11.6/8.11.3) with ESMTP id h54LFC007023;
	Wed, 4 Jun 2003 14:15:14 -0700
Message-Id: <5.1.0.14.2.20030604220557.026dc210@127.0.0.1>
X-Sender: gk-lists@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 04 Jun 2003 22:06:49 +0100
To: Alex Rousskov <rousskov@measurement-factory.com>
From: Graham Klyne <GK-lists@ninebynine.org>
Subject: Re: Capability Negotiation for OCP
Cc: OPES WG <ietf-openproxy@imc.org>
In-Reply-To: <Pine.BSF.4.53.0306040907460.38923@measurement-factory.com>
References: <5.1.0.14.2.20030604000828.00b9dde0@127.0.0.1>
 <5.1.0.14.2.20030603095445.02af7258@127.0.0.1>
 <200304172215.h3HMFFY01277@localhost.localdomain>
 <200304172215.h3HMFFY01277@localhost.localdomain>
 <5.1.0.14.2.20030603095445.02af7258@127.0.0.1>
 <5.1.0.14.2.20030604000828.00b9dde0@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


At 09:21 04/06/03 -0600, Alex Rousskov wrote:
> > On ordering, that may be a difficult dependency to evolve away from
> > once it has been introduced.
>
>I agree, but some ordering is impossible to avoid. For example, one
>may want to encrypt connection before talking about _anything_ else.
>That introduces an order dependency: negotiate encryption first and
>everything else later. Authentication has a similar side-effect (I
>will not negotiate with you about anything else until I know who you
>are).

Oh yes... I was referring to ordering in the very narrow sense of lexical 
ordering within a capability expression having a bearing on what the 
expression actually means.

#g


-------------------
Graham Klyne
<GK@NineByNine.org>
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E



From owner-ietf-openproxy@mail.imc.org  Thu Jun  5 04:24: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 EAA11272
	for <opes-archive@ietf.org>; Thu, 5 Jun 2003 04:24:04 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Nq0j-0004CD-00
	for opes-archive@ietf.org; Thu, 05 Jun 2003 04:22:13 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Nq0j-0004CA-00
	for opes-archive@ietf.org; Thu, 05 Jun 2003 04:22: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 h558DKAF097294
	for <ietf-openproxy-bks@above.proper.com>; Thu, 5 Jun 2003 01:13: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 h558DJAQ097293
	for ietf-openproxy-bks; Thu, 5 Jun 2003 01:13:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f
Received: from wwsmtp.webwasher.com ([217.146.159.49])
	by above.proper.com (8.12.9/8.12.8) with SMTP id h558DHAF097286
	for <ietf-openproxy@imc.org>; Thu, 5 Jun 2003 01:13:18 -0700 (PDT)
	(envelope-from martin.stecher@WEBWASHER.com)
Received: from mail.WEBWASHER.COM [192.168.0.251] id 6WFG22GG; 05 Jun 2003 10:13:13 +0200
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: OCP Core version head_sid6 available
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Date: Thu, 5 Jun 2003 10:13:10 +0200
Message-ID: <75F7E67FC45F6744A7D328D41E35376D013EFD@mail.webwasher.com>
Thread-Topic: OCP Core version head_sid6 available
Thread-Index: AcMqvMJL8njoYaV+RH6a3Z0IZdrIDAAd9E5Q
From: "Martin Stecher" <martin.stecher@webwasher.com>
To: "OPES WG" <ietf-openproxy@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h558DJAF097289
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 8bit


Hi,

thank you very much, Alex, for getting back with the examples.

regarding priority:

different priorities may or may not make sense; we should leave minimum
support for it in the core I guess.

But changing priority on the fly for an existing connection does not
make any sense to me; let's take it out.

Let's take your example: If OPES processor and callout server are
able to support VIP connections and the OPES processor suddenly
receives a request from an important client, it makes only little
sense to change priority of one of maybe 200 open connections.
While the connection is not yet on high priority when the change-
priority-message is sent, there is no guarantee that changing
priority will be handled very soon.
I assume that such an OPES processor will better want to keep one
or more VIP connections open and alive to ensure even higher
quality of that service.

So one (optional) parameter in the connection-start message should
pretty much cover this.



regarding services:

The usage examples do not convince me that changing of services
will be needed but the security example is very important.
Thank you very much.

If a server can do virus filtering plus language translation and
we assume that there are two types of service requests (only
AV filter or both filters), I guess that there will be many
files for either types, so that keeping multiple connections
open, some with service type 1, the others with service type 2,
makes probably more sense than switching single (sub-)services
on the fly. (for example to avoid loading and unloading
of language dictionaries in the callout server)

The other example with the different services depending on hours
of a day: I personally do not believe that this will happen
(often) in real-world examples. Either services are very much
reduced to one task (do classification of URLs OR do virus
checking) and so OPES processor handles the results by itself,
may check the time, combine results of different services, or
services are rather complex (offer different modules like URL
classification AND virus checking) and then want to handle the
complete policy by themselves and also include the user profiling,
date-time policies and so on and don't allow the OPES processor
to select the single services.
(I think some of you have a different view on this.)
But still then I think we can better live with opening new
connections with new sets of services rather than switching
services on the fly; makes (programmer's) life just simpler.

What remains is your very important remark about the secrecy
of connection-start parameters. This may be imporant for any
parameter that we add to the core now or will be added later
by a application protocol binding (which is possible, isn't it?).

So, putting it together and taking your proposal:

> To keep things symmetric we can do this:
> 	- no dedicated Connection Services (CSvcs) message
   
yes, and also remove Connection Priority message

> 	- Connection Start (CS) and Transaction Start (TS)
> 	  messages have a Services parameter

Only Connection Start message has a services parameter and
an optional priority message. TS messages have not.

> 	- transport negotiations MAY happen before
> 	  Connection Start (CS) message

Transport negotiations (if any) MUST happen before CS message.

> 
> Would you prefer this? I think I would. The last item may sound
> strange, but I think it is actually the right thing to do because, in
> theory, a single transport connection can carry multiple OCP
> connections and so transport negotiations are one level above OCP
> connections.

I agree.


Thank you.

Martin





From owner-ietf-openproxy@mail.imc.org  Thu Jun  5 12:35: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 MAA05611
	for <opes-archive@ietf.org>; Thu, 5 Jun 2003 12:35:15 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Nxg4-0000v0-00
	for opes-archive@ietf.org; Thu, 05 Jun 2003 12:33:24 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Nxg4-0000uw-00
	for opes-archive@ietf.org; Thu, 05 Jun 2003 12:33: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 h55GLdAF032774
	for <ietf-openproxy-bks@above.proper.com>; Thu, 5 Jun 2003 09:21: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 h55GLdVT032773
	for ietf-openproxy-bks; Thu, 5 Jun 2003 09:21: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 h55GLcAF032768
	for <ietf-openproxy@imc.org>; Thu, 5 Jun 2003 09:21: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 h55GLd2R077765;
	Thu, 5 Jun 2003 10:21:39 -0600 (MDT)
	(envelope-from rousskov@measurement-factory.com)
Received: (from rousskov@localhost)
	by measurement-factory.com (8.12.9/8.12.5/Submit) id h55GLc8L077764;
	Thu, 5 Jun 2003 10:21:38 -0600 (MDT)
	(envelope-from rousskov)
Date: Thu, 5 Jun 2003 10:21:38 -0600 (MDT)
From: Alex Rousskov <rousskov@measurement-factory.com>
To: OPES WG <ietf-openproxy@imc.org>
Subject: handling common callout services
In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D013EFD@mail.webwasher.com>
Message-ID: <Pine.BSF.4.53.0306050858190.75195@measurement-factory.com>
References: <75F7E67FC45F6744A7D328D41E35376D013EFD@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: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>



On Thu, 5 Jun 2003, Martin Stecher wrote:

> regarding services: The usage examples do not convince me that
> changing of services will be needed

I agree that my examples were not very convincing. Let me try to come
up with a few better/different ones:

    An OPES processor is serving a large group of users,
    with diverse filtering needs. Perhaps this is a
    hosting environment with OPES-powered translation
    of hosted pages and other customer-specific services.
    Or maybe this is a CDN-like environment. The OPES
    processor is configured to use a callout server that
    can perform any service required. When the processor
    opens the connection to the server, no single set
    of services would describe its future needs. The
    processor leaves per-connection services empty as
    the default. For each transaction, the processor
    specifies the exact services that apply to that
    transaction, overwriting the default empty set.
    Opening a new transport connection for each
    transaction is not efficient enough in this case.

    An OPES processor performs a well-known list of
    services for all transactions, except there is
    a small group of VIP users that need a different set.
    The processor can allocate a new transport connection
    whenever a request comes from a VIP user, but it would prefer
    to use the existing transport connection since
    a VIP connection is not used often enough to
    keep it persistent.

    A busy callout server shared among many OPES
    processors (they subscribe to and pay for the
    service) does not allow more than one transport
    connection from a single OPES processor (or per
    single subscription so that you can pay for extra
    connections).

To summarize my current understanding, which, I think, reached another
level thanks to your comments:

    0a.Allocation of new services can be expensive so
       it is good to have some facility to load/unload
       a set of services for a group of transactions,
       instead of doing it for every transaction.

    0b.Allocation of transport connections can be
       both very expensive and, in some cases, technically
       or administratively impossible. OCP should not require
       allocation of multiple transport connections for
       semantic reasons. Everything should work over a single
       transport connection. This is an important design
       constraint!

    1. There are cases where transactions
       share the same list of services.

    2. There are cases where transactions
       do not share the same list of services.

    3. Several common lists of services may co-exist.
       For example, common services for images and
       common services for executables.

The above observations lead me to the following solution:

    A "list of services" needs direct OCP Core support.
    We need messages that create and destroy service
    lists. We need a mechanism to refer to an existing
    service list from a transaction-start message.
    Something along these lines:

    service-list-create sid=123 (s1, s2, s3);
      transaction-start xid=56 ... sid=123 ...;
      transaction-start xid=57 ... sid=123 ...;
      transaction-start xid=58 ... sid=123 ...;
      ...
    service-list-create sid=45 (s4, s5);
      transaction-start xid=60 ... sid=45 ...;
      transaction-start xid=59 ... sid=123 ...;
      ...
    service-list-destroy sid=123
      ...
      transaction-start xid=61 ... sid=45 ...;
      ...
    service-list-destroy sid=45;

Note that service-list-create and service-list-destroy messages have
no "scope" other than OCP connection. They are, essentially, a
connection-global variables or objects. This gives us enough
flexibility to cover all cases. Yet, it is a relatively simple and
very efficient scheme.

What do you think? Does this address your concerns? Do you think a
services-for-images and services-for-executables example is
valid/common enough? Do you think that OCP MUST work over a single
transport connection?

Thank you,

Alex.


From owner-ietf-openproxy@mail.imc.org  Thu Jun  5 12:37: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 MAA05664
	for <opes-archive@ietf.org>; Thu, 5 Jun 2003 12:37:54 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Nxid-0000vY-00
	for opes-archive@ietf.org; Thu, 05 Jun 2003 12:36:03 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Nxic-0000vV-00
	for opes-archive@ietf.org; Thu, 05 Jun 2003 12:36:02 -0400
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h55GOaAF032851
	for <ietf-openproxy-bks@above.proper.com>; Thu, 5 Jun 2003 09:24:36 -0700 (PDT)
	(envelope-from owner-ietf-openproxy@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h55GOaGW032850
	for ietf-openproxy-bks; Thu, 5 Jun 2003 09:24:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f
Received: from measurement-factory.com (measurement-factory.com [206.168.0.5])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h55GOZAF032845
	for <ietf-openproxy@imc.org>; Thu, 5 Jun 2003 09:24:35 -0700 (PDT)
	(envelope-from rousskov@measurement-factory.com)
Received: from measurement-factory.com (localhost [127.0.0.1])
	by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h55GOa2R077791;
	Thu, 5 Jun 2003 10:24:36 -0600 (MDT)
	(envelope-from rousskov@measurement-factory.com)
Received: (from rousskov@localhost)
	by measurement-factory.com (8.12.9/8.12.5/Submit) id h55GOa0x077790;
	Thu, 5 Jun 2003 10:24:36 -0600 (MDT)
	(envelope-from rousskov)
Date: Thu, 5 Jun 2003 10:24:36 -0600 (MDT)
From: Alex Rousskov <rousskov@measurement-factory.com>
To: OPES WG <ietf-openproxy@imc.org>
Subject: OCP: connection priority
In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D013EFD@mail.webwasher.com>
Message-ID: <Pine.BSF.4.53.0306050858190.75195@measurement-factory.com>
References: <75F7E67FC45F6744A7D328D41E35376D013EFD@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: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>



On Thu, 5 Jun 2003, Martin Stecher wrote:

> regarding priority: different priorities may or may not make sense;
> we should leave minimum support for it in the core I guess.

Since priority handling is an optional feature that many (most?)
implementations will not support and that does not require any Core
support, it seems that it would be better to leave it out of the Core
and document it as an extension in a separate short draft.

Any other opinions/comments?

Thanks,

Alex.


From owner-ietf-openproxy@mail.imc.org  Thu Jun  5 12:53: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 MAA06130
	for <opes-archive@ietf.org>; Thu, 5 Jun 2003 12:53:46 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Nxxz-000138-00
	for opes-archive@ietf.org; Thu, 05 Jun 2003 12:51:55 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Nxxz-000135-00
	for opes-archive@ietf.org; Thu, 05 Jun 2003 12:51:55 -0400
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h55GflAF033515
	for <ietf-openproxy-bks@above.proper.com>; Thu, 5 Jun 2003 09:41: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 h55GflwX033514
	for ietf-openproxy-bks; Thu, 5 Jun 2003 09:41: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 h55GfkAF033509
	for <ietf-openproxy@imc.org>; Thu, 5 Jun 2003 09:41:46 -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 h55Gfl2R078300;
	Thu, 5 Jun 2003 10:41:47 -0600 (MDT)
	(envelope-from rousskov@measurement-factory.com)
Received: (from rousskov@localhost)
	by measurement-factory.com (8.12.9/8.12.5/Submit) id h55GflTp078299;
	Thu, 5 Jun 2003 10:41:47 -0600 (MDT)
	(envelope-from rousskov)
Date: Thu, 5 Jun 2003 10:41:47 -0600 (MDT)
From: Alex Rousskov <rousskov@measurement-factory.com>
To: OPES WG <ietf-openproxy@imc.org>
Subject: RE: OCP Core version head_sid6 available
In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D013EFD@mail.webwasher.com>
Message-ID: <Pine.BSF.4.53.0306050858190.75195@measurement-factory.com>
References: <75F7E67FC45F6744A7D328D41E35376D013EFD@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: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


On Thu, 5 Jun 2003, Martin Stecher wrote:

> What remains is your very important remark about the secrecy of
> connection-start parameters. This may be imporant for any parameter
> that we add to the core now or will be added later by a application
> protocol binding (which is possible, isn't it?).

Yes, it is. In addition to bingings, extensions may add parameters or
new messages as well.

> > 	- transport negotiations MAY happen before
> > 	  Connection Start (CS) message
>
> Transport negotiations (if any) MUST happen before CS message.

That's probably too restrictive because some transports may require
run-time negotiations in addition to startup negotiations. Also,
please note that the other side can reject any insecure transmissions
if it insists on secure communications (causing an interoperability
problem). I believe each negotiable feature must document when it can
or MUST be negotiated.

This also reminds me that the only purpose of an OCP Connection (as
defined in the Core draft) is to specify the default services to be
applied to all transactions within an OCP Connection. The only
relationship between an OCP Connection and transport connection is
that we assume that transport will somehow distinguish OCP connections
from each other (e.g., by allowing only one OCP connection per
transport connection or by using some transport channel IDs). Thus,
the "Connection" word is really misleading and not appropriate. The
reason it exists in the current draft is because the OCP requirements
draft uses it, but we do not have to follow the requirements
terminology as long as we provide intended functionality.

I would like to propose the following:

	1. Remove the concept of OCP Connection. OCP Connection
	   is the same as transport connection.

	   Document that Connection Start (CS) and Connection
	   End (CE) messages refer to OCP transport connection.
	   The Connection Start (CS) message MUST be the first
	   message on the connection. It is nice to have a
	   protocol-specific "Hello" message before any
	   negotiations begin. Connection End (CE) message
	   MUST be sent immediately before closing the
	   transport connection. Its purpose is to allow
	   one side to inform the other why the transport
	   connection is being closed.

	   The current "scope for common services" aspect
	   of OCP Connection should be supported directly,
	   see "handling common callout services" e-mail.

	2. There will be no other connection-specific
	   messages or options, for now.

	3. When documenting TLS negotiations, insist that
	   they start immediately after Connection Start (CS).

Would that work for you?

Thanks,

Alex.


From owner-ietf-openproxy@mail.imc.org  Thu Jun  5 12:57: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 MAA06268
	for <opes-archive@ietf.org>; Thu, 5 Jun 2003 12:57:36 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Ny1i-00015o-00
	for opes-archive@ietf.org; Thu, 05 Jun 2003 12:55:46 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Ny1h-00015l-00
	for opes-archive@ietf.org; Thu, 05 Jun 2003 12:55:45 -0400
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h55Gk8AF033649
	for <ietf-openproxy-bks@above.proper.com>; Thu, 5 Jun 2003 09:46: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 h55Gk8pw033648
	for ietf-openproxy-bks; Thu, 5 Jun 2003 09:46:08 -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 h55Gk7AF033629
	for <ietf-openproxy@imc.org>; Thu, 5 Jun 2003 09:46:07 -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 h55Gji404523;
	Thu, 5 Jun 2003 12:45:44 -0400 (EDT)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <KRLF0WDB>; Thu, 5 Jun 2003 12:45:45 -0400
Message-ID: <87609AFB433BD5118D5E0002A52CD75405F0368C@zcard0k6.ca.nortel.com>
From: "Abbie Barbir" <abbieb@nortelnetworks.com>
To: Markus Hofmann <markus@mhof.com>, OPES Group <ietf-openproxy@imc.org>
Subject: RE: Publishing OCP Draft as WG Document
Date: Thu, 5 Jun 2003 12:45:42 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C32B81.E6F24FE2"
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


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_01C32B81.E6F24FE2
Content-Type: text/plain

Finally,

what a releif.

abbie


> -----Original Message-----
> From: Markus Hofmann [mailto:markus@mhof.com] 
> Sent: Wednesday, June 04, 2003 2:07 PM
> To: OPES Group
> Subject: Re: Publishing OCP Draft as WG Document
> 
> 
> 
> Alex,
> 
> since no one objected.. Alex, could you please go ahead and publish 
> the current version of the draft as WG document?
> 
> Thanks,
>    Markus
> 
> Markus Hofmann wrote:
> 
> > 
> > Hi,
> > 
> > I suggest that the current OCP document gets adopted and 
> published as 
> > WG
> > Internet Draft, from which the WG will continue to work on.
> > 
> > We already discussed this a while back. Unless someone objects by
> > beginning of next week, I'd ask Alex to submit the OCP document for 
> > publication as WG document.
> > 
> > Note that this is still work in progress, and that the WG will 
> > continue
> > to work on the protocol and on the document.
> > 
> > -Markus
> > 
> > 
> 
> 

------_=_NextPart_001_01C32B81.E6F24FE2
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2656.31">
<TITLE>RE: Publishing OCP Draft as WG Document</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Finally,</FONT>
</P>

<P><FONT SIZE=2>what a releif.</FONT>
</P>

<P><FONT SIZE=2>abbie</FONT>
</P>
<BR>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Markus Hofmann [<A HREF="mailto:markus@mhof.com">mailto:markus@mhof.com</A>] </FONT>
<BR><FONT SIZE=2>&gt; Sent: Wednesday, June 04, 2003 2:07 PM</FONT>
<BR><FONT SIZE=2>&gt; To: OPES Group</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: Publishing OCP Draft as WG Document</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Alex,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; since no one objected.. Alex, could you please go ahead and publish </FONT>
<BR><FONT SIZE=2>&gt; the current version of the draft as WG document?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Thanks,</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; Markus</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Markus Hofmann wrote:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Hi,</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; I suggest that the current OCP document gets adopted and </FONT>
<BR><FONT SIZE=2>&gt; published as </FONT>
<BR><FONT SIZE=2>&gt; &gt; WG</FONT>
<BR><FONT SIZE=2>&gt; &gt; Internet Draft, from which the WG will continue to work on.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; We already discussed this a while back. Unless someone objects by</FONT>
<BR><FONT SIZE=2>&gt; &gt; beginning of next week, I'd ask Alex to submit the OCP document for </FONT>
<BR><FONT SIZE=2>&gt; &gt; publication as WG document.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Note that this is still work in progress, and that the WG will </FONT>
<BR><FONT SIZE=2>&gt; &gt; continue</FONT>
<BR><FONT SIZE=2>&gt; &gt; to work on the protocol and on the document.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; -Markus</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C32B81.E6F24FE2--


From owner-ietf-openproxy@mail.imc.org  Thu Jun  5 17:26: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 RAA17844
	for <opes-archive@ietf.org>; Thu, 5 Jun 2003 17:26:01 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19O2DR-0003k6-00
	for opes-archive@ietf.org; Thu, 05 Jun 2003 17:24:10 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19O2DR-0003k3-00
	for opes-archive@ietf.org; Thu, 05 Jun 2003 17:24: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 h55LCbAF046823
	for <ietf-openproxy-bks@above.proper.com>; Thu, 5 Jun 2003 14:12:37 -0700 (PDT)
	(envelope-from owner-ietf-openproxy@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h55LCbmH046820
	for ietf-openproxy-bks; Thu, 5 Jun 2003 14:12:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f
Received: from wwsmtp.webwasher.com ([217.146.159.49])
	by above.proper.com (8.12.9/8.12.8) with SMTP id h55LCXAF046795
	for <ietf-openproxy@imc.org>; Thu, 5 Jun 2003 14:12:35 -0700 (PDT)
	(envelope-from martin.stecher@WEBWASHER.com)
Received: from mail.WEBWASHER.COM [192.168.0.251] id 1NOBAQK9; 05 Jun 2003 23:12:35 +0200
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: handling common callout services
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Date: Thu, 5 Jun 2003 23:12:30 +0200
Message-ID: <75F7E67FC45F6744A7D328D41E35376D013F05@mail.webwasher.com>
Thread-Topic: handling common callout services
Thread-Index: AcMrfo2rxRhrGusATJKEFph5qGSY2wAJmC2A
From: "Martin Stecher" <martin.stecher@webwasher.com>
To: "OPES WG" <ietf-openproxy@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h55LCZAF046816
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 8bit


 
On Thu, 5 Jun 2003, Alex Rousskov  wrote:
 
> > regarding services: The usage examples do not convince me that
> > changing of services will be needed
> 
> I agree that my examples were not very convincing. Let me try to come
> up with a few better/different ones:
> 
[.....]
> 

> What do you think? Does this address your concerns?

Very good argumentation, Alex.
I do (now) agree with your findings.


> Do you think a services-for-images and services-for-executables
> example is valid/common enough?

Was there an example with images and executables services in your
message?


> Do you think that OCP MUST work over a single transport connection?
It's a nice example; not sure whether we will find it in real world,
but I do now agree that we should be prepared for this scenario.


 
Regards
Martin



From owner-ietf-openproxy@mail.imc.org  Thu Jun  5 17:27: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 RAA17933
	for <opes-archive@ietf.org>; Thu, 5 Jun 2003 17:27:05 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19O2ET-0003kz-00
	for opes-archive@ietf.org; Thu, 05 Jun 2003 17:25:13 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19O2ET-0003ku-00
	for opes-archive@ietf.org; Thu, 05 Jun 2003 17:25: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 h55LIDAF046998
	for <ietf-openproxy-bks@above.proper.com>; Thu, 5 Jun 2003 14:18: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 h55LIDU9046997
	for ietf-openproxy-bks; Thu, 5 Jun 2003 14:18:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f
Received: from wwsmtp.webwasher.com ([217.146.159.49])
	by above.proper.com (8.12.9/8.12.8) with SMTP id h55LIBAF046989
	for <ietf-openproxy@imc.org>; Thu, 5 Jun 2003 14:18:12 -0700 (PDT)
	(envelope-from martin.stecher@WEBWASHER.com)
Received: from mail.WEBWASHER.COM [192.168.0.251] id CZAG8NJI; 05 Jun 2003 23:18:13 +0200
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: AW: OCP Core version head_sid6 available
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Date: Thu, 5 Jun 2003 23:18:08 +0200
Message-ID: <75F7E67FC45F6744A7D328D41E35376D0143A0@mail.webwasher.com>
Thread-Topic: OCP Core version head_sid6 available
Thread-Index: AcMrgVyMQzow2IZkSWOmyX/+WJfy6wAJmiyg
From: "Martin Stecher" <martin.stecher@webwasher.com>
To: "OPES WG" <ietf-openproxy@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h55LICAF046992
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 8bit


On Thu, 5 Jun 2003, Alex Rousskov wrote:
> 
> > What remains is your very important remark about the secrecy of
> > connection-start parameters. This may be imporant for any parameter
> > that we add to the core now or will be added later by a application
> > protocol binding (which is possible, isn't it?).
> 
> Yes, it is. In addition to bingings, extensions may add parameters or
> new messages as well.
> 
> > > 	- transport negotiations MAY happen before
> > > 	  Connection Start (CS) message
> >
> > Transport negotiations (if any) MUST happen before CS message.
> 
> That's probably too restrictive because some transports may require
> run-time negotiations in addition to startup negotiations. Also,
> please note that the other side can reject any insecure transmissions
> if it insists on secure communications (causing an interoperability
> problem). I believe each negotiable feature must document when it can
> or MUST be negotiated.

You are right.


> 
> This also reminds me that the only purpose of an OCP Connection (as
> defined in the Core draft) is to specify the default services to be
> applied to all transactions within an OCP Connection. The only
> relationship between an OCP Connection and transport connection is
> that we assume that transport will somehow distinguish OCP connections
> from each other (e.g., by allowing only one OCP connection per
> transport connection or by using some transport channel IDs). Thus,
> the "Connection" word is really misleading and not appropriate. The
> reason it exists in the current draft is because the OCP requirements
> draft uses it, but we do not have to follow the requirements
> terminology as long as we provide intended functionality.
> 
> I would like to propose the following:
> 
> 	1. Remove the concept of OCP Connection. OCP Connection
> 	   is the same as transport connection.
> 
> 	   Document that Connection Start (CS) and Connection
> 	   End (CE) messages refer to OCP transport connection.
> 	   The Connection Start (CS) message MUST be the first
> 	   message on the connection. It is nice to have a
> 	   protocol-specific "Hello" message before any
> 	   negotiations begin. Connection End (CE) message
> 	   MUST be sent immediately before closing the
> 	   transport connection. Its purpose is to allow
> 	   one side to inform the other why the transport
> 	   connection is being closed.
> 
> 	   The current "scope for common services" aspect
> 	   of OCP Connection should be supported directly,
> 	   see "handling common callout services" e-mail.
> 
> 	2. There will be no other connection-specific
> 	   messages or options, for now.
> 
> 	3. When documenting TLS negotiations, insist that
> 	   they start immediately after Connection Start (CS).
> 
> Would that work for you?

Absolutely, sounds very good to me.

Regards
Martin



From owner-ietf-openproxy@mail.imc.org  Fri Jun  6 17:07: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 RAA12980
	for <opes-archive@ietf.org>; Fri, 6 Jun 2003 17:07:49 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19OOPL-0006Xj-00
	for opes-archive@ietf.org; Fri, 06 Jun 2003 17:05:55 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19OOPK-0006Xc-00
	for opes-archive@ietf.org; Fri, 06 Jun 2003 17:05:54 -0400
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h56KuqAF033968
	for <ietf-openproxy-bks@above.proper.com>; Fri, 6 Jun 2003 13:56:52 -0700 (PDT)
	(envelope-from owner-ietf-openproxy@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h56Kuq6X033967
	for ietf-openproxy-bks; Fri, 6 Jun 2003 13:56:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f
Received: from measurement-factory.com (measurement-factory.com [206.168.0.5])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h56KuoAF033961
	for <ietf-openproxy@imc.org>; Fri, 6 Jun 2003 13:56: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 h56Kuq2R023024
	for <ietf-openproxy@imc.org>; Fri, 6 Jun 2003 14:56:52 -0600 (MDT)
	(envelope-from rousskov@measurement-factory.com)
Received: (from rousskov@localhost)
	by measurement-factory.com (8.12.9/8.12.5/Submit) id h56KugOK023020;
	Fri, 6 Jun 2003 14:56:42 -0600 (MDT)
	(envelope-from rousskov)
Date: Fri, 6 Jun 2003 14:56:42 -0600 (MDT)
From: Alex Rousskov <rousskov@measurement-factory.com>
To: OPES WG <ietf-openproxy@imc.org>
Subject: OCP Core version head_sid10 available
Message-ID: <Pine.BSF.4.53.0306061452150.13180@measurement-factory.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>



This snapshot was submitted to IETF for publication as a working group
Internet Draft (draft-ietf-opes-ocp-core-00). The draft is meant to
reflect all relevant discussions on this mailing list, as of
2004/06/05.

The log of major changes is quoted below. The latest snapshot,
including XML sources for those doing hands-on modifications, is
available at

	http://www.measurement-factory.com/tmp/opes/

Please continue to comment and work on the to-do list.

Thank you,

Alex.

-------------- change log ----------------

head-sid10

  *  Removed the concept of OCP connection as a group of messages
     sharing the same group of callout services. Now there is no
     difference between OCP connection and transport connection.

  *  Added a concept of a Service Group, which is a list of services
     with an identifier, for now. A given Service Group is
     referenced by the creating/destroying side only, to prevent
     destruction synchronization.

  *  Removed Connection Services (CSvc) message.

  *  Removed connection priority until proven generally useful. Can
     be implemented as an extension.



From owner-ietf-openproxy@mail.imc.org  Sun Jun  8 23:06: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 XAA07755
	for <opes-archive@ietf.org>; Sun, 8 Jun 2003 23:06:49 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PCxm-00078x-00
	for opes-archive@ietf.org; Sun, 08 Jun 2003 23:04:50 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PCxl-00078t-00
	for opes-archive@ietf.org; Sun, 08 Jun 2003 23:04:49 -0400
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h592pkAF024866
	for <ietf-openproxy-bks@above.proper.com>; Sun, 8 Jun 2003 19:51: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 h592pkgG024865
	for ietf-openproxy-bks; Sun, 8 Jun 2003 19:51:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f
Received: from smtp-out.comcast.net (smtp-out.comcast.net [24.153.64.116])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h592piAF024859
	for <ietf-openproxy@imc.org>; Sun, 8 Jun 2003 19:51:45 -0700 (PDT)
	(envelope-from markus@mhof.com)
Received: from mhof.com ([135.104.20.73])
 by mtaout04.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May
 14 2003)) with ESMTPA id <0HG700MCB1A4SK@mtaout04.icomcast.net> for
 ietf-openproxy@imc.org; Sun, 08 Jun 2003 22:51:41 -0400 (EDT)
Date: Sun, 08 Jun 2003 22:51:40 -0400
From: Markus Hofmann <markus@mhof.com>
Subject: Re: Publishing Tracing Draft as WG Document
In-reply-to: <3ED75AD8.2060608@mhof.com>
To: OPES Group <ietf-openproxy@imc.org>
Message-id: <3EE3F63C.3060701@mhof.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4)
 Gecko/20030529
References: <3ED75AD8.2060608@mhof.com>
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7BIT


Abbie,

since no one objected, could you please go ahead and publish the 
current version of the tracing draft as WG document?

Thanks,
   Markus

Markus Hofmann wrote:

> 
> Hi,
> 
> I suggest that the current write-up on "OPES Tracing" (see Abbie's
> email to the list dated 5/4) also gets adopted and published as WG
> Internet Draft, from which the WG will continue to work on.
> 
> Unless someone objects by Friday 6/6, I'd ask Abbie to submit the
> "Opes Tracing" document for publication as WG ID.
> 
> Note that this is still work in progress, and that the WG will
> continue to work on and modify the document.
> 
> -Markus
> 
> 
> 



From owner-ietf-openproxy@mail.imc.org  Sun Jun  8 23:08: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 XAA07793
	for <opes-archive@ietf.org>; Sun, 8 Jun 2003 23:08:31 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PCzQ-00079Y-00
	for opes-archive@ietf.org; Sun, 08 Jun 2003 23:06:32 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PCzP-00079V-00
	for opes-archive@ietf.org; Sun, 08 Jun 2003 23:06:32 -0400
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h592vCAF024950
	for <ietf-openproxy-bks@above.proper.com>; Sun, 8 Jun 2003 19:57: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 h592vCR7024949
	for ietf-openproxy-bks; Sun, 8 Jun 2003 19:57:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f
Received: from smtp-out.comcast.net (smtp-out.comcast.net [24.153.64.109])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h592vBAF024943
	for <ietf-openproxy@imc.org>; Sun, 8 Jun 2003 19:57:11 -0700 (PDT)
	(envelope-from markus@mhof.com)
Received: from mhof.com ([135.104.20.73])
 by mtaout05.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May
 14 2003)) with ESMTPA id <0HG700JYU1HZRY@mtaout05.icomcast.net> for
 ietf-openproxy@imc.org; Sun, 08 Jun 2003 22:56:24 -0400 (EDT)
Date: Sun, 08 Jun 2003 22:56:23 -0400
From: Markus Hofmann <markus@mhof.com>
Subject: Re: IAB Treatment version head_sid8 available
In-reply-to: <Pine.BSF.4.53.0305282033330.88613@measurement-factory.com>
To: OPES WG <ietf-openproxy@imc.org>
Message-id: <3EE3F757.3090704@mhof.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4)
 Gecko/20030529
References: <Pine.BSF.4.53.0305282033330.88613@measurement-factory.com>
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7BIT


Folks,

please check out the current version of the "IAB considerations" draft 
and provide comments via the mailing list. Also check out the comments 
that have been mdae on the mailing list so far.

Unless someone objects by Wednesday 6/11, we'd ask Alex and Abbie to 
submit the the current version of document for publication as WG ID. 
As usual, the WG will continue to work on this draft, it's *not* 
finalized yet.

Thanks,
   Markus


Alex Rousskov wrote:

> 
> This snapshot may not represent working group or even authors
> consensus!
> 
> The [major] change log is quoted below. The latest snapshot, including
> XML sources for those doing hands-on modifications, is available at
> 
> 	http://www.measurement-factory.com/tmp/opes/
> 
> Please comment.
> 
> Thank you,
> 
> Alex.
> 
> -------------- change log ----------------
> 
>     *  Added unpolished meat for all nine considerations.
>     *  Added Abbie Barbir as an author.
> 



From owner-ietf-openproxy@mail.imc.org  Tue Jun 10 08:04:07 2003
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22529
	for <opes-archive@ietf.org>; Tue, 10 Jun 2003 08:04:07 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PhpF-0004BG-00
	for opes-archive@ietf.org; Tue, 10 Jun 2003 08:02:05 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PhpE-0004B7-00
	for opes-archive@ietf.org; Tue, 10 Jun 2003 08:02: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 h5ABqpAF064104
	for <ietf-openproxy-bks@above.proper.com>; Tue, 10 Jun 2003 04:52:51 -0700 (PDT)
	(envelope-from owner-ietf-openproxy@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h5ABqpNp064103
	for ietf-openproxy-bks; Tue, 10 Jun 2003 04:52:51 -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 h5ABqoAF064098
	for <ietf-openproxy@imc.org>; Tue, 10 Jun 2003 04:52:50 -0700 (PDT)
	(envelope-from nsyracus@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 HAA21753;
	Tue, 10 Jun 2003 07:52:49 -0400 (EDT)
Message-Id: <200306101152.HAA21753@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-00.txt
Date: Tue, 10 Jun 2003 07:52:49 -0400
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


--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-00.txt
	Pages		: 51
	Date		: 2003-6-9
	
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-00.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-00.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-00.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-6-9151144.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-opes-ocp-core-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-opes-ocp-core-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-6-9151144.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-ietf-openproxy@mail.imc.org  Tue Jun 10 10:19: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 KAA02562
	for <opes-archive@ietf.org>; Tue, 10 Jun 2003 10:19:38 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PjwO-0006nD-00
	for opes-archive@ietf.org; Tue, 10 Jun 2003 10:17:36 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PjwN-0006nA-00
	for opes-archive@ietf.org; Tue, 10 Jun 2003 10:17: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 h5AE7wAF073925
	for <ietf-openproxy-bks@above.proper.com>; Tue, 10 Jun 2003 07:07: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 h5AE7wKK073924
	for ietf-openproxy-bks; Tue, 10 Jun 2003 07:07:58 -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 h5AE7uAF073919
	for <ietf-openproxy@imc.org>; Tue, 10 Jun 2003 07:07:57 -0700 (PDT)
	(envelope-from nsyracus@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 KAA01231;
	Tue, 10 Jun 2003 10:07:55 -0400 (EDT)
Message-Id: <200306101407.KAA01231@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-00.txt
Date: Tue, 10 Jun 2003 10:07:55 -0400
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


--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-00.txt
	Pages		: 51
	Date		: 2003-6-9
	
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-00.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-00.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-00.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-6-9151144.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-opes-ocp-core-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-opes-ocp-core-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-6-9151144.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-ietf-openproxy@mail.imc.org  Tue Jun 10 21:48: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 VAA26013
	for <opes-archive@ietf.org>; Tue, 10 Jun 2003 21:48:18 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pugp-0003tE-00
	for opes-archive@ietf.org; Tue, 10 Jun 2003 21:46:15 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pugp-0003tB-00
	for opes-archive@ietf.org; Tue, 10 Jun 2003 21:46: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 h5B1Zlrb000947
	for <ietf-openproxy-bks@above.proper.com>; Tue, 10 Jun 2003 18:35: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 h5B1ZkxI000946
	for ietf-openproxy-bks; Tue, 10 Jun 2003 18:35:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f
Received: from smtp-out.comcast.net (smtp-out.comcast.net [24.153.64.115])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h5B1Zjrb000940
	for <ietf-openproxy@imc.org>; Tue, 10 Jun 2003 18:35:45 -0700 (PDT)
	(envelope-from markus@mhof.com)
Received: from mhof.com ([135.104.20.66])
 by mtaout02.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May
 14 2003)) with ESMTPA id <0HGA009ZUN3GW2@mtaout02.icomcast.net> for
 ietf-openproxy@imc.org; Tue, 10 Jun 2003 21:35:40 -0400 (EDT)
Date: Tue, 10 Jun 2003 21:35:41 -0400
From: Markus Hofmann <markus@mhof.com>
Subject: [Fwd: I-D ACTION:draft-ietf-opes-ocp-core-00.txt]
To: OPES Group <ietf-openproxy@imc.org>
Message-id: <3EE6876D.6060601@mhof.com>
MIME-version: 1.0
Content-type: multipart/mixed; boundary="Boundary_(ID_0pdJwMDefwy7bAJrcIzlHg)"
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4)
 Gecko/20030529
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


This is a multi-part message in MIME format.

--Boundary_(ID_0pdJwMDefwy7bAJrcIzlHg)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7BIT



--Boundary_(ID_0pdJwMDefwy7bAJrcIzlHg)
Content-type: message/rfc822; name="I-D ACTION:draft-ietf-opes-ocp-core-00.txt"

Return-path: <owner-ietf-openproxy@mail.imc.org>
Received: from server3.fastmail.fm (server3.internal [10.202.2.134])
	by server2.fastmail.fm (Cyrus v2.1.9) with LMTP; Tue,
 10 Jun 2003 08:12:26 -0400
Received: from smtp.us.messagingengine.com (server3.internal [10.202.2.134])
	by server3.fastmail.fm (Cyrus v2.1.9) with LMTP; Tue,
 10 Jun 2003 08:12:27 -0400
Received: from smtp.us.messagingengine.com (localhost [127.0.0.1])
	by server3.messagingengine.com (Postfix) with ESMTP id 8AEBE7E548	for
 <hofmann@fastmail.fm>; Tue, 10 Jun 2003 08:12:26 -0400 (EDT)
Received: from 127.0.0.1 ([127.0.0.1] helo=smtp.us.messagingengine.com)
 by messagingengine.com with SMTP; Tue, 10 Jun 2003 08:12:26 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by smtp.us.messagingengine.com (Postfix) with ESMTP id 043F48899F	for
 <markus@mhof.com>; Tue, 10 Jun 2003 08:12:26 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h5ABqpAF064104	for
 <ietf-openproxy-bks@above.proper.com>; Tue, 10 Jun 2003 04:52:51 -0700
Received: (from majordom@localhost)	by above.proper.com (8.12.9/8.12.9/Submit)
 id h5ABqpNp064103	for ietf-openproxy-bks; Tue, 10 Jun 2003 04:52:51 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h5ABqoAF064098	for
 <ietf-openproxy@imc.org>; Tue, 10 Jun 2003 04:52:50 -0700
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21753; Tue,
 10 Jun 2003 07:52:49 -0400 (EDT)
Date: Tue, 10 Jun 2003 07:52:49 -0400
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-opes-ocp-core-00.txt
Sender: owner-ietf-openproxy@mail.imc.org
To: IETF-Announce: ;
Cc: ietf-openproxy@imc.org
Reply-to: Internet-Drafts@ietf.org
Message-id: <200306101152.HAA21753@ietf.org>
MIME-version: 1.0
Content-type: multipart/mixed; boundary="Boundary_(ID_VCwHFDUYv3fRh82KQMlbHg)"
Precedence: bulk
X-Sieve: CMU Sieve 2.2
X-Attached: draft-ietf-opes-ocp-core-00.txt
X-Virus-checked: Yes
X-Mail-from: owner-ietf-openproxy@mail.imc.org
X-Delivered-to: <markus@mhof.com>
X-Spam-score: 4.3
X-Authentication-warning: above.proper.com: majordom set sender to
 owner-ietf-openproxy@mail.imc.org using -f
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Id: <ietf-openproxy.imc.org>


--Boundary_(ID_VCwHFDUYv3fRh82KQMlbHg)
Content-type: TEXT/PLAIN
Content-Transfer-Encoding: 7BIT

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-00.txt
	Pages		: 51
	Date		: 2003-6-9
	
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-00.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-00.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-00.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.

--Boundary_(ID_VCwHFDUYv3fRh82KQMlbHg)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_L5UCwMb8QR6J2EyCgJDDBA)"


--Boundary_(ID_L5UCwMb8QR6J2EyCgJDDBA)
Content-type: Message/External-body; server="mailserv@ietf.org";
 access-type=mail-server

Content-Type: text/plain
Content-ID:	<2003-6-9151144.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-opes-ocp-core-00.txt

--Boundary_(ID_L5UCwMb8QR6J2EyCgJDDBA)
Content-type: Message/External-body; name=draft-ietf-opes-ocp-core-00.txt;
 site=ftp.ietf.org; access-type=anon-ftp; directory=internet-drafts
Content-disposition: attachment; filename=draft-ietf-opes-ocp-core-00.txt

Content-Type: text/plain
Content-ID:	<2003-6-9151144.I-D@ietf.org>

--Boundary_(ID_L5UCwMb8QR6J2EyCgJDDBA)--

--Boundary_(ID_VCwHFDUYv3fRh82KQMlbHg)--

--Boundary_(ID_0pdJwMDefwy7bAJrcIzlHg)--


From owner-ietf-openproxy@mail.imc.org  Wed Jun 11 11:31: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 LAA13646
	for <opes-archive@ietf.org>; Wed, 11 Jun 2003 11:31:31 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q7XT-00019H-00
	for opes-archive@ietf.org; Wed, 11 Jun 2003 11:29:27 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q7XS-000195-00
	for opes-archive@ietf.org; Wed, 11 Jun 2003 11:29:26 -0400
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BFDgrb066098
	for <ietf-openproxy-bks@above.proper.com>; Wed, 11 Jun 2003 08:13:42 -0700 (PDT)
	(envelope-from owner-ietf-openproxy@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h5BFDgjp066097
	for ietf-openproxy-bks; Wed, 11 Jun 2003 08:13:42 -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.9/8.12.8) with ESMTP id h5BFDerb066088
	for <ietf-openproxy@imc.org>; Wed, 11 Jun 2003 08:13:41 -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 h5BFCxn25630;
	Wed, 11 Jun 2003 11:12:59 -0400 (EDT)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <KRLGC61J>; Wed, 11 Jun 2003 11:13:00 -0400
Message-ID: <87609AFB433BD5118D5E0002A52CD75405FBC501@zcard0k6.ca.nortel.com>
From: "Abbie Barbir" <abbieb@nortelnetworks.com>
To: internet-drafts@ietf.org
Cc: ietf-openproxy@imc.org, Markus Hofmann <markus@mhof.com>,
        Marshall Rose <mrose@dbc.mtview.ca.us>
Subject: draft-ietf-opes-end-comm-00
Date: Wed, 11 Jun 2003 11:12:57 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C3302B.EF95BA40"
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


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_01C3302B.EF95BA40
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3302B.EF95BA40"


------_=_NextPart_001_01C3302B.EF95BA40
Content-Type: text/plain

Please publish the attached as as Internet-Draft 

draft-ietf-opes-end-comm-00

thanks 


------_=_NextPart_001_01C3302B.EF95BA40
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2656.31">
<TITLE>draft-ietf-opes-end-comm-00</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Please publish the attached as as Internet-Draft </FONT>
</P>

<P><FONT SIZE=2>draft-ietf-opes-end-comm-00</FONT>
</P>

<P><FONT SIZE=2>thanks </FONT>
</P>

<P><FONT FACE="Arial" SIZE=2 COLOR="#000000"></FONT>&nbsp;

</BODY>
</HTML>
------_=_NextPart_001_01C3302B.EF95BA40--

------_=_NextPart_000_01C3302B.EF95BA40
Content-Type: text/plain;
	name="draft-ietf-opes-end-comm-00.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-ietf-opes-end-comm-00.txt"
Content-Transfer-Encoding: quoted-printable



Network Working Group                                          A. =
Barbir
Internet-Draft                                           Nortel =
Networks
Expires: December 10, 2003                                 June 11, =
2003


              OPES processor and end points communications
                      draft-ietf-opes-end-comm-00

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 December 10, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

   This memo documents tracing requirements for Open Pluggable Edge
   Services (OPES).














Barbir                 Expires December 10, 2003                [Page =
1]
=0C
Internet-Draft    OPES processor and end points communications June =
2003


Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  =
3
   2.    OPES Tracing . . . . . . . . . . . . . . . . . . . . . . . .  =
4
   2.1   What is traceable in an OPES Flow? . . . . . . . . . . . . .  =
4
   2.2   Requirements for Information Related to Traceable
         Entities?  . . . . . . . . . . . . . . . . . . . . . . . . .  =
5
   3.    Requirements for OPES systems  . . . . . . . . . . . . . . .  =
6
   4.    Requirements for OPES processors . . . . . . . . . . . . . .  =
7
   5.    Requirements for callout servers . . . . . . . . . . . . . .  =
8
   6.    Privacy considerations . . . . . . . . . . . . . . . . . . .  =
9
   6.1   Tracing and Trust Domains  . . . . . . . . . . . . . . . . .  =
9
   7.    How to Support Tracing . . . . . . . . . . . . . . . . . . . =
10
   7.1   Tracing and OPES System Granularity  . . . . . . . . . . . . =
10
   7.2   Requirements for In-Band Tracing . . . . . . . . . . . . . . =
11
   7.2.1 Tracing Information Granularity and Persistence levels
         Requirements . . . . . . . . . . . . . . . . . . . . . . . . =
11
   7.3   Protocol Binding . . . . . . . . . . . . . . . . . . . . . . =
12
   7.4   Tracing scenarios and examples . . . . . . . . . . . . . . . =
12
   8.    IAB considerations . . . . . . . . . . . . . . . . . . . . . =
13
   8.1   Notification Concerns  . . . . . . . . . . . . . . . . . . . =
13
   8.1.1 Addressing IAB Consideration 3.1 . . . . . . . . . . . . . . =
14
   8.1.2 Addressing IAB Consideration 3.2 . . . . . . . . . . . . . . =
15
   9.    Security considerations  . . . . . . . . . . . . . . . . . . =
17
   10.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . =
18
         Normative References . . . . . . . . . . . . . . . . . . . . =
19
         Informative References . . . . . . . . . . . . . . . . . . . =
20
         Author's Address . . . . . . . . . . . . . . . . . . . . . . =
20
   A.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . =
21
         Intellectual Property and Copyright Statements . . . . . . . =
22





















Barbir                 Expires December 10, 2003                [Page =
2]
=0C
Internet-Draft    OPES processor and end points communications June =
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.

   The execution of such services is governed by a set of rules
   installed on the OPES processor.  The rules enforcement can trigger
   the execution of service applications local to the OPES processor.
   Alternatively, the OPES processor can distribute the responsibility
   of service execution by communicating and collaborating with one or
   more remote callout servers. As described in [8], an OPES processor
   communicates with and invokes services on a callout server by using =
a
   callout protocol.

   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 clinet centric actions
   by OPES entities. The work focus on developing tracing requirements
   that can be used to fulfil the notification and Non-Blocking
   requirements [2].

   In the OPES architecture document [8], there is a requirement of
   relaying tracing information in-band. 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.

   The document is organized as follows: .......


















Barbir                 Expires December 10, 2003                [Page =
3]
=0C
Internet-Draft    OPES processor and end points communications June =
2003


2. OPES Tracing

   Before discussing what is traceable in an OPES flow, it is =
beneficial
   to define what tracing means. Tracing is defined as the inclusion of
   necessary information within a message in an OPES flow that could be
   used to identify the set of transformations or adpatations that have
   been performed on its content before its delivery to an end point
   (the data consumer application).

   o  OPES trace:	application message information about OPES entities
      that adapted that message

   o  OPES tracing: the process of including, manipulating, and
      interpreting an OPES trace

   To emphasize, the above definition means that OPES tracing SHOULD be
   performed on per  message basis. Trace format is dependent on the
   application protocol being adapted by OPES. Data consumer =
application
   can use OPES trace to infer the actions that have been performed by
   OPES system(s). The architecture document requires [8] that tracing
   be supported in-band.

2.1 What is traceable in an OPES Flow?

   o  The data consumer application end point MUST be able to identify
      the OPES processors that have acted on an application message.

   o  The data consumer application end point SHOULD be able to =
identify
      OPES services (including callout services) that were performed on
      request/responses that are part of an application message.

   o  TBD

   o  TBD

   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 be traceable

   o  An OPES processor SHOULD be traceable

   o  An OPES service MAY be traceable

   o  Editor Note: Need to define an OPES System properly




Barbir                 Expires December 10, 2003                [Page =
4]
=0C
Internet-Draft    OPES processor and end points communications June =
2003


2.2 Requirements for Information Related to Traceable Entities?

   The requirements for information as related to entities that are
   terceable in an OPES flow are:

   o  The privacy policy at the time it dealt with the message

   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 messag

   o  TBD



































Barbir                 Expires December 10, 2003                [Page =
5]
=0C
Internet-Draft    OPES processor and end points communications June =
2003


3. Requirements for OPES systems

   Editor Note: Need to define OPES System and state requirements
















































Barbir                 Expires December 10, 2003                [Page =
6]
=0C
Internet-Draft    OPES processor and end points communications June =
2003


4. Requirements for OPES processors

   TBD
















































Barbir                 Expires December 10, 2003                [Page =
7]
=0C
Internet-Draft    OPES processor and end points communications June =
2003


5. Requirements for callout servers

   If it is the task of an OPES processor to add trace records to
   application messages, then callout servers that uses the OCP =
protocol
   are not affected by tracing requirements.In order for an OCP =
protocol
   to be tracing neutral, the OPES server SHOULD be able to meet the
   following requirements:

   o  Callout services adapt payload regardless of the application
      protocol in use and leave header adjustment to OPES processor.

   o  OPES processor SHOULD be able  to trace its own invocation and
      service(s) execution because OPES processor understand the
      application protocol.

   o  Callout servers  MAY be able to add their own OPES trace records
      to application level messages.

   o  TBD
































Barbir                 Expires December 10, 2003                [Page =
8]
=0C
Internet-Draft    OPES processor and end points communications June =
2003


6. Privacy considerations


6.1 Tracing and Trust Domains

   A trust domain may include several OPES systems and entities. Within
   a trust domain, there MUST be at least support for one trace entry
   per system. 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.






































Barbir                 Expires December 10, 2003                [Page =
9]
=0C
Internet-Draft    OPES processor and end points communications June =
2003


7. How to Support Tracing

   In order to support tracing, the following aspects must be =
addressed:

   o  There MUST be a System Identifier that identify a domain that is
      employing an OPES system.

   o  An OPES processor MUST be able to be uniquely identified (MUST
      have an Identifier) within a system.

   o  An OPES processor MUST add its identification  to the trace.

   o  An OPES processor SHOULD add to the trace  identification of =
every
      callout service that received the application message.

   o  An OPES processor MUST add to the trace identification  of the
      "system/entity" it belongs to. "System" ID MUST make it possible
      to access "system" privacy  policy.

   o  An OPES processor MAY group the above information for sequential
      trace entries having  the same "system/entity" ID. In other =
words,
      trace  entries produced within the same "system/entity"  MAY be
      merged/aggregated into a single less detailed trace entry.

   o  An OPES processor MAY delegate trace management to  a callout
      service within the same "system/entity".

   TBD

7.1 Tracing and OPES System Granularity

   There are two distinct uses of traces. First, is to SHOULD enable =
the
   "end (content producer or consumer) to detect OPES processor =
presence
   within end's trust domain. Such "end" should be able to see a trace
   entry, but does not need to be able to interpret it beyond
   identification of the trust domain(s).

   Second, the domain administrator SHOULD be able to take a trace =
entry
   (possibly supplied by an "end? as an opaque string) and interpret =
it.
   The administrator must be able to identify OPES processor(s) =
involved
   and may be able to identify applied adaptation services along with
   other message-specific information. That information SHOULD help to
   explain what OPES agent(s) were involved and what they did. It may =
be
   impractical to provide all the required information in all cases.
   This document view a trace record as a hint, as opposed to an
   exhaustive audit.

   Since the administrators of various trust domains can have various



Barbir                 Expires December 10, 2003               [Page =
10]
=0C
Internet-Draft    OPES processor and end points communications June =
2003


   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.

   It is not expected that entities in one trust domain to be able to
   get all OPES-related feedback from entities in other trust domains.
   For example, if an end-user suspects that a served is corrupted by a
   callout service, there is no guarantee that the use will be able to
   identify that service, contact its owner, or debug it _unless_ the
   service is within my trust domain. This is no different from the
   current situation where it is impossible, in general, to know the
   contact person for an application on an origin server that generates
   corrupted HTML; and even if the person is known, one should not
   expect that person to respond to end-user queries.

7.2 Requirements for In-Band Tracing

   The OPES architecture [8] states that traces must be in-band. The
   support of this design specification is dependent on the specifics =
of
   the message application level protocol that is being used in an OPES
   flow. In-band tracing 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, the work will document requirements for
   application protocols that need to support OPES traces. However, the
   architecture does not prevent implementers of developing out-of-band
   protocols and techniques to address the above limitation.

7.2.1 Tracing Information Granularity and Persistence levels
      Requirements

   In order to be able to trace entities that have acted on an
   application message in an OPES flow, there may be requirements to
   keep information that is related to the following:

   o  Message-related informatio: All data that describes specific
      actions performed on the message SHOULD be provided with that
      message, as there is no other way to find message level details
      later.

   o  Session related information: Session level data MUST be preserved
      for the duration of the session. OPES processor is responsible =
for
      inserting notifications if session-level information changes.

   o  End-point related data: What profile is activated? Where to get



Barbir                 Expires December 10, 2003               [Page =
11]
=0C
Internet-Draft    OPES processor and end points communications June =
2003


      profile details? Where to set preferences?

   o  TBD


7.3 Protocol Binding

   How tracing is added is application protocol-specific and will be
   documented in separate drafts. This work documents what tracing
   information is required and some common tracing elements.

7.4 Tracing scenarios and examples

   TBD





































Barbir                 Expires December 10, 2003               [Page =
12]
=0C
Internet-Draft    OPES processor and end points communications June =
2003


8. IAB considerations

   This section examines IAB [2] considerations (3.1) and (3.2)
   regarding notification in an OPES architecture. The IAB
   considerations are reiterated here for ease of reference.

   Notification propagates in opposite direction of tracing and cannot
   be attached to application messages that it notifies about.
   Notification can be done out-band and may require the development of
   a new protocol. The direction of data flow for tracing and
   notification are deoicted in Figure 1.



                                      Notification
                +-----------------------------------------------
                |                                               |
                |                                               V
          +---------------+            +-------+       =
+---------------+
          |               |            |       |       | Data Provider =
|
          | Data Consumer | Tracing    | OPES  |<----->|  Application  =
|
          |  Application  |<-----------|       |       =
+---------------+
          +---------------+            +-------+
                                           ^
                                           |OCP
                                           |
                                           V
                                       +---------+
                                       | Callout |
                                       | Server  |
                                       +---------+



                      Figure 1: Notification Flow


8.1 Notification Concerns

   Notifications for every HTTP request can burden some content
   providers. Therefore, it might be preferable to consider mechanisms
   that allow for the  explicit request of notification. Hence, a
   mechanism for explicit request of notification May be required.

   Furthermore, end point privacy is a concern. An end user may =
consider
   information about OPES services applied on their behalf as private.
   For example, if translation for braille device has been applied, it
   can be concluded that the user is having eyesight problems; such



Barbir                 Expires December 10, 2003               [Page =
13]
=0C
Internet-Draft    OPES processor and end points communications June =
2003


   information may be misused if the user is applying for a job online.
   Similarly, a content provider may consider information about its =
OPES
   services private. For example, use of a specific OPES intermediary =
by
   a high traffic volume site may indicate business alliances that have
   not been publicly announced yet. Another example of privacy, include
   situations where a user may not want to reveal to any content
   provider all the OPES services that have been applied on their
   behalf. For example, why should every content provider know what
   exact virus scanner a user is using?

   Security is also a concern. An attacker may benefit from knowledge
   of internal OPES services layout, execution order, software versions
   and other information that are likely to be present in  automated
   notifications.

   The level of available details in notifications versus content
   provider interest in supporting notification is a 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 [11] 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 protocol is currently not widely deployed. This is because
   the protocol does not supply  content providers with information =
such
   as client IP addresses, browser versions, or cookies.

   The 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. Thus, it
   is important to have the right balance when specifying the
   notofication requirements for OPES.

   In this document,  IAB choice of "Notification" label is interpreted
   as "Notification assistance" (i.e. making notifications meaningful)
   and is not be interpreted as a "Notification protocol".  Therefore,
   the work treats IAB considerations (3.1 and 3.2) as informative (not
   normative).

8.1.1 Addressing IAB Consideration 3.1

   The consideration is restated below for ease of reference.

   (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.




Barbir                 Expires December 10, 2003               [Page =
14]
=0C
Internet-Draft    OPES processor and end points communications June =
2003


   IAB consideration (3.1) suggests that 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.

   It is important to note that most client-centric actions happen =
after
   the application message has left the content provider(s). Thus,
   notifications cannot be piggy-backed to application messages and =
have
   to travel in the opposite direction of traces, see Figure 1. To
   address this requirement directly, one would have to develop an out
   of band protocol to support notification.

   At this stage, there is no need to develop an out of band protocol =
to
   support notification, since requiring the OPES architecture to =
having
   a  tracing facility can fulfil the objectives of notification. In
   this regard, it is recommended that tracing MUST be always-on, just
   like HTTP Via headers. This should eliminate notification as a
   separate requirement.

8.1.2 Addressing IAB Consideration 3.2

   The consideration is restated below for ease of reference.

   (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.

   TBD

   If the OPES end points cooperate then notification can be supported
   by tracing. 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 users
      cooperate, the provider(s) have all the information they need. If
      users do not cooperate, the provider(s) cannot do much about it
      (they might be able to deny service  to uncooperative users in
      some cases).




Barbir                 Expires December 10, 2003               [Page =
15]
=0C
Internet-Draft    OPES processor and end points communications June =
2003


   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
      that case.

   o  If everything else fails, providers can enforce no-adaptation
      policy using appropriate OPES bypass mechanisms and/or end-to-end
      mechanisms.











































Barbir                 Expires December 10, 2003               [Page =
16]
=0C
Internet-Draft    OPES processor and end points communications June =
2003


9. Security considerations

   TBD
















































Barbir                 Expires December 10, 2003               [Page =
17]
=0C
Internet-Draft    OPES processor and end points communications June =
2003


10. IANA Considerations

   The proposed work will evaluate current protocols for OCP. If the
   work determines that a new protocol need to be developed, then there
   may be a need to request new numbers from IANA.














































Barbir                 Expires December 10, 2003               [Page =
18]
=0C
Internet-Draft    OPES processor and end points communications June =
2003


Normative References

   [1]  McHenry, S., et. al, "OPES Scenarios and Use Cases",
        Internet-Draft TBD, May 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]  OPES working group, "OPES Service Authorization and Enforcement
        Requirements", Internet-Draft TBD, May 2002.

   [5]  OPES working group, "OPES Ruleset Schema", Internet-Draft TBD,
        May 2002.

   [6]  A. Beck et al., "Requirements for OPES Callout Protocols",
        Internet-Draft http://www.ietf.org/internet-drafts/
        draft-ietf-opes-protocol-reqs-03.txt, December 2002.

   [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-00.txt, October  2002.

   [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.





















Barbir                 Expires December 10, 2003               [Page =
19]
=0C
Internet-Draft    OPES processor and end points communications June =
2003


Informative References

   [9]   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.

   [10]  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.

   [11]  "Hit Metering", RFC .


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 December 10, 2003               [Page =
20]
=0C
Internet-Draft    OPES processor and end points communications June =
2003


Appendix A. Acknowledgements

   TBD
















































Barbir                 Expires December 10, 2003               [Page =
21]
=0C
Internet-Draft    OPES processor and end points communications June =
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 December 10, 2003               [Page =
22]
=0C
Internet-Draft    OPES processor and end points communications June =
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 December 10, 2003               [Page =
23]
=0C




------_=_NextPart_000_01C3302B.EF95BA40--


From owner-ietf-openproxy@mail.imc.org  Thu Jun 12 07:31: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 HAA04086
	for <opes-archive@ietf.org>; Thu, 12 Jun 2003 07:31:50 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QQH1-0000oZ-00
	for opes-archive@ietf.org; Thu, 12 Jun 2003 07:29:43 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QQH1-0000oW-00
	for opes-archive@ietf.org; Thu, 12 Jun 2003 07:29:43 -0400
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CBJgrb049346
	for <ietf-openproxy-bks@above.proper.com>; Thu, 12 Jun 2003 04:19:42 -0700 (PDT)
	(envelope-from owner-ietf-openproxy@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h5CBJgMj049345
	for ietf-openproxy-bks; Thu, 12 Jun 2003 04:19:42 -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 h5CBJfrb049339
	for <ietf-openproxy@imc.org>; Thu, 12 Jun 2003 04:19:42 -0700 (PDT)
	(envelope-from nsyracus@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 HAA03672;
	Thu, 12 Jun 2003 07:19:40 -0400 (EDT)
Message-Id: <200306121119.HAA03672@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-00.txt
Date: Thu, 12 Jun 2003 07:19:40 -0400
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


--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-00.txt
	Pages		: 23
	Date		: 2003-6-11
	
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-00.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-00.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-00.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-6-11134824.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-opes-end-comm-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-opes-end-comm-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-6-11134824.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-ietf-openproxy@mail.imc.org  Thu Jun 12 08:31: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 IAA07267
	for <opes-archive@ietf.org>; Thu, 12 Jun 2003 08:31:28 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QRCk-0001h0-00
	for opes-archive@ietf.org; Thu, 12 Jun 2003 08:29:22 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QRCj-0001gr-00
	for opes-archive@ietf.org; Thu, 12 Jun 2003 08:29: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 h5CCJ1rb051428
	for <ietf-openproxy-bks@above.proper.com>; Thu, 12 Jun 2003 05:19:01 -0700 (PDT)
	(envelope-from owner-ietf-openproxy@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h5CCJ03I051426
	for ietf-openproxy-bks; Thu, 12 Jun 2003 05:19:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f
Received: from smtp.us2.messagingengine.com (ny2.fastmail.fm [66.111.4.3])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CCIxrb051415
	for <ietf-openproxy@imc.org>; Thu, 12 Jun 2003 05:18:59 -0700 (PDT)
	(envelope-from markus@mhof.com)
Received: from www.fastmail.fm (server1.internal [10.202.2.132])
	by server2.messagingengine.com (Postfix) with ESMTP id A59CF6D295
	for <ietf-openproxy@imc.org>; Thu, 12 Jun 2003 08:18:57 -0400 (EDT)
Received: from 127.0.0.1 ([127.0.0.1] helo=www.fastmail.fm) by messagingengine.com
  with SMTP; Thu, 12 Jun 2003 08:18:57 -0400
X-Epoch: 1055420337
X-Sasl-enc: FQXOnMBoYqFFNoK8IgtveA
Received: from mhof.com (H-135-104-86-17.research.bell-labs.com [135.104.86.17])
	by www.fastmail.fm (Postfix) with ESMTP id E0CEE2CCFE
	for <ietf-openproxy@imc.org>; Thu, 12 Jun 2003 08:18:56 -0400 (EDT)
Message-ID: <3EE87029.4010308@mhof.com>
Date: Thu, 12 Jun 2003 08:20:57 -0400
From: Markus Hofmann <markus@mhof.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: OPES WG <ietf-openproxy@imc.org>
Subject: Re: IAB Treatment version head_sid8 available
References: <Pine.BSF.4.53.0305282033330.88613@measurement-factory.com> <3EE3F757.3090704@mhof.com>
In-Reply-To: <3EE3F757.3090704@mhof.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit


Abbie, Alex,

since no one objected, please go ahead and sbmit the document as WG draft.

Thanks,
   Markus

Markus Hofmann wrote:
> 
> Folks,
> 
> please check out the current version of the "IAB considerations" draft 
> and provide comments via the mailing list. Also check out the comments 
> that have been mdae on the mailing list so far.
> 
> Unless someone objects by Wednesday 6/11, we'd ask Alex and Abbie to 
> submit the the current version of document for publication as WG ID. As 
> usual, the WG will continue to work on this draft, it's *not* finalized 
> yet.
> 
> Thanks,
>   Markus
> 
> 
> Alex Rousskov wrote:
> 
>>
>> This snapshot may not represent working group or even authors
>> consensus!
>>
>> The [major] change log is quoted below. The latest snapshot, including
>> XML sources for those doing hands-on modifications, is available at
>>
>>     http://www.measurement-factory.com/tmp/opes/
>>
>> Please comment.
>>
>> Thank you,
>>
>> Alex.
>>
>> -------------- change log ----------------
>>
>>     *  Added unpolished meat for all nine considerations.
>>     *  Added Abbie Barbir as an author.
>>
> 
> 



From owner-ietf-openproxy@mail.imc.org  Fri Jun 13 08:03: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 IAA29586
	for <opes-archive@ietf.org>; Fri, 13 Jun 2003 08:03:57 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QnFd-0003tC-00
	for opes-archive@ietf.org; Fri, 13 Jun 2003 08:01:49 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QnFc-0003t8-00
	for opes-archive@ietf.org; Fri, 13 Jun 2003 08:01:48 -0400
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h5DBpgrb041874
	for <ietf-openproxy-bks@above.proper.com>; Fri, 13 Jun 2003 04:51:42 -0700 (PDT)
	(envelope-from owner-ietf-openproxy@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h5DBpgKi041873
	for ietf-openproxy-bks; Fri, 13 Jun 2003 04:51:42 -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 h5DBpfrb041868
	for <ietf-openproxy@imc.org>; Fri, 13 Jun 2003 04:51:41 -0700 (PDT)
	(envelope-from nsyracus@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 HAA29160;
	Fri, 13 Jun 2003 07:51:41 -0400 (EDT)
Message-Id: <200306131151.HAA29160@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-iab-00.txt
Date: Fri, 13 Jun 2003 07:51:40 -0400
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


--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 Treatment of IAB Considerations
	Author(s)	: A. Barbir, A. Rousskov
	Filename	: draft-ietf-opes-iab-00.txt
	Pages		: 23
	Date		: 2003-6-12
	
IETF Internet Architecture Board (IAB) expressed nine
architecture-level considerations when Open Pluggable Edge Services
(OPES) working group was being chartered at the IETF.  The working
group was chartered under the condition that IAB considerations were
addressed by the group. This document describes how OPES addresses
those considerations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-opes-iab-00.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-iab-00.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-iab-00.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-6-12141937.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-opes-iab-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-opes-iab-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-6-12141937.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-ietf-openproxy@mail.imc.org  Tue Jun 24 21:33: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 VAA01693
	for <opes-archive@ietf.org>; Tue, 24 Jun 2003 21:33:05 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19UxLh-0000DB-00
	for opes-archive@ietf.org; Tue, 24 Jun 2003 19:37:17 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19UxLG-0000C3-00
	for opes-archive@ietf.org; Tue, 24 Jun 2003 19:36: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 h5OM7Urb095528
	for <ietf-openproxy-bks@above.proper.com>; Tue, 24 Jun 2003 15:07: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 h5OM7UMK095527
	for ietf-openproxy-bks; Tue, 24 Jun 2003 15:07:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h5OM7Trb095520
	for <ietf-openproxy@imc.org>; Tue, 24 Jun 2003 15:07:29 -0700 (PDT)
	(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.9/8.12.9) with ESMTP id h5OM7S9Y008533
	for <ietf-openproxy@imc.org>; Tue, 24 Jun 2003 18:07:28 -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 h5OM7LUf084410
	for <ietf-openproxy@imc.org>; Tue, 24 Jun 2003 18:07:21 -0400 (EDT)
Received: from bell-labs.com (abeck-hopc [135.180.240.202])
	by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h5OM7GQ4022523;
	Tue, 24 Jun 2003 18:07:16 -0400 (EDT)
Message-ID: <3EF8CADD.2060201@bell-labs.com>
Date: Tue, 24 Jun 2003 18:04:13 -0400
From: Andre Beck <abeck@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-openproxy@imc.org
CC: Markus Hofmann <hofmann@bell-labs.com>
Subject: draft-beck-opes-irml-03.txt
Content-Type: multipart/mixed;
 boundary="------------050306090407040500030000"
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


This is a multi-part message in MIME format.
--------------050306090407040500030000
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

We revived and re-submitted the attached IRML draft in an attempt to 
trigger some discussion on how to specify service execution rules in OPES.

Comments welcome!

-Andre

--------------050306090407040500030000
Content-Type: text/plain;
 name="draft-beck-opes-irml-03.txt"
Content-Disposition: inline;
 filename="draft-beck-opes-irml-03.txt"
Content-Transfer-Encoding: 7bit


   Internet Draft                                              A. Beck 
                                                            M. Hofmann 
   Expires: December 23, 2003                      Lucent Technologies 
   Document: draft-beck-opes-irml-03.txt            
                                                         June 24, 2003 
   Category: Informational                          
    
    
    
       IRML: A Rule Specification Language for Intermediary Services 
    
    
Status of this Memo 
    
   This document is an Internet-Draft and is in full conformance 
   with all provisions of Section 10 of RFC2026 [1]. 
    
   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. 
    
    
Abstract 
    
   The Intermediary Rule Markup Language (IRML) is an XML-based 
   language that can be used to specify rules for the execution of OPES 
   services. 
    
   OPES services are a new class of applications running on network 
   intermediaries, such as caches, proxies, gateways, etc. or dedicated 
   (callout) servers. They are invoked through intermediaries acting on 
   behalf of application endpoints. IRML is designed to serve as a 
   simple and efficient, but yet powerful language to express the 
   service execution policies of application endpoints. IRML rules are 
   typically processed by intermediaries that trigger the execution of 
   OPES services according to these rules and policies.  






    
   Beck, Hofmann        Expires December 2003                [Page 1] 
   Internet Draft                IRML                        June 2003 
    
    
Table of Contents 
    
   1  Terminology....................................................3 
   2  Introduction...................................................3 
   3  IRML Syntax and Grammar........................................4 
   3.1  High-level Structure of IRML Documents.......................4 
   3.2  IRML Rule Modules............................................5 
   3.2.1 The "rulemodule" Element....................................5 
   3.3  IRML Rule Authors............................................5 
   3.3.1 The "author" Element........................................5 
   3.3.2 The "name" Element..........................................6 
   3.3.3 The "contact" Element.......................................6 
   3.3.4 The "id" Element............................................6 
   3.3.5 IRML Rule Author Examples...................................6 
   3.4  IRML Rule Sets...............................................6 
   3.4.1 The "ruleset" Element.......................................6 
   3.4.2 The "authorized-by" Element.................................6 
   3.4.3 The "protocol" Element......................................7 
   3.5  IRML Rules...................................................7 
   3.5.1 The "rule" Element..........................................7 
   3.6  IRML Rule Conditions.........................................9 
   3.6.1 The "property" Element......................................9 
   3.6.2 Unconditional Rules........................................11 
   3.7  IRML Rule Actions...........................................11 
   3.7.1 The "execute" Element......................................11 
   3.7.2 The "service" Element......................................11 
   3.7.3 The "uri" Element..........................................12 
   3.7.4 The "any" Element..........................................13 
   3.7.5 The "parameter" Element....................................13 
   3.7.6 The "value" Element........................................14 
   3.7.7 The "variable" Element.....................................14 
   3.8  IRML Rule Set Example.......................................14 
   4  IRML Rule Processing..........................................15 
   4.1  Conflict Resolution for Endpoints...........................15 
   4.2  Order of Service Execution..................................15 
   5  IAB Considerations............................................16 
   6  Security Considerations.......................................18 
   7  Acknowledgements..............................................18 
   8  References....................................................18 
   Authors' Addresses................................................19 
   Appendix A - IRML DTD.............................................19 
   Appendix B - IRML Extensions for HTTP.............................20 
   Appendix C - IRML Sub-Systems.....................................21 
   Appendix D - Rule Module Examples.................................21 
   Appendix E - IRML Change Log......................................24 

     
   Beck, Hofmann        Expires December 2003                [Page 2] 
   Internet Draft                IRML                        June 2003 
    
   Full Copyright Statement..........................................25 
 
    
1  Terminology  
    
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
   document are to be interpreted as described in RFC 2119 [2].  
    
   DATA TRANSACTION 
    
   A message exchange between a data consumer and a data provider, 
   typically consisting of a data request and a data response message. 
    
   DATA PATH 
    
   The path that data requests and responses take through the network. 
   Typically, data requests and responses flow between a data consumer 
   and a data provider. 
    
   DATA PATH PROTOCOL 
    
   The application-layer protocol used between the two endpoints of a 
   data transaction, e.g. HTTP or RTSP. 
    
   Other terminology used in this document is consistent with that 
   defined and used in [3].      
    
2  Introduction 
    
   This document defines the Intermediary Rule Markup Language (IRML) 
   in an attempt to create a standard representation of OPES service 
   execution policies. It is designed to be simple, efficient, and easy 
   to understand but yet powerful enough to cover complex scenarios 
   with a large number of rules and rule conditions. 
    
   IRML can be used in particular, but not exclusively, in the context 
   of the OPES framework as proposed in [3] and [4]. Since OPES 
   services may only be executed on behalf of data providers or data 
   consumers - the two endpoints of a data transaction - IRML-specified 
   rules must reflect the intents of either of the two endpoints. A 
   data provider like CNN, for example, may wish to specify the 
   conditions under which CNN web pages may be adapted to fit the 
   screen for users with small wireless devices. The customers of an 
   ISP, on the other hand, may wish to specify the conditions for the 
   execution of a privacy service that removes certain information from 
   user requests before they are sent to an origin server (e.g. the 
   "referer" header in HTTP requests).  
    
   In its basic form, IRML is not tied to any particular data path 
   protocol or deployment environment. However, IRML allows for 

     
   Beck, Hofmann        Expires December 2003                [Page 3] 
   Internet Draft                IRML                        June 2003 
    
   extensions that can be used to better accommodate the specifics of 
   data path protocols or different deployment environments. 
     
   It is anticipated that IRML rules will either be authored directly 
   by data providers or data consumers or indirectly through an 
   authorized delegate such as an ISP.  
    
   IRML-specified rules are meant to be processed by a rule processor 
   on an intermediary device (e.g. a caching proxy, an access router, a 
   wireless gateway, or a switch) located in the path between data 
   providers and consumers. IRML rules are matched by evaluating rule 
   conditions against the properties of incoming and outgoing messages 
   and possibly also system and environment variables.  
    
   IRML is designed to be easily created and edited by graphical 
   tools. It is based on XML [5], so many publicly available parsers 
   and editing tools can be used in this process. The structure of the 
   language maps closely to its behavior, so that an editor can easily 
   understand IRML rule modules, even ones written by hand. The 
   language is also designed so that an IRML-enabled intermediary or 
   admin server can easily confirm the validity of IRML rule modules. 
    
   Although this document does not define a secure and reliable 
   mechanism for transferring IRML rule files to intermediary devices 
   (or other OPES entities), it is expected that existing protocols 
   (e.g. HTTPS) can be used for this purpose. 
    
3  IRML Syntax and Grammar  
    
   IRML is an application of XML. Thus, its syntax is governed by the 
   rules of the XML syntax as defined in [5], and its grammar is 
   specified by a DTD, or Document Type Definition. The IRML DTD can be 
   found in Appendix A.  
    
   An IRML rule module that appears as a top-level XML document is 
   identified with the formal public identifier "-//IETF//DTD RFCxxxx 
   IRML 1.0//EN". 
    
   An IRML rule module embedded as a fragment within another XML 
   document is identified with the XML namespace identifier 
   "http://www.rfc-editor.org/rfc/rfcxxxx.txt". 
    
3.1 High-level Structure of IRML Documents 
    
   Valid and well-formed IRML documents consist of one or more rule 
   modules. Each rule module has a section that describes the rule 
   module author. IRML rule modules can be authored directly by data 
   providers or consumers but also indirectly through authorized 
   delegates. The IRML rule author section is followed by one or more 
   IRML rule sets and information about the party that authorized each 
   set of rules. 
    

     
   Beck, Hofmann        Expires December 2003                [Page 4] 
   Internet Draft                IRML                        June 2003 
    
   The rules contained in a rule set each consist of a number of IRML 
   rule conditions and a number of consequent IRML rule actions that 
   are to be performed if the rule conditions become true. Through IRML 
   rule actions, endpoints can request the execution of services. 
    
   The conditions within a rule refer to message properties in the 
   request or response message of a given data transaction. They are 
   met if the property value matches the pattern(s) specified in the 
   rule condition(s). Rule conditions may also refer to system or 
   service-manipulated environment variables. 
    
3.2 IRML Rule Modules 
    
   IRML rule modules represent the service execution policies of data 
   providers and data consumers. The service execution policy of a 
   specific data provider or consumer MAY be expressed through more 
   than one IRML rule module. 
    
3.2.1   The "rulemodule" Element  
    
   The "rulemodule" element is the root element for all IRML rule 
   modules and MAY/MUST contain the following elements (see also IRML 
   DTD in Appendix A). 
    
3.3 IRML Rule Authors 
    
   IRML rule modules can be authored by data providers, data consumers, 
   or authorized delegates who author rule modules on behalf of data 
   providers or consumers.  
    
3.3.1   The "author" Element  
        
   The "author" element specifies the author of a rule module. Each 
   rule module MUST have exactly one author.  
    
    
   Attributes of "author"  
    
   Name         Values                         Default 
   ----------------------------------------------------  
   type         delegate|self                  self 
        
   The "type" attribute assigns a rule module author to one of the two 
   possible types of rule module authors. An attribute value of 
   "delegate" indicates that the rule module author acts as a delegate 
   for one or more endpoints. An attribute value of "self" indicates 
   that a rule module is authored directly by a data provider or 
   consumer. 
    
   The rule module author is described further by a "name", "id", and 
   optionally a "contact" element which are described in the following 
   sections. 
     
   Beck, Hofmann        Expires December 2003                [Page 5] 
   Internet Draft                IRML                        June 2003 
    
     
3.3.2   The "name" Element  
    
   The "name" element MUST contain a descriptive name for the rule 
   module author. The name does not have to be unique among rule module 
   authors. 
    
3.3.3   The "contact" Element 
    
   The "contact" element is an optional element that, if used, MUST 
   contain a valid email address at which the rule author can be 
   contacted. 
    
3.3.4   The "id" Element  
    
   The "id" element MUST contain a globally unique identifier for the 
   rule module author, for example a URI or an email address. 
    
3.3.5   IRML Rule Author Examples  
    
   <author type="delegate">  
     <name>Comcast</name>  
     <contact>rule-management@comcast.com</contact> 
     <id>www.comcast.com</id>  
   </author>  
    
   <author type="self">  
     <name>Andre Beck</name>  
     <contact>abeck@home.com</contact> 
     <id>abeck@home.com</id>  
   </author>  
    
3.4 IRML Rule Sets 
    
   IRML rule sets represent a collection of rules that apply to and 
   have been authorized by the same data provider or data consumer. 
        
3.4.1   The "ruleset" Element 
 
   The "ruleset" element MUST contain one or more "rule" elements. Rule 
   modules authored directly by a data provider or consumer MUST 
   contain exactly one "ruleset" element. Rule modules authored 
   indirectly through an authorized delegate on the other hand MAY 
   contain more than one set of rules where each rule set MUST be 
   authorized by a different data provider/consumer. 
    
3.4.2   The "authorized-by" Element 
 
   The "authorized-by" element specifies the authorizing data 
   transaction endpoint for a set of rules. This MUST be either a data 
   provider or a data consumer. In self-authored rule modules, the 
   authorizing endpoint MUST be identical with the rule module author. 

     
   Beck, Hofmann        Expires December 2003                [Page 6] 
   Internet Draft                IRML                        June 2003 
    
    
   Name         Values                           Default 
   -----------------------------------------------------  
   class        data-provider|data-consumer  
   type         individual|group                 
    
   The "class" attribute specifies whether the authorizing endpoint is 
   a data provider or data consumer.  
    
   The "type" attribute specifies whether the corresponding rule set 
   applies to and has been authorized by an individual data 
   provider/consumer or a group of data providers/consumers. An 
   attribute value of "group" means that the rules in the corresponding 
   rule set apply to all members of the specified group. A value of 
   "group" MAY only be used if the rule module author is a delegate and 
   primarily serves as a means of simplifying cases where a large 
   number of data providers/consumers have identical rules. This can be 
   the case, for example, if an ISP manages rules on behalf of its 
   customers or in an enterprise environment. 
     
   The "authorized-by" element MUST contain a "name" and "id" element 
   as described in 3.3.2 and 3.3.4 and MAY contain a "contact" element 
   as described in 3.3.3 to further identify the authorizing endpoint.  
    
   If the authorizing endpoint is of the type "individual", then these 
   elements MUST contain the endpoint's name, globally unique id (such 
   as a URI or email address), and optionally a contact email address.  
    
   If the authorizing endpoint is of the type "group", then the "name" 
   and "id" elements MUST contain a descriptive name and a globally 
   unique identifier for the corresponding group of data 
   providers/consumers and the "contact" element SHOULD contain an 
   email address at which the delegate managing the group can be 
   contacted. 
    
3.4.3   The "protocol" Element  
    
   The "protocol" element specifies the applicable data path protocol 
   for a set of rules. It MUST contain the protocol acronym of the 
   applicable data path protocol. For example, rule sets applying to 
   HTTP messages MUST specify "HTTP" in the "protocol" element. Each 
   rule set MUST apply to exactly one data path protocol. 
    
3.5 IRML Rules 
    
   IRML rules make up the actual service execution policies of data 
   providers and consumers. They are composed of rule conditions and 
   rule actions. 
     
3.5.1   The "rule" Element  
    


     
   Beck, Hofmann        Expires December 2003                [Page 7] 
   Internet Draft                IRML                        June 2003 
    
   The "rule" element typically contains one or more "property" 
   elements which represent rule conditions in IRML. In the case of 
   unconditional rules, "rule" elements MAY also contain elements 
   representing rule actions ("execute" elements). 
    
   Attributes of "rule"  
        
   Name                 Values  
   ----------------------------  
   processing-point     1|2|3|4  
    
   The "processing-point" attribute specifies at which of the four 
   points in figure 1 a rule MUST be processed by the rule engine on 
   the intermediary device. The four common processing points of an 
   OPES intermediary are further defined in [6]. Implementation 
   architectures for other intermediary devices might define different 
   or additional processing points. 
    
   Figure 1 shows the typical HTTP data flow between a client, an IRML-
   enabled intermediary (in this case a caching proxy), and an origin 
   server. The four processing points (1-4) represent locations in the 
   round trip message flow where rules can be processed and service 
   applications can be executed. A virus scanning service for instance 
   could be executed at point 3 in figure 1 in order to scan web 
   objects for viruses before they are stored in the cache. A URI-based 
   request filtering service on the other hand could be executed at 
   point 1 and a language translation service could be executed at 
   point 4. Note that in a caching proxy the message flow may skip 
   points 2 and 3 after point 1 if the requested object can be served 
   from cache.  
    
    
    
        
   +--------+       +-----------+       +--------+  
   |        |<------|4         3|<------|        |  
   | Client |       |  Caching  |       | Origin |  
   |        |       |   Proxy   |       | Server |  
   |        |------>|1         2|------>|        |  
   +--------+       +-----------+       +--------+  
      
   Figure 1: Rule Processing/Service Execution Points  
        
   Depending on the service type, rules may be processed and services 
   may be executed at any of the four points outlined in figure 1. 
   However, the local policy of an intermediary MAY prevent endpoints 
   from executing service applications at certain processing points. 
   For example, data consumers may not be allowed to execute service 
   applications at processing point 3 because a modified response 
   message may subsequently be cached and served to other data 
   consumers as well. 
    

     
   Beck, Hofmann        Expires December 2003                [Page 8] 
   Internet Draft                IRML                        June 2003 
    
3.6 IRML Rule Conditions 
    
   IRML rule conditions specify a pattern and a message, system, or 
   service property. Rule conditions are evaluated by matching the 
   specified pattern against the value of the specified message, 
   system, or service property at the time of the evaluation.    
    
3.6.1   The "property" Element  
    
   The "property" element represents a rule condition and MAY contain 
   one or more other "property" elements and/or one or more elements  
   representing rule actions, i.e. "execute" elements. Nested 
   "property" elements represent a hierarchical "AND" relationship. 
   This means that an inner "property" condition can only be true if 
   the outer "property" condition is true and so forth.  
        
   Attributes of "property"  
        
   Name              Values                            Default 
   -----------------------------------------------------------  
   name              CDATA  
   context           (req-msg|res-msg|system|service)    
   matches           CDATA  
   not-matches       CDATA 
   case-sensitive    (yes|no)                             "no" 
   sub-system        CDATA                           "standard"   
     
   The "name" attribute specifies the name of the property that is to 
   be matched.  
    
   The "context" attribute specifies the property type further. A 
   property context value of "req-msg" or "res-msg" indicates that the 
   corresponding "property" element refers to a request or a response 
   message property, i.e. a protocol-specific request or response 
   header. For HTTP messages, for example, the list of protocol-
   specific header names is defined in [7]. IRML, however, is not 
   limited to the message properties defined in protocol 
   specifications. User-defined message properties (e.g. user-defined 
   protocol headers) MAY also be used. 
    
   Note that rule conditions at processing points 1 and 2 can typically 
   only reference request message properties, whereas rule conditions 
   at processing points 3 and 4 can reference request and response 
   message properties.  
    
   If the "context" attribute is specified as "system", then the 
   property name refers to system variables that are set by the 
   intermediary.  
        
   IRML defines the following general system property variables which 
   MUST be supported by all IRML-compliant intermediaries: 
    

     
   Beck, Hofmann        Expires December 2003                [Page 9] 
   Internet Draft                IRML                        June 2003 
    
   Property Name        Value  
   --------------------------------------------------------------  
   "system-date"        a timestamp using the Internet date-time 
                        format as defined in [8]  
   "client-ip"          the IP address of the data consumer in  
                        the common dotted-decimal format 
                         
   In addition to these general system properties, IRML also defines 
   data path protocol-specific system properties.  
    
   Currently, IRML only defines protocol-specific system properties for 
   HTTP which can be found in Appendix B.  
    
   If the property "context" attribute is specified as "service", then 
   the property name refers to service-specific environment variables 
   that can be set and modified by service applications. These can be 
   used by service applications to maintain state information beyond a 
   particular session. If these service variables are referenced in 
   IRML rule conditions, then service applications can dynamically 
   adapt the conditions that lead to specific rule actions without 
   altering the actual rule. 
    
   Service-specific variables can also be used for the communication 
   between different services, e.g. if one service applications sets a 
   state variable that is subsequently read by another service 
   application. 
    
   The "matches" attribute specifies the pattern against which the 
   property value MUST be matched by the rule engine on the 
   intermediary device. The "matches" pattern MUST be a regular 
   expression compliant with the extended regular expression syntax as 
   defined in [9].  
    
   A "property" rule condition is considered true if the pattern 
   provided in the "matches" attribute matches the message, system, or 
   service attribute value referred to by the "property" element 
   through its "name" and "type" attribute values.  
    
   The "not-matches" attribute MAY be used instead of the "matches" 
   attribute to express "property" rule conditions that are considered 
   true if the provided pattern does NOT match the referenced attribute 
   value. 
        
   The "case-sensitive" attribute specifies whether the matching of the 
   pattern specified in the "matches" or "not-matches" attributes must 
   be performed case sensitive or not. The default value for this 
   attribute is "no" meaning that pattern matching is case insensitive 
   unless otherwise specified. The matching of property names, 
   regardless of their type, is always case insensitive. 
    
   The "sub-system" attribute can be used with a "context" attribute 
   value of "system" to specify rules for services that require the 

     
   Beck, Hofmann        Expires December 2003               [Page 10] 
   Internet Draft                IRML                        June 2003 
    
   evaluation of non-standard system properties which may not be 
   supported by all intermediaries. For example, limited  
   client bandwidth adaptation and streaming media adaptation services 
   may require service execution rules that reference quality of 
   service properties, such as the allocated bandwidth or the packet 
   loss rate. 
    
   The default sub-system for IRML "property" elements is "standard" 
   which means that only those system properties MAY be referenced that 
   are defined in this document. If the "sub-sytem" attribute is used 
   to specify the name of a sub-sytem other than "standard", then it is 
   up to the referenced sub-sytem to define the supported system 
   properties and how "property" rule conditions are to be matched.  
    
   Appendix C lists all currently known IRML sub-sytem specifications. 
   Rule modules that use an IRML sub-system other than the "standard" 
   sub-system MAY only be distributed to intermediaries that 
   specifically offer support for the specified sub-system. An IRML 
   rule processor that encounters a "property" rule condition with an 
   unknown sub-system MUST consider the rule condition as false. 
    
3.6.2   Unconditional Rules 
    
   If a "rule" element contains an element representing a rule action 
   outside of any "property" elements, then the specified rule action 
   MUST be performed for all data path protocol messages that originate 
   from or are intended for the authorizing endpoint and pass through 
   the specified processing point. Services with logging functionality, 
   for example, may have to be triggered for all user requests that 
   pass through the intermediary device. 
    
    
3.7 IRML Rule Actions 
    
   Through IRML rule actions, endpoints can request the execution of 
   services. This type of rule action is expressed through the 
   following IRML elements. 
    
3.7.1   The "execute" Element 
 
   The "execute" element is a rule action element that can be used to 
   express the intent of the authorizing endpoint to execute a specific 
   service application if the surrounding "property" rule conditions 
   are true. The service that the rule author wants to be executed is 
   further specified by the contained "service" element(s).  
 
 
3.7.2   The "service" Element 
 
   Rule action elements apply to a service application which is further 
   specified by the "service" element. The "service" element contains 
   either a "uri" to identify a specific service application or an 

     
   Beck, Hofmann        Expires December 2003               [Page 11] 
   Internet Draft                IRML                        June 2003 
    
   "any" element if a rule action applies to any service application. 
   It MAY also contain any number of "parameter" elements. 
    
   Attributes of "service"  
        
   Name              Values                            Default 
   -----------------------------------------------------------  
   name              CDATA 
   failure           (abort|ignore|try-alternate)      "abort" 
   type              (primary|alternate)             "primary" 
    
    
   The "name" attribute contains a descriptive name of the service 
   application, e.g. "Norton Virus Scanning".  
    
   The "failure" attribute specifies how the intermediary MUST react to 
   a service execution failure of the specified service application. 
    
   An attribute value of "abort" (which is also the default value) 
   indicates that the intermediary MUST abort the current data 
   transaction and inform the data consumer and possibly also the data 
   provider of the service execution failure. 
    
   An attribute value of "ignore" indicates that the intermediary MUST 
   ignore the service execution failure and continue the rule 
   processing as though it never attempted to execute the specified 
   service.  
    
   An attribute value of "try-alternate" indicates that the 
   intermediary MUST attempt to execute an alternate service 
   application instead of the failed service application. If multiple 
   alternate services are given, then the intermediary MUST attempt to 
   execute them in the order they are specified.  
    
   The "type" attribute specifies whether the "service" element 
   specifies a primary or an alternate service application. Alternate 
   service applications MUST only be executed if the execution of the 
   primary service application fails. A rule action element MAY only 
   contain one "service" element of the type "primary", but MAY contain 
   multiple "service" elements of the type "alternate". If a "service" 
   element has a "failure" attribute value of "try-alternate", then it 
   MUST be followed directly by at least one "service" element of the 
   type "alternate". 
    
3.7.3   The "uri" Element  
    
   The "uri" element identifies the service application of the 
   corresponding "service" element. The "uri" element does not, 
   however, specify a specific instance of a service application, e.g. 
   a specific installation on a specific server. Instead, the IRML-
   enabled intermediary can map the identified service application to a 
   specific instance at run-time in order to accommodate for system or 

     
   Beck, Hofmann        Expires December 2003               [Page 12] 
   Internet Draft                IRML                        June 2003 
    
   network conditions, e.g. the current system load on a particular 
   remote callout server.  
    
   The "uri" element MUST contain an absolute URI that follows the URI 
   syntax as defined in [10] and uniquely identifies a service 
   application including its version. Each "uri" element MAY contain 
   one service identifier.  
    
   The service identifier, to serve its intended purpose, MUST have the 
   characteristics of global uniqueness and persistence. It is not a 
   goal that it conveys information about how to retrieve or locate a 
   service. Because Uniform Resource Names [11] have been designed with 
   these goals in mind, URNs SHOULD be used as service identifiers. 
   However, other URIs can be managed in such a way as to achieve the 
   same goals. 
    
3.7.4   The "any" Element 
 
   The "any element is an empty element that can be used instead of the 
   "uri" element to express that the surrounding rule action applies to 
   any service application. For example, a rule author may wish to 
   express that under certain rule conditions no service application 
   should be executed. The "any" element MAY not be used in combination 
   with the "execute" element. 
    
3.7.5   The "parameter" Element 
 
   The "parameter" element is an optional element that can be used in 
   combination with "execute" rule actions to specify one or more 
   parameters that MUST be passed to the service application as it is 
   being executed. It MAY contain either a "variable" or a "value" 
   element which represent two different types of parameters. They are 
   described in the following two sections. 
    
   Attributes of "parameter"  
        
   Name              Values                            Default 
   ----------------------------------------------------------- 
   name              CDATA 
   type              (static|dynamic) 
    
   The "name" attribute specifies the name of the parameter as it is 
   passed to the service application.  
    
   The "type" attribute specifies whether the parameter value is static 
   or dynamic. Static "parameter" elements MUST contain a "value" 
   element and dynamic "parameter" elements MUST contain a "variable" 
   element. 
    




     
   Beck, Hofmann        Expires December 2003               [Page 13] 
   Internet Draft                IRML                        June 2003 
    
3.7.6   The "value" Element 
 
   The "value" element contains a static character value which MUST be 
   passed to the service application along with the name of the 
   surrounding "parameter" element. 
    
3.7.7   The "variable" Element 
 
   The "variable" element specifies a message, system, or service 
   property whose current value MUST be passed to the service 
   application along with the name of the surrounding "parameter" 
   element. 
    
    
   Attributes of "variable"  
        
   Name              Values                              Default 
   ------------------------------------------------------------- 
   name              CDATA 
   context           (req-msg|res-msg|system|service)    
   sub-system        CDATA                             "standard"   
    
   The "name", "context", and "sub-system" attributes have the same 
   semantics as the ones in the "property" element (section 3.6.1). 
    
3.8 IRML Rule Set Example 
 
   <ruleset> 
     <authorized-by class="data-consumer" type="individual"> 
       <name>A. Beck</name> 
       <contact>abeck@lucent.com</contact> 
       <id>abeck@lucent.com</contact> 
     </authorized-by> 
     <protocol>HTTP</protocol> 
     <rule processing-point=1> 
       <!-- Log ALL my requests --> 
       <execute> 
         <service name="Request Log"> 
           <uri>opes://log.com/requestlog-v1.0</uri> 
           <parameter name="timestamp" type="dynamic"> 
             <variable name="system-time" context="system"/> 
           </parameter> 
         </service> 
       </execute>     
     </rule> 
     <rule processing-point=4> 
       <!-- Is the requested web resource a HTML document? -->  
       <property name="Content-Type" context="res-msg" 
                                                   matches="text/html">  
         <!-- Is the user's preferred language supported? -->  
         <property name="Accept-Languages" context="req-msg" 
                                             matches="^de|^fr|^it|^es">  

     
   Beck, Hofmann        Expires December 2003               [Page 14] 
   Internet Draft                IRML                        June 2003 
    
           <!-- Invoke translation service Babelfish -->  
           <execute> 
             <service name="BabelFish Translation">  
               <uri>opes://altavista.com/babelfish</uri>  
             </service> 
           </execute> 
         </property>  
       </property>  
     </rule>  
   </ruleset> 
    
   More complete and complex rule module examples can be found in 
   Appendix D. 
    
4  IRML Rule Processing 
    
   For each data transaction the rule processor on the intermediary 
   located in the path between data consumers and data providers MUST 
   process only those IRML rule sets that are relevant to the current 
   transaction, i.e. all IRML rule modules that apply to the data path 
   protocol of the transaction (as specified by the "protocol" element) 
   and contain rule sets which have been authorized by either endpoint 
   of the transaction. Within each rule set only those rules MUST be 
   evaluated that apply to the current rule processing point. 
    
   The rule processor MUST also take into account that message and 
   service property values may be modified by the execution of service 
   applications. It MAY therefore be necessary for the rule processor 
   to re-evaluate rule conditions after the execution of a service 
   application. However, no service application MAY be executed more 
   than once as a result of the re-evaluation of rule conditions. 
     
4.1 Conflict Resolution for Endpoints 
    
   When processing rules, the rule processor MUST evaluate all rule 
   conditions of relevant rules in order to determine the intents of 
   both endpoints. Potential conflicts between the intentions of the 
   two endpoints MUST then be resolved according to the local policy of 
   the intermediary.  
        
4.2 Order of Service Execution  
    
   The order in which service applications on the intermediary device 
   are executed may influence the final result of a data transaction. 
   For example, a content analyzer/filtering service executed against 
   the result of a web page translation service may produce a different 
   result than a reverse execution order.  
    
   Within sets of rules authorized by the same endpoint, it is 
   reasonable that the authorizing endpoint should be able to determine 
   the service execution order. Within any "ruleset" element, services 


     
   Beck, Hofmann        Expires December 2003               [Page 15] 
   Internet Draft                IRML                        June 2003 
    
   MUST therefore be executed in the order they are specified in the 
   "rule", "property", and "execute" elements. 
     
   It is generally not possible, however, to automatically determine a 
   correct order if both endpoints request the execution of different 
   services at the same processing point. In these cases, the 
   intermediary MUST determine the service execution order. 
    
   In many cases, it may make sense to base this decision on the 
   request/response message flow of a data transaction, i.e. for 
   incoming requests at processing points 1 and 2, the order of service 
   execution would be:  
    
   1. Data consumer authorized rule actions  
   2. Data provider authorized rule actions  
    
   For outgoing responses at points 3 and 4, the service execution 
   order would be reverse:  
    
   1. Data provider authorized rule actions  
   2. Data consumer authorized rule actions  
    
5  IAB Considerations 
    
   This section quotes the IAB's architectural and policy 
   considerations for the OPES framework [12] and describes how these 
   are addressed by this document or why they are not relevant to IRML: 
    
   (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)." 
    
   As described in section 3.4.2 and throughout the document, this 
   document REQUIRES that each set of rules in IRML rule modules be 
   authorized by one of the endpoints of a data transaction. 
    
    
   (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" 
    
   This document does not specify or impact the addressing of OPES 
   intermediaries by the end user. 
    
    
   (3) "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." 
    


     
   Beck, Hofmann        Expires December 2003               [Page 16] 
   Internet Draft                IRML                        June 2003 
    
   Both data providers and data consumers can use IRML to express their 
   service execution policies. The processing of IRML rules from both 
   endpoints will therefore help reveal conflicts between the service 
   execution policies of both endpoints. However, it is beyond the 
   scope of IRML to define a method of facilitating the detection of 
   inappropriate service application behavior. Conflict resolution and 
   notification of data providers/consumers is not defined by IRML and 
   is done according to local policy. 
    
   (4) "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." 
    
   It is beyond the scope of IRML to define a method of assisting data 
   consumers and providers in detecting imperfect or compromised OPES 
   intermediaries. However, IRML allows both endpoints to specify the 
   behavior of the intermediary in the case of service execution 
   failures (see section 3.7.4). The default behavior is to abort the 
   data transaction and notify the application endpoint. 
    
   (5) "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." 
    
   IRML does not prevent data consumers from receiving a "non-OPES" 
   version of content if the data provider offers a "non-OPES" version 
   of its content. For example, data providers could offer a "non-OPES" 
   version under a different URI and make sure that their IRML rules do 
   not trigger any OPES services for the "non-OPES" URI. 
    
   (6) "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." 
    
   This document does not define or describe OPES services. 
    
   (7) "Reference validity: All proposed services must define their 
   impact on inter- and intra-document reference validity." 
    
   This document does not define or describe any specific OPES 
   services.  
    
   (8) "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." 
    
   This document does not define or describe any specific OPES 
   services.  
    


     
   Beck, Hofmann        Expires December 2003               [Page 17] 
   Internet Draft                IRML                        June 2003 
    
   (9) "Privacy: The overall OPES framework must provide for mechanisms 
   for end users to determine the privacy policies of OPES 
   intermediaries." 
    
   This part of the OPES framework is not defined by this document. 
     
6  Security Considerations  
        
   Since data providers and data consumers can author IRML rule 
   modules, it will be necessary to securely and reliably transfer rule 
   modules from data providers/consumers to intermediary devices (or to 
   other OPES entities in the same domain and from these entities to 
   intermediary devices).  
    
   Because IRML rule modules can control the execution of services, the 
   receiving intermediary must be able to authenticate the rule module 
   author and verify the integrity of the received rule module.  
    
   IRML therefore REQUIRES that all IRML rule modules be signed by the 
   rule module author using XML signatures as defined in [13]. 
    
   Also, to protect the privacy of data providers and data consumers, 
   application-layer or network-layer encryption SHOULD be applied to 
   connections that are used for the transfer of IRML rule modules.  
    
   As IRML-enabled intermediaries could potentially be the target of 
   security attacks, intermediaries SHOULD be able to reject submitted 
   IRML rule modules if accepting them would compromise their ability 
   to function properly. Intermediaries SHOULD also be able to reject 
   IRML rule modules that are incompatible with their own policies. 
    
    
7  Acknowledgements  
    
   The authors would like to thank all active participants in the OPES 
   mailing list for their thought-provoking discussion, and many of the 
   ideas and suggestions that have been incorporated into this 
   document.  
    
8  References 
    
   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
      9, RFC 2026, October 1996 
   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
      Levels", Request for Comments 2119, Harvard University, March 
      1997 
   3  Barbir, A., et al., "An Architecture For Open Pluggable Edge 
      Services (OPES)", Work in Progress Internet Draft: draft-ietf-
      opes-architecture-04.txt, December 2002. 
 



     
   Beck, Hofmann        Expires December 2003               [Page 18] 
   Internet Draft                IRML                        June 2003 
    
    
   4  Barbir, A., et al., "OPES Use Cases and Deployment Scenarios", 
      Work in Progress Internet Draft: draft-ietf-opes-scenarios-
      01.txt, August 2002 
   5  Bray, T., et al., Extensible Markup Language (XML) 1.0 (Second 
      Edition), http://www.w3.org/TR/2000/REC-xml-20001006, October 
      2000 
   6  Barbir, A., et al., "Policy, Authorization and Enforcement 
      Requirements", Work in Progress, Internet Draft draft-ietf-opes-
      authorization-02.txt, February 2002 
   7  Fielding, R., et al., "Hypertext Transfer Protocol -- HTTP/1.1", 
      Request for Comments 2616, June 1999 
   8  Klyne, G., et al., "Date and Time on the Internet: Timestamps", 
      Work in Progress, Internet Draft "draft-ietf-impp-datetime-
      05.txt", November 2001 
   9  ISO/IEC DIS 9945-2:1992, Information technology - Portable 
      Operating System Interface (POSIX) - Part 2: Shell and Utilities  
      (IEEE Std 1003.2-1992); X/Open CAE Specification, Commands and 
      Utilities, Issue 4, 1992 
   10 Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource    
      Identifiers (URI): Generic Syntax and Semantics", Request for    
      Comments 2396, August 1998 
   11 Moats, R., "URN Syntax", Request for Comments 2141, May 1997 
   12 Floyd, S. et al., "IAB Architectural and Policy Considerations 
      for OPES", RFC 3238, January 2002 
   13 Bartel, M. et al., "XML-Signature Syntax and Processing", W3C 
      Recommendation, February 2002 
    
    
Authors' Addresses  
      
   Andre Beck  
   Markus Hofmann  
   Bell Labs Research 
   Lucent Technologies  
   101 Crawfords Corner Rd.  
   Holmdel, NJ 07733  
   Phone: (732) 332-5983  
   Email: {abeck, hofmann}@bell-labs.com  
    
Appendix A - IRML DTD 
    
   The DTD in this section describes the XML syntax of IRML. Every rule 
   module submitted to an IRML-enabled intermediary or admin server 
   MUST comply with this DTD. Note that compliance with this DTD is not 
   a sufficient condition for correctness of an IRML rule module, as 
   some of the conditions described in this document are not 
   expressible in the DTD syntax. 
    
   <!ELEMENT rulemodule    (author, ruleset+)>  
   <!ELEMENT author        (name, contact?, id)>  
   <!ELEMENT ruleset       (authorized-by, protocol, rule+)>  

     
   Beck, Hofmann        Expires December 2003               [Page 19] 
   Internet Draft                IRML                        June 2003 
    
   <!ELEMENT authorized-by (name, contact?, id)>  
   <!ELEMENT name          (#PCDATA)>  
   <!ELEMENT contact       (#PCDATA)>  
   <!ELEMENT id            (#PCDATA)>  
   <!ELEMENT protocol      (#PCDATA)>  
   <!ELEMENT rule          (property|execute)+>  
   <!ELEMENT property      (property|execute)+>  
   <!ELEMENT execute       (service+)>  
   <!ELEMENT service       (any|uri, parameter*)>  
   <!ELEMENT uri           (#PCDATA)>  
   <!ELEMENT any           EMPTY>  
   <!ELEMENT parameter     (value|variable)>  
   <!ELEMENT value         (#PCDATA)>  
   <!ELEMENT variable      (#PCDATA)>  
    
   <!ATTLIST author        type        (delegate|self)          "self">  
   <!ATTLIST authorized-by class       (data-provider|data-consumer) 
                                                             #REQUIRED>  
   <!ATTLIST authorized-by type        (individual|group) "individual">  
    
   <!ATTLIST rule          processing-point  (1|2|3|4)       #REQUIRED>  
    
   <!ATTLIST property      name        CDATA                 #REQUIRED>  
   <!ATTLIST property      context     (req-msg|res-msg|system|service) 
                                                             #REQUIRED>  
   <!ATTLIST property      sub-system  CDATA                "standard">   
   <!ATTLIST property      matches     CDATA                 #REQUIRED>  
   <!ATTLIST property      not-matches CDATA                 #REQUIRED>  
   <!ATTLIST property      case-sensitive    (yes|no)             "no">  
   <!ATTLIST service       name        CDATA                  #IMPLIED>  
   <!ATTLIST service       type        (primary|alternate)   "primary">  
   <!ATTLIST service       failure     (abort|ignore|try-alternate) 
                                                               "abort">  
   <!ATTLIST parameter     name        CDATA                 #REQUIRED> 
   <!ATTLIST parameter     type        (static|dynamic)      #REQUIRED> 
    
    
Appendix B - IRML Extensions for HTTP 
    
   For HTTP messages, IRML defines the following system variables:  
    
   Property Name        Value  
   --------------------------------------------------------------  
   "request-line"       the first line of an HTTP request 
   "request-method"     the HTTP request method, e.g. GET or POST 
   "request-path"       the rel_path of the request URI as defined 
                        in [7] 
   "request-version"    the HTTP version number as it appears in the 
                        first HTTP request line, e.g. HTTP/1.1 
   "request-host"       the host name/IP address of the origin server 
                        as it appears in the first HTTP request line 
                        or HTTP "Host" request header 

     
   Beck, Hofmann        Expires December 2003               [Page 20] 
   Internet Draft                IRML                        June 2003 
    
   "request-uri"        the absolute request URI as defined in [7] 
   "response-line"      the first line of an HTTP response 
   "response-code"      the HTTP response code as it appears in the 
                        first HTTP response line, e.g. 200 
    
   All intermediaries that accept IRML rule modules with a protocol 
   value of "HTTP" MUST support the above listed HTTP-specific system 
   variables. 
    
    
Appendix C - IRML Sub-Systems 
    
   The following is a list of currently known IRML sub-systems: 
    
   Sub-System Name   Description                      Specification     
   ----------------------------------------------------------------  
    
    
    
Appendix D - Rule Module Examples  
     
   Data provider Rule Module Example  
     
   <?xml version="1.0"?>  
   <rulemodule xmlns="http://www.rfc-editor.org/rfc/rfcxxxx.txt">  
     <author type="self">  
       <name>Lucent Technologies</name>  
       <contact>rule-info@lucent.com</contact> 
       <id>www.lucent.com</id>  
     </author>  
     <ruleset> 
       <authorized-by class="data-provider" type="individual"> 
         <name>Lucent Technologies</name>  
         <contact>rule-info@lucent.com</contact> 
         <id>www.lucent.com</id>  
       </authorized-by>  
       <protocol>HTTP</protocol>  
       <rule processing-point="4">  
         <!-- Is the requested web document our home page? -->  
         <property name="request-path" context="system" 
                 matches="^/$|^/index.html$" case-sensitive="yes">  
           <!-- Does the user send us a specific cookie? -->  
           <property name="Cookie" matches="sew=23">  
             <execute> 
               <service name="Localized Content" failure="ignore">  
                 <uri>opes://local.net/insert-local-content</uri>  
                 <parameter name="clientip" type="dynamic"> 
                   <variable name="client-ip" context="system"/> 
                 </parameter> 
               </service> 
             </execute> 
           </property>  

     
   Beck, Hofmann        Expires December 2003               [Page 21] 
   Internet Draft                IRML                        June 2003 
    
         </property>  
       </rule>  
     </ruleset> 
   </rulemodule>  
   <signature xmlns="http://www.w3.org/2000/09/xmldsig#"> 
     ... 
   </signature> 
    
   Data consumer Rule Module Example  
        
   <?xml version="1.0"?>  
   <rulemodule xmlns="http://www.rfc-editor.org/rfc/rfcxxxx.txt">  
     <author type="self">  
       <name>Andre Beck</name>  
       <contact>abeck@home.com</contact> 
       <id>138.43.43.55</id>  
     </author>  
     <ruleset> 
       <authorized-by class="data-consumer" type="individual"> 
         <name>Lucent Technologies</name>  
         <contact>abeck@home.com</contact> 
         <id>www.lucent.com</id>  
       </authorized-by>  
       <protocol>HTTP</protocol>  
       <rule processing-point="1">  
         <!-- Execute a privacy service that removes the HTTP "Referer" 
              header from all my requests -->  
         <execute> 
           <service name="Privacy Service" failure="ignore">  
             <uri>opes://privacy.net/priv-serv</uri>  
             <parameter name="action" type="static"> 
               <value>remove-referer</value> 
             </parameter> 
           </service> 
         <execute> 
       </rule>  
     </ruleset> 
   </rulemodule>  
   <signature xmlns="http://www.w3.org/2000/09/xmldsig#"> 
     ... 
   </signature> 
    
   Delegate Rule Module Example 
    
   <?xml version="1.0"?>  
   <rulemodule xmlns="http://www.rfc-editor.org/rfc/rfcxxxx.txt">  
     <author type="delegate">  
       <name>Comcast ISP</name>  
       <contact>rule-info@comcast.com</contact> 
       <id>www.comcast.com</id>  
     </author>  
     <ruleset> 

     
   Beck, Hofmann        Expires December 2003               [Page 22] 
   Internet Draft                IRML                        June 2003 
    
       <!-- This set of rules applies to a group of ISP customers -->  
       <authorized-by class="data-consumer" type="group"> 
         <name>Virus Scanning Subscribers</name>  
         <contact>vs-subscribers@comcast.com</contact> 
         <id>www.comcast.com/irml-groups/vs-subscribers</id>  
       </authorized-by>  
       <protocol>HTTP</protocol>  
       <rule processing-point="4">  
         <!-- Can the requested web object contain a virus? -->  
         <property name="Content-Type" context="res-hdr"  
                                                 matches="application/">  
           <execute> 
             <service name="McAfee Virus Scanning Service" 
                                 type="primary" failure="try-alternate"> 
               <uri>opes://mcaffee.com/mscan</uri>  
             </service>  
             <service name="Norton Virus Scanning Service"               
                                                       type="alternate"> 
               <uri>opes://norton.com/nscan</uri>  
             </service>  
           </execute> 
         </property> 
       </rule>  
     </ruleset> 
     <ruleset> 
       <!-- This set of rules applies to a specific data provider --> 
       <authorized-by class="data-provider" type="individual"> 
         <name>CNN</name>  
         <contact>rule-info@cnn.com</contact> 
         <id>www.cnn.com</id>  
       </authorized-by>  
       <protocol>HTTP</protocol>  
       <rule processing-point=4> 
         <property name="request-uri" context="system"  
                                   matches="http://www.cnn.com/file.exe> 
           <!-- CNN wants to allow only the McAffee virus scanning 
                service on this file because there are known issues with  
                Norton's Virus scanning service and particular files.--> 
           <execute> 
             <service name="McAffee Virus Scanning Service"> 
               <uri>opes://mcaffee.com/mscan</uri>  
             </service> 
           </execute>  
         </property> 
       </rule>   
     </ruleset> 
   </rulemodule> 
   <signature xmlns="http://www.w3.org/2000/09/xmldsig#"> 
     ... 
   </signature> 
        
    

     
   Beck, Hofmann        Expires December 2003               [Page 23] 
   Internet Draft                IRML                        June 2003 
    
Appendix E - IRML Change Log 
    
   Changes from draft-beck-opes-irml-02.txt 
    
   - aligned terminology with OPES WG documents 
   - removed references to Web services 
   - removed "may-execute" and "do-not-execute" elements 
   - updated references section 
    
   Changes from draft-beck-opes-irml-01.txt 
    
   - replaced the <action> element with three different rule action 
     elements: <execute> (to request the execution of a service),  
     <do-not-execute> (to disallow the execution of services), and 
     <may-execute> (to permit the execution of services) 
   - introduced "delegate" as rule module author and separation 
     between rule module author and authorizing endpoint 
   - introduced IRML rule sets as a collection of rules authorized by  
     the same endpoint 
   - introduced separation between service identification through URI 
     and service execution parameters 
   - added recommendation to use URNs as service identifiers 
   - introduced support for dynamic parameters (i.e. the ability to  
     pass run-time message, system, and service property values to  
     service applications) 
   - introduced "failure" attribute to allow endpoints to control the  
     intermediary behavior in the case of service execution failures 
   - introduced the concept of executing alternate services in the case 
     of service execution failures 
   - rewrote introduction  
   - added "Rule Pocessing" section 
   - added "IAB Considerations" section to address the recent IAB draft 
     with considerations for OPES 
   - changed mandated order of service execution  
   - rewrote security considerations and introduced the requirement to 
     use XML signatures in all rule modules 
   - fixed syntax of comments in examples, clarified the meaning of the 
     "request-path" system property and the regular expression syntax 
     to be used in rule condition patterns 
     (as suggested by M. Cinquini) 
   - added more HTTP-specific system properties to simplify the rule  
     matching for HTTP messages (as suggested by Lily Yang) 
   - introduced "not-matches" attribute in property element  
     (as suggested by M. Cinquini) 
   - renamed "type" attribute in "property" elements to "context" 
   - added "context" attribute values "req-msg" and "res-msg" to better 
     differentiate between request message and response message 
     properties (as suggested by R. Rahman) 
   - introduced IRML sub-system attribute in "property" elements and    
     appendix with list of known sub-systems (as suggested by C.W. Ng) 
   - moved pre-defined HTTP-specific system properties to HTTP-specific  
     appendix 

     
   Beck, Hofmann        Expires December 2003               [Page 24] 
   Internet Draft                IRML                        June 2003 
    
   - added IRML document identifiers for XML 
   - rewrote all rule module examples to match the new IRML DTD 
   - added this change log  
    
   Changes from draft-beck-opes-irml-00.txt 
    
   - updated references to include the models and policy requirements  
     drafts 
   - removed terminology section and referenced the taxonomy in the  
     models draft instead 
   - revised use of terminology to be conform with models draft  
     terminology 
   - removed access provider from list of rule authors (as suggested by  
     new OPES charter) 
   - late binding in <action> field through OPES URI (as suggested by  
     Lee Rafalow and others) 
   - added "request-host" variable (as suggested by Francis Zane) 
   - added type attribute to property element to accomodate three  
     different types of properties: message, system, and service 
   - added "client-ip" system variable to support services that depend  
     on the client IP, e.g. URL rewriting in a CDN scenario  
   - added support for arbitrary service state variables which also  
     allows rule matching against members of dynamic groups (as  
     suggested by Lee Rafalow and others) 
   - new date format in <system-date> system property (as suggested by  
     Ian Cooper) 
   - removed DEFAULT keyword in IRML DTD (as suggested by Ting) 
    
Full Copyright Statement  
    
    
   Copyright (C) The Internet Society (2000). 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 assigns.  
    
   This document and the information contained herein is provided on an 
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 

     
   Beck, Hofmann        Expires December 2003               [Page 25] 
   Internet Draft                IRML                        June 2003 
    
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.  
    
     















































     
   Beck, Hofmann        Expires December 2003               [Page 26] 

--------------050306090407040500030000--




From owner-ietf-openproxy@mail.imc.org  Tue Jun 24 22:32: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 WAA03527
	for <opes-archive@ietf.org>; Tue, 24 Jun 2003 22:32:04 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19V04q-0001YT-00
	for opes-archive@ietf.org; Tue, 24 Jun 2003 22:32:04 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19V04a-0001YO-00
	for opes-archive@ietf.org; Tue, 24 Jun 2003 22:31:48 -0400
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h5P2HYrb002652
	for <ietf-openproxy-bks@above.proper.com>; Tue, 24 Jun 2003 19:17: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 h5P2HY1M002651
	for ietf-openproxy-bks; Tue, 24 Jun 2003 19:17:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f
Received: from smtp-out.comcast.net (smtp-out.comcast.net [24.153.64.113])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h5P2HWrb002638
	for <ietf-openproxy@imc.org>; Tue, 24 Jun 2003 19:17:33 -0700 (PDT)
	(envelope-from markus@mhof.com)
Received: from mhof.com ([135.104.20.78])
 by mtaout03.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May
 14 2003)) with ESMTPA id <0HH0001SCM8ZYB@mtaout03.icomcast.net> for
 ietf-openproxy@imc.org; Tue, 24 Jun 2003 22:16:29 -0400 (EDT)
Date: Tue, 24 Jun 2003 22:15:01 -0400
From: Markus Hofmann <markus@mhof.com>
Subject: Re: draft-beck-opes-irml-03.txt
In-reply-to: <3EF8CADD.2060201@bell-labs.com>
To: ietf-openproxy@imc.org
Message-id: <3EF905A5.9000100@mhof.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4)
 Gecko/20030612
References: <3EF8CADD.2060201@bell-labs.com>
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7BIT


Folks,

> We revived and re-submitted the attached IRML draft in an attempt to 
> trigger some discussion on how to specify service execution rules in OPES.

While we're making good progress with the protocol, we're behind with 
the rules language. We really need to get going here.

As Andre indicates, re-submission of the individual draft is intended 
to trigger some discussions. Please check it out and provide comments 
on the list - either to the draft itself or to the area in general.

-Markus



From owner-ietf-openproxy@mail.imc.org  Fri Jun 27 11:47: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 LAA04856
	for <opes-archive@ietf.org>; Fri, 27 Jun 2003 11:47:21 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19VvRb-000403-00
	for opes-archive@ietf.org; Fri, 27 Jun 2003 11:47:23 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19VvRL-0003z9-00
	for opes-archive@ietf.org; Fri, 27 Jun 2003 11:47:07 -0400
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h5RFYkrb049245
	for <ietf-openproxy-bks@above.proper.com>; Fri, 27 Jun 2003 08:34: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 h5RFYkva049244
	for ietf-openproxy-bks; Fri, 27 Jun 2003 08:34:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f
Received: from wwsmtp.webwasher.com ([217.146.159.49])
	by above.proper.com (8.12.9/8.12.8) with SMTP id h5RFYgrb049227
	for <ietf-openproxy@imc.org>; Fri, 27 Jun 2003 08:34:45 -0700 (PDT)
	(envelope-from martin.stecher@WEBWASHER.com)
Received: from mail.WEBWASHER.COM [192.168.0.251] id 9UI71KCF; 27 Jun 2003 17:34:17 +0200
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Subject: First HTTP/OCP example available
Date: Fri, 27 Jun 2003 17:34:13 +0200
Message-ID: <75F7E67FC45F6744A7D328D41E35376D054F4A@mail.webwasher.com>
Thread-Topic: First HTTP/OCP example available
Thread-Index: AcM8wY/g5JBm8f3HTJWVwuAHPJzVAA==
From: "Martin Stecher" <martin.stecher@webwasher.com>
To: "OPES WG (E-mail)" <ietf-openproxy@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h5RFYjrb049240
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 8bit


Hi,

Alex and I worked on a possible start for the HTTP application binding of OCP.

In preparation to some first coding, I created a message flow example.
It shows how an ad-stripping callout server alters a HTML file that has been sent within a HTTP response by the OPES proceesor.
The example can be found here: http://www.martin-stecher.de/opes/sample1.html

There are a few changes in the OCP Core draft and some first paragraphs for the HTTP/OCP draft. Alex will send more information about this later today.

Other examples will probably follow. Some more adjustments may be needed while the protocol develops.

Regards
Martin



From owner-ietf-openproxy@mail.imc.org  Fri Jun 27 13:33: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 NAA08180
	for <opes-archive@ietf.org>; Fri, 27 Jun 2003 13:33:03 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Vx5r-0004qO-00
	for opes-archive@ietf.org; Fri, 27 Jun 2003 13:33:03 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Vx5b-0004qJ-00
	for opes-archive@ietf.org; Fri, 27 Jun 2003 13:32: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 h5RHL8rb052831
	for <ietf-openproxy-bks@above.proper.com>; Fri, 27 Jun 2003 10:21: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 h5RHL8jD052830
	for ietf-openproxy-bks; Fri, 27 Jun 2003 10:21: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 h5RHL7rb052822
	for <ietf-openproxy@imc.org>; Fri, 27 Jun 2003 10:21: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 h5RHL8Ds082793;
	Fri, 27 Jun 2003 11:21:08 -0600 (MDT)
	(envelope-from rousskov@measurement-factory.com)
Received: (from rousskov@localhost)
	by measurement-factory.com (8.12.9/8.12.5/Submit) id h5RHL8x6082792;
	Fri, 27 Jun 2003 11:21:08 -0600 (MDT)
	(envelope-from rousskov)
Date: Fri, 27 Jun 2003 11:21:08 -0600 (MDT)
From: Alex Rousskov <rousskov@measurement-factory.com>
To: OPES WG <ietf-openproxy@imc.org>
Subject: Re: draft-beck-opes-irml-03.txt
In-Reply-To: <3EF905A5.9000100@mhof.com>
Message-ID: <Pine.BSF.4.53.0306270955110.79070@measurement-factory.com>
References: <3EF8CADD.2060201@bell-labs.com> <3EF905A5.9000100@mhof.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>



On Tue, 24 Jun 2003, Markus Hofmann wrote:

> > We revived and re-submitted the attached IRML draft in an attempt
> > to trigger some discussion on how to specify service execution
> > rules in OPES.
>
> While we're making good progress with the protocol, we're behind
> with the rules language. We really need to get going here.
>
> As Andre indicates, re-submission of the individual draft is
> intended to trigger some discussions. Please check it out and
> provide comments on the list - either to the draft itself or to the
> area in general.

I may have few friends left after this message, but I hope that these
comments would do at least some good as well.

My first reaction to the draft is negative. I hope that I missed
something important and that my opinion can be reversed by the
discussion. Below are first high-level comments; no reason to go into
line-by-line specifics if I am wrong about the overall draft
structure/direction.

0) IRLM draft provides insufficient set of general mechanisms for rule
   specification yet also documents many HTTP-specific extensions or
   bindings. This must be fixed. The draft should either define core
   mechanisms and strive to be application agnostic or be
   HTTP-specific. In either case, major additions and changes would be
   required: more general mechanisms are needed and more/different
   HTTP-specific bindings are required. In other words, I am not just
   talking about splitting the draft in two.

1) IRLM is closely tied to a very narrow interpretation of the OPES
   architecture. The language should focus on a more general (yet
   well-scoped) task of expressing a message adaptation rule:

	if "condition" then do "action";

   The "condition" expression should be powerful enough to express a
   mixture of processing points, processor state, application message
   properties, and extensions. The draft artificially segregates, for
   example, processing points, from message properties, severely
   limiting expression power.

   [Side note: Fortunately for us, the "action" part is rather
    simple -- execute service(s)]

2) IRML attempts to enforce rules authorship. IMO, the Rule
   Specification language must focus on specifying the rules, not
   trying to specify or enforce who has the right to submit or execute
   them. For example, imagine C or Java languages with constructs to
   specify/enforce software copyright. I believe that rights
   specification and enforcement requires different mechanisms from
   rules specification. Moreover, both mechanisms lack key features in
   the current draft.

3) I doubt that efficient rule processing would be possible with IRML.
   The language provides no mechanisms to reuse groups of rules (e.g.,
   procedures or functions) or to reuse computation results (i.e.,
   variables). Without such mechanisms, a realistic IRML program will
   be slow. It will also be huge and difficult to manage.

4) I question the choice of XML syntax. Rule specification is much
   closer to a program than it is to a static tree of configuration
   options. I believe that the history of languages used to express
   application routing, load balancing, and filtering decisions at
   intermediaries proves my point: while the industry has started with
   simple maps and tables, the application-level requirements forced
   implementors to support much more flexible rule programming. The
   choice of XML as IRLM syntax makes it very awkward to express
   anything that goes beyond a simple rule. IMO, XML must not be used
   as a programming language syntax.

   XML justification in the draft is "many publicly available parsers
   and editing tools can be used". This is a very weak argument
   because (a) getting XML tree parsed is only a minor step towards
   interpreting IRML and (b) there are more XML-unaware editing tools
   than XML-aware editing tools. The authors claim that "The structure
   of the language maps closely to its behavior" which I believe is
   true only for the authorship part of the language and only
   partially true for the actual rule specification language.
   Moreover, the behavior that XML maps to is the wrong one! See items
   (1) and (3) above. The last argument (ease of IRML validation) is
   also weak because (a) any applicable language syntax would
   relatively easy to validate and (b) syntax validation does little
   good since most errors are of semantic nature, unrelated to DTD
   validity.


If my observations above I correct, I would be surprised to see IRML
supported in practice. It can offer major users a lot less than custom
solutions (future or existing). Again, I would like to be proven wrong
because there is clearly a lot of effort put into the draft, and I am
late with my comments.

HTH,

Alex.


From owner-ietf-openproxy@mail.imc.org  Fri Jun 27 16:48: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 QAA20136
	for <opes-archive@ietf.org>; Fri, 27 Jun 2003 16:48:53 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19W09O-0006IK-00
	for opes-archive@ietf.org; Fri, 27 Jun 2003 16:48:54 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19W098-0006Hq-00
	for opes-archive@ietf.org; Fri, 27 Jun 2003 16:48:38 -0400
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h5RKZYrb062328
	for <ietf-openproxy-bks@above.proper.com>; Fri, 27 Jun 2003 13:35: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 h5RKZYpu062327
	for ietf-openproxy-bks; Fri, 27 Jun 2003 13:35:34 -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 h5RKZWrb062322
	for <ietf-openproxy@imc.org>; Fri, 27 Jun 2003 13:35: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 h5RKZYDs089545
	for <ietf-openproxy@imc.org>; Fri, 27 Jun 2003 14:35:34 -0600 (MDT)
	(envelope-from rousskov@measurement-factory.com)
Received: (from rousskov@localhost)
	by measurement-factory.com (8.12.9/8.12.5/Submit) id h5RKZYSF089544;
	Fri, 27 Jun 2003 14:35:34 -0600 (MDT)
	(envelope-from rousskov)
Date: Fri, 27 Jun 2003 14:35:34 -0600 (MDT)
From: Alex Rousskov <rousskov@measurement-factory.com>
To: OPES WG <ietf-openproxy@imc.org>
Subject: OCP Core version head_sid12 available
Message-ID: <Pine.BSF.4.53.0306271430500.79070@measurement-factory.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>



The log of major changes is quoted below. The latest snapshot is at

	http://www.measurement-factory.com/tmp/opes/

Please continue to comment and work on the to-do list. My personal
goal is to finish the bulk of data preservation/copying documentation
by the next release.

Thank you,

Alex.

-------------- change log ----------------

Appendix B. Change Log

 head-sid12

  *  Fixed BNF to remove extra SP and "," in front of structure and
     list values.

  *  Fixed the type of "id" field in a "service" structure.

  *  Documented "sg-id" parameter.

  *  Renamed "copied" to "data-id" so that it can be used by both
     agents. An OPES processor uses named "Copied: data-id"
     parameter and a callout server uses anonymous "data-id"
     parameter (instead of previously documented "copy-am-offset").

  *  Removed "rid" parameter from Negotiation Offer (NO) message as
     unused.

  *  Removed "size" parameter from messages with payload since
     payload syntax includes an explicit size value.

  *  Renamed Data Have (DH) message to Data Use Mine (DUM) message
     to preserve the symmetry with Data Use Yours (DUY) message and
     to prepare for possible addition of Data Check Mine (DCM)
     message.

  *  Finished phasing out the "modified" message parameter.

  *  Added an "As-is" named-parameter to mark adapted pieces of data
     identical to the original.

  *  Replaced a huge "message nesting" figure with a set of short
     specific rules illustrating the same concept. Added a new
     "Exchange Patterns" subsection to accommodate the rules and
     related matters. The figure was not clear enough. Hopefully,
     the rules are.



From owner-ietf-openproxy@mail.imc.org  Fri Jun 27 16:54: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 QAA20328
	for <opes-archive@ietf.org>; Fri, 27 Jun 2003 16:54:38 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19W0Ex-0006Kl-00
	for opes-archive@ietf.org; Fri, 27 Jun 2003 16:54:39 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19W0Eh-0006Kd-00
	for opes-archive@ietf.org; Fri, 27 Jun 2003 16:54: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 h5RKhFrb062679
	for <ietf-openproxy-bks@above.proper.com>; Fri, 27 Jun 2003 13:43: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 h5RKhF44062678
	for ietf-openproxy-bks; Fri, 27 Jun 2003 13:43:15 -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 h5RKhErb062673
	for <ietf-openproxy@imc.org>; Fri, 27 Jun 2003 13:43:14 -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 h5RKhFDs089994
	for <ietf-openproxy@imc.org>; Fri, 27 Jun 2003 14:43:15 -0600 (MDT)
	(envelope-from rousskov@measurement-factory.com)
Received: (from rousskov@localhost)
	by measurement-factory.com (8.12.9/8.12.5/Submit) id h5RKhF4Y089993;
	Fri, 27 Jun 2003 14:43:15 -0600 (MDT)
	(envelope-from rousskov)
Date: Fri, 27 Jun 2003 14:43:15 -0600 (MDT)
From: Alex Rousskov <rousskov@measurement-factory.com>
To: OPES WG <ietf-openproxy@imc.org>
Subject: HTTP adaptation draft version head_sid12 available
Message-ID: <Pine.BSF.4.53.0306271435460.79070@measurement-factory.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>



The "HTTP adaptation with OPES" draft will document all HTTP-specific
things related to OPES core modules: tracing, bypass, and OCP.  The
latest snapshot is at

	http://www.measurement-factory.com/tmp/opes/

This draft has not been promoted to the WG status.
Please contribute.

Thank you,

Alex.

P.S. Martin Stecher and I have started working on the first
     proof-of-concept implementation of HTTP profile for OCP.
     I am responsible for the client (processor) side while
     Martin is working on the server.


From owner-ietf-openproxy@mail.imc.org  Mon Jun 30 11:54: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 LAA02352
	for <opes-archive@ietf.org>; Mon, 30 Jun 2003 11:54:13 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19X0dX-0001se-00
	for opes-archive@ietf.org; Mon, 30 Jun 2003 11:32:11 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19X0d4-0001sD-00
	for opes-archive@ietf.org; Mon, 30 Jun 2003 11:31: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 h5UFIkFK067762
	for <ietf-openproxy-bks@above.proper.com>; Mon, 30 Jun 2003 08:18: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 h5UFIkGB067761
	for ietf-openproxy-bks; Mon, 30 Jun 2003 08:18:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f
Received: from wwsmtp.webwasher.com ([217.146.159.49])
	by above.proper.com (8.12.9/8.12.8) with SMTP id h5UFIhFK067754
	for <ietf-openproxy@imc.org>; Mon, 30 Jun 2003 08:18:44 -0700 (PDT)
	(envelope-from martin.stecher@WEBWASHER.com)
Received: from mail.WEBWASHER.COM [192.168.0.251] id 64I8RVXG; 30 Jun 2003 17:18:42 +0200
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Subject: CE message
Date: Mon, 30 Jun 2003 17:18:38 +0200
Message-ID: <75F7E67FC45F6744A7D328D41E35376D054F68@mail.webwasher.com>
Thread-Topic: CE message
Thread-Index: AcM+7mI3u33sfrCXQ/eurc0lSkf4tQ==
From: "Martin Stecher" <martin.stecher@webwasher.com>
To: "OPES WG (E-mail)" <ietf-openproxy@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h5UFIjFK067756
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 8bit


Hi,

while implementing the OCP server prototype, I got two questions regarding the CE message:

0a. While TE has a result parameter, CE has not.
    Both have an optional error parameter.
    I know we had this discussion on the list but cannot really remember.
    Section 8.13: "error ... that cannot be expressed via result"
    What kind of error could that be?

0b. The syntax of "result" should be a struct  { uni [string] }.
    

Depending on 0a:
1. How about adding an optional, anonymous result parameter to CE?
   I use status codes and error strings for various errors that
   sometimes close a connection sometimes just the transaction.
   It's handy to keep both similar.

2. The CE messages implies closing of all open transactions.
   I would like to restrict this to happen only for the error case.
   Only if the processor wants to close the connection but does not
   expect to get any response for open transactions.
   If a transaction should close without error, a TE message must be sent.
   I am still fine that TE implies AME.
   Reasons:
      - In real environments one connection will handle many transactions.
      - No real benefit to skip the very last TE message(s). That would safe
        only a few messages out of hundreds.
      - If CE implies TE and TE implies AME and a connection has many concurrent
        transactions, a callout server needs to do a lot of cleanup if a
        connection closes:
          i) check error of CE whether a graceful close seems to be wanted
          ii) iterate over all open transactions
          iii) assume that all application messages are now done, force to
               finish all filtering and return data for all transactions.
          iv) when this is done for all transactions send CE and close.
        It will be easier if this procedure runs only per transaction.
    Are you o.k. with changing this?


Regards
Martin




From owner-ietf-openproxy@mail.imc.org  Mon Jun 30 12:23: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 MAA04122
	for <opes-archive@ietf.org>; Mon, 30 Jun 2003 12:23:32 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19X1RF-0002Mq-00
	for opes-archive@ietf.org; Mon, 30 Jun 2003 12:23:33 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19X1Qo-0002Mc-00
	for opes-archive@ietf.org; Mon, 30 Jun 2003 12:23:07 -0400
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UGCZFK069444
	for <ietf-openproxy-bks@above.proper.com>; Mon, 30 Jun 2003 09:12: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 h5UGCZjH069443
	for ietf-openproxy-bks; Mon, 30 Jun 2003 09:12:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f
Received: from wwsmtp.webwasher.com ([217.146.159.49])
	by above.proper.com (8.12.9/8.12.8) with SMTP id h5UGCXFK069434
	for <ietf-openproxy@imc.org>; Mon, 30 Jun 2003 09:12:33 -0700 (PDT)
	(envelope-from martin.stecher@WEBWASHER.com)
Received: from mail.WEBWASHER.COM [192.168.0.251] id 6GSISHQV; 30 Jun 2003 18:12:33 +0200
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Subject: OCP support for Ethereal
Date: Mon, 30 Jun 2003 18:12:29 +0200
Message-ID: <75F7E67FC45F6744A7D328D41E35376D054F6A@mail.webwasher.com>
Thread-Topic: OCP support for Ethereal
Thread-Index: AcM/ImdFeFv/BLoaRR+0oPTEZi89Zw==
From: "Martin Stecher" <martin.stecher@WEBWASHER.com>
To: "OPES WG (E-mail)" <ietf-openproxy@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h5UGCYFK069439
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 8bit


Hi,

it would be nice, if Ethereal supports OCP. Should make debugging of prototypes easier.

I had a look at the source code and found the file that handles ICAP as an example.
Seems that some Ethereal programming experience is very helpful to add a new protocol ;-)

Is there someone on this list with that experience, volunteering for adding OCP support to Ethereal?

Thank you very much in advance.

Regards
Martin



From owner-ietf-openproxy@mail.imc.org  Mon Jun 30 12:26: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 MAA04299
	for <opes-archive@ietf.org>; Mon, 30 Jun 2003 12:26:09 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19X1Tm-0002OW-00
	for opes-archive@ietf.org; Mon, 30 Jun 2003 12:26:10 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19X1TW-0002OG-00
	for opes-archive@ietf.org; Mon, 30 Jun 2003 12:25:54 -0400
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UGFpFK069556
	for <ietf-openproxy-bks@above.proper.com>; Mon, 30 Jun 2003 09:15:51 -0700 (PDT)
	(envelope-from owner-ietf-openproxy@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h5UGFo2C069555
	for ietf-openproxy-bks; Mon, 30 Jun 2003 09:15:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f
Received: from measurement-factory.com (measurement-factory.com [206.168.0.5])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UGFmFK069550
	for <ietf-openproxy@imc.org>; Mon, 30 Jun 2003 09:15: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 h5UGFmDs093090;
	Mon, 30 Jun 2003 10:15:48 -0600 (MDT)
	(envelope-from rousskov@measurement-factory.com)
Received: (from rousskov@localhost)
	by measurement-factory.com (8.12.9/8.12.5/Submit) id h5UGFmJA093089;
	Mon, 30 Jun 2003 10:15:48 -0600 (MDT)
	(envelope-from rousskov)
Date: Mon, 30 Jun 2003 10:15:48 -0600 (MDT)
From: Alex Rousskov <rousskov@measurement-factory.com>
To: "OPES WG (E-mail)" <ietf-openproxy@imc.org>
Subject: Re: CE message
In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D054F68@mail.webwasher.com>
Message-ID: <Pine.BSF.4.53.0306301012170.90894@measurement-factory.com>
References: <75F7E67FC45F6744A7D328D41E35376D054F68@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: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


On Mon, 30 Jun 2003, Martin Stecher wrote:

> while implementing the OCP server prototype, I got two questions
> regarding the CE message:
>
> 0a. While TE has a result parameter, CE has not.
>     Both have an optional error parameter.
>     I know we had this discussion on the list but cannot really remember.
>     Section 8.13: "error ... that cannot be expressed via result"
>     What kind of error could that be?

I cannot think of a good example. An explicit error flag was added
because Oskar Batuner suggested that abnormal termination must be
distinguished from a normal (but possibly also erroneous) termination.
Oskar suggested a dedicated "xaction-abort" message or similar.
Somebody pointed out that the same semantics can be expressed via
special bit in a result code, but we may want to be explicit and have
an "error" flag.

We should make a decision how to express the "abnormal termination"
semantics.

> 0b. The syntax of "result" should be a struct { uni [string] }.

Yes, will document.

> Depending on 0a:
> 1. How about adding an optional, anonymous result parameter to CE?
>    I use status codes and error strings for various errors that
>    sometimes close a connection sometimes just the transaction.
>    It's handy to keep both similar.

I agree. All *End messages should be similar. Will add.

> 2. The CE messages implies closing of all open transactions.
>    I would like to restrict this to happen only for the error case.
>    Only if the processor wants to close the connection but does not
>    expect to get any response for open transactions.
>    If a transaction should close without error, a TE message must be sent.
>    I am still fine that TE implies AME.

This should be already the case, essentially. Perhaps we need to
polish documentation. AME means "I am done sending my data". AME does
not imply disinterest in the other side data. TE means "I am no longer
interested in this transaction". TE implies disinterest in other side
data for the same transaction. TE does not imply disinterest in other
transactions on the same connection. CE means "I am not longer
interested in anything on this connection and am going to close it".
CE does not imply disinterest in other connections.

Does this semantics meet your needs?

Thanks,

Alex.

-- 
                            | HTTP performance - Web Polygraph benchmark
www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
                            | all of the above - PolyBox appliance


From owner-ietf-openproxy@mail.imc.org  Mon Jun 30 14:54: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 OAA10699
	for <opes-archive@ietf.org>; Mon, 30 Jun 2003 14:54:12 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19X3n2-0003WV-00
	for opes-archive@ietf.org; Mon, 30 Jun 2003 14:54:12 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19X3mm-0003WO-00
	for opes-archive@ietf.org; Mon, 30 Jun 2003 14:53: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 h5UIgbFK074140
	for <ietf-openproxy-bks@above.proper.com>; Mon, 30 Jun 2003 11:42:37 -0700 (PDT)
	(envelope-from owner-ietf-openproxy@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h5UIgaFl074139
	for ietf-openproxy-bks; Mon, 30 Jun 2003 11:42:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f
Received: from wwsmtp.webwasher.com ([217.146.159.49])
	by above.proper.com (8.12.9/8.12.8) with SMTP id h5UIgYFK074133
	for <ietf-openproxy@imc.org>; Mon, 30 Jun 2003 11:42:35 -0700 (PDT)
	(envelope-from martin.stecher@WEBWASHER.com)
Received: from mail.WEBWASHER.COM [192.168.0.251] id ZOUP2IZA; 30 Jun 2003 20:42:34 +0200
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Subject: RE: CE message
Date: Mon, 30 Jun 2003 20:42:30 +0200
Message-ID: <75F7E67FC45F6744A7D328D41E35376D013F66@mail.webwasher.com>
Thread-Topic: CE message
Thread-Index: AcM/IuH6fF2BooLZSqCHnuW94S6HvgADedbw
From: "Martin Stecher" <martin.stecher@webwasher.com>
To: "OPES WG (E-mail)" <ietf-openproxy@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h5UIgaFK074135
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 8bit


> 
> > while implementing the OCP server prototype, I got two questions
> > regarding the CE message:
> >
> > 0a. While TE has a result parameter, CE has not.
> >     Both have an optional error parameter.
> >     I know we had this discussion on the list but cannot 
> really remember.
> >     Section 8.13: "error ... that cannot be expressed via result"
> >     What kind of error could that be?
> 
> I cannot think of a good example. An explicit error flag was added
> because Oskar Batuner suggested that abnormal termination must be
> distinguished from a normal (but possibly also erroneous) termination.
> Oskar suggested a dedicated "xaction-abort" message or similar.
> Somebody pointed out that the same semantics can be expressed via
> special bit in a result code, but we may want to be explicit and have
> an "error" flag.
> 
> We should make a decision how to express the "abnormal termination"
> semantics.
> 

For me defining a result code value as status or error would work good enough.
Such as in HTTP and many other protocols. 2xx success, 4xx and 5xx errors.

> 
> > 2. The CE messages implies closing of all open transactions.
> >    I would like to restrict this to happen only for the error case.
> >    Only if the processor wants to close the connection but does not
> >    expect to get any response for open transactions.
> >    If a transaction should close without error, a TE 
> message must be sent.
> >    I am still fine that TE implies AME.
> 
> This should be already the case, essentially. Perhaps we need to
> polish documentation. AME means "I am done sending my data". AME does
> not imply disinterest in the other side data. TE means "I am no longer
> interested in this transaction". TE implies disinterest in other side
> data for the same transaction. TE does not imply disinterest in other
> transactions on the same connection. CE means "I am not longer
> interested in anything on this connection and am going to close it".
> CE does not imply disinterest in other connections.
> 
> Does this semantics meet your needs?
> 

Did you change your mind or is there a misunderstanding?
In another mail your wrote that the AME messages in my example http://www.martin-stecher.de/opes/sample1.html are obsolete.
But if the OPES processor sends TE before it receives all data from the callout servr, it signals disinterest which is wrong. The callout server often needs a signal to know that no DUM messages will show up in this transaction and to return the last chunk of data.

Regards
Martin



From owner-ietf-openproxy@mail.imc.org  Mon Jun 30 15:10: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 PAA12114
	for <opes-archive@ietf.org>; Mon, 30 Jun 2003 15:10:01 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19X42K-0003hT-00
	for opes-archive@ietf.org; Mon, 30 Jun 2003 15:10:00 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19X424-0003hK-00
	for opes-archive@ietf.org; Mon, 30 Jun 2003 15:09:45 -0400
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UIx8FK074667
	for <ietf-openproxy-bks@above.proper.com>; Mon, 30 Jun 2003 11:59: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 h5UIx8WT074666
	for ietf-openproxy-bks; Mon, 30 Jun 2003 11:59:08 -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 h5UIx7FK074661
	for <ietf-openproxy@imc.org>; Mon, 30 Jun 2003 11:59:07 -0700 (PDT)
	(envelope-from abeck@bell-labs.com)
Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9])
	by crufty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h5UIx69Y063985;
	Mon, 30 Jun 2003 14:59:07 -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 h5UIx04e069113;
	Mon, 30 Jun 2003 14:59:00 -0400 (EDT)
Received: from bell-labs.com (abeck-hopc [135.180.240.202])
	by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h5UIwxQ4018656;
	Mon, 30 Jun 2003 14:58:59 -0400 (EDT)
Message-ID: <3F0087EF.6020805@bell-labs.com>
Date: Mon, 30 Jun 2003 14:56:47 -0400
From: Andre Beck <abeck@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Alex Rousskov <rousskov@measurement-factory.com>
CC: OPES WG <ietf-openproxy@imc.org>
Subject: Re: draft-beck-opes-irml-03.txt
References: <3EF8CADD.2060201@bell-labs.com> <3EF905A5.9000100@mhof.com> <Pine.BSF.4.53.0306270955110.79070@measurement-factory.com>
In-Reply-To: <Pine.BSF.4.53.0306270955110.79070@measurement-factory.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: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit


Alex Rousskov wrote:
> I may have few friends left after this message, but I hope that these
> comments would do at least some good as well.

Don't worry, Alex. We appreciate any and all (constructive) comments...

> 0) IRLM draft provides insufficient set of general mechanisms for rule
>    specification yet also documents many HTTP-specific extensions or
>    bindings. This must be fixed. The draft should either define core
>    mechanisms and strive to be application agnostic or be
>    HTTP-specific. In either case, major additions and changes would be
>    required: more general mechanisms are needed and more/different
>    HTTP-specific bindings are required. In other words, I am not just
>    talking about splitting the draft in two.

I absolutely agree that the goal should be to have a protocol-agnostic
rule matching core and protocol-specific extensions. Earlier versions of
IRML were HTTP-specific and since then we have tried to separate the
HTTP-specific parts from the generic parts, but, as you pointed out,
more work needs to be done to complete this process.

> 1) IRLM is closely tied to a very narrow interpretation of the OPES
>    architecture. The language should focus on a more general (yet
>    well-scoped) task of expressing a message adaptation rule:
>
> 	if "condition" then do "action";
>
>    The "condition" expression should be powerful enough to express a
>    mixture of processing points, processor state, application message
>    properties, and extensions. The draft artificially segregates, for
>    example, processing points, from message properties, severely
>    limiting expression power.

The "property" element can already refer to application message
properties (i.e. protocol header values), environment/system variables,
and sub-system properties. I don't consider the processing point a rule
condition. Rather, I believe it's a rule attribute as it specifies when
a rule is to be processed. As such, I don't see how the current IRML
design limits expression power. Can you think of a specific example that
shows where IRML lacks expression power?

> 2) IRML attempts to enforce rules authorship. IMO, the Rule
>    Specification language must focus on specifying the rules, not
>    trying to specify or enforce who has the right to submit or execute
>    them. For example, imagine C or Java languages with constructs to
>    specify/enforce software copyright. I believe that rights
>    specification and enforcement requires different mechanisms from
>    rules specification. Moreover, both mechanisms lack key features in
>    the current draft.

I am not sure IRML attempts to enforce rule authorship/authorization. It
does allow rule authors to specify rule authorship/authorization, but
how this is enforced is up to the OPES processor or whatever OPES
element receives IRML rules. Generally, I agree with your statement, 
though.

> 3) I doubt that efficient rule processing would be possible with IRML.
>    The language provides no mechanisms to reuse groups of rules (e.g.,
>    procedures or functions) or to reuse computation results (i.e.,
>    variables). Without such mechanisms, a realistic IRML program will
>    be slow. It will also be huge and difficult to manage.

Well, we never envisioned that an OPES processor would actually process
IRML rule files on the fly as it receives user requests/responses.
Instead, we figured that there would be a separate offline process that
receives IRML rule files from external sources, validates them and
subsequently translates them into some internal, proprietary format
optimized for efficient rule processing.

> 4) I question the choice of XML syntax. Rule specification is much
>    closer to a program than it is to a static tree of configuration
>    options. I believe that the history of languages used to express
>    application routing, load balancing, and filtering decisions at
>    intermediaries proves my point: while the industry has started with
>    simple maps and tables, the application-level requirements forced
>    implementors to support much more flexible rule programming. The
>    choice of XML as IRLM syntax makes it very awkward to express
>    anything that goes beyond a simple rule. IMO, XML must not be used
>    as a programming language syntax.

I don't think it's realistic to expect that OPES processors would be
able to process whatever you can express with a full-fledged programming
language just to determine which requests/responses need further OPES
processing. This would probably impose an unacceptable performance
penalty on those transactions that don't need further processing. Also,
I doubt that a service provider would let external rule authors specify
complex rule logic that could use up any amount of processing power,
e.g. through loops etc. For these reasons we decided to keep IRML rules
very simple and XML seems to be a very suitable format to do just that.

>    XML justification in the draft is "many publicly available parsers
>    and editing tools can be used". This is a very weak argument
>    because (a) getting XML tree parsed is only a minor step towards
>    interpreting IRML and

True, but would this second step by any easier if we used a different
format?

> (b) there are more XML-unaware editing tools
>    than XML-aware editing tools.

True, but then again non-XML formats would have the same problem, right?

Thanks,
Andre








From owner-ietf-openproxy@mail.imc.org  Mon Jun 30 15:32: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 PAA13399
	for <opes-archive@ietf.org>; Mon, 30 Jun 2003 15:32:25 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19X4O1-0003ol-00
	for opes-archive@ietf.org; Mon, 30 Jun 2003 15:32:25 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19X4Nl-0003od-00
	for opes-archive@ietf.org; Mon, 30 Jun 2003 15:32: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 h5UJLPFK075531
	for <ietf-openproxy-bks@above.proper.com>; Mon, 30 Jun 2003 12:21: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 h5UJLPAO075530
	for ietf-openproxy-bks; Mon, 30 Jun 2003 12:21: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 h5UJLOFK075525
	for <ietf-openproxy@imc.org>; Mon, 30 Jun 2003 12:21: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 h5UJLQDs098636;
	Mon, 30 Jun 2003 13:21:26 -0600 (MDT)
	(envelope-from rousskov@measurement-factory.com)
Received: (from rousskov@localhost)
	by measurement-factory.com (8.12.9/8.12.5/Submit) id h5UJLPHV098635;
	Mon, 30 Jun 2003 13:21:25 -0600 (MDT)
	(envelope-from rousskov)
Date: Mon, 30 Jun 2003 13:21:25 -0600 (MDT)
From: Alex Rousskov <rousskov@measurement-factory.com>
To: "OPES WG (E-mail)" <ietf-openproxy@imc.org>
Subject: RE: CE message
In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D013F66@mail.webwasher.com>
Message-ID: <Pine.BSF.4.53.0306301315140.90894@measurement-factory.com>
References: <75F7E67FC45F6744A7D328D41E35376D013F66@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: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>



On Mon, 30 Jun 2003, Martin Stecher wrote:

> > > 2. The CE messages implies closing of all open transactions.
> > >    I would like to restrict this to happen only for the error
> > >    case. Only if the processor wants to close the connection but
> > >    does not expect to get any response for open transactions. If
> > >    a transaction should close without error, a TE message must
> > >    be sent. I am still fine that TE implies AME.
> >
> > This should be already the case, essentially. Perhaps we need to
> > polish documentation. AME means "I am done sending my data". AME
> > does not imply disinterest in the other side data. TE means "I am
> > no longer interested in this transaction". TE implies disinterest
> > in other side data for the same transaction. TE does not imply
> > disinterest in other transactions on the same connection. CE means
> > "I am not longer interested in anything on this connection and am
> > going to close it". CE does not imply disinterest in other
> > connections.
> >
> > Does this semantics meet your needs?
> >
>
> Did you change your mind or is there a misunderstanding? In another
> mail your wrote that the AME messages in my example
> http://www.martin-stecher.de/opes/sample1.html are obsolete. But if
> the OPES processor sends TE before it receives all data from the
> callout servr, it signals disinterest which is wrong. The callout
> server often needs a signal to know that no DUM messages will show
> up in this transaction and to return the last chunk of data.

That statement of mine regarding AME messages was inaccurate/wrong,
apparently. AME message is optional only if TE (or CE) message
follows. You are right that in the case of OPES processor, AME is
usually required to signal the end of original data (AME) without
signaling the loss of interest (TE). I think we are on the same page
now, aren't we?

Thanks,

Alex.



From owner-ietf-openproxy@mail.imc.org  Mon Jun 30 15:46: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 PAA13707
	for <opes-archive@ietf.org>; Mon, 30 Jun 2003 15:46:13 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19X4bN-0003si-00
	for opes-archive@ietf.org; Mon, 30 Jun 2003 15:46:13 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19X4b7-0003sc-00
	for opes-archive@ietf.org; Mon, 30 Jun 2003 15:45: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 h5UJaXFK075934
	for <ietf-openproxy-bks@above.proper.com>; Mon, 30 Jun 2003 12:36: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 h5UJaXj7075933
	for ietf-openproxy-bks; Mon, 30 Jun 2003 12:36:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f
Received: from wwsmtp.webwasher.com ([217.146.159.49])
	by above.proper.com (8.12.9/8.12.8) with SMTP id h5UJaVFK075927
	for <ietf-openproxy@imc.org>; Mon, 30 Jun 2003 12:36:31 -0700 (PDT)
	(envelope-from martin.stecher@WEBWASHER.com)
Received: from mail.WEBWASHER.COM [192.168.0.251] id N6B7O701; 30 Jun 2003 21:36:32 +0200
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Subject: NO messages
Date: Mon, 30 Jun 2003 21:36:27 +0200
Message-ID: <75F7E67FC45F6744A7D328D41E35376D013F67@mail.webwasher.com>
Thread-Topic: NO messages
Thread-Index: AcM/PuXO12PHtrVLQnGpYv4VAbgHtw==
From: "Martin Stecher" <martin.stecher@WEBWASHER.com>
To: "OPES WG (E-Mail)" <ietf-openproxy@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h5UJaWFK075929
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 8bit


If a callout server supports different services, for example URL blocking and virus checking and if it allows the OPES processor to select the service(s) for the OCP transactions, then it also needs exchange this information in the profile negotiation.

For URL blocking the server is interested in the http://iana.org/opes/ocp/HTTP/request profile and for virus checking it will select the http://iana.org/opes/ocp/HTTP/response profile.

That implies that the NO message needs a services or sg-id parameter, I think.

What do you think?

Regards
Martin



From owner-ietf-openproxy@mail.imc.org  Mon Jun 30 16:06: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 QAA14173
	for <opes-archive@ietf.org>; Mon, 30 Jun 2003 16:06:39 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19X4v9-0003y6-00
	for opes-archive@ietf.org; Mon, 30 Jun 2003 16:06:39 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19X4ut-0003xt-00
	for opes-archive@ietf.org; Mon, 30 Jun 2003 16:06:23 -0400
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UJrUFK076836
	for <ietf-openproxy-bks@above.proper.com>; Mon, 30 Jun 2003 12:53: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 h5UJrUbE076835
	for ietf-openproxy-bks; Mon, 30 Jun 2003 12:53:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f
Received: from wwsmtp.webwasher.com ([217.146.159.49])
	by above.proper.com (8.12.9/8.12.8) with SMTP id h5UJrSFK076829
	for <ietf-openproxy@imc.org>; Mon, 30 Jun 2003 12:53:29 -0700 (PDT)
	(envelope-from martin.stecher@WEBWASHER.com)
Received: from mail.WEBWASHER.COM [192.168.0.251] id ZRAOQH0U; 30 Jun 2003 21:53:30 +0200
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Subject: The power of OCP
Date: Mon, 30 Jun 2003 21:53:25 +0200
Message-ID: <75F7E67FC45F6744A7D328D41E35376D013F68@mail.webwasher.com>
Thread-Topic: The power of OCP
Thread-Index: AcM/QUQLbK0V+TfsQKKOACKH0811Zg==
From: "Martin Stecher" <martin.stecher@webwasher.com>
To: "OPES WG (E-Mail)" <ietf-openproxy@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h5UJrTFK076831
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 8bit


These days I realized that one specific feature of a virus checking callout server can be implemented much better in OCP than in ICAP/1.0.

It is just one use case but it was an "aha-effect" for me, so I like to share it with you.

If a large file is being downloaded through the OPES processor which sends it to the callout server for virus checking, the server probably need to wait for the complete file before it check for viruses. Until then it does not want to send the data to the end user.

But to present at least some information to the end user while downloading there are various strategies in place to show some download progress. No real solution, just workarounds.
We talked about this before (remember LateClearance content encoding).

One popular strategy is to forward a few percent of the original message while the data is being received and processed by the callout server, known as download progress indication or data trickling.

If a callout server wants to implement this, it has to create an ICAP 200 message in ICAP/1.0 and looses the "204 no modification needed" option.
That means for a 5MB file it starts to send a few 100 bytes and after scanning the file it also has to send the other 4MB.
While the 204 message idea works for the smaller files, it does not work with data trickling and larger files. All data has to be sent forth and back. A real waste of bandwidth since no data is changed.

In OCP the callout server does not need to return any data, if the processor preservers all data and sends "Kept" parameters with its DUM messages.
During the data trickling phase, the callout server returns DUY messages with small sizes and after scanning is complete it sends one final DUY message that allows the complete rest to be sent to the client.
The 5MB is only transferred one way, and only a few bytes for the DUY messages is sent back.

Regards
Martin



From owner-ietf-openproxy@mail.imc.org  Mon Jun 30 16:26: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 QAA14663
	for <opes-archive@ietf.org>; Mon, 30 Jun 2003 16:26:42 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19X5EY-00044j-00
	for opes-archive@ietf.org; Mon, 30 Jun 2003 16:26:42 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19X5EJ-00044e-00
	for opes-archive@ietf.org; Mon, 30 Jun 2003 16:26: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 h5UKH5FK077539
	for <ietf-openproxy-bks@above.proper.com>; Mon, 30 Jun 2003 13:17: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 h5UKH5im077538
	for ietf-openproxy-bks; Mon, 30 Jun 2003 13:17: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 h5UKH4FK077531
	for <ietf-openproxy@imc.org>; Mon, 30 Jun 2003 13:17: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 h5UKH6Ds099973;
	Mon, 30 Jun 2003 14:17:06 -0600 (MDT)
	(envelope-from rousskov@measurement-factory.com)
Received: (from rousskov@localhost)
	by measurement-factory.com (8.12.9/8.12.5/Submit) id h5UKH6QB099972;
	Mon, 30 Jun 2003 14:17:06 -0600 (MDT)
	(envelope-from rousskov)
Date: Mon, 30 Jun 2003 14:17:06 -0600 (MDT)
From: Alex Rousskov <rousskov@measurement-factory.com>
To: "OPES WG (E-Mail)" <ietf-openproxy@imc.org>
Subject: Re: NO messages
In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D013F67@mail.webwasher.com>
Message-ID: <Pine.BSF.4.53.0306301406310.90894@measurement-factory.com>
References: <75F7E67FC45F6744A7D328D41E35376D013F67@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: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>



Martin,

	I feel like the current design is too rigid. You are saying
that it is common for one callout server to support multiple HTTP
adaptations services. And different adaptation services require
different messages or message parts to be exchanged via OCP. Our
current design ties message parts that can be exchanged to one of the
two HTTP profiles. Thus, with the current scheme the only way to
support multiple services that require different parts is to have at
least one OCP connection for each service.

	A possible solution would be to have a single HTTP profile
(that defines what HTTP message parts _can_ be exchanged) and
separately negotiate what services need what parts. Often a service ID
would define the list of parts and no extra negotiation would be
required. Would that work better from your point of view?

Alex.


On Mon, 30 Jun 2003, Martin Stecher wrote:

> If a callout server supports different services, for example URL
> blocking and virus checking and if it allows the OPES processor to
> select the service(s) for the OCP transactions, then it also needs
> exchange this information in the profile negotiation.
>
> For URL blocking the server is interested in the
> http://iana.org/opes/ocp/HTTP/request profile and for virus checking
> it will select the http://iana.org/opes/ocp/HTTP/response profile.
>
> That implies that the NO message needs a services or sg-id
> parameter, I think.
>
> What do you think?
>
> Regards
> Martin
>
>


From owner-ietf-openproxy@mail.imc.org  Mon Jun 30 16:45:10 2003
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15042
	for <opes-archive@ietf.org>; Mon, 30 Jun 2003 16:45:09 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UKWQFK078033
	for <ietf-openproxy-bks@above.proper.com>; Mon, 30 Jun 2003 13:32: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 h5UKWQch078032
	for ietf-openproxy-bks; Mon, 30 Jun 2003 13:32: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 h5UKWOFK078025
	for <ietf-openproxy@imc.org>; Mon, 30 Jun 2003 13:32: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 h5UKWQDs000461;
	Mon, 30 Jun 2003 14:32:26 -0600 (MDT)
	(envelope-from rousskov@measurement-factory.com)
Received: (from rousskov@localhost)
	by measurement-factory.com (8.12.9/8.12.5/Submit) id h5UKWQIO000460;
	Mon, 30 Jun 2003 14:32:26 -0600 (MDT)
	(envelope-from rousskov)
Date: Mon, 30 Jun 2003 14:32:26 -0600 (MDT)
From: Alex Rousskov <rousskov@measurement-factory.com>
To: "OPES WG (E-Mail)" <ietf-openproxy@imc.org>
Subject: Re: The power of OCP
In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D013F68@mail.webwasher.com>
Message-ID: <Pine.BSF.4.53.0306301426070.90894@measurement-factory.com>
References: <75F7E67FC45F6744A7D328D41E35376D013F68@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: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


On Mon, 30 Jun 2003, Martin Stecher wrote:

> In OCP the callout server does not need to return any data, if the
> processor preservers all data and sends "Kept" parameters with its
> DUM messages. During the data trickling phase, the callout server
> returns DUY messages with small sizes and after scanning is complete
> it sends one final DUY message that allows the complete rest to be
> sent to the client. The 5MB is only transferred one way, and only a
> few bytes for the DUY messages is sent back.

This works in theory. The hard part is to convince the processor to
preserve/keep 5MB of data. It is a lot of overhead for the processor
to keep all the data, and I am sure that a general-purpose
implementation may not be able to keep the whole thing by default.

OCP does not (yet?) have any mechanisms to (a) encourage preservation
or to (b) notify the server that the preservation buffer is limited to
X bytes and any spills will not be preserved. Do you think it should
be left to external negotiation channels (configuration files, etc.)?
Or should we try to support this directly? Which mechanism?

Thanks,

Alex.


From owner-ietf-openproxy@mail.imc.org  Mon Jun 30 16:56: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 QAA15746
	for <opes-archive@ietf.org>; Mon, 30 Jun 2003 16:56:22 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19X5hG-0004GC-00
	for opes-archive@ietf.org; Mon, 30 Jun 2003 16:56:22 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19X5h1-0004G3-00
	for opes-archive@ietf.org; Mon, 30 Jun 2003 16:56:07 -0400
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UKiFFK078639
	for <ietf-openproxy-bks@above.proper.com>; Mon, 30 Jun 2003 13:44: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 h5UKiFaR078638
	for ietf-openproxy-bks; Mon, 30 Jun 2003 13:44:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f
Received: from wwsmtp.webwasher.com ([217.146.159.49])
	by above.proper.com (8.12.9/8.12.8) with SMTP id h5UKiDFK078628
	for <ietf-openproxy@imc.org>; Mon, 30 Jun 2003 13:44:13 -0700 (PDT)
	(envelope-from martin.stecher@WEBWASHER.com)
Received: from mail.WEBWASHER.COM [192.168.0.251] id L0NYPRST; 30 Jun 2003 22:44: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.6249.0
Subject: RE: NO messages
Date: Mon, 30 Jun 2003 22:44:09 +0200
Message-ID: <75F7E67FC45F6744A7D328D41E35376D013F6A@mail.webwasher.com>
Thread-Topic: NO messages
Thread-Index: AcM/RJV7bwPR+wAWRPaWqB2lYcbZSQAAxsDg
From: "Martin Stecher" <martin.stecher@webwasher.com>
To: "OPES WG (E-Mail)" <ietf-openproxy@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h5UKiEFK078633
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 8bit


> 	I feel like the current design is too rigid. You are saying
> that it is common for one callout server to support multiple HTTP
> adaptations services. And different adaptation services require
> different messages or message parts to be exchanged via OCP. Our
> current design ties message parts that can be exchanged to one of the
> two HTTP profiles. Thus, with the current scheme the only way to
> support multiple services that require different parts is to have at
> least one OCP connection for each service.

I had no problem if distinct connections per service worked.
But if at the beginning of a connection a NO message offers alternatives, the callout server does not know which services will be selected later on and so cannot make a decision.

> 
> 	A possible solution would be to have a single HTTP profile
> (that defines what HTTP message parts _can_ be exchanged) and
> separately negotiate what services need what parts. Often a service ID
> would define the list of parts and no extra negotiation would be
> required. Would that work better from your point of view?

That could work. Can you make a suggestion how this separate negotiation will look like?

Martin


> 
> Alex.
> 
> 
> On Mon, 30 Jun 2003, Martin Stecher wrote:
> 
> > If a callout server supports different services, for example URL
> > blocking and virus checking and if it allows the OPES processor to
> > select the service(s) for the OCP transactions, then it also needs
> > exchange this information in the profile negotiation.
> >
> > For URL blocking the server is interested in the
> > http://iana.org/opes/ocp/HTTP/request profile and for virus checking
> > it will select the http://iana.org/opes/ocp/HTTP/response profile.
> >
> > That implies that the NO message needs a services or sg-id
> > parameter, I think.
> >
> > What do you think?
> >
> > Regards
> > Martin
> >
> >
> 



From owner-ietf-openproxy@mail.imc.org  Mon Jun 30 17:10: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 RAA16533
	for <opes-archive@ietf.org>; Mon, 30 Jun 2003 17:10:40 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19X5v6-0004Nq-00
	for opes-archive@ietf.org; Mon, 30 Jun 2003 17:10:40 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19X5uq-0004Nb-00
	for opes-archive@ietf.org; Mon, 30 Jun 2003 17:10: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 h5UKtwFK079016
	for <ietf-openproxy-bks@above.proper.com>; Mon, 30 Jun 2003 13:55:58 -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 h5UKtwTZ079015
	for ietf-openproxy-bks; Mon, 30 Jun 2003 13:55:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f
Received: from wwsmtp.webwasher.com ([217.146.159.49])
	by above.proper.com (8.12.9/8.12.8) with SMTP id h5UKttFK079007
	for <ietf-openproxy@imc.org>; Mon, 30 Jun 2003 13:55:56 -0700 (PDT)
	(envelope-from martin.stecher@WEBWASHER.com)
Received: from mail.WEBWASHER.COM [192.168.0.251] id X6QYRE71; 30 Jun 2003 22:55:57 +0200
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Subject: RE: The power of OCP
Date: Mon, 30 Jun 2003 22:55:52 +0200
Message-ID: <75F7E67FC45F6744A7D328D41E35376D013F6B@mail.webwasher.com>
Thread-Topic: The power of OCP
Thread-Index: AcM/Rrm1MwEi0TpjQYqOOqYrOY4vmAAAdG6g
From: "Martin Stecher" <martin.stecher@webwasher.com>
To: "OPES WG (E-Mail)" <ietf-openproxy@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h5UKtvFK079010
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 8bit


> 
> > In OCP the callout server does not need to return any data, if the
> > processor preservers all data and sends "Kept" parameters with its
> > DUM messages. During the data trickling phase, the callout server
> > returns DUY messages with small sizes and after scanning is complete
> > it sends one final DUY message that allows the complete rest to be
> > sent to the client. The 5MB is only transferred one way, and only a
> > few bytes for the DUY messages is sent back.
> 
> This works in theory. The hard part is to convince the processor to
> preserve/keep 5MB of data. It is a lot of overhead for the processor
> to keep all the data, and I am sure that a general-purpose
> implementation may not be able to keep the whole thing by default.

I know at least one ICAP/1.0 implementation that can keep copies of very large files (swapping to disk if needed).
Virus filtering is one of the most wanted callout service today. It makes sense to design OPES processors in a way to support those best.
While many OPES processors are caching proxies and because virus filter services often do not change data, it makes sense to store already the original data into the cache, being prepared to replace it later if required and so preserving all data anytime.

> 
> OCP does not (yet?) have any mechanisms to (a) encourage preservation
> or to (b) notify the server that the preservation buffer is limited to
> X bytes and any spills will not be preserved. Do you think it should
> be left to external negotiation channels (configuration files, etc.)?
> Or should we try to support this directly? Which mechanism?

I do not think right now that exchanging this data or even negotiating on this will really change something.
A processor may or may not have limitation for its data preservation capabilities. Preferences of the callout server will probably not change anything here.
Callout servers may like to make intensive use from preserved data but be definition need to be prepared that the processor stops to preserve more data; it has to handle that anyway. No need for a special announcement I guess; it won't change the algorithm I guess.

Am I missing something?
Do you know of examples where exhanging of that information will make a difference?

Martin




From owner-ietf-openproxy@mail.imc.org  Mon Jun 30 17:26: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 RAA17080
	for <opes-archive@ietf.org>; Mon, 30 Jun 2003 17:26:49 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19X6Aj-0004Vb-00
	for opes-archive@ietf.org; Mon, 30 Jun 2003 17:26:49 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19X6AT-0004VO-00
	for opes-archive@ietf.org; Mon, 30 Jun 2003 17:26:33 -0400
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h5ULGbFK079822
	for <ietf-openproxy-bks@above.proper.com>; Mon, 30 Jun 2003 14:16:37 -0700 (PDT)
	(envelope-from owner-ietf-openproxy@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h5ULGawK079821
	for ietf-openproxy-bks; Mon, 30 Jun 2003 14:16:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f
Received: from measurement-factory.com (measurement-factory.com [206.168.0.5])
	by above.proper.com (8.12.9/8.12.8) with ESMTP id h5ULGZFK079816
	for <ietf-openproxy@imc.org>; Mon, 30 Jun 2003 14:16:35 -0700 (PDT)
	(envelope-from rousskov@measurement-factory.com)
Received: from measurement-factory.com (localhost [127.0.0.1])
	by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h5ULGbDs001539
	for <ietf-openproxy@imc.org>; Mon, 30 Jun 2003 15:16:37 -0600 (MDT)
	(envelope-from rousskov@measurement-factory.com)
Received: (from rousskov@localhost)
	by measurement-factory.com (8.12.9/8.12.5/Submit) id h5ULGb22001538;
	Mon, 30 Jun 2003 15:16:37 -0600 (MDT)
	(envelope-from rousskov)
Date: Mon, 30 Jun 2003 15:16:37 -0600 (MDT)
From: Alex Rousskov <rousskov@measurement-factory.com>
To: "OPES WG (E-Mail)" <ietf-openproxy@imc.org>
Subject: RE: NO messages
In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D013F6A@mail.webwasher.com>
Message-ID: <Pine.BSF.4.53.0306301507080.90894@measurement-factory.com>
References: <75F7E67FC45F6744A7D328D41E35376D013F6A@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: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>



On Mon, 30 Jun 2003, Martin Stecher wrote:

> > 	A possible solution would be to have a single HTTP profile
> > (that defines what HTTP message parts _can_ be exchanged) and
> > separately negotiate what services need what parts. Often a
> > service ID would define the list of parts and no extra negotiation
> > would be required. Would that work better from your point of view?
>
> That could work. Can you make a suggestion how this separate
> negotiation will look like?

It could be the same as service "negotiation" now. For services that
imply a particular set of parts, the service ID is sufficient. For
other services, the part names will be listed as service parameters,
just like they are listed as profile parameters now.

OCP does not have a mechanism to negotiate services, but one can
reject a Transaction Start (TS) or Create Service Group (SGC) message
by closing the transaction or connection.

Alex.


From owner-ietf-openproxy@mail.imc.org  Mon Jun 30 17:35: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 RAA17267
	for <opes-archive@ietf.org>; Mon, 30 Jun 2003 17:35:29 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19X6J8-0004YD-00
	for opes-archive@ietf.org; Mon, 30 Jun 2003 17:35:30 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19X6Is-0004Y9-00
	for opes-archive@ietf.org; Mon, 30 Jun 2003 17:35: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 h5ULOxFK080093
	for <ietf-openproxy-bks@above.proper.com>; Mon, 30 Jun 2003 14:24: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 h5ULOxiO080092
	for ietf-openproxy-bks; Mon, 30 Jun 2003 14:24: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 h5ULOvFK080086
	for <ietf-openproxy@imc.org>; Mon, 30 Jun 2003 14:24:57 -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 h5ULOxDs001673;
	Mon, 30 Jun 2003 15:24:59 -0600 (MDT)
	(envelope-from rousskov@measurement-factory.com)
Received: (from rousskov@localhost)
	by measurement-factory.com (8.12.9/8.12.5/Submit) id h5ULOxeR001672;
	Mon, 30 Jun 2003 15:24:59 -0600 (MDT)
	(envelope-from rousskov)
Date: Mon, 30 Jun 2003 15:24:59 -0600 (MDT)
From: Alex Rousskov <rousskov@measurement-factory.com>
To: "OPES WG (E-Mail)" <ietf-openproxy@imc.org>
Subject: RE: The power of OCP
In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D013F6B@mail.webwasher.com>
Message-ID: <Pine.BSF.4.53.0306301518210.90894@measurement-factory.com>
References: <75F7E67FC45F6744A7D328D41E35376D013F6B@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: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>



On Mon, 30 Jun 2003, Martin Stecher wrote:

> I do not think right now that exchanging this data or even
> negotiating on this will really change something. A processor may or
> may not have limitation for its data preservation capabilities.
> Preferences of the callout server will probably not change anything
> here. Callout servers may like to make intensive use from preserved
> data but be definition need to be prepared that the processor stops
> to preserve more data; it has to handle that anyway. No need for a
> special announcement I guess; it won't change the algorithm I guess.
>
> Am I missing something? Do you know of examples where exhanging of
> that information will make a difference?

A translation service will not use any of the data. An ad banner
stripping service will use all but the prefix data. The virus filter
service will use all the data. Ideally, the processor should not keep
5MB file to be translated but should keep the 5MB file being filtered.
How does the processor distinguish among these cases? Should the
processor assume that most data will be re-requested and preserve
aggressively until it receives a Wont-Use message?

Alex.