Subject: RE: Bypassing

From: "Martin Stecher" <[email-masked]>
Date: Thu, 2 Oct 2003 10:08:58 +0200

Hi,

>...
> 
> > Did we ever think about different classes of services? It could make
> > sense to allow all non-modifying OPES services, i.e. those that do
> > some logging/reporting wihtout touching the data at all or those
> > that block the complete message on policy violation (e.g. virus
> > found) but would not alter the page itself.
> 
> Good point. I would suggest that we standardize URIs that identify
> overlapping "classes" or "types" of OPES entities:
> 	- modifying (forwarding with modifications other than traces)
> 	- blocking (not forwarding)
> 	- reading (forwarding without modifications other than traces)
> 	- logging (keeping a portion of a message beyond message TTL)
> 	- unknown (the entity in charge of bypass does not know the
> 	  class of an entity it forwards OPES traffic to)
> 
> More or better class names, anyone?
> 

What about encoding changes?
Is removing/adding a content or transfer encoding a modification?
Not of the real content but we may have this as an additional class
or subclass.

 - modifying
 - blocking+encoding
 - logging+encoding
 - blocking
 - logging
 - reading
 - unknown

Does this make sense?

If yes, what if the service is of class "blocking" and the OPES processor
does the preprocessing of removing gzip-encoding? Is the OPES processor
then responsible for adjusting the class?

Martin

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 2 Oct 2003 09:43:34 -0600 (MDT)

> Not of the real content but we may have this as an additional class

Indeed! Looks like we have modification of content/message _meaning_
and modification of content/message presentation (encodings and
formats of all sorts). In general, it is impossible to distinguish the
two formally, but there are many specific adaptations where the
difference is clear. I would suggest:

	- modifying
	  ~ meaning
	  ~ presentation
	- blocking
	- logging
	- reading
	- unknown

The total of 7 classes. One would be able to request a bypass of all
services that modify the message (in any way) OR bypass of all
services that modify the message beyond presentational modifications
such as content encoding or image quality adaptations.

Any combination is permitted, of course. An entity may be both
meaning-modifying and blocking. Somebody may request bypass for all
unknown and logging entities.

N.B. Transfer encoding allowed by the application protocol is not
adaptation we care about, I guess. This can be done outside of OPES
already, without violating protocol rules. We only care about
OPES-enabled adaptations that are not allowed by application protocols
or break end-to-end expectations (e.g., addition of ads or logging
adaptations).

> If yes, what if the service is of class "blocking" and the OPES
> processor does the preprocessing of removing gzip-encoding? Is the
> OPES processor then responsible for adjusting the class?

The class is currently not reported anywhere (we should probably add
this as an optional parameter to the OPES-* headers though!). Thus,
there is nothing to adjust.

Each entity (including processors and services) is responsible for
handling bypass instructions it receives. If processor only knows its
own class, it will handle bypass based on that class and, optionally,
handle bypass for "unknown" class of service (since the processor does
not know the class of service). The service, in turn, will bypass its
own class if it can. Of course, if the processor does know more about
the service it uses, it should bypass the service when there is a
match.

Does this clarify? Did I miss anything?

Thanks,

Alex.