From nobody Wed Oct 1 07:17:41 2014 Return-Path: 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 2260B1ACDC2 for ; Wed, 1 Oct 2014 07:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 WVx2S-epb-QO for ; Wed, 1 Oct 2014 07:17:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A94971ACDC3 for ; Wed, 1 Oct 2014 07:17:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: webpush@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141001141733.7733.91429.idtracker@ietfa.amsl.com> Date: Wed, 01 Oct 2014 07:17:33 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/WqLZ0qnZktGhMJA3HAvANV1F6yM Subject: [Webpush] State changed: charter-ietf-webpush-00-01 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 01 Oct 2014 14:17:37 -0000 State changed to IESG review. URL: http://datatracker.ietf.org/doc/charter-ietf-webpush/ From nobody Wed Oct 1 17:16:26 2014 Return-Path: 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 05CF51A884C; Wed, 1 Oct 2014 17:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 ql5cPjcHtv2f; Wed, 1 Oct 2014 17:00:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EACA51A8841; Wed, 1 Oct 2014 17:00:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Pete Resnick" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141002000057.14282.88330.idtracker@ietfa.amsl.com> Date: Wed, 01 Oct 2014 17:00:57 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/dLlpLo-a6U6jDaVrOAETXCzGtUE X-Mailman-Approved-At: Wed, 01 Oct 2014 17:16:23 -0700 Cc: webpush@ietf.org Subject: [Webpush] Pete Resnick's Yes on charter-ietf-webpush-00-01: (with COMMENT) X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 02 Oct 2014 00:00:59 -0000 Pete Resnick has entered the following ballot position for charter-ietf-webpush-00-01: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-webpush/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In the third paragraph, it seems like instead of "The work may describe a protocol", you want "The work will describe a protocol". Am I misunderstanding something? I am still concerned that not chartering this work to use an HTTP-based protocol is inviting unproductive discussions when the WG gets started. I do note that Paul Hoffman raised the identical concern in his review of the charter. This is, IMO, just inviting a standard APP rathole. That said, if you really want to leave the choice of base protocol up to a consensus discussion in the WG, I'm not going stand in the way. From nobody Wed Oct 1 20:46:05 2014 Return-Path: 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 6D0841A0056; Wed, 1 Oct 2014 20:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 fwzCBlhqDzs6; Wed, 1 Oct 2014 20:45:52 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3CC31A005E; Wed, 1 Oct 2014 20:45:51 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id hi2so2621501wib.3 for ; Wed, 01 Oct 2014 20:45:50 -0700 (PDT) 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=WXokOr4mwCvbZxiSrZUjlfR+fepH+OomK8z3KE0ifH4=; b=Y22sJXh/NWQJ5bFZPDNVqV/kaO5AK9aQFqLY5hquz2nUM6zRyIXKfC1c2olNtXA8HC E3yH0U3XYXspBzRfBlZxVDxjou2ICykhDuSOZsE/lmKuH4pm3lMchSmfnRRvpzJj+cbP jbtkYdBmz481JRcMk/xMx/GUPI1d3gjnECxOyKwlg4M19txRutACtA5p+GutrzQd71fU V46V3dGK+0dNaP6ERk2qqv9WzFrWrxyqieQB9O8YWwyXg1G6j+8HWYECq/bOdhUZ78qw XA4497NwuclAbuwNepfnsnNFQLcdNeaPlDBgGHmOwxMTTfgs9BL5cOD4ZSFZFlbKoP+J /sUQ== MIME-Version: 1.0 X-Received: by 10.180.198.203 with SMTP id je11mr375685wic.69.1412221550553; Wed, 01 Oct 2014 20:45:50 -0700 (PDT) Received: by 10.216.166.201 with HTTP; Wed, 1 Oct 2014 20:45:50 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Oct 2014 20:45:50 -0700 Message-ID: From: Costin Manolache To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7b625368dd8b2b0504687373 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/uzz9GzVcpMgCEpySrJghDN_qs9Q Cc: "iesg@ietf.org" , "webpush@ietf.org" , Elio Damaggio Subject: Re: [Webpush] Comment on charter and HTTP 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 03:45:57 -0000 --047d7b625368dd8b2b0504687373 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Sep 29, 2014 at 11:29 AM, Martin Thomson wrote: > On 29 September 2014 10:43, Elio Damaggio wrote: > > I read the charter, and, as stated, it includes any =E2=80=9Cpush=E2=80= =9D protocol for > > arbitrary devices. Does the charter include low-powered devices, such a= s > > embedded systems (think IoT, =E2=80=9CSmart things=E2=80=9D, etc.)? > > The overall architecture will probably suit, but the protocol might > not. The immediate goal is to enable this for things with web > browsers, so I'd imagine that some choices will be made that are > Things "with web browsers" include phones - and saving battery is quite critical there. For example GCM includes quite a few optimizations for this. Costin > suboptimal for IoT devices (or at least, not aggressive enough in the > power/processing cost savings direction). It's probably not wise to > try to solve for too wide a range of devices; I've seen that go very > poorly. > > That doesn't mean that we can't eventually considering widening the > net a little. But I personally want to ensure that we have a really > good solution for browsers first and foremost. > > What I was envisaging with my proposal was that this would serve as a > baseline, from which customized protocols could be bootstrapped. For > instance, if you are talking to a server, you could hint that you can > talk some as-yet-unspecified, super-power-saving protocol, at which > point the push server switches over to that instead. Of course, the > protocol also works over COAP with some small modifications, which > might be more practical short term goal. None of that is in the > charter though. > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > --047d7b625368dd8b2b0504687373 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Sep 29, 2014 at 11:29 AM, Martin Thomson <martin.thomson@gm= ail.com> wrote:
On 29 September 2014 10:43, Elio Damaggio <= ;elioda@microsoft.com> wrote= :
> I read the charter, and, as stated, it includes any =E2=80=9Cpush=E2= =80=9D protocol for
> arbitrary devices. Does the charter include low-powered devices, such = as
> embedded systems (think IoT, =E2=80=9CSmart things=E2=80=9D, etc.)?
The overall architecture will probably suit, but the protocol m= ight
not.=C2=A0 The immediate goal is to enable this for things with web
browsers, so I'd imagine that some choices will be made that are

Things "with web browsers" inclu= de phones - and saving battery is quite critical there.
For examp= le GCM includes quite a few optimizations for this.

Costin



=C2=A0
suboptimal for IoT devices (or at least, no= t aggressive enough in the
power/processing cost savings direction).=C2=A0 It's probably not wise = to
try to solve for too wide a range of devices; I've seen that go very poorly.

That doesn't mean that we can't eventually considering widening the=
net a little.=C2=A0 But I personally want to ensure that we have a really good solution for browsers first and foremost.

What I was envisaging with my proposal was that this would serve as a
baseline, from which customized protocols could be bootstrapped.=C2=A0 For<= br> instance, if you are talking to a server, you could hint that you can
talk some as-yet-unspecified, super-power-saving protocol, at which
point the push server switches over to that instead.=C2=A0 Of course, the protocol also works over COAP with some small modifications, which
might be more practical short term goal.=C2=A0 None of that is in the
charter though.

_______________________________________________
Webpush mailing list
Webpush@ietf.org
https://www.ietf.org/mailman/listinfo/webpush

--047d7b625368dd8b2b0504687373-- From nobody Thu Oct 2 06:24:13 2014 Return-Path: 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 D5ABF1A6EEC; Thu, 2 Oct 2014 05:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 mLyPqnoW4mRw; Thu, 2 Oct 2014 05:13:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F011A6EF1; Thu, 2 Oct 2014 05:13:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Brian Haberman" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141002121301.9817.57372.idtracker@ietfa.amsl.com> Date: Thu, 02 Oct 2014 05:13:01 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/OOVhwFN6njSL6-PlNBuTJSu6nvc X-Mailman-Approved-At: Thu, 02 Oct 2014 06:24:10 -0700 Cc: webpush@ietf.org Subject: [Webpush] Brian Haberman's No Objection on charter-ietf-webpush-00-01: (with COMMENT) X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 02 Oct 2014 12:13:04 -0000 Brian Haberman has entered the following ballot position for charter-ietf-webpush-00-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-webpush/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Pete's comment. From nobody Thu Oct 2 07:06:49 2014 Return-Path: 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 3C3071A03A0; Thu, 2 Oct 2014 07:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 lJ8453ckzjwQ; Thu, 2 Oct 2014 07:06:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 58BE71A036C; Thu, 2 Oct 2014 07:06:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141002140617.32284.75902.idtracker@ietfa.amsl.com> Date: Thu, 02 Oct 2014 07:06:17 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/NtpYrALf9tndLgzFcuX6xbRh-cI X-Mailman-Approved-At: Thu, 02 Oct 2014 07:06:46 -0700 Cc: webpush@ietf.org Subject: [Webpush] Spencer Dawkins' Yes on charter-ietf-webpush-00-01: (with COMMENT) X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 02 Oct 2014 14:06:22 -0000 Spencer Dawkins has entered the following ballot position for charter-ietf-webpush-00-01: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-webpush/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Can I just say how much I love short, clear charters? Not enough to write them myself, apparently, but a lot. And this one's quite accessible. I agree with Pete's comments, including the part where if you think the working group should explicitly choose an HTTP-based solution, that's OK with me. From nobody Thu Oct 2 08:04:40 2014 Return-Path: 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 C66C51A871B; Thu, 2 Oct 2014 08:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 G3lLixGrNQx1; Thu, 2 Oct 2014 08:04:34 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 569B31A1A0A; Thu, 2 Oct 2014 08:04:29 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id a1so3333842wgh.35 for ; Thu, 02 Oct 2014 08:04:27 -0700 (PDT) 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=T88qR8j4lGwemWLYRCFovIheKzPfkq1xtRZOAIuDQaA=; b=ZazGLG0iiYGjy9P+sqfUNmFawFmUlFjqp1eAEjPjQnJLTmD/XZwGrv9Lp0X8nz3Qbv Nv+InRwMaqa4FqDcHq9RfKG5huG5+iYFRGTQ90zJuZMhIkV4tPn6JDlxYagCqvNRnLVW /EYXEPVRJ8nP5YUjSpKfwX/L3hLXOZ4lgn33jOIvkcCpdBQn/L4Du7OybEudZgzaSoI7 G7kLwaN4JHt7NDAfpaYYuZY30RmGQHlbRVUMIyfTAsCLFbGz54CvywgkWPFidHkgulBl x8JEFy0H+rHMoQf71WQZxz94TXVB4oi3OQ8qTSfQcespqYNQU+m104LzN7Kp8pHY/H6U GF7Q== MIME-Version: 1.0 X-Received: by 10.194.103.200 with SMTP id fy8mr15965973wjb.123.1412262267755; Thu, 02 Oct 2014 08:04:27 -0700 (PDT) Received: by 10.216.166.201 with HTTP; Thu, 2 Oct 2014 08:04:27 -0700 (PDT) In-Reply-To: References: <20140917145417.2309.43465.idtracker@ietfa.amsl.com> <542180F3.2060902@cs.tcd.ie> <542B111C.6000008@cs.tcd.ie> <542B1B84.5020408@cs.tcd.ie> Date: Thu, 2 Oct 2014 08:04:27 -0700 Message-ID: From: Costin Manolache To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7bfe9522cca464050471ee04 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/uautlqlv-TEpFisYBZLFDHK6iQM Cc: Alissa Cooper , The IESG , "webpush@ietf.org" , Stephen Farrell Subject: Re: [Webpush] Stephen Farrell's No Objection on charter-ietf-webpush-00-00: (with COMMENT) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 15:04:37 -0000 --047d7bfe9522cca464050471ee04 Content-Type: text/plain; charset=UTF-8 On Tue, Sep 30, 2014 at 3:10 PM, Martin Thomson wrote: > On 30 September 2014 14:07, Stephen Farrell > wrote: > > Do we have any worked examples of using security (and caring > > about privacy) here though? I remain concerned that its too easy > > to just say "turn on push" for , where the security and > > privacy consequences of doing so are unknowable for . But > > maybe I'm worrying over not so much and a worked example will > > help. > > OK, so the intent of the proposed security mechanism is that the > easiest thing to do is to provide end-to-end security. > > How we'd do that is the API returns two things to the application > running in the browser: a location to send messages and a key with > which to encrypt them. If you don't encrypt them, then the browser > will fail to deliver pushed messages. > (from android/gcm perspective): there are quite a few developers using push with multiple 'senders', i.e. the app can receive messages from different organizations that don't share keys. There is also the case of 'groups' - where the entire group may need a shared key. I think the API will need to be able to return multiple keys, based on the sender. There is also the issue of authorizing the send - so you need to return at least 2 keys, one that is shared with the push provider and is used to authorize the send ( 'registration id' in gcm ), and the encryption key that will not be shared with the provider. > > The keying material isn't used in the message delivery at all. An > application running on the server can send anything to the browser > over the push channel, but if the message doesn't decrypt and > authenticate with the selected key, it doesn't get delivered. It's a > little odd to effectively hold functionality hostage like that, but I > think that it will work. > Yes, it works - even without any intervention from the push provider, i.e. there are apps that generate the key and do end-to-end encryption on top of gcm. Allowing a binary payload is probably the best way to help them. Costin > > I won't lie, we can't prevent someone outside of the browser context > from only using the hop-by-hop security mechanisms. I can't help but > be optimistic that a demonstration of feasibility will help shift > those use cases too. It's possible that this sort of mechanism could > be enforced at the operating system level in the same way. > > > Ever the eternal optimist, I suppose. > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > --047d7bfe9522cca464050471ee04 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Sep 30, 2014 at 3:10 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
On 30 September 2014 14:07, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
> Do we have any worked examples of using security (and caring
> about privacy) here though? I remain concerned that its too easy
> to just say "turn on push" for <foo>, where the securi= ty and
> privacy consequences of doing so are unknowable for <foo>. But > maybe I'm worrying over not so much and a worked example will
> help.

OK, so the intent of the proposed security mechanism is that the
easiest thing to do is to provide end-to-end security.

How we'd do that is the API returns two things to the application
running in the browser: a location to send messages and a key with
which to encrypt them.=C2=A0 If you don't encrypt them, then the browse= r
will fail to deliver pushed messages.

(= from android/gcm perspective): there are quite a few developers using=C2=A0=
push with multiple 'senders', i.e. the app can receive m= essages from=C2=A0
different organizations that don't share k= eys.=C2=A0 There is also the case
=C2=A0of 'groups' - whe= re the entire group may need a shared key.

I think= the API will need to be able to return multiple keys, based on the
sender. There is also the issue of authorizing the send - so you need
to return at least 2 keys, one that is shared with the push provide= r
and is used to authorize the send ( 'registration id' i= n gcm ), and the
encryption key that will not be shared with the = provider.



=C2=A0

The keying material isn't used in the message delivery at all.=C2=A0 An=
application running on the server can send anything to the browser
over the push channel, but if the message doesn't decrypt and
authenticate with the selected key, it doesn't get delivered.=C2=A0 It&= #39;s a
little odd to effectively hold functionality hostage like that, but I
think that it will work.

Yes, it works = - even without any intervention from the push provider, i.e.
ther= e are apps that generate the key and do end-to-end encryption on top
<= div>of gcm. Allowing a binary payload is probably the best way to help them= .

Costin
=C2=A0

I won't lie, we can't prevent someone outside of the browser contex= t
from only using the hop-by-hop security mechanisms.=C2=A0 I can't help = but
be optimistic that a demonstration of feasibility will help shift
those use cases too.=C2=A0 It's possible that this sort of mechanism co= uld
be enforced at the operating system level in the same way.
=


=C2=A0

Ever the eternal optimist, I suppose.

_______________________________________________
Webpush mailing list
Webpush@ietf.org
https://www.ietf.org/mailman/listinfo/webpush

