Re: [Webpush] Use Case related to subscription sets

Benjamin Bangert <bbangert@mozilla.com> Mon, 23 November 2015 17:31 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 BDC0A1A92EB for <webpush@ietfa.amsl.com>; Mon, 23 Nov 2015 09:31:20 -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 i8jvuNpHioyB for <webpush@ietfa.amsl.com>; Mon, 23 Nov 2015 09:31:17 -0800 (PST)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 592D81A92EF for <webpush@ietf.org>; Mon, 23 Nov 2015 09:31:17 -0800 (PST)
Received: by wmww144 with SMTP id w144so106274227wmw.1 for <webpush@ietf.org>; Mon, 23 Nov 2015 09:31:15 -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=4YJxVlTCfqyhYB25x22kaPdW4I0gzRX8MT4JC/sbbEc=; b=UNHZ+IHAEzheFRLdZef6+wI8nx8H9bVCRwYszbJFSQqHRa5hfYrUHs8AVjkEs1cUvP GT+07eSu8HVIso4GLXgZxSzoS4Yi4VfWksKEe4HpQKaQ+Ly0xfcoQ59o3IBGqNhJ2IZf 796GSdMsamEbf0zZk1Wd27tPYTgdLP9Awd2C2HYcvLM9NKGK4mt2ZVzyUBOjc6OYLtCA 89TIBgEj4R3x5tQyn4UJKLjKjQMVl9FPJD5iHLR8A7xGodu3OGJMITkYQXUu3Jnlp6Xt akiNzubLFqtJqL9jgXNsFUYX+0o52BgC9KRtOFdnG+qIHylTGTNkRUJnuKD7Dwc7bPAD v0qA==
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=4YJxVlTCfqyhYB25x22kaPdW4I0gzRX8MT4JC/sbbEc=; b=aEsSwbfgNAMgKMVw6vbknWoS3yq8u9D3dyQc96L30y3RgNueDQAOgKcaQBL6JQX4IQ AJlkVPZMp55L/rXp8sdliQLCTl4xigv1fcjynbypsj2PSb8VxOBmdA3h3NlXZO4+O2zg eAII9k/PHF84YV4xzObt/s2Qc2PBhtoxRyV/IYSPfmy3GeP5QFZnVxWuHRYQk92/Dh+C 5wUzYROufBelzJciaYqRM+nvTmfMQTl6W+qLDBJ38M5vLnffYH75CvRWDyNOiFTV5apg vCheWNMgBpwnNnPpy/h5Al6EjvGq5wfbcPRvIiXUzsjCDCEWo9sHyc+Ni9yf5Ihhiqdb B/9Q==
X-Gm-Message-State: ALoCoQkAGLM0zAw0P0IlqbR9M/tDDmPm0j7udtIZJf291z2TZUJjbFNcGZMiVF9KSBoaScLFVkPi
MIME-Version: 1.0
X-Received: by 10.28.127.141 with SMTP id a135mr16891152wmd.69.1448299875530; Mon, 23 Nov 2015 09:31:15 -0800 (PST)
Received: by 10.27.179.194 with HTTP; Mon, 23 Nov 2015 09:31:15 -0800 (PST)
In-Reply-To: <5652E2CD.8090709@crf.canon.fr>
References: <564C50B7.7070505@crf.canon.fr> <CABp8EuLXNQWmc0mnt-m_vBQhPuhhef5GDgbrZdyM8TKUZv+GxQ@mail.gmail.com> <564EF895.4020200@crf.canon.fr> <CABp8Eu+OsXiEAsxOQpV_O-bF2o21upbJ14x8bCO=Y9TfgXOw2A@mail.gmail.com> <BY2PR0301MB06474FB76B480F37957A531A831A0@BY2PR0301MB0647.namprd03.prod.outlook.com> <5652E2CD.8090709@crf.canon.fr>
Date: Mon, 23 Nov 2015 09:31:15 -0800
Message-ID: <CABp8EuKoWQ+JJdbqcTAge7wK=69P4M-e9kSZjoRW04yYvardUw@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=001a11420af49c1224052538979f
Archived-At: <http://mailarchive.ietf.org/arch/msg/webpush/bHeDEUnG2hC2tn_KMvHtzFedNpw>
Cc: Brian Raymor <brian.raymor@microsoft.com>, "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: Mon, 23 Nov 2015 17:31:20 -0000

On Mon, Nov 23, 2015 at 1:56 AM, Hervé Ruellan <herve.ruellan@crf.canon.fr>;
wrote:

>
> On 20/11/15 18:49, Brian Raymor wrote:
>
>>
>> On Fri, Nov 20, 2015 at 8:43 AM, Benjamin Bangert
>> <bbangert@mozilla.com>; wrote:
>> > 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.
>>
>> The mobile phone ("proxy") acts as the user agent in this case with a
>> HTTPS connection to the push service. A different protocol than HTTP
>> may be required between phone and the camera. Sounds similar to a
>> field gateway scenario?
>>
>
> Yes, the HTTPS connection is between the mobile phone and the push server.
> And another protocol is used between the camera and the phone.
>
> > 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.
>>
>> Regarding "unsecured", Section 9 requires HTTPS - This protocol MUST
>> use HTTP over TLS [RFC2818].
>>
>
> For our scenario, we would like to be able to use a generic push server. I
> agree that the spec supports the use-case, but we would also like the
> implementations to support the use-case.
> A short mention of the use-case in the spec would be really helpful. The
> consequences for an implementation would be to allow a user agent to create
> a *few* subscription sets, and not limit it to *1*, and also to allow a
> user agent to open a *few* streams to subscription resources.


Implementation-wise, the only reason a client using our service is
restricted to one active subscription set at a time is due to the
concurrent stream limit setting. It is however, just that, a setting.

Someone could use our eventual implementation and set the stream limit
setting to whatever they want to support at scale. Our specific deployment
will restrict our clients to 2 concurrent streams via this setting.

I'm assuming there will be multiple implementations out there to choose
from if you don't want to implement your own, and many/most of them will
likely implement the ability to restrict subscription sets in a similar
manner... merely by setting a config flag.

Cheers,
Ben