On Thu, 2 Oct 2003, Martin Stecher wrote:
if we require that the service's trace URI is identical with the
service URI being used by the OPES processor in the SGC (service
group create) command, then we ensure that the OPES processor is
able to handle the bypass without contacting the service at all.
I would not require that (MUST). It can be a SHOULD, I guess. Imagine
a callout server that does one of 10 things to the message, depending
on message content. The processor will know the server under
i-do-10-things URI, but a trace may contain a more specific
i-did-1-thing URI (unknown a priory to the processor).
Also, with your adaptation classes idea, the processor may not know
the class of the adaptation service it is using and, hence, would not
be able to bypass it without communicating with the service first.
This implies that we should probably pass bypass URIs in the SGC or a
similar command, right? This way the service can bypass itself before
it sees the message, if possible.
Since bypass is, by nature, an imprecise no-guarantees mechanism, my
preference would be to leave things simple and flexible rather than
introduce a new layer of strict/rigid requirements on service
identification. On the other hand, I understand that we need to find a
balance between "a overly complicated optional feature that nobody
supports" and "an overly flexible optional feature that is widely
supported but offers no reliability".
Alex.
-----Original Message-----
From: owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of
Alex Rousskov
Sent: Thursday, October 02, 2003 1:51 AM
To: OPES WG
Subject: honoring bypass is a MUST
Abbie,
You asked me to investigate whether honoring bypass is a MUST
or a SHOULD. IMO, IAB consideration 3.3 clearly indicates that it has
to be a MUST, with a caveat:
(3.3) Non-blocking: If there exists a "non-OPES" version of content
available from the content provider, the OPES architecture must not
prevent users from retrieving this "non-OPES" version from the
content provider.
The bypass requirement will be non-trivial to define accurately.
First, you have to distinguish two cases based on availability of
non-OPES content.
Second, you have to be careful not to require compliance from OPES
entities that do not care about application message headers that may
contain bypass instructions. For example, it is unreasonable to expect
an image transformation service that works with content, not HTTP
headers to handle bypass -- an OPES processor calling that service
must handle bypass. On the other hand, in some cases, only the service
would be able to match the bypass URI because an OPES processor will
not know the URI of the service or will not know its "class" (see
Martin's thoughts on classes of services). Now, what do we do when the
two cases are combined (the service is not able and the processor is
able but does not have the required information)??
Third, you have to document what happens when an OPES entity needs to
bypass itself. Clearly, it should not modify message content, but
should it add its own trace since it touched the message? Yes, because
it did touch the message. No, because maybe its [corrupted] trace
entry is the reason the other end wants to bypass!
Finally, you should not rely on bypass instructions to be transmitted
in-band (e.g., in request headers). Bypass information transmission
should be left to the application binding drafts.
Keep it simple :-).
Good luck,
Alex.
------------------------------------------------------------
This mail has been scanned by debian3-smtp
(WebWasher 4.4.1 Build 652)
------------------------------------------------------------