Re: [Webpush] Use Case related to subscription sets

Benjamin Bangert <bbangert@mozilla.com> Fri, 20 November 2015 16:42 UTC

Return-Path: <bbangert@mozilla.com>
X-Original-To: webpush@ietfa.amsl.com
Delivered-To: webpush@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B26D61B3898 for <webpush@ietfa.amsl.com>; Fri, 20 Nov 2015 08:42:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level:
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pHmvydcucvKx for <webpush@ietfa.amsl.com>; Fri, 20 Nov 2015 08:42:27 -0800 (PST)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DFEA1B3899 for <webpush@ietf.org>; Fri, 20 Nov 2015 08:42:23 -0800 (PST)
Received: by wmww144 with SMTP id w144so28337108wmw.0 for <webpush@ietf.org>; Fri, 20 Nov 2015 08:42:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WOKBOAFJIN+WWheZBAIDbyT48Pg2EHbnCuwffMtuacw=; b=Ud4Qm8m4PuWKVklnHKaU2Dhs8cVh/VQGIuXV2IAjj8RuUmyVT+Zyykm7BDNFona5AR AkpwfdJxs+HRwogzCnpmbqGlxEY0YTfeclziLfBXZG53Ze4C9re4O2mwGBhZUs3LAuSZ ooJSVZi4vP8AcLK64xWFPiK3n+6KIaVtaFdW4Wt+e80FrMS1hK7xX3oCOFoCMgLn92ug tdUnkusWidiIEHICchtRCkZUmNSaYsxyizi/HhcO0TpJGf6k+CufaVX7GAe/IHPGAuAy /XiNvP53j4NvTWNq9Ex7Xy+lzku+KD7GCj4w4ITuT6FzfTjzoYfITdN5U0JNek0ZSg7n +c9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WOKBOAFJIN+WWheZBAIDbyT48Pg2EHbnCuwffMtuacw=; b=ZG9aVkGGfr5uzVvjCOqNbut5SEbz7+bkI/BFcAOSxRkEH8v0nAA09dR6GLmPqE8JIS e8XSZhSs7dIyg3UW4Zm1DBtAnpZDAIixHchGbaSHRJJM9eRwfxLQ9QYUndPcTeZ2bTII W1UPWND5RLD34P1g69JzdHnKd0BSP+KsZ+UWDW+I/CIeW7bVc/5udUDJra6IyHXbtFIV gxYwbmuUxXHZO46EamnpH3UHOhcNkr9JdrHNl+lA24Iieqo/+IbmbWZwuehKIU7ZUcAz nPFrqMxsCrY0IEy75CdoUI0plQ2fZKmLGnBPhrWsmKRmW3zP9Z5KywVM/nA5FbNvtyye ZCGA==
X-Gm-Message-State: ALoCoQky9DoiaFKvPcdQGOJ2zD8KPD1vhG6/NLJ6BHO7EYfxRMCpKkGOjGAJTkF3pFHSYtW1POsZ
MIME-Version: 1.0
X-Received: by 10.194.175.230 with SMTP id cd6mr9972303wjc.100.1448037741928; Fri, 20 Nov 2015 08:42:21 -0800 (PST)
Received: by 10.27.179.194 with HTTP; Fri, 20 Nov 2015 08:42:21 -0800 (PST)
In-Reply-To: <564EF895.4020200@crf.canon.fr>
References: <564C50B7.7070505@crf.canon.fr> <CABp8EuLXNQWmc0mnt-m_vBQhPuhhef5GDgbrZdyM8TKUZv+GxQ@mail.gmail.com> <564EF895.4020200@crf.canon.fr>
Date: Fri, 20 Nov 2015 08:42:21 -0800
Message-ID: <CABp8Eu+OsXiEAsxOQpV_O-bF2o21upbJ14x8bCO=Y9TfgXOw2A@mail.gmail.com>
From: Benjamin Bangert <bbangert@mozilla.com>
To: =?UTF-8?Q?Herv=C3=A9_Ruellan?= <herve.ruellan@crf.canon.fr>
Content-Type: multipart/alternative; boundary=089e013cc3003ac7b50524fb8fbc
Archived-At: <http://mailarchive.ietf.org/arch/msg/webpush/BSaasC0MdGHKLrY1yFJMsXkvoKs>
Cc: "webpush@ietf.org" <webpush@ietf.org>
Subject: Re: [Webpush] Use Case related to subscription sets
X-BeenThere: webpush@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of potential IETF work on a web push protocol <webpush.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/webpush>, <mailto:webpush-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/webpush/>
List-Post: <mailto:webpush@ietf.org>
List-Help: <mailto:webpush-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/webpush>, <mailto:webpush-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Nov 2015 16:42:29 -0000

On Fri, Nov 20, 2015 at 2:40 AM, Hervé Ruellan <herve.ruellan@crf.canon.fr>
wrote:

>
>
> On 18/11/15 19:20, Benjamin Bangert wrote:
>
>> I'm not sure any changes would be needed as is. If a Push Server is
>> limiting the concurrent streams, the proxy could just open several
>> connections, one for each device its proxying for that devices
>> subscription set.
>>
>
> The main concern for us is a Push Server enforcing only one subscription
> set for a client: in our use case, this client would be the proxy (from the
> WebPush point of view). However, we could have several devices "hidden"
> behind this proxy, and we want to keep them independent.
>

If a Push Server chooses to constrain concurrent streams, that's entirely
within its right to do so. One solution for this use-case may be to have
the proxy register the subscription sets for each of the devices using it,
then switch to a polling model, polling each registered subscription set in
turn periodically, though that could bump into request limiting.

If a proxy is going to put additional load on a Push Server, then the
people running the proxy should run the Push Server as well so that they
can shoulder the burden of their use.

Since most push servers, as far as I know, will be using SSL, I don't know
how a proxy could even function since it would need to MITM the secured
connection which is obviously not good.

Either way, this situation and use-case seems accounted for by the spec as
it is, since those wishing to handle this scenario may run their own Push
Server without a low concurrent stream max, and unsecured so that a proxy
may function.

Cheers,
Ben