Subject: RE: honoring bypass is a MUST

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

Hi,

if we require that the service's trace URI is identical with the service URI being used by the OPES processor in the SGC (service group create) command, then we ensure that the OPES processor is able to handle the bypass without contacting the service at all.

Martin

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Alex Rousskov
> Sent: Thursday, October 02, 2003 1:51 AM
> To: OPES WG
> Subject: honoring bypass is a MUST
> 
> 
> 
> Abbie,
> 
> 	You asked me to investigate whether honoring bypass is a MUST
> or a SHOULD. IMO, IAB consideration 3.3 clearly indicates that it has
> to be a MUST, with a caveat:
> 
>    (3.3) Non-blocking: If there exists a "non-OPES" version of content
>    available from the content provider, the OPES architecture must not
>    prevent users from retrieving this "non-OPES" version from the
>    content provider.
> 
> The bypass requirement will be non-trivial to define accurately.
> First, you have to distinguish two cases based on availability of
> non-OPES content.
> 
> Second, you have to be careful not to require compliance from OPES
> entities that do not care about application message headers that may
> contain bypass instructions. For example, it is unreasonable to expect
> an image transformation service that works with content, not HTTP
> headers to handle bypass -- an OPES processor calling that service
> must handle bypass. On the other hand, in some cases, only the service
> would be able to match the bypass URI because an OPES processor will
> not know the URI of the service or will not know its "class" (see
> Martin's thoughts on classes of services). Now, what do we do when the
> two cases are combined (the service is not able and the processor is
> able but does not have the required information)??
> 
> Third, you have to document what happens when an OPES entity needs to
> bypass itself. Clearly, it should not modify message content, but
> should it add its own trace since it touched the message? Yes, because
> it did touch the message. No, because maybe its [corrupted] trace
> entry is the reason the other end wants to bypass!
> 
> Finally, you should not rely on bypass instructions to be transmitted
> in-band (e.g., in request headers). Bypass information transmission
> should be left to the application binding drafts.
> 
> Keep it simple :-).
> 
> Good luck,
> 
> Alex.
> 
> ------------------------------------------------------------
> This mail has been scanned by debian3-smtp
> (WebWasher 4.4.1 Build 652)
> ------------------------------------------------------------
>

---

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

On Thu, 2 Oct 2003, Martin Stecher wrote:

> if we require that the service's trace URI is identical with the
> service URI being used by the OPES processor in the SGC (service
> group create) command, then we ensure that the OPES processor is
> able to handle the bypass without contacting the service at all.

I would not require that (MUST). It can be a SHOULD, I guess. Imagine
a callout server that does one of 10 things to the message, depending
on message content. The processor will know the server under
i-do-10-things URI, but a trace may contain a more specific
i-did-1-thing URI (unknown a priory to the processor).

Also, with your adaptation classes idea, the processor may not know
the class of the adaptation service it is using and, hence, would not
be able to bypass it without communicating with the service first.
This implies that we should probably pass bypass URIs in the SGC or a
similar command, right? This way the service can bypass itself before
it sees the message, if possible.

Since bypass is, by nature, an imprecise no-guarantees mechanism, my
preference would be to leave things simple and flexible rather than
introduce a new layer of strict/rigid requirements on service
identification. On the other hand, I understand that we need to find a
balance between "a overly complicated optional feature that nobody
supports" and "an overly flexible optional feature that is widely
supported but offers no reliability".

Alex.