Re: [Webpush] Use Case related to subscription sets

Benjamin Bangert <bbangert@mozilla.com> Wed, 18 November 2015 18:21 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 E98FE1A1B92 for <webpush@ietfa.amsl.com>; Wed, 18 Nov 2015 10:21:01 -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 HFi3NFVla-CV for <webpush@ietfa.amsl.com>; Wed, 18 Nov 2015 10:20:59 -0800 (PST)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 7C3FD1A1B8F for <webpush@ietf.org>; Wed, 18 Nov 2015 10:20:59 -0800 (PST)
Received: by wmec201 with SMTP id c201so85498647wme.1 for <webpush@ietf.org>; Wed, 18 Nov 2015 10:20:58 -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=PWTFc/KfCjB7V3ZTSejtD9hr8ggzOISVy1r7rOgwk9k=; b=WAXg5lADTioVonVxyx9vn5aUj4hcq8SH4DqvqlK+83A8UuSaPzD+uKssouVIOncf2H j8ZtapxSuKwws2VhXeWoYCtTtxfcBvqc5J917tZGXJAqBGgpExiztu0Zwe/nzMb7uVyl BxfZcmMhsijvHzK5HYRb36GiJmJ90PzCvhaBMdsjvKsxqhzJsaFRlMtCmcghQ7ehyzZe WBYQGnxWX46XIjuwIO8V0ZMNbCPKdorhoypm0j+Bj4dHtblG9z6RSaU6ZOsysXd5qfqp uVkdeMb1+BIzWP10705KP/8TTJlupjvN+Oqyqm1HZl/ui0j3yvk6Vuvjl8H5lUHqZsqL RFYA==
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=PWTFc/KfCjB7V3ZTSejtD9hr8ggzOISVy1r7rOgwk9k=; b=CDkWCqfZIyiqJHx0VQ3umKuvBYMiDsd+51w+o+YQD8rfk1RbWpDWsmeQDJnhpc9ms5 6SEgKOxAlThg1757BWb8vkb6JM+AQQ80iADkbWLT2PduAflDAmFO6pIbtRF1xGUJDznF pVv+CuAN5XinWaX6mD8bIa22MDOUORJUnRJS8jYTzmh7Bd26TAcOJuDPO7Kk+phVHCDL BZ0krc9e42FGekAC778ZoC9+jO6adVcWxih7b59Z57yY88gbgBBuaptmy5O13d8QpBf6 P4JKwlj/WQBgCMDchWzjaiHVpVhURwpLsW09M3cpJ3JBHXNrqTWo2PPWdj8NZpIu0r2/ Rw9w==
X-Gm-Message-State: ALoCoQn7hvUb5pcoqpC5siaXmHiRuF7gkh569xq+dM8v2SH2iWAZImcU++qmdaoEnUwlps9k3HoX
MIME-Version: 1.0
X-Received: by 10.194.8.227 with SMTP id u3mr3598943wja.38.1447870857849; Wed, 18 Nov 2015 10:20:57 -0800 (PST)
Received: by 10.27.155.196 with HTTP; Wed, 18 Nov 2015 10:20:57 -0800 (PST)
In-Reply-To: <564C50B7.7070505@crf.canon.fr>
References: <564C50B7.7070505@crf.canon.fr>
Date: Wed, 18 Nov 2015 10:20:57 -0800
Message-ID: <CABp8EuLXNQWmc0mnt-m_vBQhPuhhef5GDgbrZdyM8TKUZv+GxQ@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=047d7b5d9c0729ce510524d4b479
Archived-At: <http://mailarchive.ietf.org/arch/msg/webpush/KR-Ti3zgH-ndgFNXCMRifv0f4g8>
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: Wed, 18 Nov 2015 18:21:02 -0000

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.

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

On Wed, Nov 18, 2015 at 2:19 AM, Hervé Ruellan <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
> https://www.ietf.org/mailman/listinfo/webpush
>