On Tue, 8 Apr 2003, Abbie Barbir wrote:
The difference is that notification occur first and then tracing can occur.
Basically, the assumption is that the default is that tracing if off.
For example, contnet provider gets to be aware of a problem thru
notification. Then tracing is invoked to help solve the issues.
If that is the case, I suggest that tracing should be always-on, just
like HTTP Via headers now. This eliminates notification as a separate
problem!
I expected you to say that notification goes in opposite direction of
tracing and does not (cannot) be attached to application messages that
it notifies about. For example, if OPES is processing an HTTP request,
the trace is attached to that request and optional notifications are
sent to the client as the request passes through OPES intermediaries.
If OPES is processing an HTTP response, the trace is attached to that
response, and an optional notification is sent to provider(s?) as the
response passes through OPES intermediaries.
Note that since some of the application protocols we want to support
use "store and forward" model and not "request/response" (e.g.,
SMTP), we cannot use responses to attach request notifications. In any
case, that trick will not help a provider because notification
information about the response is not available at the time of the
request.
This opposite-direction, outside-of-message scheme is much more
difficult to support and, frankly, I think it would be a waste of time
developing it. However, it is probably very close to what IAB would
prefer (based on what the Considerations RFC they wrote).
Comments?
Alex.