[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Optional Notification?


Alex Rousskov wrote:

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.

Exactly, that's what I had in mind.

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

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