Re: [dispatch] Proposal for Per Resource Events Protocol Wed, 16 August 2023 19:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C9644C1519A5 for <>; Wed, 16 Aug 2023 12:05:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.993
X-Spam-Status: No, score=-5.993 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_SOFTFAIL=0.665, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id s8I_a9O_35Hg for <>; Wed, 16 Aug 2023 12:05:12 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EBD53C15154F for <>; Wed, 16 Aug 2023 12:05:11 -0700 (PDT)
Received: from ([]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 256/256 bits) (Client did not present a certificate) by with ESMTP id WH9jqu8XIprSIWLnSqDVHY; Wed, 16 Aug 2023 19:03:10 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20211018a; t=1692212590; bh=2VOmFOqkczprKBX6giqFISOIZgwnxBGZ+jrIvSMLjEI=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID:Xfinity-Spam-Result; b=P+gFxTueS/HoOndmNLP887H/bGR2U0cDkeytrvm9kqN3uK1N2l4ERUf+Gd/Jjswra t336Ebi2kjXcC8cWdLZr8VX+a1DyZ8IqJn1ySL7ES0vWiwAzaI1aitkeNyxL0TodqF 6baPRxqgBRGY/SeX9yj/Z0y1r0CIZA1qspsTwZFpGJrcW3hJ+uQyfWoWF8t2YuUW6i NZarxIy3XVKvGh57ZzQZaVgiNj7rmLPkuCqc7wLZvtEjb18+3uLfF6FpTPOjmZZy1k QXXdhj2CZqBgdwfFjalYn/bL28XR9UfqRZJq50dojbwsjMirGacgv4H1ryCfmRzT/f xm5MXqH8b8lHg==
Received: from ([IPv6:2601:192:4a00:430::67f6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 256/256 bits) (Client did not present a certificate) by with ESMTPA id WLnQqDQJxp9FsWLnRqfgW3; Wed, 16 Aug 2023 19:03:10 +0000
Received: from (localhost []) by (8.16.1/8.16.1) with ESMTPS id 37GJ38Dd161473 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 16 Aug 2023 15:03:08 -0400
Received: (from worley@localhost) by (8.16.1/8.16.1/Submit) id 37GJ37BT161470; Wed, 16 Aug 2023 15:03:07 -0400
X-Authentication-Warning: worley set sender to using -f
Cc: Rahul Gupta <>, Michael Toomim <>, Tim Bray <>
In-Reply-To: <> (
Date: Wed, 16 Aug 2023 15:03:07 -0400
Message-ID: <>
Archived-At: <>
Subject: Re: [dispatch] Proposal for Per Resource Events Protocol
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: DISPATCH Working Group Mail List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 16 Aug 2023 19:05:15 -0000 (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

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

(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

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