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

Elio Damaggio <> Tue, 24 February 2015 19:01 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C326A1A887A for <>; Tue, 24 Feb 2015 11:01:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.798
X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id r8ACJ-CH1E5R for <>; Tue, 24 Feb 2015 11:01:17 -0800 (PST)
Received: from ( [IPv6:2a01:111:f400:fc10::1:767]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7672D1A8878 for <>; Tue, 24 Feb 2015 11:01:17 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 24 Feb 2015 19:00:59 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 24 Feb 2015 19:00:58 +0000
Received: from ([]) by ([]) with mapi id 15.01.0099.004; Tue, 24 Feb 2015 19:00:58 +0000
From: Elio Damaggio <>
To: Martin Thomson <>, Benjamin Bangert <>
Thread-Topic: [Webpush] Broadcast (was Re: webpush for http2 -02)
Thread-Index: AQHQR0dRdjQKEVJkfkiNVlpzjghP+p0AOG1A
Date: Tue, 24 Feb 2015 19:00:58 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: [2001:4898:80e8:ee31::2]
authentication-results: spf=none (sender IP is );
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN1PR0301MB0626; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN1PR0301MB0611;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005004); SRVR:BN1PR0301MB0626; BCL:0; PCL:0; RULEID:; SRVR:BN1PR0301MB0626;
x-forefront-prvs: 04976078F0
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(189002)(199003)(3905003)(377454003)(13464003)(62966003)(77156002)(106356001)(106116001)(561944003)(105586002)(64706001)(99286002)(101416001)(97736003)(54356999)(76176999)(76576001)(50986999)(33656002)(46102003)(122556002)(87936001)(86612001)(2656002)(74316001)(15975445007)(86362001)(102836002)(68736005)(19580405001)(2950100001)(19580395003)(2900100001)(40100003)(92566002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR0301MB0626;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2015 19:00:58.2147 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR0301MB0626
Archived-At: <>
Cc: "" <>
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 19:01:20 -0000

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.


-----Original Message-----
From: Webpush [] On Behalf Of Martin Thomson
Sent: Thursday, February 12, 2015 8:41 PM
To: Benjamin Bangert
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