Re: [dispatch] Proposal for Per Resource Events Protocol

[Michael Toomim <[e-mail]>]

Dale:
>> Now that you make me think of it, using SIP's SUBSCRIBE/NOTIFY mechanism
>> (RFC 3265) for notifications might be a good solution.  ...
> I started looking into this and discovered that we already have such a
> mechanism:
>
> 5989 A SIP Event Package for Subscribing to Changes to an HTTP Resource.
>       A.B. Roach. October 2010. (Format: TXT, HTML) (Status: PROPOSED
>       STANDARD) (DOI: 10.17487/RFC5989)

These are excellent finds!

Thank you, Dale. I've been making a list of RFCs doing state 
synchronization, so that we can generalize them into a single 
interoperable protocol. This is quite helpful to discover!

And now just a couple questions:

Dale:

> One thing I've noticed with subscribe/notify mechanisms is that the
> initial definition tends to be oriented toward sending "status"
> messages, that is, each notification is the current status of the
> resource being watched.

By "status" do you mean the current "state"?

If my resource is a text document, do you mean sending the entire string 
of the document each time the user types a char?

> (2) Often the desired semantics isn't to communicate current state but
> to communicate that an (instantaneous) event has happened.
Can you give some examples of events that you've encountered that do not 
imply a change to the state? I usually find that events /are/ 
communicating changes to state, even though it might not be obvious what 
the state is.
>> We call this format the Range Patch
> You probably want to add an "XML" type of range specification, given the
> amount of XML that is used to deliver state information.  (Certainly,
> it's popular in SIP.)

Yes! Definitely.

XPath could be a starting point, but we'd ideally want something that 
also allows to specify a range of children, and not just a single child. 
It's nice to be able to say that children 4 through 10 got replaced, 
rather than have to issue 6 separate patches, with one for each child.