From nobody Mon Feb 1 10:43:13 2016 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 38F161B341C for ; Mon, 1 Feb 2016 10:43:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKRjHdasB3H9 for ; Mon, 1 Feb 2016 10:43:10 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 799F61B33D0 for ; Mon, 1 Feb 2016 10:43:10 -0800 (PST) Received: by mail-lb0-x22c.google.com with SMTP id x4so81562385lbm.0 for ; Mon, 01 Feb 2016 10:43:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=inuYnBs3qo01zYY8jcYNDn55euzUA5M6MjXU88gFX/0=; b=ge1gBEqgdixl07UzTOKfQjjs0nxemnOLIGUpauNkxB1M9OGrrwx9B6nXiQOSmUdQC9 tJlnGFdQISZxLCFU9ArSkOGHr4Bal4eNtU92rJUHUgkDoHtF+SB7xmloRiA/V6Vmn+R+ femX5vP1jc8xYqWRhwc/FPQYLq8Ang7/1pTvayYPnyZHdSsiBoho5DqDtt7l0d1upE5L f9QCBT0zd+W/DIE6zzt/YJ01r4hy4pLxi9eP1qonSqKccuF56Cd4T9HMQcNKBc0FR2up H8cjw65JCL3oJYVj3Iv+5XtgUHyvGvQP8F7h3kIuMZmf9xjDiAYqZ12QkM44HPqcekge PSSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=inuYnBs3qo01zYY8jcYNDn55euzUA5M6MjXU88gFX/0=; b=jgFk57hJQgcX+dG4E9Qkxkn+81nChZjW4zyhyNINCTa99HOUUpfnTZhmYO8kD6ToUU XON03Y1/SgUAFX0HEfMCtOmDug5GtknCCwD9FNz1MmHukfCnYe3Fbzxs87wn6zwkgYgg nGOJwI+Xe3CebkAP8OG3WjkT4el1HWRLNYJLlTojbnHYk/3cb7DDOM1oL09buOn7trA2 BZsCGsm/CjsNLuwDWr5R/u7KPzzOvbX7OuuVcF3ZlbXkwm3NQNdQRTWUK8TvzhT5HMIx ptSN0sQjYio6RgSsihhroclPyJKUgptgDsi+jZNpo2hRCBym+jdMeRGlScgUCKkUwhWW JqUA== X-Gm-Message-State: AG10YOQeTib+umVADJT6HadUQk0Evz5Zi4m33IXeInJ1HTBtqywsLk0/rI9iN/8ghchbNlei6YQaGSk9/mdH3SLS MIME-Version: 1.0 X-Received: by 10.112.198.102 with SMTP id jb6mr9107377lbc.44.1454352188481; Mon, 01 Feb 2016 10:43:08 -0800 (PST) Received: by 10.25.20.156 with HTTP; Mon, 1 Feb 2016 10:43:08 -0800 (PST) In-Reply-To: References: Date: Mon, 1 Feb 2016 18:43:08 +0000 Message-ID: From: Peter Beverloo To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11c34aa8930a9e052ab9c1bc Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Voluntary Application Server Identification -02 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, 01 Feb 2016 18:43:12 -0000 --001a11c34aa8930a9e052ab9c1bc Content-Type: text/plain; charset=UTF-8 Thank you for publishing the draft, Martin! While I'm not sure how much significance it carries since I'm listed as an editor, I do of course support the draft as the resolve to Issue 44. Server authentication and subscription association are important problems to us, and, pending any further feedback from the working group, we plan to adopt the proposed solution in our implementations. Thanks, Peter On Mon, Feb 1, 2016 at 1:56 AM, Martin Thomson wrote: > I have just posted a new version of the draft, taking the recent > feedback from discussions into account. > > https://tools.ietf.org/html/draft-thomson-webpush-vapid-02 > > This includes only the JWT option, with a lot more of the details > fleshed out. I've implemented it in order to create the example, and > that is dead simple to do. > > I think that this is the answer we want for issue 44 [44]. Does the > group agree? Is this worth adopting? > > [44] https://github.com/webpush-wg/webpush-protocol/issues/44 > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > --001a11c34aa8930a9e052ab9c1bc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you for publishing the draft, Martin!

=
While I'm not sure how much significance it carries since I'm = listed as an editor, I do of course support the draft as the resolve to Iss= ue 44.

Server authentication and subscription asso= ciation are important problems to us, and, pending any further feedback fro= m the working group, we plan to adopt the proposed solution in our implemen= tations.

Thanks,
Peter

On Mon, Feb 1, 2016= at 1:56 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
I have just posted a new version= of the draft, taking the recent
feedback from discussions into account.

https://tools.ietf.org/html/draft-thomson= -webpush-vapid-02

This includes only the JWT option, with a lot more of the details
fleshed out.=C2=A0 I've implemented it in order to create the example, = and
that is dead simple to do.

I think that this is the answer we want for issue 44 [44].=C2=A0 Does the group agree? Is this worth adopting?

[44] https://github.com/webpush-wg/webpush-p= rotocol/issues/44

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

--001a11c34aa8930a9e052ab9c1bc-- From nobody Mon Feb 1 12:33:52 2016 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 AB75D1B362F for ; Mon, 1 Feb 2016 12:33:50 -0800 (PST) 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 6IAvo8CtB13x for ; Mon, 1 Feb 2016 12:33:48 -0800 (PST) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EF1F1B3633 for ; Mon, 1 Feb 2016 12:33:46 -0800 (PST) Received: by mail-oi0-x22f.google.com with SMTP id p187so97886733oia.2 for ; Mon, 01 Feb 2016 12:33:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JtHQB3C2PunDTWjoq8uIGj6v9zkns1IzBVBO7Q9MBxo=; b=VVNPbl7YYy3f5zGtLvPFzsgyfX9QjrnEbtIZa+ZKVGmdfrf5Nns7j8/BPt6SWSrznd O1wU8EyQCc26QU9LKSTAVbOoRraTLxRXpYMr01Dos9RdcZlkel+9gGrhRMgLMbSEUzMB iF2EcgrJ6JUBkT5dmh3C5d0q2QseN0yW2hJ5UZ9UCUAU/1ajyCSq2fT4ouxCzJ45Ioof 4Fpo2E3MAbtL+2O8A7PHaMiZdW4suxncWjblnCFM1fX60DiEjyVAFZXaXk46H7+jhc0w SkOptMXZBYLwpwKlMuO8VC30nRKF4kEjMpmNJxgqxZXisQh74UCY8GfMttHC3UWFmXLI MuHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=JtHQB3C2PunDTWjoq8uIGj6v9zkns1IzBVBO7Q9MBxo=; b=SkrUKBNVcgTt2qe5oEqgGD1To3wclaSaWUfbDqUUHdDMusZf3Haeu0iMWsVZQqmB+G 4oBE4ILUNCxG9QawpWjUj+0BX4jo8t1Oy5b+h+kA3WvloIE2lnkt6Q3cntWW9Nx65UhB e0P8pfSNZczp8o2piIOfDeC21Y2WWpAuipMwYMyyHLsSUtM+ItmhP+XWFwIKR2BaoRV0 YcFNxqN/74vdX2UFNn5w9GI1vFuOhYPQ8S9SKfnzKI4Ev9+5MMdT8c4q4nQM6hxXVviq y0rBsfJ384lhw8BysCR89EPkykUZI7I/eQldDc4Oh48mb3TN+Ebr9VTOkFSS/0FTPlfO Z66g== X-Gm-Message-State: AG10YOTx3tFlaqvSTw1bVWOpmusQNsz205VoppjtwGfpH2O2ZipOFhArt4by1CQzv55pGbVbqBlCJvQKn4YJNw== MIME-Version: 1.0 X-Received: by 10.202.204.16 with SMTP id c16mr9494586oig.93.1454358826027; Mon, 01 Feb 2016 12:33:46 -0800 (PST) Received: by 10.76.8.74 with HTTP; Mon, 1 Feb 2016 12:33:45 -0800 (PST) In-Reply-To: References: Date: Mon, 1 Feb 2016 12:33:45 -0800 Message-ID: From: Costin Manolache To: Peter Beverloo Content-Type: multipart/alternative; boundary=001a1134fde8339abd052abb4dce Archived-At: Cc: Martin Thomson , "webpush@ietf.org" Subject: Re: [Webpush] Voluntary Application Server Identification -02 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, 01 Feb 2016 20:33:50 -0000 --001a1134fde8339abd052abb4dce Content-Type: text/plain; charset=UTF-8 +1 Costin On Mon, Feb 1, 2016 at 10:43 AM, Peter Beverloo wrote: > Thank you for publishing the draft, Martin! > > While I'm not sure how much significance it carries since I'm listed as an > editor, I do of course support the draft as the resolve to Issue 44. > > Server authentication and subscription association are important problems > to us, and, pending any further feedback from the working group, we plan to > adopt the proposed solution in our implementations. > > Thanks, > Peter > > On Mon, Feb 1, 2016 at 1:56 AM, Martin Thomson > wrote: > >> I have just posted a new version of the draft, taking the recent >> feedback from discussions into account. >> >> https://tools.ietf.org/html/draft-thomson-webpush-vapid-02 >> >> This includes only the JWT option, with a lot more of the details >> fleshed out. I've implemented it in order to create the example, and >> that is dead simple to do. >> >> I think that this is the answer we want for issue 44 [44]. Does the >> group agree? Is this worth adopting? >> >> [44] https://github.com/webpush-wg/webpush-protocol/issues/44 >> >> _______________________________________________ >> 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 > > --001a1134fde8339abd052abb4dce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

Costin

On Mon, Feb 1, 2016 at 10:43 AM, Pe= ter Beverloo <beverloo@google.com> wrote:
Thank you for publishing the draft, Mart= in!

While I'm not sure how much significance it carr= ies since I'm listed as an editor, I do of course support the draft as = the resolve to Issue 44.

Server authentication and= subscription association are important problems to us, and, pending any fu= rther feedback from the working group, we plan to adopt the proposed soluti= on in our implementations.

Thanks,
P= eter

On Mon, Feb 1, 2016 at 1:56 AM, Mart= in Thomson <martin.thomson@gmail.com> wrote:
I have just posted a new version of the draft, ta= king the recent
feedback from discussions into account.

https://tools.ietf.org/html/draft-thomson= -webpush-vapid-02

This includes only the JWT option, with a lot more of the details
fleshed out.=C2=A0 I've implemented it in order to create the example, = and
that is dead simple to do.

I think that this is the answer we want for issue 44 [44].=C2=A0 Does the group agree? Is this worth adopting?

[44] https://github.com/webpush-wg/webpush-p= rotocol/issues/44

_______________________________________________
Webpush mailing list
Webpush@ietf.org<= br> https://www.ietf.org/mailman/listinfo/webpush


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


--001a1134fde8339abd052abb4dce-- From nobody Mon Feb 1 15:32:06 2016 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 2633E1B389C for ; Mon, 1 Feb 2016 15:32:05 -0800 (PST) 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 QZq71tzx2xG5 for ; Mon, 1 Feb 2016 15:32:03 -0800 (PST) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 383BF1B389B for ; Mon, 1 Feb 2016 15:32:03 -0800 (PST) Received: by mail-io0-x235.google.com with SMTP id 9so97319243iom.1 for ; Mon, 01 Feb 2016 15:32:03 -0800 (PST) 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=6ff9AbbUQBxEMoa3DyiDuUp9Ow2E33WgKS1gFSB2BN0=; b=iBa7XzX64Yg3NunbK7EB7AM/sTXEQiQEGEHEX6l0/5NuYgWZgWjSyruvrlXN2OByTw ob+99Tuw88mUe6n1tksfRfyv155airmSect+1aeTGARVsIQhcGKbQJIJ0d25MU4g58lY OpTWdkwA5b1qd8eomrMQzT541MBv+kJcq+y7ByDK0GPVBTwFoy4TgQEQK7pmzrb5jbvP bQTHUatJsoxUwUVtVxuftywqh1bos3LnJPwkF1yHFOMtrNJuOqq0IKy0qfTRyM9DdddH ljeSsNZ/yMMdUX9KHE+W+YPMSPGuAGLPGzLYhFnpxVY+YXS33B27YDu2BJPBFeYLZSg4 LtAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=6ff9AbbUQBxEMoa3DyiDuUp9Ow2E33WgKS1gFSB2BN0=; b=mJ+Xok2uJPrf5rTmU8CKMmBeTliiQhZZfXwmD9Yzd+CEE2M+StZVufV1fMjYqJOuIF SuPRj1H47H5wzf8WwAfdK9s0hDkPw6L+HzAouYEqXLl7Sy8OcYLFh2mhnDOqbQf62g66 Q53fBiKYmbJMnGy3zw6k1+urPWEhJ1rRC0lJyqDlg3XzNp1rWCDC0YPIPRFuroYVCuaq AvchtRo2C9a4eGpae0RaAZgMXVd6GtfAavfZpm4R40OiK3ZwQoAnEmlU93X2VGok7TRA EIeajmXSf8cTohOQnfYZbbyNoQ6srfHsIaM6fHaaoyOF/hfRI9P3Jw3nEWiL7wcDk1p0 iYkA== X-Gm-Message-State: AG10YOTFQ5ZSTSyYEJ0zD77O+rB0U+OT78D9QZlaYEQwNBJg80jU99tdc7tJH/8I9szfVmNbNeF9H9xGXTLvAg== MIME-Version: 1.0 X-Received: by 10.107.131.38 with SMTP id f38mr20660242iod.190.1454369522623; Mon, 01 Feb 2016 15:32:02 -0800 (PST) Received: by 10.36.149.130 with HTTP; Mon, 1 Feb 2016 15:32:02 -0800 (PST) Date: Tue, 2 Feb 2016 10:32:02 +1100 Message-ID: From: Martin Thomson To: Shida Schubert Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Brian Raymor , "webpush@ietf.org" Subject: [Webpush] Work venue (Re: Niceness or urgency of messages) 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, 01 Feb 2016 23:32:05 -0000 On 1 February 2016 at 18:38, Shida Schubert wrote: > I think for now we need to strike a balance of contributors not having have > to waste their energy keeping the WG in loop but making sure some of the > critical changes discussed on github is distributed on the ML. I think that we've missed that balance recently. I will try to ensure that I bring any substantive discussion here and limit discussion on github to editorial matters. From nobody Wed Feb 3 18:12:45 2016 Return-Path: X-Original-To: webpush@ietf.org Delivered-To: webpush@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2371B3863; Wed, 3 Feb 2016 18:12:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160204021242.9637.6244.idtracker@ietfa.amsl.com> Date: Wed, 03 Feb 2016 18:12:42 -0800 Archived-At: Cc: webpush@ietf.org Subject: [Webpush] I-D Action: draft-ietf-webpush-protocol-03.txt 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, 04 Feb 2016 02:12:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web-Based Push Notifications Working Group of the IETF. Title : Generic Event Delivery Using HTTP Push Authors : Martin Thomson Elio Damaggio Brian Raymor Filename : draft-ietf-webpush-protocol-03.txt Pages : 30 Date : 2016-02-03 Abstract: A simple protocol for the delivery of realtime events to user agents is described. This scheme uses HTTP/2 server push. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-webpush-protocol/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-webpush-protocol-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-webpush-protocol-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 3 18:34:09 2016 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 467401B3883 for ; Wed, 3 Feb 2016 18:34:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, 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 y7AaIqGMszgq for ; Wed, 3 Feb 2016 18:34:06 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0123.outbound.protection.outlook.com [207.46.100.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31F441B3882 for ; Wed, 3 Feb 2016 18:34:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=AhxFRtJDCbNU0QHJITQLRskS7A0iAcKsvi/Zebkm/Yg=; b=dFRp/e57c8426prj4TmTyAL/WnxRySzGsYc2vptlm5G1kykxQ89IvYXi1dc6Q6cpJzD76frO/uExd8/FL+ivZ4+6i/p/39MEbM2AVvChwiDZ97/A32KkMTp48p+mGe7o0NdxssNMYF6KIGRcuiRNZhByAiV9GKB6Gwt+LZmNUQ0= Received: from BY2PR0301MB0647.namprd03.prod.outlook.com (10.160.63.14) by BY2PR0301MB0645.namprd03.prod.outlook.com (10.160.63.13) with Microsoft SMTP Server (TLS) id 15.1.396.15; Thu, 4 Feb 2016 02:34:04 +0000 Received: from BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) by BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) with mapi id 15.01.0403.016; Thu, 4 Feb 2016 02:34:03 +0000 From: Brian Raymor To: "webpush@ietf.org" Thread-Topic: [Webpush] I-D Action: draft-ietf-webpush-protocol-03.txt Thread-Index: AQHRXvGUSrgpeS4ey0OmWkbqckU1op8bJofQ Date: Thu, 4 Feb 2016 02:34:03 +0000 Message-ID: References: <20160204021242.9637.6244.idtracker@ietfa.amsl.com> In-Reply-To: <20160204021242.9637.6244.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2601:600:8000:5a8:18ae:ba4c:a3c7:bed1] x-ms-office365-filtering-correlation-id: 383940fe-ddf8-4937-bd3f-08d32d0ba5dc x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0645; 5:c/Hu4qIVdpy6wkunYubscUU/bQJMu+ssxzbcwtj4v+OwUMsFXDuZu+Mj4wozxUtcet6B17qrW8xs/uaYWJAAMdVKqoT0nzg93wVSzyy0Kzw9c4HpiZCYmx10TO0y/2Lyf11KE9FcNtKND114dslBWg==; 24:adfW0cc+QpsudYM6cHtbH1uUlzjflijba1t/dVvJwj3nynM0z6WAmE4ifBZ3GUpILYjL5Psvjo+YGlhnvfquK85yfk2PDIv4sWZngv6hI08= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0301MB0645; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:BY2PR0301MB0645; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0645; x-forefront-prvs: 084285FC5C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377424004)(377454003)(8990500004)(87936001)(33656002)(40100003)(76576001)(10400500002)(5005710100001)(77096005)(5002640100001)(10290500002)(5004730100002)(5003600100002)(10090500001)(74316001)(189998001)(2900100001)(5001960100002)(2351001)(3660700001)(5008740100001)(230783001)(450100001)(6116002)(92566002)(586003)(1220700001)(1730700002)(1096002)(102836003)(122556002)(76176999)(3280700002)(107886002)(19580405001)(2501003)(106116001)(54356999)(2950100001)(19580395003)(99286002)(50986999)(2906002)(15975445007)(86362001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0645; H:BY2PR0301MB0647.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2016 02:34:03.7000 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0645 Archived-At: Subject: Re: [Webpush] I-D Action: draft-ietf-webpush-protocol-03.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, 04 Feb 2016 02:34:08 -0000 -03 incorporates pull requests from Martin, including the changes to subscr= iption sets for Herve's scenarios (explicit correlation from the user agent= ) and the new push message updates section (message collapsing). In addition, the Push-Receipt header field has been transitioned to a link= relation type which closes https://github.com/webpush-wg/webpush-protocol/= issues/61 ... -----Original Message----- From: Webpush [mailto:webpush-bounces@ietf.org] On Behalf Of internet-draft= s@ietf.org Sent: Wednesday, February 3, 2016 6:13 PM To: i-d-announce@ietf.org Cc: webpush@ietf.org Subject: [Webpush] I-D Action: draft-ietf-webpush-protocol-03.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web-Based Push Notifications Working Grou= p of the IETF. Title : Generic Event Delivery Using HTTP Push Authors : Martin Thomson Elio Damaggio Brian Raymor Filename : draft-ietf-webpush-protocol-03.txt Pages : 30 Date : 2016-02-03 Abstract: A simple protocol for the delivery of realtime events to user agents is described. This scheme uses HTTP/2 server push. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-webpush-protocol/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-webpush-protocol-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-webpush-protocol-03 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Webpush mailing list Webpush@ietf.org https://www.ietf.org/mailman/listinfo/webpush From nobody Thu Feb 4 12:29:33 2016 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 489591AD0D3 for ; Thu, 4 Feb 2016 12:29:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 VD3xf6IkJ1VO for ; Thu, 4 Feb 2016 12:29:29 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0764.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::764]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC9F21AD0D2 for ; Thu, 4 Feb 2016 12:29:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VTrusW85KpZjGkHZ1eLKMwjLI9zfPuImwE/qeQb/dJI=; b=PbW6bk5YeNXEfM3SowVugNK17OsGDq7Clf/HLXg+HkaknROdLQ34tDCywvI+WB8MCeCjkZIg2x0r+zAQbgLS+BbHyugbthlckugXaAnOaoZpvmQa04p2U6DsSUU21xW4RtFhQzfrZJ/cZt0WcGDilgppvzQru/TGZbkM4x5APug= Received: from BY2PR0301MB0647.namprd03.prod.outlook.com (10.160.63.14) by BY2PR0301MB0648.namprd03.prod.outlook.com (10.160.63.140) with Microsoft SMTP Server (TLS) id 15.1.396.15; Thu, 4 Feb 2016 20:29:07 +0000 Received: from BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) by BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) with mapi id 15.01.0403.016; Thu, 4 Feb 2016 20:29:07 +0000 From: Brian Raymor To: "webpush@ietf.org" Thread-Topic: Urgency of Messages Thread-Index: AdFe9QCWSAtzWeHZRk65x3keYm8NZw== Date: Thu, 4 Feb 2016 20:29:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2601:600:8000:5a8:a991:fd36:d5f3:19e] x-ms-office365-filtering-correlation-id: a5731274-9b74-4581-4c05-08d32da1d4d0 x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0648; 5:R5i9P2j3uIkg5khRgJoCDCE2TUErs62QJiJOwJJ2EzfDYWUviqf14Tyu5mEgSjnDQeShFACUAK6kPUGVfb52RoySAek+QffpDJdSHTWT97+osiX/5yUzcuLNPq2g7ox49TRpSwY57CaksyMueBgtGg==; 24:czU/DzomiKlfubToTFa0yHZNWDz52i5TqXL1h81VE6Wn7axl/XHUfBq9Izcl+G9OhBEgA31MYiG/SbVLKH+mLWXgyc6TKxv1rlA+FGy0SBA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0301MB0648; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR0301MB0648; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0648; x-forefront-prvs: 084285FC5C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(33656002)(102836003)(54356999)(10400500002)(99286002)(450100001)(3280700002)(74316001)(6116002)(586003)(2900100001)(1220700001)(86612001)(5005710100001)(2501003)(15975445007)(229853001)(5004730100002)(40100003)(76576001)(5002640100001)(50986999)(5008740100001)(77096005)(3480700002)(3660700001)(10290500002)(10090500001)(2906002)(2351001)(107886002)(5003600100002)(92566002)(110136002)(122556002)(5001960100002)(11100500001)(189998001)(1730700002)(19580395003)(86362001)(87936001)(1096002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0648; H:BY2PR0301MB0647.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2016 20:29:06.9808 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0648 Archived-At: Subject: [Webpush] Urgency of Messages 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, 04 Feb 2016 20:29:31 -0000 https://github.com/webpush-wg/webpush-protocol/issues/28 There's been a long conversation in this issue that I'd like to bring to th= e mailing list for broader discussion and closure. Questions: a) Is there rough consensus to support this feature in the protocol? b) If so, then what is the shape of the design? I believe that there's general agreement that we need the following capabil= ities for an application server publishing a message to the push service: * 0 | "high" | "urgent" - send urgent message immediately and wake up the u= ser agent=20 * 1 | "normal" - send opportunistically - send prior to expiration if no ur= gent messages are queued * 2 | "low" | "non-urgent" - send opportunistically - allow to expire if no= urgent messages are queued Multiple variations for the mapping have been suggested. I don't have a str= ong feeling for whether the mapping should be 0 or "high" or "urgent". GCM= uses "high" and "normal" in its Priority field. APNS uses 10 and 5.=20 In addition, not everyone favors the "Nice" header field name unless they'r= e quite fond of Unix. Perhaps we could rename it to "Urgency". I would pref= er to avoid "Priority". As I remarked in the issue: Priority is too overloaded a term, since it may refer to: * Message Ordering * Urgency ("Niceness") as in "Is it urgent enough to wake the device and bu= rn the battery?" Then there's another question of whether there also needs to be a public pr= otocol between the user agent and push service to either hint at the device= state or apply an urgency "filter": Benjamin writes: >> @costinm Do you plan on introducing additional flags for the client when= making a >> notification request that conveys all this additional knowledge (on wifi= , 'charging', etc) >> to the Push service? Is it the right place for the Push service to choos= e how to optimize >> delivery, or should the client flag indicate what level of urgency it wa= nts notifications for? Costin responds: > GCM uses a binary protocol for UA-push service, which already has the fla= gs ( it wouldn't work > otherwise for the deep sleep for example ). I think common ones could be= added to webpush > spec, but with lots of care - we don't want the UA to send notifications = too often (for example > on state change).=20 > A start would be to define a header for the 'monitor' request, with a lis= t of flags, and > define common ones ( charging, network type ).=20 I'm curious what the working group thinks about these proposals. Are there = alternative approaches that we should consider? Thanks, ...Brian From nobody Thu Feb 4 18:12:37 2016 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 F30CA1B2CCD for ; Thu, 4 Feb 2016 18:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaT3psE6xiUZ for ; Thu, 4 Feb 2016 18:12:33 -0800 (PST) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B1801B2CCF for ; Thu, 4 Feb 2016 18:12:32 -0800 (PST) Received: by mail-yw0-x236.google.com with SMTP id h129so40346537ywb.1 for ; Thu, 04 Feb 2016 18:12:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=wruFaeLabbyZiXpcOYUA8gXy5tK+iYy/qH53oeQpzzE=; b=NEPuavFnZojNQ2QUBGofCGpGjHQK3dTChLS/KgT4AAGyp03ZhdyAgcwe+ASujsDeur +jHL1NHeTJX1ltydb7cz4oSzEOkbmjqTv1+TEODSvt79nHyAU6rRGBVWSEtWSv3toPBo wmuFtfM27eYE4w+M5uqhEC0qWDF9ng8HxnpImwAWZKZF5UuOFFDK7/i+xXrX+/3xvUNP Hk5M4RTIIjyPnGRQ6pucjupDuCuDmvqgD8Yyd7JoqYlXx4vCnG5blxr7HX96a6lSJm7l w5vTgMeOXcaFW9XW1J0a/Kl60djOjhEUKT788B6KTViHRhbqb3EPhx+uCbvqbpyFihMf 5YmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=wruFaeLabbyZiXpcOYUA8gXy5tK+iYy/qH53oeQpzzE=; b=aH3M8VKnUQkhPhiF1wGLGty7CeRfXAaEPuQbUh1P60wLLuw7BZL/MsiF9N8Nc88/xX e4/itygbnIpYoR4c721270FIldAfYy8DXgfkiaanLj+ILHJWZ+eF43Qj19J3ZMdBWLVS 7tLXjnm6Vl/YigCsuQVhvkoY5/AD3MGJm7zjvThr+r2yIhj0APpSZUbkn6F6nOe4RgL+ OdAG9ovZ+h4SBwI7/JnGRIdaemGrZqjRS6JP8ZiDcyCEYzEYTpPQj1ZOojMaKfYvnxZF +z6CIX13/XXFzC1p1A/oTRGsU0pL3IM1jU8ROsBdfUEn9htZGYCUZ3LtQOW5HOtdmzmz Orrw== X-Gm-Message-State: AG10YOSqNccQGRI4u5miWnwo8WTx3HkDgMqdDP30OpSLHp1+RuWd42Gt0YEbfuidJWSA8/0i/Qpz0ZvAYvZsDHmp MIME-Version: 1.0 X-Received: by 10.13.207.65 with SMTP id r62mr6027293ywd.27.1454638352168; Thu, 04 Feb 2016 18:12:32 -0800 (PST) Received: by 10.37.196.68 with HTTP; Thu, 4 Feb 2016 18:12:32 -0800 (PST) Date: Thu, 4 Feb 2016 18:12:32 -0800 Message-ID: From: Benjamin Bangert To: "webpush@ietf.org" Content-Type: multipart/alternative; boundary=001a114e6d7e422bb6052afc6208 Archived-At: Subject: [Webpush] Require the TTL header 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, 05 Feb 2016 02:12:36 -0000 --001a114e6d7e422bb6052afc6208 Content-Type: text/plain; charset=UTF-8 Can we require a TTL value for web-push notifications? The current behavior is not obvious to an implementer and likely to lead them to think they've successfully sent messages when they're actually dropped. If you omit the TTL, then the value is assumed to be 0. This results in the message being dropped, but the 201 status is still returned. An astute implementer will notice in this case that no Location header is present, since no resource was actually created. Regarding the resource creation, the spec does not clearly state whether a Location header should be returned for a TTL of 0 since its intended that the message is only delivered to an online user. If so, it would be useful to mention. In the past 2 days, out of approximately 76k webpush notifications to our service, 23k of them were dropped due to a missing TTL header, but a 201 status was returned. Defaulting a missing TTL header seems ripe for implementer issues (I have a hard time believing this many dropped notifications was intentional). If it was a required header, we could return a 401 which would very quickly alert developers about the problem. Cheers, Ben --001a114e6d7e422bb6052afc6208 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Can we require a TTL value f= or web-push notifications?

The current behavior is not obvious= to an implementer and likely to lead them to think they've successfull= y sent messages when they're actually dropped.

If you omit= the TTL, then the value is assumed to be 0. This results in the message be= ing dropped, but the 201 status is still returned. An astute implementer wi= ll notice in this case that no Location header is present, since no resourc= e was actually created.

Regarding the resource creation, the spec do= es not clearly state whether a Location header should be returned for a TTL= of 0 since its intended that the message is only delivered to an online us= er. If so, it would be useful to mention.

In the past 2 days, = out of approximately 76k webpush notifications to our service, 23k of them = were dropped due to a missing TTL header, but a 201 status was returned.
Defaulting a missing TTL header seems ripe for implementer issue= s (I have a hard time believing this many dropped notifications was intenti= onal). If it was a required header, we could return a 401 which would very = quickly alert developers about the problem.