--047d7bfe9522cca464050471ee04-- From nobody Thu Oct 2 08:05:30 2014 Return-Path: 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 CE7A41A8736; Thu, 2 Oct 2014 08:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 dUqa0Rfeo8Vc; Thu, 2 Oct 2014 08:05:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF5D1A8731; Thu, 2 Oct 2014 08:05:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141002150523.27303.68943.idtracker@ietfa.amsl.com> Date: Thu, 02 Oct 2014 08:05:23 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/9x2Hda5XC-BNNFqWH1lZDuSAd7I Cc: webpush@ietf.org Subject: [Webpush] Stephen Farrell's Block on charter-ietf-webpush-00-01: (with BLOCK) X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 02 Oct 2014 15:05:25 -0000 Stephen Farrell has entered the following ballot position for charter-ietf-webpush-00-01: Block When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-webpush/ ---------------------------------------------------------------------- BLOCK: ---------------------------------------------------------------------- I'm sorry, despite some discussion I still do not get the position here wrt security and privacy, nor the likely outcomes. From nobody Thu Oct 2 08:43:11 2014 Return-Path: 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 2C5211A6EDB; Thu, 2 Oct 2014 08:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 xyyupx4nRpf9; Thu, 2 Oct 2014 08:16:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7D11A1B75; Thu, 2 Oct 2014 08:16:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Adrian Farrel" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141002151641.11476.33987.idtracker@ietfa.amsl.com> Date: Thu, 02 Oct 2014 08:16:41 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/oCywS4ZhakgdFfBgustagEMxpAc X-Mailman-Approved-At: Thu, 02 Oct 2014 08:43:09 -0700 Cc: webpush@ietf.org Subject: [Webpush] Adrian Farrel's No Objection on charter-ietf-webpush-00-01: (with COMMENT) X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 02 Oct 2014 15:16:47 -0000 Adrian Farrel has entered the following ballot position for charter-ietf-webpush-00-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-webpush/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I reserved my position on this while I watched the discussion that Stephen had about Security. I was surprised that this did not reach a conclusion that he was tolerably able to live with. That is a shame. So I support his Block. From nobody Thu Oct 2 08:56:15 2014 Return-Path: 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 A10381A1A26; Thu, 2 Oct 2014 08:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 lupY_8ijT8Nz; Thu, 2 Oct 2014 08:55:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5251A0394; Thu, 2 Oct 2014 08:55:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alia Atlas" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141002155523.18660.67364.idtracker@ietfa.amsl.com> Date: Thu, 02 Oct 2014 08:55:23 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/uuFaafFPrTOnLaeX9LzUk0cya7g X-Mailman-Approved-At: Thu, 02 Oct 2014 08:56:13 -0700 Cc: webpush@ietf.org Subject: [Webpush] Alia Atlas' No Objection on charter-ietf-webpush-00-01: (with COMMENT) X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 02 Oct 2014 15:55:27 -0000 Alia Atlas has entered the following ballot position for charter-ietf-webpush-00-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-webpush/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I also support Stephen's push for clearer security and privacy details. From nobody Thu Oct 2 09:14:45 2014 Return-Path: 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 1126E1A877F; Thu, 2 Oct 2014 09:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ELf42BNei6Fp; Thu, 2 Oct 2014 09:14:24 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D14A1A8742; Thu, 2 Oct 2014 09:14:18 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id f15so2571426lbj.11 for ; Thu, 02 Oct 2014 09:14:16 -0700 (PDT) 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=d6RqXv7srfY/EyTiWZs4YaEO9fTmQoeikcyyzzYSCcY=; b=AV+yDorL+dc/MMFrSNApjd0BFhbNDLfLiW0DJX2TBnt1hbnOh91sHmakPFVuszmTBR Ly2f/OlwYLx1cPfGb9ngFNCP/OejlqKRfWojLS+ddvmNuPcpWsXbl3ipbo9Zx5QYrQ5G fZcFlIcvzTmp5oHOz3A3iQV7w3vrHFEskU+y5Mb20ox/+5wifF8IdapM003uT+aB+qwJ Kx3mVegPtWyl9Xw9WmBpCbLPu6o3aVD+0BB5jgp82fvY19KbF1mAaTXjhO0L7sAsX9+e kQe0WabTyj8dZW2/jdJ9S4B6o1lg3U9ucWtqGVnDqkwKWKvftpZkK9KG0UzYTmAI8Xoe TmTQ== MIME-Version: 1.0 X-Received: by 10.112.148.170 with SMTP id tt10mr61887024lbb.61.1412266456792; Thu, 02 Oct 2014 09:14:16 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Thu, 2 Oct 2014 09:14:16 -0700 (PDT) In-Reply-To: References: Date: Thu, 2 Oct 2014 09:14:16 -0700 Message-ID: From: Martin Thomson To: Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/F58QfL2dHmuuQJzePCRHbZt-Yp0 Cc: "iesg@ietf.org" , "webpush@ietf.org" , Elio Damaggio Subject: Re: [Webpush] Comment on charter and HTTP 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 16:14:26 -0000 On 1 October 2014 20:45, Costin Manolache wrote: > Things "with web browsers" include phones - and saving battery is quite > critical there. > For example GCM includes quite a few optimizations for this. Absolutely, but if we build a solution that is good for a light switch, that could be a different sort of proposition. From nobody Thu Oct 2 09:27:17 2014 Return-Path: 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 C86E11A882A for ; Thu, 2 Oct 2014 09:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 N9tU0xFNLsLe for ; Thu, 2 Oct 2014 09:27:06 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E57D61A882F for ; Thu, 2 Oct 2014 09:27:05 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by gateway2.nyi.internal (Postfix) with ESMTP id 2153420729 for ; Thu, 2 Oct 2014 12:27:05 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 02 Oct 2014 12:27:05 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= x-sasl-enc:content-type:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; s= mesmtp; bh=ESE11/Ko6rBL8JzCRGyS6zUu690=; b=qVoAPizQDeOsfORD5P+uI nPeOwygXfMNCbEUXrSAt59T0Nx1iY34SSk6choAyfwzGn3bDfNrDAsyUxV9b+itJ mu2pJzXqHW/fskhp8g/zelonDDCctRDecfPON4Nf6VsAKVFSsDIbyfPQ/gpz7jLM /0PeCWToZETLyqIhduwZWE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:content-type:mime-version :subject:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; s=smtpout; bh=ESE11/Ko6rBL8JzCRGyS6zU u690=; b=JmeYsGg4WRcTIJ4N4pz2PS4xww9MI3XR/HviEKDb8xDAz9Oz6Jz57cF iXhrrekDRCkPUUCLPb8ggrQGIXc6NzsPLCSz/+KUC0rv6hGh4xX/Wz+LqEImWvvO KSxPnReGcoqI76xRXqE+UWvy52vm4uOoMor3uOVOX3Qob6hbSjKw= X-Sasl-enc: J1EUUJlDJKp0D91tDLhCqLZyJziiXc+T3cDxjqHcDubi 1412267224 Received: from [10.35.132.83] (unknown [128.107.239.233]) by mail.messagingengine.com (Postfix) with ESMTPA id 96738C00012; Thu, 2 Oct 2014 12:27:04 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: <20141002150523.27303.68943.idtracker@ietfa.amsl.com> Date: Thu, 2 Oct 2014 09:27:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <41FE6C7F-EBC6-4A68-A337-7BCD106D13F4@cooperw.in> References: <20141002150523.27303.68943.idtracker@ietfa.amsl.com> To: Stephen Farrell X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/vVDcsKZ_Le6acu1xmL2CQfvMtSs Cc: IESG , webpush@ietf.org Subject: Re: [Webpush] Stephen Farrell's Block on charter-ietf-webpush-00-01: (with BLOCK) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 16:27:11 -0000 I was hoping this would resolve in the back-and-forth, but let me try to = take a stab: I think it=92s important to give the community working on this problem = some flexibility in terms of how security requirements will be met =97 = might require application support, might require API updates, might = require protocol support, or some combination of those. At a minimum, = applications can always arrange for e2e encryption of pushed data = regardless of what the protocol supports, including for the multicast = case. So I think we could add something along the following lines to the = charter: "The output of the WG should be able to support end-to-end integrity and = confidentiality protections for the data being pushed, as well as the = ability to prevent the push server from associating users with = applications.=94 Does that help? Alissa On Oct 2, 2014, at 8:05 AM, Stephen Farrell = wrote: > Stephen Farrell has entered the following ballot position for > charter-ietf-webpush-00-01: Block >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 >=20 > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/charter-ietf-webpush/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > BLOCK: > ---------------------------------------------------------------------- >=20 >=20 > I'm sorry, despite some discussion I still do not get the=20 > position here wrt security and privacy, nor the likely > outcomes. >=20 >=20 >=20 >=20 > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush From nobody Thu Oct 2 09:30:57 2014 Return-Path: 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 BA6D81A882A; Thu, 2 Oct 2014 09:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Ac1Tzsep7QdZ; Thu, 2 Oct 2014 09:30:49 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5C021A87EA; Thu, 2 Oct 2014 09:30:43 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id gi9so2746133lab.33 for ; Thu, 02 Oct 2014 09:30:42 -0700 (PDT) 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:content-transfer-encoding; bh=DQQfiPmMvtgiP39TZdayEEDoRnKijw/pyVhVxG3Bisw=; b=nf5hPSLER32f+TBirokU8KN7GEKuagK3AfcoUk8IZrxUr7sQkYlv0/woSJRBjl7UIF x02migrSABF+amP/4hjGR6MJogllgz+Ru7xzz9PxFuO41XcQxzAloOIqV3CxKEjFw/Tn 6GnjmgcWvyL8wEJQuQobFOoJsHzWpZ2VCBmEWVnWByy+4reVNdhwzq+SXu8ch0LDaAJ8 CfJ6nhvBNqdOdytH28Cau0RDdSWAD0RCBBvGC17IiuGZwQqstv7T7tWKxjoFCjWhnQ3A 0kc0vBe4q2YQu6s+2hH6O/sNbYwRX0u18V3hzCPCuriw+TWeDRCAZYvhMiobl2ZqIVCw 5iPg== MIME-Version: 1.0 X-Received: by 10.112.243.43 with SMTP id wv11mr12581937lbc.95.1412267442229; Thu, 02 Oct 2014 09:30:42 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Thu, 2 Oct 2014 09:30:42 -0700 (PDT) In-Reply-To: <41FE6C7F-EBC6-4A68-A337-7BCD106D13F4@cooperw.in> References: <20141002150523.27303.68943.idtracker@ietfa.amsl.com> <41FE6C7F-EBC6-4A68-A337-7BCD106D13F4@cooperw.in> Date: Thu, 2 Oct 2014 09:30:42 -0700 Message-ID: From: Martin Thomson To: Alissa Cooper Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/P4dx3l1GwW0OBnppulFENLr2gQ0 Cc: IESG , "webpush@ietf.org" , Stephen Farrell Subject: Re: [Webpush] Stephen Farrell's Block on charter-ietf-webpush-00-01: (with BLOCK) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 16:30:51 -0000 On 2 October 2014 09:27, Alissa Cooper wrote: > "The output of the WG should be able to support end-to-end integrity and = confidentiality protections for the data being pushed, as well as the abili= ty to prevent the push server from associating users with applications.=E2= =80=9D That is something I can buy in to. Adding "HTTP-based" is also OK. From nobody Thu Oct 2 10:40:35 2014 Return-Path: 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 85B471A90EB for ; Thu, 2 Oct 2014 10:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 F9PRDDNzNpU6 for ; Thu, 2 Oct 2014 10:40:25 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C3961A90E6 for ; Thu, 2 Oct 2014 10:40:25 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by gateway2.nyi.internal (Postfix) with ESMTP id DD99C20AE2 for ; Thu, 2 Oct 2014 13:40:24 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Thu, 02 Oct 2014 13:40:24 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= x-sasl-enc:content-type:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; s= mesmtp; bh=LAhJqRTisODqvP1gZWZ2+0y4VLs=; b=O/bPEclP4hpdS6lSVWbAL NX56tqDU+ylqxG5IT8lTkViBesPp8AQ2UDlosnV3oHBbyuRv7OuxF/0t0e9ROww+ K6FidXM21V8rdWIQKDKrHeYSq7fjf+OlTamwA1POWEjr28D0ZGu2bzG+nfI6gLCp HWz9VP0Ksd22wEDNCRYDno= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:content-type:mime-version :subject:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; s=smtpout; bh=LAhJqRTisODqvP1gZWZ2+0y 4VLs=; b=nIF0qaL4gAFt2WGa3Fx3yhV22xgSyJgKEXCV8MyslXP3dAgqCe9jhX5 nvvLURLe4oYZd9Ficat8PatQ6XjdE6IVT7ZG//BZdZ/q4rJcMXz5OFO9Kr82PsL+ oZXo0F4RqW7fAtg0doCBcatKRwvoCaQ5S1r9IFQF0q9rAyCfaLsU= X-Sasl-enc: O3ZPwrmacKt7KBQgPx2fzEpV5CTBxxmjFAC1KDJoaniw 1412271624 Received: from [10.35.132.83] (unknown [128.107.239.234]) by mail.messagingengine.com (Postfix) with ESMTPA id 52A70C00015; Thu, 2 Oct 2014 13:40:24 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: Date: Thu, 2 Oct 2014 10:40:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <20A44D92-7395-45BF-A4C8-666BEA3271EF@cooperw.in> References: <20141002150523.27303.68943.idtracker@ietfa.amsl.com> <41FE6C7F-EBC6-4A68-A337-7BCD106D13F4@cooperw.in> To: Martin Thomson X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/v7rkhaEdfAioaI8DmW9LdKV-s_w Cc: IESG , "webpush@ietf.org" , Stephen Farrell Subject: Re: [Webpush] Stephen Farrell's Block on charter-ietf-webpush-00-01: (with BLOCK) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 17:40:30 -0000 I had some further off-line discussion with Stephen to work in a few = more clarifications, and here is what I suggest as a result: "The WG will aim to minimize the amount of additional information that = is revealed to the push notification service. It must be possible for = the application to apply end-to-end security mechanisms so that messages = sent via the push notification service cannot be read or modified by the = push notification service. The WG will also consider additional privacy = protections, including the ability to prevent the push notification = service from gleaning other types of information, such as the = association between an application and a specific user.=94 I think for the =93HTTP-based=94 bit we can do the following in the = charter 3rd para: s/This working group will develop a protocol/This working group will = develop an HTTP-based protocol/ I=92d like to get these changes posted in a day or two assuming = Stephen=92s concerns are satisfied and there are no further objections. Thanks, Alissa On Oct 2, 2014, at 9:30 AM, Martin Thomson = wrote: > On 2 October 2014 09:27, Alissa Cooper wrote: >> "The output of the WG should be able to support end-to-end integrity = and confidentiality protections for the data being pushed, as well as = the ability to prevent the push server from associating users with = applications.=94 >=20 > That is something I can buy in to. >=20 > Adding "HTTP-based" is also OK. From nobody Thu Oct 2 10:55:09 2014 Return-Path: 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 0222B1A90F6; Thu, 2 Oct 2014 10:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 WrC5XOqf1vlE; Thu, 2 Oct 2014 10:54:50 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A75C1A90F9; Thu, 2 Oct 2014 10:54:48 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id u10so2652740lbd.20 for ; Thu, 02 Oct 2014 10:54:47 -0700 (PDT) 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:content-transfer-encoding; bh=Dnq0LHcbBSYPbtV5Uaz65qJXf4xKfCagE5doKANdjXY=; b=qimOblD7B/VR/6nbtX+y6Fl4Z0uUcAdhDiQyj9qCwmA11Fn6tmie6ENLg/xgjaGQiR TVghpC/cS9Ceg/X254nZ01gjDybyvXhvxJ7Bv5tySbaCEawg1KXHDhkAF7MULZiEpcpF RFaMiXsgG8Ypr+4yHwEmdGBhXyZ1x9CKVaOCPHT1cOqvy+vwCE9ctCSoErxuojTWY0C8 foTI+rSoWs9O96uB2WLIeBME41AG7JM2w2C6Eptg5tP7iHmuaZ029dbEHYUiCnul0ox9 jAFfcrYyu2L+oD0xgDlYhz7I+GIdLpl3RBvjtQMq5nIaROVGik3t01kdpjsAV1DzECjn 8nIQ== MIME-Version: 1.0 X-Received: by 10.112.166.35 with SMTP id zd3mr371486lbb.3.1412272487466; Thu, 02 Oct 2014 10:54:47 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Thu, 2 Oct 2014 10:54:47 -0700 (PDT) In-Reply-To: <20A44D92-7395-45BF-A4C8-666BEA3271EF@cooperw.in> References: <20141002150523.27303.68943.idtracker@ietfa.amsl.com> <41FE6C7F-EBC6-4A68-A337-7BCD106D13F4@cooperw.in> <20A44D92-7395-45BF-A4C8-666BEA3271EF@cooperw.in> Date: Thu, 2 Oct 2014 10:54:47 -0700 Message-ID: From: Martin Thomson To: Alissa Cooper Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/DxlncBMZwlIle4jaqG2-1vCHljM Cc: IESG , "webpush@ietf.org" , Stephen Farrell Subject: Re: [Webpush] Stephen Farrell's Block on charter-ietf-webpush-00-01: (with BLOCK) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 17:54:55 -0000 On 2 October 2014 10:40, Alissa Cooper wrote: > "The WG will aim to minimize the amount of additional information that is= revealed to the push notification service. It must be possible for the ap= plication to apply end-to-end security mechanisms so that messages sent via= the push notification service cannot be read or modified by the push notif= ication service. The WG will also consider additional privacy protections,= including the ability to prevent the push notification service from gleani= ng other types of information, such as the association between an applicati= on and a specific user.=E2=80=9D Sure, I was certainly intending to do that. From nobody Thu Oct 2 11:02:08 2014 Return-Path: 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 CE75C1A9109; Thu, 2 Oct 2014 11:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 gymk6aDMJrY8; Thu, 2 Oct 2014 11:02:01 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id AF26D1A9105; Thu, 2 Oct 2014 11:02:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4B87FBE8A; Thu, 2 Oct 2014 19:02:00 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6nRQ98dkKjT; Thu, 2 Oct 2014 19:01:58 +0100 (IST) Received: from [10.87.48.6] (unknown [86.42.29.169]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B68A2BE83; Thu, 2 Oct 2014 19:01:58 +0100 (IST) User-Agent: K-9 Mail for Android In-Reply-To: <20A44D92-7395-45BF-A4C8-666BEA3271EF@cooperw.in> References: <20141002150523.27303.68943.idtracker@ietfa.amsl.com> <41FE6C7F-EBC6-4A68-A337-7BCD106D13F4@cooperw.in> <20A44D92-7395-45BF-A4C8-666BEA3271EF@cooperw.in> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Stephen Farrell Date: Thu, 02 Oct 2014 19:00:01 +0100 To: Alissa Cooper , Martin Thomson Message-ID: <0D99B723-35B2-40F1-BB57-FC06E04E37FA@cs.tcd.ie> Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/5N3e3RYtT15ZRJTAZmC50kh1sYM Cc: IESG , "webpush@ietf.org" Subject: Re: [Webpush] Stephen Farrell's Block on charter-ietf-webpush-00-01: (with BLOCK) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 18:02:04 -0000 On 2 October 2014 18:40:25 IST, Alissa Cooper wrote: >I had some further off-line discussion with Stephen to work in a few >more clarifications, and here is what I suggest as a result: > >"The WG will aim to minimize the amount of additional information that >is revealed to the push notification service. It must be possible for >the application to apply end-to-end security mechanisms so that >messages sent via the push notification service cannot be read or >modified by the push notification service. The WG will also consider >additional privacy protections, including the ability to prevent the >push notification service from gleaning other types of information, >such as the association between an application and a specific user.” Lovely. Happy to unblock on that basis once back online. Ta, S. > >I think for the “HTTP-based” bit we can do the following in the charter >3rd para: > >s/This working group will develop a protocol/This working group will >develop an HTTP-based protocol/ > >I’d like to get these changes posted in a day or two assuming Stephen’s >concerns are satisfied and there are no further objections. > >Thanks, >Alissa > >On Oct 2, 2014, at 9:30 AM, Martin Thomson >wrote: > >> On 2 October 2014 09:27, Alissa Cooper wrote: >>> "The output of the WG should be able to support end-to-end integrity >and confidentiality protections for the data being pushed, as well as >the ability to prevent the push server from associating users with >applications.” >> >> That is something I can buy in to. >> >> Adding "HTTP-based" is also OK. From nobody Thu Oct 2 14:05:25 2014 Return-Path: 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 64B271A87A6; Thu, 2 Oct 2014 14:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 CX62j__CT6j9; Thu, 2 Oct 2014 14:04:58 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E61B1A038E; Thu, 2 Oct 2014 14:04:58 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id cc10so2732593wib.0 for ; Thu, 02 Oct 2014 14:04:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=Gq43IBd6zglZaHK9cuXHzIfcuTYVsfzFSDgfrZ9qaUU=; b=NBy1WG1XEepJ/ghgLyG5K+Ob9w63KePv/q49U3q+X+L9PAGJwSSE+tskPCERyPx9pY bGqtbaAMfHfnYoLJBlSQ2wwtxDHPyEWgQ3tvg6sWwMbaklme6dh+zeAseeNZygi1oIRv KUUVl6EdVWqtb9AQvU4UOsHV98rfxSKtI7kfXPrvaEiilTa51Ertt8MNu5IqR1GzDwEN LCA+Lpd/pNJUz1W/lhVlN8INDrKvZlk4rVSK9SSnhpIyyGib3I/6ThIxpYWGZcYtUrpL 66FZ/jpyRVfKzDtN1X5RV9o8yrpqvXh49gKFt+mhh444QTqXFWM24JwPijTlpuU7BTVJ C8iA== X-Received: by 10.180.109.162 with SMTP id ht2mr7533626wib.12.1412283896772; Thu, 02 Oct 2014 14:04:56 -0700 (PDT) Received: from [10.0.1.6] (host109-155-30-136.range109-155.btcentralplus.com. [109.155.30.136]) by mx.google.com with ESMTPSA id ji10sm2445957wid.7.2014.10.02.14.04.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Oct 2014 14:04:55 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <1E601E9B-608E-4A80-A209-FAC298F074C0@gmail.com> X-Mailer: iPad Mail (12A405) From: Daniel Appelquist Date: Thu, 2 Oct 2014 22:04:55 +0100 To: Martin Thomson Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/6KivdY2GNixWdiyM8oyJy_T7lpw Cc: Costin Manolache , "iesg@ietf.org" , "webpush@ietf.org" , Elio Damaggio Subject: Re: [Webpush] Comment on charter and HTTP 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 21:05:00 -0000 > On 2 Oct 2014, at 17:14, Martin Thomson wrote: >=20 >> On 1 October 2014 20:45, Costin Manolache wrote: >> Things "with web browsers" include phones - and saving battery is quite >> critical there. >> For example GCM includes quite a few optimizations for this. >=20 > Absolutely, but if we build a solution that is good for a light > switch, that could be a different sort of proposition. >=20 +1 on keeping the work focused to "things with web browsers" and not the mor= e general iot / embedded devices cases, which implies a different set of req= uirements. Dan= From nobody Thu Oct 2 14:18:00 2014 Return-Path: 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 24DBE1ACD61; Thu, 2 Oct 2014 14:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 pSWMzcYlUta3; Thu, 2 Oct 2014 14:17:56 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3786D1ACD9F; Thu, 2 Oct 2014 14:17:56 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id cc10so2759119wib.0 for ; Thu, 02 Oct 2014 14:17:54 -0700 (PDT) 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=6prs7Z+6RBwAVxCnaY5kSDeP9HLlv9S9h6Iebnhqy68=; b=TnEUbaMwUJ6VRBjY0aLTGQWTh5IYFZWKQRi4mmQs6Odu3FDmfqE+Yu1PHkgYl6wRVK mkCNYFG/gYJOw3OBrS2VVw6w4aIwA95byP3SzXX49pVmsyzupiqsrnFa6Qm5WZ4q2blb iVaUO2awdIyKVPwwXb+Cc9CYVoxDK9yhp7PBYTF6yEvRka8zCuVstPGZQFJoh+pi5b76 Fam3aNGWwPFrntyp+4Q8HBmTaIwROeL/c5RwKr24SLZbo6uU+EXWvEsB0NT3SrBfT7L3 Mcx5Sp7O3xHqPRJbJDOEe25s+MtW5eOWE1WhtuxRU7f9lr8VOf/Mpp4fse+11mYKZH/a 9Lqg== MIME-Version: 1.0 X-Received: by 10.194.103.200 with SMTP id fy8mr1580284wjb.123.1412284674932; Thu, 02 Oct 2014 14:17:54 -0700 (PDT) Received: by 10.216.166.201 with HTTP; Thu, 2 Oct 2014 14:17:54 -0700 (PDT) In-Reply-To: References: Date: Thu, 2 Oct 2014 14:17:54 -0700 Message-ID: From: Costin Manolache To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7bfe95225f08bd05047726e3 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/e21oCHEY5rCyHisxopSmqG9DGx4 Cc: "iesg@ietf.org" , "webpush@ietf.org" , Elio Damaggio Subject: Re: [Webpush] Comment on charter and HTTP 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 21:17:58 -0000 --047d7bfe95225f08bd05047726e3 Content-Type: text/plain; charset=UTF-8 On Thu, Oct 2, 2014 at 9:14 AM, Martin Thomson wrote: > On 1 October 2014 20:45, Costin Manolache wrote: > > Things "with web browsers" include phones - and saving battery is quite > > critical there. > > For example GCM includes quite a few optimizations for this. > > > Absolutely, but if we build a solution that is good for a light > switch, that could be a different sort of proposition "Things with a battery that could run a browser or other http-based apps" is a good target. I think taking battery into account is critical - for phones, tablets and even laptops. IOT and light switch is indeed a different problem - but most of the times the switches are still connected to 'something that can run http' and act as a proxy to their non-IP protocols. Costin --047d7bfe95225f08bd05047726e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 2, 2014 at 9:14 AM, Martin Thomson <martin.thomson@= gmail.com> wrote:
On= 1 October 2014 20:45, Costin Manolache <costin@gmail.com> wrote:
> Things "with web browsers" include phones - and saving batte= ry is quite
> critical there.
> For example GCM includes quite a few optimizations for this.


Absolutely, but if we build a solution that is good for a light
switch, that could be a different sort of proposition

=
"Things with a battery that could run a browser or other ht= tp-based apps" is a good target.
I think taking battery into= account is critical - for phones, tablets and even laptops. =C2=A0

IOT and light switch is indeed a different problem - but = most of the times the switches
are still connected to 'someth= ing that can run http' and act as a proxy to their non-IP=C2=A0
protocols.

