I've received several responses about my comments regarding OPES tracing
and access to diagnostics. Rather than get drawn into a repetitious series
of overlapping emails, I'm going to try and deal with them all together.
First a summary of my position: I think an endpoint-user needs to be able
to access OPES diagnostic information using commonly-used legacy
software. Requiring the endpoint-user to upgrade their software to access
diagnostic information does not, in my view, adequately address the intent
of the IAB requirements.
I have no problem with protocol extensions being available to facilitate
access to the information.
I would also like to maintain some focus on the particular example I
raised: I think it represents a common use-case that well illustrates the
need for diagnostic information. It is the case of an intermediate cache
that returns the wrong data in response to a web page request. Using a
standard browser, how am I to use the OPES trace/log information to
diagnose the problem? (I'm not claiming this is the *only* case that OPES
should deal with, just that it's illustrative of an important case.)
Objections to my position that I have noted are:
- End users can't understand this diagnostic stuff
- Only administrators need to access the traces
Maybe many end-users won't understand it, but I see that as no reason to
deny access to the information by those who can use it. My experience of
over-stretched ISPs and corporate IT departments suggests that
administrators won't bother - I feel strongly that Internet technology
should not operate to deny self help to users at the network edge. I also
think this principle informs the IAB requirements on OPES.
- Inband signalling means the user will have a locally stored copy
- Email system as model
For email, I can see a case that in-band signalling could provide the
needed information, but even there I'm not totally convinced. It is in the
nature of email that messages are stored, complete with their headers,
which are used for such purposes as constructing replies. I don't know if
all email clients provide access to arbitrary header information, but I
acknowledge that some (many?) do.
But OPES is not just about email. Someone on this list mentioned that HTTP
is the target of any initial protocol-specific design work. I claim that
HTTP content is inherently transient. It is designed as a stateless
protocol so servers don't have to hold on to request information, and in
typical default use the results are displayed transiently at the
client. (Yes, I know there's usually a browser cache, but that too is
transient and as far as I have been aware it's only the HTTP response
bodies and essential identifying information that are cached.)
So, I remain unconvinced that in-band signalling is the way to persist
diagnostic information.
- In-band is needed for information from other administrative domains
This is a fair point. Ad-hoc out-of-band mechanisms cannot really be
expected to be effective across administrative domains. Thus it seems to
me that accessing information about behaviours in other domains is going to
be a tricky problem to solve well. In-band information may help, and I'm
not opposed to using it (just not depending on it).
The OPES architecture requires that each intermediary is operating under
the authority of one or other endpoint (the colouring
discussion). Further, even when the infrastructure providers may have
little interest in resolving problems, the endpoints will often have reason
to cooperate. So, it seems to me that always having out of band access
from one endpoint or the other is a far better outcome than having none.
- OPES operations are determined per-message
- Keeping a log at an intermediary is insufficient
Actually, I imagine that keeping a log could be quite sufficient, if
sufficient information is logged.
I understand that one of the OPES requirements is that any intermediary
operates with the authorization of one of the endpoints, which implies that
at least one endpoint should know about any OPES intermediary that
manipulates some data in transit.
Knowing the time, source and target of a request, it should be reasonably
easy to identify a particular HTTP request and response from logging data
kept at an intermediary.
#g
-------------------
Graham Klyne
<GK(_at_)NineByNine(_dot_)org>