Re: [Webpush] Use Case related to subscription sets

Hervé Ruellan <herve.ruellan@crf.canon.fr> Fri, 20 November 2015 10:40 UTC

Return-Path: <Herve.Ruellan@crf.canon.fr>
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 0685B1B2D12 for <webpush@ietfa.amsl.com>; Fri, 20 Nov 2015 02:40:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.535
X-Spam-Level:
X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585] autolearn=ham
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 pD7PnNz0L_I5 for <webpush@ietfa.amsl.com>; Fri, 20 Nov 2015 02:40:25 -0800 (PST)
Received: from inari-msr.crf.canon.fr (inari-msr.crf.canon.fr [194.2.158.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A8951B2D21 for <webpush@ietf.org>; Fri, 20 Nov 2015 02:40:24 -0800 (PST)
Received: from mir-msr.corp.crf.canon.fr (mir-msr.corp.crf.canon.fr [172.19.77.98]) by inari-msr.crf.canon.fr (8.13.8/8.13.8) with ESMTP id tAKAeM0F006358; Fri, 20 Nov 2015 11:40:22 +0100
Received: from Antiope.crf.canon.fr (antiope.fesl2.crf.canon.fr [172.19.70.56]) by mir-msr.corp.crf.canon.fr (8.13.8/8.13.8) with ESMTP id tAKAeMsN029800; Fri, 20 Nov 2015 11:40:22 +0100
Received: from timor.intra-usr.crf.canon.fr (172.20.5.234) by Antiope.crf.canon.fr (172.19.70.56) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 20 Nov 2015 11:40:21 +0100
To: Benjamin Bangert <bbangert@mozilla.com>
References: <564C50B7.7070505@crf.canon.fr> <CABp8EuLXNQWmc0mnt-m_vBQhPuhhef5GDgbrZdyM8TKUZv+GxQ@mail.gmail.com>
From: =?UTF-8?Q?Herv=c3=a9_Ruellan?= <herve.ruellan@crf.canon.fr>
Message-ID: <564EF895.4020200@crf.canon.fr>
Date: Fri, 20 Nov 2015 11:40:21 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <CABp8EuLXNQWmc0mnt-m_vBQhPuhhef5GDgbrZdyM8TKUZv+GxQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Originating-IP: [172.20.5.234]
X-ClientProxiedBy: Antiope.crf.canon.fr (172.19.70.56) To Antiope.crf.canon.fr (172.19.70.56)
Archived-At: <http://mailarchive.ietf.org/arch/msg/webpush/Rnn6vXBshFkK-xJei8ZkVnSTB_w>
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 10:40:27 -0000


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.

Its true that a Push Server putting a severe limit to the number of 
concurrent streams could also be a problem. Using several HTTP/2 
connections would probably not be a good solution: as Martin pointed 
out, this is not allowed by the HTTP/2 spec. Moreover, a Push Server 
strongly limiting the number of concurrent streams would also probably 
check that a client doesn't using several connections.

> When the device disconnects from the proxy, it would shut down that Push
> Service connection, and the device could query the Push Service directly.
>
> We currently field many connections from single IP's (proxies), and
> don't plan on enforcing connection limits for a single IP since mobile
> proxies are quite common.
>
> Cheers,
> Ben

Cheers,

Hervé

>
> On Wed, Nov 18, 2015 at 2:19 AM, Hervé Ruellan
> <herve.ruellan@crf.canon.fr <mailto:herve.ruellan@crf.canon.fr>> wrote:
>
>     Hi all,
>
>     We, at Canon, have a use case that is dependent on the rules
>     relating subscriptions and subscription sets.
>
>     In this use case, a device (e.g. a camera) connects to a push-server
>     through a proxy (e.g. a mobile phone). The communication between the
>     camera and the proxy uses an appropriate protocol (most possibly not
>     HTTP). A notification goes from the push-server to the proxy (acting
>     as a user-agent) through WebPush, then from the proxy to the device
>     through the appropriate protocol.
>
>     We plan to use the same proxy for several devices. We would like to
>     allow a device to change from a proxy to another seamlessly (e.g.
>     going from the mobile phone to a PC when coming home). When a device
>     moves from a proxy to another, we would like it to keep the same
>     subscription. This means that each device would need to have its own
>     subscription set to contain its subscription (or subscriptions).
>
>     Supporting this use case means that a client, here the proxy, is
>     allowed to have several subscription sets. However, this number
>     would be quite limited as we think only a few devices would connect
>     through the same proxy.
>
>     This scenario is of importance for us, and we would like the WG to
>     take it into account in the definition of subscription sets.
>
>     Cheers,
>
>     Hervé Ruellan
>
>     _______________________________________________
>     Webpush mailing list
>     Webpush@ietf.org <mailto:Webpush@ietf.org>
>     https://www.ietf.org/mailman/listinfo/webpush
>
>