IETF Logo Mail Archive

Re: [Webpush] Use Case related to subscription sets

Martin Thomson <martin.thomson@gmail.com> Wed, 18 November 2015 19:31 UTC

Return-Path: <martin.thomson@gmail.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 D10B71A9053 for <webpush@ietfa.amsl.com>; Wed, 18 Nov 2015 11:31:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level:
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 cfqqPzwTasxg for <webpush@ietfa.amsl.com>; Wed, 18 Nov 2015 11:31:13 -0800 (PST)
Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::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 782BA1A9037 for <webpush@ietf.org>; Wed, 18 Nov 2015 11:31:13 -0800 (PST)
Received: by iofh3 with SMTP id h3so65077930iof.3 for <webpush@ietf.org>; Wed, 18 Nov 2015 11:31:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ef8QSYbuTPcMaWT/jrzwL4UHH2Soz1QVu8zoAvwd024=; b=WT+KOgqdzNuEcCm8EMSmVGsdVkKyGA0SYgHw6NcpvegdMrbeklXNOVle0GpK9URoF3 6cdZNrdp0UMWRN2C2/aJHgLKQlHIR9btc/IX5c5CF4MH1zKtIJg5IQv+g5rnEOoq6jSt laDprjMXLGEUxE0/QCGqo71nswV+5sxEEYrws+YF7orrwdgNPkbN2aJ/ER2ZBreaL3hQ 4U6fqvqAP4GOmy1CIQV6zfhe0NDLb8kUuArkU2K/djXoSu7vN3rfTU22n0NaR3Cn+D6/ 20GsUzFIPF3CovEXl1vas4+Q29Fuy5kXkBgTYWRj2VbhneRT87YeF+5a11XbRI9Wf6ac +jIw==
MIME-Version: 1.0
X-Received: by 10.107.33.203 with SMTP id h194mr4324980ioh.108.1447875072651; Wed, 18 Nov 2015 11:31:12 -0800 (PST)
Received: by 10.36.155.139 with HTTP; Wed, 18 Nov 2015 11:31:12 -0800 (PST)
In-Reply-To: <CABp8EuLXNQWmc0mnt-m_vBQhPuhhef5GDgbrZdyM8TKUZv+GxQ@mail.gmail.com>
References: <564C50B7.7070505@crf.canon.fr> <CABp8EuLXNQWmc0mnt-m_vBQhPuhhef5GDgbrZdyM8TKUZv+GxQ@mail.gmail.com>
Date: Wed, 18 Nov 2015 11:31:12 -0800
Message-ID: <CABkgnnVXoGKngS1MbSpKv76DC+hbd6wN5k=zBezbVZv=0=UbOA@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Benjamin Bangert <bbangert@mozilla.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/webpush/mHe4PVGRqKbXia0LHY1hrzmKjjw>
Cc: "webpush@ietf.org" <webpush@ietf.org>, Hervé Ruellan <herve.ruellan@crf.canon.fr>
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 19:31:15 -0000

On 18 November 2015 at 10:20, Benjamin Bangert <bbangert@mozilla.com> 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 HTTP/2 RFC is pretty clear about having multiple connections.

A very simple solution here is to have the client use some sort of
explicit correlator, as we have discussed.  Then there is no need for
multiple connections.  Of course, if the push service were disinclined
to permit multiple subscription sets then this wouldn't work, but
that's probably OK here.

n.b., the concurrent stream limit isn't a good signal to use for
negotiation, it's only a way of ensuring compliance in the presence of
bad actors.

v2.23.0 | Report a Bug | By Email