Re: [Webpush] Broadcast (was Re: webpush for http2 -02)

Martin Thomson <> Tue, 24 February 2015 21:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 865D51A8928 for <>; Tue, 24 Feb 2015 13:30:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7MgDNfrAUtKs for <>; Tue, 24 Feb 2015 13:30:19 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9B1CE1A893E for <>; Tue, 24 Feb 2015 13:30:19 -0800 (PST)
Received: by with SMTP id x69so21905704oia.5 for <>; Tue, 24 Feb 2015 13:30:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ekntwOj2cZwkGsXijSCgmsYNiotZgps4vT9YrooRL6Q=; b=Imw9bekQWlE4buWw8gDaS0d0zbKrsL2ugdRwB7O/BwrhUhXdBvogZWClaBDmYtHl/s pEeCmSDp7giLSYUX5gWIUOkj5W67+PxLdQWMZoEaAuuzQzI22AgjwqfEYIQYbLYqgR/k NWsRD99iAcVfuaP8a7+7AmZjg3NNd33EZdz+eFbZYINTfiC0qWFnnbIATDIBPcBCZ4Pz 0Qv/DeGj6Cp2xLKtyTE5M7klT8kR/foKhmfTE+zRd1BqKpNqUZzAfOqerVjfrmZguayb 1CN0wrQneG3+trq0R3mM9YZ+hHN4rzgJywOcNnlIKgYwxksGzRA/7WqmWYAEgxNe3Kh0 YJBg==
MIME-Version: 1.0
X-Received: by with SMTP id s188mr12129059oib.94.1424813418844; Tue, 24 Feb 2015 13:30:18 -0800 (PST)
Received: by with HTTP; Tue, 24 Feb 2015 13:30:18 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Wed, 25 Feb 2015 10:30:18 +1300
Message-ID: <>
From: Martin Thomson <>
To: Elio Damaggio <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: Benjamin Bangert <>, "" <>
Subject: Re: [Webpush] Broadcast (was Re: webpush for http2 -02)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of potential IETF work on a web push protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Feb 2015 21:30:22 -0000

The question here for me is how much a protocol can enable this and
how much is best left to services like Notification Hubs, etc...
Those services are offered to those who wish to generate push messages
and as such are less encumbered by a need for standardization.  In
fact, much of their value-add derives from the flexibility and
expressiveness of their APIs. They benefit from standardization of a
push protocol in that their downstream interactions become
homogeneous, but a standard for aggregation might only act as a

The intent with the aggregation draft I described was to allow a
single push service provider to provide aggregation capabilities
across its endpoints.  That leaves open the possibility of an
aggregator that operates across multiple push services (like the
aforementioned),  It's hard to see how that could be driven from
anything but the application side, where standards are less urgent.

At this stage, my proposal seems more like a half-measure, and I'm
reconsidering whether there is anything worth standardizing on the
aggregation front.  Do you think that there is something here worth

Either way, I think that our efforts are best concentrated on
completing the basic protocol first.

On 25 February 2015 at 08:00, Elio Damaggio <> wrote:
> Hi Martin,
> Continuing the discussion on broadcast, from our experience of designing and operating Azure Notification Hubs, we realized that the major hurdles for users of a push aggregation system are the following:
> 1.      Push aggregation have to be regularly synched with other data stores.
> Aggregation sets are application data, e.g. list of people in "platinum" status, list of users following a certain sport team, enterprise or social groups. The protocol has to be amenable to synching operations. In our experience forcing explicit management of the topics (creation and deletion) hampers these operations compared to more flexible approaches where tags are associated to device tokens. Azure Notification Hubs is not the only system that uses this kind of grouping; Urban Airship and Parse (now Facebook) have a similar systems. Reference:
> 2.      Topic updates happen from both device and topic perspectives.
> This means that it should be possible to say "add/remove topics A,B, and C to this user", and also "add/remove users 1,2, and 3 to/from this topic". In a system where both of this kind of updates happen concurrently, having to explicitly keep track of topic creation and deletion is burdensome.
> 3.      Sending to dynamic sets.
> Given the effort that goes into synching topics between the push system and other stores, it is usually preferable for both the users and the implementer of the push aggregation system to allow Boolean expressions on topics to be used as targets. Consider a sports application that sends a reminder to everyone in Boston about a game between the Red Sox and Cardinals. If the client app registers tags about interest in teams and location, then the notification should be targeted to everyone in Boston who is interested in either the Red Sox or the Cardinals. This condition can be expressed with the following Boolean expression: (follows_RedSox || follows_Cardinals) && location_Boston
> Notification Hubs, Urban Airship and Parse all support this feature. Even if this feature is not required to be implemented in all aggregation servers, it follows that a push endpoint, that is independent of a specific topic and that takes a target topic (or Boolean expression on topics), is probably better suited than a topic-specific push URL.
> Elio
> -----Original Message-----
> From: Webpush [] On Behalf Of Martin Thomson
> Sent: Thursday, February 12, 2015 8:41 PM
> To: Benjamin Bangert
> Cc:
> Subject: [Webpush] Broadcast (was Re: webpush for http2 -02)
> On 13 February 2015 at 12:23, Benjamin Bangert <> wrote:
>> Section 2:
>> - The diagram is good, but I think adding one variant for broadcast
>> messages would be good. I could see a crypto secured broadcast working like so:
>>   - Broadcast Subscribe (In contrast to normal subscribe)
>>   - Browser Agent makes Provide Subscription request to Application,
>> including request (flag) to be issued the broadcast key
>>   - Browser stores the broadcast key with the new subscription (rather
>> than generating its own key)
> I have proposed a separate document with a different model for broadcast.  In that, clients/browsers/UAs don't drive the subscription to a broadcast, that broadcast is managed by the application sender.
> I got the sense that there wasn't a whole lot of interest in a broadcast system in the initial stages.
> The advantage there is that you don't have to worry about clients having to be able to connect to push services that they might not have a pre-existing relationship with (and therefore federate authorization).  The disadvantage is that it drives more of the responsibility for push fanout onto the application server.
> In your proposal here, how do you see the broadcast subscription being identified and managed?  Would an application request the creation of one and then distribute it to its clients to subscribe to?
> _______________________________________________
> Webpush mailing list