Cheers,
B= en
--001a114e6d7e422bb6052afc6208-- From nobody Thu Feb 4 21:42:24 2016 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 9F1FB1B35A4 for ; Thu, 4 Feb 2016 21:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, 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 r-ncnWlbQIvD for ; Thu, 4 Feb 2016 21:42:21 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0109.outbound.protection.outlook.com [207.46.100.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A64A1B35A3 for ; Thu, 4 Feb 2016 21:42:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WlZRF5F/+b5FLg84ltOq8lLnUzbha8d2jyHYukCwDwE=; b=hxZ7eyyzYys5MpOd/ddhoBc2mvV1PFX4RuvhTPY/skux6FTsVh/hApRWU8l3lLZ51vlWQMUf1vNnLbpJtqULiHhTyxk4bIsOj08kYn+WtckJ4k7wcy6WaVZ6KOw2zoFVNxPB3k3uGsR2KtL4oGgCy4Ohe+/sh7OCceHD+U6yu9I= Received: from BY2PR0301MB0647.namprd03.prod.outlook.com (10.160.63.14) by BY2PR0301MB0645.namprd03.prod.outlook.com (10.160.63.13) with Microsoft SMTP Server (TLS) id 15.1.396.15; Fri, 5 Feb 2016 05:42:19 +0000 Received: from BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) by BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) with mapi id 15.01.0403.016; Fri, 5 Feb 2016 05:42:19 +0000 From: Brian Raymor To: Benjamin Bangert , "webpush@ietf.org" Thread-Topic: [Webpush] Require the TTL header Thread-Index: AQHRX7qxmPHR5E4P70WaFLGI8LoOcp8c4q4A Date: Fri, 5 Feb 2016 05:42:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: mozilla.com; dkim=none (message not signed) header.d=none;mozilla.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2601:600:8000:5a8:a991:fd36:d5f3:19e] x-ms-office365-filtering-correlation-id: 8375cac5-27ac-4bf4-ca81-08d32def1cf3 x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0645; 5:kQeXz1/Y2QSreQ2KKhlPmAZEDWng29Ku4FpezCinC0wN5PIyikZQCw0NJCSUwdG+0qYqSSaewCkl6R4Sd6u4r5/5ZxW5NL4ds7v0SgNw87lSBnQaL9NmlclrO5H6wKwoXFXAAJDvWMbHNvE/NTblKQ==; 24:+3oBBC3awmexZg2IiVlAEMzeFBqiORdOBiyQCabtvq7W7qNnmMbtu5fnfUWHF+yC5YhQ+eelG5vN+jP7vBhhS/VXfBu0VC2rolWyVZ9MjDk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0301MB0645; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:BY2PR0301MB0645; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0645; x-forefront-prvs: 0843C17679 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(76576001)(77096005)(40100003)(87936001)(10400500002)(5004730100002)(5005710100001)(33656002)(11100500001)(10290500002)(5003600100002)(5002640100001)(10090500001)(74316001)(189998001)(2900100001)(3280700002)(5001960100002)(5008740100001)(3660700001)(586003)(1220700001)(102836003)(1096002)(76176999)(122556002)(92566002)(6116002)(15975445007)(107886002)(106116001)(50986999)(19580395003)(54356999)(2906002)(2950100001)(86362001)(2501003)(5001770100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0645; H:BY2PR0301MB0647.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2016 05:42:19.2575 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0645 Archived-At: Subject: Re: [Webpush] Require the TTL header 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, 05 Feb 2016 05:42:22 -0000 DQo+IENhbiB3ZSByZXF1aXJlIGEgVFRMIHZhbHVlIGZvciB3ZWItcHVzaCBub3RpZmljYXRpb25z Pw0KDQpJJ2Qgc3VwcG9ydCB0aGlzIHJlcXVpcmVtZW50IGlmIGl0IGhlbHBzIHRvIGVuZm9yY2Ug Y29ycmVjdCBiZWhhdmlvciBpbiBpbXBsZW1lbnRhdGlvbnMuDQoNCj4gUmVnYXJkaW5nIHRoZSBy ZXNvdXJjZSBjcmVhdGlvbiwgdGhlIHNwZWMgZG9lcyBub3QgY2xlYXJseSBzdGF0ZSB3aGV0aGVy IGEgTG9jYXRpb24gaGVhZGVyIHNob3VsZCBiZSByZXR1cm5lZCBmb3IgYSBUVEwgb2YgMA0KPiBz aW5jZSBpdHMgaW50ZW5kZWQgdGhhdCB0aGUgbWVzc2FnZSBpcyBvbmx5IGRlbGl2ZXJlZCB0byBh biBvbmxpbmUgdXNlci4gSWYgc28sIGl0IHdvdWxkIGJlIHVzZWZ1bCB0byBtZW50aW9uLg0KDQpS RkM3MjMxIHN0YXRlczoNCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzIzMSNzZWN0 aW9uLTQuMy4zDQoNCiAgIElmIG9uZSBvciBtb3JlIHJlc291cmNlcyBoYXMgYmVlbiBjcmVhdGVk IG9uIHRoZSBvcmlnaW4gc2VydmVyIGFzIGENCiAgIHJlc3VsdCBvZiBzdWNjZXNzZnVsbHkgcHJv Y2Vzc2luZyBhIFBPU1QgcmVxdWVzdCwgdGhlIG9yaWdpbiBzZXJ2ZXINCiAgIFNIT1VMRCBzZW5k IGEgMjAxIChDcmVhdGVkKSByZXNwb25zZSBjb250YWluaW5nIGEgTG9jYXRpb24gaGVhZGVyDQog ICBmaWVsZCB0aGF0IHByb3ZpZGVzIGFuIGlkZW50aWZpZXIgZm9yIHRoZSBwcmltYXJ5IHJlc291 cmNlIGNyZWF0ZWQNCiAgIChTZWN0aW9uIDcuMS4yKSBhbmQgYSByZXByZXNlbnRhdGlvbiB0aGF0 IGRlc2NyaWJlcyB0aGUgc3RhdHVzIG9mIHRoZQ0KICAgcmVxdWVzdCB3aGlsZSByZWZlcnJpbmcg dG8gdGhlIG5ldyByZXNvdXJjZShzKS4NCg0KPiBJZiBpdCB3YXMgYSByZXF1aXJlZCBoZWFkZXIs IHdlIGNvdWxkIHJldHVybiBhIDQwMSB3aGljaCB3b3VsZCB2ZXJ5IHF1aWNrbHkgYWxlcnQgZGV2 ZWxvcGVycyBhYm91dCB0aGUgcHJvYmxlbS4NCg0KRGlkIHlvdSBpbnRlbmQgYSA0MDAgKEJhZCBS ZXF1ZXN0KSByYXRoZXIgdGhhbiBhIDQwMSAoVW5hdXRob3JpemVkKT8NCg0KLi4uQnJpYW4NCg0K From nobody Fri Feb 5 03:22:03 2016 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 DCF671A21B7 for ; Fri, 5 Feb 2016 03:22:00 -0800 (PST) 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 d2aCO6I_Ydll for ; Fri, 5 Feb 2016 03:21:59 -0800 (PST) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB4AE1A21B4 for ; Fri, 5 Feb 2016 03:21:59 -0800 (PST) Received: by mail-io0-x22e.google.com with SMTP id 9so125592331iom.1 for ; Fri, 05 Feb 2016 03:21:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ldvpRlRMAQmoyAggrIHqlk96LxuD4ktYlHqVLBMYLdE=; b=mNSLzQy5rhN5M9xbtcxXN25xKRs0qC/OmsMrkbZtvzCQW0jfqVGBKfvoJewnTu6zQm exaOxNebZPPgtXedJKhUTVjRO9KLkAN6qyKGcQH266nCoHLT++lzG6SifxYZfUMn9umm BSsYAGheGDDLaQDnH2HOd0gLZ3MxgHiMop9OZFLIyDM9JAX98gLk4hxv+GdlNuLW0po4 q7NIAYxoy1alWAuCiw/I32MmwF+i26NLczWvRL+qpT1QqDuV3W3rxgiX7TJ4NgKkuo4w q9RM/K5yLjhpIfihl+iLRcFhciF3bYtVe7CDgF9PeORANcP4UoNLXa3pfBzTT0p8Spbp pxtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ldvpRlRMAQmoyAggrIHqlk96LxuD4ktYlHqVLBMYLdE=; b=T7hTuC86vWlImJdNH2brPcL6zN3GaITZffxe9xEn/23QNzYpfwXLwQEQiR2uhD7JTN 1rEofRBCVW7QQRcXuetUBaKfJUTBRz/x5E2FmRGMyMtpwhbMo0S2pflaZdcy4sn485mO 9tULjaOU1nDodHSIBFUL10S3656vbQGw3bl+K4gaD9ABWLK01ChW8NkWbuosXcm/PYps X5gXSWwzUnziksbPtMcM2cCt5UiLPB+oHw9o7IFm63i12Oi+DoZqYs1aB+s/CCRj1NK0 Vx8bSQWhQ7l911I1ZufUGn9tL+TQERc4Ye73sd80DcS9X0MKYnym/Z0Mvzs532pWGD8+ 2N5w== X-Gm-Message-State: AG10YOT4Ccm19DwhZ0lMuFDd1XpopeloZQlpxmrYEmWmQxiOlX2XRFXBARc050/ymRbeAKYHRWWvqhyStD5k+w== MIME-Version: 1.0 X-Received: by 10.107.33.14 with SMTP id h14mr13200761ioh.108.1454671319057; Fri, 05 Feb 2016 03:21:59 -0800 (PST) Received: by 10.36.53.79 with HTTP; Fri, 5 Feb 2016 03:21:58 -0800 (PST) In-Reply-To: References: Date: Fri, 5 Feb 2016 22:21:58 +1100 Message-ID: From: Martin Thomson To: Brian Raymor Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Urgency of Messages 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, 05 Feb 2016 11:22:01 -0000 I think that you have the right idea here, picking urgency. On 5 February 2016 at 07:29, Brian Raymor wrote: >> A start would be to define a header for the 'monitor' request, with a list of flags, and >> define common ones ( charging, network type ). > > I'm curious what the working group thinks about these proposals. Are there alternative approaches that we should consider? I think that it would be better to simply have the client indicate the urgency of the messages it wants to receive. That way, there's a clear understanding of what it will receive without being subject to some unspecified algorithm in the push service. We can make some suggestions perhaps. For instance: On power and wifi: urgency = very-low On one but not both: urgency = low On neither: urgency = normal (or absent) Low battery: urgency = high Setting a value indicates that the UA wants "normal" delivery of messages at that urgency. Higher urgency values than what was advertised would get accelerated delivery. Lower values would get stored and delivered later. We can also try to set some guidelines around what each urgency means: high = incoming phone call, time-sensitive alert normal = chat message, first email notification, calendar message low = subsequent email notification very-low = advertising That might help establish some consistency between applications in terms of what they use, so that user agents can set values with some confidence that they will be respected. I tried that with -nice, but it could definitely be improved. From nobody Fri Feb 5 03:26:16 2016 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 DB49F1A21C1 for ; Fri, 5 Feb 2016 03:26:14 -0800 (PST) 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 M2BleDXHnkOH for ; Fri, 5 Feb 2016 03:26:13 -0800 (PST) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9DD31A21C0 for ; Fri, 5 Feb 2016 03:26:13 -0800 (PST) Received: by mail-ig0-x22e.google.com with SMTP id hb3so11592959igb.0 for ; Fri, 05 Feb 2016 03:26:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OZP9f1H2pQ/70tHe22ok/0Aj1pRor4BeFIwSe1jOMlg=; b=p6s1yBR1yeo96hbvJ5800hb3AsyDq6Fp1MOl6B8bbJAPplxGYVRY5K1TtCamtFE/Nw 5mskc8a46wsSRK/ylWaYa+JUYkybh+aG5ZkIYffqDCCMIUPZUYng/GBqRI72JLUe/UNU SeAcLF7kCf4in7+ST+GQsIHTqfMhXgzxAnwgP4CtPPEmJpVjJdPSCfO2UCrOb/yxO3Bv SCEHuInEPk2OgNf+x985QPlRB2f+KdryKJWhMBjQmU2Tl3A0VGjqRA45lb+uYQl9vH5V kWxaJkg11NEHwVPPB9iFAwDWjgxRtqR4BhxuY+nX7knUxr/IWxRDPD6xRtOZamTz9wsw gLOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OZP9f1H2pQ/70tHe22ok/0Aj1pRor4BeFIwSe1jOMlg=; b=fttUa/KAOdDRBq3c+BNljZ0BMEqW2zamA9RdIggSbUI+V6PDjjhnAx7Pv6phB5UhwS sdRNmCEAqLpouVcTlTp8IZ+edzxxW1ybNaRzdLbxF5f0OhbNL7iybmB+eGusUgP0dNfK MJPCInKYa08qoA4c+Oy7HVWgRQxkQtIYNFWVri6vHsmas/HfGA+Q1608ZXu+gAN8/3MM tMV9EbqDh7YJ5pO7+XAhpZWmIHZD5egY26qD8OOGLMESgHl+zQ48j1ymaRWO1t9aKIgG PiWA892egxltwGyFurVhQbMuHJfOJ+rtZkPeOacyLQrGtk3LnwwvFIugvNZl5RHpqnXE 1cPw== X-Gm-Message-State: AG10YOTmOXGu+eeDi3zqHm7CS/CFIutYvEhgqVdKMlbmaXfagNVudhY4dKp8+trfU328FHC4kT7At4qQbOKDsw== MIME-Version: 1.0 X-Received: by 10.50.12.3 with SMTP id u3mr6483336igb.77.1454671573117; Fri, 05 Feb 2016 03:26:13 -0800 (PST) Received: by 10.36.53.79 with HTTP; Fri, 5 Feb 2016 03:26:13 -0800 (PST) In-Reply-To: References: Date: Fri, 5 Feb 2016 22:26:13 +1100 Message-ID: From: Martin Thomson To: Brian Raymor Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Benjamin Bangert , "webpush@ietf.org" Subject: Re: [Webpush] Require the TTL header 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, 05 Feb 2016 11:26:15 -0000 On 5 February 2016 at 16:42, Brian Raymor wrote: >> Can we require a TTL value for web-push notifications? > > I'd support this requirement if it helps to enforce correct behavior in implementations. I'm also in support of this. Ben makes a good argument. Removing defaults and being up-front about potential mistakes was a pretty good way to ensure solid interoperability for h2. From nobody Fri Feb 5 03:31:55 2016 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 6ACFB1A6EE1 for ; Fri, 5 Feb 2016 03:31:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E_Gtxi4asaxY for ; Fri, 5 Feb 2016 03:31:51 -0800 (PST) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E83F1A6EDE for ; Fri, 5 Feb 2016 03:31:51 -0800 (PST) Received: by mail-vk0-x22d.google.com with SMTP id c3so8128888vkb.3 for ; Fri, 05 Feb 2016 03:31:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=WlKIVEN+e6j3GwGrtXHcHgR715tua5XFwnc+74e9HUg=; b=nMZUmZBWNjq94My0zOWu9VUUDZWqXsYzXxb+3TqdVpB64Hvt73zGPwYkY2qHa3kko7 XzVKaHNwMKLKQw+5oJe7Lvn5MWg4/qJkjeqwm5HKryybwFCzQrow/33s26nKKTDNnZlN nxJYtBij5yN6RLi7KrRwx4Db5ycsG6On+4W+QdfkT/hT9G9TuaT250zrOJ8H5WC9t0N2 7iBNtaxNZec1YgaioKSIVluHgh4Cpt+svwxUta8HmQsX8LlSwuvCoPSpguy2dtsEF7k+ ERwH5rh4PRPcSdFMTOFHktPe4NzGcULh6E52jfVA6/XJN+gkrkr2MqPpFQF0y862CIy3 5uug== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=WlKIVEN+e6j3GwGrtXHcHgR715tua5XFwnc+74e9HUg=; b=K5BtB8uHWqshxu4aAI6cwLUO1t3uifWQGdnSgGv/xadspeYA57iLXxQhRAWz1tsREC jRpOECEj/im5pB2pFd0IG9AW/RxY53cXbkmgJ0ddKybfvOXsXG3o31T/JCSgA8G9LArx WPueEFOKqJ0FBqwjQuauT75jcRF2EhSr/NYeQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=WlKIVEN+e6j3GwGrtXHcHgR715tua5XFwnc+74e9HUg=; b=h/6BG/j9bO+gEcgkVylT0oad/jXKX7UEI6Pg+7icOL4N8GQNX0oBiuC4NNFwD2QsTz cF6WjEGq9blPkixRmmx1ycOhw4KcW1gD5Tu2UvuAEYHuC9vE9/1FrgETqN2gStHqtcHH UdS8F6uEsk00cULb229UtdPaGSd9Tyl2Ac08TrfNBnB/InxItyWcvxvT9VQKPQvx82YB SNx4T2KKIUBqe7Tif2vYN5E2cCL9RAL4UL1RDi0JWKk5oRjWFecrbFaGYZ/QUWjKY65G 1A+AcvoX8/JGRH1uWv3egtYXaJ5WV3Ssb92cfdwbeG9Q77l3BPstVXd1SgvL1LnIcFjt XK2Q== X-Gm-Message-State: AG10YOS81UDZPLvXCxDzfBDEzl4URE3TLddgA9ENvosFgfFfwy2vBt+LMhowA/H/7pSOg9Qos9L6d1kHv8CzMpgR X-Received: by 10.31.16.146 with SMTP id 18mr9181784vkq.152.1454671910080; Fri, 05 Feb 2016 03:31:50 -0800 (PST) MIME-Version: 1.0 Sender: miguelg@google.com Received: by 10.31.226.68 with HTTP; Fri, 5 Feb 2016 03:31:30 -0800 (PST) In-Reply-To: References: From: Miguel Garcia Date: Fri, 5 Feb 2016 11:31:30 +0000 X-Google-Sender-Auth: 8FOSI1wQv4RoubZ9d2z3cTk4qjQ Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11431b4677723b052b043291 Archived-At: Cc: Benjamin Bangert , Brian Raymor , "webpush@ietf.org" Subject: Re: [Webpush] Require the TTL header 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, 05 Feb 2016 11:31:53 -0000 --001a11431b4677723b052b043291 Content-Type: text/plain; charset=UTF-8 I agree with this as well. Especially since the default behavior in GCM is different (not supplying it defaults to ttl of 4 weeks). Making it required would avoid unnecessary confusion. On Fri, Feb 5, 2016 at 11:26 AM, Martin Thomson wrote: > On 5 February 2016 at 16:42, Brian Raymor > wrote: > >> Can we require a TTL value for web-push notifications? > > > > I'd support this requirement if it helps to enforce correct behavior in > implementations. > > I'm also in support of this. Ben makes a good argument. Removing > defaults and being up-front about potential mistakes was a pretty good > way to ensure solid interoperability for h2. > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > --001a11431b4677723b052b043291 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree with this as well. Especially since the default be= havior in GCM is different (not supplying it defaults to ttl of 4 w= eeks). Making it required would avoid unnecessary confusion.

On Fri, Feb 5, 2016 at 11:= 26 AM, Martin Thomson <martin.thomson@gmail.com> wrot= e:
On 5 February 2016 at= 16:42, Brian Raymor <Bria= n.Raymor@microsoft.com> wrote:
>> Can we require a TTL value for web-push notifications?
>
> I'd support this requirement if it helps to enforce correct behavi= or in implementations.

I'm also in support of this.=C2=A0 Ben makes a good argument.=C2= =A0 Removing
defaults and being up-front about potential mistakes was a pretty good
way to ensure solid interoperability for h2.

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

--001a11431b4677723b052b043291-- From nobody Fri Feb 5 08:26:56 2016 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 0FBBA1B3B2A for ; Fri, 5 Feb 2016 08:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.876 X-Spam-Level: X-Spam-Status: No, score=-0.876 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, HTTP_ESCAPED_HOST=1.125, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGFKjroFOt0a for ; Fri, 5 Feb 2016 08:26:53 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0771.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:771]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D18B1B3B29 for ; Fri, 5 Feb 2016 08:26:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wK76w4usqZrKgJNmcIKFXaKyuXQ9dqUyNK187NR1/0Q=; b=O73J7F4s6R7f3edb1SdjaswjHO1o6JxB1NrkTcZNdelvyQd9Ek4xFNlGu1Va397mDusUL94gytQdeklTHDkZLNxePMQ8WoxEArQBLk5GByTPPHve0kcg1h8LHR62fuRzqq5PnmZndD6B8yWmkjnZoGB2PW5BR9tXlP+ml7iBVLw= Received: from BY2PR0301MB0647.namprd03.prod.outlook.com (10.160.63.14) by BY2PR0301MB0645.namprd03.prod.outlook.com (10.160.63.13) with Microsoft SMTP Server (TLS) id 15.1.396.15; Fri, 5 Feb 2016 16:26:34 +0000 Received: from BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) by BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) with mapi id 15.01.0403.016; Fri, 5 Feb 2016 16:26:34 +0000 From: Brian Raymor To: Miguel Garcia , Martin Thomson Thread-Topic: [Webpush] Require the TTL header Thread-Index: AQHRX7qxmPHR5E4P70WaFLGI8LoOcp8c4q4AgABt5oCAAAF6AIAAUj4Q Date: Fri, 5 Feb 2016 16:26:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: chromium.org; dkim=none (message not signed) header.d=none; chromium.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2601:600:8000:5a8:c5c7:6c53:91d6:3b] x-ms-office365-filtering-correlation-id: 41c0c42c-8f15-415c-4c0c-08d32e491d34 x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0645; 5:XjBTVc9i8AEZ2pINtOG/tdE4R43F505N250d0aocIy6SpDzQylMyrUfAMyKsnnLpSMl58vkz5eXPwvoLC3JrSjMfs/3tvDQoHfjRPFnb5dMK4TzdT+JD74u4tfhERmFwxkz8sM3gsEu5LAwmcPy3Zw==; 24:PkaNjZFZE/FanNXTK9ghp9fm0sLKt7TOVtHEdhXZL07ItdSldi53ER+mIC83+5XZdunFRmeMt7PKAIQiI+/P2ujDX9zj+oThsh6M1QZHrfM= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0301MB0645; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:BY2PR0301MB0645; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0645; x-forefront-prvs: 0843C17679 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(377454003)(1096002)(790700001)(86612001)(76176999)(122556002)(102836003)(92566002)(6116002)(93886004)(3660700001)(5008740100001)(19617315012)(3280700002)(5001960100002)(586003)(1220700001)(19580405001)(50986999)(19300405004)(19580395003)(5001770100001)(4326007)(2906002)(54356999)(99286002)(2950100001)(86362001)(106116001)(15975445007)(16236675004)(19625215002)(5005710100001)(87936001)(40100003)(76576001)(77096005)(10400500002)(33656002)(2900100001)(74316001)(189998001)(10090500001)(11100500001)(5002640100001)(5003600100002)(5004730100002)(10290500002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0645; H:BY2PR0301MB0647.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR0301MB06471B81A391EBBFCEEC29CF83D20BY2PR0301MB0647_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2016 16:26:34.5266 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0645 Archived-At: Cc: Benjamin Bangert , "webpush@ietf.org" Subject: Re: [Webpush] Require the TTL header 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, 05 Feb 2016 16:26:55 -0000 --_000_BY2PR0301MB06471B81A391EBBFCEEC29CF83D20BY2PR0301MB0647_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBvcGVuZWQgLSBodHRwczovL2dpdGh1Yi5jb20vd2VicHVzaC13Zy93ZWJwdXNoLXByb3RvY29s L2lzc3Vlcy83Ng0KDQoNCkZyb206IG1pZ3VlbGdAZ29vZ2xlLmNvbSBbbWFpbHRvOm1pZ3VlbGdA Z29vZ2xlLmNvbV0gT24gQmVoYWxmIE9mIE1pZ3VlbCBHYXJjaWENClNlbnQ6IEZyaWRheSwgRmVi cnVhcnkgNSwgMjAxNiAzOjMyIEFNDQpUbzogTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29u QGdtYWlsLmNvbT4NCkNjOiBCcmlhbiBSYXltb3IgPEJyaWFuLlJheW1vckBtaWNyb3NvZnQuY29t PjsgQmVuamFtaW4gQmFuZ2VydCA8YmJhbmdlcnRAbW96aWxsYS5jb20+OyB3ZWJwdXNoQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW1dlYnB1c2hdIFJlcXVpcmUgdGhlIFRUTCBoZWFkZXINCg0KSSBh Z3JlZSB3aXRoIHRoaXMgYXMgd2VsbC4gRXNwZWNpYWxseSBzaW5jZSB0aGUgZGVmYXVsdCBiZWhh dmlvciBpbiBHQ008JTIwaHR0cHM6L2RldmVsb3BlcnMuZ29vZ2xlLmNvbS9jbG91ZC1tZXNzYWdp bmcvY29uY2VwdC1vcHRpb25zI3R0bD4gaXMgZGlmZmVyZW50IChub3Qgc3VwcGx5aW5nIGl0IGRl ZmF1bHRzIHRvIHR0bCBvZiA0IHdlZWtzKS4gTWFraW5nIGl0IHJlcXVpcmVkIHdvdWxkIGF2b2lk IHVubmVjZXNzYXJ5IGNvbmZ1c2lvbi4NCg0KT24gRnJpLCBGZWIgNSwgMjAxNiBhdCAxMToyNiBB TSwgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTxtYWlsdG86bWFydGlu LnRob21zb25AZ21haWwuY29tPj4gd3JvdGU6DQpPbiA1IEZlYnJ1YXJ5IDIwMTYgYXQgMTY6NDIs IEJyaWFuIFJheW1vciA8QnJpYW4uUmF5bW9yQG1pY3Jvc29mdC5jb208bWFpbHRvOkJyaWFuLlJh eW1vckBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQo+PiBDYW4gd2UgcmVxdWlyZSBhIFRUTCB2YWx1 ZSBmb3Igd2ViLXB1c2ggbm90aWZpY2F0aW9ucz8NCj4NCj4gSSdkIHN1cHBvcnQgdGhpcyByZXF1 aXJlbWVudCBpZiBpdCBoZWxwcyB0byBlbmZvcmNlIGNvcnJlY3QgYmVoYXZpb3IgaW4gaW1wbGVt ZW50YXRpb25zLg0KDQpJJ20gYWxzbyBpbiBzdXBwb3J0IG9mIHRoaXMuICBCZW4gbWFrZXMgYSBn b29kIGFyZ3VtZW50LiAgUmVtb3ZpbmcNCmRlZmF1bHRzIGFuZCBiZWluZyB1cC1mcm9udCBhYm91 dCBwb3RlbnRpYWwgbWlzdGFrZXMgd2FzIGEgcHJldHR5IGdvb2QNCndheSB0byBlbnN1cmUgc29s aWQgaW50ZXJvcGVyYWJpbGl0eSBmb3IgaDIuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpXZWJwdXNoIG1haWxpbmcgbGlzdA0KV2VicHVzaEBpZXRm Lm9yZzxtYWlsdG86V2VicHVzaEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vd2VicHVzaA0KDQo= --_000_BY2PR0301MB06471B81A391EBBFCEEC29CF83D20BY2PR0301MB0647_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv UGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxl LW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkkgb3BlbmVkIC0gPGEgaHJlZj0iaHR0 cHM6Ly9naXRodWIuY29tL3dlYnB1c2gtd2cvd2VicHVzaC1wcm90b2NvbC9pc3N1ZXMvNzYiPg0K aHR0cHM6Ly9naXRodWIuY29tL3dlYnB1c2gtd2cvd2VicHVzaC1wcm90b2NvbC9pc3N1ZXMvNzY8 L2E+IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+IG1pZ3VlbGdAZ29vZ2xlLmNvbSBbbWFpbHRvOm1pZ3VlbGdAZ29vZ2xlLmNvbV0NCjxi Pk9uIEJlaGFsZiBPZiA8L2I+TWlndWVsIEdhcmNpYTxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXks IEZlYnJ1YXJ5IDUsIDIwMTYgMzozMiBBTTxicj4NCjxiPlRvOjwvYj4gTWFydGluIFRob21zb24g Jmx0O21hcnRpbi50aG9tc29uQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IEJyaWFuIFJh eW1vciAmbHQ7QnJpYW4uUmF5bW9yQG1pY3Jvc29mdC5jb20mZ3Q7OyBCZW5qYW1pbiBCYW5nZXJ0 ICZsdDtiYmFuZ2VydEBtb3ppbGxhLmNvbSZndDs7IHdlYnB1c2hAaWV0Zi5vcmc8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtXZWJwdXNoXSBSZXF1aXJlIHRoZSBUVEwgaGVhZGVyPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWdyZWUgd2l0 aCB0aGlzIGFzIHdlbGwuIEVzcGVjaWFsbHkgc2luY2UgdGhlIGRlZmF1bHQgYmVoYXZpb3IgaW4N CjxhIGhyZWY9IiUyMGh0dHBzOi9kZXZlbG9wZXJzLmdvb2dsZS5jb20vY2xvdWQtbWVzc2FnaW5n L2NvbmNlcHQtb3B0aW9ucyN0dGwiPkdDTTwvYT4gaXMgZGlmZmVyZW50IChub3Qgc3VwcGx5aW5n IGl0IGRlZmF1bHRzIHRvIHR0bCBvZiA0IHdlZWtzKS4gTWFraW5nIGl0IHJlcXVpcmVkIHdvdWxk IGF2b2lkIHVubmVjZXNzYXJ5IGNvbmZ1c2lvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgRmViIDUsIDIwMTYgYXQgMTE6MjYgQU0sIE1hcnRp biBUaG9tc29uICZsdDs8YSBocmVmPSJtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+bWFydGluLnRob21zb25AZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gNSBGZWJy dWFyeSAyMDE2IGF0IDE2OjQyLCBCcmlhbiBSYXltb3IgJmx0OzxhIGhyZWY9Im1haWx0bzpCcmlh bi5SYXltb3JAbWljcm9zb2Z0LmNvbSI+QnJpYW4uUmF5bW9yQG1pY3Jvc29mdC5jb208L2E+Jmd0 OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyBDYW4gd2UgcmVxdWlyZSBhIFRUTCB2YWx1ZSBmb3Igd2Vi LXB1c2ggbm90aWZpY2F0aW9ucz88YnI+DQomZ3Q7PGJyPg0KJmd0OyBJJ2Qgc3VwcG9ydCB0aGlz IHJlcXVpcmVtZW50IGlmIGl0IGhlbHBzIHRvIGVuZm9yY2UgY29ycmVjdCBiZWhhdmlvciBpbiBp bXBsZW1lbnRhdGlvbnMuPGJyPg0KPGJyPg0KSSdtIGFsc28gaW4gc3VwcG9ydCBvZiB0aGlzLiZu YnNwOyBCZW4gbWFrZXMgYSBnb29kIGFyZ3VtZW50LiZuYnNwOyBSZW1vdmluZzxicj4NCmRlZmF1 bHRzIGFuZCBiZWluZyB1cC1mcm9udCBhYm91dCBwb3RlbnRpYWwgbWlzdGFrZXMgd2FzIGEgcHJl dHR5IGdvb2Q8YnI+DQp3YXkgdG8gZW5zdXJlIHNvbGlkIGludGVyb3BlcmFiaWxpdHkgZm9yIGgy LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCldl YnB1c2ggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOldlYnB1c2hAaWV0Zi5vcmci PldlYnB1c2hAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby93ZWJwdXNoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby93ZWJwdXNoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_BY2PR0301MB06471B81A391EBBFCEEC29CF83D20BY2PR0301MB0647_-- From nobody Fri Feb 5 08:55:49 2016 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 087021B3B8C for ; Fri, 5 Feb 2016 08:55:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RudVkP1VBQ3S for ; Fri, 5 Feb 2016 08:55:45 -0800 (PST) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D30501B3B8B for ; Fri, 5 Feb 2016 08:55:44 -0800 (PST) Received: by mail-yk0-x233.google.com with SMTP id r207so62671029ykd.2 for ; Fri, 05 Feb 2016 08:55:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WbMGGw10LyP31iajB+9R7wfeLXFopJMLwGoMOWY66yE=; b=b+Y58mII/4Ei/O1tAtxrfkA/S0XDeXYzFG8w2HSpp46OamDU3sTSYSWxDuBqqNbXin a0uql3a/B0apaOF/zGR5N+t0dzcww3wLXdARZbmY+TRlEExX0HH7a2aU2xLOIuwRMCrj 8mdCeEzqAC3jR+krIK9QraoIC4AutvNFdCQa4VsYy7Ev6254B74is+XT5c/anRhTBMRN jIiia8EQJNIgfGRy4IQagdqMDKO6kP0imi+HUwqLgn6DMeFo/WmVphw6R9cOh2TRdBZf +9ctNhPUsPTrl07X+W852YHGUa6J6DOSvmYkjoqOUTG+NH1nrHe6Ya7x2UwUVhJD3dfB FxvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WbMGGw10LyP31iajB+9R7wfeLXFopJMLwGoMOWY66yE=; b=D12AATo7sDVILgbwVCKXjxRQok9XcUpLtlGHVVeMEf2ofbiR8OT+pQAxeA7CBsUaXL BlFt/+pVAAw5v3vmuLP63InXs+ClZMR9MK/RMiemNNxhNBWYvXhgHyEsTGLldho+Q4QI lk7th8mFznk/2T9t2XmyC7QS96C/XwvtaZFIipIrUI9EnMUUpH0TvWmq/m7vK1FJirOR qM8vEMMcVwrtynawjhI2uO3ph1QYBYiFFuYwaqKb3NKEVKOpKmqXSmtPqZwf11QPQ2tS lLubol8OEVhBENGRbinvkpK5aKAoBFuYqlGOQqWwsVjXB7l2+/a0mapG8p9o0zwlSn3j bbgA== X-Gm-Message-State: AG10YORbmKPkbxxXFbCH9ht6LZU/S68cd0O0wPOQHp9yklFPZAt0d7RWgwzWUr0Gd3xqCYBD9QIkOiVZWllqN6UO MIME-Version: 1.0 X-Received: by 10.37.2.23 with SMTP id 23mr4723782ybc.15.1454691344064; Fri, 05 Feb 2016 08:55:44 -0800 (PST) Received: by 10.37.196.68 with HTTP; Fri, 5 Feb 2016 08:55:43 -0800 (PST) In-Reply-To: References: Date: Fri, 5 Feb 2016 08:55:43 -0800 Message-ID: From: Benjamin Bangert To: Brian Raymor Content-Type: multipart/alternative; boundary=001a113d44d4d25f5e052b08b8cb Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Require the TTL header 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, 05 Feb 2016 16:55:48 -0000 --001a113d44d4d25f5e052b08b8cb Content-Type: text/plain; charset=UTF-8 On Thu, Feb 4, 2016 at 9:42 PM, Brian Raymor wrote: > > > Can we require a TTL value for web-push notifications? > > I'd support this requirement if it helps to enforce correct behavior in > implementations. > > > Regarding the resource creation, the spec does not clearly state whether > a Location header should be returned for a TTL of 0 > > since its intended that the message is only delivered to an online user. > If so, it would be useful to mention. > > RFC7231 states: > > http://tools.ietf.org/html/rfc7231#section-4.3.3 > > If one or more resources has been created on the origin server as a > result of successfully processing a POST request, the origin server > SHOULD send a 201 (Created) response containing a Location header > field that provides an identifier for the primary resource created > (Section 7.1.2) and a representation that describes the status of the > request while referring to the new resource(s). > I took that to mean that no Location is returned if the user is offline since no notification was created. > > If it was a required header, we could return a 401 which would very > quickly alert developers about the problem. > > Did you intend a 400 (Bad Request) rather than a 401 (Unauthorized)? Yes, sorry, a 400 would be returned if it's missing. --001a113d44d4d25f5e052b08b8cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Feb 4, 2016 at 9:42 PM, Brian Raymor <Brian.Raymor@microsoft.= com> wrote:

> Can we require a TTL value for web-push notifications?

I'd support this requirement if it helps to enforce correct beha= vior in implementations.

> Regarding the resource creation, the spec does not clearly state wheth= er a Location header should be returned for a TTL of 0
> since its intended that the message is only delivered to an online use= r. If so, it would be useful to mention.

RFC7231 states:

http://tools.ietf.org/html/rfc7231#section-4.3.3=

=C2=A0 =C2=A0If one or more resources has been created on the origin server= as a
=C2=A0 =C2=A0result of successfully processing a POST request, the origin s= erver
=C2=A0 =C2=A0SHOULD send a 201 (Created) response containing a Location hea= der
=C2=A0 =C2=A0field that provides an identifier for the primary resource cre= ated
=C2=A0 =C2=A0(Section 7.1.2) and a representation that describes the status= of the
=C2=A0 =C2=A0request while referring to the new resource(s).

I took that to mean that no Location is returned if the user is = offline since no notification was created.
=C2=A0
> If it was a required header, we could return a 401 which would very qu= ickly alert developers about the problem.

Did you intend a 400 (Bad Request) rather than a 401 (Unauthorized)?=

Yes, sorry, a 400 would be returned if it's missi= ng.
--001a113d44d4d25f5e052b08b8cb-- From nobody Fri Feb 5 09:09:34 2016 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 ED00C1B3BB2 for ; Fri, 5 Feb 2016 09:09:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NicktbtihcGT for ; Fri, 5 Feb 2016 09:09:29 -0800 (PST) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A15161B3BB1 for ; Fri, 5 Feb 2016 09:09:29 -0800 (PST) Received: by mail-yk0-x22d.google.com with SMTP id u9so62713326ykd.1 for ; Fri, 05 Feb 2016 09:09:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DSqRqvsrIpaLjrM7oprfT6visxierEx4dbNxYTQCXV4=; b=OuhCScgwWx6KBCopT4adobp9rCGOXLvnK/+ZunfFAI9rmwW41HWx7zk1EiDckSD6xj SVonY5C+yKmOyM/2452p7dWRXiu2N7AU+W9AcuEXbufoBESXgONKF5mjvlR1C3ITlt9p gYki1TNZ8B1Hd4YE1rBso7gfkfu2G1Vphjkhzp5z/rNv8cST5Jog2Cg+WNIqnMm6ck9h RQKs2xi9SlGOTdG/05kUoGpdhdiZMekRGfcPWQw4iwtk7i4pOI/HoHUmrp8OLYWSBhsY cy4ijT8L/mkkEdLfrxyUeZFHEhRUpp94LX8z8gZe9FCKbZC7e3YEP20pcy6iJE8+no0A c7Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DSqRqvsrIpaLjrM7oprfT6visxierEx4dbNxYTQCXV4=; b=mXx6CihG0PmpWE9AZG3jEHdD1EF+GrTBfiUc1dMNXC7IYur/84PJ+pf1fnociEzGUR SAuUfosyn8jI3KQgkle3zqFnHXeUWqQ8mEEcRA6dNA1VAClaD+lyrCIeaMCxu0KFLu/y Wj2rXJgK5u/oN76h9D6udM8xcxLK62OWUn0pmHK+RC4oLaIFDUXfibqmVkZSYqw5YO8b UWlzz7mjlpW/zITaYwXEzfTO2cjX9l2r/a2HSJs3wLtd4Oxy5tQgmF1mGqtY24ZjSzf7 /mSnD2biJ5vaAj2iBcWuesGKca43leEsLw761bgT+RooXdZC7zcS7fZ5/4jKLaEsxha+ pmPg== X-Gm-Message-State: AG10YOR4CCANlNKH7WPZ/GZRnrTGI2hDrNxds4a//Vo2ssSvoLbqwyY7rqc652s8BLEHsN6FfREKn7FXEGWJJlaf MIME-Version: 1.0 X-Received: by 10.37.95.84 with SMTP id t81mr7731513ybb.58.1454692168652; Fri, 05 Feb 2016 09:09:28 -0800 (PST) Received: by 10.37.196.68 with HTTP; Fri, 5 Feb 2016 09:09:28 -0800 (PST) In-Reply-To: References: Date: Fri, 5 Feb 2016 09:09:28 -0800 Message-ID: From: Benjamin Bangert To: Brian Raymor Content-Type: multipart/alternative; boundary=001a11427594f8a0ea052b08e97f Archived-At: Cc: "Martin Thomson \(martin.thomson@gmail.com\)" , "webpush@ietf.org" Subject: Re: [Webpush] Require the TTL header 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, 05 Feb 2016 17:09:33 -0000 --001a11427594f8a0ea052b08e97f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Feb 5, 2016 at 8:29 AM, Brian Raymor wrote: > > > If you don=E2=80=99t create a push message resource, how do you handle al= l the > related dependencies? > > > > For example, Receiving Push Messages: > > > > https://tools.ietf.org/html/draft-ietf-webpush-protocol-03#section-7 > > > > Each push message is pushed as the response to a synthesized GET > > request in a PUSH_PROMISE. This GET request is made to the push > > message resource that was created by the push service when the > > application server requested message delivery. > In our system we determine if the user agent is available as we process the notification from the application server and attempt delivery immediately if so. > and in Acknowledging Push Messages: > > > > https://tools.ietf.org/html/draft-ietf-webpush-protocol-03#section-7.2 > > > > To ensure that a push message is properly delivered to the user agent > > at least once, the user agent MUST acknowledge receipt of the message > > by performing a HTTP DELETE on the push message resource. > > > > There is also a caveat in the TTL section that the push message resource > may be deleted before the acknowledgement: > > > > https://tools.ietf.org/html/draft-ietf-webpush-protocol-03#section-6.2 > > > > A Push message with a zero TTL is immediately delivered > > if the user agent is available to receive the message. After > > delivery, the push service is permitted to immediately remove a push > > message with a zero TTL. This might occur before the user agent > > acknowledges receipt of the message by performing a HTTP DELETE on > > the push message resource. Consequently, an application server > > cannot rely on receiving acknowledgement receipts for zero TTL push > > messages. > It looks like our current choice of not returning a Location if the user is offline is not to spec, since returning a 201 implies it must contain a Location header. We will be changing this to a 400 for a Bad Request if the TTL header is missing in the future, and always include the Location field for TTL: 0 messages. Cheers, Ben --001a11427594f8a0ea052b08e97f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Feb 5, 2016 at 8:29 AM, Brian Raymor <Brian.Raymor@microsoft.= com> wrote:

=C2=A0

If you don=E2=80=99t create a push me= ssage resource, how do you handle all the related dependencies?

=C2=A0

For example, Receiving Push Messages:

=C2=A0

https://tools.ietf.org/html/draft-ietf-webpush-p= rotocol-03#section-7

=C2=A0

=C2=A0=C2=A0 Each push message is pushed as the response to a synthesize= d GET

=C2=A0=C2=A0 request in a PUSH_PROMISE.=C2=A0 This GET request is made t= o the push

=C2=A0=C2=A0 message resource that was created by the push service when = the

=C2=A0=C2=A0 application server requested message delivery.


In our system we determine if the user = agent is available as we process the notification from the application serv= er and attempt delivery immediately if so.
=C2=A0
<= p>

=C2=A0and in Acknowledging Push Messages:

=C2=A0

https://tools.ietf.org/html/draft-ietf-webpush= -protocol-03#section-7.2

=C2=A0

=C2=A0=C2=A0 To ensure that a push message is properly delivered to the = user agent

=C2=A0=C2=A0 at least once, the user agent MUST acknowledge receipt of t= he message

=C2=A0=C2=A0 by performing a HTTP DELETE on the push message resource.

=C2=A0

There is also a caveat in the TTL section that the push message resource= may be deleted before the acknowledgement:

=C2=A0

https://tools.ietf.org/html/draft-ietf-webpush= -protocol-03#section-6.2

=C2=A0

=C2=A0=C2=A0 A Push message with a zero TTL is immediately delivered<= /u>

=C2=A0=C2=A0 if the user agent is available to receive the message.=C2= =A0 After

=C2=A0=C2=A0 delivery, the push service is permitted to immediately remo= ve a push

=C2=A0=C2=A0 message with a zero TTL.=C2=A0 This might occur before the = user agent

=C2=A0=C2=A0 acknowledges receipt of the message by performing a HTTP DE= LETE on

=C2=A0=C2=A0 the push message resource.=C2=A0 Consequently, an applicati= on server

=C2=A0=C2=A0 cannot rely on receiving acknowledgement receipts for zero = TTL push

=C2=A0=C2=A0 messages.


= =C2=A0It looks like our current choice of not returning a Location if the u= ser is offline is not to spec, since returning a 201 implies it must contai= n a Location header. We will be changing this to a 400 for a Bad Request if= the TTL header is missing in the future, and always include the Location f= ield for TTL: 0 messages.

Cheers,
Ben
--001a11427594f8a0ea052b08e97f-- From nobody Sat Feb 6 12:47:41 2016 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 4FDB01B337D for ; Sat, 6 Feb 2016 12:47:39 -0800 (PST) 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 hoa55AXiBeIB for ; Sat, 6 Feb 2016 12:47:36 -0800 (PST) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAA251B337C for ; Sat, 6 Feb 2016 12:47:35 -0800 (PST) Received: by mail-ob0-x235.google.com with SMTP id ba1so116700301obb.3 for ; Sat, 06 Feb 2016 12:47:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mP6nmr4nUFBCud2yjuUASihY6JnSRPnKrRFhjSzAhx4=; b=FmJnFaAoFJJ4M1uvIJC7rVR1tFFIfpHjrvqoBJO8bJm3JUSEmMg7xaviGx2NNnoJf+ 5ow2WmdqgJM2jS9+Pj5q3+5y+UV+F8MBVIxxawFWgcnMRgo2uFF0GMsMECKMuqsTqw3v AdZq3DKi4/Pow471YcRHRatTh8C9dQRhSjKR2f8e9+jurzQEtwDRYSwKD7OE3uRT7AK3 KpTkyImJRNPpZJH2rzb0MhtQZu6DfEivx64omyWmBPsqraxi1B9g4Rrs5j0RhqBppxjR nOYi5Duet45+vpiA95926HS8LfshG8Gm/dSizQEYxtZ0lEKEprzlbYWOz4uY61RvRTbu VRUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mP6nmr4nUFBCud2yjuUASihY6JnSRPnKrRFhjSzAhx4=; b=h3wVDJCgBs+aNxwhHRwee/z66L1wlap28VjCOJFPl4CtlHK3jj0m9YSL21DVtOv4EF hErHbpsRCCRaLhf59L5FTfwMZfZvVmBOdrdBKSwL67MgdN2I9hssQ0p7pDEqkspwNQAe jQBU7Nmsjr3WtEp/XUIakLsDu9ZXkJ80g2acK/KBtAt6IvuwfG+9/qotq1CsRgE4jcNs DDIDKFOEj5NbLSTa/eiPuEbZtTnh3vQUbXaNJPx6CLMPuCWKKuTiydkWTxN28CFgB7iQ 1LvnrRCpgvr9ysSrNWMJ8rsxYt4zUbajkRTQOYZprceY0IToKIBTvWxsnFDVhKm5AVb2 Oc1Q== X-Gm-Message-State: AG10YOR2ZvLQ2UQAl322NdRXqgPwa22h8soqrbErHD1oSSDOBd8BbuFd9BAQDQJYmE5ppsm5b5R0jwGp2VFf6w== MIME-Version: 1.0 X-Received: by 10.182.19.164 with SMTP id g4mr18368195obe.15.1454791655364; Sat, 06 Feb 2016 12:47:35 -0800 (PST) Received: by 10.76.8.74 with HTTP; Sat, 6 Feb 2016 12:47:35 -0800 (PST) In-Reply-To: References: Date: Sat, 6 Feb 2016 12:47:35 -0800 Message-ID: From: Costin Manolache To: Benjamin Bangert Content-Type: multipart/alternative; boundary=001a11c2a5f6d72115052b2013b7 Archived-At: Cc: Brian Raymor , "Martin Thomson \(martin.thomson@gmail.com\)" , "webpush@ietf.org" Subject: Re: [Webpush] Require the TTL header 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, 06 Feb 2016 20:47:39 -0000 --001a11c2a5f6d72115052b2013b7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 on requiring ttl, and returning a Location even for TTL=3D0 However receipt behavior is a bit tricky. The service may 'delete immediately' ( which is the same with not storing it in the first place ), but the delivery receipts should still be returned when the device acks. The push service may believe the device is connected, and call send - but in many cases send will succeed even if the other end is gone - TCP will do its retry and eventually will timeout and close the connection, but it takes some time and it's well after send. I assume 202 (Accepted) would be better for TTL=3D0 if the service is not actually storing the message. GCM ( and I assume other services ) may also optimize small TTLs by not persisting - so it may make sense to indicate this with 202, and not require in the spec that the service is persisting all messages. Finally, it is very impractical for us to determine if the user agent is available at the time of the send (replication and cross-DC latency, plus the TCP retries) Costin On Fri, Feb 5, 2016 at 9:09 AM, Benjamin Bangert wrote: > On Fri, Feb 5, 2016 at 8:29 AM, Brian Raymor > wrote: > >> >> >> If you don=E2=80=99t create a push message resource, how do you handle a= ll the >> related dependencies? >> >> >> >> For example, Receiving Push Messages: >> >> >> >> https://tools.ietf.org/html/draft-ietf-webpush-protocol-03#section-7 >> >> >> >> Each push message is pushed as the response to a synthesized GET >> >> request in a PUSH_PROMISE. This GET request is made to the push >> >> message resource that was created by the push service when the >> >> application server requested message delivery. >> > > In our system we determine if the user agent is available as we process > the notification from the application server and attempt delivery > immediately if so. > > >> and in Acknowledging Push Messages: >> >> >> >> https://tools.ietf.org/html/draft-ietf-webpush-protocol-03#section-7.2 >> >> >> >> To ensure that a push message is properly delivered to the user agent >> >> at least once, the user agent MUST acknowledge receipt of the message >> >> by performing a HTTP DELETE on the push message resource. >> >> >> >> There is also a caveat in the TTL section that the push message resource >> may be deleted before the acknowledgement: >> >> >> >> https://tools.ietf.org/html/draft-ietf-webpush-protocol-03#section-6.2 >> >> >> >> A Push message with a zero TTL is immediately delivered >> >> if the user agent is available to receive the message. After >> >> delivery, the push service is permitted to immediately remove a push >> >> message with a zero TTL. This might occur before the user agent >> >> acknowledges receipt of the message by performing a HTTP DELETE on >> >> the push message resource. Consequently, an application server >> >> cannot rely on receiving acknowledgement receipts for zero TTL push >> >> messages. >> > > It looks like our current choice of not returning a Location if the user > is offline is not to spec, since returning a 201 implies it must contain = a > Location header. We will be changing this to a 400 for a Bad Request if t= he > TTL header is missing in the future, and always include the Location fiel= d > for TTL: 0 messages. > > Cheers, > Ben > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > > --001a11c2a5f6d72115052b2013b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 on requiring ttl, and returning a Location even for TTL= =3D0

However receipt behavior is a bit tricky. The servi= ce may 'delete immediately' ( which is the same with=C2=A0
not storing it in the first place ), but the delivery receipts should sti= ll be returned when the device
acks.=C2=A0

The push service may believe the device is connected, and call send - bu= t in many cases send
will succeed even if the other end is gone -= TCP will do its retry and eventually will timeout and
close the = connection, but it takes some time and it's well after send.
=
I assume 202 (Accepted) would be better for TTL=3D0 if the s= ervice is not actually storing the message.

GCM ( = and I assume other services ) may also optimize small TTLs by not persistin= g - so=C2=A0
it may make sense to indicate this with 202, and not= require in the spec that the service is persisting
all messages.= =C2=A0

Finally, it is very impractical for us to d= etermine if the user agent is available at the time of the send
(= replication and cross-DC latency, plus the TCP retries)

Costin=C2=A0



On Fri, Feb 5, 2016 at 9:09 AM, = Benjamin Bangert <bbangert@mozilla.com> wrote:
On Fri, Feb 5, 2016 at 8:29 AM, Brian Raymor <Brian.Raymor@microsoft.com> wrote:

=C2=A0

If you don=E2=80=99t create a push me= ssage resource, how do you handle all the related dependencies?

=C2=A0

For example, Receiving Push Messages:

=C2=A0

https://tools.ietf.org/html/draft-ietf-webpush-p= rotocol-03#section-7

=C2=A0

=C2=A0=C2=A0 Each push message is pushed as the response to a synthesize= d GET

=C2=A0=C2=A0 request in a PUSH_PROMISE.=C2=A0 This GET request is made t= o the push

=C2=A0=C2=A0 message resource that was created by the push service when = the

=C2=A0=C2=A0 application server requested message delivery.


In our system we determine if the user = agent is available as we process the notification from the application serv= er and attempt delivery immediately if so.
=C2=A0
<= p>

=C2=A0and in Acknowledging Push Messages:

=C2=A0

https://tools.ietf.org/html/draft-ietf-webpush= -protocol-03#section-7.2

=C2=A0

=C2=A0=C2=A0 To ensure that a push message is properly delivered to the = user agent

=C2=A0=C2=A0 at least once, the user agent MUST acknowledge receipt of t= he message

=C2=A0=C2=A0 by performing a HTTP DELETE on the push message resource.

=C2=A0

There is also a caveat in the TTL section that the push message resource= may be deleted before the acknowledgement:

=C2=A0

https://tools.ietf.org/html/draft-ietf-webpush= -protocol-03#section-6.2

=C2=A0

=C2=A0=C2=A0 A Push message with a zero TTL is immediately delivered<= /u>

=C2=A0=C2=A0 if the user agent is available to receive the message.=C2= =A0 After

=C2=A0=C2=A0 delivery, the push service is permitted to immediately remo= ve a push

=C2=A0=C2=A0 message with a zero TTL.=C2=A0 This might occur before the = user agent

=C2=A0=C2=A0 acknowledges receipt of the message by performing a HTTP DE= LETE on

=C2=A0=C2=A0 the push message resource.=C2=A0 Consequently, an applicati= on server

=C2=A0=C2=A0 cannot rely on receiving acknowledgement receipts for zero = TTL push

=C2=A0=C2=A0 messages.


= =C2=A0It looks like our current choice of not returning a Location if the u= ser is offline is not to spec, since returning a 201 implies it must contai= n a Location header. We will be changing this to a 400 for a Bad Request if= the TTL header is missing in the future, and always include the Location f= ield for TTL: 0 messages.

Cheers,
Ben

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


--001a11c2a5f6d72115052b2013b7-- From nobody Sat Feb 6 13:40:26 2016 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 E62471B33FC for ; Sat, 6 Feb 2016 13:40:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImFH4LY7BdKV for ; Sat, 6 Feb 2016 13:40:22 -0800 (PST) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAAFA1B33FB for ; Sat, 6 Feb 2016 13:40:21 -0800 (PST) Received: by mail-yk0-x233.google.com with SMTP id u9so74005891ykd.1 for ; Sat, 06 Feb 2016 13:40:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NeeY3pFoyAxrxkxOf8twd75quUR1SDUoswhfcg5i3c0=; b=jY8RRlcRyX3td6YNLmIvx7HsCTD75QvnroFAXrPY22dWuxu4pXPkK7SGQtAfwUnrWk oz+mJW+zhIU97X7D7K1/1YzFyPPvytd0lMuLRMi59tuddNyP1fZZlCMkDTWZGeDDLQMY r+9Gjcqf0F7uqhrxuTzWt2jyioXVQPT2CARIG1ESP8j6pjixryco0AIEFA08hs5JX0kd 7etRmz8ZKC2x0mzOmV1AxrKZ+XXcx16BpLxL3F67/5XaHKVsB4rIgERsX6pZKbSkvkGn wHCOt6dajPSc7rAGVbKDZpM1s5xsawB6AYErEoS1i6yQerLIKDc4+3Cbyg9MNqCVxJMX 7aCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NeeY3pFoyAxrxkxOf8twd75quUR1SDUoswhfcg5i3c0=; b=Bs92tX6OiL/lgdyI3d/+rtx6RkrwpbaIPrwM5/7nEVj1j6d4pAC1nxAH25qR3BjIBL TDZU74bfFPtSpaluYSgDU2AP5AWetaJ+ubKiT74NKMIhNwuxr+YgI5QS8FLzpF0nd7WI FJ7XmlYP6tsdO/8Nvomh/986KDYyDdjzm4YUC/E4Cet512T+U/V2MQ5i/QejqBzVLMpA k4HE8U1EW7uZPI6tFNZMjGgoQqoqOB4WnBb2xRL84TRfOKHZ0ApFHT03c062+NvNpWbd cUCJDYtXtDZvJ8V866TSTHnMIvZey3h1tPyS+FjjJjdcdwrQlk3Q/ai/eHnWluhruMqT UyKA== X-Gm-Message-State: AG10YOR1be4m2DDlzSY1wHs08+j9XYc4dQW0dOYvcL/HBQwb5GeJyFCEOBdeG1YCsLBDj7Ot0iS1P7cnKIKU9kwJ MIME-Version: 1.0 X-Received: by 10.37.95.84 with SMTP id t81mr11034681ybb.58.1454794820891; Sat, 06 Feb 2016 13:40:20 -0800 (PST) Received: by 10.37.196.68 with HTTP; Sat, 6 Feb 2016 13:40:20 -0800 (PST) In-Reply-To: References: Date: Sat, 6 Feb 2016 13:40:20 -0800 Message-ID: From: Benjamin Bangert To: Costin Manolache Content-Type: multipart/alternative; boundary=001a114275948573e7052b20d0ed Archived-At: Cc: Brian Raymor , "Martin Thomson \(martin.thomson@gmail.com\)" , "webpush@ietf.org" Subject: Re: [Webpush] Require the TTL header 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, 06 Feb 2016 21:40:25 -0000 --001a114275948573e7052b20d0ed Content-Type: text/plain; charset=UTF-8 On Sat, Feb 6, 2016 at 12:47 PM, Costin Manolache wrote: > +1 on requiring ttl, and returning a Location even for TTL=0 > I realized on more careful reading that to return a 201, a Location must accompany it, so our implementation was wrong in this regard. However receipt behavior is a bit tricky. The service may 'delete > immediately' ( which is the same with > not storing it in the first place ), but the delivery receipts should > still be returned when the device > acks. > > The push service may believe the device is connected, and call send - but > in many cases send > will succeed even if the other end is gone - TCP will do its retry and > eventually will timeout and > close the connection, but it takes some time and it's well after send. > > I assume 202 (Accepted) would be better for TTL=0 if the service is not > actually storing the message. > I'd be in favor of that, not sure if there's any relevant privacy implications from immediately indicating that a user is offline. And as you note, it still leaves open the possibility of returning a 201 with the belief the client is connected before it times out on the TCP retries. So all the 202 indicates in this regard is that the client is definitely not connected, nor has been recently enough for a stale connection to be present. > GCM ( and I assume other services ) may also optimize small TTLs by not > persisting - so > it may make sense to indicate this with 202, and not require in the spec > that the service is persisting > all messages. > Yep, we don't store TTL=0 messages at all. > Finally, it is very impractical for us to determine if the user agent is > available at the time of the send > (replication and cross-DC latency, plus the TCP retries) > > Costin > Cheers, Ben --001a114275948573e7052b20d0ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Feb 6, 2016 at 12:47 PM, Costin Manolache <costin@= gmail.com> wrote:
+1 on requiri= ng ttl, and returning a Location even for TTL=3D0
I realized on more careful reading that to return a 201, a Loc= ation must accompany it, so our implementation was wrong in this regard.
However rec= eipt behavior is a bit tricky. The service may 'delete immediately'= ( which is the same with=C2=A0
not storing it in the first place= ), but the delivery receipts should still be returned when the device
acks.=C2=A0

The push service may believe the= device is connected, and call send - but in many cases send
will= succeed even if the other end is gone - TCP will do its retry and eventual= ly will timeout and
close the connection, but it takes some time = and it's well after send.

I assume 202 (Accept= ed) would be better for TTL=3D0 if the service is not actually storing the = message.

I'd be in favor of= that, not sure if there's any relevant privacy implications from immed= iately indicating that a user is offline. And as you note, it still leaves = open the possibility of returning a 201 with the belief the client is conne= cted before it times out on the TCP retries. So all the 202 indicates in th= is regard is that the client is definitely not connected, nor has been rece= ntly enough for a stale connection to be present.
=C2=A0
GCM ( and I assume other ser= vices ) may also optimize small TTLs by not persisting - so=C2=A0
it may make sense to indicate this with 202, and not require in the spec t= hat the service is persisting
all messages.=C2=A0

Yep, we don't store TTL=3D0 messages at al= l.
=C2=A0
= Finally, it is very impractical for us to determine if the user agent is av= ailable at the time of the send
(replication and cross-DC latency= , plus the TCP retries)

Costin=C2=A0

Cheers,
Ben
--001a114275948573e7052b20d0ed-- From nobody Sat Feb 6 14:04:08 2016 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 A895B1B3439 for ; Sat, 6 Feb 2016 14:04:07 -0800 (PST) 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 NlvEG498FbnD for ; Sat, 6 Feb 2016 14:04:05 -0800 (PST) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68D9D1B3437 for ; Sat, 6 Feb 2016 14:04:05 -0800 (PST) Received: by mail-ob0-x230.google.com with SMTP id is5so116429556obc.0 for ; Sat, 06 Feb 2016 14:04:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3ncMxXWBPJTn9J+4CPVd3Qq86fewXfXXyV/TZL8bYNQ=; b=dfZNME72xOUACgRzmzpQ32vHFE5Olqo+yzOuRe1lzrlHU8b4ZxMwXo8J9JJacgt4yn Bmt9A6U5boQ3OIs48n7wNy8QjaVOtmen4e51ppxbX00brmxp++PjEg6eEceDyWQUKyIQ 22dvXeInYXBSsKnpmjnzMO20RWY5J/uTpt8mIUxhvuAAJ7ydCRdZIIQyh75+IQW38boI jvzYUIZCZ7RZ+ABu7olwBqj7JFiaKmzKHWvfnBiqGzEVwHiu3XC7Bx6+YjiFmUvbZLdy 8ysDLU0MrqcJB5EpFRV8A+6KycZu50X+AKIN2UKucbocVvQ8HzVtN5bASqLS+f9AJTS1 0qog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3ncMxXWBPJTn9J+4CPVd3Qq86fewXfXXyV/TZL8bYNQ=; b=i2CrtT4o9nYlP5N/In3OLG8RMcY8/cA55ySYF6WhoYYlCzXfHJfp6KDkP/zSJqXjRG MJZCSEvpcrC8VqgWQj6BoLHBTcCqO6boGdCwpU9inyo1hpvvblgWAMCDcXqFgSWU2g4K VQzgtGnMJsZCkCpKH4jpzLarrqJyC32w4IuQv89Z7nroljYsVyAXxtPXPPdpRhtRvJrc pFG1tSlrhO1WU+Vr8FQoMNK/4hpSWW9K3olDyheOs4VENs1onUkULRPeQM9S09GmzYqO dLUs/yhQ5jhpDhr2UG7qDGZLp4XaxzaKoZcX02MDBtew35U93U4XRwCst27N8Ce5D/T3 H+AA== X-Gm-Message-State: AG10YOSBccWu/VVsboI5JW0o8etA3h29jhcOzetSAcCOjUEXcEkLZfUUrXyzsWMdsyg1sHC6ywVonJFL82prhQ== MIME-Version: 1.0 X-Received: by 10.60.47.195 with SMTP id f3mr18205494oen.1.1454796244812; Sat, 06 Feb 2016 14:04:04 -0800 (PST) Received: by 10.76.8.74 with HTTP; Sat, 6 Feb 2016 14:04:04 -0800 (PST) In-Reply-To: References: Date: Sat, 6 Feb 2016 14:04:04 -0800 Message-ID: From: Costin Manolache To: Benjamin Bangert Content-Type: multipart/alternative; boundary=001a11c3029e648e3a052b2125fe Archived-At: Cc: Brian Raymor , "Martin Thomson \(martin.thomson@gmail.com\)" , "webpush@ietf.org" Subject: Re: [Webpush] Require the TTL header 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, 06 Feb 2016 22:04:07 -0000 --001a11c3029e648e3a052b2125fe Content-Type: text/plain; charset=UTF-8 On Sat, Feb 6, 2016 at 1:40 PM, Benjamin Bangert wrote: > On Sat, Feb 6, 2016 at 12:47 PM, Costin Manolache > wrote: > >> +1 on requiring ttl, and returning a Location even for TTL=0 >> > > I realized on more careful reading that to return a 201, a Location must > accompany it, so our implementation was wrong in this regard. > > However receipt behavior is a bit tricky. The service may 'delete >> immediately' ( which is the same with >> not storing it in the first place ), but the delivery receipts should >> still be returned when the device >> acks. >> >> The push service may believe the device is connected, and call send - but >> in many cases send >> will succeed even if the other end is gone - TCP will do its retry and >> eventually will timeout and >> close the connection, but it takes some time and it's well after send. >> >> I assume 202 (Accepted) would be better for TTL=0 if the service is not >> actually storing the message. >> > > I'd be in favor of that, not sure if there's any relevant privacy > implications from immediately indicating that a user is offline. And as you > note, it still leaves open the possibility of returning a 201 with the > belief the client is connected before it times out on the TCP retries. So > all the 202 indicates in this regard is that the client is definitely not > connected, nor has been recently enough for a stale connection to be > present. > What I meant is: if TTL=0, don't store the message, and return 202 (Accepted) regardless of user status, since no resource is actually created. However in order to return a delivery receipt, it needs to have an identifier. Regarding privacy implication - the delivery receipt has the same characteristics, if you send a message and later get a delivery receipt, it implies the user recently connected, and you can estimate how long he was offline. It's not very precise - at least GCM batches and may delay receipts, I don't think the draft requires immediate delivery of a receipt. In either case - a very useful feature would be to reject a message if user has not been connected for a 'long' time - I think this is covered implicitly by the expiration of the subscription. > > >> GCM ( and I assume other services ) may also optimize small TTLs by not >> persisting - so >> it may make sense to indicate this with 202, and not require in the spec >> that the service is persisting >> all messages. >> > > Yep, we don't store TTL=0 messages at all. > I suspect nobody will, one of the benefits of TTL=0 is that it's likely to be cheaper and faster in most implementations. Costin > > >> Finally, it is very impractical for us to determine if the user agent is >> available at the time of the send >> (replication and cross-DC latency, plus the TCP retries) >> >> Costin >> > > Cheers, > Ben > --001a11c3029e648e3a052b2125fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Feb 6, 2016 at 1:40 PM, Benjamin Bangert <= bbangert@mozilla.= com> wrote:
On Sat, Feb 6, 2016 at 12:47 PM, Costin Manolache <costi= n@gmail.com> wrote:
+1 on requiring ttl, and returning a Location even for TTL=3D0=

I realized on more careful re= ading that to return a 201, a Location must accompany it, so our implementa= tion was wrong in this regard.

However receipt behavior is a bit tr= icky. The service may 'delete immediately' ( which is the same with= =C2=A0
not storing it in the first place ), but the delivery rece= ipts should still be returned when the device
acks.=C2=A0

The push service may believe the device is connected, and= call send - but in many cases send
will succeed even if the othe= r end is gone - TCP will do its retry and eventually will timeout and
=
close the connection, but it takes some time and it's well after s= end.

I assume 202 (Accepted) would be better for T= TL=3D0 if the service is not actually storing the message.

I'd be in favor of that, not sure if= there's any relevant privacy implications from immediately indicating = that a user is offline. And as you note, it still leaves open the possibili= ty of returning a 201 with the belief the client is connected before it tim= es out on the TCP retries. So all the 202 indicates in this regard is that = the client is definitely not connected, nor has been recently enough for a = stale connection to be present.

What I meant is: if TTL=3D0, don't store the message, = and return 202 (Accepted) regardless of user status, since=C2=A0
= no resource is actually created. However in order to return a delivery rece= ipt, it needs to have an identifier.

Regarding pri= vacy implication - the delivery receipt has the same characteristics, if yo= u send a message and later
get a delivery receipt, it implies the= user recently connected, and you can estimate how long he was offline.=C2= =A0
It's not very precise - at least GCM batches and may dela= y receipts, I don't think the draft requires immediate
delive= ry of a receipt.=C2=A0

In either case - a very use= ful feature would be to reject a message if user has not been connected for= a 'long' time -
I think this is covered implicitly by th= e expiration of the subscription.=C2=A0

=C2=A0
=C2=A0
GCM ( and I assume other servi= ces ) may also optimize small TTLs by not persisting - so=C2=A0
i= t may make sense to indicate this with 202, and not require in the spec tha= t the service is persisting
all messages.=C2=A0

Yep, we don't store TTL=3D0 messages = at all.

I suspe= ct nobody will, one of the benefits of TTL=3D0 is that it's likely to b= e cheaper and faster in most
implementations.

Costin
=C2=A0
=C2=A0<= br>
<= div>Finally, it is very impractical for us to determine if the user agent i= s available at the time of the send
(replication and cross-DC lat= ency, plus the TCP retries)

Costin=C2=A0

<= /span>
Cheers,
Ben

--001a11c3029e648e3a052b2125fe-- From nobody Sun Feb 7 16:41:51 2016 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 14CE51A870F for ; Sun, 7 Feb 2016 16:41:50 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001] 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 hDJuWUYX9vB2 for ; Sun, 7 Feb 2016 16:41:46 -0800 (PST) Received: from gateway32.websitewelcome.com (gateway32.websitewelcome.com [192.185.145.18]) (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 CD9C31A8712 for ; Sun, 7 Feb 2016 16:41:46 -0800 (PST) Received: from cm1.websitewelcome.com (cm.websitewelcome.com [192.185.0.102]) by gateway32.websitewelcome.com (Postfix) with ESMTP id 3B77CFC544B5B for ; Sun, 7 Feb 2016 18:41:46 -0600 (CST) Received: from gator4135.hostgator.com ([192.185.4.147]) by cm1.websitewelcome.com with id Fchk1s00K3AKFgo01chlgN; Sun, 07 Feb 2016 18:41:46 -0600 Received: from c-71-202-231-23.hsd1.ca.comcast.net ([71.202.231.23]:42060 helo=[10.0.96.16]) by gator4135.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aSZtg-000SyK-0r; Sun, 07 Feb 2016 18:41:44 -0600 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Shida Schubert In-Reply-To: Date: Sun, 7 Feb 2016 16:41:42 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7E474B21-B040-475E-B684-52894D56FAF0@ntt-at.com> References: To: Martin Thomson X-Mailer: Apple Mail (2.2104) 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: 71.202.231.23 X-Exim-ID: 1aSZtg-000SyK-0r X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: c-71-202-231-23.hsd1.ca.comcast.net ([10.0.96.16]) [71.202.231.23]:42060 X-Source-Auth: shida@agnada.com X-Email-Count: 2 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== Archived-At: Cc: Brian Raymor , "webpush@ietf.org" Subject: Re: [Webpush] Work venue (Re: Niceness or urgency of messages) 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, 08 Feb 2016 00:41:50 -0000 Martin; I understand it is extra burden and work for the contributors that are = moving things forward but I really appreciate keeping the rest of the WG = in the loop. As mentioned, if you don=E2=80=99t want to miss any progress or changes = suggested, I would like to encourage the people to watch the github repo = to be notified of any changes or discussions surrounding the issues.=20 Thanks Shida as co-chair > On Feb 1, 2016, at 3:32 PM, Martin Thomson = wrote: >=20 > On 1 February 2016 at 18:38, Shida Schubert wrote: >> I think for now we need to strike a balance of contributors not = having have >> to waste their energy keeping the WG in loop but making sure some of = the >> critical changes discussed on github is distributed on the ML. >=20 > I think that we've missed that balance recently. I will try to ensure > that I bring any substantive discussion here and limit discussion on > github to editorial matters. >=20 > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush From nobody Wed Feb 10 14:30:12 2016 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 39C201B30D0 for ; Wed, 10 Feb 2016 14:30:11 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 h4Dwgqe6GGE2 for ; Wed, 10 Feb 2016 14:30:07 -0800 (PST) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FC061B30D5 for ; Wed, 10 Feb 2016 14:30:06 -0800 (PST) Received: by mail-pa0-x22c.google.com with SMTP id fl4so6709080pad.0 for ; Wed, 10 Feb 2016 14:30:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=from:subject:to:references:cc:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=ybpeTQsJpsjstnIRzp9XUIdCLCjYiTKG/B7OUzi/AVE=; b=fVrQgbYa9DXovehHe4ox/dlsPY9vcwOHWidtB19a3eyYmaaiZ1Z1pZDvjsWfS6y8qG K2xCZzaltTqx0aAb7B5LD7Lx+282xfP9znFwAlVmD6Gtm0axm5OY9Y3Bdcm7qQG913Ab SqvLI4jn9HJVHYvQPhd95kZXeTRrm3H6nHPD0YwYru2TS8QUMvFLymwViMrn2AjgnA06 9LTncFTiGBa9PrNwbtfAn1WyQEtJdgUoJb/DS/4dAktc2L/tZjjkYR6TGfm6kM7zxUR4 Y7E/8Smn8kWRvZ4pSO3d5Ba72gOAK/bZ41T0h7dOROSNcjK3gI21tW1s9ldip2KJ151c 3yjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:cc:organization :message-id:date:user-agent:mime-version:in-reply-to:content-type; bh=ybpeTQsJpsjstnIRzp9XUIdCLCjYiTKG/B7OUzi/AVE=; b=kgl0hSuSgkpNzpRGTjqf/T9gGSCL7yAsvWfK/x/JhVo23E2GNZcXeEDkZnu1LOhhg1 2S9ARQEtJvaezkiLhQfivr8HRmn7MOdwbEw1Qy6slR07VYTtzUJpyW870PD4fTarrt21 JDFLu7/cq38ZLcNI01RasrLCFPVGEaIOb7JamXVKyI0eoVdRiQDqkiOL4d1DjM2gTAtE apa6QDYoPfU6MgZha/My+TypzDpeL61OTrCXMhQaQD/cyZ1fWZQ5hcSe9titpYbp56xf ea0ovgqCZAhn55A7wzTkWTMzijtKZnaivY3AD00iSgZBIsVqmJzsb9CBIytPNzh7EDRd fuQw== X-Gm-Message-State: AG10YOQVZysI/J+nQzUlVS+XxkB5Z1jQ8hT706BJcXzvzcXAeocT4u4BsHn8p2f6W00ptZZC X-Received: by 10.67.22.166 with SMTP id ht6mr62472099pad.9.1455143406553; Wed, 10 Feb 2016 14:30:06 -0800 (PST) Received: from ?IPv6:2620:101:80fc:224:4953:821e:b31b:6d71? ([2620:101:80fc:224:4953:821e:b31b:6d71]) by smtp.gmail.com with ESMTPSA id wt2sm7413766pac.48.2016.02.10.14.30.05 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 10 Feb 2016 14:30:05 -0800 (PST) From: JR Conlin X-Google-Original-From: JR Conlin To: Costin Manolache , Peter Beverloo References: Organization: mozilla Message-ID: <7f44560b-5b3e-fa6c-47de-b10fd6265379@mozilla.com> Date: Wed, 10 Feb 2016 14:30:04 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:46.0) Gecko/20100101 Thunderbird/46.0a2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5D2F9DDFA5637A02677815FB" Archived-At: Cc: Martin Thomson , "webpush@ietf.org" Subject: Re: [Webpush] Voluntary Application Server Identification -02 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: Wed, 10 Feb 2016 22:30:11 -0000 This is a multi-part message in MIME format. --------------5D2F9DDFA5637A02677815FB Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit While talking with Kit, I'd like to present a set of rules (I was going to call them best practices, but really, that's like saying "Do not lick high voltage lines" is a best practice.) 1) If a site registers a public key as part of a subscription request, that key is used to validate the JWT. Invalid JWTs result in a 401. 2) If a site registers a public key, it should NOT include the public key as part of the Crypto-Key header in the Push request (since this increases the chance that the key is inadvertently disclosed.) I'm not sure how or if we should signal that back to the App Servers. 3) If the Crypto-Key:p256ecdsa == Crypto-Key:p256dh, that will return a 401. (it's just math kids, you can pick different coordinate sets, for free.) Seem reasonable? On 2/1/2016 12:33 PM, Costin Manolache wrote: > +1 > > Costin > > On Mon, Feb 1, 2016 at 10:43 AM, Peter Beverloo > wrote: > > Thank you for publishing the draft, Martin! > > While I'm not sure how much significance it carries since I'm > listed as an editor, I do of course support the draft as the > resolve to Issue 44. > > Server authentication and subscription association are important > problems to us, and, pending any further feedback from the working > group, we plan to adopt the proposed solution in our implementations. > > Thanks, > Peter > > On Mon, Feb 1, 2016 at 1:56 AM, Martin Thomson > > wrote: > > I have just posted a new version of the draft, taking the recent > feedback from discussions into account. > > https://tools.ietf.org/html/draft-thomson-webpush-vapid-02 > > This includes only the JWT option, with a lot more of the details > fleshed out. I've implemented it in order to create the > example, and > that is dead simple to do. > > I think that this is the answer we want for issue 44 [44]. > Does the > group agree? Is this worth adopting? > > [44] https://github.com/webpush-wg/webpush-protocol/issues/44 > > _______________________________________________ > 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 > > > > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush --------------5D2F9DDFA5637A02677815FB Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
While talking with Kit, I'd like to present a set of rules (I was going to call them best practices, but really, that's like saying "Do not lick high voltage lines" is a best practice.)

1) If a site registers a public key as part of a subscription request, that key is used to validate the JWT. Invalid JWTs result in a 401.

