On Fri, 29 Aug 2003, Markus Hofmann wrote:
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....)
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.