Subject: Optional Notification?

From: Markus Hofmann <[email-masked]>
Date: Fri, 29 Aug 2003 12:09:00 -0400

Hi,

in addition to the points Abbie already mentioned, we also need to 
discuss the notion of having optional notifications being sent - This 
was something briefly mentioned at the Vienna meeting.

We already agreed that notifications should *not* be sent per default 
per message (scalability problems - notification aggregation was 
mentioned as possible approach to overcome this).

An idea might be to specify sort of a flag that would allow endpoints 
to signal that they want to receive an explicit notification if an 
OPES service is applied to this specific message. This would allow 
endpoints to do some (random?) probes. The flag could possibly also 
include how the notification should be sent (e.g. via email, or by 
issuing an HTTP request, or....)

Any thoughts?

-Markus

 > Hi,
 >
 > I am working my way through the tracing draft.
 > The next issue is section 2.1 "What is traceable in an OPES Flow?"
 >
 > The section is below
 >
 >
 >   o  The data consumer application end point MUST be able to identify
 >       the OPES processors that have acted on an application message.
 >
 >    o  The data consumer application end point SHOULD be able to 
identify
 >       OPES services (including callout services) that were performed on
 >       request/responses that are part of an application message.
 >
 >    o  TBD
 >
 >    o  TBD
 >
 >    For a given trace, an OPES entity involved in handling the
 >    corresponding application message is "traceable" or "traced" if
 >    information about it appears in that trace. OPES entities have
 >    different levels of traceability requirements. Specifically,
 >
 >    o  An OPES system MUST be traceable
 >
 >    o  An OPES processor SHOULD be traceable
 >
 >    o  An OPES service MAY be traceable
 >
 > I need feedback from the WG on this issue. Please send your remark ASAP
 >
 > Abbie
 >

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 29 Aug 2003 10:46:17 -0600 (MDT)

On Fri, 29 Aug 2003, Markus Hofmann wrote:

> discuss the notion of having optional notifications being sent -
> This was something briefly mentioned at the Vienna meeting.
>
> We already agreed that notifications should *not* be sent per
> default per message (scalability problems - notification aggregation
> was mentioned as possible approach to overcome this).
>
> An idea might be to specify sort of a flag that would allow
> endpoints to signal that they want to receive an explicit
> notification if an OPES service is applied to this specific message.
> This would allow endpoints to do some (random?) probes. The flag
> could possibly also include how the notification should be sent
> (e.g. via email, or by issuing an HTTP request, or....)

We can say that the value of this optional flag/field is a URI that
identifies notification method plus parameters. If a processor
understands the method, it would be able to further decode the field
and send a notification. This way, we only have to document the field
name and format for ever application protocol. We do not have to
invent the notification protocol. For example, we can document the
following HTTP header:

	OPES-Notify: URI *(pname=pvalue)

On the other hand, the utility of the above approach is going to be
rather low. An alternative is for whoever writes the notification
protocol is to document the above approach OR invent its own, specific
to that protocol. For example,

	My-OPES-Notify: foo=bar q=0.5

(which simply moves URI standardization problem to the header name
standardization problem).

HTH,

Alex.

---

From: Markus Hofmann <[email-masked]>
Date: Fri, 29 Aug 2003 13:01:27 -0400

Alex Rousskov wrote:

> invent the notification protocol. 

Exactly, that's what I had in mind.

> For example, we can document the
> following HTTP header:
> 

I don't think we want to start specifying our own notification 
protocol. Using the URI option for now, but allowing someone to 
specify - if needed - a notification protocol later on might be the 
way to go.

Anyone else any thoughts? Should we include "OPES-Notify:" HTTP header 
in our OCP/HTTP bindings document?

-Markus