[Webpush] Use Case related to subscription sets

Hervé Ruellan <herve.ruellan@crf.canon.fr> Wed, 18 November 2015 10:19 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 508C81B2BBF for <webpush@ietfa.amsl.com>; Wed, 18 Nov 2015 02:19:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.636
X-Spam-Level:
X-Spam-Status: No, score=-0.636 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 jMLPca9dAk8C for <webpush@ietfa.amsl.com>; Wed, 18 Nov 2015 02:19:39 -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 E42DB1ACEC0 for <webpush@ietf.org>; Wed, 18 Nov 2015 02:19:38 -0800 (PST)
Received: from mir-bsr.corp.crf.canon.fr (mir-bsr.corp.crf.canon.fr [172.19.77.99]) by inari-msr.crf.canon.fr (8.13.8/8.13.8) with ESMTP id tAIAJa47027759 for <webpush@ietf.org>; Wed, 18 Nov 2015 11:19:36 +0100
Received: from Antiope.crf.canon.fr (antiope.fesl2.crf.canon.fr [172.19.70.56]) by mir-bsr.corp.crf.canon.fr (8.13.8/8.13.8) with ESMTP id tAIAJatd032759 for <webpush@ietf.org>; Wed, 18 Nov 2015 11:19:36 +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; Wed, 18 Nov 2015 11:19:36 +0100
To: <webpush@ietf.org>
From: =?UTF-8?Q?Herv=c3=a9_Ruellan?= <herve.ruellan@crf.canon.fr>
Message-ID: <564C50B7.7070505@crf.canon.fr>
Date: Wed, 18 Nov 2015 11:19:35 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
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/IhJr4c7vqgbeI83kgVxfISTXlbQ>
Subject: [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 10:19:40 -0000

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