Re: WG Last Call: draft-ietf-opes-architecture-00

Graham Klyne wrote:

> I presume that the OPES intermediary would be communicating with the 
> endpoint in whose admin domain it is operating, so some local 
> arrangement is not unreasonable.  Returning to my earlier example (ISP 
> web cache), the link for tracing information could be provided through a 
> web page that is accessed through a login mechanism similar to that used 
> for retrieving mail via a web browser.
What about endpoints that are *not* located within the admin domain of 
the (faulty) OPES system? And how would an endpoint learn about which 
OPES systems have been involved at all?
It's not only the OPES system in the enduser's admin domain that migth 
cause trouble, it might be any OPES system on the way betweem client 
and server. Therefore, the endpoint somehow needs to identify which 
OPES systems the message went through - and this is not static, it can 
be different on a per message basis.
> Note, I'm not saying extensions cannot be used, just that obtaining the 
> diagnostics should not depend on the endpoint having implemented such 
> extensions.
Please correct me if I'm wrong, but I think we're in agreement that an 
enduser would retrieve detailed tracing information from an OPES 
system out-of-band, via some standard mechanism (e.g. Web page etc.). 
I.e. there's no need to implement any extensiosn to retrieve the 
detailed tracing info. What remains open, though, is the question (a) 
how the enduser learns which OPES system(s) the message traveled 
through and, therefore, might have to be contacted, and (b) how to 
contact them.
-Markus