Re: [Webpush] Use Case related to subscription sets

Benjamin Bangert <> Mon, 23 November 2015 17:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BDC0A1A92EB for <>; Mon, 23 Nov 2015 09:31:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.978
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i8jvuNpHioyB for <>; Mon, 23 Nov 2015 09:31:17 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 592D81A92EF for <>; Mon, 23 Nov 2015 09:31:17 -0800 (PST)
Received: by wmww144 with SMTP id w144so106274227wmw.1 for <>; Mon, 23 Nov 2015 09:31:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id a135mr16891152wmd.69.1448299875530; Mon, 23 Nov 2015 09:31:15 -0800 (PST)
Received: by with HTTP; Mon, 23 Nov 2015 09:31:15 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Mon, 23 Nov 2015 09:31:15 -0800
Message-ID: <>
From: Benjamin Bangert <>
To: =?UTF-8?Q?Herv=C3=A9_Ruellan?= <>
Content-Type: multipart/alternative; boundary=001a11420af49c1224052538979f
Archived-At: <>
Cc: Brian Raymor <>, "" <>
Subject: Re: [Webpush] Use Case related to subscription sets
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of potential IETF work on a web push protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 23 Nov 2015 17:31:20 -0000

On Mon, Nov 23, 2015 at 1:56 AM, Hervé Ruellan <>

> On 20/11/15 18:49, Brian Raymor wrote:
>> On Fri, Nov 20, 2015 at 8:43 AM, Benjamin Bangert
>> <> 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.