2) If a site registers a public key, it should NOT include the public key as part of the Crypto-Key header in the Push request (since this increases the chance that the key is inadvertently disclosed.)
I'm not sure how or if we should signal that back to the App Servers.

3) If the Crypto-Key:p256ecdsa == Crypto-Key:p256dh, that will return a 401. (it's just math kids, you can pick different coordinate sets, for free.)

Seem reasonable?

On 2/1/2016 12:33 PM, Costin Manolache wrote:
+1

Costin

On Mon, Feb 1, 2016 at 10:43 AM, Peter Beverloo <beverloo@google.com> wrote:
Thank you for publishing the draft, Martin!

While I'm not sure how much significance it carries since I'm listed as an editor, I do of course support the draft as the resolve to Issue 44.

Server authentication and subscription association are important problems to us, and, pending any further feedback from the working group, we plan to adopt the proposed solution in our implementations.

Thanks,
Peter

On Mon, Feb 1, 2016 at 1:56 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
I have just posted a new version of the draft, taking the recent
feedback from discussions into account.

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

This includes only the JWT option, with a lot more of the details
fleshed out.  I've implemented it in order to create the example, and
that is dead simple to do.

I think that this is the answer we want for issue 44 [44].  Does the
group agree? Is this worth adopting?

[44] https://github.com/webpush-wg/webpush-protocol/issues/44

_______________________________________________
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




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


--------------5D2F9DDFA5637A02677815FB-- From nobody Wed Feb 10 22:26:07 2016 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 7D12F1A9095 for ; Wed, 10 Feb 2016 22:26:06 -0800 (PST) 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 Q3mKdET9XgSF for ; Wed, 10 Feb 2016 22:26:04 -0800 (PST) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3A881A9075 for ; Wed, 10 Feb 2016 22:26:03 -0800 (PST) Received: by mail-ob0-x230.google.com with SMTP id wb13so61951995obb.1 for ; Wed, 10 Feb 2016 22:26:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BrYYY8P+SoiLTOOgfPaGK4K++lSoRRJprR4RBC8wKZg=; b=sEhLzTNqcjtyyyiSemxFtnACTShz60gWqjvBP2u+uS1dib0GRsmlJe4vTirlD4WCpY VZHeCljEl6GzmkVwoKyKW/pQYJJK542ARl6osa9MCcd1aGoaGcVXzKrZfRTgXvrbHiRz FxaAu2NbPf40IEk4btAKUj6QoexFRcfGNS0X0P7YrqTTfAU5mRPbf8uivfRUT0WFHtlF ZdrLoayYicvdymNIuZ6J/k3X3yvQB2auCPP8p/E01vBVNVyfgu6kPvrJKpAC94In/tCC dpwxH08+FKOAeXMX7hm6nb4hdf91noRY03rw1Osa3zsv0w2tTJG9ijPfAUoi8wQG7AhV R2Ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BrYYY8P+SoiLTOOgfPaGK4K++lSoRRJprR4RBC8wKZg=; b=dNWr6HRsqW8gN3aNJx+bJAxcvzZsFYfkh88jgCzd/XdtB3eXBd6HJBwJiTpQvcteQD 7UQMz5q6qmo20A+AmvxD4KKbXon1ry9aQp3MVTphK+mc82WDTX9Rv5cS44e0PD2NcuPM kBUDN5GBpTv1/Us1q/M8N462lcIDqPOiGhTnIvdgYU1z67Mle/dLyLqnN3i7koPDavT1 SFJZQhbgS8nzQ5tSJz2eMxk0PNqYaHH28IncwykbxHVboFvIq815NzeEFapw4vuwdcJY TjU5QsYgPcBdrRM8FWBs+jzmE221HvQRYElA6V5yRil2rjPmENicrwvYtnxU3CZXgIO/ bnwA== X-Gm-Message-State: AG10YOQhKiQn6/PaMPvZuZME0lMOc7HXn+wPDl2E3nTQ2HpyqxbU14PMRVAWNVOJuZMmk7sMM+/NrFEcnsmLRA== MIME-Version: 1.0 X-Received: by 10.60.47.195 with SMTP id f3mr44465124oen.1.1455171956914; Wed, 10 Feb 2016 22:25:56 -0800 (PST) Received: by 10.76.8.74 with HTTP; Wed, 10 Feb 2016 22:25:56 -0800 (PST) In-Reply-To: <7f44560b-5b3e-fa6c-47de-b10fd6265379@mozilla.com> References: <7f44560b-5b3e-fa6c-47de-b10fd6265379@mozilla.com> Date: Wed, 10 Feb 2016 22:25:56 -0800 Message-ID: From: Costin Manolache To: JR Conlin Content-Type: multipart/alternative; boundary=001a11c3029e944104052b789fda Archived-At: Cc: Martin Thomson , "webpush@ietf.org" , Peter Beverloo Subject: Re: [Webpush] Voluntary Application Server Identification -02 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, 11 Feb 2016 06:26:06 -0000 --001a11c3029e944104052b789fda Content-Type: text/plain; charset=UTF-8 On Wed, Feb 10, 2016 at 2:30 PM, JR Conlin wrote: > While talking with Kit, I'd like to present a set of rules (I was going to > call them best practices, but really, that's like saying "Do not lick high > voltage lines" is a best practice.) > > 1) If a site registers a public key as part of a subscription request, > that key is used to validate the JWT. Invalid JWTs result in a 401. > Not sure I understand - the register() call takes a public key, and the push service needs to verify that the send request includes a JWT token with the same key - is that what you mean ? > > 2) If a site registers a public key, it should NOT include the public key > as part of the Crypto-Key header in the Push request (since this increases > the chance that the key is inadvertently disclosed.) > I'm not sure how or if we should signal that back to the App Servers. > The key used in register() needs to be included in the push request - technically we can work around this, by having the push service store the key - but by having it in the push header it can reduce the storage ( the push service can only store a hash of the key, or can include a hash of the key in the registration token, so no storage - assuming the registration is encrypted/signed). It's a public key - why would it be a problem in disclosing it ? Anyone who cares can get it from the browser making the subscribe request, it's more or less as secure as the public key in the TLS cert. Costin > > 3) If the Crypto-Key:p256ecdsa == Crypto-Key:p256dh, that will return a > 401. (it's just math kids, you can pick different coordinate sets, for > free.) > > Seem reasonable? > > > > On 2/1/2016 12:33 PM, Costin Manolache wrote: > > +1 > > Costin > > On Mon, Feb 1, 2016 at 10:43 AM, Peter Beverloo > wrote: > >> Thank you for publishing the draft, Martin! >> >> While I'm not sure how much significance it carries since I'm listed as >> an editor, I do of course support the draft as the resolve to Issue 44. >> >> Server authentication and subscription association are important problems >> to us, and, pending any further feedback from the working group, we plan to >> adopt the proposed solution in our implementations. >> >> Thanks, >> Peter >> >> On Mon, Feb 1, 2016 at 1:56 AM, Martin Thomson < >> martin.thomson@gmail.com> wrote: >> >>> I have just posted a new version of the draft, taking the recent >>> feedback from discussions into account. >>> >>> https://tools.ietf.org/html/draft-thomson-webpush-vapid-02 >>> >>> This includes only the JWT option, with a lot more of the details >>> fleshed out. I've implemented it in order to create the example, and >>> that is dead simple to do. >>> >>> I think that this is the answer we want for issue 44 [44]. Does the >>> group agree? Is this worth adopting? >>> >>> [44] https://github.com/webpush-wg/webpush-protocol/issues/44 >>> >>> _______________________________________________ >>> 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 >> >> > > > _______________________________________________ > Webpush mailing listWebpush@ietf.orghttps://www.ietf.org/mailman/listinfo/webpush > > > --001a11c3029e944104052b789fda Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Feb 10, 2016 at 2:30 PM, JR Conlin <jconlin@mozilla.com&= gt; wrote:
=20 =20 =20
While talking with Kit, I'd like to present a set of rules (I was going to call them best practices, but really, that's like saying "Do not lick high voltage lin= es" is a best practice.)