=C2=A0
Costin=C2=A0
<= /div>
--047d7bfe95225f08bd05047726e3-- From nobody Thu Oct 2 14:20:51 2014 Return-Path: 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 560D91ACD5F; Thu, 2 Oct 2014 14:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-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 m4Azk8rgzpcf; Thu, 2 Oct 2014 14:20:48 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0722.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::722]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 121D91A8030; Thu, 2 Oct 2014 14:20:47 -0700 (PDT) Received: from BL2PR03MB132.namprd03.prod.outlook.com (10.255.230.24) by BL2PR03MB129.namprd03.prod.outlook.com (10.255.230.20) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Thu, 2 Oct 2014 21:20:24 +0000 Received: from BL2PR03MB132.namprd03.prod.outlook.com ([169.254.9.55]) by BL2PR03MB132.namprd03.prod.outlook.com ([169.254.9.55]) with mapi id 15.00.1044.008; Thu, 2 Oct 2014 21:20:24 +0000 From: Elio Damaggio To: Costin Manolache , Martin Thomson Thread-Topic: [Webpush] Comment on charter and HTTP Thread-Index: Ac/cCK0ubT2yJjc2Q2a49PXxavRwYQACqPoAAHgCngAAGiOEAAAKmrIAAAAFWfA= Date: Thu, 2 Oct 2014 21:20:24 +0000 Message-ID: <1126d24f78e04f9ab72d853b7def1723@BL2PR03MB132.namprd03.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [131.107.0.118] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB129; x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-forefront-prvs: 03524FBD26 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(24454002)(189002)(377454003)(19609705001)(95666004)(15975445006)(19300405004)(76482002)(10300001)(64706001)(66066001)(19580405001)(21056001)(19580395003)(76576001)(46102003)(108616004)(99286002)(80022003)(107046002)(4396001)(97736003)(106356001)(76176999)(15202345003)(101416001)(33646002)(86362001)(105586002)(120916001)(87936001)(50986999)(93886004)(77096002)(16236675004)(20776003)(2656002)(19625215002)(74316001)(85852003)(92566001)(85306004)(86612001)(54356999)(31966008)(99396003)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB129; H:BL2PR03MB132.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_1126d24f78e04f9ab72d853b7def1723BL2PR03MB132namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/8pFje5hSzgZWyxdik0ax0rSlTss Cc: "iesg@ietf.org" , "webpush@ietf.org" Subject: Re: [Webpush] Comment on charter and HTTP 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 21:20:50 -0000 --_000_1126d24f78e04f9ab72d853b7def1723BL2PR03MB132namprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEuDQoNClRoYXQgaXMgY29ycmVjdC4gQSBsb3Qgb2YgSW9UIHNjZW5hcmlvcyBhcmUgYWNoaWV2 ZWQgdXNpbmcgYSBnYXRld2F5ICh3aXRoIGFuIOKAnGh0dHAtYmFzZWQgYXBw4oCdKSB3aGljaCBy ZWxheXMgY29tbXVuaWNhdGlvbnMgdG8gdGhlIGxvd2VyIHBvd2VyZWQg4oCcdGhpbmdz4oCdLg0K DQpGcm9tOiBDb3N0aW4gTWFub2xhY2hlIFttYWlsdG86Y29zdGluQGdtYWlsLmNvbV0NClNlbnQ6 IFRodXJzZGF5LCBPY3RvYmVyIDIsIDIwMTQgMjoxOCBQTQ0KVG86IE1hcnRpbiBUaG9tc29uDQpD YzogRWxpbyBEYW1hZ2dpbzsgaWVzZ0BpZXRmLm9yZzsgd2VicHVzaEBpZXRmLm9yZw0KU3ViamVj dDogUmU6IFtXZWJwdXNoXSBDb21tZW50IG9uIGNoYXJ0ZXIgYW5kIEhUVFANCg0KDQoNCk9uIFRo dSwgT2N0IDIsIDIwMTQgYXQgOToxNCBBTSwgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29u QGdtYWlsLmNvbTxtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tPj4gd3JvdGU6DQpPbiAx IE9jdG9iZXIgMjAxNCAyMDo0NSwgQ29zdGluIE1hbm9sYWNoZSA8Y29zdGluQGdtYWlsLmNvbTxt YWlsdG86Y29zdGluQGdtYWlsLmNvbT4+IHdyb3RlOg0KPiBUaGluZ3MgIndpdGggd2ViIGJyb3dz ZXJzIiBpbmNsdWRlIHBob25lcyAtIGFuZCBzYXZpbmcgYmF0dGVyeSBpcyBxdWl0ZQ0KPiBjcml0 aWNhbCB0aGVyZS4NCj4gRm9yIGV4YW1wbGUgR0NNIGluY2x1ZGVzIHF1aXRlIGEgZmV3IG9wdGlt aXphdGlvbnMgZm9yIHRoaXMuDQoNCg0KQWJzb2x1dGVseSwgYnV0IGlmIHdlIGJ1aWxkIGEgc29s dXRpb24gdGhhdCBpcyBnb29kIGZvciBhIGxpZ2h0DQpzd2l0Y2gsIHRoYXQgY291bGQgYmUgYSBk aWZmZXJlbnQgc29ydCBvZiBwcm9wb3NpdGlvbg0KDQoiVGhpbmdzIHdpdGggYSBiYXR0ZXJ5IHRo YXQgY291bGQgcnVuIGEgYnJvd3NlciBvciBvdGhlciBodHRwLWJhc2VkIGFwcHMiIGlzIGEgZ29v ZCB0YXJnZXQuDQpJIHRoaW5rIHRha2luZyBiYXR0ZXJ5IGludG8gYWNjb3VudCBpcyBjcml0aWNh bCAtIGZvciBwaG9uZXMsIHRhYmxldHMgYW5kIGV2ZW4gbGFwdG9wcy4NCg0KSU9UIGFuZCBsaWdo dCBzd2l0Y2ggaXMgaW5kZWVkIGEgZGlmZmVyZW50IHByb2JsZW0gLSBidXQgbW9zdCBvZiB0aGUg dGltZXMgdGhlIHN3aXRjaGVzDQphcmUgc3RpbGwgY29ubmVjdGVkIHRvICdzb21ldGhpbmcgdGhh dCBjYW4gcnVuIGh0dHAnIGFuZCBhY3QgYXMgYSBwcm94eSB0byB0aGVpciBub24tSVANCnByb3Rv Y29scy4NCg0KDQpDb3N0aW4NCg== --_000_1126d24f78e04f9ab72d853b7def1723BL2PR03MB132namprd03pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiYjNDM7MS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlRoYXQgaXMgY29ycmVjdC4gQSBsb3Qgb2YgSW9UIHNjZW5hcmlvcyBhcmUgYWNo aWV2ZWQgdXNpbmcgYSBnYXRld2F5ICh3aXRoIGFuIOKAnGh0dHAtYmFzZWQgYXBw4oCdKSB3aGlj aCByZWxheXMgY29tbXVuaWNhdGlvbnMgdG8gdGhlIGxvd2VyIHBvd2VyZWQg4oCcdGhpbmdz4oCd LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBDb3N0aW4gTWFu b2xhY2hlIFttYWlsdG86Y29zdGluQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVy c2RheSwgT2N0b2JlciAyLCAyMDE0IDI6MTggUE08YnI+DQo8Yj5Ubzo8L2I+IE1hcnRpbiBUaG9t c29uPGJyPg0KPGI+Q2M6PC9iPiBFbGlvIERhbWFnZ2lvOyBpZXNnQGlldGYub3JnOyB3ZWJwdXNo QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbV2VicHVzaF0gQ29tbWVudCBvbiBj aGFydGVyIGFuZCBIVFRQPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBPY3QgMiwg MjAxNCBhdCA5OjE0IEFNLCBNYXJ0aW4gVGhvbXNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcnRp bi50aG9tc29uQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hcnRpbi50aG9tc29uQGdtYWls LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIDEgT2N0b2JlciAyMDE0IDIwOjQ1LCBDb3N0aW4gTWFub2xhY2hlICZs dDs8YSBocmVmPSJtYWlsdG86Y29zdGluQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNvc3Rp bkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IFRoaW5ncyAmcXVvdDt3aXRoIHdl YiBicm93c2VycyZxdW90OyBpbmNsdWRlIHBob25lcyAtIGFuZCBzYXZpbmcgYmF0dGVyeSBpcyBx dWl0ZTxicj4NCiZndDsgY3JpdGljYWwgdGhlcmUuPGJyPg0KJmd0OyBGb3IgZXhhbXBsZSBHQ00g aW5jbHVkZXMgcXVpdGUgYSBmZXcgb3B0aW1pemF0aW9ucyBmb3IgdGhpcy48YnI+DQo8YnI+DQo8 YnI+DQpBYnNvbHV0ZWx5LCBidXQgaWYgd2UgYnVpbGQgYSBzb2x1dGlvbiB0aGF0IGlzIGdvb2Qg Zm9yIGEgbGlnaHQ8YnI+DQpzd2l0Y2gsIHRoYXQgY291bGQgYmUgYSBkaWZmZXJlbnQgc29ydCBv ZiBwcm9wb3NpdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7VGhpbmdzIHdpdGggYSBiYXR0ZXJ5IHRoYXQgY291bGQg cnVuIGEgYnJvd3NlciBvciBvdGhlciBodHRwLWJhc2VkIGFwcHMmcXVvdDsgaXMgYSBnb29kIHRh cmdldC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkkgdGhpbmsgdGFraW5nIGJhdHRlcnkgaW50byBhY2NvdW50IGlzIGNyaXRpY2FsIC0gZm9yIHBo b25lcywgdGFibGV0cyBhbmQgZXZlbiBsYXB0b3BzLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SU9UIGFuZCBsaWdodCBzd2l0Y2gg aXMgaW5kZWVkIGEgZGlmZmVyZW50IHByb2JsZW0gLSBidXQgbW9zdCBvZiB0aGUgdGltZXMgdGhl IHN3aXRjaGVzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5hcmUgc3RpbGwgY29ubmVjdGVkIHRvICdzb21ldGhpbmcgdGhhdCBjYW4gcnVuIGh0dHAn IGFuZCBhY3QgYXMgYSBwcm94eSB0byB0aGVpciBub24tSVAmbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnByb3RvY29scy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Db3N0aW4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_1126d24f78e04f9ab72d853b7def1723BL2PR03MB132namprd03pro_-- From nobody Thu Oct 2 15:27:02 2014 Return-Path: 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 286EA1ACE83 for ; Thu, 2 Oct 2014 15:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 KsWEUv57dAln for ; Thu, 2 Oct 2014 15:26:58 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56A3C1ACE6E for ; Thu, 2 Oct 2014 15:26:58 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by gateway2.nyi.internal (Postfix) with ESMTP id A305720621 for ; Thu, 2 Oct 2014 18:26:57 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Thu, 02 Oct 2014 18:26:57 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= x-sasl-enc:content-type:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; s=mesmtp; bh=diFNj7DTQJx650r8 ZElJL0tTmHk=; b=111Iiu/ul/gS59jLnd+h69oZOpgYbjigwNUTQW+Ks76fhb/c sZDx7AxtZ46C5B3g35UsQK2sj7I9cxXCp7l8BMk1IVzOeSMQS+KLD8fgvErg55e8 72ztFWiOUkSU6ariXpaEuAPIh9+E7JK7jC6K8GrQUOr2frkAFaUnSRD9ZF8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:content-type:mime-version :subject:from:in-reply-to:date:cc:message-id:references:to; s= smtpout; bh=diFNj7DTQJx650r8ZElJL0tTmHk=; b=m8kQsUinTJFO9Xm7PMxh wzyvBsf88pKSt5Eln5f0CewRIVvAI57N7Y4Hn5/7mU0lRFLtKTUhl+bPYs8wWRqR PIgF5WuSg9gA23zTxnTGPrlzh5EuM8+fb9iwIrDDBOzdSnFvlyS5IBUUcfug/NdQ cJqQ9krYbi8X25GRE1rhxXg= X-Sasl-enc: gH+C1jdUiacFoV4nyL0x9puO+a3q7CEOzmThdpOelIlA 1412288817 Received: from [10.35.132.83] (unknown [128.107.239.233]) by mail.messagingengine.com (Postfix) with ESMTPA id D976DC00013; Thu, 2 Oct 2014 18:26:56 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_6AB0ADA4-FCEC-4F6D-ABAE-57E5D0E0A965" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: <1126d24f78e04f9ab72d853b7def1723@BL2PR03MB132.namprd03.prod.outlook.com> Date: Thu, 2 Oct 2014 15:26:55 -0700 Message-Id: References: <1126d24f78e04f9ab72d853b7def1723@BL2PR03MB132.namprd03.prod.outlook.com> To: Elio Damaggio X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/vjoSh0XW4n2rObSwgwHGNeCG99I Cc: Costin Manolache , Martin Thomson , IESG , "webpush@ietf.org" Subject: Re: [Webpush] Comment on charter and HTTP 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 22:27:00 -0000 --Apple-Mail=_6AB0ADA4-FCEC-4F6D-ABAE-57E5D0E0A965 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 My impression is that the scoping issue discussed in this thread is = covered by the existing charter text (which highlights battery-powered = devices) plus the proposed addition of specifying that the WG will work = on an =93HTTP-based=94 protocol. Shout if you disagree. Alissa On Oct 2, 2014, at 2:20 PM, Elio Damaggio wrote: > +1. > =20 > That is correct. A lot of IoT scenarios are achieved using a gateway = (with an =93http-based app=94) which relays communications to the lower = powered =93things=94. > =20 > From: Costin Manolache [mailto:costin@gmail.com]=20 > Sent: Thursday, October 2, 2014 2:18 PM > To: Martin Thomson > Cc: Elio Damaggio; iesg@ietf.org; webpush@ietf.org > Subject: Re: [Webpush] Comment on charter and HTTP > =20 > =20 > =20 > On Thu, Oct 2, 2014 at 9:14 AM, Martin Thomson = wrote: > On 1 October 2014 20:45, Costin Manolache wrote: > > Things "with web browsers" include phones - and saving battery is = quite > > critical there. > > For example GCM includes quite a few optimizations for this. >=20 >=20 > Absolutely, but if we build a solution that is good for a light > switch, that could be a different sort of proposition > =20 > "Things with a battery that could run a browser or other http-based = apps" is a good target. > I think taking battery into account is critical - for phones, tablets = and even laptops. =20 > =20 > IOT and light switch is indeed a different problem - but most of the = times the switches > are still connected to 'something that can run http' and act as a = proxy to their non-IP=20 > protocols. > =20 > =20 > Costin=20 --Apple-Mail=_6AB0ADA4-FCEC-4F6D-ABAE-57E5D0E0A965 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
My impression is that the scoping issue = discussed in this thread is covered by the existing charter text (which = highlights battery-powered devices) plus the proposed addition of = specifying that the WG will work on an =93HTTP-based=94 protocol. Shout = if you disagree.

Alissa

On = Oct 2, 2014, at 2:20 PM, Elio Damaggio <elioda@microsoft.com> = wrote:

+1.
 
That is correct. A lot of = IoT scenarios are achieved using a gateway (with an =93http-based app=94) = which relays communications to the lower powered = =93things=94.
 
From: Costin Manolache [mailto:costin@gmail.com] 
Sent: Thursday, October 2, 2014 = 2:18 PM
To: Martin = Thomson
Cc: Elio Damaggio; iesg@ietf.org; webpush@ietf.org
Subject: Re: [Webpush] Comment = on charter and HTTP
 
 
 
On = Thu, Oct 2, 2014 at 9:14 AM, Martin Thomson <martin.thomson@gmail.com> = wrote:
On 1 October 2014 20:45, Costin Manolache <costin@gmail.com> = wrote:
> Things "with web browsers" include phones - and saving = battery is quite
> critical there.
> For example GCM = includes quite a few optimizations for this.


Absolutely, but = if we build a solution that is good for a light
switch, that could be = a different sort of proposition
 
"Things with a battery that could run a browser or = other http-based apps" is a good target.
I think taking battery into account is critical - = for phones, tablets and even laptops. =  
 
IOT = and light switch is indeed a different problem - but most of the times = the switches
are = still connected to 'something that can run http' and act as a proxy to = their non-IP 
protocols.
 
 
Costin 

= --Apple-Mail=_6AB0ADA4-FCEC-4F6D-ABAE-57E5D0E0A965-- From nobody Thu Oct 2 16:55:31 2014 Return-Path: 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 ABCA51A8827; Thu, 2 Oct 2014 16:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 3gZ5fY6U33Sh; Thu, 2 Oct 2014 16:55:27 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 421691A86F9; Thu, 2 Oct 2014 16:55:27 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id gi9so139892lab.19 for ; Thu, 02 Oct 2014 16:55:25 -0700 (PDT) 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:content-transfer-encoding; bh=b0pTmOtfHHw1yhQ3YkE0+ywbZMO3xxiNxs9IgtAtjRg=; b=XHjhbJ/HIlNw62NZaZYCWpx6ypINpUOhUScH4BhCWR2CCitcck3hxzXzdezl+gPD2Z iHW1AGHpZ4r++qaKA6Adak2meoqmoP+O9bOW6ck+qJ0/vc2pGXr/GEJiaubFyXzi1zdn ZGLrPYpcSZW3ui01Wgw/Xr188E3yvOYkh7uky4JQtfJQOR1xe2ZS0H0ZSZuoupfxBH1H NVt4d9ih65URuwOwIGT0fm9+udlp5s4Snm2zcw/++AJeuxU7UCEItJ9X96NLUSuxbG4M 6t2YZBZpjxbKnlO+d5YjQ8cs6xIgtoHBO+ZQpfxSYO1GvanFq9csOxXPxI9uRYTrFTzI 2v+A== MIME-Version: 1.0 X-Received: by 10.152.9.132 with SMTP id z4mr2096576laa.8.1412294125502; Thu, 02 Oct 2014 16:55:25 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Thu, 2 Oct 2014 16:55:25 -0700 (PDT) In-Reply-To: References: <1126d24f78e04f9ab72d853b7def1723@BL2PR03MB132.namprd03.prod.outlook.com> Date: Thu, 2 Oct 2014 16:55:25 -0700 Message-ID: From: Martin Thomson To: Alissa Cooper Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/rfhyNReXBIRfISlziMVrZZHumNQ Cc: Costin Manolache , IESG , "webpush@ietf.org" , Elio Damaggio Subject: Re: [Webpush] Comment on charter and HTTP 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 23:55:29 -0000 On 2 October 2014 15:26, Alissa Cooper wrote: > My impression is that the scoping issue discussed in this thread is cover= ed > by the existing charter text (which highlights battery-powered devices) p= lus > the proposed addition of specifying that the WG will work on an =E2=80=9C= HTTP-based=E2=80=9D > protocol. Shout if you disagree. Yep. Saying HTTP-based is almost orthogonal, but it does cut out the absolute bottom end. Better efficiency for everything that needs efficiency is a stretch, but if we can make it better for a low-end phone, we're probably still making it better for all other devices on Costin's list. ...and maybe even for those devices that are attached to a power plant by a long piece of metal. From nobody Fri Oct 3 08:55:31 2014 Return-Path: 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 AF5551A035D for ; Fri, 3 Oct 2014 08:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 xDGK2QU4H8s3 for ; Fri, 3 Oct 2014 08:55:25 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 809BA1A0337 for ; Fri, 3 Oct 2014 08:55:25 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by gateway2.nyi.internal (Postfix) with ESMTP id 92E25208ED for ; Fri, 3 Oct 2014 11:55:24 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Fri, 03 Oct 2014 11:55:24 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= x-sasl-enc:content-type:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; s=mesmtp; bh=W1da6vjh56Z3qiMK qq8htER8Ucg=; b=Qvs1ATTdUB4K9cGQfnDHHSzyu9qAAhY9TbKwVbiu73/ynF6u /iPq6SAd4CMeRATDASAgX5Hi3VLUCsqyq9IgiNPSxJAQ4I1nNTPoWjrVoAlFW9Sv aKjHfwwuiy+1i1/B1vWlUjZ/7VP2QeCwqZcNXQt/MDNuUFcFF5NBJIbRkbA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:content-type:mime-version :subject:from:in-reply-to:date:cc:message-id:references:to; s= smtpout; bh=W1da6vjh56Z3qiMKqq8htER8Ucg=; b=U1M+hzrebV7OYfVs7mJg 6gCYc9PRWatL1y+/S82dfrVRHEwkGzU0TTtgAU7iBLOjZM4Oj1917NIDPeE6DavW Qu2Jkd8lxJECO8Tw3zEy1GQFrY5/mA72z54yrEHgRtyRlN/JZqV10cgVd9c5uVUI ePLqmst3rht4Ebb4NafzmEA= X-Sasl-enc: svuhm4Ee4dlJdFjGIoHAN1piG1bRnOFuAKzDWIQlBndG 1412351724 Received: from sjc-vpn5-339.cisco.com (unknown [128.107.239.235]) by mail.messagingengine.com (Postfix) with ESMTPA id A2C6EC0000E; Fri, 3 Oct 2014 11:55:23 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_909216E8-B421-4B9F-909A-CB7B8337971B" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: <0D99B723-35B2-40F1-BB57-FC06E04E37FA@cs.tcd.ie> Date: Fri, 3 Oct 2014 08:55:22 -0700 Message-Id: <45B0EA2A-BC54-4CE0-835E-CD1881DDCDD0@cooperw.in> References: <20141002150523.27303.68943.idtracker@ietfa.amsl.com> <41FE6C7F-EBC6-4A68-A337-7BCD106D13F4@cooperw.in> <20A44D92-7395-45BF-A4C8-666BEA3271EF@cooperw.in> <0D99B723-35B2-40F1-BB57-FC06E04E37FA@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/Oqb3AhNujz7RQSfywL9h8u_DqZs Cc: Martin Thomson , IESG , "webpush@ietf.org" Subject: Re: [Webpush] Stephen Farrell's Block on charter-ietf-webpush-00-01: (with BLOCK) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 15:55:27 -0000 --Apple-Mail=_909216E8-B421-4B9F-909A-CB7B8337971B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I=92ve updated the charter text: = http://datatracker.ietf.org/doc/charter-ietf-webpush/ Once Stephen unblocks, I=92ll send this to the secretariat for = chartering. Alissa On Oct 2, 2014, at 11:00 AM, Stephen Farrell = wrote: > On 2 October 2014 18:40:25 IST, Alissa Cooper = wrote: >> I had some further off-line discussion with Stephen to work in a few >> more clarifications, and here is what I suggest as a result: >>=20 >> "The WG will aim to minimize the amount of additional information = that >> is revealed to the push notification service. It must be possible = for >> the application to apply end-to-end security mechanisms so that >> messages sent via the push notification service cannot be read or >> modified by the push notification service. The WG will also consider >> additional privacy protections, including the ability to prevent the >> push notification service from gleaning other types of information, >> such as the association between an application and a specific user.=94 >=20 > Lovely. Happy to unblock on that basis once back online. >=20 > Ta, > S. >=20 >=20 >>=20 >> I think for the =93HTTP-based=94 bit we can do the following in the = charter >> 3rd para: >>=20 >> s/This working group will develop a protocol/This working group will >> develop an HTTP-based protocol/ >>=20 >> I=92d like to get these changes posted in a day or two assuming = Stephen=92s >> concerns are satisfied and there are no further objections. >>=20 >> Thanks, >> Alissa >>=20 >> On Oct 2, 2014, at 9:30 AM, Martin Thomson >> wrote: >>=20 >>> On 2 October 2014 09:27, Alissa Cooper wrote: >>>> "The output of the WG should be able to support end-to-end = integrity >> and confidentiality protections for the data being pushed, as well as >> the ability to prevent the push server from associating users with >> applications.=94 >>>=20 >>> That is something I can buy in to. >>>=20 >>> Adding "HTTP-based" is also OK. >=20 >=20 > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush --Apple-Mail=_909216E8-B421-4B9F-909A-CB7B8337971B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

On= ce Stephen unblocks, I=92ll send this to the secretariat for = chartering.

Alissa

On Oct 2, 2014, at 11:00 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie>= ; wrote:

On 2 October 2014 18:40:25 IST, = Alissa Cooper <alissa@cooperw.in> = wrote:
I had some further off-line = discussion with Stephen to work in a few
more clarifications, and = here is what I suggest as a result:

"The WG will aim to minimize = the amount of additional information that
is revealed to the push = notification service.  It must be possible for
the application = to apply end-to-end security mechanisms so that
messages sent via the = push notification service cannot be read or
modified by the push = notification service.  The WG will also consider
additional = privacy protections, including the ability to prevent the
push = notification service from gleaning other types of information,
such = as the association between an application and a specific = user.=94

Lovely. Happy to unblock on that basis once = back online.

Ta,
S.



I = think for the =93HTTP-based=94 bit we can do the following in the = charter
3rd para:

s/This working group will develop a = protocol/This working group will
develop an HTTP-based = protocol/

I=92d like to get these changes posted in a day or two = assuming Stephen=92s
concerns are satisfied and there are no further = objections.

Thanks,
Alissa

On Oct 2, 2014, at 9:30 AM, = Martin Thomson <martin.thomson@gmail.com><= br>wrote:

On 2 October 2014 09:27, = Alissa Cooper <alissa@cooperw.in> = wrote:
"The output of the WG should be able = to support end-to-end integrity
and = confidentiality protections for the data being pushed, as well as
the = ability to prevent the push server from associating users = with
applications.=94

That is = something I can buy in to.

Adding "HTTP-based" is also = OK.


_________________________________= ______________
Webpush mailing list
Webpush@ietf.org
https://www.ietf.or= g/mailman/listinfo/webpush

= --Apple-Mail=_909216E8-B421-4B9F-909A-CB7B8337971B-- From nobody Fri Oct 3 10:33:43 2014 Return-Path: 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 9EBB81A8785; Fri, 3 Oct 2014 10:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 C7d_gn_W9ocW; Fri, 3 Oct 2014 10:33:37 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75F901A8752; Fri, 3 Oct 2014 10:33:36 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hi2so2818271wib.14 for ; Fri, 03 Oct 2014 10:33:35 -0700 (PDT) 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=zzboejDTOgMEC/7W9KHnyZXZVrex9b7Ew/g7I6GwNKE=; b=DNNMGvNE0jLhksCVZF4Z7zsk5dAErXPjV1ChlacavKcSPOdc/W9S1TFLjPwFfMjO/V S30fD+hemDtjNErOvDjLKcT+UYCZSkAUG+gHKMBRQKmzlY/mFi+8+0fdxPi2oc4LdImM 1mjPBxm4RowNta5m+HF+g2XeFldPh1oX8xhs6HgznQnW6HL3PGavBhy6p4LfKt3qZR4x kiN8ByHkG7hoz4Y3PeCn4DuvZ14VnSyvbrmfOzyatadyCdGB+L8R7sc6mEtFaNiKLCDZ Z0gVEiyuj68Sqt+d1sw0CNWS1VZ23oOmZXVwbHsLv1a7hqzCvgYcQMPU4GkCfZ5ZU+O9 3hKw== MIME-Version: 1.0 X-Received: by 10.194.94.196 with SMTP id de4mr9670968wjb.86.1412357615014; Fri, 03 Oct 2014 10:33:35 -0700 (PDT) Received: by 10.216.166.201 with HTTP; Fri, 3 Oct 2014 10:33:34 -0700 (PDT) In-Reply-To: References: <1126d24f78e04f9ab72d853b7def1723@BL2PR03MB132.namprd03.prod.outlook.com> Date: Fri, 3 Oct 2014 10:33:34 -0700 Message-ID: From: Costin Manolache To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7bb03ebaf05c620504882157 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/KuhHd1QJ_7si-dx1XuMPTSyTuC4 Cc: Alissa Cooper , IESG , "webpush@ietf.org" , Elio Damaggio Subject: Re: [Webpush] Comment on charter and HTTP 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 17:33:38 -0000 --047d7bb03ebaf05c620504882157 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable As long as "HTTP-based" doesn't explicitly exclude the use of non-HTTP protocols in parts of the system implementation - I think all is good. Beside battery, the 'chattiness' and bandwidth usage are important on mobile networks, so some parts may need to be optimized for the last mile. Costin On Thu, Oct 2, 2014 at 4:55 PM, Martin Thomson wrote: > On 2 October 2014 15:26, Alissa Cooper wrote: > > My impression is that the scoping issue discussed in this thread is > covered > > by the existing charter text (which highlights battery-powered devices) > plus > > the proposed addition of specifying that the WG will work on an > =E2=80=9CHTTP-based=E2=80=9D > > protocol. Shout if you disagree. > > Yep. Saying HTTP-based is almost orthogonal, but it does cut out the > absolute bottom end. > > Better efficiency for everything that needs efficiency is a stretch, > but if we can make it better for a low-end phone, we're probably still > making it better for all other devices on Costin's list. ...and maybe > even for those devices that are attached to a power plant by a long > piece of metal. > --047d7bb03ebaf05c620504882157 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As long as "HTTP-based" doesn't explicitly e= xclude the use of non-HTTP protocols in
=C2=A0parts of the system imple= mentation - I think all is good.
Beside battery, the 'chattiness= 9; and bandwidth usage are important on mobile networks, so some parts
may need to be optimized for the last mile.

=
Costin=C2=A0
On Thu, Oct 2, 2014 at 4:55 PM, Martin Thomson = <martin.thomson@gmail.com> wrote:
On 2 October 2014 15:26, Alissa Cooper <= alissa@cooperw.in> wrote:
> My impression is that the scoping issue discussed in this thread is co= vered
> by the existing charter text (which highlights battery-powered devices= ) plus
> the proposed addition of specifying that the WG will work on an =E2=80= =9CHTTP-based=E2=80=9D
> protocol. Shout if you disagree.

Yep.=C2=A0 Saying HTTP-based is almost orthogonal, but it does cut o= ut the
absolute bottom end.

Better efficiency for everything that needs efficiency is a stretch,
but if we can make it better for a low-end phone, we're probably still<= br> making it better for all other devices on Costin's list.=C2=A0 ...and m= aybe
even for those devices that are attached to a power plant by a long
piece of metal.

