see inline,
Abbie
> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@xxxxxxxxxxxxxxxxxxxxxxx]
> Sent: Tuesday, April 08, 2003 8:29 AM
> To: ietf-openproxy@xxxxxxx
> Subject: RE: Notification
>
>
>
> 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.
Yes, this should be the case. In this case, is Notification application Protocol dependent?
Or is it done out of band, (this also addresses next paragraph too). I agree with u that this will not be easy. The point here is to define what we will support for notification, since it can be argued that tracing by itself is a tool and notification is the mechanism for using tracing/debugging.
>
> 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.
Here are the IAB requirements:
(3.1) Notification: The overall OPES framework needs to assist
content providers in detecting and responding to client-centric
actions by OPES intermediaries that are deemed inappropriate by the
content provider.
(3.2) Notification: The overall OPES framework should assist end
users in detecting the behavior of OPES intermediaries, potentially
allowing them to identify imperfect or compromised intermediaries.
abbie