1) If a site registers a public key as part of a subscription request, that key is used to validate the JWT. Invalid JWTs result in a 401.


<= div>Not sure I understand - the register() call takes a public key, and the= push service needs to verify that the send request
includes a JW= T token with the same key - is that what you mean ?=C2=A0

=C2=A0

2) If a site registers a public key, it should NOT include the public key as part of the Crypto-Key header in the Push request (since this increases the chance that the key is inadvertently disclosed.)
I'm not sure how or if we should signal that back to the App Servers.

The key used= in register() needs to be included in the push request - technically we ca= n work around this, by having the=C2=A0
push service store the ke= y - but by having it in the push header it can reduce the storage ( the pus= h service can=C2=A0
only store a hash of the key, or can include = a hash of the key in the registration token, so no storage - assuming the r= egistration is encrypted/signed).

It's a publi= c key - why would it be a problem in disclosing it ? Anyone who cares can g= et it from the browser making=C2=A0
the subscribe request, it'= ;s more or less as secure as the public key in the TLS cert.=C2=A0

Costin
=C2=A0

3) If the Crypto-Key:p256ecdsa =3D=3D Crypto-Key:p256dh, that will return a 401. (it's just math kids, you can pick different coordinate sets, for free.)

Seem reasonable?


=C2=A0


On 2/1/2016 12:33 PM, Costin Manolache wrote:
+1

Costin

On Mon, Feb 1, 2016 at 10:43 AM, Peter Beverloo <beverloo@google.com> wrote:
Thank you for publishing the draft, Martin!

While I'm not sure how much significance it carries since I'm listed as an editor, I do of course support the draft as the resolve to Issue 44.

Server authentication and subscription association are important problems to us, and, pending any further feedback from the working group, we plan to adopt the proposed solution in our implementations.

Thanks,
Peter

On Mon, Feb 1, 2016 at 1:56 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
I have just posted a new version of the draft, taking the recent
feedback from discussions into account.

https://tools.ietf.o= rg/html/draft-thomson-webpush-vapid-02

This includes only the JWT option, with a lot more of the details
fleshed out.=C2=A0 I've implemented it in order t= o create the example, and
that is dead simple to do.

I think that this is the answer we want for issue 44 [44].=C2=A0 Does the
group agree? Is this worth adopting?

[44] https://github.co= m/webpush-wg/webpush-protocol/issues/44

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


_______________________________________________
Webpush mailing list
Webpush@i= etf.org
https://www.ietf.org/mailman/listinfo/web= push




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



--001a11c3029e944104052b789fda-- From nobody Thu Feb 11 02:41:40 2016 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 BFF191ACEC9 for ; Thu, 11 Feb 2016 02:41:38 -0800 (PST) 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 OPmZwzjMl7cY for ; Thu, 11 Feb 2016 02:41:37 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2860C1ACEAD for ; Thu, 11 Feb 2016 02:41:37 -0800 (PST) Received: by mail-ig0-x234.google.com with SMTP id xg9so32312107igb.1 for ; Thu, 11 Feb 2016 02:41:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OHfELDsm2WQ26gJbr0twep09vjjjSe5Zs2R/8h2P5/M=; b=vL6Gm843HxV3T1XaHpTHaCLbvyhxMrV57S3e2L/gLZLHH6+SNHrJZ3QNvPzKFNGW3J 8+/4wYBCyStJKc1GnV5+CL35A+mGz3MOMusbIQ4U63EmawYBkBlY8gxOw5tWU7nidfaO YzEcEOEb1/LGH9HQ9JhHPrCR9RHm30tsU5/rRPIWI/HWgRyDB0EmR8kXmjIr8+DwY8Z2 hbzFuMARGmcOeaVP5WWGQBbwE3NnLatiAij+p7t7IbSfi9XTu+5UYhd7iG41h09LxKDg 10h73cj+SIGM64w0OUrWLYvKZKhON/B73QDZdp5vF+XYCQ3ZQ1OuEX07Jv+xf/HUMpML MwKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OHfELDsm2WQ26gJbr0twep09vjjjSe5Zs2R/8h2P5/M=; b=alqicT8cYNkYswrJKsdyJJIcFKIBuvM5Q8A6Afkem7svhtgSvzSi4mb9ESRwx/ohux nyY48To/mzDxHq6DnmNOUML4e0motLKuhewMshb+WfawB+lOQqrcbxYlATQsm1oM9fyy DdOxasKv7lhIIjTZ26NCOfQ48Kdb4Cw7jsSUh41QOm0Ffp9Lum9lJqIK4pr9dr1KjbrT +sIqEqLMFYZWalD9o+d3U+uQJ+yuR+/txA68ISoiF/OT0MxBiHV2mgZzpLBiLb8ZZyRt AU+P9frg427LwNzhdGIuiR9JqZyA7u6tfZLbpSazVAgHejOm0asdl6oWE8/SOrrjcK7a 7a6A== X-Gm-Message-State: AG10YOQyx58GCUlveDBRy3R5+AWniXJdoY1T5zBsVs1BZAG5Hc5LGI31IPlQXZ/lXJgtMNtLnj+jngrvDRSvSQ== MIME-Version: 1.0 X-Received: by 10.50.20.73 with SMTP id l9mr15833376ige.58.1455187296515; Thu, 11 Feb 2016 02:41:36 -0800 (PST) Received: by 10.36.53.79 with HTTP; Thu, 11 Feb 2016 02:41:36 -0800 (PST) In-Reply-To: References: <7f44560b-5b3e-fa6c-47de-b10fd6265379@mozilla.com> Date: Thu, 11 Feb 2016 21:41:36 +1100 Message-ID: From: Martin Thomson To: Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: JR Conlin , "webpush@ietf.org" , Peter Beverloo Subject: Re: [Webpush] Voluntary Application Server Identification -02 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, 11 Feb 2016 10:41:38 -0000 On 11 February 2016 at 17:25, Costin Manolache wrote: > The key used in register() needs to be included in the push request - > technically we can work around this, by having the > push service store the key - but by having it in the push header it can > reduce the storage ( the push service can > only store a hash of the key, or can include a hash of the key in the > registration token, so no storage - assuming the registration is > encrypted/signed). Yes, I have this in the draft actually: (see the editor's note here: https://martinthomson.github.io/webpush-vapid/#using-restricted-subscriptions) I am absolutely OK with rejecting idiot attempts to use the same EC key for key exchange and signing. That I am happy to put in the draft with a MUST on it. Like Costin, I'm confused about the need to restate the first point. The whole purpose of including a key in the subscription is to limit pushes to application servers that have the corresponding private key. See https://martinthomson.github.io/webpush-vapid/#using-restricted-subscriptions and https://github.com/w3c/push-api/pull/182 From nobody Thu Feb 11 02:49:07 2016 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 7FBEA1ACEE6 for ; Thu, 11 Feb 2016 02:49:06 -0800 (PST) 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 egoR2SiCa90g for ; Thu, 11 Feb 2016 02:49:05 -0800 (PST) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D4201ACED6 for ; Thu, 11 Feb 2016 02:49:05 -0800 (PST) Received: by mail-ig0-x22f.google.com with SMTP id hb3so32487390igb.0 for ; Thu, 11 Feb 2016 02:49:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5phmIPIPE5T2wHWVIYLpyDkFk6AJlE3WY2DG8QQFd9U=; b=QCdzW98Kc6cfx3X6Q4/7QBCPBLCL/DMr2vxh8UTBtI0zshRo6JPM4dHCuPs9SYn+Nz iQtFns9jRA9yImm/RFv1keAG2bnirNqCFzUQ7IGapmYtyCCnNamU593CfwUlAY/r/Q4F d6V2wZ7JjbhZs4oU5h0suGOu4j4q60ZRon2GhYeUjNUex+dAjDZTl70M2ipMfx9K3u3v yyW+0bw8E/DT+MFN4PXzXlTic6EMBO6uiZwx5NhLhcOqUVLsC7l5r857VQKkMw2YesJY u8YXTIOs3D7XPRBT6iUdxau37R+zrSkpkI8xjWYhzblxCFUsumw1lNWBQUTlxFw1R4au ugyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5phmIPIPE5T2wHWVIYLpyDkFk6AJlE3WY2DG8QQFd9U=; b=i2N0sxq9KXBtY09KIgfPf5DRP56wdhay7VJfOvpiAtqYI4akVXJol04QgZhg4eq6x2 k+vodBlXFWKGqoMwJxLLVSSPFme3RSLG3kNXQHQE842OD2esb+lu4sFVjnE5+ay0+4bJ 956nls29iNwew3vV2iBDX7gjJCpVnhQNrgPaxJm3v3x2zyV7jtCoFK+lakPeehmArXHh 2Oe5UsYlEEcipsAchelnItLl1dh+wPq3d1qEQTgZAknjabSgKmit8QpYCmuRhsMymqmA 2pXxHzcWALyiMinDOrSyLCzHNjxw7RdvlPHW+tyZk8yq9ehdIaHoT+fE6+PfjuM4+c6C 4bpw== X-Gm-Message-State: AG10YOTjENT+YDOKurBtryp1bSQ5QSX/aGlwAbZpydL/yhuMyVVp/zOrcp9Bqq5fd0KhURGJMLZ87fx09NmjTQ== MIME-Version: 1.0 X-Received: by 10.50.20.73 with SMTP id l9mr15861477ige.58.1455187744566; Thu, 11 Feb 2016 02:49:04 -0800 (PST) Received: by 10.36.53.79 with HTTP; Thu, 11 Feb 2016 02:49:04 -0800 (PST) In-Reply-To: References: <7f44560b-5b3e-fa6c-47de-b10fd6265379@mozilla.com> Date: Thu, 11 Feb 2016 21:49:04 +1100 Message-ID: From: Martin Thomson To: Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: JR Conlin , "webpush@ietf.org" , Peter Beverloo Subject: Re: [Webpush] Voluntary Application Server Identification -02 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, 11 Feb 2016 10:49:06 -0000 On 11 February 2016 at 21:41, Martin Thomson wrote: > I am absolutely OK with rejecting idiot attempts to use the same EC > key for key exchange and signing. That I am happy to put in the draft > with a MUST on it. And lo, I have created a request to pull thus: https://github.com/martinthomson/webpush-vapid/pull/6 (OK, it's late) From nobody Thu Feb 11 08:52:37 2016 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 E2B321B3465 for ; Thu, 11 Feb 2016 08:52:35 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 HBDhnNgQKm3c for ; Thu, 11 Feb 2016 08:52:32 -0800 (PST) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B9F81B34A9 for ; Thu, 11 Feb 2016 08:52:25 -0800 (PST) Received: by mail-pf0-x230.google.com with SMTP id x65so32102904pfb.1 for ; Thu, 11 Feb 2016 08:52:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=LvSB3bU2mVA+6KwhMANjFOycKc2SuriaKLwMX3yJOds=; b=Dzd1x7LaIO7nGBOf9TPebwl6KUHreCv8SPc+gczfdrnCL1zLiMVwGJFoJpoRcu5GZH OJZBFG728ttcTOfYa62/Y17V8ok7/b5odp6KhRcL5x09PT8qh0AWRcmuo2TheJHZoWvB BbXZ1CwFdk1gyyCtuDrg7RsRn0ISxsiMtEsALoxdHwfwuViW2rWHDKIf/vgdfW+oh3uu Zknz+u9ggZsX8KpPVsWCUwsHO13wBKQeC/U7H8E4pePHRlolAFouh6vs2TneXTmqWBKC AgbQL5+AL23KPIZtNVAFTCwDo4AKW4KyJkoHSsQajAhIHbawlQKA7Nh5+KaAiNfXhUsf B2Fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=LvSB3bU2mVA+6KwhMANjFOycKc2SuriaKLwMX3yJOds=; b=bQZlfXb1xqag1FQ2nfABy1GXpzGx+TBhOB+H1WRt7MTyNwkNczm1DMfMmlfIrJ/JpM whkcJ/jARRL6YK6cKLUYIowMVNSL1+1roCJAw1WySf6yQFyH+HEwoolAKjlMSX4/hZYS PmvpH/737VQy4OhKBL9NZIg3VMRjF99dBVv1TvxLngJ8paTBtzxrZdVNzXjLT0Y+52f+ IT7o9fi5Q+TRgIQsh/3t60uKYi3KrPRzcMZqJo2oeQVGQQ2ztJKYX65xFMHnhvFGr7Kq h+GARBnc0MOlbJR63f4ojwIsaWZP7R0nGTnnJu6R9ZDUnG0GjMR1jsn2yYmKbZlI69kN t+CQ== X-Gm-Message-State: AG10YORKwXrr3BqmfW0PHD7EdGuPlGWhW4LKM05g7uZqQsBGzi3VigcR9RNBwWgFDdPuPhBa X-Received: by 10.98.16.12 with SMTP id y12mr68218765pfi.6.1455209544803; Thu, 11 Feb 2016 08:52:24 -0800 (PST) Received: from ?IPv6:2620:101:80fc:224:851d:643f:3f18:9573? ([2620:101:80fc:224:851d:643f:3f18:9573]) by smtp.gmail.com with ESMTPSA id 195sm13545921pfa.5.2016.02.11.08.52.23 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 11 Feb 2016 08:52:23 -0800 (PST) To: Martin Thomson , Costin Manolache References: <7f44560b-5b3e-fa6c-47de-b10fd6265379@mozilla.com> From: jr conlin Message-ID: Date: Thu, 11 Feb 2016 08:52:23 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:46.0) Gecko/20100101 Thunderbird/46.0a2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "webpush@ietf.org" , Peter Beverloo Subject: Re: [Webpush] Voluntary Application Server Identification -02 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, 11 Feb 2016 16:52:36 -0000 On 2/11/2016 2:41 AM, Martin Thomson wrote: > On 11 February 2016 at 17:25, Costin Manolache wrote: >> The key used in register() needs to be included in the push request - >> technically we can work around this, by having the >> push service store the key - but by having it in the push header it can >> reduce the storage ( the push service can >> only store a hash of the key, or can include a hash of the key in the >> registration token, so no storage - assuming the registration is >> encrypted/signed). > Like Costin, I'm confused about the need to restate the first point. > The whole purpose of including a key in the subscription is to limit > pushes to application servers that have the corresponding private key. > See https://martinthomson.github.io/webpush-vapid/#using-restricted-subscriptions > and https://github.com/w3c/push-api/pull/182 I tend to prefer limiting the amount of data exchange required. Since the Crypto-Key component would match the previously provided register() key, it seemed redundant to provided it on every subsequent call. Having discussed things with Ben and Kit offline, I'm fine with the public key being included in both, in order to make things easier for the Application server creators. From nobody Tue Feb 16 14:45:14 2016 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 4AECD1A90A1 for ; Tue, 16 Feb 2016 14:45:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 ye90_Dp3Gzje for ; Tue, 16 Feb 2016 14:45:10 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0771.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:771]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC3F51A9115 for ; Tue, 16 Feb 2016 14:45:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8qGKs1MrdquBso3UYMduF/u5dgtUKM1WkRoPDkF+yvQ=; b=YID9OIVEJBce1HJ5bdNc3hiChcjbUu1DsymzLsCjqpdks9A7imsThmwNwDOWrdSNBpdkkBydeBwhqclrCojmEELUVv/b3WavGm8DeIuOa4YpzdrWDDAgjn3PjBk5ypbr8EQGv52znb3OjpZt4L9onng+krfTbRIQwXZBLVvh+wg= Received: from BY2PR0301MB0647.namprd03.prod.outlook.com (10.160.63.14) by BY2PR0301MB0648.namprd03.prod.outlook.com (10.160.63.140) with Microsoft SMTP Server (TLS) id 15.1.409.15; Tue, 16 Feb 2016 22:44:51 +0000 Received: from BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) by BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) with mapi id 15.01.0409.017; Tue, 16 Feb 2016 22:44:51 +0000 From: Brian Raymor To: Costin Manolache Thread-Topic: Re: [Webpush] Require the TTL header Thread-Index: AdFpCrXjzUkEsh6URySrfNlymrNO/w== Date: Tue, 16 Feb 2016 22:44:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2601:600:8000:5a8:a991:fd36:d5f3:19e] x-ms-office365-filtering-correlation-id: a74946fd-789e-4749-5cb8-08d33722c7d7 x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0648; 5:ke7JhMjtIWwjewIeFEqCZErPSJbP3aibEMf5ZOVC4kRvfORqkDp/EjtXGX92yYGDqa2mnpsEl29mBFNv400AEy8EMRCmieyC39GX1ltXoBvaDLyKjZ68tDM9tFkuFEk+kRWTJc7FnywYIscNqPLysQ==; 24:aEDmO7ouEPZCnMVvXvN4bLM73/Gj+DB6QC2UrwPx82YUoPhUmGBgozI2gFVBh/uWabUfQ/m3hrL0TRV1jFwl2jhIIdggIN0KM4Xsj6JWVns= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0301MB0648; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:BY2PR0301MB0648; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0648; x-forefront-prvs: 0854128AF0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(45074003)(24454002)(5003600100002)(50986999)(5002640100001)(54356999)(5001960100002)(1220700001)(33656002)(586003)(102836003)(6116002)(5008740100001)(1096002)(110136002)(99286002)(2906002)(4326007)(189998001)(11100500001)(10090500001)(122556002)(19580405001)(19580395003)(10290500002)(10400500002)(76576001)(40100003)(92566002)(15975445007)(86612001)(2900100001)(77096005)(74316001)(5005710100001)(5004730100002)(86362001)(87936001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0648; H:BY2PR0301MB0647.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2016 22:44:50.7442 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0648 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Require the TTL header 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: Tue, 16 Feb 2016 22:45:13 -0000 On Sat, Feb 6, 2016 at 12:48 PM, Costin Manolache wrote: > I assume 202 (Accepted) would be better for TTL=3D0 if the service is not= actually storing the message. My reading of 202 (Accepted) is that it's intended for asynchronous operati= ons: http://tools.ietf.org/html/rfc7231#section-6.3.3 The 202 response is intentionally noncommittal. Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the server persist until the process is completed. The representation sent with this response ought to describe the request's current status and point to (or embed) a status monitor that can provide the user with an estimate of when the request will be fulfilled. I suggest that we require the TTL - https://github.com/webpush-wg/webpush-p= rotocol/issues/76 - but maintain the current behavior where a Location is returned even for TTL= =3D0. There are already special cases in the text for TTL=3D0 indicating that the resource may be d= eleted before the user agent can acknowledge a message. =20 As I noted in my earlier response to Ben, the Location resource is also sub= sequently required for the synthesized GET: https://tools.ietf.org/html/draft-ietf-webpush-protocol-03#section-7.1 Each push message is pushed as the response to a synthesized GET request sent in a PUSH_PROMISE. This GET request is made to the push message resource that was created by the push service when the application server requested message delivery. ...Brian From nobody Wed Feb 17 11:32:41 2016 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 5ED651A8794 for ; Wed, 17 Feb 2016 11:32:40 -0800 (PST) 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 VzDWl081P2NQ for ; Wed, 17 Feb 2016 11:32:38 -0800 (PST) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CF811A8824 for ; Wed, 17 Feb 2016 11:32:37 -0800 (PST) Received: by mail-io0-x236.google.com with SMTP id 9so47614724iom.1 for ; Wed, 17 Feb 2016 11:32:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ttl+CZSeCXcmIvmSNsVlSnUuGKd2yb19DO9brdX2yY0=; b=PPI9mVME334Bd+1ymFhq0ystGOJRAkvP0b2yYX8Yei3+PqglYbLnGHOVAGz8tUFJTp oK9UBHgBFNwOm4MSerTe6x5oN2I9ntVjVlOgxeiZp67CExPHVGt6FwTFEx6jmJ0K14ML pnN1xOujBHDROdCdYHlGhC9AsUn28CEk3xh7r8oa36ZydJ2sr5B+UU7TDqgTRwGc/81g MvXSuDvGWGMOVApejRNHgUHRT/oKEqboC+pjX9KDRLxKRGorw6ndgZHxoMcMRnpRVTTd ox8zzUkVOYXHdQReN2zY3k360xPzZVymjaeigR09EcLeMRzvABpamB+vnAMwNBYI10xh hWQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Ttl+CZSeCXcmIvmSNsVlSnUuGKd2yb19DO9brdX2yY0=; b=d9g7Lh6BwslAGPaPA9kHCKOKir4pa6LR8qiiH1TDxN5SnW+4mwAb64QpAwM0EUjVHg NMXxKDXNcku5pfsukFcIH55CUhGW7I0LQxzLKZHXBPBTIuhi++ewyo7t0ygmW1aef5D8 EdeqLaqjU7hfwG+RC2mV4dz1+AHMqHuVVfRomXOORcnQDNCARiEY1FtzqXQHqbp527NV UipYy0cLefn4xP7E9Fa9VLv7wq6ufTLGWuEk2nKlYYTW3Wdbug0O9PxWk3xDcBZR7f0D HELhxV9xpLaRfHBlxt0BB0Oo8PxGlhYtJ2h1UFQ0Zrk62Top3k4x4qIMIT2jsQ6rQ7l+ ecyA== X-Gm-Message-State: AG10YOR6TZSqHYgsMKPa64DvtM3on3iKjGC0qclMwV/b3eMwZJ1iwSc+gQIO7QqdlO6EVXB3MBJRsRoIgfYi8g== MIME-Version: 1.0 X-Received: by 10.107.16.153 with SMTP id 25mr5246033ioq.100.1455737556580; Wed, 17 Feb 2016 11:32:36 -0800 (PST) Received: by 10.36.53.79 with HTTP; Wed, 17 Feb 2016 11:32:36 -0800 (PST) In-Reply-To: References: Date: Thu, 18 Feb 2016 06:32:36 +1100 Message-ID: From: Martin Thomson To: Brian Raymor Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Costin Manolache , "webpush@ietf.org" Subject: Re: [Webpush] Require the TTL header 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: Wed, 17 Feb 2016 19:32:40 -0000 This matches my understanding and seems like a reasonable plan. If you aren't persisting anything, and you don't need a good message identifier (because you are fully proprietary on the other side), just crank out a random number and tack it onto a junk URL. On 17 February 2016 at 09:44, Brian Raymor wrote: > > On Sat, Feb 6, 2016 at 12:48 PM, Costin Manolache wrote: > >> I assume 202 (Accepted) would be better for TTL=0 if the service is not actually storing the message. > > My reading of 202 (Accepted) is that it's intended for asynchronous operations: > > http://tools.ietf.org/html/rfc7231#section-6.3.3 > > The 202 response is intentionally noncommittal. Its purpose is to > allow a server to accept a request for some other process (perhaps a > batch-oriented process that is only run once per day) without > requiring that the user agent's connection to the server persist > until the process is completed. The representation sent with this > response ought to describe the request's current status and point to > (or embed) a status monitor that can provide the user with an > estimate of when the request will be fulfilled. > > I suggest that we require the TTL - https://github.com/webpush-wg/webpush-protocol/issues/76 - > but maintain the current behavior where a Location is returned even for TTL=0. There are already > special cases in the text for TTL=0 indicating that the resource may be deleted before the user agent can > acknowledge a message. > > As I noted in my earlier response to Ben, the Location resource is also subsequently required for the > synthesized GET: > > https://tools.ietf.org/html/draft-ietf-webpush-protocol-03#section-7.1 > > Each push message is pushed as the response to a synthesized GET > request sent in a PUSH_PROMISE. This GET request is made to the push > message resource that was created by the push service when the > application server requested message delivery. > > ...Brian > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush From nobody Wed Feb 17 11:38:19 2016 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 8D8961A0AFE for ; Wed, 17 Feb 2016 11:38:17 -0800 (PST) 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 cgCFnc1D2PPY for ; Wed, 17 Feb 2016 11:38:15 -0800 (PST) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACD361A0378 for ; Wed, 17 Feb 2016 11:38:15 -0800 (PST) Received: by mail-ob0-x22d.google.com with SMTP id jq7so30794269obb.0 for ; Wed, 17 Feb 2016 11:38:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hvc7pZDGKi3g9hWxMdviCU9fsr3gu3+5VUfwqeL2i3k=; b=MJ7bJmGnp3dIRRFayI2bimU/Izb5bOk7AUi6GIGlHqzTH7eguGHHhye91Bqaxt1z3J jEepZw+OgqJViMdvUoOwQ8T8D/Gvnd98xJUzMAuY0ak0YKjm9DbCFk0p8HsfpJtUQP21 tdqePuqyXET74I7PtVWe5y0AJgtvhx/vdDVMcc8iMpJ/DaF0yQwX4c3hoHETSrskeGWq E7YnkArpXZUl6AivfHJQYZnhcUMx+oPaCGp5jKI2J0UUAQdEoyOAI+70DpNHOCMABbjS 3NJHxW6vSUzYESAxZnX/rHvYaQZ/Y0xBg5lNIP8Ck6pHn+mSm3pRelNzLrrMgxadno1q 8UJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hvc7pZDGKi3g9hWxMdviCU9fsr3gu3+5VUfwqeL2i3k=; b=LeeH86QHtvKcsExkZ86FWpJt68hrJKDVvKm9OUMFMhnTyqgvvEoSMnFhpTcXUWVnzB her17YY38BMhg+Iuf5Y/UJ+e4U73dBr/i6KMale9GwsLpjpEk6c7f8YBLq4ImUyx1M2W ZKfHC88voSs/2Wul2WE2KWV2+beMgHVTCQlGQIoqBfaGEfTXGlNGPM06xZQ01E7cqxSI aW66v2/ZMQMuGou7tSuV2C/yvrACRhHanKuDIk9eGdKVecnRncNd8ZiAIPYvGTIXhN+E 9SQ0OmPdMe4xq0CwvOnvxt//5k5uZRELmtxj1bLL5ZaRFG+BpgtBC7epo1ghNkkU9ze6 RMCw== X-Gm-Message-State: AG10YOQY2PhsXx7q65vWERHjq5ypSTP4OwwIgddWqZ5tdO2HM+Q1DOObNuaeeCyWnwNfwtSftpAEDSsV8dm63Q== MIME-Version: 1.0 X-Received: by 10.202.102.69 with SMTP id a66mr2600090oic.93.1455737895193; Wed, 17 Feb 2016 11:38:15 -0800 (PST) Received: by 10.76.68.196 with HTTP; Wed, 17 Feb 2016 11:38:15 -0800 (PST) In-Reply-To: References: Date: Wed, 17 Feb 2016 11:38:15 -0800 Message-ID: From: Costin Manolache To: Brian Raymor Content-Type: multipart/alternative; boundary=001a1140f400211271052bfc641b Archived-At: Cc: Costin Manolache , "webpush@ietf.org" Subject: Re: [Webpush] Require the TTL header 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: Wed, 17 Feb 2016 19:38:17 -0000 --001a1140f400211271052bfc641b Content-Type: text/plain; charset=UTF-8 On Tue, Feb 16, 2016 at 2:44 PM, Brian Raymor wrote: > > On Sat, Feb 6, 2016 at 12:48 PM, Costin Manolache > wrote: > > > I assume 202 (Accepted) would be better for TTL=0 if the service is not > actually storing the message. > > My reading of 202 (Accepted) is that it's intended for asynchronous > operations: > > http://tools.ietf.org/html/rfc7231#section-6.3.3 > > The 202 response is intentionally noncommittal. Its purpose is to > allow a server to accept a request for some other process (perhaps a > batch-oriented process that is only run once per day) without > requiring that the user agent's connection to the server persist > until the process is completed. The representation sent with this > response ought to describe the request's current status and point to > (or embed) a status monitor that can provide the user with an > estimate of when the request will be fulfilled. > > This is pretty much what webpush is doing - accepts the request, and some other process ( the connection side ) may deliver it later :-) However it may be confusing, so I'm fine either way. > I suggest that we require the TTL - > https://github.com/webpush-wg/webpush-protocol/issues/76 - > but maintain the current behavior where a Location is returned even for > TTL=0. There are already > special cases in the text for TTL=0 indicating that the resource may be > deleted before the user agent can > acknowledge a message. > +1 Costin > As I noted in my earlier response to Ben, the Location resource is also > subsequently required for the > synthesized GET: > > https://tools.ietf.org/html/draft-ietf-webpush-protocol-03#section-7.1 > > Each push message is pushed as the response to a synthesized GET > request sent in a PUSH_PROMISE. This GET request is made to the push > message resource that was created by the push service when the > application server requested message delivery. > > ...Brian > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > --001a1140f400211271052bfc641b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Feb 16, 2016 at 2:44 PM, Brian Raymor <Brian.Raymor@micro= soft.com> wrote:

On Sat, Feb 6, 2016 at 12:48 PM, Costin Manolache <costin@gmail.com> wrote:

> I assume 202 (Accepted) would be better for TTL=3D0 if the service is = not actually storing the message.

My reading of 202 (Accepted) is that it's intended for asynchronous ope= rations:

http://tools.ietf.org/html/rfc7231#section-6.3.3=

=C2=A0 =C2=A0The 202 response is intentionally noncommittal.=C2=A0 Its purp= ose is to
=C2=A0 =C2=A0allow a server to accept a request for some other process (per= haps a
=C2=A0 =C2=A0batch-oriented process that is only run once per day) without<= br> =C2=A0 =C2=A0requiring that the user agent's connection to the server p= ersist
=C2=A0 =C2=A0until the process is completed.=C2=A0 The representation sent = with this
=C2=A0 =C2=A0response ought to describe the request's current status an= d point to
=C2=A0 =C2=A0(or embed) a status monitor that can provide the user with an<= br> =C2=A0 =C2=A0estimate of when the request will be fulfilled.


This is pretty much what webpush is do= ing - accepts the request, and some other=C2=A0
process ( the con= nection side ) may deliver it later :-)
However it may be confusi= ng, so I'm fine either way.

=C2=A0
I suggest that we require the TTL - https://= github.com/webpush-wg/webpush-protocol/issues/76 -
but maintain the current behavior where a Location is returned even for TTL= =3D0.=C2=A0 =C2=A0There are already
special cases in the text for TTL=3D0 indicating that the resource may be d= eleted before the user agent can
acknowledge a message.

+1
=C2= =A0

Costin


As I noted in my earlier response to Ben, the Location resource is also sub= sequently required for the
synthesized GET:

https://tools.ietf.org/html/dr= aft-ietf-webpush-protocol-03#section-7.1

=C2=A0 =C2=A0Each push message is pushed as the response to a synthesized G= ET
=C2=A0 =C2=A0request sent in a PUSH_PROMISE.=C2=A0 This GET request is made= to the push
=C2=A0 =C2=A0message resource that was created by the push service when the=
=C2=A0 =C2=A0application server requested message delivery.

...Brian

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

--001a1140f400211271052bfc641b-- From nobody Fri Feb 19 10:10:01 2016 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 8AAD81B33CC for ; Fri, 19 Feb 2016 10:09:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 2L-mAglwTYXu for ; Fri, 19 Feb 2016 10:09:53 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0763.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:763]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9C161B33C5 for ; Fri, 19 Feb 2016 10:09:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nZXeW7xVk7ZrqFniwtZqDtKHPmhyn/CJB+XN5J2JK24=; b=M/J/xXnO2QCH48pDki8EOZMVYd47rjZYSDTkgq6o8t6eR8/UTEGnK2L/8jhlRo3LmQlAmJYJzyOUKaLv8SHD1C6ue5NMiJzVrhFaC36/wbDPfpfQzOxbkwOD8XJ6t3N3zsKe+i2OMzC3lXy4Zh1Mf95lzqy3RPFcZ3UhYO4TcY8= Received: from BY2PR0301MB0647.namprd03.prod.outlook.com (10.160.63.14) by BY2PR0301MB0646.namprd03.prod.outlook.com (10.160.63.139) with Microsoft SMTP Server (TLS) id 15.1.409.15; Fri, 19 Feb 2016 18:09:35 +0000 Received: from BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) by BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) with mapi id 15.01.0409.017; Fri, 19 Feb 2016 18:09:35 +0000 From: Brian Raymor To: Costin Manolache Thread-Topic: [Webpush] Require the TTL header Thread-Index: AQHRabq/NNt0i5J5AE6H2BK5Tqj6DJ8zrMCw Date: Fri, 19 Feb 2016 18:09:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2601:600:8000:5a8:ccdc:8fb0:107c:4e51] x-ms-office365-filtering-correlation-id: bf230f57-d863-4317-4b8c-08d33957d345 x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0646; 5:AZ+OLZs1zp6ksoxws9MeRfvBpI/2u1YMJNG+u26eMWcKhcLAo3UVMb/ooFkeaRLKDZbfX9xbGTuHWyEydU9wfC+1+er7VDIPnC5DYQcuGKYETXaHoGQZ5ft7PX08FLHG8qsru2VSwCf/W8w4B941mA==; 24:TF9rj1GNSfmSNWIQr/SAipYFogY0PK39Z+VFXOrFBebxhBRxnNK+mcLbz3UnUiYKFVMVv7ycMzmVjyinnUxXQn4oOS+8Y3pflNG1QCKn7ko= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0301MB0646; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR0301MB0646; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0646; x-forefront-prvs: 08572BD77F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(45074003)(24454002)(377454003)(4326007)(2906002)(92566002)(76576001)(3280700002)(5002640100001)(5003600100002)(74316001)(110136002)(189998001)(5001960100002)(5008740100001)(106116001)(2950100001)(99286002)(33656002)(1411001)(2900100001)(11100500001)(77096005)(50986999)(54356999)(15975445007)(10090500001)(19580405001)(122556002)(19580395003)(40100003)(76176999)(86612001)(6116002)(87936001)(1096002)(86362001)(3660700001)(102836003)(5004730100002)(1220700001)(10400500002)(5005710100001)(586003)(10290500002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0646; H:BY2PR0301MB0647.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2016 18:09:35.6656 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0646 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Require the TTL header 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, 19 Feb 2016 18:09:59 -0000 SSd2ZSBjbG9zZWQgdGhlICJSZXF1aXJlIHRoZSBUVEwiIGlzc3VlIC0gaHR0cHM6Ly9naXRodWIu Y29tL3dlYnB1c2gtd2cvd2VicHVzaC1wcm90b2NvbC9pc3N1ZXMvNzYgLSB3aXRoIC0gaHR0cHM6 Ly9naXRodWIuY29tL3dlYnB1c2gtd2cvd2VicHVzaC1wcm90b2NvbC9wdWxsLzc3IC4NCg0KDQpG cm9tOiBDb3N0aW4gTWFub2xhY2hlIFttYWlsdG86Y29zdGluQGdtYWlsLmNvbV0gDQpTZW50OiBX ZWRuZXNkYXksIEZlYnJ1YXJ5IDE3LCAyMDE2IDExOjM4IEFNDQpUbzogQnJpYW4gUmF5bW9yIDxC cmlhbi5SYXltb3JAbWljcm9zb2Z0LmNvbT4NCkNjOiBDb3N0aW4gTWFub2xhY2hlIDxjb3N0aW5A Z29vZ2xlLmNvbT47IHdlYnB1c2hAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbV2VicHVzaF0gUmVx dWlyZSB0aGUgVFRMIGhlYWRlcg0KDQoNCk9uIFR1ZSwgRmViIDE2LCAyMDE2IGF0IDI6NDQgUE0s IEJyaWFuIFJheW1vciA8QnJpYW4uUmF5bW9yQG1pY3Jvc29mdC5jb20+IHdyb3RlOg0KDQpPbiBT YXQsIEZlYiA2LCAyMDE2IGF0IDEyOjQ4IFBNLCBDb3N0aW4gTWFub2xhY2hlIDxjb3N0aW5AZ21h aWwuY29tPiB3cm90ZToNCg0KPiBJIGFzc3VtZSAyMDIgKEFjY2VwdGVkKSB3b3VsZCBiZSBiZXR0 ZXIgZm9yIFRUTD0wIGlmIHRoZSBzZXJ2aWNlIGlzIG5vdCBhY3R1YWxseSBzdG9yaW5nIHRoZSBt ZXNzYWdlLg0KDQpNeSByZWFkaW5nIG9mIDIwMiAoQWNjZXB0ZWQpIGlzIHRoYXQgaXQncyBpbnRl bmRlZCBmb3IgYXN5bmNocm9ub3VzIG9wZXJhdGlvbnM6DQoNCmh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzcyMzEjc2VjdGlvbi02LjMuMw0KDQrCoCDCoFRoZSAyMDIgcmVzcG9uc2UgaXMg aW50ZW50aW9uYWxseSBub25jb21taXR0YWwuwqAgSXRzIHB1cnBvc2UgaXMgdG8NCsKgIMKgYWxs b3cgYSBzZXJ2ZXIgdG8gYWNjZXB0IGEgcmVxdWVzdCBmb3Igc29tZSBvdGhlciBwcm9jZXNzIChw ZXJoYXBzIGENCsKgIMKgYmF0Y2gtb3JpZW50ZWQgcHJvY2VzcyB0aGF0IGlzIG9ubHkgcnVuIG9u Y2UgcGVyIGRheSkgd2l0aG91dA0KwqAgwqByZXF1aXJpbmcgdGhhdCB0aGUgdXNlciBhZ2VudCdz IGNvbm5lY3Rpb24gdG8gdGhlIHNlcnZlciBwZXJzaXN0DQrCoCDCoHVudGlsIHRoZSBwcm9jZXNz IGlzIGNvbXBsZXRlZC7CoCBUaGUgcmVwcmVzZW50YXRpb24gc2VudCB3aXRoIHRoaXMNCsKgIMKg cmVzcG9uc2Ugb3VnaHQgdG8gZGVzY3JpYmUgdGhlIHJlcXVlc3QncyBjdXJyZW50IHN0YXR1cyBh bmQgcG9pbnQgdG8NCsKgIMKgKG9yIGVtYmVkKSBhIHN0YXR1cyBtb25pdG9yIHRoYXQgY2FuIHBy b3ZpZGUgdGhlIHVzZXIgd2l0aCBhbg0KwqAgwqBlc3RpbWF0ZSBvZiB3aGVuIHRoZSByZXF1ZXN0 IHdpbGwgYmUgZnVsZmlsbGVkLg0KDQpUaGlzIGlzIHByZXR0eSBtdWNoIHdoYXQgd2VicHVzaCBp cyBkb2luZyAtIGFjY2VwdHMgdGhlIHJlcXVlc3QsIGFuZCBzb21lIG90aGVywqANCnByb2Nlc3Mg KCB0aGUgY29ubmVjdGlvbiBzaWRlICkgbWF5IGRlbGl2ZXIgaXQgbGF0ZXIgOi0pDQpIb3dldmVy IGl0IG1heSBiZSBjb25mdXNpbmcsIHNvIEknbSBmaW5lIGVpdGhlciB3YXkuDQoNCsKgDQpJIHN1 Z2dlc3QgdGhhdCB3ZSByZXF1aXJlIHRoZSBUVEwgLSBodHRwczovL2dpdGh1Yi5jb20vd2VicHVz aC13Zy93ZWJwdXNoLXByb3RvY29sL2lzc3Vlcy83NiAtDQpidXQgbWFpbnRhaW4gdGhlIGN1cnJl bnQgYmVoYXZpb3Igd2hlcmUgYSBMb2NhdGlvbiBpcyByZXR1cm5lZCBldmVuIGZvciBUVEw9MC7C oCDCoFRoZXJlIGFyZSBhbHJlYWR5DQpzcGVjaWFsIGNhc2VzIGluIHRoZSB0ZXh0IGZvciBUVEw9 MCBpbmRpY2F0aW5nIHRoYXQgdGhlIHJlc291cmNlIG1heSBiZSBkZWxldGVkIGJlZm9yZSB0aGUg dXNlciBhZ2VudCBjYW4NCmFja25vd2xlZGdlIGEgbWVzc2FnZS4NCg0KKzENCsKgDQoNCkNvc3Rp bg0KDQoNCkFzIEkgbm90ZWQgaW4gbXkgZWFybGllciByZXNwb25zZSB0byBCZW4sIHRoZSBMb2Nh dGlvbiByZXNvdXJjZSBpcyBhbHNvIHN1YnNlcXVlbnRseSByZXF1aXJlZCBmb3IgdGhlDQpzeW50 aGVzaXplZCBHRVQ6DQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXdl YnB1c2gtcHJvdG9jb2wtMDMjc2VjdGlvbi03LjENCg0KwqAgwqBFYWNoIHB1c2ggbWVzc2FnZSBp cyBwdXNoZWQgYXMgdGhlIHJlc3BvbnNlIHRvIGEgc3ludGhlc2l6ZWQgR0VUDQrCoCDCoHJlcXVl c3Qgc2VudCBpbiBhIFBVU0hfUFJPTUlTRS7CoCBUaGlzIEdFVCByZXF1ZXN0IGlzIG1hZGUgdG8g dGhlIHB1c2gNCsKgIMKgbWVzc2FnZSByZXNvdXJjZSB0aGF0IHdhcyBjcmVhdGVkIGJ5IHRoZSBw dXNoIHNlcnZpY2Ugd2hlbiB0aGUNCsKgIMKgYXBwbGljYXRpb24gc2VydmVyIHJlcXVlc3RlZCBt ZXNzYWdlIGRlbGl2ZXJ5Lg0KDQouLi5Ccmlhbg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KV2VicHVzaCBtYWlsaW5nIGxpc3QNCldlYnB1c2hAaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vd2VicHVzaA0KDQo= From nobody Fri Feb 19 12:26:17 2016 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 E91341A1BDF for ; Fri, 19 Feb 2016 12:26:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, 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 7Y6H_Y6tP23l for ; Fri, 19 Feb 2016 12:26:14 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0127.outbound.protection.outlook.com [65.55.169.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A7511A1B1C for ; Fri, 19 Feb 2016 12:26:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+smC+HIjOpeH+rqokdcudWBhC/J6VtCJHjCluGyXB74=; b=Du+9leQo61c49ziGaAfMfbHLph4G63thxytYmfn+KEEGxx9n0OmM+QuyrfNmk6uyyer+RO+KozmCYTq5OEgqem2x7ydcgG0+wqG2+AQyLBVuJ4KTq4dJgPhGkRZ1+ga2SmA9/xqR7u1YsO9f17zFxflm/o7XqqL7bme7+sByuJw= Received: from BY2PR0301MB0647.namprd03.prod.outlook.com (10.160.63.14) by BY2PR0301MB0648.namprd03.prod.outlook.com (10.160.63.140) with Microsoft SMTP Server (TLS) id 15.1.409.15; Fri, 19 Feb 2016 20:26:12 +0000 Received: from BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) by BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) with mapi id 15.01.0409.017; Fri, 19 Feb 2016 20:26:12 +0000 From: Brian Raymor To: "webpush@ietf.org" Thread-Topic: 202 (Accepted) and simplifying acknowledgements Thread-Index: AdFrSF8gtTEETI3TT4mdvlYA58NVcw== Date: Fri, 19 Feb 2016 20:26:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2601:600:8000:5a8:ccdc:8fb0:107c:4e51] x-ms-office365-filtering-correlation-id: 6666ae38-00f7-4f28-21e8-08d3396ae90f x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0648; 5:vtur30V/SFf/WZlVpjcYTYlvSvc3PjpAgKhXTNistGRfQdzZRMMtSOUb6da2494eKEZwjtYA+59LM+Aeo7bn4nnL1ed8gZpgVFI7etj88oOLsf0dboppq/xz5m7/EmWVXGI6EsdBtGyS5KGqD3E+kQ==; 24:FZdG34HYWaZQW3FvVV2L4Py5d1PVfmXRj9Xm+cr+7LJVB1cssw7yCAwx3fKVG6wwxwa878A/QgRBk2sYvSlJecsV804d42u7Zgdnced8w8o= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0301MB0648; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR0301MB0648; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0648; x-forefront-prvs: 08572BD77F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(86612001)(5002640100001)(5003600100002)(15975445007)(87936001)(5001960100002)(107886002)(76576001)(86362001)(2351001)(11100500001)(2501003)(19580395003)(74316001)(229853001)(189998001)(5008740100001)(1096002)(77096005)(92566002)(10090500001)(561944003)(99286002)(450100001)(5004730100002)(40100003)(54356999)(2906002)(50986999)(2900100001)(33656002)(122556002)(1730700002)(3280700002)(3660700001)(10400500002)(5005710100001)(6116002)(102836003)(586003)(110136002)(10290500002)(1220700001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0648; H:BY2PR0301MB0647.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2016 20:26:12.5646 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0648 Archived-At: Subject: [Webpush] 202 (Accepted) and simplifying acknowledgements 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, 19 Feb 2016 20:26:17 -0000 I've thought a bit more about the 202 discussion with Ben, Costin, and Mart= in. I have a small proposal that I've run past Martin and Elio for a sanity= check.=20 Currently - when an application server requests push message delivery, ther= e are separate flows for message creation and message delivery: 1. Message Creation - The push service returns a 201 (Created) returned by = the POST with a Location resource 2. Subsequent notification of delivery success or failure using Receipt Ack= nowledgements. Receipt Acknowledgements also has many moving parts: 1. The PS returns :push and :push:receipts to the UA during its message sub= scription process. 2. The UA distributes :push and :push:receipts to its AS. 3. The AS requests a receipts subscription (:push:receipt) from the PS usin= g :push:receipts. 4. The AS requests message delivery from the PS using :push and includes :p= ush:receipt. 5. The PS returns a 201 (Created) on success for the message delivery reque= st from the AS. It also includes a Location. 6. The AS monitors :push:receipt for success (acknowledgements) or failure = (expiration or delivery attempts ceased). A more natural flow could use 202 (Accepted) with the :push:receipt as the = "status monitor". As Costin noted: > This is pretty much what webpush is doing - accepts the request, and some= other=20 > process ( the connection side ) may deliver it later :-) 1. The PS returns :push to the UA during its message subscription process. 2. The UA distributes :push to its AS. 3. The AS requests message delivery from the PS using :push. 4. The PS returns a 202 (Accepted) on success for the message delivery requ= est from the AS. It also includes a Location and :push:receipt as the "stat= us monitor" suggested for a 202. 5. The AS monitors :push:receipt for success (acknowledgements) or failure = (expiration or delivery attempts ceased). This eliminates the need for the :push:receipts link relation and its "mach= inery" and simplifies the flow a bit.=20 Another difference is that the current design allows the AS to request ackn= owledgements by including :push:receipt with its message delivery request t= o the PS. If we want to maintain this optional behavior, then we would nee= d a header - perhaps reusing Prefer: respond-async as a hint - http://tools= .ietf.org/html/rfc7240#section-4.1 - that would be included when the AS req= uests message delivery. If a pull request would offer more clarity, please let me know. Thoughts? ...Brian From nobody Fri Feb 19 14:22:45 2016 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 0B0881B317F for ; Fri, 19 Feb 2016 14:22:45 -0800 (PST) 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 4r10R3himeky for ; Fri, 19 Feb 2016 14:22:42 -0800 (PST) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 917BD1B2EDA for ; Fri, 19 Feb 2016 14:22:42 -0800 (PST) Received: by mail-oi0-x234.google.com with SMTP id m82so21778490oif.1 for ; Fri, 19 Feb 2016 14:22:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TWHtJsCepY9F+CGvGRp+SnAphjczM7Hj3l/zlTuNh9A=; b=gPMPmlR8TD24cuftSypSfAr/y90UH5xjK1FdClaE9LJ7C2oj0G+TXBF/Y0JxLmesPb 0UOFLlEfpptjlXex9pNjR94slTFdPkXqpvs4GjNzkQT8FlmSlta+FPL6IdGf2Pu7NdNf V+I9TqpEOHAOmwSRxKzpMPpjkKc5T1tmmO0suApoDQ9dGX2Z/KllkgD530WH1SibYzy0 M1gIhKxe4f0spyZYaHRZkfTteAu2kR0hL94uTKDLlMguH9cSjGFZooTka5piJ3t5PQGu Gq7c88nmW8Vn/0Pu3QHp8TYc0cWXWbFNeiGGn/4hVVwfxLDxKRuABu5+N9No53DKapB1 lFGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TWHtJsCepY9F+CGvGRp+SnAphjczM7Hj3l/zlTuNh9A=; b=PiY1LyKGX+UJPo4SchrBp41MUHNX4ZGggZB8AxwNGeL+SSvuVbQwK3ejXUuxw8rEbz 0GMckm9dve+pk21XenBnoBGtFAh6ucmwpgDZUAoDW+yETvB6jGRFGtosaJpN8IiSR62W vmd/LiFghfWQ8RulyB6rslcLW0LVK850pRUcMRliV3YemqsZ+UmI58gLdpc1esAn4T+A KfhbMbhhO6FS0vxvjrFUrJkrFRQAdly8zggL9bvRz1ItVfX1LpU8B7p53PZNlCtN3DTp j3xmNU33C51RzJgSCtHjSLuP6Zqx3bdnVj4TBX/DEFMmTma7erS6ywjdFZE+cudH8XZa lRGg== X-Gm-Message-State: AG10YOS4RkA9N5ai5zTimt2CPI6LhXAz3oP8HtzyNKQ0yuMNZ4ZW2+IBjK5t96Zc6EtD/4nv4RwsYk+vmcIVlQ== MIME-Version: 1.0 X-Received: by 10.202.102.69 with SMTP id a66mr13282601oic.93.1455920561999; Fri, 19 Feb 2016 14:22:41 -0800 (PST) Received: by 10.76.75.35 with HTTP; Fri, 19 Feb 2016 14:22:41 -0800 (PST) In-Reply-To: References: Date: Fri, 19 Feb 2016 14:22:41 -0800 Message-ID: From: Costin Manolache To: Brian Raymor Content-Type: multipart/alternative; boundary=001a1140f400eb54a0052c26eb8d Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] 202 (Accepted) and simplifying acknowledgements 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, 19 Feb 2016 22:22:45 -0000 --001a1140f400eb54a0052c26eb8d Content-Type: text/plain; charset=UTF-8 Sounds good. The optional "push:receipt" is very important for everyone, and we should add some info about the additional costs of requesting a receipt. At least in some implementation the push receipts can be more expensive than the actual messages, and in most cases the UA will make some http requests to the AS - so the ACK is redundant. I assume the rest of the receipt will be the same: AS will connect to the URL, make a GET and get push promises, like in the case of UA getting messages ? Costin On Fri, Feb 19, 2016 at 12:26 PM, Brian Raymor wrote: > > I've thought a bit more about the 202 discussion with Ben, Costin, and > Martin. I have a small proposal that I've run past Martin and Elio for a > sanity check. > > Currently - when an application server requests push message delivery, > there are separate flows for message creation and message delivery: > > 1. Message Creation - The push service returns a 201 (Created) returned by > the POST with a Location resource > 2. Subsequent notification of delivery success or failure using Receipt > Acknowledgements. > > Receipt Acknowledgements also has many moving parts: > > 1. The PS returns :push and :push:receipts to the UA during its message > subscription process. > 2. The UA distributes :push and :push:receipts to its AS. > 3. The AS requests a receipts subscription (:push:receipt) from the PS > using :push:receipts. > 4. The AS requests message delivery from the PS using :push and includes > :push:receipt. > 5. The PS returns a 201 (Created) on success for the message delivery > request from the AS. It also includes a Location. > 6. The AS monitors :push:receipt for success (acknowledgements) or failure > (expiration or delivery attempts ceased). > > A more natural flow could use 202 (Accepted) with the :push:receipt as the > "status monitor". As Costin noted: > > > This is pretty much what webpush is doing - accepts the request, and > some other > > process ( the connection side ) may deliver it later :-) > > 1. The PS returns :push to the UA during its message subscription process. > 2. The UA distributes :push to its AS. > 3. The AS requests message delivery from the PS using :push. > 4. The PS returns a 202 (Accepted) on success for the message delivery > request from the AS. It also includes a Location and :push:receipt as the > "status monitor" suggested for a 202. > 5. The AS monitors :push:receipt for success (acknowledgements) or failure > (expiration or delivery attempts ceased). > > This eliminates the need for the :push:receipts link relation and its > "machinery" and simplifies the flow a bit. > > Another difference is that the current design allows the AS to request > acknowledgements by including :push:receipt with its message delivery > request to the PS. If we want to maintain this optional behavior, then we > would need a header - perhaps reusing Prefer: respond-async as a hint - > http://tools.ietf.org/html/rfc7240#section-4.1 - that would be included > when the AS requests message delivery. > > If a pull request would offer more clarity, please let me know. > > Thoughts? > > ...Brian > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > --001a1140f400eb54a0052c26eb8d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sounds good.