--047d7bb03ebaf05c620504882157-- From nobody Fri Oct 3 10:40:34 2014 Return-Path: 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 0C2D01A877E; Fri, 3 Oct 2014 10:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 kwvY8aVJHHjG; Fri, 3 Oct 2014 10:40:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E67B71A03E1; Fri, 3 Oct 2014 10:40:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141003174029.22184.52496.idtracker@ietfa.amsl.com> Date: Fri, 03 Oct 2014 10:40:29 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/3KYGV7W37gGj9VV0xxVkHlybrEk Cc: webpush@ietf.org Subject: [Webpush] Stephen Farrell's Yes on charter-ietf-webpush-00-02: (with COMMENT) X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 03 Oct 2014 17:40:31 -0000 Stephen Farrell has entered the following ballot position for charter-ietf-webpush-00-02: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-webpush/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for putting in that security/privacy text. With that, this sounds like an excellent plan. From nobody Fri Oct 3 13:57:27 2014 Return-Path: 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 84E731A6F98 for ; Fri, 3 Oct 2014 13:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 u5QZ5nwmESvS for ; Fri, 3 Oct 2014 13:57:24 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F6B91A6FB6 for ; Fri, 3 Oct 2014 13:57:21 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by gateway2.nyi.internal (Postfix) with ESMTP id 85EEF2090D for ; Fri, 3 Oct 2014 16:57:20 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Fri, 03 Oct 2014 16:57:20 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= x-sasl-enc:content-type:mime-version:subject:from:date:cc :content-transfer-encoding:message-id:to; s=mesmtp; bh=G/4a5QG2K OJJi1zNEhWjP3ZZaAw=; b=t3ifn39Xzzruee7wgdFinSdZYHwsPSBODtrSK02Bv dHX1q1DmVJdKkzHJpN880yLbJQAb26dm62dlNMpxPGkQ191YIJbadXKA9982kBWZ ufjjLt2w+LMPZanOTy4Z1OU5HA5sQaACbYl5T4iUHEE61eAoOL9AwLbwKtcHifly JY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:content-type:mime-version :subject:from:date:cc:content-transfer-encoding:message-id:to; s=smtpout; bh=G/4a5QG2KOJJi1zNEhWjP3ZZaAw=; b=MpZmIOH3pCd7jCBuU d6bOWqJsYMZ3T4KfIS2MomdHGSh0eEc3Sq7vA8l9Of8TQPrsDQdImt0a0nwadtiv GN6zhq+75U/cbcsCXei12Y6XUiutdGkkPN8D5Lm54PqI/cKQlXuKJLvOtdHNjovH EYTmTXNOsJ2VsDI9XIJYajpn5I= X-Sasl-enc: U2jD94WWsGbr+ptEd8ECPrGDCzSMriDOQ1Q/pI8lUsp+ 1412369840 Received: from sjc-vpn5-339.cisco.com (unknown [128.107.239.234]) by mail.messagingengine.com (Postfix) with ESMTPA id AF74CC00011; Fri, 3 Oct 2014 16:57:19 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper Date: Fri, 3 Oct 2014 13:57:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9ECA60C4-C404-43B4-8D87-67CA63922804@cooperw.in> To: IESG X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/oih4-DDJlWJa6UN18Evn5hFtfgo Cc: "Joe Hildebrand \(jhildebr\)" , webpush@ietf.org, shidaschubert@gmail.com Subject: [Webpush] Approved: webpush WG 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 20:57:24 -0000 Webpush is approved as a new WG. Chairs are Shida Schubert and Joe = Hildebrand. Their contact info is in the tracker. Alissa= From nobody Wed Oct 8 17:15:56 2014 Return-Path: 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 78FCE1A6FAA for ; Wed, 8 Oct 2014 17:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 HC-3CkoNkmJe for ; Wed, 8 Oct 2014 17:15:32 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 462071A01CB for ; Wed, 8 Oct 2014 17:15:29 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id mk6so169883lab.1 for ; Wed, 08 Oct 2014 17:15:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=5eHZHSw1XVw2NPtbhyAqlKnqtgUTgUvnFjoCYgvX3ls=; b=TWMFPwIkbU2EXxh5NogkWSWT7ZqDSO4YRSj4ativiiy6IOtsoVmSh8iAL7VOcXcTSq WMKsdWyrv0vptlJKB6zGMGiezkVmXZGBsPxv6shf7YEqODHPbLk+BTxOuThJW5mNUWiI rt7Tnh8OpybJBhtMply/4s8DcWxzXKVAUP9UWHMoYQAhCjq8D58iG/CIHknN7PrpJsZy ZUV0c/Ixv/KNxP/1GTsqo/u/vYR0B+Eiz6ShX8oBQWBdQ4aRcUf57L4lsCo/5HBjz2vn 49Wob5RGYeTgHLGFvtsymjPRJntAcjkGfRwzQU7bZ4sZmP6Z9LlZ+4R8JRGQWj5LyANq 0ESA== MIME-Version: 1.0 X-Received: by 10.152.43.50 with SMTP id t18mr7255073lal.91.1412813727576; Wed, 08 Oct 2014 17:15:27 -0700 (PDT) Received: by 10.25.215.217 with HTTP; Wed, 8 Oct 2014 17:15:27 -0700 (PDT) Date: Wed, 8 Oct 2014 17:15:27 -0700 Message-ID: From: Martin Thomson To: "webpush@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/ujpJ6fckxMziJlVU2Ir0yUmr2WA Subject: [Webpush] Protocol proposal updated 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 00:15:38 -0000 I've just submitted an updated version of my push protocol proposal: https://tools.ietf.org/html/draft-thomson-webpush-http2 And a new proposal that builds on the first for dealing with the delivery of the same message to multiple recipients: https://tools.ietf.org/html/draft-thomson-webpush-aggregate One feature of these proposals is that they assume the presence of something in the W3C API that is not currently there related to push message security. If the API can force end-to-end security, I think it would be strictly a good thing. I'm happy to articulate the proposed solution, or you can read my proposal here: https://github.com/w3c/push-api/issues/55 From nobody Wed Oct 8 17:49:20 2014 Return-Path: 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 5FDB71A87DF for ; Wed, 8 Oct 2014 17:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Bdy1HPbLUmcV for ; Wed, 8 Oct 2014 17:49:18 -0700 (PDT) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C96961A87DB for ; Wed, 8 Oct 2014 17:49:17 -0700 (PDT) Received: by mail-qc0-f174.google.com with SMTP id m20so184630qcx.33 for ; Wed, 08 Oct 2014 17:49:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ef+gX8yndKG3wQyS2DopU51ahO0peZVUkGAD55vGbSo=; b=e3sivrfc+/JO7R+GECS0nq4U5aqd3Uf4VnspXl6xlAiFeq+uo3IxAG7RHNBQX445zm E+Wh2UITdnWDYJAR0FpG+G1CUr8iY6AflEiXhiTp9VuNCoTSneDPKnOkVLQgOl03RPCA 4mMC5gvNlljkax8oiFCW3ToIOKApmc7dxHjeZFIERtLnLhPXmk9iVcKT01wegjWzm/dd UxcfMXXgnFaNt6/07TO8qqEzaxstZtYJrnIDEKTIIQfElymLRRfpsVBZk+Xmx8jDZqN5 wCMYvoovDFT00QcdyUbjugfQssqTDJ3iXI+39BBAUHzLbwGczzwgV/YuQ21tIf7sBklR +QLw== X-Received: by 10.140.84.84 with SMTP id k78mr31331628qgd.80.1412815756949; Wed, 08 Oct 2014 17:49:16 -0700 (PDT) Received: from Barstow-MBP.local (c-71-232-127-252.hsd1.ma.comcast.net. [71.232.127.252]) by mx.google.com with ESMTPSA id j91sm1185925qgj.31.2014.10.08.17.49.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 Oct 2014 17:49:16 -0700 (PDT) Message-ID: <5435DB8B.3040202@gmail.com> Date: Wed, 08 Oct 2014 20:49:15 -0400 From: Arthur Barstow User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "webpush@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/mFmcc6-Frngzpf57Jh3jyu1gaGU Subject: Re: [Webpush] Protocol proposal updated 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 00:49:19 -0000 On 10/8/14 8:15 PM, Martin Thomson wrote: > I've just submitted an updated version of my push protocol proposal: > > https://tools.ietf.org/html/draft-thomson-webpush-http2 Speaking of new publications, FYI, on October 7 a new snapshot of Push API was published [WD], although the Editor's Draft [ED] reflects the latest developments (f.ex. bug fixes). [WD] [ED] From nobody Fri Oct 10 11:52:59 2014 Return-Path: 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 C75E91ACDE9 for ; Fri, 10 Oct 2014 11:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 aAw8KF5ioJin for ; Fri, 10 Oct 2014 11:52:56 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4399E1ACDBD for ; Fri, 10 Oct 2014 11:52:56 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hi2so2969660wib.2 for ; Fri, 10 Oct 2014 11:52:54 -0700 (PDT) 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=xb7qKzpsnNykdXFtGKufklR4HOWcAuSKj17izUZYF9U=; b=0HgnhVgNjlsfVz72glhNhBegvy3CDLgaPbNmJ0bJin1udcpBaoUA3pzFPUiTUSBt0u sLLAOOGu0ijI71peKqgYnvzOEEuLslwHHXczOC/58VQ5WrSN2vz3gb/Dnm++BrIjlKgo h5oa33/AmOGMYeISaVaxI4l43jvKak0C+9QxWLDEMyt9mAtmAt/Ae7tlSb+0avi75SAm 0BxjSoVbWK5mjW7hN7Idyw0k8/BzeJrzZjBP8T5b6MasthEt8Pc6ugkz5Y4clN8PJREO fd0Vif8iDazRtIGRct5Sulpoz+MMpJP7karC8ZMfq3FeRXfcgfLE6lMQIPZWM8kMT3Nb 5JRw== MIME-Version: 1.0 X-Received: by 10.194.23.106 with SMTP id l10mr4740574wjf.123.1412967174865; Fri, 10 Oct 2014 11:52:54 -0700 (PDT) Received: by 10.217.63.202 with HTTP; Fri, 10 Oct 2014 11:52:54 -0700 (PDT) In-Reply-To: References: Date: Fri, 10 Oct 2014 11:52:54 -0700 Message-ID: From: Costin Manolache To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7b472548898aef0505160e31 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/GVLOvIIY-GD7vHEUJRoqg_wPdWE Cc: "webpush@ietf.org" Subject: Re: [Webpush] Protocol proposal updated 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 18:52:59 -0000 --047d7b472548898aef0505160e31 Content-Type: text/plain; charset=UTF-8 I have a few small suggestions - I'll start with what is more blocking: 1. The push server needs some way to authenticate the sender. I understand the Channel URL is used as a bearer token ( which is probably not a good idea, but separate issue ), and UA can reject the message if the encryption fails, but the push server still needs to deliver the message if the bearer token ( channel URL ) becomes compromised. The push server may also need quotas or TOS agreements (or in some cases billing ? not all push servers are free) with the sender. 2. Expiration: this creates some load problems if too many devices attempt to re-register at the same time. It would be preferable for the push server to request renewal of registration or channel - it can do this with special control messages send from the push server. This will also allow the server to address some special use cases - device registration that become invalid (it happens after some backup/restore for example, or on storage corruption on low memory, and few other obscure cases) or for security reasons, if keys need to be rotated or invalidated. 3. Authentication - I think some form of authentication is needed in all layers, use of the URL as auth, server address and identity is not very common. The registration, channel and sender all need to authenticate with either shared secrets, oauthx or certificates - and the auth needs to be managed separately, i.e. tokens may need to be rotated, invalidated, etc. 4. Encryption of messages - it needs to be specified what format it is - can be simple openpgp (rfc4880), or anything else. Otherwise no interoperability. It seems the rfc requires encryption, which is great, but it still need more authentication than 'can't decrypt the message'. I'm also not sure if using the public key of the channel as a secret is the best option - but it may work (usually public keys are treated as public). Costin On Wed, Oct 8, 2014 at 5:15 PM, Martin Thomson wrote: > I've just submitted an updated version of my push protocol proposal: > > https://tools.ietf.org/html/draft-thomson-webpush-http2 > > And a new proposal that builds on the first for dealing with the > delivery of the same message to multiple recipients: > > https://tools.ietf.org/html/draft-thomson-webpush-aggregate > > One feature of these proposals is that they assume the presence of > something in the W3C API that is not currently there related to push > message security. If the API can force end-to-end security, I think > it would be strictly a good thing. I'm happy to articulate the > proposed solution, or you can read my proposal here: > > https://github.com/w3c/push-api/issues/55 > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > --047d7b472548898aef0505160e31 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have a few small suggestions - I'll start with what = is more blocking:

1. The push server needs some way= to authenticate the sender. I understand the Channel URL is used as a bear= er token ( which is probably not=C2=A0
a good idea, but separate = issue ), and UA can reject the message if the encryption fails, but the pus= h server still needs to deliver
the message if the bearer token (= channel URL ) becomes compromised.
The push server may also need= quotas or TOS agreements (or in some cases billing ? not all push servers = are free) with the sender.

2. Expiration: this cre= ates some load problems if too many devices attempt to re-register at the s= ame time. It would be preferable for the push server
to request r= enewal of registration or channel - it can do this with special control mes= sages send from the push server.
This will also allow the server = to address some special use cases - device registration that become invalid= (it happens after some backup/restore for example,
or on storage= corruption on low memory, and few other obscure cases) or for security rea= sons, if keys need to be rotated or invalidated.

3= . Authentication - I think some form of authentication is needed in all lay= ers, use of the URL as auth, server address and identity is not very common= .
The registration, channel and sender all need to authenticate w= ith either shared secrets, oauthx or certificates - and the auth needs to
be managed separately, i.e. tokens may need to be rotated, invalid= ated, etc.

4. Encryption of messages - it needs to= be specified what format it is - can be simple openpgp (rfc4880), or anyth= ing else. Otherwise no interoperability.
It seems the rfc require= s encryption, which is great, but it still need more authentication than &#= 39;can't decrypt the message'. I'm also not sure if using the
=C2=A0public key of the channel as a secret is the best option - b= ut it may work (usually public keys are treated as public).


Costin

On Wed, Oct 8, 2014 at 5:15 PM, Martin Thom= son <martin.thomson@gmail.com> wrote:
I've just submitted an updated version of my push pr= otocol proposal:

https://tools.ietf.org/html/draft-thomson-webpush-http2

And a new proposal that builds on the first for dealing with the
delivery of the same message to multiple recipients:

https://tools.ietf.org/html/draft-thomson-webpush-aggregate<= /a>

One feature of these proposals is that they assume the presence of
something in the W3C API that is not currently there related to push
message security.=C2=A0 If the API can force end-to-end security, I think it would be strictly a good thing.=C2=A0 I'm happy to articulate the proposed solution, or you can read my proposal here:

htt= ps://github.com/w3c/push-api/issues/55

_______________________________________________
Webpush mailing list
Webpush@ietf.org
https://www.ietf.org/mailman/listinfo/webpush

--047d7b472548898aef0505160e31-- From nobody Fri Oct 10 12:53:20 2014 Return-Path: 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 EA6421ACF54 for ; Fri, 10 Oct 2014 12:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 XU4qthAxwTNL for ; Fri, 10 Oct 2014 12:53:17 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D35C31ACF02 for ; Fri, 10 Oct 2014 12:53:16 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id l4so3738826lbv.24 for ; Fri, 10 Oct 2014 12:53:15 -0700 (PDT) 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=p+1l40Q32RRlDV4Gx7z6uVC7d+rVJRI+h7cZU7qAfmU=; b=iksUPlR2A+4Qd/5KzJe2T7CRAPiB4pLYNgNxpNUhNeLkazwdQMCEm7eDf8F/AMDDlS 7Ur8WvOagrJOL/V1RNpHDeDBwy+pL+YYJhwloP9R25iSqf0XTun4rVptWeuPtgCoBy8p znjZf3MldqbNxT7YgiV6kEIPMLG+0GuOK7D3Tl/eOkJ04n7aZA6shFG4N5R4BzQvsS2V pPxnlrwxtlu9G5X7Q3xHMgWKpUb2FCV/DpAISvkz99rCculR88WCpWCicCb4r1MvfP8p 2slKWS8dkB6zPYLiEGyxhMQ1MZcx6FzOK5eQTakIF15lynIx+h61b8ikOhqovEyxO+13 6gbg== MIME-Version: 1.0 X-Received: by 10.112.140.137 with SMTP id rg9mr5741560lbb.93.1412970794883; Fri, 10 Oct 2014 12:53:14 -0700 (PDT) Received: by 10.25.215.217 with HTTP; Fri, 10 Oct 2014 12:53:14 -0700 (PDT) In-Reply-To: References: Date: Fri, 10 Oct 2014 12:53:14 -0700 Message-ID: From: Martin Thomson To: Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/P0r0O_98JVvQ0R0XLwybQ-o44BA Cc: "webpush@ietf.org" Subject: Re: [Webpush] Protocol proposal updated 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 19:53:19 -0000 Thanks for the feedback Costin, These are things that I have considered, and they do need to be better addressed in the draft. I want to open a new thread about the two questions you asked on authentication, because I think authentication is a big deal and it ties into a lot of things. If we don't have some sort of common understanding about how this works, we're not going to get far. The other two points are, I think, less of a concern. On 10 October 2014 11:52, Costin Manolache wrote: > 2. Expiration: this creates some load problems if too many devices attempt > to re-register at the same time. It would be preferable for the push server > to request renewal of registration or channel - it can do this with special > control messages send from the push server. This is something that proprietary protocols already have to deal with, certainly. You can either let clients deal with it and suffer the stampeding herd problems that come when clients re-register en-masse, or you can trigger something. While it's not explicit, an HTTP-based protocol, as proposed, permits a server to expire a registration at any time. This could trigger re-registration. The server can do that by providing a response to the hanging GET that we use to monitor for pushed messages. This has the intended effect, though the process remains under the control of clients. > 4. Encryption of messages - it needs to be specified what format it is - can > be simple openpgp (rfc4880), or anything else. Otherwise no > interoperability. > It seems the rfc requires encryption, which is great, but it still need more > authentication than 'can't decrypt the message'. I'm also not sure if using > the > public key of the channel as a secret is the best option - but it may work > (usually public keys are treated as public). I can see how this might be confusing. Yes. There definitely needs to be a format specification for the encrypted message. But at the level of the protocol itself, there is only one place that matters (you will see this in the -aggregate draft). The thing here is that there should be no need to enforce format restrictions at the protocol level. It's the browser API that ultimately will care that the message is encrypted (and decryptable). I'm going to propose that we use the JSON encoding of JWE (again see the -aggregate draft), but that is something that will land in the W3C specification ultimately. From nobody Fri Oct 10 13:42:32 2014 Return-Path: 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 F2CF31AD0BC for ; Fri, 10 Oct 2014 13:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 6SK-KGiS2CJg for ; Fri, 10 Oct 2014 13:42:28 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 171B61AD0BB for ; Fri, 10 Oct 2014 13:42:27 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id x13so4773922wgg.18 for ; Fri, 10 Oct 2014 13:42:26 -0700 (PDT) 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=Vvf+Yk3dStBvNgwcuYh8SpFnQB0MznEK0SfQWZamBxE=; b=m8Dmc0vs1G2c25nEm+HrWbNjmekAEYcKHX5eTRrqLxmnEWIFIEMVUtZ5PYIa0Hl6xw Yup7/od8eE9mIfIW1jeG3Xx6IRZiLXs6BRS5lI6E/byaoYdLFaYoJFWgDzLRUodGNRQt e6k6e3P14m3QhTwhXrB9NS9u6Nc97Un+wQi7MkOnp57prQVQqw2Z58xv5Z0mCqoTUbgG rukzPDnl5CiDa7RtHZuPD4qNH5tq1uNZ37xhePuLHsSUh3Plt4IWWqoqTFYuxNUm4sZc 2UBlzO5ZCHJz961QosFxzFTNRyjKDo2zhk9J9prznXbGm//tV+yt43nSgTStzG72DQqs 70nA== MIME-Version: 1.0 X-Received: by 10.194.241.229 with SMTP id wl5mr2454443wjc.53.1412973746747; Fri, 10 Oct 2014 13:42:26 -0700 (PDT) Received: by 10.217.63.202 with HTTP; Fri, 10 Oct 2014 13:42:26 -0700 (PDT) In-Reply-To: References: Date: Fri, 10 Oct 2014 13:42:26 -0700 Message-ID: From: Costin Manolache To: Martin Thomson Content-Type: multipart/alternative; boundary=089e01493cac407eea0505179649 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/FeDwFj761hPFHmSmc_iOPkxrSL4 Cc: "webpush@ietf.org" Subject: Re: [Webpush] Protocol proposal updated 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 20:42:31 -0000 --089e01493cac407eea0505179649 Content-Type: text/plain; charset=UTF-8 On Fri, Oct 10, 2014 at 12:53 PM, Martin Thomson wrote: > Thanks for the feedback Costin, > > These are things that I have considered, and they do need to be better > addressed in the draft. I want to open a new thread about the two > questions you asked on authentication, because I think authentication > is a big deal and it ties into a lot of things. If we don't have some > sort of common understanding about how this works, we're not going to > get far. > > The other two points are, I think, less of a concern. > > On 10 October 2014 11:52, Costin Manolache wrote: > > 2. Expiration: this creates some load problems if too many devices > attempt > > to re-register at the same time. It would be preferable for the push > server > > to request renewal of registration or channel - it can do this with > special > > control messages send from the push server. > > This is something that proprietary protocols already have to deal > with, certainly. You can either let clients deal with it and suffer > the stampeding herd problems that come when clients re-register > en-masse, or you can trigger something. > > While it's not explicit, an HTTP-based protocol, as proposed, permits > a server to expire a registration at any time. This could trigger > re-registration. The server can do that by providing a response to > the hanging GET that we use to monitor for pushed messages. This has > the intended effect, though the process remains under the control of > clients. > I think we're in agreement - but the draft is saying a different thing ( or I'm reading it wrong ). According to draft: when the client register or creates a channel ( independent of them listening for notifications ) they do get a max-age and/or Expires. That means the client app or UA must renew before it expires. What I'm suggesting - and you seem to - is that part of the hanging GET that monitors for pushed messages you will get the server to expire a registration or channel ID. The format needs to be specified - it needs to include the channelId that is getting expired or if the registration id itself is expired. Expiring the registration (i.e. the device identity and credentials) is pretty simple in this case, the monitor request can return a status code. The issue is how can the server send to the app the message that its channel needs to be renewed during the hanging GET, with server controlling the rate and timing - i.e. which synthetic GET or other control message is sent and with which parameters. > > > 4. Encryption of messages - it needs to be specified what format it is - > can > > be simple openpgp (rfc4880), or anything else. Otherwise no > > interoperability. > > It seems the rfc requires encryption, which is great, but it still need > more > > authentication than 'can't decrypt the message'. I'm also not sure if > using > > the > > public key of the channel as a secret is the best option - but it may > work > > (usually public keys are treated as public). > > I can see how this might be confusing. Yes. There definitely needs > to be a format specification for the encrypted message. But at the > level of the protocol itself, there is only one place that matters > (you will see this in the -aggregate draft). The thing here is that > there should be no need to enforce format restrictions at the protocol > level. It's the browser API that ultimately will care that the > message is encrypted (and decryptable). > > I'm going to propose that we use the JSON encoding of JWE (again see > the -aggregate draft), but that is something that will land in the W3C > specification ultimately. > The JWE is a bit too verbose for mobile - having a base64 / web safe encoding in the binary payload of the message seems too chatty. This matters the most when sending the message from the 3p server to the push server - which is also probably sent as binary payload, I couldn't find the proposed details. I also suspect there would be more libraries/implementations and experience on using a (relatively) common encoding like pgp. In any case - the push server would need to do some validations and in particular if JWE is used to re-package in more compact form for transmission to mobile devices. Costin --089e01493cac407eea0505179649 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Oct 10, 2014 at 12:53 PM, Martin Thomson <= martin.thomso= n@gmail.com> wrote:
Thanks = for the feedback Costin,

These are things that I have considered, and they do need to be better
addressed in the draft.=C2=A0 I want to open a new thread about the two
questions you asked on authentication, because I think authentication
is a big deal and it ties into a lot of things.=C2=A0 If we don't have = some
sort of common understanding about how this works, we're not going to get far.

The other two points are, I think, less of a concern.

On 10 October 2014 11:52, Costin Manolache <costin@gmail.com> wrote:
> 2. Expiration: this creates some load problems if too many devices att= empt
> to re-register at the same time. It would be preferable for the push s= erver
> to request renewal of registration or channel - it can do this with sp= ecial
> control messages send from the push server.

This is something that proprietary protocols already have to deal with, certainly.=C2=A0 You can either let clients deal with it and suffer the stampeding herd problems that come when clients re-register
en-masse, or you can trigger something.

While it's not explicit, an HTTP-based protocol, as proposed, permits a server to expire a registration at any time.=C2=A0 This could trigger
re-registration.=C2=A0 The server can do that by providing a response to the hanging GET that we use to monitor for pushed messages.=C2=A0 This has<= br> the intended effect, though the process remains under the control of
clients.

I think we're in agreement= - but the draft is saying a different thing ( or I'm reading it wrong = ).

According to draft: when the client register or= creates a channel ( independent of them listening for notifications )=C2= =A0
they do get a max-age and/or Expires. That means the client a= pp or UA must renew before it expires.

What I'= m suggesting - and you seem to - is that part of the hanging GET that monit= ors for pushed
messages you will get the server to expire a regis= tration or channel ID. The format needs to be
specified - it need= s to include the channelId that is getting expired or if the registration i= d itself is expired.

Expiring the registration (i.= e. the device identity and credentials) is pretty simple in this case, the = monitor
request can return a status code.

The issue is how can the server send to the app the message that its chan= nel needs to be renewed
during the hanging GET, with server contr= olling the rate and timing - i.e. which synthetic GET or=C2=A0
ot= her control message is sent and with which parameters.

=

=C2=A0

> 4. Encryption of messages - it needs to be specified what format it is= - can
> be simple openpgp (rfc4880), or anything else. Otherwise no
> interoperability.
> It seems the rfc requires encryption, which is great, but it still nee= d more
> authentication than 'can't decrypt the message'. I'm a= lso not sure if using
> the
>=C2=A0 public key of the channel as a secret is the best option - but i= t may work
> (usually public keys are treated as public).

I can see how this might be confusing.=C2=A0 Yes.=C2=A0 There defini= tely needs
to be a format specification for the encrypted message.=C2=A0 But at the level of the protocol itself, there is only one place that matters
(you will see this in the -aggregate draft).=C2=A0 The thing here is that there should be no need to enforce format restrictions at the protocol
level.=C2=A0 It's the browser API that ultimately will care that the message is encrypted (and decryptable).

I'm going to propose that we use the JSON encoding of JWE (again see the -aggregate draft), but that is something that will land in the W3C
specification ultimately.

