All,
I think we can mention that, but I really doubt that we should get involved
in it.
Aptional Notification in my opnion should be out of scope.
Abbie
-----Original Message-----
From: Markus Hofmann [mailto:markus(_at_)mhof(_dot_)com]
Sent: Friday, August 29, 2003 1:01 PM
To: OPES Group
Subject: 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