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@xxxxxxxx]
> 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
>
>