The JWE is a = bit too verbose for mobile - having a base64 / web safe encoding
= =C2=A0in the binary payload of the message seems too chatty.
This= matters the most when sending the message from the 3p server to the push s= erver -=C2=A0
which is also probably sent as binary payload, I co= uldn't find the proposed details.

I also suspe= ct there would be more libraries/implementations and experience on using a = (relatively)
common encoding like pgp.

I= n any case - the push server would need to do some validations and in parti= cular if JWE is used
to re-package in more compact form for trans= mission to mobile devices.=C2=A0

Costin
--089e01493cac407eea0505179649-- From nobody Fri Oct 10 14:06:43 2014 Return-Path: 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 51A561AD3E1 for ; Fri, 10 Oct 2014 14:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 JeTG_OmK9z5C for ; Fri, 10 Oct 2014 14:06:38 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CAD01AD3E2 for ; Fri, 10 Oct 2014 14:06:37 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id pv20so3971233lab.6 for ; Fri, 10 Oct 2014 14:06:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=50BYfgIbpcKRwGp+BA6ZSrAN8Jx3FbuHLS+GbQfthfU=; b=Hibwzx7ym3eOxoYXuxbMi3DP4RzvSpgDHtksTVQJqXS6a4J0kFIUcUnnRZDg3C5c7x VpD+ejkvr3SvNN4MsMkZ7oPFnTqMEzN1YWiZsiSs79nNC6MKxJN46/HHhqHOBK7Bmkls EPb/OOxgY3yS/rRGol3s/wGctNZbgIQwwyDVmFxXn3A0UbMVssOvzv6QSd8Wj09zztM5 fym1YHuRJi4RZa7vdf0ggP+DyBU4EekjsTZA6e4jfKCyT5DmBUDvLIwfMGy52CXc7J0H V1jEo39+QEQf5IHJiIKatcPR4WiL7zPUNOl+852Jrg9L+5UF49ZkQljL4JONZwHLKynN 2kGw== MIME-Version: 1.0 X-Received: by 10.152.8.194 with SMTP id t2mr7482061laa.85.1412975195627; Fri, 10 Oct 2014 14:06:35 -0700 (PDT) Received: by 10.25.215.217 with HTTP; Fri, 10 Oct 2014 14:06:35 -0700 (PDT) Date: Fri, 10 Oct 2014 14:06:35 -0700 Message-ID: From: Martin Thomson To: Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/OGa62g-Ec3azXpGkBsOh3y9TOEo Cc: "webpush@ietf.org" Subject: [Webpush] Expiration (was: Protocol proposal updated) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 21:06:40 -0000 On 10 October 2014 13:42, Costin Manolache wrote: > I think we're in agreement - but the draft is saying a different thing ( or > I'm reading it wrong ). Oh no, if anything it wrong, it's the draft. Guarantee it. > According to draft: when the client register or creates a channel ( > independent of them listening for notifications ) > they do get a max-age and/or Expires. That means the client app or UA must > renew before it expires. Yes, and this is a feature I'd like to retain. Not that the server is required to indicate an expiration date, just that it can. What I'm trying to do is to reuse as much of the HTTP caching semantics for these as possible. Thus, notification of expiration ahead of time - or spontaneously, like you do - both rely on the same basic mechanism. > The issue is how can the server send to the app the message that its channel > needs to be renewed > during the hanging GET, with server controlling the rate and timing - i.e. > which synthetic GET or > other control message is sent and with which parameters. Yeah, so the hanging GET can just return if the whole thing needs to reboot (rare, I hope), but I realize that the push channel expiration is going to get confused with message expiry. Unless the server pushes a 410 (Gone) response for the channel. That's unambiguous. (I'll respond to your other comments elsewhere.) --Martin From nobody Fri Oct 10 14:14:35 2014 Return-Path: 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 CFD271AD3FC for ; Fri, 10 Oct 2014 14:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 d51yas4XD5LK for ; Fri, 10 Oct 2014 14:14:31 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EB431AD3F3 for ; Fri, 10 Oct 2014 14:14:31 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id ge10so3989789lab.38 for ; Fri, 10 Oct 2014 14:14:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=QiBPcZctRsFPh62qgMq+U4XT38chWqg4kZ6Xf9+UEMU=; b=XgrrID4mysa1Aqe6E1KbWtHVKE6Z8QnX6npGLSMdOzUXFj76gzGGp8svwfg0ngwvI0 RHUfb1LDUVRbBxpMDoTxhtPovc58abWKek+EnBBV66/DT1BDBNpB4xgnRwcrGuZKU5og lDAUQFuthUMbKATDQUDZIQN50hgofu+eAsLA/KMffMOADeSCIZV3w+AN22eGRWVfm51y 4287rOGTcz34bPJqKEIG/tCkp15GSi3vS8vUJQOVMyqKDshmLT8n45At3IPOAyqJtFYX wACQdEo1lkndob0gOUy+U6N9yduB2MqiTNwkRKG8IRuEGRhsgs2MSK06PDM8GDHTjW1y rnBg== MIME-Version: 1.0 X-Received: by 10.152.115.229 with SMTP id jr5mr7596539lab.7.1412975669064; Fri, 10 Oct 2014 14:14:29 -0700 (PDT) Received: by 10.25.215.217 with HTTP; Fri, 10 Oct 2014 14:14:29 -0700 (PDT) Date: Fri, 10 Oct 2014 14:14:29 -0700 Message-ID: From: Martin Thomson To: Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/mG1pJpTIBdHoiVAMV7SIVAdf38w Cc: "webpush@ietf.org" Subject: [Webpush] Encryption container format (was: Protocol proposal updated) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 21:14:33 -0000 On 10 October 2014 13:42, Costin Manolache wrote: > The JWE is a bit too verbose for mobile - having a base64 / web safe > encoding > in the binary payload of the message seems too chatty. > This matters the most when sending the message from the 3p server to the > push server - > which is also probably sent as binary payload, I couldn't find the proposed > details. Yeah, I get the opposite about JWE from others: the attempts to keep it small are considered too aggressive by some. I guess there really is no such thing as "one size fits all". I'm going to suggest that gzip content-encoding might be your best friend. We can make support for that mandatory if you like. HTTP/2 didn't manage to make support for it mandatory, but it's not particularly hard to do. > I also suspect there would be more libraries/implementations and experience > on using a (relatively) > common encoding like pgp. Actually, the reason I chose JWE was the ease of implementation. There is lots of code out there already. Web Crypto uses JWK, so it's going to be partially supported in browsers anyway. I'm sure that we'll find that there are S/MIME enthusiasts out there as well. I don't really mind what we pick in the end as long as it is easy to consume. Well, as long as it supports the same sort of key encryption mechanism that JWE does, because that's needed in -aggregate. > In any case - the push server would need to do some validations and in > particular if JWE is used > to re-package in more compact form for transmission to mobile devices. Why do you think that the server would want to validate messages? Or even be able to? I totally understand repackaging (see above re: gzip). From nobody Fri Oct 10 14:38:48 2014 Return-Path: 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 DB5C01AD437 for ; Fri, 10 Oct 2014 14:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 msVfa-wV3zS4 for ; Fri, 10 Oct 2014 14:38:45 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26ABF1AD42E for ; Fri, 10 Oct 2014 14:38:45 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id cc10so5425126wib.0 for ; Fri, 10 Oct 2014 14:38:43 -0700 (PDT) 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=eNuXHwdnRub+W6tlcLitHOmTV6jhY+WHOEMQomFFt8c=; b=0/GD/iEGARQmucdWDw+eZnbPjyf+d34+Z5JBQDOWun87qeQpk2IobeHwxLSk5XhFfN EdXv7HZmR9ye/dg1MQytDMNHd3108HL34TkDxmC8srI8G5GEBHowGWteiqeMSRKFJ1W5 DhG16dKA36GRFbWP5UreVSyI6YvkCfk1ragz/y1TakdOb/l1UqKEC1CSCWTnIhUI1Z/x wX9syq90t+xzK7H3ndZ3T/h8p0A7iBzSn5cxQcM8ykvINSgCncfbyZ6FPhsjoQ1HPEr4 FPXg/fDd52VX7m1AvM5e4WNPh1KndpmY7WcBuhUmmEYZuuvbGRkrXCgsn0AlVkdoYUxS GZDA== MIME-Version: 1.0 X-Received: by 10.194.178.99 with SMTP id cx3mr5339637wjc.113.1412977123591; Fri, 10 Oct 2014 14:38:43 -0700 (PDT) Received: by 10.217.63.202 with HTTP; Fri, 10 Oct 2014 14:38:43 -0700 (PDT) In-Reply-To: References: Date: Fri, 10 Oct 2014 14:38:43 -0700 Message-ID: From: Costin Manolache To: Martin Thomson Content-Type: multipart/alternative; boundary=089e0141aafe870ce20505185f6e Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/13FPnJVJztmgA3B6tyiGs8Ran58 Cc: "webpush@ietf.org" Subject: Re: [Webpush] Expiration (was: Protocol proposal updated) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 21:38:47 -0000 --089e0141aafe870ce20505185f6e Content-Type: text/plain; charset=UTF-8 On Fri, Oct 10, 2014 at 2:06 PM, Martin Thomson wrote: > On 10 October 2014 13:42, Costin Manolache wrote: > > I think we're in agreement - but the draft is saying a different thing ( > or > > I'm reading it wrong ). > > Oh no, if anything it wrong, it's the draft. Guarantee it. > > > According to draft: when the client register or creates a channel ( > > independent of them listening for notifications ) > > they do get a max-age and/or Expires. That means the client app or UA > must > > renew before it expires. > > Yes, and this is a feature I'd like to retain. Not that the server is > required to indicate an expiration date, just that it can. > > What I'm trying to do is to reuse as much of the HTTP caching > semantics for these as possible. Thus, notification of expiration > ahead of time - or spontaneously, like you do - both rely on the same > basic mechanism. > Since it's optional, I suppose there is no harm, just keep in mind that it may cause harm, it's very different from users actively going to a web page and having the content or cookies expire. In this case you have 1B users making periodic herd-requests to push servers and their own servers - just to keep listening to a relatively infrequent message (like hurricane warning). > > The issue is how can the server send to the app the message that its > channel > > needs to be renewed > > during the hanging GET, with server controlling the rate and timing - > i.e. > > which synthetic GET or > > other control message is sent and with which parameters. > > Yeah, so the hanging GET can just return if the whole thing needs to > reboot (rare, I hope), but I realize that the push channel expiration > is going to get confused with message expiry. Unless the server > pushes a 410 (Gone) response for the channel. That's unambiguous. > > (I'll respond to your other comments elsewhere.) > I think you need to go into more details about the content of the synthetic GET - it'll have some headers and body, you may as well define 'Content-Type: channel-refresh'. Costin > > --Martin > --089e0141aafe870ce20505185f6e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Oct 10, 2014 at 2:06 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
On 10 Oc= tober 2014 13:42, Costin Manolache <= costin@gmail.com> wrote:
> I think we're in agreement - but the draft is saying a different t= hing ( or
> I'm reading it wrong ).

Oh no, if anything it wrong, it's the draft.=C2=A0 Guarantee it.

> According to draft: when the client register or creates a channel ( > independent of them listening for notifications )
> they do get a max-age and/or Expires. That means the client app or UA = must
> renew before it expires.

Yes, and this is a feature I'd like to retain.=C2=A0 Not that the serve= r is
required to indicate an expiration date, just that it can.

What I'm trying to do is to reuse as much of the HTTP caching
semantics for these as possible.=C2=A0 Thus, notification of expiration
ahead of time - or spontaneously, like you do - both rely on the same
basic mechanism.

Since it's optiona= l, I suppose there is no harm, just keep in mind that it may cause harm,
it's very different from users actively going to a web page and= having the content or
cookies expire.=C2=A0

=
In this case you have 1B users making periodic herd-requests to push s= ervers and their
own servers - just to keep listening to a relati= vely infrequent message (like hurricane warning).

=

> The issue is how can the server send to the app the message that its c= hannel
> needs to be renewed
> during the hanging GET, with server controlling the rate and timing - = i.e.
> which synthetic GET or
> other control message is sent and with which parameters.

Yeah, so the hanging GET can just return if the whole thing needs to
reboot (rare, I hope), but I realize that the push channel expiration
is going to get confused with message expiry.=C2=A0 Unless the server
pushes a 410 (Gone) response for the channel.=C2=A0 That's unambiguous.=

(I'll respond to your other comments elsewhere.)
<= br>
I think you need to go into more details about the content of= the synthetic GET -=C2=A0
it'll have some headers and body, = you may as well define 'Content-Type: channel-refresh'.
<= br>

Costin
=C2=A0

--Martin

--089e0141aafe870ce20505185f6e-- From nobody Fri Oct 10 14:50:33 2014 Return-Path: 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 D59A61AD427 for ; Fri, 10 Oct 2014 14:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 cgGkxYQFyr0m for ; Fri, 10 Oct 2014 14:50:27 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1B281A8852 for ; Fri, 10 Oct 2014 14:50:26 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id n3so3293975wiv.5 for ; Fri, 10 Oct 2014 14:50:25 -0700 (PDT) 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=ihhkwRC3/H483QRxvc/McjaY8aosKx/gJSpTwDdCiEk=; b=kZwNZ9IccZBtVOClE/SevBeegW+uz2gh3pdHSw3VlsDaV2AFxFI0UgyPX7Xe/hw0ua jHMj/Id0ECZFpo3gUK6RjYwGl+xGkDw2SrMr6bzaBf8bWYyH/LWXY22jAYWPPB/HObTu eez+UPRmz9OMtUdrJX2kaVV2+o3fJLYBHVCgBS0oypJat9JRkM67cSf+n4ecT6xpzCMM 3PwmM15ZzUXCHO0HGfDlroVcxyui6EovfY2yRlC+GBSrqzh4Lf+v6RwE76mY+mFWiUiE 6DZaz0gurc9MXABtizjEyZ5EXl9yduvEatViy66yXeA85L7o2kZ5ISiDXMY13gjF8N+J guIA== MIME-Version: 1.0 X-Received: by 10.180.8.102 with SMTP id q6mr7317974wia.15.1412977825321; Fri, 10 Oct 2014 14:50:25 -0700 (PDT) Received: by 10.217.63.202 with HTTP; Fri, 10 Oct 2014 14:50:25 -0700 (PDT) In-Reply-To: References: Date: Fri, 10 Oct 2014 14:50:25 -0700 Message-ID: From: Costin Manolache To: Martin Thomson Content-Type: multipart/alternative; boundary=f46d044402805a98e30505188983 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/rWZt0TUhUCMJzjbAUMA8fWmupGw Cc: "webpush@ietf.org" Subject: Re: [Webpush] Encryption container format (was: Protocol proposal updated) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 21:50:32 -0000 --f46d044402805a98e30505188983 Content-Type: text/plain; charset=UTF-8 On Fri, Oct 10, 2014 at 2:14 PM, Martin Thomson wrote: > On 10 October 2014 13:42, Costin Manolache wrote: > > The JWE is a bit too verbose for mobile - having a base64 / web safe > > encoding > > in the binary payload of the message seems too chatty. > > This matters the most when sending the message from the 3p server to the > > push server - > > which is also probably sent as binary payload, I couldn't find the > proposed > > details. > > Yeah, I get the opposite about JWE from others: the attempts to keep > it small are considered too aggressive by some. I guess there really > is no such thing as "one size fits all". > > I'm going to suggest that gzip content-encoding might be your best > friend. We can make support for that mandatory if you like. HTTP/2 > didn't manage to make support for it mandatory, but it's not > particularly hard to do. > Average message size is quite low, it's quite common to send only few bytes. The HTTP/2 stream frame and the data frame headers are going to be larger than the content of the message. That's the issue: for notifications that result in sync or client contacting the server directly ( quite common ) you have 5 bytes of content - wrapped in many layers. Short packets keep the radio on for less time and may use significantly less battery. I would suggest using just regular data frames (streaming) instead of the synthetic GET for the same reason. > > > I also suspect there would be more libraries/implementations and > experience > > on using a (relatively) > > common encoding like pgp. > > Actually, the reason I chose JWE was the ease of implementation. > There is lots of code out there already. Web Crypto uses JWK, so it's > going to be partially supported in browsers anyway. > > I'm sure that we'll find that there are S/MIME enthusiasts out there > as well. I don't really mind what we pick in the end as long as it is > easy to consume. Well, as long as it supports the same sort of key > encryption mechanism that JWE does, because that's needed in > -aggregate. > On receiving side it's not a huge problem - browser (or UA) will decrypt and handle the clear message to the app. There is the issue of how easy it is for the 3p sender to generate the message - JWE in browser won't help much there, and the issue of wasted bandwidth and battery due to base64 encoding and extra verbose encoding. > > > In any case - the push server would need to do some validations and in > > particular if JWE is used > > to re-package in more compact form for transmission to mobile devices. > > Why do you think that the server would want to validate messages? Or > even be able to? > > I totally understand repackaging (see above re: gzip). > You can't gzip encrypted content, at most push server may take the base64 encoded JWE and send it as binary ( if it is possible ). If you mean gzip the json keywords - I don't think that works either, keeping the compression context would be too hard. Costin --f46d044402805a98e30505188983 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Oct 10, 2014 at 2:14 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
On 10 Oc= tober 2014 13:42, Costin Manolache <= costin@gmail.com> wrote:
> The JWE is a bit too verbose for mobile - having a base64 / web safe > encoding
>=C2=A0 in the binary payload of the message seems too chatty.
> This matters the most when sending the message from the 3p server to t= he
> push server -
> which is also probably sent as binary payload, I couldn't find the= proposed
> details.

Yeah, I get the opposite about JWE from others: the attempts to keep
it small are considered too aggressive by some.=C2=A0 I guess there really<= br> is no such thing as "one size fits all".

I'm going to suggest that gzip content-encoding might be your best
friend.=C2=A0 We can make support for that mandatory if you like.=C2=A0 HTT= P/2
didn't manage to make support for it mandatory, but it's not
particularly hard to do.

Average messag= e size is quite low, it's quite common to send only few bytes.
The HTTP/2 stream frame and the data frame headers are going to be larger= than=C2=A0
the content of the message.=C2=A0

That's the issue: for notifications that result in sync or client= contacting the server
directly ( quite common ) you have 5 bytes= of content - wrapped in many layers.
Short packets keep the radi= o on for less time and may use significantly less battery.

I would suggest using just regular data frames (streaming) instead= of the synthetic
GET for the same reason.


=C2=A0

> I also suspect there would be more libraries/implementations and exper= ience
> on using a (relatively)
> common encoding like pgp.

Actually, the reason I chose JWE was the ease of implementation.
There is lots of code out there already.=C2=A0 Web Crypto uses JWK, so it&#= 39;s
going to be partially supported in browsers anyway.

I'm sure that we'll find that there are S/MIME enthusiasts out ther= e
as well.=C2=A0 I don't really mind what we pick in the end as long as i= t is
easy to consume.=C2=A0 Well, as long as it supports the same sort of key encryption mechanism that JWE does, because that's needed in
-aggregate.

On receiving side it's = not a huge problem - browser (or UA) will decrypt and handle
the = clear message to the app.=C2=A0

There is the issue= of how easy it is for the 3p sender to generate the message -=C2=A0
<= div>JWE in browser won't help much there, and the issue of wasted bandw= idth and=C2=A0
battery due to base64 encoding and extra verbose e= ncoding. =C2=A0

=C2=A0

> In any case - the push server would need to do some validations and in=
> particular if JWE is used
> to re-package in more compact form for transmission to mobile devices.=

Why do you think that the server would want to validate messages?=C2=A0 Or<= br> even be able to?

I totally understand repackaging (see above re: gzip).

You can't gzip = encrypted content, at most push server may take the base64 encoded JWE and = send it
as binary ( if it is possible ). If= you mean gzip the json keywords - I don't think that works
either, keeping the compression context would be too h= ard.

<= br>
Costin
--f46d044402805a98e30505188983-- From nobody Fri Oct 10 22:21:24 2014 Return-Path: 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 868F31A1ABC for ; Fri, 10 Oct 2014 22:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 uSbmHWINJR0n for ; Fri, 10 Oct 2014 22:21:11 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 919D91A1AD2 for ; Fri, 10 Oct 2014 22:21:07 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id em10so3677367wid.16 for ; Fri, 10 Oct 2014 22:21:06 -0700 (PDT) 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=b2wQJWIsbIg/IRDSMvRyhiYGc8JTfOAFMAsxuPpzOgg=; b=ETTDPfU5t5gwp4fy1iJmvelwd9k5RNPVL9N5e6eeT8sRlxK7A4eRoJrRriYEH/x278 u16hC939AQt4hO36hXO2MewKyfePtkHACxNBsB5V0sJbNxIRurRruWuTboeUqSRQcRL6 q3pElmYCAXl8kvOKiej0Xy8OfXo2f4S6V/m5bp8LxeCmOZaGr7nGrSlDs9Je3a7WDdV5 4oUMCxLuQhErRAQE12ZuqM6vOY+fWofpg7ASz3qPTakOkzxINFsz/FjYU/1EgX7fy9C3 LeNVF/IobyNaVH8HgHoiOrGbMXDX0jnGHOlMRXf67eEB3iEw7KRB2OCxoVEGZd1rivA0 oqWQ== MIME-Version: 1.0 X-Received: by 10.181.29.134 with SMTP id jw6mr8477857wid.69.1413004866123; Fri, 10 Oct 2014 22:21:06 -0700 (PDT) Received: by 10.217.63.202 with HTTP; Fri, 10 Oct 2014 22:21:05 -0700 (PDT) In-Reply-To: References: Date: Fri, 10 Oct 2014 22:21:05 -0700 Message-ID: From: Costin Manolache To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1137fd781c7dbb05051ed57b Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/HhinttObGl6X5jaIX3nR7mYeU-8 Cc: "webpush@ietf.org" Subject: Re: [Webpush] Expiration (was: Protocol proposal updated) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 05:21:17 -0000 --001a1137fd781c7dbb05051ed57b Content-Type: text/plain; charset=UTF-8 BTW - looks like the W3C side also has "onpushregistrationlost". IMHO a pretty bad name ( it's not really "lost" - just needs to be updated ), but allows the server/UA to decide when to request a refresh, instead of exposing an expiration and letting the serviceworker do the refresh. I suspect other special notifications from push server to app will be needed - IMHO in both the API and protocol this can be nicely expressed as a message with a defined type. I haven't seen details about the format of the message besides 'DOMString' in the w3c side, however in the draft you mention 'synthetic GET' - which implies a binary payload and headers, so pretty normal to have Content-Type. I would assume a "From" header will also be present, indicating the authenticated sender - and this can also be used to clearly indicate messages from the push server itself. Costin On Fri, Oct 10, 2014 at 2:38 PM, Costin Manolache wrote: > > > On Fri, Oct 10, 2014 at 2:06 PM, Martin Thomson > wrote: > >> On 10 October 2014 13:42, Costin Manolache wrote: >> > I think we're in agreement - but the draft is saying a different thing >> ( or >> > I'm reading it wrong ). >> >> Oh no, if anything it wrong, it's the draft. Guarantee it. >> >> > According to draft: when the client register or creates a channel ( >> > independent of them listening for notifications ) >> > they do get a max-age and/or Expires. That means the client app or UA >> must >> > renew before it expires. >> >> Yes, and this is a feature I'd like to retain. Not that the server is >> required to indicate an expiration date, just that it can. >> >> What I'm trying to do is to reuse as much of the HTTP caching >> semantics for these as possible. Thus, notification of expiration >> ahead of time - or spontaneously, like you do - both rely on the same >> basic mechanism. >> > > Since it's optional, I suppose there is no harm, just keep in mind that it > may cause harm, > it's very different from users actively going to a web page and having the > content or > cookies expire. > > In this case you have 1B users making periodic herd-requests to push > servers and their > own servers - just to keep listening to a relatively infrequent message > (like hurricane warning). > > > >> > The issue is how can the server send to the app the message that its >> channel >> > needs to be renewed >> > during the hanging GET, with server controlling the rate and timing - >> i.e. >> > which synthetic GET or >> > other control message is sent and with which parameters. >> >> Yeah, so the hanging GET can just return if the whole thing needs to >> reboot (rare, I hope), but I realize that the push channel expiration >> is going to get confused with message expiry. Unless the server >> pushes a 410 (Gone) response for the channel. That's unambiguous. >> >> (I'll respond to your other comments elsewhere.) >> > > I think you need to go into more details about the content of the > synthetic GET - > it'll have some headers and body, you may as well define 'Content-Type: > channel-refresh'. > > > Costin > > >> >> --Martin >> > > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > > --001a1137fd781c7dbb05051ed57b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
BTW - looks like the W3C side also has=C2=A0"onpushre= gistrationlost".
IMHO a pretty bad name ( it's not really &quo= t;lost" - just needs to be updated ), but allows the
server/= UA to decide when to request a refresh, instead of exposing an expiration a= nd letting
the serviceworker do the refresh.

=
I suspect other special notifications from push server to app will be = needed - IMHO in both=C2=A0
the API and protocol this can be nice= ly expressed as a message with a defined type.

I h= aven't seen details about the format of the message besides 'DOMStr= ing' in the w3c side,
however in the draft you mention 's= ynthetic GET' - which implies a binary payload and
headers, s= o pretty normal to have Content-Type. I would assume a "From" hea= der will=C2=A0
also be present, indicating the authenticated send= er - and this can also be used to=C2=A0
clearly indicate messages= from the push server itself.

Costin
=C2= =A0

=C2=A0
<= br>
On Fri, Oct 10, 2014 at 2:38 PM, Costin Manol= ache <costin@gmail.com> wrote:


On Fri, Oct 10, 2014 at 2:06 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 10 October 2014 13:42, Costin Manolache <costin@gmail.com> wrote:
> I think we're in agreement - but the draft is saying a different t= hing ( or
> I'm reading it wrong ).

Oh no, if anything it wrong, it's the draft.=C2=A0 Guarantee it.

> According to draft: when the client register or creates a channel ( > independent of them listening for notifications )
> they do get a max-age and/or Expires. That means the client app or UA = must
> renew before it expires.

Yes, and this is a feature I'd like to retain.=C2=A0 Not that the serve= r is
required to indicate an expiration date, just that it can.

What I'm trying to do is to reuse as much of the HTTP caching
semantics for these as possible.=C2=A0 Thus, notification of expiration
ahead of time - or spontaneously, like you do - both rely on the same
basic mechanism.

Since it's = optional, I suppose there is no harm, just keep in mind that it may cause h= arm,
it's very different from users actively going to a web p= age and having the content or
cookies expire.=C2=A0
In this case you have 1B users making periodic herd-requests to= push servers and their
own servers - just to keep listening to a= relatively infrequent message (like hurricane warning).



> The issue is how can the server send to the app the message that its c= hannel
> needs to be renewed
> during the hanging GET, with server controlling the rate and timing - = i.e.
> which synthetic GET or
> other control message is sent and with which parameters.

Yeah, so the hanging GET can just return if the whole thing needs to
reboot (rare, I hope), but I realize that the push channel expiration
is going to get confused with message expiry.=C2=A0 Unless the server
pushes a 410 (Gone) response for the channel.=C2=A0 That's unambiguous.=

(I'll respond to your other comments elsewhere.)
<= br>
I think you need to go into more details about the con= tent of the synthetic GET -=C2=A0
it'll have some headers and= body, you may as well define 'Content-Type: channel-refresh'.


Costin
=C2=A0

--Martin


_______________________________________________
Webpush mailing list
Webpush@ietf.org
https://www.ietf.org/mailman/listinfo/webpush


--001a1137fd781c7dbb05051ed57b-- From nobody Mon Oct 13 10:25:26 2014 Return-Path: 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 6C0B71A1BB5 for ; Mon, 13 Oct 2014 10:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mOltxzSvz7co for ; Mon, 13 Oct 2014 10:25:14 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 211561A1BC0 for ; Mon, 13 Oct 2014 10:25:10 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id b6so6838691lbj.31 for ; Mon, 13 Oct 2014 10:25:09 -0700 (PDT) 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=WoG8oxAO4O7zTNkGU0uVmxJMPpv2SFCPHSOiC984I2A=; b=b4uARz1WeqfXX6HmqKxdHGUrNNYonmT9k52RiEjAdUzaUrd3IO3rysuSFg4EIrZzaq vPv10p+1OSnubDG4NSW6gNnNEaFgqT4C5YF1Yqt2zYGOIaJU1epY+rG2Bl5cgaaDbbOQ 1cWJp6TwrB7i7bp3fqbcZ6u4wWjh4f/toBie433Xo06avAdNhYlBwF3SDZu4DYlw/HEM 7LyZbSoVMVT5OKRq2E/Nfhr79Ymx+JXJQ3vFnJSkDbumxeJjW3gA4jnYnvsLNWJ6DNqt rvMT/e+0kXba2kt4f0gibZDA4aclhInvlqge8ihFzm+9Wj7fk/JRcvmwDT9N1qQzcIQK y6jg== MIME-Version: 1.0 X-Received: by 10.152.19.37 with SMTP id b5mr25758563lae.43.1413221109368; Mon, 13 Oct 2014 10:25:09 -0700 (PDT) Received: by 10.25.215.217 with HTTP; Mon, 13 Oct 2014 10:25:09 -0700 (PDT) In-Reply-To: References: Date: Mon, 13 Oct 2014 10:25:09 -0700 Message-ID: From: Martin Thomson To: Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/ACv_ZPsBvca3i6Cq4vq3w62JS2o Cc: "webpush@ietf.org" Subject: Re: [Webpush] Expiration (was: Protocol proposal updated) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 17:25:18 -0000 On 10 October 2014 22:21, Costin Manolache wrote: > BTW - looks like the W3C side also has "onpushregistrationlost". > IMHO a pretty bad name ( it's not really "lost" - just needs to be updated > ), but allows the > server/UA to decide when to request a refresh, instead of exposing an > expiration and letting > the serviceworker do the refresh. Yes, that was always the intent. The serviceworker shouldn't have to do anything other than react to a) reported outages, and b) new or changed endpoints (or registration identifiers). > I suspect other special notifications from push server to app will be needed > - IMHO in both > the API and protocol this can be nicely expressed as a message with a > defined type. Why do you think that? If the existing protocol mechanisms convey sufficient information, there shouldn't be any need to add more mechanisms. > I haven't seen details about the format of the message besides 'DOMString' > in the w3c side, > however in the draft you mention 'synthetic GET' - which implies a binary > payload and > headers, so pretty normal to have Content-Type. I would assume a "From" > header will > also be present, indicating the authenticated sender - and this can also be > used to > clearly indicate messages from the push server itself. The synthesized GET is an artifact of how HTTP/2 push works. The response to that includes the push message. In the current view, this would be some sort of encrypted blob. Why do you think we would have a From header field? That's basically never used in HTTP, and that implies something about authentication that I don't think is uniformly possible. (Yes, I still owe you a write-up on the authentication piece.) From nobody Mon Oct 13 11:03:42 2014 Return-Path: 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 B91A61A8034 for ; Mon, 13 Oct 2014 11:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 ND2xHHkq_Wqq for ; Mon, 13 Oct 2014 11:03:39 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EBA21A7D83 for ; Mon, 13 Oct 2014 11:03:38 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id hi2so9874851wib.1 for ; Mon, 13 Oct 2014 11:03:37 -0700 (PDT) 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=2ny11XvWuGgxOEvxHiCzen9KbWw5HnH5+iOKaL/dkTE=; b=bDMoN09gsYFMEm9fzLGOAI2JksKUTtYCRMGL9rmQ3yFn4DJMv6L1lPPYcUWJcORx2q cdZXUYc97T/qUtidYRxqoD1ImG5vGkKyIGLeaewn3AdgJ7uH7aB1FKtL1H4xFnLpLXch CA+WMPTuAw/sOkD9H8gMxQ67OnWacl6/+9Rrz2Z9Xsj70JVoBKbZsscDHl8k3Qf36Xz4 4TYqRdyBcrG7F/M+nP2CH/UuxbnYj7ip9T5on1OVA87MeqVcF6LxonEZVNg6eqJiSlty 8b8rNylbXI8pKy+2TAJleB48EtQ0ormvWWMtSMPrSq3jovzDlWezayuz5RwQ8m4TZo7a gevw== MIME-Version: 1.0 X-Received: by 10.180.74.227 with SMTP id x3mr628754wiv.15.1413223417110; Mon, 13 Oct 2014 11:03:37 -0700 (PDT) Received: by 10.217.63.202 with HTTP; Mon, 13 Oct 2014 11:03:36 -0700 (PDT) In-Reply-To: References: Date: Mon, 13 Oct 2014 11:03:36 -0700 Message-ID: From: Costin Manolache To: Martin Thomson Content-Type: multipart/alternative; boundary=f46d043c7eeec3e6e8050551b789 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/uOXRtGOvlFkS7WhYPahn96VNMAw Cc: "webpush@ietf.org" Subject: Re: [Webpush] Expiration (was: Protocol proposal updated) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 18:03:41 -0000 --f46d043c7eeec3e6e8050551b789 Content-Type: text/plain; charset=UTF-8 On Mon, Oct 13, 2014 at 10:25 AM, Martin Thomson wrote: > On 10 October 2014 22:21, Costin Manolache wrote: > > BTW - looks like the W3C side also has "onpushregistrationlost". > > IMHO a pretty bad name ( it's not really "lost" - just needs to be > updated > > ), but allows the > > server/UA to decide when to request a refresh, instead of exposing an > > expiration and letting > > the serviceworker do the refresh. > > > Yes, that was always the intent. The serviceworker shouldn't have to > do anything other than react to a) reported outages, and b) new or > changed endpoints (or registration identifiers). > > > I suspect other special notifications from push server to app will be > needed > > - IMHO in both > > the API and protocol this can be nicely expressed as a message with a > > defined type. > > Why do you think that? If the existing protocol mechanisms convey > sufficient information, there shouldn't be any need to add more > mechanisms. The protocol as specified - with synthetized GET - would convey sufficient information if the HTTP headers are exposed to the client API. So if the HTTP transport remain - I don't think we need additional notifications, not even for 'expiry', since this can be expressed as a message with "Content-Type:refresh" ( or similar name ). > > > I haven't seen details about the format of the message besides > 'DOMString' > > in the w3c side, > > however in the draft you mention 'synthetic GET' - which implies a binary > > payload and > > headers, so pretty normal to have Content-Type. I would assume a "From" > > header will > > also be present, indicating the authenticated sender - and this can also > be > > used to > > clearly indicate messages from the push server itself. > > The synthesized GET is an artifact of how HTTP/2 push works. The > response to that includes the push message. In the current view, this > would be some sort of encrypted blob. > > Why do you think we would have a From header field? That's basically > never used in HTTP, and that implies something about authentication > that I don't think is uniformly possible. (Yes, I still owe you a > write-up on the authentication piece.) > My primary concern is making sure that "Content-Type" is there and used. As any HTTP request, it would be possible to add X- headers, or to evolve the protocol by defining specific content-types and headers instead of requiring changes to the transport. While the actual payload will be encrypted and not visible to the push server- some of the headers in the HTTP message will be originated from the push server. I don't know if this spec should include a list of common headers that are specific to push, or a subset of the HTTP headers that are likely to be present in push. But IMHO Content-Type should be required, and other should be mentioned - Date ( defined as the time when the message was sent ?), Content-Encoding, Via. Re. From: what is the plan for the URL of the synthetized GET ? It could be a URL that identifies the sender of the push, in the case of multiple senders. Otherwise - some way to indicate who sent the push will be needed, From is normally used for this. Costin --f46d043c7eeec3e6e8050551b789 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Oct 13, 2014 at 10:25 AM, Martin Thomson <= martin.thomso= n@gmail.com> wrote:
On 10 October 2014 22:21, Costin Manolache <costin@gmail.com> wrote:
> BTW - looks like the W3C side also has "onpushregistrationlost&qu= ot;.
> IMHO a pretty bad name ( it's not really "lost" - just n= eeds to be updated
> ), but allows the
> server/UA to decide when to request a refresh, instead of exposing an<= br> > expiration and letting
> the serviceworker do the refresh.


Yes, that was always the intent.=C2=A0 The serviceworker shouldn'= ;t have to
do anything other than react to a) reported outages, and b) new or
changed endpoints (or registration identifiers).

> I suspect other special notifications from push server to app will be = needed
> - IMHO in both
> the API and protocol this can be nicely expressed as a message with a<= br> > defined type.

Why do you think that?=C2=A0 If the existing protocol mechanisms con= vey
sufficient information, there shouldn't be any need to add more
mechanisms.


The protocol as = specified - with synthetized GET - would convey sufficient information
if the HTTP headers are exposed to the client API. So if the HTTP tra= nsport remain -=C2=A0
I don't think we need additional notifi= cations, not even for 'expiry', since this
can be express= ed as a message with "Content-Type:refresh" ( or similar name ).<= /div>


=C2=A0

> I haven't seen details about the format of the message besides = 9;DOMString'
> in the w3c side,
> however in the draft you mention 'synthetic GET' - which impli= es a binary
> payload and
> headers, so pretty normal to have Content-Type. I would assume a "= ;From"
> header will
> also be present, indicating the authenticated sender - and this can al= so be
> used to
> clearly indicate messages from the push server itself.

The synthesized GET is an artifact of how HTTP/2 push works.=C2=A0 T= he
response to that includes the push message.=C2=A0 In the current view, this=
would be some sort of encrypted blob.

Why do you think we would have a From header field?=C2=A0 That's basica= lly
never used in HTTP, and that implies something about authentication
that I don't think is uniformly possible.=C2=A0 (Yes, I still owe you a=
write-up on the authentication piece.)