The optional "push:re= ceipt" is very important for everyone, and we should add some info abo= ut the additional
costs of requesting a receipt.

At least in some implementation the push receipts can be more expe= nsive than the actual messages, and in
most cases the UA will mak= e some http requests to the AS - so the ACK is redundant.=C2=A0
<= br>
I assume the rest of the receipt will be the same: AS will co= nnect to the URL, make a GET and get push promises,=C2=A0
like in= the case of UA getting messages ?=C2=A0

Costin=C2= =A0

On= Fri, Feb 19, 2016 at 12:26 PM, Brian Raymor <Brian.Raymor@micro= soft.com> wrote:

I've thought a bit more about the 202 discussion with Ben, Costin, and = Martin. I have a small proposal that I've run past Martin and Elio for = a sanity check.

Currently - when an application server requests push message delivery, ther= e are separate flows for message creation and message delivery:

1. Message Creation - The push service returns a 201 (Created) returned by = the POST with a Location resource
2. Subsequent notification of delivery success or failure using Receipt Ack= nowledgements.

Receipt Acknowledgements also has many moving parts:

1. The PS returns :push and :push:receipts to the UA during its message sub= scription process.
2. The UA distributes :push and :push:receipts to its AS.
3. The AS requests a receipts subscription (:push:receipt) from the PS usin= g :push:receipts.
4. The AS requests message delivery from the PS using :push and includes :p= ush:receipt.
5. The PS returns a 201 (Created) on success for the message delivery reque= st from the AS. It also includes a Location.
6. The AS monitors :push:receipt for success (acknowledgements) or failure = (expiration or delivery attempts ceased).

A more natural flow could use 202 (Accepted) with the :push:receipt as the = "status monitor". As Costin noted:

> This is pretty much what webpush is doing - accepts the request, and s= ome other
> process ( the connection side ) may deliver it later :-)

1. The PS returns :push to the UA during its message subscription process.<= br> 2. The UA distributes :push to its AS.
3. The AS requests message delivery from the PS using :push.
4. The PS returns a 202 (Accepted) on success for the message delivery requ= est from the AS. It also includes a Location and :push:receipt as the "= ;status monitor" suggested for a 202.
5. The AS monitors :push:receipt for success (acknowledgements) or failure = (expiration or delivery attempts ceased).

This eliminates the need for the :push:receipts link relation and its "= ;machinery" and simplifies the flow a bit.

Another difference is that the current design allows the AS to request ackn= owledgements by including :push:receipt with its message delivery request t= o the PS.=C2=A0 If we want to maintain this optional behavior, then we woul= d need a header - perhaps reusing Prefer: respond-async as a hint - http://tools.ietf.org/html/rfc7240#section-4.1 - that wou= ld be included when the AS requests message delivery.

If a pull request would offer more clarity, please let me know.

Thoughts?

...Brian

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

