Re: [dispatch] Proposal for Per Resource Events Protocol

[[e-mail]]

[e-mail] (Dale R. Worley) writes:
> Now that you make me think of it, using SIP's SUBSCRIBE/NOTIFY mechanism
> (RFC 3265) for notifications might be a good solution.  It has been used
> extensively for over 20 years.  It has well-developed methods of dealing
> with NATs, aggregating notifications, etc.  For short and infrequent
> notifications, it uses UDP alone, so it doesn't maintain connections.
> And there are a lot of existing implementations.

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) 

Let me repeat again, SIP has a lot of implemented infrastructure to deal
with the various transport-related problems.

> From: Michael Toomim <[e-mail]>
> 
> This is why I think it's much more valuable to go all the way, and 
> standardize how mutations occur, rather than just provide a generic 
> event stream.

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.  But this approach seems to consistently run int
problems.

(1) Very often the "status" doesn't change much.  So it's considerably
more efficient to send just the changes in the status, "deltas" as it
were.

In SIP, various "event packages" have been modified to incorporate a
notion of "partial" and "full" updates.

(2) Often the desired semantics isn't to communicate current state but
to communicate that an (instantaneous) event has happened.

(3) If we want intermediaries to cache and update the resource itself,
rather than just a set of event notifications, or we want the
intermediary to be able to coalesce a series of notifications, we need a
defined generic format for partial updates that supports these
operations well.

> From: Michael Toomim <[e-mail]>
>
> 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.)

In any of these cases, we need a clean method for the subscriber and
notifier to keep synchronized where they are in the update stream.  In
SIP, any problems are usually cleaned up by a single, full update,
either requested by the subscriber or pushed by the notifier, and always
provided when the subscriber updates its end-of-subscription time.

Dale