Re: [Webpush] Use Case related to subscription sets

Brian Raymor <Brian.Raymor@microsoft.com> Fri, 20 November 2015 17:49 UTC

Return-Path: <Brian.Raymor@microsoft.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 1C81F1B3A5F for <webpush@ietfa.amsl.com>; Fri, 20 Nov 2015 09:49:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.702
X-Spam-Level:
X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, 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 g6UAIdk5a16q for <webpush@ietfa.amsl.com>; Fri, 20 Nov 2015 09:49:54 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0774.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:774]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADB1B1B3A61 for <webpush@ietf.org>; Fri, 20 Nov 2015 09:49:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7BUCsMEZRL2PzAiSZo5dobN1avULZ3pfbjdYv7zOcBM=; b=El1VeWjgJ/4/jhf9JBxJdbABrqooTpWli/DZUWrK+SThWVYNC2zgsDOsEEfN4vgSM3nSQVXgcNYMgqKJO3RrW2oCdv5H23/jw6AXEC/Zaq1MeYQ5abBQFVtID2IAkMddp0EIwnu4kj2hxtyI6Y3hJWFlCvPBmUwYMb22HKXZCNs=
Received: from BY2PR0301MB0647.namprd03.prod.outlook.com (10.160.63.14) by BY2PR0301MB0648.namprd03.prod.outlook.com (10.160.63.140) with Microsoft SMTP Server (TLS) id 15.1.325.17; Fri, 20 Nov 2015 17:49:33 +0000
Received: from BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) by BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) with mapi id 15.01.0325.019; Fri, 20 Nov 2015 17:49:33 +0000
From: Brian Raymor <Brian.Raymor@microsoft.com>
To: Benjamin Bangert <bbangert@mozilla.com>, Hervé Ruellan <herve.ruellan@crf.canon.fr>
Thread-Topic: [Webpush] Use Case related to subscription sets
Thread-Index: AQHRIeqmRM5eVbt/pk6X9PcfmrGbf56iF+eAgAKj+YCAAGUkgIAADnDw
Date: Fri, 20 Nov 2015 17:49:33 +0000
Message-ID: <BY2PR0301MB06474FB76B480F37957A531A831A0@BY2PR0301MB0647.namprd03.prod.outlook.com>
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>
In-Reply-To: <CABp8Eu+OsXiEAsxOQpV_O-bF2o21upbJ14x8bCO=Y9TfgXOw2A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brian.Raymor@microsoft.com;
x-originating-ip: [2601:600:8000:5a8:f944:677b:e7d6:ab35]
x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0648; 5:PlkicXnhsCILeOwOP66B9klh9thM4fxg4YmXVeAuO9GZjDlmHXEvliUNGOMAZHMK+raDWOoeFuie5qa3xuWzK7/dImo2wHAobag6w10kcecd6NSq2E0yXnWVD37CqPIa34y2fP7sVFrRMY9zMRc6cA==; 24:mje8RMLPa2gX7Z1kN7s2uA2LDtIKmLH9K3L5xPwpw3Z4OPJUmka2QF1KhXYOndZUkVwQWcQKIFbVFTU49wpnORHfIjWrA0gcjSejCJwmg3k=; 20:idr3cfzo1kMzA1GrdA6xk8GKBOJwNoNaSPLx8ncp+KsDGt1QTfmX8GE0znLAv4NEL+zqPeVB/82m1qKtizZAYw==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0301MB0648;
x-microsoft-antispam-prvs: <BY2PR0301MB064854EAD85196AA5925B041831A0@BY2PR0301MB0648.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(10201501046)(61426024)(61427024); SRVR:BY2PR0301MB0648; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0648;
x-forefront-prvs: 07665BE9D1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(24454002)(189002)(377454003)(76176999)(101416001)(93886004)(5007970100001)(77096005)(102836003)(92566002)(33656002)(74316001)(189998001)(122556002)(2900100001)(99286002)(5002640100001)(10290500002)(5005710100001)(5008740100001)(106356001)(97736004)(8990500004)(106116001)(11100500001)(10400500002)(586003)(105586002)(5001770100001)(81156007)(5004730100002)(10090500001)(6116002)(5001960100002)(2950100001)(5003600100002)(86612001)(19580395003)(87936001)(19580405001)(76576001)(50986999)(54356999)(40100003)(86362001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0648; H:BY2PR0301MB0647.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2015 17:49:33.3155 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0648
Archived-At: <http://mailarchive.ietf.org/arch/msg/webpush/EhZDYXwGLp6yuEWjp_4yC8CyYE0>
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: Fri, 20 Nov 2015 17:49:58 -0000

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?

> 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].