Subject: Bypassing

From: "Martin Stecher" <[email-masked]>
Date: Wed, 1 Oct 2003 19:14:52 +0200

Hi,

some questions about how to fill the Bypass section in the http adaption document.

0. Information missing in other drafts?
draft-ietf-opes-end-comm-02 does not include any information about bypassing.
draft-ietf-opes-iab-02 only points out that the tracin information can be later
used to request OPES bypass.
Do we need more elaboration on bypassing in draft-ietf-opes-end-comm?

1. What to bypass?
There are trace headers OPES-System, OPES-Processor and OPES-Service.
Which ones make sense to use in bypassing?
Usually it will not be possible to bypass an OPES-Processor but is it required
to ask for bypassing of all OPES services that an OPES processor uses?
So, do we need one, two or three OPES-Bypass headers?

2. Wildcards
I guess we want to allow something like
  OPES-Bypass: *
to request bypassing of all OPES services.
Did we ever think about different classes of services?
It could make sense to allow all non-modifying OPES services, i.e. those that
do some logging/reporting wihtout touching the data at all or those that block
the complete message on policy violation (e.g. virus found) but would not alter
the page itself.
I guess due to the notification/tracing dilema in almost all cases, the HTTP
server will not know about single OPES services to bypass and if it is concerned
about OPES services it has to request bypass of all or at least of some sort of
OPES services.

Regards
Martin

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 1 Oct 2003 11:57:39 -0600 (MDT)

> Do we need more elaboration on bypassing in draft-ietf-opes-end-comm?

Yes. I also included a note about that in my review (sent to the list
an hour or so ago).

> So, do we need one, two or three OPES-Bypass headers?

For simplicity and generality, I would suggest one header. Each OPES
entity above must be identified by its URI. So, assuming different
kinds of entities have different URIs, one header to bypass anything
is sufficient. Of course, some entities (on any level) may not be
bypass-able for a given application message. That's OK.

> to request bypassing of all OPES services.

Yes.

> Did we ever think about different classes of services? It could make
> sense to allow all non-modifying OPES services, i.e. those that do
> some logging/reporting wihtout touching the data at all or those
> that block the complete message on policy violation (e.g. virus
> found) but would not alter the page itself.

Good point. I would suggest that we standardize URIs that identify
overlapping "classes" or "types" of OPES entities:
	- modifying (forwarding with modifications other than traces)
	- blocking (not forwarding)
	- reading (forwarding without modifications other than traces)
	- logging (keeping a portion of a message beyond message TTL)
	- unknown (the entity in charge of bypass does not know the
	  class of an entity it forwards OPES traffic to)

More or better class names, anyone?

One could argue that pure "reading" entities do not exist. We can
leave it as a loophole for statistics-collecting entities, but note
that statistics collection at a "reading-only" entity MUST NOT include
storing samples of any size.

This addition will not affect OPES-Bypass header syntax or semantics.
We are still doing a URI match. It's just that some entities are known
by several URIs (unique one and a "group/class" URI). See below for an
example.

> I guess due to the notification/tracing dilema in almost all cases,
> the HTTP server will not know about single OPES services to bypass
> and if it is concerned about OPES services it has to request bypass
> of all or at least of some sort of OPES services.

I agree that it would take some advance configuration support on
processor side to implement bypass, but it is probably relatively easy
to document in the draft. Eventually, it may become implemented:

	id:         unique URI

	aka:        classification URIs (at least one SHOULD be
	            present since we have an unknown category)

	protocol:   internal info describing
	            ways to communicate with the service
	            (ICAP, OCP, plugin, etc.)

	bypassable: yes/no (indicates whether requests to
	            bypass the service should be honored)

HTH,

Alex.