=
My primary concern is making sure that "Content-Type&qu= ot; is there and used.

As any HTTP request, it wou= ld be possible to add X- headers, or to
evolve the protocol by de= fining specific content-types and headers instead=C2=A0
of requir= ing changes to the transport.

While the actual pay= load will be encrypted and not visible to the push server- =C2=A0some
=
of the headers in the HTTP message will be originated from the push se= rver.
I don't know if this spec should include a list of comm= on headers that are specific
to push, or a subset of the HTTP hea= ders that are likely to be present in push.
But IMHO Content-Type= should be required, and other should be mentioned -=C2=A0
Da= te ( defined as the time when the message was sent ?), Content-Encoding, Vi= a.

Re. From: what is the plan for the URL of the s= ynthetized GET ? It could be=C2=A0
a URL that identifies the send= er of the push, in the case of multiple senders.
Otherwise - some= way to indicate who sent the push will be needed, From
is normal= ly used for this.

Costin=C2=A0

--f46d043c7eeec3e6e8050551b789-- From nobody Mon Oct 13 14:35:27 2014 Return-Path: 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 C0DD11A008F for ; Mon, 13 Oct 2014 14:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 qJMiyNyZacNh for ; Mon, 13 Oct 2014 14:35:24 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7E131A008A for ; Mon, 13 Oct 2014 14:35:23 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id q1so7404087lam.4 for ; Mon, 13 Oct 2014 14:35:22 -0700 (PDT) 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=1z95MVbfKLxQafokG9zzWCBPBdpb/Y7aVzd96gtxTRc=; b=PU5DgcfJWizBso6cLSfDKrZzRAhtPbkmbkPZ9Q2RwHlogMMLRD9oecXtK9XGbMuUlH gLdzeE2MY7Ca27YRtOfdLR0O8v2z63igfc3qTZSO70Hrk/lEW9db8c6CtnHuvexdpWuu VHn1qZg952zstglrRMNtZ9MtPcmn1DP1FRMzr9mXs2rghLZBMNFNWIPzOzPHf5dMlQRP d9yMGuuFJGi7NO0YUcfiniv/rTih74CROwTTItnGmXn1esJFcXrUzHm+BOkYwvyf1RaA wulQOBuHXwqE0/Hr7RsUrSvP7eYUaNVxkkkN4tzYDQ8jK0OtmvyeC9ZJsn8jz5LJzUqE v9GA== MIME-Version: 1.0 X-Received: by 10.152.27.38 with SMTP id q6mr1139097lag.92.1413236122047; Mon, 13 Oct 2014 14:35:22 -0700 (PDT) Received: by 10.25.215.217 with HTTP; Mon, 13 Oct 2014 14:35:22 -0700 (PDT) In-Reply-To: References: Date: Mon, 13 Oct 2014 14:35:22 -0700 Message-ID: From: Martin Thomson To: Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/58ZUutIqjAlluDuJn4UFpgWUS_o Cc: "webpush@ietf.org" Subject: Re: [Webpush] Expiration (was: Protocol proposal updated) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 21:35:25 -0000 Regarding expiration, this is something that I would expect the browser to consume. The application running in the browser would not need to concern itself with refresh. The application would only have to react to outages (optionally), or any changes in the endpoint or registration id (if that's possible; some systems will do that occasionally, others are completely stable in that regard). On 13 October 2014 11:03, Costin Manolache wrote: > My primary concern is making sure that "Content-Type" is there and used. > > As any HTTP request, it would be possible to add X- headers, or to > evolve the protocol by defining specific content-types and headers instead > of requiring changes to the transport. > > While the actual payload will be encrypted and not visible to the push > server- some > of the headers in the HTTP message will be originated from the push server. > I don't know if this spec should include a list of common headers that are > specific > to push, or a subset of the HTTP headers that are likely to be present in > push. > But IMHO Content-Type should be required, and other should be mentioned - > Date ( defined as the time when the message was sent ?), Content-Encoding, > Via. The current API doesn't expose this meta information. I would like for that to be possible. However, I don't think that Content-Encoding is something that the application needs to worry about, and I can't think of a use case for Via. The Date header is definitely useful though, since this allows the push server to communicate the age of a message. And I'm sure that there are other header fields that have genuine use cases. > Re. From: what is the plan for the URL of the synthetized GET ? It could be > a URL that identifies the sender of the push, in the case of multiple > senders. > Otherwise - some way to indicate who sent the push will be needed, From > is normally used for this. The draft currently uses the channel URI - the same string that the application needs. The idea was that if you want to use this to identify where it came from, you would create one for each application server. From nobody Mon Oct 13 15:06:12 2014 Return-Path: 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 AD2B81A02F4 for ; Mon, 13 Oct 2014 15:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 ahJGMwP29nBd for ; Mon, 13 Oct 2014 15:06:05 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F39441A02F0 for ; Mon, 13 Oct 2014 15:06:04 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id a1so9537298wgh.33 for ; Mon, 13 Oct 2014 15:06:03 -0700 (PDT) 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=gyNtFg0HKxO2YKHDKqiVN1xbtUVmkLDEigtrrlUu3qI=; b=n6rgZMCQRm4j7dlrJvYknAJG007FsMEX3mfiafVxh9OcC4ISfdK34fH3Ke0TstRvBh M/+2+CoqOhj/XCbOJmkqy0MMbZHTICjsvRbXSNONGXlHZ8wMsavtzNVhZezvXRSKryuE X7q7D9P4QJ4M5YUUOgINmMXvUq1j0Mq4LOq4eg3i3Bvsy472QQy7/m6IcBiNUNLAtoCw ZClnw/9BEilEjkkSzzu41wxhBijApkuqJG4TmYnhB+0n7ZPjiBsj/cTzHgIQUQor90jr 74+lp75uxAifjsY58pMZn+QU7u+zIKRZcNF/m1YXfczSRW+r0UnKDJg79PSsRqDntcZP VqqA== MIME-Version: 1.0 X-Received: by 10.180.107.69 with SMTP id ha5mr1468189wib.69.1413237963531; Mon, 13 Oct 2014 15:06:03 -0700 (PDT) Received: by 10.217.63.202 with HTTP; Mon, 13 Oct 2014 15:06:03 -0700 (PDT) In-Reply-To: References: Date: Mon, 13 Oct 2014 15:06:03 -0700 Message-ID: From: Costin Manolache To: Martin Thomson Content-Type: multipart/alternative; boundary=e89a8f2348c7ccaeb00505551a52 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/mZ0jQcWbOc8X6oOnGeHcUaL2FA8 Cc: "webpush@ietf.org" Subject: Re: [Webpush] Expiration (was: Protocol proposal updated) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 22:06:09 -0000 --e89a8f2348c7ccaeb00505551a52 Content-Type: text/plain; charset=UTF-8 On Mon, Oct 13, 2014 at 2:35 PM, Martin Thomson wrote: > Regarding expiration, this is something that I would expect the > browser to consume. The application running in the browser would not > need to concern itself with refresh. The application would only have > to react to outages (optionally), or any changes in the endpoint or > registration id (if that's possible; some systems will do that > occasionally, others are completely stable in that regard). > The browser needs to consume it in most cases - it'll need to call register() again, get a brand new ID and send it to the sender app. Otherwise the sending server would have the expired registration. There are 3 separate communications: 1. device to push server, where 'expiration' events happen. 2. Push server to the sending app - the sender needs a valid, unexpired channel Id. 3. device to the sending app - that's how the sending app gets the channel ID from device, and will need to be able to get refreshed IDs. We tried to update the sending server - but it doesn't work well, the send may be very infrequent, and in some cases the device data may become invalid/corrupted - and there is nothing to do to recover it except doing a brand new registration. > > On 13 October 2014 11:03, Costin Manolache wrote: > > My primary concern is making sure that "Content-Type" is there and used. > > > > As any HTTP request, it would be possible to add X- headers, or to > > evolve the protocol by defining specific content-types and headers > instead > > of requiring changes to the transport. > > > > While the actual payload will be encrypted and not visible to the push > > server- some > > of the headers in the HTTP message will be originated from the push > server. > > I don't know if this spec should include a list of common headers that > are > > specific > > to push, or a subset of the HTTP headers that are likely to be present in > > push. > > But IMHO Content-Type should be required, and other should be mentioned - > > Date ( defined as the time when the message was sent ?), > Content-Encoding, > > Via. > > The current API doesn't expose this meta information. I would like > for that to be possible. > > However, I don't think that Content-Encoding is something that the > application needs to worry about, and I can't think of a use case for > Via. The Date header is definitely useful though, since this allows > the push server to communicate the age of a message. And I'm sure > that there are other header fields that have genuine use cases. > I agree - some of the headers are only relevant to the UA, while some may or may not be relevant to the application. For example "Via" (or similar) would indicate which push server was used. But I agree, the spec should only include the headers that have clear use cases - Content-Type is one needed both by UA and application, Content-Encoding probably only by UA.. > > > Re. From: what is the plan for the URL of the synthetized GET ? It could > be > > a URL that identifies the sender of the push, in the case of multiple > > senders. > > Otherwise - some way to indicate who sent the push will be needed, From > > is normally used for this. > > The draft currently uses the channel URI - the same string that the > application needs. The idea was that if you want to use this to > identify where it came from, you would create one for each application > server. > Sounds good, than there is no need for a From header in transport, :url is good. But I think the app will need access to this data - it's quite important to know which channel (sender) originated the message - but that's on the API side, easy to extract from url. Costin --e89a8f2348c7ccaeb00505551a52 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Oct 13, 2014 at 2:35 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
Regardin= g expiration, this is something that I would expect the
browser to consume.=C2=A0 The application running in the browser would not<= br> need to concern itself with refresh.=C2=A0 The application would only have<= br> to react to outages (optionally), or any changes in the endpoint or
registration id (if that's possible; some systems will do that
occasionally, others are completely stable in that regard).


The browser needs to consume it in most= cases - it'll need to call register() again, get=C2=A0
a bra= nd new ID and send it to the sender app. Otherwise the sending server would=
have the expired registration.

There ar= e 3 separate communications:=C2=A0
1. device to push server, wher= e 'expiration' events happen.
2. Push server to the sendi= ng app - the sender needs a valid, unexpired channel Id.
3. devic= e to the sending app - that's how the sending app gets the channel ID f= rom device,
and will need to be able to get refreshed IDs.
<= div>
We tried to update the sending server - but it doesn'= ;t work well, the send may be very infrequent,
and in some cases = the device data may become invalid/corrupted - and there is nothing to do
to recover it except doing a brand new registration.

=C2=A0=C2=A0

On 13 October 2014 11:03, Costin Manolache <costin@gmail.com> wrote:
> My primary concern is making sure that "Content-Type" is the= re and used.
>
> As any HTTP request, it would be possible to add X- headers, or to
> evolve the protocol by defining specific content-types and headers ins= tead
> of requiring changes to the transport.
>
> While the actual payload will be encrypted and not visible to the push=
> server-=C2=A0 some
> of the headers in the HTTP message will be originated from the push se= rver.
> I don't know if this spec should include a list of common headers = that are
> specific
> to push, or a subset of the HTTP headers that are likely to be present= in
> push.
> But IMHO Content-Type should be required, and other should be mentione= d -
> Date ( defined as the time when the message was sent ?), Content-Encod= ing,
> Via.

The current API doesn't expose this meta information.=C2=A0 I wo= uld like
for that to be possible.

However, I don't think that Content-Encoding is something that the
application needs to worry about, and I can't think of a use case for Via.=C2=A0 The Date header is definitely useful though, since this allows the push server to communicate the age of a message.=C2=A0 And I'm sure=
that there are other header fields that have genuine use cases.

I agree - some of the headers are only relevant to= the UA, while some may or may=C2=A0
not be relevant to the appli= cation. For example "Via" (or similar) would indicate
w= hich push server was used. But I agree, the spec should only include=C2=A0<= /div>
the headers that have clear use cases - Content-Type is one neede= d both
by UA and application, Content-Encoding probably only by U= A..


=C2=A0

> Re. From: what is the plan for the URL of the synthetized GET ? It cou= ld be
> a URL that identifies the sender of the push, in the case of multiple<= br> > senders.
> Otherwise - some way to indicate who sent the push will be needed, Fro= m
> is normally used for this.

The draft currently uses the channel URI - the same string that the<= br> application needs.=C2=A0 The idea was that if you want to use this to
identify where it came from, you would create one for each application
server.

Sounds good, than there is no n= eed for a From header in transport, :url is good.=C2=A0

But I think the app will need access to this data - it's quite im= portant to know which=C2=A0
channel (sender) originated the messa= ge - but that's on the API side, easy to extract from url.
Costin

--e89a8f2348c7ccaeb00505551a52-- From nobody Mon Oct 13 15:54:43 2014 Return-Path: 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 39BD61A1A4F for ; Mon, 13 Oct 2014 15:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 UZ66lKSlCpBn for ; Mon, 13 Oct 2014 15:54:39 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84F5C1A1A42 for ; Mon, 13 Oct 2014 15:54:38 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id s18so7477736lam.23 for ; Mon, 13 Oct 2014 15:54:36 -0700 (PDT) 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=KKc68lxa0qH4yyqyfFajkhN45zXE8z+hDBW5iGRTrhM=; b=b64alrN4lxeR3DoTJ1ZAp/3G52yn2CEBEil1n180iRMWRLaeibIAuMpfjtt8WaIHD2 gED9OgWI3Bxa4cPIfq9KV79JznmOy1v6d+iKEi68lo8Eacp5BcGtPpSTppxQiBQy0N0K zMJAdnFkLvkeHgUSpIDL6EzesBneCrzEbm+iDwbno+8pcBVzr8vZK8y2HBmpfYMDeWtN 5Qzp6dCbC7MTGhxuLdLbGya0S+wyr3xncVrcQ72SoV/puXac7fcnup0k2Tdo6yu8Pu1g 4jiXjkjaXM5QOKpqerDBWxu+R+ZHWQnE0V3dH6no/3xGqMaMebOOn4t9yaMGn0d1Vf9p NT+w== MIME-Version: 1.0 X-Received: by 10.152.4.132 with SMTP id k4mr1403654lak.1.1413240876647; Mon, 13 Oct 2014 15:54:36 -0700 (PDT) Received: by 10.25.215.217 with HTTP; Mon, 13 Oct 2014 15:54:36 -0700 (PDT) In-Reply-To: References: Date: Mon, 13 Oct 2014 15:54:36 -0700 Message-ID: From: Martin Thomson To: Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/RUdnNWKSFnFoVo0hZ39PTBoYwDA Cc: "webpush@ietf.org" Subject: Re: [Webpush] Expiration (was: Protocol proposal updated) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 22:54:40 -0000 On 13 October 2014 15:06, Costin Manolache wrote: > But I think the app will need access to this data - it's quite important to > know which > channel (sender) originated the message - but that's on the API side, easy > to extract from url. Definitely. Currently there is a one-to-one mapping between channel ("registration" in the API, we still need to normalize terminology) and a service worker, so there is little risk of confusion. I've proposed that applications be permitted to create any number of channels though. From nobody Thu Oct 16 13:10:03 2014 Return-Path: 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 89E951A884D for ; Thu, 16 Oct 2014 13:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 9-fVJhq18pmn for ; Thu, 16 Oct 2014 13:09:59 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F4A51A802F for ; Thu, 16 Oct 2014 13:09:59 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id gf13so3889619lab.29 for ; Thu, 16 Oct 2014 13:09:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=N4XqynCt5Ibmx54R3MRFVKqKqgOBFhAR5f9gsWZ/sW0=; b=iBM0S65+s/VM/9rTF92iZ8Sp/WymVFVU2VLbE3zgk6lxbxhfasRJUhdGnxTqeLSsaS ZBakadQf181f3nc3FlUr/qRxL39FkqbtLT063TlGYWC/KCdRkUuJMf3C1DUyvYw+d8WT 3OxDJIgHdNFvlD0o6sUUQcgZucqymJeUaj/Pl4LG3KDkFa8w+kVN9eciTYqHGz0voIwO sZ2dvdPenS0ruh38yOwSg1y4pD0pgahL10MoW2BfqbSfrhr98/IZ/e0+ZIZ+WhPhGDGR L6DBWbvsCxdpZgAbSCZDj7AVix1DvX27lqXyN8yh0obGhTxJKBs0wYdxPuxeVu6aG0kR rL5g== MIME-Version: 1.0 X-Received: by 10.152.27.134 with SMTP id t6mr4015128lag.17.1413490197888; Thu, 16 Oct 2014 13:09:57 -0700 (PDT) Received: by 10.25.215.217 with HTTP; Thu, 16 Oct 2014 13:09:57 -0700 (PDT) Date: Thu, 16 Oct 2014 13:09:57 -0700 Message-ID: From: Martin Thomson To: "webpush@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/RHVvviOgqApIYr68_kBjI4GRFd4 Subject: [Webpush] Pointer to W3C WebPush API discussions 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 20:10:01 -0000 It might not be obvious to everyone involved in the discussion here that our companion group in the W3C is debating many of the same sorts of issues we are. If you want to participate, here is where all the action is happening: --Martin p.s., If you aren't familiar with github, the "Watch" button at the top (right-ish) will ensure that you get email for the discussions. You can respond to those emails, but that doesn't produce nice results; the web interface is best. From nobody Thu Oct 30 08:50:09 2014 Return-Path: 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 606E91AD0EA for ; Thu, 30 Oct 2014 08:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 DmQO03e9tDrB for ; Thu, 30 Oct 2014 08:50:05 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAE3B1A016B for ; Thu, 30 Oct 2014 08:50:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2204; q=dns/txt; s=iport; t=1414684205; x=1415893805; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=AfBsIO2gyXEEUJPKBCuFX1TKpS8NPe1hoRS3b6gse2Y=; b=MQzHS2tgpcdAqbme+vD0z/Mmz7ASkkmaVJmkcvVl7ut88f12Uec9vSka TaNsxA6lud1Fz1PReTHn4teJ8VUOHhF3lOTPzlwDBXll8dg4GR1VLSkrF mxXNp7YiyANJnQBiZOuSspAvmn+I8dGcBRDyw0eeRv1U8hCZKXawhlz6d Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFAAddUlStJV2Q/2dsb2JhbABcgmsjVFgEzVqHSwKBJBYBAQEBAXILhAIBAQEEOjQJAhACAQgRBAEBCxQQMh0IAgQOBQgBiDgBDMglAQEBAQEBAQEBAQEBAQEBAQEBAQEBF5BfMQeDLYEeBZINhEqIRDyDDooahyqDeGwBgUeBAwEBAQ X-IronPort-AV: E=Sophos;i="5.07,286,1413244800"; d="scan'208";a="368172030" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-2.cisco.com with ESMTP; 30 Oct 2014 15:50:04 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s9UFo4vA025357 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Oct 2014 15:50:04 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Thu, 30 Oct 2014 10:50:03 -0500 From: "Ali C. Begen (abegen)" To: "webpush@ietf.org" Thread-Topic: New Version Notification for draft-begen-webpush-dash-reqs-00.txt Thread-Index: AQHP8jXm+p1ODwswC0afPVpJ5XEbApxIy+OE Date: Thu, 30 Oct 2014 15:50:03 +0000 Message-ID: References: <20141027223229.23918.92412.idtracker@ietfa.amsl.com> In-Reply-To: <20141027223229.23918.92412.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.222.164] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/mmWDYIQ3wqRTdwiXUo3gQeh031M Cc: Imed Bouazizi , Franck Denoual , Kevin Streeter Subject: Re: [Webpush] New Version Notification for draft-begen-webpush-dash-reqs-00.txt 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 15:50:08 -0000 This is a pretty short informational draft that gives a quick update on the= developments happening in the DASH (dynamic adaptive streaming over http) = subgroup at MPEG. We have two core experiments ongoing and we believe there= is a lot of commonality between the tools we are considering to use in tho= se core experiments and the proposed webpush protocol. =0A= =0A= I asked the WG chairs to give us some time to present these core experiment= s, mention about our requirements and seek some guidance from the WG.=0A= =0A= Any discussion on the mailing list is also welcome.=0A= =0A= -acbegen=0A= =0A= =0A= ________________________________________=0A= From: internet-drafts@ietf.org [internet-drafts@ietf.org]=0A= Sent: Monday, October 27, 2014 6:32 PM=0A= To: Franck Denoual; Ali C. Begen (abegen); Imed Bouazizi; Imed Bouazizi; Al= i C. Begen (abegen); Franck Denoual; Kevin Streeter; Kevin Streeter=0A= Subject: New Version Notification for draft-begen-webpush-dash-reqs-00.txt= =0A= =0A= A new version of I-D, draft-begen-webpush-dash-reqs-00.txt=0A= has been successfully submitted by Ali Begen and posted to the=0A= IETF repository.=0A= =0A= Name: draft-begen-webpush-dash-reqs=0A= Revision: 00=0A= Title: MPEG DASH Requirements for a webpush Protocol=0A= Document date: 2014-10-27=0A= Group: Individual Submission=0A= Pages: 6=0A= URL: http://www.ietf.org/internet-drafts/draft-begen-webpush-das= h-reqs-00.txt=0A= Status: https://datatracker.ietf.org/doc/draft-begen-webpush-dash-r= eqs/=0A= Htmlized: http://tools.ietf.org/html/draft-begen-webpush-dash-reqs-00= =0A= =0A= =0A= Abstract:=0A= This draft presents two of the ongoing core experiments for the=0A= amendment of the MPEG Dynamic Adaptive Streaming over HTTP (DASH)=0A= specification and discusses some requirements for a webpush protocol=0A= in the context of these core experiments.=0A= =0A= =0A= =0A= =0A= Please note that it may take a couple of minutes from the time of submissio= n=0A= until the htmlized version and diff are available at tools.ietf.org.=0A= =0A= The IETF Secretariat=0A= From nobody Thu Oct 30 09:03:37 2014 Return-Path: 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 90E721A0248 for ; Thu, 30 Oct 2014 09:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 5TvexMdkSvH2 for ; Thu, 30 Oct 2014 09:03:26 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D5A91AD547 for ; Thu, 30 Oct 2014 09:02:01 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id hs14so4686379lab.19 for ; Thu, 30 Oct 2014 09:02:00 -0700 (PDT) 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=e8LpZgU8xtqMrKqxON9bk7ZEMWxJ2FyipohggWjwJ7Y=; b=yq/UIpETnVLRZ1x67JyCXZ6tga3bsMeXZkmTBuuTes1hCpq1RDuMrLI1FaZqCytka/ b9NR9u+zF+zdObxErEYXU3eg7c1W9cQfRtzYvZf4gsCG7f03KRf7dWdaPgB51kRTh+F3 e6Ia3w8sxcOmvuarbu/miIMF4idxzQa0XO0V0hgJNxD45NwGZjqUV5h5J37QC3lTwGN3 2jE7VKcx1PSqOpBzq4mOj411K8f2bypCY5xAsws4IU50BI9XXs08ql1ayzw0yPy7pegI PqG2rP1Z3wB8dv+2JzX0kxP98Uzvow4n3/eI3/i9M4AvYTslTwEIwEuRlNsNSVbgXWKn L5kg== MIME-Version: 1.0 X-Received: by 10.112.210.102 with SMTP id mt6mr20036466lbc.73.1414684920156; Thu, 30 Oct 2014 09:02:00 -0700 (PDT) Received: by 10.25.215.134 with HTTP; Thu, 30 Oct 2014 09:02:00 -0700 (PDT) In-Reply-To: References: <20141027223229.23918.92412.idtracker@ietfa.amsl.com> Date: Thu, 30 Oct 2014 09:02:00 -0700 Message-ID: From: Martin Thomson To: "Ali C. Begen (abegen)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/ErM_Zgv6OUUaX6yMdXkeDve6kc0 Cc: Imed Bouazizi , Franck Denoual , Kevin Streeter , "webpush@ietf.org" Subject: Re: [Webpush] New Version Notification for draft-begen-webpush-dash-reqs-00.txt 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 16:03:33 -0000 On 30 October 2014 08:50, Ali C. Begen (abegen) wrote: > I asked the WG chairs to give us some time to present these core experiments, mention about our requirements and seek some guidance from the WG. I think that this work is more appropriate for the HTTP working group. From nobody Thu Oct 30 09:45:04 2014 Return-Path: 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 28A191A00FF for ; Thu, 30 Oct 2014 09:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 AQirQE43nLKA for ; Thu, 30 Oct 2014 09:45:02 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71AA41A0023 for ; Thu, 30 Oct 2014 09:45:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2383; q=dns/txt; s=iport; t=1414687502; x=1415897102; h=from:to:cc:subject:date:message-id:mime-version; bh=pyxTpq4VJc5om/Gl9LBl8yAbMlczr4UlPifNjQ2hn3c=; b=ckodP1pvO1ehOMF+NSkk5it+cTbbTfmAVvSskgtdQAJgJnof3LJj/SQg WpP5qX0AkPvtOfZupVUaY8F+WdBhoJvtQA/lx1XJKWizv3PciF38Ox4l8 92wJMnNQuplTTNb5chynA1u4hAlLcsuUvzYTChMgb3zs2VT4MpELfZBVH U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApYGAOxpUlStJA2B/2dsb2JhbABcgmsjVFjVKQIcgQgWAQEBAQF9g3kKAQEEI1QCEgEIAwEUCiACBB8RJgEEDgUIiCQDEgG1LI42DYRiAQEBAQEBAQEBAQEBAQEBAQEBAQEBF45Wggkxgn42gR4BBJINiUyRaIZog3hsgksBAQE X-IronPort-AV: E=Sophos;i="5.07,286,1413244800"; d="scan'208,217";a="367925866" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-8.cisco.com with ESMTP; 30 Oct 2014 16:45:01 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s9UGj17F021891 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Oct 2014 16:45:01 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Thu, 30 Oct 2014 11:45:01 -0500 From: "Ali C. Begen (abegen)" To: Martin Thomson Thread-Topic: [Webpush] New Version Notification for draft-begen-webpush-dash-reqs-00.txt Thread-Index: Ac/0YNgy+p1ODwswC0afPVpJ5XEbAg== Date: Thu, 30 Oct 2014 16:45:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_C15918F2FCDA0243A7C919DA7C4BE994302076C2xmbalnx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/top_57E2nRMG6t48pULXqn_lVKg Cc: Imed Bouazizi , Franck Denoual , Kevin Streeter , "webpush@ietf.org" Subject: Re: [Webpush] New Version Notification for draft-begen-webpush-dash-reqs-00.txt 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 16:45:04 -0000 --_000_C15918F2FCDA0243A7C919DA7C4BE994302076C2xmbalnx01ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBPY3QgMzAsIDIwMTQgNjowMiBQTSwgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29u QGdtYWlsLmNvbT4gd3JvdGU6DQo+DQo+IE9uIDMwIE9jdG9iZXIgMjAxNCAwODo1MCwgQWxpIEMu IEJlZ2VuIChhYmVnZW4pIDxhYmVnZW5AY2lzY28uY29tPiB3cm90ZToNCj4gPiBJIGFza2VkIHRo ZSBXRyBjaGFpcnMgdG8gZ2l2ZSB1cyBzb21lIHRpbWUgdG8gcHJlc2VudCB0aGVzZSBjb3JlIGV4 cGVyaW1lbnRzLCBtZW50aW9uIGFib3V0IG91ciByZXF1aXJlbWVudHMgYW5kIHNlZWsgc29tZSBn dWlkYW5jZSBmcm9tIHRoZSBXRy4NCj4NCj4gSSB0aGluayB0aGF0IHRoaXMgd29yayBpcyBtb3Jl IGFwcHJvcHJpYXRlIGZvciB0aGUgSFRUUCB3b3JraW5nIGdyb3VwLg0KDQpDb3VsZCBiZSBidXQg dGhlcmUgaXMgYW4gaW5jb21pbmcgbGlhaXNvbiBmcm9tIHRoZSBtcGVnIHRvIHRoZSB3ZWJwdXNo IFdHIHNvIEkgdGhpbmsgYSBzaG9ydCBkaXNjdXNzaW9uIHdpbGwgYmUgdXNlZnVsLg0KDQpBbHNv IGZvciBjbGFyaWZpY2F0aW9uIHdlIGFyZSBub3QgbWFraW5nIG9yIGFza2luZyBmb3IgYW55IGNo YW5nZXMgaW4gdGhlIGh0dHAgcHJvdG9jb2wuDQo= --_000_C15918F2FCDA0243A7C919DA7C4BE994302076C2xmbalnx01ciscoc_ Content-Type: text/html; charset="utf-8" Content-ID: <8309F77617427845A141BC5D162A5047@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHAgZGlyPSJsdHIi Pjxicj4NCk9uIE9jdCAzMCwgMjAxNCA2OjAyIFBNLCBNYXJ0aW4gVGhvbXNvbiAmbHQ7bWFydGlu LnRob21zb25AZ21haWwuY29tJmd0OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiAzMCBP Y3RvYmVyIDIwMTQgMDg6NTAsIEFsaSBDLiBCZWdlbiAoYWJlZ2VuKSAmbHQ7YWJlZ2VuQGNpc2Nv LmNvbSZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7IEkgYXNrZWQgdGhlIFdHIGNoYWlycyB0byBn aXZlIHVzIHNvbWUgdGltZSB0byBwcmVzZW50IHRoZXNlIGNvcmUgZXhwZXJpbWVudHMsIG1lbnRp b24gYWJvdXQgb3VyIHJlcXVpcmVtZW50cyBhbmQgc2VlayBzb21lIGd1aWRhbmNlIGZyb20gdGhl IFdHLjxicj4NCiZndDs8YnI+DQomZ3Q7IEkgdGhpbmsgdGhhdCB0aGlzIHdvcmsgaXMgbW9yZSBh cHByb3ByaWF0ZSBmb3IgdGhlIEhUVFAgd29ya2luZyBncm91cC48L3A+DQo8cCBkaXI9Imx0ciI+ Q291bGQgYmUgYnV0IHRoZXJlIGlzIGFuIGluY29taW5nIGxpYWlzb24gZnJvbSB0aGUgbXBlZyB0 byB0aGUgd2VicHVzaCBXRyBzbyBJIHRoaW5rIGEgc2hvcnQgZGlzY3Vzc2lvbiB3aWxsIGJlIHVz ZWZ1bC4NCjwvcD4NCjxwIGRpcj0ibHRyIj5BbHNvIGZvciBjbGFyaWZpY2F0aW9uIHdlIGFyZSBu b3QgbWFraW5nIG9yIGFza2luZyBmb3IgYW55IGNoYW5nZXMgaW4gdGhlIGh0dHAgcHJvdG9jb2wu DQo8YnI+DQo8L3A+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_C15918F2FCDA0243A7C919DA7C4BE994302076C2xmbalnx01ciscoc_-- From nobody Thu Oct 30 10:36:09 2014 Return-Path: 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 B3E781A0393 for ; Thu, 30 Oct 2014 10:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hygjTrnY3q6Y for ; Thu, 30 Oct 2014 10:36:07 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD84F1A036E for ; Thu, 30 Oct 2014 10:36:06 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id ge10so4702202lab.8 for ; Thu, 30 Oct 2014 10:36:04 -0700 (PDT) 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=tj6EjgDH5mrJcJdBQYzt3xQjvY+bL+KdCNkeLxWcoVE=; b=fDuYJzNGUL7r+u1TMuEfayCGz+eGbbOe/GYgnJsQgX8bb2DVJz7Y0l0CsWJbVo6vOC ICBjTGPD4ZenWQ177TOCnAsf8+1CtUNaaB+uj2DkG/OUOVeVP6PzfruesX8jwA32myK3 yuwDOQwd900Qo4jyYxAfyWEscVwUi50hpP0yputvb8M8uPSEZmSsXJxl+aZmhCJ+jtIl bxn/noLaKpRbnl162xN9bFRhhIEvXFTSCPokJoQYSbqzVRuKzb0OO+VABPlugQpd5n33 tbkRTvH/bAmwXH8VIfoEALWHFnz5n9n3kMo/TRkG2KUimTRwm2eXvGPer4PpC4bxQxI+ vblA== MIME-Version: 1.0 X-Received: by 10.113.5.7 with SMTP id ci7mr20964646lbd.9.1414690564808; Thu, 30 Oct 2014 10:36:04 -0700 (PDT) Received: by 10.25.215.134 with HTTP; Thu, 30 Oct 2014 10:36:04 -0700 (PDT) In-Reply-To: References: Date: Thu, 30 Oct 2014 10:36:04 -0700 Message-ID: From: Martin Thomson To: "Ali C. Begen (abegen)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/YcVFfoUSATN5s9kTZYvgvALVVGQ Cc: Imed Bouazizi , Franck Denoual , Kevin Streeter , "webpush@ietf.org" Subject: Re: [Webpush] New Version Notification for draft-begen-webpush-dash-reqs-00.txt 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 17:36:08 -0000 On 30 October 2014 09:45, Ali C. Begen (abegen) wrote: > Could be but there is an incoming liaison from the mpeg to the webpush WG so > I think a short discussion will be useful. How about we start that discussion here. How do you think that this is relevant to the work in this working group? From nobody Thu Oct 30 11:17:50 2014 Return-Path: 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 E542E1A1A58 for ; Thu, 30 Oct 2014 11:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_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 LuqBSqGypIom for ; Thu, 30 Oct 2014 11:17:40 -0700 (PDT) Received: from gator4135.hostgator.com (gator4135.hostgator.com [192.185.4.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38D221A1A4E for ; Thu, 30 Oct 2014 11:17:40 -0700 (PDT) Received: from [172.56.39.140] (port=32215 helo=[172.20.10.3]) by gator4135.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XjuHy-00024O-Hp; Thu, 30 Oct 2014 13:17:38 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Shida Schubert In-Reply-To: Date: Thu, 30 Oct 2014 11:17:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <695CE707-38A2-4A6C-8AF6-CADAD5EDECB6@ntt-at.com> References: To: Martin Thomson X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator4135.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source-IP: 172.56.39.140 X-Exim-ID: 1XjuHy-00024O-Hp X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([172.20.10.3]) [172.56.39.140]:32215 X-Source-Auth: shida@agnada.com X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/5Zj2mnPJPTao8a-XQIMEJWwXAZI Cc: Imed Bouazizi , Franck Denoual , "Ali C. Begen \(abegen\)" , Kevin Streeter , "webpush@ietf.org" Subject: Re: [Webpush] New Version Notification for draft-begen-webpush-dash-reqs-00.txt 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 18:17:48 -0000 I agree with Martin in that we should start the discussion on the = mailing list. If we see that we can benefit from F2F time, then we can allocate some = time at the meeting. =20 Shida as co-chair On Oct 30, 2014, at 10:36 AM, Martin Thomson = wrote: > On 30 October 2014 09:45, Ali C. Begen (abegen) = wrote: >> Could be but there is an incoming liaison from the mpeg to the = webpush WG so >> I think a short discussion will be useful. >=20 > How about we start that discussion here. How do you think that this > is relevant to the work in this working group? >=20 > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush From nobody Thu Oct 30 14:26:17 2014 Return-Path: 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 345821A87E9 for ; Thu, 30 Oct 2014 14:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 1IHgNV150Ryu for ; Thu, 30 Oct 2014 14:26:12 -0700 (PDT) Received: from mail.mozilla.com (zmmta2.corp.phx1.mozilla.com [63.245.216.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0EB91A883C for ; Thu, 30 Oct 2014 14:26:12 -0700 (PDT) Received: from mail.mozilla.com (localhost6.localdomain [127.0.0.1]) by zmmta2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPS id F4191102116 for ; Thu, 30 Oct 2014 14:26:11 -0700 (PDT) Received: from [10.252.25.111] (zlb1.mail.corp.phx1.mozilla.com [10.20.77.200]) (Authenticated sender: jconlin@mozilla.com) by zmmta2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id E433610201B for ; Thu, 30 Oct 2014 14:26:11 -0700 (PDT) Message-ID: <5452ACF4.10902@mozilla.com> Date: Thu, 30 Oct 2014 14:26:12 -0700 From: JR Conlin Organization: Mozilla.com User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Thunderbird/33.0 MIME-Version: 1.0 To: webpush@ietf.org References: <695CE707-38A2-4A6C-8AF6-CADAD5EDECB6@ntt-at.com> In-Reply-To: <695CE707-38A2-4A6C-8AF6-CADAD5EDECB6@ntt-at.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/0h1T9C9AZ9l7IcRNGhAbU4z7GQc Subject: Re: [Webpush] New Version Notification for draft-begen-webpush-dash-reqs-00.txt 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 21:26:15 -0000 If I understand the core of the proposal correctly, this is a request to layer a media content delivery and control system on top of WebPush. I'm going to start by saying that I'm a fan of simplicity. I believe that things should be minimal and play nice with other things. It's certainly possible to embed streaming rich media content and control into WebPush. It's also equally possible to layer the X windows protocol into WebPush for remote terminal display and control. I'm not really sure that WebPush should be the vector for that sort of thing. I think it's certainly possible for WebPush to help initiate a more efficient, dedicated protocol exchange between parties, possibly even using the same common HTTP2 (or like) carrier channel, but I don't believe it really behooves anyone to add more layers onto a fairly complex exchange as is. I'm also not quite certain that WebPush could address some of the larger issues that a media content delivery and control system might have (e.g. broadcast control of multiple recipients, metricing, multi-end secure key dispersal, etc.) On 2014/10/30 11:17 AM, Shida Schubert wrote: > > I agree with Martin in that we should start the discussion on the mailing list. > > If we see that we can benefit from F2F time, then we can allocate some time at the meeting. > > Shida as co-chair > > On Oct 30, 2014, at 10:36 AM, Martin Thomson wrote: > >> On 30 October 2014 09:45, Ali C. Begen (abegen) wrote: >>> Could be but there is an incoming liaison from the mpeg to the webpush WG so >>> I think a short discussion will be useful. >> >> How about we start that discussion here. How do you think that this >> is relevant to the work in this working group? >> >> _______________________________________________ >> Webpush mailing list >> Webpush@ietf.org >> https://www.ietf.org/mailman/listinfo/webpush > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > From nobody Thu Oct 30 16:58:14 2014 Return-Path: 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 3D9C91A8952 for ; Thu, 30 Oct 2014 16:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 z1wvjIw8xit4 for ; Thu, 30 Oct 2014 16:58:08 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98BEA1A8823 for ; Thu, 30 Oct 2014 16:58:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5211; q=dns/txt; s=iport; t=1414713488; x=1415923088; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=xx32sYPSQrGP+gUiWZsa1lWTt7EBq2dJ8S7NzLwv5dI=; b=Pn9u83J3FP/0iWhfK5BzGzTD6WProi0ggnxa0hezi54Umvc7IeXS/dUC 9niO71jDYOJx+3FoirAC5jG/cm2DzROjqxO8WIR5kNU4Tpsk+Hp7Job8z OxbR2t4wSFFrK7UTbxwJf+prlEA2UBl8QGE3HnVamV97DYvG0WLDfjoYW g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAFbQUlStJA2M/2dsb2JhbABcgmsjU1gEzE0KhnlUAoEoFgF9hAIBAQEEAQEBNy0HCRICAQgRBAEBAQoLCRAhBgsdCAEBBAESCBOIEAMRAQzDXw2GOgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEjh2CAzgKgyOBHgEEhRWMbIlIkVmGWoN3bIFIgQMBAQE X-IronPort-AV: E=Sophos;i="5.07,290,1413244800"; d="scan'208";a="364911846" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-1.cisco.com with ESMTP; 30 Oct 2014 23:58:06 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s9UNw6NM030174 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Oct 2014 23:58:06 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Thu, 30 Oct 2014 18:58:05 -0500 From: "Ali C. Begen (abegen)" To: JR Conlin , "webpush@ietf.org" Thread-Topic: [Webpush] New Version Notification for draft-begen-webpush-dash-reqs-00.txt Thread-Index: Ac/0YNgy+p1ODwswC0afPVpJ5XEbAgAMQs4AAAFymIAABpb1AP//0N5P Date: Thu, 30 Oct 2014 23:58:04 +0000 Message-ID: References: <695CE707-38A2-4A6C-8AF6-CADAD5EDECB6@ntt-at.com>, <5452ACF4.10902@mozilla.com> In-Reply-To: <5452ACF4.10902@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.222.164] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/GrYhSXRrJ-G3rDIYQ75LzQ1tDTI Subject: Re: [Webpush] New Version Notification for draft-begen-webpush-dash-reqs-00.txt 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 23:58:12 -0000 =0A= ________________________________________=0A= From: Webpush [webpush-bounces@ietf.org] on behalf of JR Conlin [jrconlin@m= ozilla.com]=0A= Sent: Thursday, October 30, 2014 5:26 PM=0A= To: webpush@ietf.org=0A= Subject: Re: [Webpush] New Version Notification for draft-begen-webpush-das= h-reqs-00.txt=0A= =0A= If I understand the core of the proposal correctly, this is a request to=0A= layer a media content delivery and control system on top of WebPush.=0A= =0A= acbegen: First of all, I apologize for the lack of depth of information on = the DASH stuff in the draft. The MPEG meeting was last week where it was de= cided to submit this draft to this WG (and send an official liaison to this= WG, too). Now, I assume you are familiar with how media is carried over HT= TP today with several not-so-different technologies like microsoft smooth, = apple hls, adobe zeri, netflix, etc. These technologies (and also DASH) alr= eady use HTTP as it is to distribute content (both live and on-demand) in a= "pull-based" fashion. A streaming client asks for a piece of content and t= he server sends it. Quite simple, widely deployed and works fine. Yet, thru= core experiments, the DASH subgroup at MPEG is investigating for new featu= res/solutions that might enhance the streaming service. For example, low-la= tency live streaming is quite desirable and for that we are looking into we= bsockets and push features of http/2. A lightweight messaging plane between= the servers (and possibly other devices on the network) and streaming clie= nts seems also quite desirable to solve a number of issues in existing depl= oyments. It is not strictly a control system per se. We will define the mes= sages that will be carried over this plane but now we are trying to choose = the best protocol to use on this plane. Hence, the interest in the webpush = protocol.=0A= =0A= I'm going to start by saying that I'm a fan of simplicity. I believe=0A= that things should be minimal and play nice with other things.=0A= =0A= acbegen: No disagreement here.=0A= =0A= It's certainly possible to embed streaming rich media content and=0A= control into WebPush. It's also equally possible to layer the X windows=0A= protocol into WebPush for remote terminal display and control. I'm not=0A= really sure that WebPush should be the vector for that sort of thing.=0A= =0A= I think it's certainly possible for WebPush to help initiate a more=0A= efficient, dedicated protocol exchange between parties, possibly even=0A= using the same common HTTP2 (or like) carrier channel, but I don't=0A= believe it really behooves anyone to add more layers onto a fairly=0A= complex exchange as is.=0A= =0A= acbegen: If it turns out the protocol solution you are trying to develop he= re will not fit our needs, then we will naturally use something else. I don= 't think you or anyone else on this list should reach a yes/no conclusion r= ight away. I looked at the list archives and the wg charter, and I could no= t be sure about the ultimate application target for the outcome of this WG,= but I have to say that given a large portion (if not huge) of the HTTP tra= ffic is already DASH-like media, I believe this WG should at least understa= nd the problems we have and maybe take our requirements into account.=0A= =0A= I'm also not quite certain that WebPush could address some of the larger=0A= issues that a media content delivery and control system might have (e.g.=0A= broadcast control of multiple recipients, metricing, multi-end secure=0A= key dispersal, etc.)=0A= =0A= acbegen: Don't worry about those details. As I said we are already in the p= rocess of defining what messages/info could/should/would be carried over th= e messaging plane using a web push protocol. That work belongs to MPEG not = to this WG.=0A= =0A= I hope this clarifies the intent of the draft.=0A= =0A= -acbegen=0A= =0A= On 2014/10/30 11:17 AM, Shida Schubert wrote:=0A= >=0A= > I agree with Martin in that we should start the discussion on the mailing= list.=0A= >=0A= > If we see that we can benefit from F2F time, then we can allocate some ti= me at the meeting.=0A= >=0A= > Shida as co-chair=0A= >=0A= > On Oct 30, 2014, at 10:36 AM, Martin Thomson w= rote:=0A= >=0A= >> On 30 October 2014 09:45, Ali C. Begen (abegen) wrote= :=0A= >>> Could be but there is an incoming liaison from the mpeg to the webpush = WG so=0A= >>> I think a short discussion will be useful.=0A= >>=0A= >> How about we start that discussion here. How do you think that this=0A= >> is relevant to the work in this working group?=0A= >>=0A= >> _______________________________________________=0A= >> Webpush mailing list=0A= >> Webpush@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/webpush=0A= >=0A= > _______________________________________________=0A= > Webpush mailing list=0A= > Webpush@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/webpush=0A= >=0A= =0A= _______________________________________________=0A= Webpush mailing list=0A= Webpush@ietf.org=0A= https://www.ietf.org/mailman/listinfo/webpush= From nobody Thu Oct 30 16:59:33 2014 Return-Path: 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 2FBF91A8823 for ; Thu, 30 Oct 2014 16:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 f4ANh4Qm_mpK for ; Thu, 30 Oct 2014 16:59:23 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE5E31A8952 for ; Thu, 30 Oct 2014 16:59:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=829; q=dns/txt; s=iport; t=1414713564; x=1415923164; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=XlRg7hvxa+bmLTuEJUWP+hBIRs4SKNMyoFxqfdN0Xfs=; b=FlH2PEaNIGN3QWyjI4418mDrEcpCoJk2K2MwbChiZpCXSD7oAa6Z18so OBrRrWtEBasQlfNA72g7MlT3y13ERy3Xa98K+ung/enCQtduXWWyqAUBw VCK6X4Gj5ZhJzCX8tv10MAbgDHWUOGERDOlfdyiSOXzWBziYDiG1h268i U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAN3PUlStJV2P/2dsb2JhbABcgmsjgSwE1GgCgSkWAQEBAQF9hAIBAQEEOj0CEAIBCBEEAQEBChQQIREdCAEBBA4FCIgkAxIBxAsNhjoBAQEBAQEBAQEBAQEBAQEBAQEBAQEXjlWBWBEBHzEHgy2BHgEEkhCJT4NCg0qKXoZrg3hsgQ85gQMBAQE X-IronPort-AV: E=Sophos;i="5.07,290,1413244800"; d="scan'208";a="91939921" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-5.cisco.com with ESMTP; 30 Oct 2014 23:59:23 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s9UNxMNZ023336 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Oct 2014 23:59:22 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Thu, 30 Oct 2014 18:59:21 -0500 From: "Ali C. Begen (abegen)" To: Martin Thomson Thread-Topic: [Webpush] New Version Notification for draft-begen-webpush-dash-reqs-00.txt Thread-Index: Ac/0YNgy+p1ODwswC0afPVpJ5XEbAgAMQs4AAALfAYk= Date: Thu, 30 Oct 2014 23:59:21 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.222.164] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/rI0ZL1bChUykyWhtosqp-B1BetE Cc: Imed Bouazizi , Franck Denoual , Kevin Streeter , "webpush@ietf.org" Subject: Re: [Webpush] New Version Notification for draft-begen-webpush-dash-reqs-00.txt 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 23:59:28 -0000 I replied to JR's email first and I hope it has enough meat to start the di= scussion. Please follow up as you see fit.=0A= ________________________________________=0A= From: Martin Thomson [martin.thomson@gmail.com]=0A= Sent: Thursday, October 30, 2014 1:36 PM=0A= To: Ali C. Begen (abegen)=0A= Cc: Kevin Streeter; webpush@ietf.org; Franck Denoual; Imed Bouazizi=0A= Subject: Re: [Webpush] New Version Notification for draft-begen-webpush-das= h-reqs-00.txt=0A= =0A= On 30 October 2014 09:45, Ali C. Begen (abegen) wrote:= =0A= > Could be but there is an incoming liaison from the mpeg to the webpush WG= so=0A= > I think a short discussion will be useful.=0A= =0A= How about we start that discussion here. How do you think that this=0A= is relevant to the work in this working group?=0A= From nobody Fri Oct 31 08:59:27 2014 Return-Path: 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 A2C901A9049 for ; Fri, 31 Oct 2014 08:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 b_drMAF25oN7 for ; Fri, 31 Oct 2014 08:59:24 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEA401AC413 for ; Fri, 31 Oct 2014 08:59:23 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id z12so6235150lbi.39 for ; Fri, 31 Oct 2014 08:59:22 -0700 (PDT) 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=zGqGPNFA8oMMJT2qkGYtFTGN7xEekTl+rNNhSBE30hA=; b=WCw4XOxx2glq6spOpS7JHxPIyqFdgBNiBeU3GfSoqVhsukqyV/kNru/0dcCRcjpbcf tgv/SU8T1lFiy5Wd08c2DecncvQhO4m9rnlvFpOaK0aKRdDIRYB5coSNp1WerPs7HOfR tRUIv4DfVjEFp8sBi+nPs36LzuLWyU0ajNqrM/TV2pwN1lrCCxFnCAXxtzlFKDR/KUnE SWTj203Lxb3oiESM81McxbzgxKUqrYdVjkGMKHhBNQVplNqkDsZ2xejUSePR/uNK+gUG 7fA8NOjiQHs8GmbctYyrE1onzfZSZoFft+7vepTVS68EKXQPc62yLSjMP1Mxs2pfgucC rR4w== MIME-Version: 1.0 X-Received: by 10.152.27.38 with SMTP id q6mr19793701lag.92.1414771162103; Fri, 31 Oct 2014 08:59:22 -0700 (PDT) Received: by 10.25.215.134 with HTTP; Fri, 31 Oct 2014 08:59:22 -0700 (PDT) In-Reply-To: References: <695CE707-38A2-4A6C-8AF6-CADAD5EDECB6@ntt-at.com> <5452ACF4.10902@mozilla.com> Date: Fri, 31 Oct 2014 08:59:22 -0700 Message-ID: From: Martin Thomson To: "Ali C. Begen (abegen)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/LNafI2AwsFFphU4YZflmnlFM1eQ Cc: JR Conlin , "webpush@ietf.org" Subject: Re: [Webpush] New Version Notification for draft-begen-webpush-dash-reqs-00.txt 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 15:59:25 -0000 On 30 October 2014 16:58, Ali C. Begen (abegen) wrote: > A lightweight messaging plane between the servers (and possibly other devices on the network) and streaming clients seems also quite desirable to solve a number of issues in existing deployments. If you already have a connection to the server, is there any reason you couldn't use HTTP to exchange these messages? Web Push is intended to provide a lightweight substitute for constant connectivity. This is intended to ensure availability for devices that need to conserve scarce resources, like a phone needs to conserve power for its radio. Sending messages over Web Push when the target of those requests is already connected to you is not appropriate. Performance worse than sending packets directly, and it is a far more expensive method of exchanging data. From nobody Fri Oct 31 09:10:49 2014 Return-Path: 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 0BDA81ACD26 for ; Fri, 31 Oct 2014 09:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 sNZHh_pJMgoe for ; Fri, 31 Oct 2014 09:10:19 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E66081A0024 for ; Fri, 31 Oct 2014 09:10:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4347; q=dns/txt; s=iport; t=1414771819; x=1415981419; h=from:to:cc:subject:date:message-id:mime-version; bh=FtvOoJGie6kG5Bp4D9zHavOu41wwYcTonQhpoVr25NE=; b=FeUXL1BjufeFDroJ2qCg38RM8dYGxMgT+YGwEXlVX3MZm1FKCL4Zk0dn wmS9uX5zCOK2K/SUsSZP5JMKBi7hgXcFnndpHsgYk5Y07Excuv0dGLT// Z9FMPvRlSkvjsY7CJ15LKxBj1BncavWO5yTj5o7baoQnCTdMZGBI4M8rR Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApkFAPOzU1StJA2J/2dsb2JhbABcgmsjVFiDBtFuAhx6FgEBAQEBfYQCAQEBAwEjVAISAQgEFAogAgQfESYBBA4FCIgkAwkJAbV9jjENhj4BAQEBAQEBAQEBAQEBAQEBAQEBAQEXjlaBbB0xgn42gR4FkhWJUpFshm2DeGyCSwEBAQ X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208,217";a="368200983" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-7.cisco.com with ESMTP; 31 Oct 2014 16:10:18 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s9VGAFqI011119 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 Oct 2014 16:10:18 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Fri, 31 Oct 2014 11:10:15 -0500 From: "Ali C. Begen (abegen)" To: Martin Thomson Thread-Topic: [Webpush] New Version Notification for draft-begen-webpush-dash-reqs-00.txt Thread-Index: Ac/1JSgS+p1ODwswC0afPVpJ5XEbAg== Date: Fri, 31 Oct 2014 16:10:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_C15918F2FCDA0243A7C919DA7C4BE9943021773Exmbalnx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/aXNtKIhaoOg-bnqySyfR-Pf6Yxo Cc: JR Conlin , "webpush@ietf.org" Subject: Re: [Webpush] New Version Notification for draft-begen-webpush-dash-reqs-00.txt 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 16:10:47 -0000 --_000_C15918F2FCDA0243A7C919DA7C4BE9943021773Exmbalnx01ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBPY3QgMzEsIDIwMTQgNTo1OSBQTSwgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29u QGdtYWlsLmNvbT4gd3JvdGU6DQo+DQo+IE9uIDMwIE9jdG9iZXIgMjAxNCAxNjo1OCwgQWxpIEMu IEJlZ2VuIChhYmVnZW4pIDxhYmVnZW5AY2lzY28uY29tPiB3cm90ZToNCj4gPiBBIGxpZ2h0d2Vp Z2h0IG1lc3NhZ2luZyBwbGFuZSBiZXR3ZWVuIHRoZSBzZXJ2ZXJzIChhbmQgcG9zc2libHkgb3Ro ZXIgZGV2aWNlcyBvbiB0aGUgbmV0d29yaykgYW5kIHN0cmVhbWluZyBjbGllbnRzIHNlZW1zIGFs c28gcXVpdGUgZGVzaXJhYmxlIHRvIHNvbHZlIGEgbnVtYmVyIG9mIGlzc3VlcyBpbiBleGlzdGlu ZyBkZXBsb3ltZW50cy4NCj4NCj4gSWYgeW91IGFscmVhZHkgaGF2ZSBhIGNvbm5lY3Rpb24gdG8g dGhlIHNlcnZlciwgaXMgdGhlcmUgYW55IHJlYXNvbg0KPiB5b3UgY291bGRuJ3QgdXNlIEhUVFAg dG8gZXhjaGFuZ2UgdGhlc2UgbWVzc2FnZXM/DQoNClRoZXNlIG1lc3NhZ2VzIHdvbid0IG5lY2Vz c2FyaWx5IGNvbWUgZnJvbSB0aGUgc2FtZSBzZXJ2ZXIuIEl0IGNvdWxkIGJlIGFuIGFuYWx5dGlj cyBzZXJ2ZXIgT3IgYW5vdGhlciBuZXR3b3JrIGVsZW1lbnQuDQoNCj4NCj4gV2ViIFB1c2ggaXMg aW50ZW5kZWQgdG8gcHJvdmlkZSBhIGxpZ2h0d2VpZ2h0IHN1YnN0aXR1dGUgZm9yIGNvbnN0YW50 DQo+IGNvbm5lY3Rpdml0eS4gVGhpcyBpcyBpbnRlbmRlZCB0byBlbnN1cmUgYXZhaWxhYmlsaXR5 IGZvciBkZXZpY2VzIHRoYXQNCj4gbmVlZCB0byBjb25zZXJ2ZSBzY2FyY2UgcmVzb3VyY2VzLCBs aWtlIGEgcGhvbmUgbmVlZHMgdG8gY29uc2VydmUNCj4gcG93ZXIgZm9yIGl0cyByYWRpby4NCg0K WWVzIEkgZ2V0IHRoYXQgcGFydCBhbmQgdGhhdCBpcyBvbmUgb2YgdGhlIHRoaW5ncyB0aGF0IG1h a2UgaXQgYXR0cmFjdGl2ZSBmb3IgbWUuDQoNCj4NCj4gU2VuZGluZyBtZXNzYWdlcyBvdmVyIFdl YiBQdXNoIHdoZW4gdGhlIHRhcmdldCBvZiB0aG9zZSByZXF1ZXN0cyBpcw0KPiBhbHJlYWR5IGNv bm5lY3RlZCB0byB5b3UgaXMgbm90IGFwcHJvcHJpYXRlLiAgUGVyZm9ybWFuY2Ugd29yc2UgdGhh bg0KPiBzZW5kaW5nIHBhY2tldHMgZGlyZWN0bHksIGFuZCBpdCBpcyBhIGZhciBtb3JlIGV4cGVu c2l2ZSBtZXRob2Qgb2YNCj4gZXhjaGFuZ2luZyBkYXRhLg0KDQpVbmRlcnN0b29kIGJ1dCBhcyBJ IHNhaWQgdGhlIG1lc3NhZ2VzIGNvdWxkIGJlIGNvbWluZyBmcm9tIHZhcmlvdXMgZW50aXRpZXMu DQo= --_000_C15918F2FCDA0243A7C919DA7C4BE9943021773Exmbalnx01ciscoc_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHAgZGlyPSJsdHIi Pjxicj4NCk9uIE9jdCAzMSwgMjAxNCA1OjU5IFBNLCBNYXJ0aW4gVGhvbXNvbiAmbHQ7bWFydGlu LnRob21zb25AZ21haWwuY29tJmd0OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiAzMCBP Y3RvYmVyIDIwMTQgMTY6NTgsIEFsaSBDLiBCZWdlbiAoYWJlZ2VuKSAmbHQ7YWJlZ2VuQGNpc2Nv LmNvbSZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7IEEgbGlnaHR3ZWlnaHQgbWVzc2FnaW5nIHBs YW5lIGJldHdlZW4gdGhlIHNlcnZlcnMgKGFuZCBwb3NzaWJseSBvdGhlciBkZXZpY2VzIG9uIHRo ZSBuZXR3b3JrKSBhbmQgc3RyZWFtaW5nIGNsaWVudHMgc2VlbXMgYWxzbyBxdWl0ZSBkZXNpcmFi bGUgdG8gc29sdmUgYSBudW1iZXIgb2YgaXNzdWVzIGluIGV4aXN0aW5nIGRlcGxveW1lbnRzLjxi cj4NCiZndDs8YnI+DQomZ3Q7IElmIHlvdSBhbHJlYWR5IGhhdmUgYSBjb25uZWN0aW9uIHRvIHRo ZSBzZXJ2ZXIsIGlzIHRoZXJlIGFueSByZWFzb248YnI+DQomZ3Q7IHlvdSBjb3VsZG4ndCB1c2Ug SFRUUCB0byBleGNoYW5nZSB0aGVzZSBtZXNzYWdlcz88L3A+DQo8cCBkaXI9Imx0ciI+VGhlc2Ug bWVzc2FnZXMgd29uJ3QgbmVjZXNzYXJpbHkgY29tZSBmcm9tIHRoZSBzYW1lIHNlcnZlci4gSXQg Y291bGQgYmUgYW4gYW5hbHl0aWNzIHNlcnZlciBPciBhbm90aGVyIG5ldHdvcmsgZWxlbWVudC4N CjwvcD4NCjxwIGRpcj0ibHRyIj4mZ3Q7PGJyPg0KJmd0OyBXZWIgUHVzaCBpcyBpbnRlbmRlZCB0 byBwcm92aWRlIGEgbGlnaHR3ZWlnaHQgc3Vic3RpdHV0ZSBmb3IgY29uc3RhbnQ8YnI+DQomZ3Q7 IGNvbm5lY3Rpdml0eS4gVGhpcyBpcyBpbnRlbmRlZCB0byBlbnN1cmUgYXZhaWxhYmlsaXR5IGZv ciBkZXZpY2VzIHRoYXQ8YnI+DQomZ3Q7IG5lZWQgdG8gY29uc2VydmUgc2NhcmNlIHJlc291cmNl cywgbGlrZSBhIHBob25lIG5lZWRzIHRvIGNvbnNlcnZlPGJyPg0KJmd0OyBwb3dlciBmb3IgaXRz IHJhZGlvLjwvcD4NCjxwIGRpcj0ibHRyIj5ZZXMgSSBnZXQgdGhhdCBwYXJ0IGFuZCB0aGF0IGlz IG9uZSBvZiB0aGUgdGhpbmdzIHRoYXQgbWFrZSBpdCBhdHRyYWN0aXZlIGZvciBtZS4NCjwvcD4N CjxwIGRpcj0ibHRyIj4mZ3Q7PGJyPg0KJmd0OyBTZW5kaW5nIG1lc3NhZ2VzIG92ZXIgV2ViIFB1 c2ggd2hlbiB0aGUgdGFyZ2V0IG9mIHRob3NlIHJlcXVlc3RzIGlzPGJyPg0KJmd0OyBhbHJlYWR5 IGNvbm5lY3RlZCB0byB5b3UgaXMgbm90IGFwcHJvcHJpYXRlLiZuYnNwOyBQZXJmb3JtYW5jZSB3 b3JzZSB0aGFuPGJyPg0KJmd0OyBzZW5kaW5nIHBhY2tldHMgZGlyZWN0bHksIGFuZCBpdCBpcyBh IGZhciBtb3JlIGV4cGVuc2l2ZSBtZXRob2Qgb2Y8YnI+DQomZ3Q7IGV4Y2hhbmdpbmcgZGF0YS48 L3A+DQo8cCBkaXI9Imx0ciI+VW5kZXJzdG9vZCBidXQgYXMgSSBzYWlkIHRoZSBtZXNzYWdlcyBj b3VsZCBiZSBjb21pbmcgZnJvbSB2YXJpb3VzIGVudGl0aWVzLg0KPGJyPg0KPC9wPg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_C15918F2FCDA0243A7C919DA7C4BE9943021773Exmbalnx01ciscoc_--