Subject: RE: Notification

From: "Abbie Barbir" <[email-masked]>
Date: Tue, 8 Apr 2003 09:20:00 -0400

see inline,

Abbie

> -----Original Message-----
> From: Alex Rousskov [mailto:[email-masked]] 
> Sent: Tuesday, April 08, 2003 8:29 AM
> To: [email-masked]
> 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

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 8 Apr 2003 08:57:29 -0600 (MDT)

On Tue, 8 Apr 2003, Abbie Barbir wrote:

> 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).

Does not matter at this point. Application dependency is a secondary
problem, IMO. First, we need to decide whether we should support
notification (on a protocol level) at all.

>    allowing them to identify imperfect or compromised intermediaries.

I believe tracing satisfies 3.2. The only problem is with 3.1 because
most client-centric actions happen _after_ the application message left
the content provider(s) and, thus, notifications cannot be piggy-backed
to application messages and have to travel in the opposite direction of
traces. Let's concentrate on satisfying 3.1 as the subject of this
thread.

The 3.1 requirement is quite vague and it is not clear how normative
are the comments that accompany/justify it. My vote is to interpret
"assist" above as "assistance on non-protocol level". That is, we
provide always-on tracing and claim that traces are sufficient to
satisfy 3.1 above as long as both ends cooperate. We can also assert
that if the ends do not cooperate, then no protocol-level solution
will work either. Specifically, we suggest that content providers that
suspect or experience difficulties do the following:

	1. Check whether requests they receive pass through
	  OPES intermediaries. Presence of OPES tracing info
	  will determine that. This check is only possible for
	  request/response protocols. For other protocols (e.g.,
	  broadcast or push), the provider would have to assume
	  that OPES intermediaries are involved until proven
	  otherwise.

	2. If OPES intermediaries are suspected,
	  request OPES traces from potentially affected user(s).
	  The trace will be a part of the application message
	  received by the user software. If users cooperate,
	  the provider(s) have all the information they need.
	  If users do not cooperate, the provider(s) cannot
	  do much about it (they might be able to deny service
	  to uncooperative users in some cases).

	3. Some traces may indicate that more information
	  is available by accessing certain resources on the
	  specified OPES intermediary or elsewhere. Content
	  providers may query for more information in that
	  case.

	4. If everything else fails, providers can enforce
	   no-adaptation policy using appropriate OPES
	   bypass mechanisms and/or end-to-end mechanisms.

Alex.