--001a1140f400eb54a0052c26eb8d-- From nobody Fri Feb 19 15:53:29 2016 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 F20461B36AF for ; Fri, 19 Feb 2016 15:53:27 -0800 (PST) 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 OtqENXwlFIpR for ; Fri, 19 Feb 2016 15:53:26 -0800 (PST) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C0841B36AB for ; Fri, 19 Feb 2016 15:53:26 -0800 (PST) Received: by mail-ig0-x22a.google.com with SMTP id 5so47507383igt.0 for ; Fri, 19 Feb 2016 15:53:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=ppduj6ifOo1aV5d7XvsolZ828gmT0/er2ub9nPxbQ6k=; b=tCvSWhWT49hBn5YDi6tAtX8MJtI+T2Pb3KvKBgoI+/uvlG/jvWUaRp70Ku25dFbPR0 NbCosvbUBPWQ+g3It8Q40LxkxwCGXCPvYJwlGkwtmvzSE3qESgJ51fhdHgEGH7poi3Tz OoS8li4Vwq020pXmeJ/EeuMhFhaEmmrCCk2Ec7X8TPbxNy+YS3lnFWVdqMftUBUKTRcf qFsm7AoPRQeJP5N+cVx9RNEHeyuShIjvekbZw15Z8hnXWubzser75vQLFMsYG5WYWJRI n/QPc9rHOCkaKVjeMD3emL4eSRcE89EC/ELmwJRsLR8nWEY5wbXubMhuclhTbI1U8d6W M+VQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=ppduj6ifOo1aV5d7XvsolZ828gmT0/er2ub9nPxbQ6k=; b=F3JbBQV1POU3+LP4Zb3U9HgjU3zrHzDfZaEylCV7v8iyjhXS5cqfCANn0DbjN+9LCQ VUhwlqc8sETRgp/eKZjABz9bL0ZSWtLs8hmiBbD1LvQ8HxCHQ56qbKse1nsEt/gRkieg VcynH9uAlUZ2PyKTAsTUTcXaeOSbFz3PxAmoPaqZg1HVUq5Cf31jOhUZSYkSVElLz9AL Hh9GmOLb06dWRirOLbHQwyg9CZTP6qTRHmo52JuuQ9jCucDeCjlQTQJfmhxaJqcLSajZ SK+r4FQZG7tGw9iiifry2E/w4QZBqd0E0IuKzd9J30ur58mCHhg6F37J+p/lODh7YfUC i7QQ== X-Gm-Message-State: AG10YOSw3asuZvKcYsFL0+BgqzxgoTRfFBsSMvv0O0SZwA+w3XR4aZ61tsPFlSn4wYaQSDC92bBIIVP81rLOOQ== MIME-Version: 1.0 X-Received: by 10.50.6.104 with SMTP id z8mr495988igz.58.1455926005992; Fri, 19 Feb 2016 15:53:25 -0800 (PST) Received: by 10.36.53.79 with HTTP; Fri, 19 Feb 2016 15:53:25 -0800 (PST) In-Reply-To: References: Date: Fri, 19 Feb 2016 16:53:25 -0700 Message-ID: From: Martin Thomson To: Brian Raymor Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] 202 (Accepted) and simplifying acknowledgements 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, 19 Feb 2016 23:53:28 -0000 On 19 February 2016 at 13:26, Brian Raymor wrote: > 4. The PS returns a 202 (Accepted) on success for the message delivery request from the AS. It also includes a Location and :push:receipt as the "status monitor" suggested for a 202. I think that: a) this change in design is generally good, but I have one question and maybe a suggestion b) we should use 201 still, since a resource is created (even if it is purely ephemeral, as it is in the case of TTL: 0) The question is: what would the :receipt link identify? This is a resource that the application server would monitor for receipts. But that has the same problem we had with subscriptions that led to the creation of subscription sets, namely that the application server has to make a request for every push message it wants to track. Is that your intention? Because if it is, that's a lot of GET requests, which could lead to scaling issues. I have a suggestion. If this were to act like a subscription *set* rather than a subscription (see Costin's question), I think that this would be better. The only question then is how an application server causes its receipts to be correlated. The obvious answer is to create the subscription set in an initial request and use the inclusion of the link relation in the push message request as an indication that the application server wants to link receipts to an existing subscription. A less good, but probably OK possibility is to hook into the voluntary identification and have application servers get a subscription set based on their offered identity. From nobody Fri Feb 19 16:04:19 2016 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 414BD1B36F0 for ; Fri, 19 Feb 2016 16:04:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, 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 jy4XUnVE04aG for ; Fri, 19 Feb 2016 16:04:15 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0124.outbound.protection.outlook.com [65.55.169.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E5871B36F6 for ; Fri, 19 Feb 2016 16:04:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UU/U12HYn47QovEK62hVr76S4xlCZR8MrwwyUAK97f8=; b=Mywx9evihICFJP8FanmhRC07Jx624knLCIVWWMr/zTWGmBIvsqglvhhriVvYyf5Lt8fSLAP7trYFvd1xcGBmEIJez0gOBRIVdJSQscevPaoGYSHhMiXD9K5f4kTMzlGbcLP6FVSe4mvxOaELGAl+13JOIX4JXmnKz+HYQ6pfkzU= Received: from BY2PR0301MB0647.namprd03.prod.outlook.com (10.160.63.14) by BY2PR0301MB0647.namprd03.prod.outlook.com (10.160.63.14) with Microsoft SMTP Server (TLS) id 15.1.409.15; Sat, 20 Feb 2016 00:04:08 +0000 Received: from BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) by BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) with mapi id 15.01.0409.017; Sat, 20 Feb 2016 00:04:08 +0000 From: Brian Raymor To: Costin Manolache Thread-Topic: [Webpush] 202 (Accepted) and simplifying acknowledgements Thread-Index: AdFrSF8gtTEETI3TT4mdvlYA58NVcwAG6y2AAAN1/5A= Date: Sat, 20 Feb 2016 00:04:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2601:600:8000:5a8:ccdc:8fb0:107c:4e51] x-ms-office365-filtering-correlation-id: a7ead4c0-35a9-4171-f033-08d339895a7c x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0647; 5:nSYoSLOVEmHF0ECU/NPVKfZycshwn6Oqunh7d7HC7l7GUeNDc3b1GBt0CkQrTsrO5sfSxr/iAh/AYsRSx1ncFwDi+Arj1tKHg4CoApdFjVaM9C+zgIUV9XIlRGatrCA7ftKCEAoyD6m384PXJZBGsA==; 24:zK4jAbOZe4Wte6Q9s2FQVI0aQaBIAd+O9ssP6dk8My6oYFODQR+X3o5sCZUC/QkhzbFqDwbbok593egEWhrL/mLnm19qEOxuZx6zKf6Chkw= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0301MB0647; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR0301MB0647; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0647; x-forefront-prvs: 0858FF8026 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(10090500001)(8990500004)(99286002)(92566002)(5004730100002)(10290500002)(50986999)(76176999)(54356999)(2900100001)(2950100001)(5005710100001)(40100003)(10400500002)(19580395003)(3280700002)(558084003)(86362001)(1220700001)(86612001)(77096005)(1096002)(586003)(5008740100001)(122556002)(76576001)(110136002)(4326007)(5001960100002)(102836003)(5002640100001)(11100500001)(33656002)(189998001)(19580405001)(3660700001)(87936001)(5003600100002)(6116002)(74316001)(2906002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0647; H:BY2PR0301MB0647.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2016 00:04:07.7999 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0647 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] 202 (Accepted) and simplifying acknowledgements 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, 20 Feb 2016 00:04:18 -0000 T24gRnJpLCBGZWIgMTksIDIwMTYgYXQgMjoyMyBQTSwgQ29zdGluIE1hbm9sYWNoZSA8IGNvc3Rp bkBnbWFpbC5jb20gPiB3cm90ZToNCg0KPiBJIGFzc3VtZSB0aGUgcmVzdCBvZiB0aGUgcmVjZWlw dCB3aWxsIGJlIHRoZSBzYW1lOiBBUyB3aWxsIGNvbm5lY3QgdG8gdGhlIFVSTCwNCj4gbWFrZSBh IEdFVCBhbmQgZ2V0IHB1c2ggcHJvbWlzZXMsIGxpa2UgaW4gdGhlIGNhc2Ugb2YgVUEgZ2V0dGlu ZyBtZXNzYWdlcyA/DQoNCkNvcnJlY3QuIFRoYXQgc2VjdGlvbiBpcyB1bmNoYW5nZWQuDQo= From nobody Fri Feb 19 16:52:37 2016 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 C61701B35D2 for ; Fri, 19 Feb 2016 16:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, 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 1F6phmXuHpoy for ; Fri, 19 Feb 2016 16:52:32 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0118.outbound.protection.outlook.com [65.55.169.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D2711B3598 for ; Fri, 19 Feb 2016 16:52:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=INXO6zaMzCnwBZ4VAZoLUsBbCkTY0Sd8eVcGvebuOZg=; b=FU7r7t3NMPk5tQNnUEjAf1fSiEyjRJAvo10m2Kl7P7m5DGwsehPtpJS7wfjs7Vi79G5I7NryGz7c6oZ5lJho4zOJp2DsKN1ex5ufcfdijSsVSWBKbmmLdkG+9eRLTj0dfe1R4wsxSdySIbugHjJNpu7JVrl8ls10JjTt9dANL/A= Received: from BY2PR0301MB0647.namprd03.prod.outlook.com (10.160.63.14) by BY2PR0301MB0647.namprd03.prod.outlook.com (10.160.63.14) with Microsoft SMTP Server (TLS) id 15.1.409.15; Sat, 20 Feb 2016 00:52:28 +0000 Received: from BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) by BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) with mapi id 15.01.0409.017; Sat, 20 Feb 2016 00:52:28 +0000 From: Brian Raymor To: Martin Thomson Thread-Topic: [Webpush] 202 (Accepted) and simplifying acknowledgements Thread-Index: AdFrSF8gtTEETI3TT4mdvlYA58NVcwAKFmWAAABgEPA= Date: Sat, 20 Feb 2016 00:52:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2601:600:8000:5a8:ccdc:8fb0:107c:4e51] x-ms-office365-filtering-correlation-id: d724bafb-94cc-4a00-594f-08d339901b42 x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0647; 5:eXAF22f54l2qQNDrGHaO58jhbJl5COjbG2e+JTIYOLI11i8kSwaN9cTkvqNizTsBCxEsOBUmzdeYTDqpQfdRphJ2vlcrJM2qyxPQ9tsGpIxfIdqaMlMXXuk04qt2CjBWtNDvv6nnU0BbbhgABhB0gQ==; 24:+T6oFPG4HWnis+v1d6TekJm8htSv1Eo6RNA8A/h6Oufl+2ETAwSRJnzwd72rnJPtxPd6rKg6UDIyc41/ZcfeWl7C7vdzjS3GIu3DTKzNqCY= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0301MB0647; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:BY2PR0301MB0647; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0647; x-forefront-prvs: 0858FF8026 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(122556002)(76576001)(110136002)(102836003)(5001960100002)(4326007)(86362001)(1220700001)(3280700002)(586003)(5008740100001)(86612001)(1096002)(77096005)(5003600100002)(3660700001)(19580405001)(87936001)(2906002)(74316001)(6116002)(11100500001)(5002640100001)(33656002)(189998001)(54356999)(50986999)(76176999)(99286002)(10090500001)(8990500004)(5004730100002)(92566002)(10290500002)(10400500002)(5005710100001)(40100003)(19580395003)(2950100001)(2900100001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0647; H:BY2PR0301MB0647.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2016 00:52:28.2122 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0647 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] 202 (Accepted) and simplifying acknowledgements 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, 20 Feb 2016 00:52:35 -0000 T24gRnJpLCBGZWIgMTksIDIwMTYgYXQgMzo1MyBQTSwgTWFydGluIFRob21zb24gPCBtYXJ0aW4u dGhvbXNvbkBnbWFpbC5jb20gPiB3cm90ZToNCg0KPiBUaGUgcXVlc3Rpb24gaXM6IHdoYXQgd291 bGQgdGhlIDpyZWNlaXB0IGxpbmsgaWRlbnRpZnk/IA0KPGJpZyBzbmlwPg0KDQpCZXlvbmQgcmVk dWNpbmcgbW92aW5nIHBhcnRzLCB0aGVyZSBpcyByZWFsbHkgbm8gc3Vic3RhbnRpYWwgYmVoYXZp b3JhbCBkaWZmZXJlbmNlIGZyb20gdGhlIGN1cnJlbnQgOnB1c2g6cmVjZWlwdCBkZXNpZ24uIEJ1 dCBpdCdzIGJlZW4gYSBsb25nIHdlZWsgYW5kIEkgbWF5IGJlIG1pc3NpbmcgdGhlIG9idmlvdXMu DQoNClRoZSBQUyBoYXMgdGhlIHNhbWUgYW1vdW50IG9mIGluZm9ybWF0aW9uIHdoZW4gcmV0dXJu aW5nIGEgOnB1c2g6cmVjZWlwdCBhcyBiZWZvcmUsIHNpbmNlIGl0IGhhcyB0aGUgYWJpbGl0eSB0 byBtYWludGFpbiB0aGUgcmVsYXRpb25zaGlwcyAoaW1wbGljaXQgb3IgZXhwbGljaXQpIGJldHdl ZW4gYW4gaW5kaXZpZHVhbCBzdWJzY3JpcHRpb24gYW5kL29yIGEgc3Vic2NyaXB0aW9uIHNldCwg YW5kIGl0cyBjb3JyZXNwb25kaW5nIDpwdXNoIHJlc291cmNlLiBJdCBjb3VsZCByZXR1cm4gdGhl IGFwcHJvcHJpYXRlIDpwdXNoOnJlY2VpcHQgZm9yIGFsbCByZXNwb25zZXMgcmVsYXRlZCB0byBh IHNwZWNpZmljIDpwdXNoIHJlc291cmNlLg0KDQpUaGF0J3Mgd2h5IHdlJ3ZlIGFsd2F5cyBoYWQg bGFuZ3VhZ2UgdG8gcHJvdmlkZSBhIHdheSBmb3IgdGhlIEFTIHRvIGRpc2Nlcm4gYmV0d2VlbiBy ZWNlaXB0cyBhc3NvY2lhdGVkIHdpdGggZGlmZmVyZW50IG1lc3NhZ2VzOg0KDQogICBFYWNoIHJl Y2VpcHQgaXMgcHVzaGVkIGFzIHRoZSByZXNwb25zZSB0byBhIHN5bnRoZXNpemVkIEdFVCByZXF1 ZXN0DQogICBzZW50IGluIGEgUFVTSF9QUk9NSVNFLiAgVGhpcyBHRVQgcmVxdWVzdCBpcyBtYWRl IHRvIHRoZSBzYW1lIHB1c2gNCiAgIG1lc3NhZ2UgcmVzb3VyY2UgdGhhdCB3YXMgY3JlYXRlZCBi eSB0aGUgcHVzaCBzZXJ2aWNlIHdoZW4gdGhlDQogICBhcHBsaWNhdGlvbiBzZXJ2ZXIgcmVxdWVz dGVkIG1lc3NhZ2UgZGVsaXZlcnkuICANCg0KT3IgYXJlIHlvdSBwcm9wb3NpbmcgYSBuZXcgZmVh dHVyZSBhbmQgSSd2ZSBtaXNzZWQgdGhlIHBvaW50Pw0KDQouLi5Ccmlhbg0KDQoNCg0KDQoNCg== From nobody Fri Feb 19 17:44:32 2016 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 E44431B335F for ; Fri, 19 Feb 2016 17:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 S0c9TiCdzT8p for ; Fri, 19 Feb 2016 17:44:26 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0730.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 345CB1B3174 for ; Fri, 19 Feb 2016 17:44:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rHZQBy0lPGjjnX/RCev4WFr9DHFCu1wc3jG/UiUdoYI=; b=lqANTUuNW64pgN1HMbeDk5wsm247I9lEWqHDQFxqachtXIxszGOhnRBD2yFxPJxyzBjBFOaIQBr7cMWB2CIfiZta3kyNM/TmQGl3yzR6FUuhnOdh9Ii7kWJW9oyDOu+F91tvnBRyu5+jwKtBzaJGMtllYQilFUEmNiQbgzOEjys= Received: from BY2PR0301MB0647.namprd03.prod.outlook.com (10.160.63.14) by BY2PR0301MB0645.namprd03.prod.outlook.com (10.160.63.13) with Microsoft SMTP Server (TLS) id 15.1.409.15; Sat, 20 Feb 2016 01:44:04 +0000 Received: from BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) by BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) with mapi id 15.01.0409.017; Sat, 20 Feb 2016 01:44:04 +0000 From: Brian Raymor To: "webpush@ietf.org" Thread-Topic: Niceness or urgency of messages #28 Thread-Index: AdFrgAu+FvNRL8bUQpm4q78Kji7quQ== Date: Sat, 20 Feb 2016 01:44:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2601:600:8000:5a8:ccdc:8fb0:107c:4e51] x-ms-office365-filtering-correlation-id: d130eaf5-2994-44e1-a98c-08d3399750ea x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0645; 5:kiXBngGNpOULXRMgn2f/Rso/Po8mLh6EoFjLeQ3KD3oSuCTDCk6LaSeQCBHUml2CqHLCcK8dvgy7cDLoOWbJb6umZOi4sN8bmRajiHe9DKpS4jvcJQO2qOhHHPsoblO0G/ESnGV86ySX7mdEPRV7JQ==; 24:tEcAg83eUgR11j1WBmfJxcYetgieUeBLLIITtX1dadjrNKC5xLqeAouBDS7SeNDzsH6jnJ5+MiE2OBFf2GpoSpul2Sqp4UZy5GqSq+6ERDg= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0301MB0645; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR0301MB0645; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0645; x-forefront-prvs: 0858FF8026 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(50986999)(450100001)(8990500004)(10090500001)(86362001)(11100500001)(40100003)(87936001)(122556002)(86612001)(5005710100001)(74316001)(99286002)(10290500002)(229853001)(189998001)(2351001)(5004730100002)(10400500002)(5008740100001)(54356999)(76576001)(110136002)(5001960100002)(107886002)(6116002)(102836003)(586003)(5002640100001)(15975445007)(77096005)(2900100001)(3280700002)(3660700001)(92566002)(1096002)(1220700001)(558084003)(1730700002)(5003600100002)(2906002)(2501003)(33656002)(19580395003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0645; H:BY2PR0301MB0647.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2016 01:44:04.6804 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0645 Archived-At: Subject: [Webpush] Niceness or urgency of messages #28 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, 20 Feb 2016 01:44:31 -0000 I've create a first draft of changes for https://github.com/webpush-wg/webp= ush-protocol/issues/28. The pull request is available for review at - https= ://github.com/webpush-wg/webpush-protocol/pull/78 ...Brian From nobody Fri Feb 19 18:34:29 2016 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 B7B8F1B330D for ; Fri, 19 Feb 2016 18:34:28 -0800 (PST) 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 TFcml_aQ3Aju for ; Fri, 19 Feb 2016 18:34:27 -0800 (PST) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B3AF1A1A00 for ; Fri, 19 Feb 2016 18:34:27 -0800 (PST) Received: by mail-ig0-x231.google.com with SMTP id y8so52087411igp.0 for ; Fri, 19 Feb 2016 18:34:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XtltC7zTKD+xaZThrhj3TiYUVtZOWPUHEiHoCysx8ms=; b=cqXnmLerTLmJiSQUQuSbtH48RFDcyrfj0nKMPamsdLr7dwsod2SZe6NDsFD9lB1szk R/+mjdwHtEuLhIU1IVBVRPVlk/3MN5PUUcozykyHMBrSK0hpRnGQBXF26t88Zr9rNoJ/ DRT+Vz6H36K7iiny/KdDwnO7FHNxE8cEgs1wWj1NzNRnVND6Y90BHJFOlWHhvvM/1f6P 0yj+VvkBJlsteL+ld3HzG4XhfutyeofAoQ0WQf5fH5r5+GglpmSxfbus/Eknogs0M/sm oFE9O6TnC4XdG279WVJQ5Y2B6FVhA/EbYmYGireXH9x1OABjn0gAotTnIBP+dYWTtfsC sGPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XtltC7zTKD+xaZThrhj3TiYUVtZOWPUHEiHoCysx8ms=; b=PQF68FY/Ox2L/ZqzHMBdK0atPs9nSWwjEjPTwNT9TStdA5IpdNw+gYx+NvC6l1Ov2p glUR5f4bxzMNIJ0gZrzrlkre4nBDiUeIH4jes+pVxZ/lYlH1k7NM18DpkVFLDJVE3fk6 US11EexP6Ajfmsv6ORiYPUhjoedpIfVZbxBmb7WwVUkW+x++slD2mk0p1f9dKoF3c5cI jbGb4wTO91OfmcCNsvt57rJ/oG9VZcauTWnYzG1QNVo54M5vxNG1wJeLAZLES7gpdtIO UTC8uQPLnaRLDJEaDqbWHR3imo1GeWXhgey38PWrJRTzqBPhNk3PUn2s5U10Uy5Mn9iU qKMg== X-Gm-Message-State: AG10YOTeuTL4AsBnAzSI3nvVNNMRapAuS0JrN0OcQ8g9agl6gGuwBoPSiXv5E9Bvhs3mDtr1oVVPbQr75T9Anw== MIME-Version: 1.0 X-Received: by 10.50.20.73 with SMTP id l9mr287753ige.58.1455935666809; Fri, 19 Feb 2016 18:34:26 -0800 (PST) Received: by 10.36.53.79 with HTTP; Fri, 19 Feb 2016 18:34:26 -0800 (PST) In-Reply-To: References: Date: Fri, 19 Feb 2016 18:34:26 -0800 Message-ID: From: Martin Thomson To: Brian Raymor Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Niceness or urgency of messages #28 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, 20 Feb 2016 02:34:28 -0000 Thanks for putting this together Brian. I think that this would be easier to explain if the numbers were switched for tokens. Maybe: high, normal, low, super-dooper-low. (Similar values are defined for the now-defunct Priority field for mail, apart from the last). Also, I think that it might pay to note that this header field is not forwarded to user agents. On 19 February 2016 at 17:44, Brian Raymor wrote: > > I've create a first draft of changes for https://github.com/webpush-wg/webpush-protocol/issues/28. The pull request is available for review at - https://github.com/webpush-wg/webpush-protocol/pull/78 > > ...Brian > > > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush From nobody Fri Feb 19 18:41:22 2016 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 6C9D21B2FEA for ; Fri, 19 Feb 2016 18:41:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phtfkuClmjIT for ; Fri, 19 Feb 2016 18:41:19 -0800 (PST) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 830271B31A6 for ; Fri, 19 Feb 2016 18:41:19 -0800 (PST) Received: by mail-oi0-x234.google.com with SMTP id w5so24492258oie.3 for ; Fri, 19 Feb 2016 18:41:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wrRGczvafIKyienFri5/8Fc0FcLIty/yI6/I25/ZPcI=; b=mgej0IJ4LlvD3VUqnGzR4HFs0pgIpat8n3uyTcDQB1I/AVjkvS6OXSYE2gjAAt6wdr +phxQ3cqvGph4dw983oBGHr7IM4I7dTsNEUwiNe9V7+cYT+wMmao1o/DgMrQ12uLJxFV Sz7quhaG0qXpDUm/bHuCJg17yUPb7VXgRARxLfeuYosMOZbS3l7qvsmF/2Otmq8L8ajQ 1PxokJnBfev6cAcUVIRCA+KRRv3zIA+L0w2XjIj+WSusUo8q6pD50wRtAyvFJROAWGzl kPz7MbMzQjPt8MwxAtEfsilqAyAhIq1TMYS3c8f9ZEqDF+L00l8XW3evtRiFAncdTtvI 6ktw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wrRGczvafIKyienFri5/8Fc0FcLIty/yI6/I25/ZPcI=; b=dVi0sSB7G6LdQBgZ4bF66vNvjucXf7jLE8vZi02sz3RZ0PLDyUeN3MxSlKrUd3Ntqa 1by5Aks8nJ9B6UeFDmDfvU3NWYdZO3wZAEJ7yoqbUdIaLLkXJBqJVTUjjobK/FN1Fms4 CqDOzUuJZAdutJZTVsrU4dxZpGaVa9mIIs6bI2E0nbs0dHOuG2zPa13B9d/UuwcIW+jo lRycWBDZiBGoscVFovPuD2uWTxbs/7V4+r5AhhNItEKmVqHn/MUhsRbD7FHuBV26Zltz br196f7dRs/JhcSeS+0YozhdTd7x94G5FlgwzIE6MNvWIrtAdJ/TZmgwWm6TE4S1Yx3I sBpQ== X-Gm-Message-State: AG10YOS3N297zDslY7pY/IGOy2m+Bsmu3DF9jUeY0cXmya0RMImxzXn9/ahE4qajtN/KxrnlKtxuomtvRgMaKQ== MIME-Version: 1.0 X-Received: by 10.202.104.73 with SMTP id d70mr12623640oic.16.1455936078974; Fri, 19 Feb 2016 18:41:18 -0800 (PST) Received: by 10.76.75.35 with HTTP; Fri, 19 Feb 2016 18:41:18 -0800 (PST) In-Reply-To: References: Date: Sat, 20 Feb 2016 02:41:18 +0000 Message-ID: From: Costin Manolache To: Brian Raymor Content-Type: multipart/alternative; boundary=001a11409e84cd951d052c2a8832 Archived-At: Cc: Martin Thomson , "webpush@ietf.org" Subject: Re: [Webpush] 202 (Accepted) and simplifying acknowledgements 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, 20 Feb 2016 02:41:21 -0000 --001a11409e84cd951d052c2a8832 Content-Type: text/plain; charset=UTF-8 Let me try to describe the problem: 1. AS1 sends 100 push messages 2. AS2 sends another 100 push messages 3. PS returns 100 push receipt URLs for each. The question is contained in the receipt URL. The PS has no way to know which message is from AS1 and which is from AS2 - all sent messages look the same. So it must return 200 distinct push receipts. If a PS requires sender authentication - it's pretty easy, PS knows public key of AS1 and AS2, and it returns only 2 URLs, one for AS1 and one for AS2, than 2 GET requests are made and AS1 and AS2 each get their 100 receipts. So in GCM case - everything looks great. If a PS doesn't require authentication - you need some other way to know that messages are sent from AS1 or AS2. This is similar with the subscription set on the UA side - where the UA starts by creating a subscription set, and than each subscription is associated with the set. We could be symmetrical, and just let AS create a 'subscription set' for itself, and have each send include the set. This would act like the public key - but have shorter life and be more private. Costin On Sat, Feb 20, 2016 at 12:52 AM, Brian Raymor wrote: > On Fri, Feb 19, 2016 at 3:53 PM, Martin Thomson < martin.thomson@gmail.com > > wrote: > > > The question is: what would the :receipt link identify? > > > Beyond reducing moving parts, there is really no substantial behavioral > difference from the current :push:receipt design. But it's been a long week > and I may be missing the obvious. > > The PS has the same amount of information when returning a :push:receipt > as before, since it has the ability to maintain the relationships (implicit > or explicit) between an individual subscription and/or a subscription set, > and its corresponding :push resource. It could return the appropriate > :push:receipt for all responses related to a specific :push resource. > > That's why we've always had language to provide a way for the AS to > discern between receipts associated with different messages: > > Each receipt is pushed as the response to a synthesized GET request > sent in a PUSH_PROMISE. This GET request is made to the same push > message resource that was created by the push service when the > application server requested message delivery. > > Or are you proposing a new feature and I've missed the point? > > ...Brian > > > > > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > --001a11409e84cd951d052c2a8832 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Let me try to describe the problem:
1. AS1 sends 100 p= ush messages
2. AS2 sends another 100 push messages
3. = PS returns 100 push receipt URLs for each.

The que= stion is contained in the receipt URL. The PS has no way to know which mess= age is=C2=A0
from AS1 and which is from AS2 - all sent messages l= ook the same. So it must return 200=C2=A0
distinct push receipts.= =C2=A0

If a PS requires sender authentication - it= 's pretty easy, PS knows public key of AS1 and AS2, and
it re= turns only 2 URLs, one for AS1 and one for AS2, than 2 GET requests are mad= e and AS1
and AS2 each get their 100 receipts. So in GCM case - e= verything looks great.

If a PS doesn't require= authentication - you need some other way to know that messages are sent fr= om
AS1 or AS2. This is similar with the subscription set on the U= A side - where the UA starts by creating
a subscription set, and = than each subscription is associated with the set. We could be symmetrical,= and just=C2=A0
let AS create a 'subscription set' for it= self, and have each send include the set. This would act like the=C2=A0
public key - but have shorter life and be more private.
Costin=C2=A0

On Sat, Feb 20, 2016 at 12:52 AM, Brian Raymor <Brian.Raymor@microsoft.com> wrote:
On Fri, Feb 19, 2016 at 3:53 PM, Martin Thomson= < martin.thomson@gmail.com<= /a> > wrote:

> The question is: what would the :receipt link identify?
<big snip>

Beyond reducing moving parts, there is really no substantial behavioral dif= ference from the current :push:receipt design. But it's been a long wee= k and I may be missing the obvious.

The PS has the same amount of information when returning a :push:receipt as= before, since it has the ability to maintain the relationships (implicit o= r explicit) between an individual subscription and/or a subscription set, a= nd its corresponding :push resource. It could return the appropriate :push:= receipt for all responses related to a specific :push resource.

That's why we've always had language to provide a way for the AS to= discern between receipts associated with different messages:

=C2=A0 =C2=A0Each receipt is pushed as the response to a synthesized GET re= quest
=C2=A0 =C2=A0sent in a PUSH_PROMISE.=C2=A0 This GET request is made to the = same push
=C2=A0 =C2=A0message resource that was created by the push service when the=
=C2=A0 =C2=A0application server requested message delivery.

Or are you proposing a new feature and I've missed the point?

...Brian





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

