Subject: RE: Notification

From: "Abbie Barbir" <[email-masked]>
Date: Tue, 8 Apr 2003 06:16:58 -0400

Alex,

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.

Just my $000002 cents.

Abbie

> -----Original Message-----
> From: Alex Rousskov [mailto:[email-masked]] 
> Sent: Monday, April 07, 2003 7:38 PM
> To: [email-masked]
> Subject: Re: Notification
> 
> 
> Abbie,
> 
> 	What is the difference between tracing and notification 
> _if_ tracing is always-on (i.e., trace info is attached to 
> every message)? Both architecture and OCP requirements drafts 
> do not define "notification" (AFAIK), so I am not sure what 
> the difference is. Please clarify.
> 
> Thank you,
> 
> Alex.
> 
> On Mon, 7 Apr 2003, Abbie Barbir wrote:
> 
> >
> > With all the discussions on tracing, I discovered late 
> today during my 
> > attempt to summarize the discussion in a draft format that 
> we have not 
> > yet discussed Notification.
> >
> > So, to start,
> > 1. What really triggers notification
> >    - End Application/user
> > 2. Is the process automated
> >    - Rules triggers action, then error occurs OPES processor notify 
> > content provider
> >    - Callout server dicovers errors and inform whom, OPES 
> processor and it
> >      then notify content provider?
> > 3. How does this relate to Trust domains and Deployment
> > 4. In the simplest case, can we say
> >    - Agent (consumer/provider application)  does not like the OPES 
> > actions, invoke tracing (assuming that we have agreed on how) as a 
> > mechanism for notification (this is indirectly addressing 
> > notification)
> >
> > 5. Can we assume that notification is done on error only?
> >   - What is an error
> >     - Inavlid URL
> >     - Malformed Image etc..
> >
> > 6. How about Content Provider induced erros ( bad links or bad 
> > programming practices)are they part of OPES Notification.
> >
> > 7. Can Notification be done offline (Poll OPES Servers at 
> the end of 
> > business day and check an error log file ?)
> >
> > These are just thoughs for now
> >
> > Abbie
> >
> >
> >
> >
> >
>

---

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

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

---

From: Markus Hofmann <[email-masked]>
Date: Tue, 08 Apr 2003 10:54:54 -0400

Alex Rousskov wrote:

> it notifies about. 

Yup, that's my interpretation of "tracing" and "notification". I would 
further assume that "tracing" is always-on, just as "tracing" mail 
servers via headers is always-on.

A major concern with notification is scalability. A content provider 
certainly is not interested in receiving a notification for every HTTP 
response sent out. As such, a mechanism for explicit request of 
notification is required. Now, when exactly would a content provider 
issue such request? How would such mechanism be used? Randomly, or on 
a statistical basis? Or manually? Is such a scheme of practical relevance?

Privacy is another concern. Maybe a user doesn't want to reveal to any 
content provider all the OPES services that have been applied on her 
behalf. For example, why should every content provider know what exact 
virus scanner I'm using? Wouldn't that help hackers, for example?

> prefer (based on what the Considerations RFC they wrote).

I tend to agree with you that the kind of "opposite-direction, 
outside-of-message scheme" is quite tricky, and IMHO not very 
practical. Scalability and also privacy are a big concern here.

However, IAB consideration (3.1) suggests a kind of notification along 
thos lines:

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

Section 3.1 of RFC3238 provides the motivation for this consideration, 
and there are certainly some very valid arguments. However, maybe 
there're other means to address these concerns?

Probably best if we check-in with our ADs and the IAB at some point, 
but I'd first like to discuss this a little bit further and solicit 
input on this very topic from other folks as well. So, please post 
your comments on this one!

-Markus

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 8 Apr 2003 12:07:50 -0600 (MDT)

> practical. Scalability and also privacy are a big concern here.

Yes. I would also add "the level of detail that providers would want
to see in those notifications" as a problem. IMO, these concerns
together make any general-purpose notification scheme impractical. If
the group decides to proceed anyway, we should talk to Hit Metering
(RFC 2227) folks for an advice how to avoid their protocol fate.

Hit Metering for caching is exactly what Notifications are for OPES.
Hit Metering is dead, AFAIK.

> your comments on this one!

Just to summarize for the record: IMO, we should satisfy 3.1
consideration by saying that "always-on tracing assists content
providers" and giving a few specific examples. We should not go beyond
that and we should seek ADs and the IAB opinion ASAP.

In other words, we would be saying that the IAB choice of
"Notification" label should be interpreted as "Notification
assistance" (making notifications meaningful) and should not be
interpreted as "Notification protocol". We go by the actual
consideration wording, ignore the label, and consider any IAB
motivation text as informative (not normative).

Again, once we decide what to do, we should contact ADs/IAB ASAP.

Alex.