Re: WG Last Call: draft-ietf-opes-architecture-002002-05-21 13:10:08
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.