--001a11409e84cd951d052c2a8832-- From nobody Fri Feb 19 22:01:19 2016 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 D82541A6F9D for ; Fri, 19 Feb 2016 22:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 fxMeiviv_mKN for ; Fri, 19 Feb 2016 22:01:14 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0724.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::724]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83DEE1A0119 for ; Fri, 19 Feb 2016 22:01:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=L5qnrNZTGLiadMRQtkMUG7/bBz9GovSeGzL06zrAfuw=; b=F9FkF1byKnp1gc/2K3oeTYN5bJ71SkmLVmjgC84/Nev6+Ui2hHDBoxZc9gMssurAebNhbdu8HpVP+RwoGliZGtJ6oPOwIDxJ5+8LVCMYagPvQ/w4WHG/TfkXIpYeE50qkRgVI8Y/n5zy+PJ0JeeWZ3MoWJLV0DjjjKFT/gQuMz0= Received: from BY2PR0301MB0647.namprd03.prod.outlook.com (10.160.63.14) by BY2PR0301MB0648.namprd03.prod.outlook.com (10.160.63.140) with Microsoft SMTP Server (TLS) id 15.1.409.15; Sat, 20 Feb 2016 06:00:56 +0000 Received: from BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) by BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) with mapi id 15.01.0409.017; Sat, 20 Feb 2016 06:00:57 +0000 From: Brian Raymor To: Martin Thomson Thread-Topic: [Webpush] Niceness or urgency of messages #28 Thread-Index: AdFrgAu+FvNRL8bUQpm4q78Kji7quQABytgAAAZwu/A= Date: Sat, 20 Feb 2016 06:00:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2601:600:8000:5a8:ccdc:8fb0:107c:4e51] x-ms-office365-filtering-correlation-id: e19113ee-577c-49b8-e027-08d339bb3354 x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0648; 5:BH/ZivdVnsEXpTQ0MUVV691VsvABDznXeQJLHHrUrsxXIdgo4nPUqmCPoDsmjRlY8D55geczn4pCrVdR78BBIZWmD8E9woeEVLlMtpU/RhS1Dgr8YX4se9LPlAnawC9jS7ki04gbfu7NNwQdxswqOA==; 24:AxOtvx3F0A5A3T5c/HiJ4AlyxfkOL9FlD2j07vFGnV24W0L03GrYYoC/xnVfqpBFgni6nCSWPsHv5TKyCERo10+eqgh/zAEEjvY6IBQu4AQ= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0301MB0648; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR0301MB0648; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0648; x-forefront-prvs: 0858FF8026 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51444003)(24454002)(377454003)(15650500001)(5002640100001)(5003600100002)(15975445007)(76576001)(19580405001)(87936001)(5001960100002)(7110500001)(86362001)(19580395003)(74316001)(2420400007)(5008740100001)(189998001)(1096002)(92566002)(77096005)(10090500001)(99286002)(8990500004)(40100003)(4326007)(2906002)(54356999)(76176999)(10710500007)(2900100001)(5004730100002)(50986999)(33656002)(3280700002)(2950100001)(10400500002)(3660700001)(19300405004)(6116002)(5005710100001)(102836003)(586003)(122556002)(110136002)(10290500002)(1220700001)(3826002)(562404015); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0648; H:BY2PR0301MB0647.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2016 06:00:57.0208 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0648 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Niceness or urgency of messages #28 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, 20 Feb 2016 06:01:18 -0000 DQpPbiBGcmksIEZlYiAxOSwgMjAxNiBhdCA2OjM0IFBNLCBNYXJ0aW4gVGhvbXNvbiA8IG1hcnRp bi50aG9tc29uQGdtYWlsLmNvbSA+IHdyb3RlOg0KDQo+IEkgdGhpbmsgdGhhdCB0aGlzIHdvdWxk IGJlIGVhc2llciB0byBleHBsYWluIGlmIHRoZSBudW1iZXJzIHdlcmUNCj4gc3dpdGNoZWQgZm9y IHRva2Vucy4gIE1heWJlOiBoaWdoLCBub3JtYWwsIGxvdywgc3VwZXItZG9vcGVyLWxvdy4NCj4g KFNpbWlsYXIgdmFsdWVzIGFyZSBkZWZpbmVkIGZvciB0aGUgbm93LWRlZnVuY3QgUHJpb3JpdHkg ZmllbGQgZm9yDQo+IG1haWwsIGFwYXJ0IGZyb20gdGhlIGxhc3QpLg0KDQpJIHdlbnQgb2xkIHNj aG9vbCB3aXRoIC0gaHR0cDovL3Rvb2xzLmlldGYub3JnL3JmYy9yZmM1NzcudHh0IC0gd2hpY2gg d2UgY291bGQgKGFsbW9zdCkgaGF2ZSByZXVzZWQ6DQoNCiAgIE5vdyB0aGF0IEkgaGF2ZSBhcmd1 ZWQgYWxsIHRoYXQsIGxldCBtZSBzdWdnZXN0IGludGVycHJldGF0aW9ucyBmb3INCiAgIHVyZ2Vu Y3kgdmFsdWVzLiAgVGhpcyBpcyBzbyB0aGF0IHByb2dyYW1tZXJzIGNhbiBoYXZlIGF1dG9tYXRh LQ0KICAgZ2VuZXJhdGVkIG1haWwgKGUuZy4sIG5vdGlmaWNhdGlvbiBvZiB0aGUgc3RhdHVzIG9m IHByZXZpb3VzbHkgc2VudA0KICAgbWFpbCkgY2FycnkgcmVhc29uYWJsZSB1cmdlbmN5IHZhbHVl czoNCg0KICAgICAgMTAgIFBob25lIGluIHRoZSBtaWRkbGUgb2YgdGhlIG5pZ2h0LCBpZiBuZWNl c3NhcnkuDQogICAgICAgOQ0KICAgICAgIDggIERlbGl2ZXIgdG8gdXNlcidzIHRlcm1pbmFsIE5P Vy4NCiAgICAgICA3DQogICAgICAgNiAgRGVsaXZlciB0byB1c2VyJ3MgdGVybWluYWwgb25seSBp ZiB1c2VyIGlzIGF0ICJleGVjIg0KICAgICAgICAgIGxldmVsLg0KICAgICAgIDUNCiAgICAgICA0 ICBEZWxpdmVyIGltbWVkaWF0ZWx5IGFmdGVyIHNpZ24tb24gb3IgYmVmb3JlIHNpZ24tb2ZmLg0K ICAgICAgIDMNCiAgICAgICAyICBEZWxpdmVyIGludG8gc3RhbmRhcmQgbWFpbGJveC4NCiAgICAg ICAxDQogICAgICAgMCAgSnVuayBNYWlsDQoNCkkgcmVhbGx5IGxvdmUgIlBob25lIGluIHRoZSBt aWRkbGUgb2YgdGhlIG5pZ2h0IC4uLiIuIEkgd291bGQgYWxzbyBwcmVmZXIgc3RyaW5ncyBmb3IN CnNlbGYtZG9jdW1lbnRhdGlvbiwgYnV0IHdhcyBjb25jZXJuZWQgYWJvdXQgdGhlIHBvdGVudGlh bCBsYWNrIG9mIGNsYXJpdHkgcmVsYXRlZA0KdG8gb3JkZXJpbmcgaW4gc3RhdGVtZW50cyBzdWNo IGFzOg0KDQogICBUaGUgcHVzaCBzZXJ2aWNlIE1VU1Qgb25seSBkZWxpdmVyIG1lc3NhZ2VzIHdp dGggYW4gdXJnZW5jeSAqZ3JlYXRlciB0aGFuDQogICBvciBlcXVhbCB0byogdGhlIHZhbHVlIG9m IHRoZSBoZWFkZXIgZmllbGQuDQoNCkkgYWxzbyBleHBsb3JlZCBzaW1pbGFyIHVzZSBjYXNlcyBh bmQgbm90ZWQgdGhhdCB0aGUgU0lQIHByaW9yaXR5IGhlYWRlciBmaWVsZA0KcmVnaXN0ZXJlZCB2 YWx1ZXM6DQoNCiAgImVtZXJnZW5jeSIgfCAidXJnZW50IiB8ICJub3JtYWwiIHwgIm5vbi11cmdl bnQiIA0KDQogICAgaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9zaXAtcGFyYW1ldGVy cy9zaXAtcGFyYW1ldGVycy54aHRtbCNzaXAtcGFyYW1ldGVycy03Mw0KDQpidXQgdGhpcyBwcm92 b2tlZCBzaW1pbGFyIGNvbmNlcm5zIGFib3V0IHRoZSBuZWVkIGZvciAiZXhwbGljaXQgc3RhdGVt ZW50W3NdIGFib3V0IHRoZSBvcmRlcmluZyBvZiB0aGVzZSB2YWx1ZXMiIGFuZDoNCg0KICAgICJU aGlzIGNvbnN0YW50IHVzZSBvZiBzcGVjaWZpYyBFbmdsaXNoIHdvcmRzIHJhdGhlciB0aGFuIG51 bWVyaWMgdmFsdWVzIGlzIA0KICAgIGNhdXNpbmcgdGhlIHByb3RvY29sIGFuZCBpdHMgcHJvY2Vz c2luZyB0byBiZWNvbWUgbGVzcyBlZmZpY2llbnQgYW5kIGlzIA0KICAgIGxlYWRpbmcgdG8gY29t cGxpY2F0aW9ucyBpbiB0aGUgZGVmaW5pdGlvbiAuLi4iDQoNCiAgICAgaHR0cDovL3d3dy5pZXRm Lm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NpcC9jdXJyZW50L21zZzAxNDQxLmh0bWwNCg0KVW5mb3J0 dW5hdGVseSwgSSBjb3VsZCBub3QgZmluZCBhIHJlc3BvbnNlIGZvciB0aGUgcmVzdCBvZiB0aGUg ZGlzY3Vzc2lvbi4gSSdtIGRlZmluaXRlbHkgb3BlbiB0byBzdWdnZXN0aW9ucyBhYm91dCB0aGUg YmVzdCB3YXkgdG8gZW5zdXJlIHRoYXQgdGhpcyBpcyBjbGVhciB0byBpbXBsZW1lbnRlcnMuDQoN Cj4gQWxzbywgSSB0aGluayB0aGF0IGl0IG1pZ2h0IHBheSB0byBub3RlIHRoYXQgdGhpcyBoZWFk ZXIgZmllbGQgaXMgbm90DQo+IGZvcndhcmRlZCB0byB1c2VyIGFnZW50cy4NCg0KR29vZCBwb2lu dC4gSSdsbCBpbmNsdWRlIHRoYXQgaW4gdGhlIG5leHQgY29tbWl0Lg0KDQoNCg== From nobody Fri Feb 19 22:48:13 2016 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 97EC81B38F2 for ; Fri, 19 Feb 2016 22:48:11 -0800 (PST) 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 L-I99kUe62RZ for ; Fri, 19 Feb 2016 22:48:10 -0800 (PST) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDB531B3953 for ; Fri, 19 Feb 2016 22:48:09 -0800 (PST) Received: by mail-io0-x235.google.com with SMTP id 9so131867350iom.1 for ; Fri, 19 Feb 2016 22:48:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6Fz7ySUTJghJNinbtctTS0L9oE1HiDos3VY36ViJt2o=; b=05hQv1cHN0k8aNqaMGFrPSkFu81JLhngoZSV5/TtSl+EWqwrxHoxgxMikvraRghdRR WAID4esOh5X2WEgZ/6IX5Phu16JPszA5/ztKcVD/ZViNP53SmwmIWE9kJyNwjKy2aPVH kybaEDmJxkIonVBhMPaiDjcvXwKxW1vvDTgbWBAEpLZOG1YxZ6TUPRwT0I/AvYweJEtm x/tOSAMND1ypjkmXsCluWdgHZ4OoD7yjHvJfDCTXa/MY8zGs4lyZ3cZjK7BMzfPybTGb H9E+fno3m6fUJxhh0D8Gj1eciLdsVBvhLF/ZU7e3jNZ9fsKW6EdVaH+W0TEdoSzaSp+z kmBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6Fz7ySUTJghJNinbtctTS0L9oE1HiDos3VY36ViJt2o=; b=ZqBp/nGekZT3ADLxUnDriq3087iOZHeEYMkVunboz9bJ5u5Lwnf9LIMZcJjR+0aT5P Eg5i20KK+tL8jXkZ76huOswhIeC8Y3YnWK5gr6xXsJGsiUW45Vz6mgS85nEZERaXKqAf 2BzVM1bpBMkOxP9PukCUr8qfkmw5vxXrZ4PnOheCQenlxDZ0rJX4QAohibrefYogIi3H JwG2wKTb8pNqgaA3bfVN/bY4fHUH9l9bEI6v3+QRLZgRyVj1mPdpgRCapa0BStTiic5/ +abThPdMuoMYfGoRY+lfDpmlZlN5DwgpOgtmICTINfx3Jl7e8jFUGhAmLvZw7VTDosR8 rYkQ== X-Gm-Message-State: AG10YORlcY7BeR/yxpPAivfV5lhH4sqX70YGMTOjmFtEm5lFkBosH/q+ww6gJyte2/T9XXJblQkHQYxk4CaDQg== MIME-Version: 1.0 X-Received: by 10.107.41.133 with SMTP id p127mr6097395iop.100.1455950889291; Fri, 19 Feb 2016 22:48:09 -0800 (PST) Received: by 10.36.53.79 with HTTP; Fri, 19 Feb 2016 22:48:09 -0800 (PST) In-Reply-To: References: Date: Fri, 19 Feb 2016 22:48:09 -0800 Message-ID: From: Martin Thomson To: Brian Raymor Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Niceness or urgency of messages #28 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, 20 Feb 2016 06:48:11 -0000 Ordering is easy: define the order. On 19 February 2016 at 22:00, Brian Raymor wrote: > but this provoked similar concerns about the need for "explicit statement[s] about the ordering of these values" and: > > "This constant use of specific English words rather than numeric values is > causing the protocol and its processing to become less efficient and is > leading to complications in the definition ..." > > http://www.ietf.org/mail-archive/web/sip/current/msg01441.html > > Unfortunately, I could not find a response for the rest of the discussion. I'm definitely open to suggestions about the best way to ensure that this is clear to implementers. That is usually a sign that the mail was not taken seriously. We use string-based enumerations all the time today. They have great extensibility properties, they read well (though mostly for English speakers, I will conceded), and they don't cost any significant amount to implement. From nobody Sat Feb 20 08:59:26 2016 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 17D871A9053 for ; Sat, 20 Feb 2016 08:59:25 -0800 (PST) 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 z8kn0Nqk0wbt for ; Sat, 20 Feb 2016 08:59:23 -0800 (PST) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 645031A9056 for ; Sat, 20 Feb 2016 08:59:23 -0800 (PST) Received: by mail-oi0-x236.google.com with SMTP id j125so31863632oih.0 for ; Sat, 20 Feb 2016 08:59:23 -0800 (PST) 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=JaLKdh9Xah0k4wFjx6hPR5xIl7OZPKYSj4HVIVob/VA=; b=cQ+8aeU543PqhPAacsIxgz9tBj/ggU4GyrcFOInb3L1U4mkl/86+U8o0kojr3pARTE lFWPU/s/CtlNFT09iDBlLzHWnET/uxC9tqhNzg6w9mIKeeK22rmIoULaWm8HzOWBPrsL a9i9KiyyhfSZmyqHpca2W2EhiKNenCQLLqX9zeNW8u4RuRZHG2aYbF8E/rWSs8pisjbh geqXcBnfHrO9KKQltS2jF5IQmxtlQ1nJjdWnlgPF68diKXr6h3Tt+65JZ2TDOqMRLyO4 uiKiPoKRiSc4bRT6Ju9IQgJgdxQ6IxIE4Iqm50l/EcsQSss0AK2s6Zlm0dqafjME63rj 3WxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=JaLKdh9Xah0k4wFjx6hPR5xIl7OZPKYSj4HVIVob/VA=; b=ANZp0sFVgosIUNdD2wIZ30Or69m3yOaBpa9wTjmV8d+u0LWXrETt4tvNJd9gn1GUSb XaLx0JMa+pU6Gx1rksgpyaHY1y9dpgiHwX+PoODTGpoEkSNcO0wNxcPAR75oE7YY8p+I kF+kflOekGa4xzqA4Q8qd2KfePMASPQSsIeY0BDwumRVqMQjXbqgXMyE+uJk1ikB2OIb Cm3vt7tTJDlTVaWdGl7G9el+4Tq5vJHDlC/2p7K4jc/g+VqIHhslz+gu4OMusVBuYX3N PHfCd4NDNLGIs7fCsq1jW9ZVx+LedSDmpDSUEO3Ml+6qZWQvwQEE1BXJhqay37URK0PP dVQg== X-Gm-Message-State: AG10YOSC01TDC+aKyP9crxsxTFpr8AjW31T7iXlHx9cbaUvVdk+jSF6irsJIKL/CFLJbiSMb3ougohWmkjTojg== MIME-Version: 1.0 X-Received: by 10.202.215.137 with SMTP id o131mr15959408oig.6.1455987562732; Sat, 20 Feb 2016 08:59:22 -0800 (PST) Received: by 10.76.75.35 with HTTP; Sat, 20 Feb 2016 08:59:22 -0800 (PST) Date: Sat, 20 Feb 2016 16:59:22 +0000 Message-ID: From: Costin Manolache To: "webpush@ietf.org" Content-Type: multipart/alternative; boundary=001a113d54f8796301052c36857f Archived-At: Subject: [Webpush] Alternate/fallback mechanism for receiving 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, 20 Feb 2016 16:59:25 -0000 --001a113d54f8796301052c36857f Content-Type: text/plain; charset=UTF-8 Hi, I know this may be a bit controversial, and I love both HTTP/2 and push promises :-) However, to make it easier to implement/test/deploy, would it be possible to add a small change to sections 7, 7.1 and 7.3: 'if http/2 or push promises are not supported on a platform, the PS will return a mime-multipart response to the GET request, with the same content as the push promise' Nothing else needs to be changed - just instead of a push promise frame, it will be a mime part. A UA or PS can support only http/2 - but some may optionally also support the multipart response, and accept requests as http/1.1. While many HTTP/2 stacks are now available, the APIs for push promises are not very familiar or well exposed. This is a problem in particular for receipts, since the AS to PS communication has to be implemented by many developers. It will also help in the case of UA to PS, low-end IOT devices tend to lack http/2 support. Costin --001a113d54f8796301052c36857f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I know this may be a bit controvers= ial, and I love both HTTP/2 and push promises :-)

= However, to make it easier to implement/test/deploy, would it be possible t= o add a small=C2=A0
change to sections 7, 7.1 and 7.3:
=
'if http/2 or push promises are not supported on a platf= orm, the PS will return =C2=A0
a mime-multipart response to the G= ET request, with the same content as the push promise'

Nothing else needs to be changed - just instead of a push promise = frame, it will be a mime part.
A UA or PS can support only http/2= - but some may optionally also support the multipart=C2=A0
respo= nse, and accept requests as http/1.1. =C2=A0

While= many HTTP/2 stacks are now available, the APIs for push promises are not v= ery familiar
or well exposed.=C2=A0

This= is a problem in particular for receipts, since the AS to PS communication = has to be implemented
by many developers. It will also help in th= e case of UA to PS, low-end IOT devices tend to lack=C2=A0
http/2= support.=C2=A0

Costin

--001a113d54f8796301052c36857f-- From nobody Sat Feb 20 16:02:55 2016 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 E22181B2BEE for ; Sat, 20 Feb 2016 16:02:53 -0800 (PST) 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 YBboND6VcuCL for ; Sat, 20 Feb 2016 16:02:52 -0800 (PST) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 885101B2BED for ; Sat, 20 Feb 2016 16:02:52 -0800 (PST) Received: by mail-ig0-x230.google.com with SMTP id xg9so56930837igb.1 for ; Sat, 20 Feb 2016 16:02:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=THLIN8ER4xBXrvJ2qNSrmdUEnEYqZ9NWIkRC+QEnUoE=; b=FkkzzPBNEPIVqcxalYoKXr+yPbQWmUAA5OSyRZIsqyWvpEmzhSkm8rQ9BSgYwrXHlx O4ty3DY8rJRjUJq94YEI9K7Q3uekNIpPs2oJCEArCbA1obDG/ZJSJ3xwvrcE48s+naOb w00Be1q6hYsz6cAOQFAlxhig3Xb/q1S1hCfdpnzkGPWOl7pfU1SyMH4XzpY0fV9XTqQp V824gSI6RuZ06/rGqSHf2wBG27iFjw3Ns2adSDW5WOgj5QQb0gD4Oq3f1QLMciySZspf fm4hNFapQUn0LazCXJcDJuDU3+NBER6O+mEAj8s7YJrpAIjscyUL339QVrGRghJLwjPi P/5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=THLIN8ER4xBXrvJ2qNSrmdUEnEYqZ9NWIkRC+QEnUoE=; b=KOC695JW0CMQRdN3392+4nwD7X1PnjS4Gyhn8q05eN20g0v/CUnDinqztuCEKF4PSx 2E2yU5zdqUW/oN0My8FT7j/8eB+4n2KtIMrOtiIMEO0+LH48HVyA4DEzQebUGIvLjvuN eub+w2Am4N5tbP/vvQVzpwvsdEJ4wauvBIhDlmqOSF5ObhMzi0TlCDZXjE7ws6lPzkkY Q5Es0936qSYBG1+rmfgsQ2cAApKoW0OXPwLMdv9p35YthfLIgdpLgJKiOzoh7B2nwQJt SKQPpo7kBEdWsJIW/ySEAJEiC/BHv2X+cziCVlJeYqvZylke3Nv2D/DFfXwxwbHkD0mi y56w== X-Gm-Message-State: AG10YOTz0FThtqZ1tgPu21Qb/88iWWRGCizQiobwoaPTz+i8/eT1FTqebF3KRaXwqOoL+sKyAkIN7C8m6/MQnA== MIME-Version: 1.0 X-Received: by 10.50.6.104 with SMTP id z8mr4238614igz.58.1456012971969; Sat, 20 Feb 2016 16:02:51 -0800 (PST) Received: by 10.36.53.79 with HTTP; Sat, 20 Feb 2016 16:02:51 -0800 (PST) In-Reply-To: References: Date: Sat, 20 Feb 2016 16:02:51 -0800 Message-ID: From: Martin Thomson To: Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Alternate/fallback mechanism for receiving 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: Sun, 21 Feb 2016 00:02:54 -0000 Why not just implement a proprietary protocol? On 20 February 2016 at 08:59, Costin Manolache wrote: > Hi, > > I know this may be a bit controversial, and I love both HTTP/2 and push > promises :-) > > However, to make it easier to implement/test/deploy, would it be possible to > add a small > change to sections 7, 7.1 and 7.3: > > 'if http/2 or push promises are not supported on a platform, the PS will > return > a mime-multipart response to the GET request, with the same content as the > push promise' > > Nothing else needs to be changed - just instead of a push promise frame, it > will be a mime part. > A UA or PS can support only http/2 - but some may optionally also support > the multipart > response, and accept requests as http/1.1. > > While many HTTP/2 stacks are now available, the APIs for push promises are > not very familiar > or well exposed. > > This is a problem in particular for receipts, since the AS to PS > communication has to be implemented > by many developers. It will also help in the case of UA to PS, low-end IOT > devices tend to lack > http/2 support. > > Costin > > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > From nobody Sat Feb 20 19:22:47 2016 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 836B61B2F07 for ; Sat, 20 Feb 2016 19:22:46 -0800 (PST) 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 Zze9A_ASSOqI for ; Sat, 20 Feb 2016 19:22:44 -0800 (PST) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73B401B2F05 for ; Sat, 20 Feb 2016 19:22:44 -0800 (PST) Received: by mail-ob0-x22d.google.com with SMTP id xk3so141894821obc.2 for ; Sat, 20 Feb 2016 19:22:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bbzEvHI0BTPyGLXOIhDRmD56lmTMz2IN3hztm3KwUxE=; b=Y2iIzV5iIO03xL7+F8vcBBK+mjey5pDMbhUvaPlUhKy7Lm/1EQUqC7O/PuTkLdpEYR csVA1rHHW+cqtYbTX6c2NYIQ8z1/02oNxcy4P3Eu89YBlcDGVJgA2Wakug/5M8kL1pNX 36tVK2ZOpig9LLjAh+JjuECDXoDIfGD8xjWFLsx9D1kR4Zy6XXNVA7VqnUiLzLtwwQT0 bbjAXbn1rlriLtzX/quHlcYU4je00k22ipkR/lzzKa7XVz/wQyzn8byo3U23wqHpcywv cn2TNYsa62YfaiVx1xJc1VDnDEuCpF6HnQMzZiVLZtMO1uJy4c1KewPfPbzjGIc69o52 Vj9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bbzEvHI0BTPyGLXOIhDRmD56lmTMz2IN3hztm3KwUxE=; b=Z3SfLqmJqumIyRlODfnP59tS5kkwnN0PoDiRHVodjBRe+3/zdDsjA1k8UAZZ8Acb/h E2x62uL6zu/S7v3Ymqrhxsb9WqctmbwA0EJk8l8ggA/lzhzXh4Wq7BCq9VNI1MG6SmG8 B52PQ65XCBGX5anjSJ+PMNZYA288pDn4EMUC4wOasXTuHNxij107E0XXXOqkImOaHC7X i3fGa5go2jHY3fb5bqICKFYi2r+i2pckMcd1ZoVCH1Q0GnY4y4PmMpWQV/FPxzaeGZyW CEcCTbMmkmzewxDXGR2MQgP8rIfSfYliVpECxerHTNgCSTRFhcMw12zNMuDKMWH+UpPq +E9g== X-Gm-Message-State: AG10YORPxVR1JSggivccBkQTVUUPIgFyZmjSqaKJ6ehhrkgFSUeKwG5d6yYQWzw5MFoyesYN6YpSa0j592DojQ== MIME-Version: 1.0 X-Received: by 10.60.226.134 with SMTP id rs6mr18248478oec.69.1456024963833; Sat, 20 Feb 2016 19:22:43 -0800 (PST) Received: by 10.76.75.35 with HTTP; Sat, 20 Feb 2016 19:22:43 -0800 (PST) In-Reply-To: References: Date: Sun, 21 Feb 2016 03:22:43 +0000 Message-ID: From: Costin Manolache To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1136a220c0e6c1052c3f3a44 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Alternate/fallback mechanism for receiving 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: Sun, 21 Feb 2016 03:22:46 -0000 --001a1136a220c0e6c1052c3f3a44 Content-Type: text/plain; charset=UTF-8 We already implement an alternate protocol for receipts - based on XMPP, so not even 'proprietary' :-) The benefit of having a fallback in webpush standard is that it makes it easier for AS to adopt - it is a small extra effort for the PS, but big benefit for many AS. Compatibility with existing infrastructure - and backward compatibility in general - are good for any protocol. Webpush sending is defined as HTTP/1.1, subscription and delete are HTTP/1.1 compatible - it's only receipts that require push promises, with no backward option. Does anyone have a survey of platforms and APIs supporting push promises ? Most that I know require custom HTTP implementations, even the library/platform supports HTTP/2, promises are not usually exposed and/or well documented/understood. Costin On Sun, Feb 21, 2016 at 12:02 AM, Martin Thomson wrote: > Why not just implement a proprietary protocol? > > On 20 February 2016 at 08:59, Costin Manolache wrote: > > Hi, > > > > I know this may be a bit controversial, and I love both HTTP/2 and push > > promises :-) > > > > However, to make it easier to implement/test/deploy, would it be > possible to > > add a small > > change to sections 7, 7.1 and 7.3: > > > > 'if http/2 or push promises are not supported on a platform, the PS will > > return > > a mime-multipart response to the GET request, with the same content as > the > > push promise' > > > > Nothing else needs to be changed - just instead of a push promise frame, > it > > will be a mime part. > > A UA or PS can support only http/2 - but some may optionally also support > > the multipart > > response, and accept requests as http/1.1. > > > > While many HTTP/2 stacks are now available, the APIs for push promises > are > > not very familiar > > or well exposed. > > > > This is a problem in particular for receipts, since the AS to PS > > communication has to be implemented > > by many developers. It will also help in the case of UA to PS, low-end > IOT > > devices tend to lack > > http/2 support. > > > > Costin > > > > > > _______________________________________________ > > Webpush mailing list > > Webpush@ietf.org > > https://www.ietf.org/mailman/listinfo/webpush > > > --001a1136a220c0e6c1052c3f3a44 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We already implement an alternate protocol for receipts - = based on XMPP,
so not even 'proprietary' :-)

The benefit of having a fallback in webpush standard is that it make= s it easier=C2=A0
for AS to adopt - it is a small extra effort fo= r the PS, but big benefit for many AS.
Compatibility with existin= g infrastructure - and backward compatibility in general -
are go= od for any protocol. Webpush sending is defined as HTTP/1.1, subscription a= nd
=C2=A0delete are HTTP/1.1 compatible - it's only receipts = that require push promises, with=C2=A0
no backward option.=C2=A0<= /div>

Does anyone have a survey of platforms and APIs su= pporting push promises ?=C2=A0
Most that I know require custom HT= TP implementations, even the library/platform
supports HTTP/2, pr= omises are not usually exposed and/or well documented/understood.

Costin
=C2=A0

On Sun, Feb 21, 2016 at 12:02 AM, Martin = Thomson <martin.thomson@gmail.com> wrote:
Why not just implement a proprietary protocol?

On 20 February 2016 at 08:59, Costin Manolache <costin@gmail.com> wrote:
> Hi,
>
> I know this may be a bit controversial, and I love both HTTP/2 and pus= h
> promises :-)
>
> However, to make it easier to implement/test/deploy, would it be possi= ble to
> add a small
> change to sections 7, 7.1 and 7.3:
>
> 'if http/2 or push promises are not supported on a platform, the P= S will
> return
> a mime-multipart response to the GET request, with the same content as= the
> push promise'
>
> Nothing else needs to be changed - just instead of a push promise fram= e, it
> will be a mime part.
> A UA or PS can support only http/2 - but some may optionally also supp= ort
> the multipart
> response, and accept requests as http/1.1.
>
> While many HTTP/2 stacks are now available, the APIs for push promises= are
> not very familiar
> or well exposed.
>
> This is a problem in particular for receipts, since the AS to PS
> communication has to be implemented
> by many developers. It will also help in the case of UA to PS, low-end= IOT
> devices tend to lack
> http/2 support.
>
> Costin
>
>
> _______________________________________________
> Webpush mailing list
> Webpush@ietf.org
> https://www.ietf.org/mailman/listinfo/webpush<= br> >

--001a1136a220c0e6c1052c3f3a44-- From nobody Sat Feb 20 21:18:03 2016 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 F0FC61B2F96 for ; Sat, 20 Feb 2016 21:18:01 -0800 (PST) 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 EhIQov0N6y5E for ; Sat, 20 Feb 2016 21:18:00 -0800 (PST) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 764C61B2EBC for ; Sat, 20 Feb 2016 21:18:00 -0800 (PST) Received: by mail-io0-x232.google.com with SMTP id g203so147797507iof.2 for ; Sat, 20 Feb 2016 21:18:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/o0GdFVtB79AnZrSnOMceQLSaFh7AwrdQuL+X4JQVmY=; b=ONtodSkX9hPz1rP5J68E8r/5njYihb12lPo1+Svb3dBS8HACPYTUuTDTNitwz4dtly ARgBk2wIcFsP0V/1Y7wQGoh9lx0Jh6cAGAAZppsbseOZqyo52osgZ4sSlGZxuBXLzOkm vW1HgBCd34BZJuXsOXx1lCjA3FHmkuOI+5fx5WCx/ASC4ZOOvs9SO0LqseuK0fp8X+uj yL9U1ekVtCmC5tSjlbK4UgzOl03IUf+C55RMTUy/isR2qagy0xsaeamem54hExG5Dtb2 vv3RTg8o4UaL98FlphbR1m/4dvqoERGr2n8cRP+CbSlCpVBEShfTlRQGC341ClB2AjLL JDmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/o0GdFVtB79AnZrSnOMceQLSaFh7AwrdQuL+X4JQVmY=; b=S0Uc2fo4fk4d34ltRKkitD/vkFXJqQdbkGTmUL0zMtzgDdPtHUOnZq3wVvglASYzGp lhCRnLGpbf6Qmu6sRmVH8pCahFPJLiOWgycCOWtAydfSk/GK4FXQTJY8rIEJ5b7woAh7 GNgGfvnhIavqQwRhW0s8hcqBj7+We45ue4Aka1p2WRXEV0FGJ0KI8xwI0/liCWSJAL4F vZbAza2fOqXdb69j0BIAyoVZ27qLreJ4ogY801dAAZG/Z6F8tQTx4jSXp9cRgwEv3OB9 UWF9IqXkI740WH9z0vn7y4VZx8hGYhxe1tyJix2xB4VB/WW2sQPZcrzsG/LMx94CfmFR JK8w== X-Gm-Message-State: AG10YOTQ1q/lM1TeVIWmBM33xZ4HTYYg3dLg7La46gsDTY09aXm6V6gYIXHADUIMQHvrmcOuDY/c/BPPlmHCYw== MIME-Version: 1.0 X-Received: by 10.107.34.139 with SMTP id i133mr20351267ioi.108.1456031879844; Sat, 20 Feb 2016 21:17:59 -0800 (PST) Received: by 10.36.53.79 with HTTP; Sat, 20 Feb 2016 21:17:59 -0800 (PST) In-Reply-To: References: Date: Sat, 20 Feb 2016 21:17:59 -0800 Message-ID: From: Martin Thomson To: Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Alternate/fallback mechanism for receiving 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: Sun, 21 Feb 2016 05:18:02 -0000 On 20 February 2016 at 19:22, Costin Manolache wrote: > Does anyone have a survey of platforms and APIs supporting push promises ? Firefox has an API, though that is still pretty-much internal. nghttp2 has an API: https://www.nghttp2.org/documentation/types.html#c.nghttp2_on_begin_headers_callback I'm not opposed to someone defining a fallback, but I think that it would be better written as a separate document, because it isn't as simple to do as what you describe by a long stretch. From nobody Sat Feb 20 23:48:04 2016 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 9F1281B3529 for ; Sat, 20 Feb 2016 23:48:03 -0800 (PST) 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 ovRhzZ6a-m4r for ; Sat, 20 Feb 2016 23:48:02 -0800 (PST) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D34C91B3528 for ; Sat, 20 Feb 2016 23:48:01 -0800 (PST) Received: by mail-oi0-x232.google.com with SMTP id x21so37713927oix.2 for ; Sat, 20 Feb 2016 23:48:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OHTYVZPiUlKNgh0bl3gLtIzX24X+gsJHvbLy5R3Ji7U=; b=rLx6ajZiGrLyMv/Nv/MoVJfN0QvRBhV7XVHPRfRfCyyhKdvzhn7YnSIr0FAaAhkz0N QDa/ask2YoaRbJDgs00I+hdIRQRm6vNagUNdo4tnyfnTqyrGLckfG9zeBmzxzPeSTfOv eNalEIhcH73imhcaquSwD4n/xtrI8frEYj7wUeHjkRY3E8jt4Bs7bR4AO52N9Jz8lV9/ pO9g9oRLkRZF5yD/oLW5GB91nbRFvy4ORM4pGoV+38kkBRPXWtr3yxS3p29LCpv7+0BK +fWm5fzYnV4NycUMIBIKA5BagNQHOL2kIYeys9C9idd5Sk74vwfGWRJhzzhqaZPxt2RV MDgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OHTYVZPiUlKNgh0bl3gLtIzX24X+gsJHvbLy5R3Ji7U=; b=YIDtoYmWobHmnBfM6sDoxdDj7sQMpONN8r5l57tSlkGcwAxN/deYUKaQG7c4cRKNR1 xMzFaOpifkyYnB2lwUoll9SenybAu1EHlHNQuHf3YxtI2mjxWVBVjOH47dkcPf3FU8O/ lLu8iZ6G74fGfyuSV6IdUt/EG+M+RvHfMQq5idHsPthREXolyr6473xZtCJrdCAu9Vd1 T2Oq8pRcd7tNc+N3B1DBZhmyBrSSxJk7f5U81bqAodh/vsV56cGkXZNsJ6gNa9auerek dZLJclOViX71bWnYMds/+cVxgjyhYu4lbemPfaRppEgavMWiZKb3JJyS8oeAsHCqg2hF dzVw== X-Gm-Message-State: AG10YOSSG0xwm1A+qubOS63TAFrjpT9yNao/Kia7PCc32k6hcG8XeJqgsUuGpOyF7VsVZUwXW2KCC19u0rr8SQ== MIME-Version: 1.0 X-Received: by 10.202.49.88 with SMTP id x85mr15922394oix.123.1456040881299; Sat, 20 Feb 2016 23:48:01 -0800 (PST) Received: by 10.76.75.35 with HTTP; Sat, 20 Feb 2016 23:48:01 -0800 (PST) In-Reply-To: References: Date: Sat, 20 Feb 2016 23:48:01 -0800 Message-ID: From: Costin Manolache To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113bd248822834052c42ef10 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Alternate/fallback mechanism for receiving 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: Sun, 21 Feb 2016 07:48:03 -0000 --001a113bd248822834052c42ef10 Content-Type: text/plain; charset=UTF-8 On Sat, Feb 20, 2016 at 9:17 PM, Martin Thomson wrote: > On 20 February 2016 at 19:22, Costin Manolache wrote: > > Does anyone have a survey of platforms and APIs supporting push promises > ? > > Firefox has an API, though that is still pretty-much internal. > > nghttp2 has an API: > > https://www.nghttp2.org/documentation/types.html#c.nghttp2_on_begin_headers_callback > > I'm not opposed to someone defining a fallback, but I think that it > would be better written as a separate document, because it isn't as > simple to do as what you describe by a long stretch. > Push message delivery is defined as 'http' - and that's what most developers will do. I'm ok with a separate document - and my main concern is delivery receipts, since that's the only point AS developers are required to use low level http2 APIs. Most implementations I found so far are low level, similar with nghttp2 - or 'pretty-much internal'. Getting receipts is a GET request - it seems natural to return the receipts as body if promises are not available - json or any other format would be fine too. Costin --001a113bd248822834052c42ef10 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Feb 20, 2016 at 9:17 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
On 20 February 2016 at 19:22, Costin Manolache <costin@gmail.com> wrote:
> Does anyone have a survey of platforms and APIs supporting push promis= es ?

Firefox has an API, though that is still pretty-much internal.

nghttp2 has an API:
https://www.nght= tp2.org/documentation/types.html#c.nghttp2_on_begin_headers_callback
I'm not opposed to someone defining a fallback, but I think that it
would be better written as a separate document, because it isn't as
simple to do as what you describe by a long stretch.

Push message delivery is defined as 'http' - and that= 's what most developers will=C2=A0
do.<= /div>

I'= m ok with a separate document - and my main concern is delivery receipts, s= ince=C2=A0
that's the only point AS dev= elopers are required to use low level http2 APIs.=C2=A0
Most implementations I found so far are low level, similar wit= h nghttp2 - or 'pretty-much internal'.

Getting receipts is a GET request = - it seems natural to return the receipts as body if promises are=C2=A0
not available - json or any other format would= be fine too.

Costin


