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.