--001a113bd248822834052c42ef10-- From nobody Sun Feb 21 12:03:40 2016 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 514861A8FD5 for ; Sun, 21 Feb 2016 12:03:39 -0800 (PST) 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 Iv9PtlviLK99 for ; Sun, 21 Feb 2016 12:03:38 -0800 (PST) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 106181A9152 for ; Sun, 21 Feb 2016 12:03:37 -0800 (PST) Received: by mail-ig0-x22b.google.com with SMTP id y8so73040705igp.0 for ; Sun, 21 Feb 2016 12:03:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UQx2CbGjvCZezZuhPRl2GeOvOJZlei+kmovJucPBguU=; b=hynh0Ca4K7+LCH2U2HT2MqWw2gCWckKfI13jbpPbz/8txpcmrFKX1p2Ny9hsHZ0VOk iqhjgcH5gd7dM4Cyv9EmY26QjKjh1yXanA7oXXE/twCg8TvpRXL86lUxlMI60yShgZjn RtddwkRavxQe3MTn/sUK/CdEeSv8A5nibOEvlHlQrvDDcDaMtL+onn3O6G2ttgHdpMzr gmGwUlyt7MCgPi4be6VmFcZMABmGeo/VVOQydvt6WPm1DmKo8wTR6BwDaQbPl15rQYvz qju6nQLTDk6QmmCAfQcrnAjYWmZ4T8hEBTET+JVc/MBjjIqzD5PrlfKiZY6f6QN4wCLB 9+Lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UQx2CbGjvCZezZuhPRl2GeOvOJZlei+kmovJucPBguU=; b=ZZavRxIRiLFBc5RMDIv9xxp5Fng2TpiTiA5q0PtaXV5GSi+fGOfatmky1IXAFPU5XC cLl0FRt5qtP6wDKrqvNU5gly37uUFN/m6b/BuzGdNpPYwJi7hcN5kvP4cbT0OHIiIIqm xdkhxj/Yf3fsh5hxFxFqljd8Xy5o1uY/ZZQ3qifTi45JxJ3Nuhis7s//C8L7gGBoTrVc pJFP/y17DigjtZL3X4u9dD1jTHxuMuK9k9oHiPjAInDVYYLFPrv9OJozKpgZ5C9752Cx jLhY7qGwvCYHg2oHP44M6xEUzD3ZYg2c+gUKOpVloOH0AjPg0G5UD8Rp6h3BxIU/2rZo HMyw== X-Gm-Message-State: AG10YOQPh9XqlkFuuwG88C9uuFO6AEDLkD0TBJ27dKEdPdmzRE94imh88BcvIbNVJ5moU3ASEvhqnPq7r5cnhg== MIME-Version: 1.0 X-Received: by 10.50.131.227 with SMTP id op3mr1021713igb.94.1456085017381; Sun, 21 Feb 2016 12:03:37 -0800 (PST) Received: by 10.36.53.79 with HTTP; Sun, 21 Feb 2016 12:03:37 -0800 (PST) In-Reply-To: References: Date: Sun, 21 Feb 2016 12:03:37 -0800 Message-ID: From: Martin Thomson To: Brian Raymor Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] 202 (Accepted) and simplifying acknowledgements 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: Sun, 21 Feb 2016 20:03:39 -0000 On 19 February 2016 at 12:26, Brian Raymor wrote: > A more natural flow could use 202 (Accepted) with the :push:receipt as the "status monitor". I realize that I forgot one of the original reasons for the existing design. A design like you propose was considered, but not adopted because it creates a race condition. The acknowledgment races the request that the application server makes to the receipt resource. However, if your assertion is that TTL:0 messages will not be acknowledged, and that all other messages require that the push service persist the acknowledgments as well as the messages themselves, I think that this is probably OK. TTL:1 and maybe other small values are probably a little risky, but a simple caveat might suffice. From nobody Mon Feb 22 16:42:52 2016 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 43E021B2FC8 for ; Mon, 22 Feb 2016 16:42:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 9hYHHbG9GFAg for ; Mon, 22 Feb 2016 16:42:47 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0770.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:770]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 210D31B2DC6 for ; Mon, 22 Feb 2016 16:42:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WmBmOt70p8D4SzAeCzwmbEbgowm775FjhAcDa1ad49Y=; b=ds2SKiVRV403Q9gdZX8pHbY8OMfggnp4iaO9khqGedmQ7HYCq0Napy/ysCu6dNSkKW4y2IYyJxVRafh3wF61KyxeRipc9XdJs1dokEY6IqbRSEXrNivrtBmp9gTXLo4M70tvWN785s6xLay4nWzpcw77aoWf48Ic1RdJ3dM/gQw= Received: from BY2PR0301MB0647.namprd03.prod.outlook.com (10.160.63.14) by BY2PR0301MB0646.namprd03.prod.outlook.com (10.160.63.139) with Microsoft SMTP Server (TLS) id 15.1.409.15; Tue, 23 Feb 2016 00:42:28 +0000 Received: from BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) by BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) with mapi id 15.01.0409.024; Tue, 23 Feb 2016 00:42:28 +0000 From: Brian Raymor To: Martin Thomson Thread-Topic: [Webpush] Niceness or urgency of messages #28 Thread-Index: AdFrgAu+FvNRL8bUQpm4q78Kji7quQABytgAAAZwu/AAAmusgACKEI8g Date: Tue, 23 Feb 2016 00:42:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2601:600:8000:5a8:2073:9de4:7497:9509] x-ms-office365-filtering-correlation-id: 987c300d-299e-450f-77d7-08d33bea34bb x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0646; 5:I99cRsfsSUcyAgeWBFdPjUTIvku1+sPhXk8dyL3VZgeJ70NjfNXkTKG2kl60J+A/NoUUqeoA1aHHuBINEA/UYQu4HJenBQKuYitSa9YuurGBCBkt//e5gCPjlPkBeOQ9ncRcw4EKyiv1vwC0i/SYHQ==; 24:ugz0mKIiL1dTY+yC5MRqi7SBRdiWUopG/MkBvY2J+WWvG71iC9Mr6Le4mGtIUtt4cFl0L/lVcaADqLB0e2i/C6wTzfS6aehmtMv24xQKIWc= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0301MB0646; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(61426038)(61427038); SRVR:BY2PR0301MB0646; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0646; x-forefront-prvs: 08617F610C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(13464003)(40100003)(87936001)(122556002)(93886004)(86612001)(76576001)(76176999)(86362001)(54356999)(50986999)(99286002)(11100500001)(5005710100001)(1220700001)(10290500002)(10400500002)(5004730100002)(33656002)(8990500004)(1096002)(5008740100001)(102836003)(6116002)(586003)(4326007)(7110500001)(74316001)(15975445007)(3660700001)(3280700002)(189998001)(15650500001)(110136002)(19580395003)(5001960100002)(19580405001)(2950100001)(2906002)(5002640100001)(2900100001)(10710500007)(2420400007)(5003600100002)(77096005)(92566002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0646; H:BY2PR0301MB0647.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2016 00:42:27.9959 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0646 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Niceness or urgency of messages #28 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: Tue, 23 Feb 2016 00:42:51 -0000 SSd2ZSB1cGRhdGVkIHRoZSBwdWxsIHJlcXVlc3Qgd2l0aCBNYXJ0aW4ncyBmZWVkYmFjay4NCg0K UGxlYXNlIGxldCBtZSBrbm93IGlmIHRoZXJlJ3MgZnVydGhlciBmZWVkYmFjayB0byBpbmNvcnBv cmF0ZS4NCg0KLi4uQnJpYW4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1h cnRpbiBUaG9tc29uIFttYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tXSANClNlbnQ6IEZy aWRheSwgRmVicnVhcnkgMTksIDIwMTYgMTA6NDggUE0NClRvOiBCcmlhbiBSYXltb3IgPEJyaWFu LlJheW1vckBtaWNyb3NvZnQuY29tPg0KQ2M6IHdlYnB1c2hAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbV2VicHVzaF0gTmljZW5lc3Mgb3IgdXJnZW5jeSBvZiBtZXNzYWdlcyAjMjgNCg0KT3JkZXJp bmcgaXMgZWFzeTogZGVmaW5lIHRoZSBvcmRlci4NCg0KT24gMTkgRmVicnVhcnkgMjAxNiBhdCAy MjowMCwgQnJpYW4gUmF5bW9yIDxCcmlhbi5SYXltb3JAbWljcm9zb2Z0LmNvbT4gd3JvdGU6DQo+ IGJ1dCB0aGlzIHByb3Zva2VkIHNpbWlsYXIgY29uY2VybnMgYWJvdXQgdGhlIG5lZWQgZm9yICJl eHBsaWNpdCBzdGF0ZW1lbnRbc10gYWJvdXQgdGhlIG9yZGVyaW5nIG9mIHRoZXNlIHZhbHVlcyIg YW5kOg0KPg0KPiAgICAgIlRoaXMgY29uc3RhbnQgdXNlIG9mIHNwZWNpZmljIEVuZ2xpc2ggd29y ZHMgcmF0aGVyIHRoYW4gbnVtZXJpYyB2YWx1ZXMgaXMNCj4gICAgIGNhdXNpbmcgdGhlIHByb3Rv Y29sIGFuZCBpdHMgcHJvY2Vzc2luZyB0byBiZWNvbWUgbGVzcyBlZmZpY2llbnQgYW5kIGlzDQo+ ICAgICBsZWFkaW5nIHRvIGNvbXBsaWNhdGlvbnMgaW4gdGhlIGRlZmluaXRpb24gLi4uIg0KPg0K PiAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zaXAvY3VycmVudC9t c2cwMTQ0MS5odG1sDQo+DQo+IFVuZm9ydHVuYXRlbHksIEkgY291bGQgbm90IGZpbmQgYSByZXNw b25zZSBmb3IgdGhlIHJlc3Qgb2YgdGhlIGRpc2N1c3Npb24uIEknbSBkZWZpbml0ZWx5IG9wZW4g dG8gc3VnZ2VzdGlvbnMgYWJvdXQgdGhlIGJlc3Qgd2F5IHRvIGVuc3VyZSB0aGF0IHRoaXMgaXMg Y2xlYXIgdG8gaW1wbGVtZW50ZXJzLg0KDQpUaGF0IGlzIHVzdWFsbHkgYSBzaWduIHRoYXQgdGhl IG1haWwgd2FzIG5vdCB0YWtlbiBzZXJpb3VzbHkuICBXZSB1c2UNCnN0cmluZy1iYXNlZCBlbnVt ZXJhdGlvbnMgYWxsIHRoZSB0aW1lIHRvZGF5LiAgVGhleSBoYXZlIGdyZWF0DQpleHRlbnNpYmls aXR5IHByb3BlcnRpZXMsIHRoZXkgcmVhZCB3ZWxsICh0aG91Z2ggbW9zdGx5IGZvciBFbmdsaXNo DQpzcGVha2VycywgSSB3aWxsIGNvbmNlZGVkKSwgYW5kIHRoZXkgZG9uJ3QgY29zdCBhbnkgc2ln bmlmaWNhbnQgYW1vdW50DQp0byBpbXBsZW1lbnQuDQo= From nobody Wed Feb 24 20:44:10 2016 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 098131B315E for ; Wed, 24 Feb 2016 20:44:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.421 X-Spam-Level: * X-Spam-Status: No, score=1.421 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVmrA6bkMu1p for ; Wed, 24 Feb 2016 20:44:05 -0800 (PST) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B78F41B3155 for ; Wed, 24 Feb 2016 20:44:05 -0800 (PST) Received: by mail-yk0-x22c.google.com with SMTP id z13so17639811ykd.0 for ; Wed, 24 Feb 2016 20:44:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=QXHjI/17ZU03x7scQ7hNcBaY7z6PdfF9Ox02OMvtGZk=; b=K7wz4/J6cjdJ/w++eb0VqJvZW48GIQHUPn8GkQ8Azx23LQj+dbjXv+ayEngnETRq+F 2wBxl7j2K87mPug9THnkrIEwIee8QbsEq7aIFJgfO8kdHtD2yUiX8Vfl1lJhYY2Gv/p8 J55X6/ezoGxZu8eup+iqjJcXbSJhuP/XiT8TXLvp5lF+hw+ARLOll29J4EckfJ4K8WUF Ii2lJPh7ha9RmMzEbib/4urUg5wXaQCx9UJQRjh5gQX9hGnGgy2uieNMyGkRR85pAFEY Oj9ZwgqMc6hN5QlXOw2Ad2ezl91+VP+xxhS7apJ7efWGDzrkaGROPr+telbV8z1p61/8 m4jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=QXHjI/17ZU03x7scQ7hNcBaY7z6PdfF9Ox02OMvtGZk=; b=Y+tnMVE0YZKm8AcOkVz4O2QqIIK1lVs2qoXIgzydG403bGlDS2vBLREUFDBXeJic56 8cX0IXMaVXXpxaAPaLvFOUhq0q2Z6VijcFSgX/b07PLWLk6XCfIkjraLFfebs28o2gJM D5Iqfp8zrJL/noTagBsymt1X5woGYRXvY92IVUXzJWmMj/D3Udcx7GrpWevMlCnQsHR2 PSg1+ZnYh7XdJiPlEEozw+OKqnSy2hsDlK2fQMU2qdWsxrGmV1FbrnnSBxigPCmK3iZM DENgkmPCKAIc1RT34UeqKq16eWe6FZQFYFP5ZSdNPQflEk0HcMGFxLaWCkEDE2r2x8sm Vl4g== X-Gm-Message-State: AG10YOQLEKqwcrWr+MwardGY7gHMpkRjcmFHUfxjxTkWTjinGqQ0T1Cqn1shMS31lCut5MT84inhVkBDM6nr9YZE MIME-Version: 1.0 X-Received: by 10.37.95.84 with SMTP id t81mr23571945ybb.58.1456375444865; Wed, 24 Feb 2016 20:44:04 -0800 (PST) Received: by 10.37.196.68 with HTTP; Wed, 24 Feb 2016 20:44:04 -0800 (PST) Date: Wed, 24 Feb 2016 20:44:04 -0800 Message-ID: From: Benjamin Bangert To: "webpush@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Webpush] The Push Experience 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, 25 Feb 2016 04:44:09 -0000 This may not be entirely on-topic for the webpush ietf spec per-se, but I know a lot of the right people are on this list, so I'm going to throw this out here. If this was already proposed elsewhere, and there's work proceeding on it, great, link me to it so we can choose a version to support. :) First, a little background. Almost a month ago, Firefox 44 was released which included Push support along with data payloads per the recent WebPush draft 02. Since its release, we've seen some interesting uses of it, the least of which was lots of dropped messages due to missing TTL headers which the recent spec additions remedy. The most glaring issue though, is some of the difficulty from early adopters actually trying to use it. This shouldn't be too surprising, because to provide a compelling Push experience, a developer must understand and utilize at least 4 specs, possibly 5... DOM API's Notification API: https://notifications.spec.whatwg.org/ ^^ There's also WebNotification API on W3C, how do developers ever figure this out?? Service Worker API: https://www.w3.org/TR/service-workers/ Push API: https://www.w3.org/TR/push-api/ IETF WebPush: https://datatracker.ietf.org/doc/draft-ietf-webpush-protocol/ Dep, HTTP Encryption: http://tools.ietf.org/html/draft-ietf-httpbis-encryption-encoding-00 VAPID: https://datatracker.ietf.org/doc/draft-thomson-webpush-vapid/ Dep, JWT: http://tools.ietf.org/html/rfc7519 (Additional Dep. specs left out) This is.... rather overwhelming to many web developers. Nevermind trying to figure out what drafts of what specs each browser has actually implemented. So far we have already seen libraries drop to the lowest common denominator, which so far means we have not been carrying data payloads even though Firefox supports it, because Chrome does not. This doesn't include how you ask for permissions for these things, because technically the Notification permission is separate from the Push permission, but afaik, both Chrome and Firefox will accept one of them as both to reduce clutter. So you might have accepted notifications without knowing you get push when the tab is closed, though lots of users probably can't make that distinction..... ugh. How these permissions are squashed, and for which browsers, appears to be completely ignored by the docs I've seen. Do the doc writers even realize browsers are squashing these permissions? None of these specs speak to the user experience. Does the service backing my browser allow 200 or 2000 notifications to be queued? Will they all be shown? Do I want them to be? Does the browser implement safeguards to prevent my screen from being flooded with these? Is there a spec dictating the UX for how to handle 100 queued notifications in a way that doesn't make the user immediately delete the program (like the ask for permission spec)? Even ignoring the above paragraph, which some could perhaps consider a browser detail that should not be mandated (so we can all compete on how compelling our notification spam management is), there's more important questions for our developers. How do I code this in a way that works on more than one browser given there's 4-5 API's at various draft states implemented at different stages in each browser? For that last question specifically, I'm proposing there a meta-specification, perhaps called the Push Experience (I'm bad at naming specs, no clever initials like VAPID), which essentially acts as a global version pegging for the various spec dependencies needed for a good Push experience. I.e. Push Experience Draft 1: - Notification API Draft N: - Service Worker API Draft Z: .... This way it's clearly documented to a developer what the overall set of available API's they can work with are, as a base minimum for each browser. I'm not a spec-writer myself, so I don't even know what group this belongs in.... whatwg? ietf? w3c? Technically it's a meta-spec pegging specs from a variety of groups together to provide a cohesive whole that a developer won't lose their mind over implementing. I'm not sure there's much precedent for this, as I haven't heard of any other emerging web tech's that involve so many specs in such a variety of locations (back-end and front-end web dev). I'd be happy to collaborate on this, or for some others to take over this entirely, as I do believe having something like this is very important to developers attempting to use Push. I'm not sure what the appropriate venue for something of this nature to be, since it would appear to tie together specs in at least 3 different spec groups. Maybe it=E2=80=99s not a formal spec at all, but some other collaboration t= o agree on minimum definitions for each phase, like the ACID 2 vs. ACID 3 browser tests so that a developer could easily see =E2=80=98How ready is = my browser for a Push Experience?=E2=80=99. Thoughts? Cheers, Ben From nobody Thu Feb 25 08:07:03 2016 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 BD4FC1B2BFC for ; Thu, 25 Feb 2016 08:07:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.422 X-Spam-Level: * X-Spam-Status: No, score=1.422 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tc9--Kh3QaXn for ; Thu, 25 Feb 2016 08:06:58 -0800 (PST) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D0501B2B7B for ; Thu, 25 Feb 2016 08:06:58 -0800 (PST) Received: by mail-qg0-x232.google.com with SMTP id b67so43246477qgb.1 for ; Thu, 25 Feb 2016 08:06:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=pRZ5NYdRbUzmsXXtKi9VBTavQhXfGoFEusc37VoXkG0=; b=gyCK5Yz0zbSZgdyAnAo/km9dBG/iFMSwhxdARJBSDqACVDDhAeknmAdgjomcq/32Me dTWN/ddRwhZpDbdqoPpr5rYmCo3E80gxOrUxdbw1EMvzzjiqkYk+gXSNJXY2G1W02yMq WUHepdfYEXpX3dv7sDyJErCCgCKDne6Ei5CG0F2BWjNwTYUR6N90DGeBPpFqAl5utHzi 91sUSfvUBwHYt175gqBaTyRHKdrgk7xnk75LFhy0fwp1QDuBt4zWCSH23ToWDS8wW9q1 ZHRbUJCWaHkd/bsD3/6Ji0ylpM+MV4JqLKX9+uPhcPP2XK0ru7uCQERXFpO10J99Lepe AxfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=pRZ5NYdRbUzmsXXtKi9VBTavQhXfGoFEusc37VoXkG0=; b=XIsQov3aqITXv5UQ2Xl8M/y7ml62LebjAcwjF3nSgkdnXSUEbkqSuwVt5EOnrPPUk1 Ovjs9p+HSRgrjWjnC9bvmsxxynLHGv7A221y5YaSUerr4Yr+9NrYk4inEcqk5bJTKlb+ C2eWO64wAAKjNtk0kGN0OrRwJwNZMHUxxHjDWMSi1glMwryw/yXQeB4TUzexWISkefO3 QfPMEjpbs+Py2H+cImba2DXI24kI9Y/zO3nSOtiDq5lSWO9UnKqgrPL6UhKzcFap0KZN R0+Z4JKRmC5je3HUaqdlJ4NgHSbBpqGshyZo6U5jiPqj5J1b5nMOaTCWbKnlSOIbYxNa 3CSQ== X-Gm-Message-State: AG10YOSyK51Xlky8BDn3U/C8kUnij1ktg7sfwAYm4+pBW4DPa1l9U6GP40qdMKeMoK/84bWlKjkDI0N6cuKKv8FF X-Received: by 10.140.109.100 with SMTP id k91mr58241827qgf.54.1456416417514; Thu, 25 Feb 2016 08:06:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.33.230 with HTTP; Thu, 25 Feb 2016 08:06:37 -0800 (PST) In-Reply-To: References: From: Luke Crouch Date: Thu, 25 Feb 2016 10:06:37 -0600 Message-ID: To: Benjamin Bangert Content-Type: multipart/alternative; boundary=001a1139b43a362f8d052c9a5f34 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] The Push Experience 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, 25 Feb 2016 16:07:02 -0000 --001a1139b43a362f8d052c9a5f34 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Just my $0.02 ... I spent the better part of 2-3 weeks in January learning how web push messages work, and yes - I had absorb notifications, service workers, push api, and vapid. I updated some MDN docs and examples along the way, and tried to contribute patches to libraries where I could. But, adding *another* spec at this point feels too much like https://xkcd.com/927/. I'd personally rather spend time coding the best push experience into *libraries* like the node module and the wordpress plugin to make it accessible to more developers. -L On Wed, Feb 24, 2016 at 10:44 PM, Benjamin Bangert wrote: > This may not be entirely on-topic for the webpush ietf spec per-se, > but I know a lot of the right people are on this list, so I'm going to > throw this out here. If this was already proposed elsewhere, and > there's work proceeding on it, great, link me to it so we can choose a > version to support. :) > > First, a little background. > > Almost a month ago, Firefox 44 was released which included Push > support along with data payloads per the recent WebPush draft 02. > Since its release, we've seen some interesting uses of it, the least > of which was lots of dropped messages due to missing TTL headers which > the recent spec additions remedy. > > The most glaring issue though, is some of the difficulty from early > adopters actually trying to use it. This shouldn't be too surprising, > because to provide a compelling Push experience, a developer must > understand and utilize at least 4 specs, possibly 5... > > DOM API's > > Notification API: https://notifications.spec.whatwg.org/ > ^^ There's also WebNotification API on W3C, how do developers ever > figure this out?? > > Service Worker API: https://www.w3.org/TR/service-workers/ > Push API: https://www.w3.org/TR/push-api/ > > > IETF > WebPush: https://datatracker.ietf.org/doc/draft-ietf-webpush-protocol/ > Dep, HTTP Encryption: > http://tools.ietf.org/html/draft-ietf-httpbis-encryption-encoding-00 > VAPID: https://datatracker.ietf.org/doc/draft-thomson-webpush-vapid/ > Dep, JWT: http://tools.ietf.org/html/rfc7519 > > (Additional Dep. specs left out) > > This is.... rather overwhelming to many web developers. Nevermind > trying to figure out what drafts of what specs each browser has > actually implemented. So far we have already seen libraries drop to > the lowest common denominator, which so far means we have not been > carrying data payloads even though Firefox supports it, because Chrome > does not. > > This doesn't include how you ask for permissions for these things, > because technically the Notification permission is separate from the > Push permission, but afaik, both Chrome and Firefox will accept one of > them as both to reduce clutter. So you might have accepted > notifications without knowing you get push when the tab is closed, > though lots of users probably can't make that distinction..... ugh. > How these permissions are squashed, and for which browsers, appears to > be completely ignored by the docs I've seen. Do the doc writers even > realize browsers are squashing these permissions? > > None of these specs speak to the user experience. Does the service > backing my browser allow 200 or 2000 notifications to be queued? Will > they all be shown? Do I want them to be? Does the browser implement > safeguards to prevent my screen from being flooded with these? Is > there a spec dictating the UX for how to handle 100 queued > notifications in a way that doesn't make the user immediately delete > the program (like the ask for permission spec)? > > Even ignoring the above paragraph, which some could perhaps consider a > browser detail that should not be mandated (so we can all compete on > how compelling our notification spam management is), there's more > important questions for our developers. How do I code this in a way > that works on more than one browser given there's 4-5 API's at various > draft states implemented at different stages in each browser? > > For that last question specifically, I'm proposing there a > meta-specification, perhaps called the Push Experience (I'm bad at > naming specs, no clever initials like VAPID), which essentially acts > as a global version pegging for the various spec dependencies needed > for a good Push experience. > > I.e. > > Push Experience Draft 1: > - Notification API Draft N: > - Service Worker API Draft Z: > > .... > > This way it's clearly documented to a developer what the overall set > of available API's they can work with are, as a base minimum for each > browser. I'm not a spec-writer myself, so I don't even know what group > this belongs in.... whatwg? ietf? w3c? Technically it's a meta-spec > pegging specs from a variety of groups together to provide a cohesive > whole that a developer won't lose their mind over implementing. I'm > not sure there's much precedent for this, as I haven't heard of any > other emerging web tech's that involve so many specs in such a variety > of locations (back-end and front-end web dev). > > I'd be happy to collaborate on this, or for some others to take over > this entirely, as I do believe having something like this is very > important to developers attempting to use Push. I'm not sure what the > appropriate venue for something of this nature to be, since it would > appear to tie together specs in at least 3 different spec groups. > Maybe it=E2=80=99s not a formal spec at all, but some other collaboration= to > agree on minimum definitions for each phase, like the ACID 2 vs. ACID > 3 browser tests so that a developer could easily see =E2=80=98How ready i= s my > browser for a Push Experience?=E2=80=99. > > Thoughts? > > Cheers, > Ben > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > --001a1139b43a362f8d052c9a5f34 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just my $0.02 ...

I spent the better part of 2= -3 weeks in January learning how web push messages work, and yes - I had ab= sorb notifications, service workers, push api, and vapid. I updated some MD= N docs and examples along the way, and tried to contribute patches to libra= ries where I could.

But, adding *another* spec at this po= int feels too much like https://xkcd.com/= 927/.

I'd personally rather spend time coding the= best push experience into *libraries* like the node module and the wordpre= ss plugin to make it accessible to more developers.

-L

On W= ed, Feb 24, 2016 at 10:44 PM, Benjamin Bangert <bbangert@mozilla.com> wrote:
This may not be entir= ely on-topic for the webpush ietf spec per-se,
but I know a lot of the right people are on this list, so I'm going to<= br> throw this out here. If this was already proposed elsewhere, and
there's work proceeding on it, great, link me to it so we can choose a<= br> version to support. :)

First, a little background.

Almost a month ago, Firefox 44 was released which included Push
support along with data payloads per the recent WebPush draft 02.
Since its release, we've seen some interesting uses of it, the least of which was lots of dropped messages due to missing TTL headers which
the recent spec additions remedy.

The most glaring issue though, is some of the difficulty from early
adopters actually trying to use it. This shouldn't be too surprising, because to provide a compelling Push experience, a developer must
understand and utilize at least 4 specs, possibly 5...

DOM API's

Notification API: https://notifications.spec.whatwg.org/ ^^ There's also WebNotification API on W3C, how do developers ever
figure this out??

Service Worker API: https://www.w3.org/TR/service-workers/
Push API: https://www.w3.org/TR/push-api/


IETF
WebPush: https://datatracker.ietf.org/d= oc/draft-ietf-webpush-protocol/
=C2=A0 =C2=A0 Dep, HTTP Encryption:
http://tools.ietf.org/html/draft= -ietf-httpbis-encryption-encoding-00
VAPID: https://datatracker.ietf.org/doc= /draft-thomson-webpush-vapid/
=C2=A0 =C2=A0 Dep, JWT: http://tools.ietf.org/html/rfc7519
(Additional Dep. specs left out)

This is.... rather overwhelming to many web developers. Nevermind
trying to figure out what drafts of what specs each browser has
actually implemented. So far we have already seen libraries drop to
the lowest common denominator, which so far means we have not been
carrying data payloads even though Firefox supports it, because Chrome
does not.

This doesn't include how you ask for permissions for these things,
because technically the Notification permission is separate from the
Push permission, but afaik, both Chrome and Firefox will accept one of
them as both to reduce clutter. So you might have accepted
notifications without knowing you get push when the tab is closed,
though lots of users probably can't make that distinction..... ugh.
How these permissions are squashed, and for which browsers, appears to
be completely ignored by the docs I've seen. Do the doc writers even realize browsers are squashing these permissions?

None of these specs speak to the user experience. Does the service
backing my browser allow 200 or 2000 notifications to be queued? Will
they all be shown? Do I want them to be? Does the browser implement
safeguards to prevent my screen from being flooded with these? Is
there a spec dictating the UX for how to handle 100 queued
notifications in a way that doesn't make the user immediately delete the program (like the ask for permission spec)?

Even ignoring the above paragraph, which some could perhaps consider a
browser detail that should not be mandated (so we can all compete on
how compelling our notification spam management is), there's more
important questions for our developers. How do I code this in a way
that works on more than one browser given there's 4-5 API's at vari= ous
draft states implemented at different stages in each browser?

For that last question specifically, I'm proposing there a
meta-specification, perhaps called the Push Experience (I'm bad at
naming specs, no clever initials like VAPID), which essentially acts
as a global version pegging for the various spec dependencies needed
for a good Push experience.

I.e.

Push Experience Draft 1:
=C2=A0 - Notification API Draft N:
=C2=A0 - Service Worker API Draft Z:

=C2=A0 ....

This way it's clearly documented to a developer what the overall set of available API's they can work with are, as a base minimum for each browser. I'm not a spec-writer myself, so I don't even know what gr= oup
this belongs in.... whatwg? ietf? w3c? Technically it's a meta-spec
pegging specs from a variety of groups together to provide a cohesive
whole that a developer won't lose their mind over implementing. I'm=
not sure there's much precedent for this, as I haven't heard of any=
other emerging web tech's that involve so many specs in such a variety<= br> of locations (back-end and front-end web dev).

I'd be happy to collaborate on this, or for some others to take over this entirely, as I do believe having something like this is very
important to developers attempting to use Push. I'm not sure what the appropriate venue for something of this nature to be, since it would
appear to tie together specs in at least 3 different spec groups.
Maybe it=E2=80=99s not a formal spec at all, but some other collaboration t= o
agree on minimum definitions for each phase, like the ACID 2 vs. ACID
3 browser tests so that a developer could easily see =E2=80=98How ready is = my
browser for a Push Experience?=E2=80=99.

Thoughts?

Cheers,
Ben

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

--001a1139b43a362f8d052c9a5f34-- From nobody Thu Feb 25 08:26:29 2016 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 814291B2C9C for ; Thu, 25 Feb 2016 08:26:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.421 X-Spam-Level: * X-Spam-Status: No, score=1.421 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwiWvbi13YZy for ; Thu, 25 Feb 2016 08:26:24 -0800 (PST) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E74941B2CB4 for ; Thu, 25 Feb 2016 08:26:23 -0800 (PST) Received: by mail-yk0-x22d.google.com with SMTP id u9so24204679ykd.1 for ; Thu, 25 Feb 2016 08:26:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=QhcWkO4DpqtSwuKwy0rBc1dvfl4gecjfRwCv9VYqbGw=; b=vRmPMB4ilcIJtk0ZG33DgrgHNQSz5mEnuHoqjDKtbcHk1Wo4NeyoJfdLasi0S9FrvM tJyrPHEnClnYJVlIELH1sBMnniYzngvSuhc5nJLxCL+SszCVRSJeAjRxyizpk5d+v7tG gb7msr7ZoBFwX3aGYl1kUCcJRnxwCMZsP/fk3eXCNgDP6WiE421LBXEneQwhm85Qrd1p 4soPr1kaqFqX/zKgxfyxpClcNFaluwyxGwh1z5J7ji/ycKkxGPIYfND1y5dsBG/CPcqD PW9PbfIO3lO0ZYblo51khlju8Lm0XbzNxOugwcSlyqf7hoEkYTRSyiIc1kiwH/fjpsIx 750g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QhcWkO4DpqtSwuKwy0rBc1dvfl4gecjfRwCv9VYqbGw=; b=FBg5KDxk/ir4gpeTQCoyMVCpR18VsmM/9VCCUWKi+Mh3En2yyp1gbQXFE1lxX/upUi TbJb6Gp58xOIroZQ7YcCMsgkh1oOq5SVGjKKf/vCfz/Vy5O+Nc2rhx1n5qIQOywrzouq NC65nnrpMBDBIaH/FS2vWHfd0xer3YtFXK2tQDzqPtnicZMWA5JNb4gaIk0g2YZjjbFy Pc8/6GeZTlP/OWbxx6hzxBBdHoCI5Ue/G5/fkeqol45H9lmHwb5d3lOndxRcPpqcmwGg 5blrAFeiMztudWeF7iSUgLB6apD+cOo03BpsAifnJWvnYr4+HxLA4Wdu5aQfYMii4kmI ra7w== X-Gm-Message-State: AG10YOSJl6RlIDbIk8+AIU3WTPbxguiIHn1X/xVTjodnS6jhyzt+15SBihEtUDpnB6aZCe5dhaBdTnb84eSUsf6t MIME-Version: 1.0 X-Received: by 10.37.87.65 with SMTP id l62mr23506333ybb.113.1456417583049; Thu, 25 Feb 2016 08:26:23 -0800 (PST) Received: by 10.37.196.68 with HTTP; Thu, 25 Feb 2016 08:26:22 -0800 (PST) In-Reply-To: References: Date: Thu, 25 Feb 2016 08:26:22 -0800 Message-ID: From: Benjamin Bangert To: Luke Crouch Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] The Push Experience 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, 25 Feb 2016 16:26:27 -0000 This wouldn't be a new spec, it'd mainly be a way to see what versions of which specs various browsers/push-services had implemented in which browser versions. Maybe a website that just indicates what features of which specs are supported on which browsers, ala: https://html5test.com/ And indicate what features are supported by the Push-Service for that brows= er. Where you can see at a glance what features are available for which specs. Cheers, Ben On Thu, Feb 25, 2016 at 8:06 AM, Luke Crouch wrote: > Just my $0.02 ... > > I spent the better part of 2-3 weeks in January learning how web push > messages work, and yes - I had absorb notifications, service workers, pus= h > api, and vapid. I updated some MDN docs and examples along the way, and > tried to contribute patches to libraries where I could. > > But, adding *another* spec at this point feels too much like > https://xkcd.com/927/. > > I'd personally rather spend time coding the best push experience into > *libraries* like the node module and the wordpress plugin to make it > accessible to more developers. > > -L > > On Wed, Feb 24, 2016 at 10:44 PM, Benjamin Bangert > wrote: >> >> This may not be entirely on-topic for the webpush ietf spec per-se, >> but I know a lot of the right people are on this list, so I'm going to >> throw this out here. If this was already proposed elsewhere, and >> there's work proceeding on it, great, link me to it so we can choose a >> version to support. :) >> >> First, a little background. >> >> Almost a month ago, Firefox 44 was released which included Push >> support along with data payloads per the recent WebPush draft 02. >> Since its release, we've seen some interesting uses of it, the least >> of which was lots of dropped messages due to missing TTL headers which >> the recent spec additions remedy. >> >> The most glaring issue though, is some of the difficulty from early >> adopters actually trying to use it. This shouldn't be too surprising, >> because to provide a compelling Push experience, a developer must >> understand and utilize at least 4 specs, possibly 5... >> >> DOM API's >> >> Notification API: https://notifications.spec.whatwg.org/ >> ^^ There's also WebNotification API on W3C, how do developers ever >> figure this out?? >> >> Service Worker API: https://www.w3.org/TR/service-workers/ >> Push API: https://www.w3.org/TR/push-api/ >> >> >> IETF >> WebPush: https://datatracker.ietf.org/doc/draft-ietf-webpush-protocol/ >> Dep, HTTP Encryption: >> http://tools.ietf.org/html/draft-ietf-httpbis-encryption-encoding-00 >> VAPID: https://datatracker.ietf.org/doc/draft-thomson-webpush-vapid/ >> Dep, JWT: http://tools.ietf.org/html/rfc7519 >> >> (Additional Dep. specs left out) >> >> This is.... rather overwhelming to many web developers. Nevermind >> trying to figure out what drafts of what specs each browser has >> actually implemented. So far we have already seen libraries drop to >> the lowest common denominator, which so far means we have not been >> carrying data payloads even though Firefox supports it, because Chrome >> does not. >> >> This doesn't include how you ask for permissions for these things, >> because technically the Notification permission is separate from the >> Push permission, but afaik, both Chrome and Firefox will accept one of >> them as both to reduce clutter. So you might have accepted >> notifications without knowing you get push when the tab is closed, >> though lots of users probably can't make that distinction..... ugh. >> How these permissions are squashed, and for which browsers, appears to >> be completely ignored by the docs I've seen. Do the doc writers even >> realize browsers are squashing these permissions? >> >> None of these specs speak to the user experience. Does the service >> backing my browser allow 200 or 2000 notifications to be queued? Will >> they all be shown? Do I want them to be? Does the browser implement >> safeguards to prevent my screen from being flooded with these? Is >> there a spec dictating the UX for how to handle 100 queued >> notifications in a way that doesn't make the user immediately delete >> the program (like the ask for permission spec)? >> >> Even ignoring the above paragraph, which some could perhaps consider a >> browser detail that should not be mandated (so we can all compete on >> how compelling our notification spam management is), there's more >> important questions for our developers. How do I code this in a way >> that works on more than one browser given there's 4-5 API's at various >> draft states implemented at different stages in each browser? >> >> For that last question specifically, I'm proposing there a >> meta-specification, perhaps called the Push Experience (I'm bad at >> naming specs, no clever initials like VAPID), which essentially acts >> as a global version pegging for the various spec dependencies needed >> for a good Push experience. >> >> I.e. >> >> Push Experience Draft 1: >> - Notification API Draft N: >> - Service Worker API Draft Z: >> >> .... >> >> This way it's clearly documented to a developer what the overall set >> of available API's they can work with are, as a base minimum for each >> browser. I'm not a spec-writer myself, so I don't even know what group >> this belongs in.... whatwg? ietf? w3c? Technically it's a meta-spec >> pegging specs from a variety of groups together to provide a cohesive >> whole that a developer won't lose their mind over implementing. I'm >> not sure there's much precedent for this, as I haven't heard of any >> other emerging web tech's that involve so many specs in such a variety >> of locations (back-end and front-end web dev). >> >> I'd be happy to collaborate on this, or for some others to take over >> this entirely, as I do believe having something like this is very >> important to developers attempting to use Push. I'm not sure what the >> appropriate venue for something of this nature to be, since it would >> appear to tie together specs in at least 3 different spec groups. >> Maybe it=E2=80=99s not a formal spec at all, but some other collaboratio= n to >> agree on minimum definitions for each phase, like the ACID 2 vs. ACID >> 3 browser tests so that a developer could easily see =E2=80=98How ready = is my >> browser for a Push Experience?=E2=80=99. >> >> Thoughts? >> >> Cheers, >> Ben >> >> _______________________________________________ >> Webpush mailing list >> Webpush@ietf.org >> https://www.ietf.org/mailman/listinfo/webpush > >