From nobody Fri May 2 09:56:07 2014 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8596A1A6FC1 for ; Fri, 2 May 2014 09:54:48 -0700 (PDT) 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, FREEMAIL_FROM=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 T2XYcNOOQMpM for ; Fri, 2 May 2014 09:54:47 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id EC4EA1A6F88 for ; Fri, 2 May 2014 09:54:43 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id y10so185064wgg.22 for ; Fri, 02 May 2014 09:54:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=LVKuIhJztDcJeM4R24HEgjRDRMiVcQDr5vVNFfR+vWM=; b=I4T84/HvarYyGax75xVMC7nnsXOCAJ1ISS6QFDQewP2VXByFJysOXU4lV6d98FMxFI 4gtBspKiY6AU5duEbavXfQkrtGSAPfPkoZKINZYgQFpQMyFUjc0Wh4DXZttrFuHWNuVA xZFoPfsc+O1PTas5S1wUjHzAhFl67voehjEbpxXiGg3p/KsvdUh4cLI7msQNo7ziOzsy lcdH4UlCGBvNL9ll+nNB/15dco8mXatAENYdMmBCoEYnkSchRkg7rjIc6eEsgz276gOJ dUb5h6oLIwMVciYBtLaa69hfhecrNTuieMmmG0sIg3hj71KaYu8DV1fHUjQIaAGvQrRC rAag== X-Received: by 10.180.72.179 with SMTP id e19mr3716763wiv.61.1399049681144; Fri, 02 May 2014 09:54:41 -0700 (PDT) MIME-Version: 1.0 Sender: doug.turner@gmail.com Received: by 10.227.233.141 with HTTP; Fri, 2 May 2014 09:54:21 -0700 (PDT) From: Doug Turner Date: Fri, 2 May 2014 09:54:21 -0700 X-Google-Sender-Auth: 5bfLIaeLvYRMApwXy4U4e8V41aw Message-ID: To: webpush@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/9tkclPmc49FN1o0F4NMsKqNS7CY X-Mailman-Approved-At: Fri, 02 May 2014 09:56:05 -0700 Subject: [Webpush] First post 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, 02 May 2014 16:54:48 -0000 The draft we are working on is here: https://github.com/dougt/webpush-protocol The related w3c draft is here: https://dvcs.w3.org/hg/push/raw-file/tip/index.html Regards, Doug Turner From nobody Mon May 5 14:55:36 2014 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D55D1A0641; Mon, 5 May 2014 14:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtoMrkcBTDKC; Mon, 5 May 2014 14:43:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 883721A0522; Mon, 5 May 2014 14:43:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140505214342.32016.42852.idtracker@ietfa.amsl.com> Date: Mon, 05 May 2014 14:43:42 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/6QTUIWJkvRscyqTDitZ05TV5R-U X-Mailman-Approved-At: Mon, 05 May 2014 14:55:34 -0700 Cc: dougt@mozilla.com, ekr@rtfm.com, webpush@ietf.org Subject: [Webpush] New Non-WG Mailing List: webpush X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org 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, 05 May 2014 21:43:43 -0000 A new IETF non-working group email list has been created. List address: webpush@ietf.org Archive: http://www.ietf.org/mail-archive/web/webpush/current/maillist.html To subscribe: https://www.ietf.org/mailman/listinfo/webpush Purpose: Discussion of potential IETF work on a web push protocol. For additional information, please contact the list administrators. From nobody Mon May 12 15:17:25 2014 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3391A0788 for ; Mon, 12 May 2014 15:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRBm0JBjCmKF for ; Mon, 12 May 2014 15:17:22 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id C967B1A0767 for ; Mon, 12 May 2014 15:17:21 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id n15so5292168wiw.14 for ; Mon, 12 May 2014 15:17:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=WbD/fSS7pgmSHrA0S52Iffly/75bBeZBEYJr3mDGusc=; b=t67p24yAc8euKyu56y/kvRtaVdyGQO/9qX6VlM/5pY012qGQPEietrY4fkhyrY3eoD GAg9CZYPnslyRtfF5brNZITGDj2KSOJdmVnRXzARuPNucp34ZHDAwNxYsaWeLB+tjb6N Yeeo7BwcMfi1xhTtBi89X7lNMWubPPA98UJMxZEjgY+gha1/OSjdxDi+9HudYOu+ziDg wbSIo8VhGd+E/+bv0hXDqahj/kYctYr9ittudis5u4AokbNxeRpfdRRHhfCaA5nh8mD1 436iOTUywHMp8Nn8C8RXMPd3f60Gv2vlfjSQBJKHFFoT48A4lN8PaIwI+rR8qRsKDEnK ygmw== MIME-Version: 1.0 X-Received: by 10.194.57.38 with SMTP id f6mr3860428wjq.59.1399933035286; Mon, 12 May 2014 15:17:15 -0700 (PDT) Received: by 10.194.235.163 with HTTP; Mon, 12 May 2014 15:17:15 -0700 (PDT) Date: Mon, 12 May 2014 15:17:15 -0700 Message-ID: From: Martin Thomson To: webpush@ietf.org, dougt@mozilla.com Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/-8X23OADlfbHdi0XtqUM_diXvl8 Subject: [Webpush] Push over HTTP/2 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, 12 May 2014 22:17:23 -0000 I was asked to write down my thoughts on what a Web Push protocol using HTTP/2 might look like. I've written that down here: http://tools.ietf.org/html/draft-thomson-webpush-http2-00 I hope that there is enough explanation for the features that are described in the draft. Let's use the mailing list to discuss the things that aren't in the draft. --Martin From nobody Tue May 13 15:59:43 2014 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A211A0123 for ; Tue, 13 May 2014 15:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ly9o-lXWm3e8 for ; Tue, 13 May 2014 15:59:40 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 934721A011F for ; Tue, 13 May 2014 15:59:40 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id f8so1460938wiw.4 for ; Tue, 13 May 2014 15:59:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=F3w3gwLV0+xHpu8VTyUhZQnQ/pzvNvGhhBodyqWf+CA=; b=bE/YzeFnj2HkFz47K7iTJ5Tk6mbBNm8Q5SrWaR4imlTyNOpEMN9iOztqGTi9sACYbn ChuJs5ifLYVlTsFsKZ6jeCvjBPXmXGDjUefq7uEM4LNYwzfSZHcOKRvjplIA1qYHUQCl tqIvBNlcF13ev2uddUzjyZGX/vOVCLiPw7fq2kcktGDzB8Bmzq/gxSdifs3ZZeRoexaB GVbRIAjNF/45mn62RciqQUiWi6w0H49tHfx/PBmdo+ySjvnAMK5szMZ0dc3Do75/kBIp vZh1IsdtlOL86aBy0rOKN5ey6t3DeQuf0anqT7M7dTHcvEPOlDzNvFYIo6GXeGcvQYXV aW9w== MIME-Version: 1.0 X-Received: by 10.194.133.1 with SMTP id oy1mr9933wjb.87.1400021973584; Tue, 13 May 2014 15:59:33 -0700 (PDT) Received: by 10.194.235.163 with HTTP; Tue, 13 May 2014 15:59:33 -0700 (PDT) Date: Tue, 13 May 2014 15:59:33 -0700 Message-ID: From: Martin Thomson To: webpush@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/wkDwYYgltr1IvSXBdIdjt3AMi7A Subject: [Webpush] Avoiding push for less important 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: Tue, 13 May 2014 22:59:42 -0000 See http://tools.ietf.org/html/draft-thomson-http-nice A new version is imminent, pending secretariat intervention. From nobody Wed May 14 01:33:29 2014 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9D011A0273 for ; Wed, 14 May 2014 01:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 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.651, 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 TXn3tbB3uMyY for ; Wed, 14 May 2014 01:33:26 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA8D1A027D for ; Wed, 14 May 2014 01:33:26 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id e16so2269134qcx.0 for ; Wed, 14 May 2014 01:33:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=iTPapZDtQVK/jPQzPDGIsmrWV7Le93V30iDFToAY3aE=; b=iLObxHxx3GeFPYvuFsFZfcnNU79jO7vgFLt9P1tduI2qYsFKufQT2fZWIRI1/CAHVw UWa19wfMt+XhaIHLi9p6oLNtUvVWKZcW6CSMD3jyfOGLio1rW4nv7iptruIWaodqetIb 6ytuY8eXt2WrxNQ9+45S31UUpzWZ6M3OMSGuRz1McZnSq4NpXZbvO00Ra4RKn50rrOO1 oaUOgp59yFb185kgWr5jUO/l1KQK4eXsio5Gj2iRtPwSdw9WrIUzj700MZo5Kheo7kTh 1OCoqpTM2nICvWujsl/hi7is+7V63h7Pp5xy63nlfc2Zx0T/QNFzu75rOLiZgfjWzY/Z wyyQ== 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=iTPapZDtQVK/jPQzPDGIsmrWV7Le93V30iDFToAY3aE=; b=QWSz7CPpTXFpE/ixe22Mt6Od/jsYvktjtASWUiCP5fhSXSvnRMpsFoFx0Gj3JVsixx uz3LBXET0w5BxEXZ1pA7whe1UD3C0ZPol1elGoAtWXN6Lk6jRmZ5HB9pUt1sTNAVQJOs ETvDkjE/3o01Q9HT3UyUoooYt9XQ+7Sft3chw1YqrwmZ943TexkfAD3uDu+gEy07f1wW iI/3B8k86BvjeHyyARGd27caf57Zc3kNvAKoTm6VWu/fOWr+Sajz60LP58+JVaQfY0WT sxi2MwoRf69YhZZKChUe21QFow03EnxcoOeiXpoqVtV1sXdyYvxm59BXdHe/EI48XQKu X7Kg== X-Gm-Message-State: ALoCoQmMXgoZAIRjkkGSwT8bren9oEJCffsVH7J8cCNyjCN3PHKfpeWwhJX1F3VYDmGTpX8tTY0r MIME-Version: 1.0 X-Received: by 10.224.79.207 with SMTP id q15mr1189199qak.40.1400056399847; Wed, 14 May 2014 01:33:19 -0700 (PDT) Received: by 10.229.214.196 with HTTP; Wed, 14 May 2014 01:33:19 -0700 (PDT) Date: Wed, 14 May 2014 10:33:19 +0200 Message-ID: From: Peter Beverloo To: webpush@ietf.org Content-Type: multipart/alternative; boundary=047d7bdc8ae260ff8904f958084d Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/WxVUWc2mdO5_r5oOd55lKbbPoOE Subject: [Webpush] Feedback on Martin's WebPush draft 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, 14 May 2014 08:33:29 -0000 --047d7bdc8ae260ff8904f958084d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Context: http://tools.ietf.org/html/draft-thomson-webpush-http2-00 Hi Martin, Thank you for putting up your proposal for a HTTP 2.0-based Push service mechanism. The omission of a dependency on WebSockets is something we support, given that this raises implementation complexities for us. I have reviewed your proposal, and want to provide the following feedback. * Defining the scope of this specification. I consider there to be three primary pieces in an entire push transaction. These are: a) client <=3D=3D=3D=3D> push service, registering for a push channel to be= opened; b) app server =3D=3D=3D=3D> push service, asking the push service to delive= r a message to a client; c) push service =3D=3D=3D=3D> client, informing the client of the pushed me= ssage. I consider (a) and (c) to be implementation details of the Push service, which users will rarely get in contact with. The draft mentions that discovery of push services is considered out of scope. My recommendation is to consider (a), establishing a registration, part of that. This is relevant to sections the registration part, as well as the concept of monitoring channels (most notably section 6). * Definition of the payload itself. This seems to be missing in the draft. I assume we=E2=80=99ll work on this = later? :-). * Separate channel name from URL / enabling multi-cast delivery. Moving the channel name (or the registration Id, depending on context) to the message contents allows us to accept an array of recipients, allowing the Push service to multi-cast the message. This would significantly lower the number of requests required for larger broadcasts. I would recommend having a SHOULD requirement on supporting at least a thousand targets. * Explicit responses for push requests to the push service. There are a few reasons why a push request may fail: (1) invalid formatting, (2) invalid channel/target, (3) invalid authentication information where required. Having a short JSON reply indicating *why* it failed would be very helpful here. Furthermore, in case we want to enable a continuous WebSocket-like flow in the future (a persistent channel would also allow for asynchronous delivery receipts or an upstream channel), the HTTP response code may not always be relied upon. * Push services to make a best effort for message delivery. Section 7 currently provides very weak guidance on what level of message delivery could be expected. I would like to see stronger wording here, expressing that push services are expected to make a best effort at delivering the message (possibly through an RFC2119 SHOULD). * Synchronous status reporting by the push service. Section 3 defines that the push service can reply with specific status codes depending on whether the message could be delivered. How realistic is it to expect a push service to reply with 200 OK responses? Does any current service support that? I expect this to become much more asynchronous over time. It would also be good to specify the response when a message has been rejected, for example because of invalid formatting. I would recommend to change these to be RFC2119 MAYs. Thanks, Peter NB: considering GCM terminology, =E2=80=9Cchannel=E2=80=9D maps to =E2=80= =9Cregistration Id=E2=80=9D --047d7bdc8ae260ff8904f958084d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Martin,

T= hank you for putting up your proposal for a HTTP 2.0-based Push service mec= hanism. The omission of a dependency on WebSockets is something we support,= given that this raises implementation complexities for us.

I have reviewed your proposal, and want to provide the = following feedback.

=C2=A0 =C2=A0 * Defining the s= cope of this specification.

I consider there to be= three primary pieces in an entire push transaction. These are:

a) client <=3D=3D=3D=3D> push service, registerin= g for a push channel to be opened;
b) app server =3D=3D=3D=3D>= push service, asking the push service to deliver a message to a client;
c) push service =3D=3D=3D=3D> client, informing the client of th= e pushed message.

I consider (a) and (c) to be implementation details of = the Push service, which users will rarely get in contact with.
The draft mentions that discovery of push services is consider= ed out of scope. My recommendation is to consider (a), establishing a regis= tration, part of that.

This is relevant to sections the registration part, as = well as the concept of monitoring channels (most notably section 6).
<= div>

=C2=A0 =C2=A0 * Definition of the payload= itself.

This seems to be missing in the draft. I assume we=E2= =80=99ll work on this later? :-).


= =C2=A0 =C2=A0 * Separate channel name from URL / enabling multi-cast delive= ry.

Moving the channel name (or the registration Id, depending on co= ntext) to the message contents allows us to accept an array of recipients, = allowing the Push service to multi-cast the message. This would significant= ly lower the number of requests required for larger broadcasts.

I would recommend having a SHOULD requirement on suppor= ting at least a thousand targets.


= =C2=A0 =C2=A0 * Explicit responses for push requests to the push service.

There are a few reasons why a push request may fail: (1) inv= alid formatting, (2) invalid channel/target, (3) invalid authentication inf= ormation where required. Having a short JSON reply indicating *why* it fail= ed would be very helpful here.

Furthermore, in case we want to enable a continuous Web= Socket-like flow in the future (a persistent channel would also allow for a= synchronous delivery receipts or an upstream channel), the HTTP response co= de may not always be relied upon.


=C2=A0 =C2=A0 * Push services to make a = best effort for message delivery.

Section 7 curren= tly provides very weak guidance on what level of message delivery could be = expected. I would like to see stronger wording here, expressing that push s= ervices are expected to make a best effort at delivering the message (possi= bly through an RFC2119 SHOULD).


=C2=A0 =C2=A0 * Synchronous status repor= ting by the push service.

Section 3 defines that t= he push service can reply with specific status codes depending on whether t= he message could be delivered.

How realistic is it to expect a push service to reply w= ith 200 OK responses? Does any current service support that? I expect this = to become much more asynchronous over time.

It wou= ld also be good to specify the response when a message has been rejected, f= or example because of invalid formatting. I would recommend to change these= to be RFC2119 MAYs.=C2=A0


Thanks,
Peter

NB: considering GCM terminology, =E2=80=9Cchannel=E2=80=9D maps to= =E2=80=9Cregistration Id=E2=80=9D

--047d7bdc8ae260ff8904f958084d-- From nobody Thu May 15 09:16:52 2014 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF811A02A1 for ; Thu, 15 May 2014 09:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fy2sgrswkxyi for ; Thu, 15 May 2014 09:16:46 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42C2E1A02B8 for ; Thu, 15 May 2014 09:16:46 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id w62so1311684wes.2 for ; Thu, 15 May 2014 09:16:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=BqC44C8Yd0cAY4X0k6vVMBdmva95Y+YlpXS/bsXQFOk=; b=Kh7b9PWwCAM+bY62cjK6IB99IdELYCFbh0dIVzgzXqDmQuZPJGCwP5MSFOWUTcA4y9 1z2JJABg9/k4JkAr6pDouijAbK1E0jQH1ziGYtNXxv6w2p4vibRvuVOPAIgMgGOiUIVO cm3ldIibuM3IvL54DD8LpIR/oPE/BRQ8Qz2PuVIuB2lGtywlO3+WafBnRP9ryKjzTnTc /RxLsBJm2VwzpLEjqwv2Ueqtp3mwBX+dS4Vyr4WkdXeFcsYL9sY06YaZ36VaYTE/fUCZ UM3d1nzbS37Ns8NBsjOA4+Aw0tW3mkWIIJhBVJQL58nna+EgqiofsqMza0ftRPXcpZZ8 nQIg== MIME-Version: 1.0 X-Received: by 10.180.77.165 with SMTP id t5mr9559190wiw.38.1400170598037; Thu, 15 May 2014 09:16:38 -0700 (PDT) Received: by 10.194.235.163 with HTTP; Thu, 15 May 2014 09:16:37 -0700 (PDT) In-Reply-To: References: Date: Thu, 15 May 2014 09:16:37 -0700 Message-ID: From: Martin Thomson To: Peter Beverloo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/JvAQNCWkh5fWBNjPyHp2WuQzNbk Cc: webpush@ietf.org Subject: Re: [Webpush] Feedback on Martin's WebPush draft 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, 15 May 2014 16:16:48 -0000 Hi Peter, Responses inline... On 14 May 2014 01:33, Peter Beverloo wrote: > * Defining the scope of this specification. > > I consider there to be three primary pieces in an entire push transaction= . > These are: > > a) client <=3D=3D=3D=3D> push service, registering for a push channel to = be opened; > b) app server =3D=3D=3D=3D> push service, asking the push service to deli= ver a > message to a client; > c) push service =3D=3D=3D=3D> client, informing the client of the pushed = message. > > I consider (a) and (c) to be implementation details of the Push service, > which users will rarely get in contact with. > > The draft mentions that discovery of push services is considered out of > scope. My recommendation is to consider (a), establishing a registration, > part of that. > > This is relevant to sections the registration part, as well as the concep= t > of monitoring channels (most notably section 6). I consider the proprietary nature of this interface to be a problem. > * Definition of the payload itself. > > This seems to be missing in the draft. I assume we=E2=80=99ll work on thi= s later? > :-). Doug asked about it too. That was entirely intentional. The payload is defined. It's whatever you can put in an HTTP PUT. > * Separate channel name from URL / enabling multi-cast delivery. > > Moving the channel name (or the registration Id, depending on context) to > the message contents allows us to accept an array of recipients, allowing > the Push service to multi-cast the message. This would significantly lowe= r > the number of requests required for larger broadcasts. > > I would recommend having a SHOULD requirement on supporting at least a > thousand targets. I think that we need to discuss this further. There's definitely a case for optimization. I didn't include this for a couple of reasons: a) it compromises end-to-end security, and b) I want to find a better way. > * Explicit responses for push requests to the push service. > > There are a few reasons why a push request may fail: (1) invalid formatti= ng, > (2) invalid channel/target, (3) invalid authentication information where > required. Having a short JSON reply indicating *why* it failed would be v= ery > helpful here. I wasn't going to write this down. It turns out that most of these failures aren't actionable in any automated fashion, so the combination of the mechanisms available in HTTP (retry-after, various status codes) and textual bodies for the purposes of manual diagnosis seemed adequate to me. > Furthermore, in case we want to enable a continuous WebSocket-like flow i= n > the future (a persistent channel would also allow for asynchronous delive= ry > receipts or an upstream channel), the HTTP response code may not always b= e > relied upon. Whoa, why would you want a continuous flow? Why not actually use websockets, triggered by a push? > * Push services to make a best effort for message delivery. > > Section 7 currently provides very weak guidance on what level of message > delivery could be expected. I would like to see stronger wording here, > expressing that push services are expected to make a best effort at > delivering the message (possibly through an RFC2119 SHOULD). The purpose of the push server is to perform this function. I'm not sure that there is any sense in attempting to mandate that a push server do what a push server exists for. Even more so for normative language. > * Synchronous status reporting by the push service. > > Section 3 defines that the push service can reply with specific status co= des > depending on whether the message could be delivered. > > How realistic is it to expect a push service to reply with 200 OK respons= es? Fairly, I think. > Does any current service support that? Yes. > I expect this to become much more > asynchronous over time. That's an interesting perspective. It turns out that an end-to-end, positive acknowledgement is an extremely useful property when it comes to reliable distributed system design. > It would also be good to specify the response when a message has been > rejected, for example because of invalid formatting. I would recommend to > change these to be RFC2119 MAYs. Invalid formatting? And I'm not following you on the second point either, what exactly do you think needs changing? From nobody Thu May 15 12:03:03 2014 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C047E1A0178 for ; Thu, 15 May 2014 12:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 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.651, 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 TL0n_zzfQ3rW for ; Thu, 15 May 2014 12:03:00 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C58FB1A014E for ; Thu, 15 May 2014 12:02:59 -0700 (PDT) Received: by mail-qg0-f51.google.com with SMTP id q107so2526090qgd.10 for ; Thu, 15 May 2014 12:02:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=hmtJxgQPH/KkCKPYunO7a4ZPFLOpY5UqMYtt9QsjDMc=; b=B/R7mA42eUksfiMPouyDxEm0mriggZdorKipu7/1KGkFv3OIN8/CSxmzUeTlf/hP7Q XQ6aKJ+PJERoZhFAEinxU+tZN0cicGWIqTZGfkAO5EpA8JUob/AZZUY/n89NkgHsBpHZ X6qCsXTlXbS6ong22s/87J+BzDPVMWQGfKOxZ1tnN8fzGAnHtqu3XQGNAPGv7TVFI6hk vZJXtbBoAsoAKsVQiz2KrTJ9db+uD5/l43YsMNkkewN2XKJrcuzICwY0p8WheKb6Rrus 13VovkGkmpbiTpwr6OJoa8KJQnc5mfg3J7wJEOo6v8ApaRbYaUGaKdBAirchRdlLP7uL dpDA== 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=hmtJxgQPH/KkCKPYunO7a4ZPFLOpY5UqMYtt9QsjDMc=; b=ffut9wMua1FWpeT49RcD+5u1A5xUmPLrzznj2Icq4et2eDWZ/qwoppVjaitZNYY8o4 ucqtlgFAaCbce1nqzzmCT4K8BIK5Lyd1J5bz8yLXNjO82sfOQ6EDYIrEt5HzXJJmwAO7 yrm4hGNNMbP4OkTvYt5P5oQIsmgrCyPEfU5KqFF6HUFHOtKvY/uI44ChYvywiaIlW6qa LLDh16ulKo5VGPt5YUOeqvXrB7v0mjHy6ySgj7JUf9U4LICSSvY2YBbl/Vv7C1WepjlN zWWwB9M+8wmkVvoqgtrv8N2nr5TG+gI2m2aNbkvRt73Wg7kEAlEL0rAdDAn9TJPgCoog vHNA== X-Gm-Message-State: ALoCoQktUGyHqdb3DoIGLe4eFZeTzmb+J59t2M0ggKZqJ3m1Cr/GwlwKmXMlt5uwu5O6R9PRI8zZ MIME-Version: 1.0 X-Received: by 10.140.80.229 with SMTP id c92mr17447197qgd.79.1400180572222; Thu, 15 May 2014 12:02:52 -0700 (PDT) Received: by 10.229.214.196 with HTTP; Thu, 15 May 2014 12:02:52 -0700 (PDT) Date: Thu, 15 May 2014 20:02:52 +0100 Message-ID: From: Peter Beverloo To: webpush@ietf.org, Martin Thomson Content-Type: multipart/alternative; boundary=001a11c126c8a10feb04f974f1ba Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/jL4JFLnbulLzvOMT3SHg2UpIyME Cc: Doug Turner Subject: [Webpush] Message payload format 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, 15 May 2014 19:03:02 -0000 --001a11c126c8a10feb04f974f1ba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Martin, On Thu, May 15, 2014 at 5:16 PM, Martin Thomson wrote: > > > * Definition of the payload itself. > > > > This seems to be missing in the draft. I assume we=E2=80=99ll work on t= his later? > > :-). > > Doug asked about it too. > > That was entirely intentional. The payload is defined. It's whatever > you can put in an HTTP PUT. I see. I understand that by consolidating the Push registration Id and the endpoint, as the Web Push API currently describes, the developer would be able to utilize the entirety of the HTTP PUT request body for the data payload. There are a few reasons why I don't think this is a good idea. (1) It requires a push message to have a 1:1 relationship with a specific channel. This is sufficient for many instant messages use-cases, but presents a limitation for broadcasting (1:N relationships) use-cases. To name two examples, in the instant message situation a message might be directed to a group of people. For a news service, an important article will be sent to a series of users, not just individuals. Sending individual HTTP requests for each of them introduces a large amount of overhead. You mention that it compromises end-to-end security, I would like to understand what you are thinking of exactly. It is true that the developer loses the ability to use per-user encryption keys when multicasting a message, but unless the draft enforces payload encryption this seems like a trade-off which the developer should make. (2) It limits the ability to specify advanced options. GCM supports various advanced options, which have gained a lot of traction from developers. To name a few notable examples of our features: collapse_key - override previous messages to a channel having the same collapse_key. time_to_live - timeout before which the message should be delivered, before it will be dropped. delay_while_idle - postpone delivery of a message until the user wakes up their device. Given the traction these features have, I would propose including options in the protocol. These could be specified in the query string of the PUT request, but this doesn't scale very well, especially when considering the 1:N relationships. As such, what would your opinion be on using a minimalistic JSON syntax? { "recipients": "..", // 1:1 "recipients": ["..", ".."], // 1:N "data": ..., // an object or an opaque string. "delay_while_idle": 1, // optional options. } We can consider standardizing smaller satellite specifications to describe the available options, and the basic behavior to expect from them. Thanks, Peter --001a11c126c8a10feb04f974f1ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Martin,

On Thu, May 15, 2014 a= t 5:16 PM, Martin Thomson=C2=A0<martin.thomson@gmail.com>=C2=A0wrote:
> =C2=A0 =C2=A0 * Definition of the payload itself.
&= gt;
> This seems to be missing in the draft. I assume we=E2=80=99ll w= ork on this later?
> :-).

Doug asked about it too.
That was entirely intentional. =C2=A0The payload is defined. =C2=A0It'= ;s whatever
you can put in an HTTP PUT.

I see. I unders= tand that by consolidating the Push registration Id and the endpoint, as th= e Web Push API currently describes, the developer would be able to utilize = the entirety of the HTTP PUT request body for the data payload.

There are a few reasons why I don't think this is a= good idea.

=C2=A0 =C2=A0 (1) It requires a push m= essage to have a 1:1 relationship with a specific channel.

This is sufficient for many instant messages use-cases, but presents a limi= tation for broadcasting (1:N relationships) use-cases.

=
To name two examples, in the instant message situation a message might= be directed to a group of people. For a news service, an important article= will be sent to a series of users, not just individuals. Sending individua= l HTTP requests for each of them introduces a large amount of overhead.

You mention that it compromises end-to-end security, I = would like to understand what you are thinking of exactly. It is true that = the developer loses the ability to use per-user encryption keys when multic= asting a message, but unless the draft enforces payload encryption this see= ms like a trade-off which the developer should make.

=C2=A0 =C2=A0 (2) It limits the ability to specify adva= nced options.

GCM supports various advanced option= s, which have gained a lot of traction from developers. To name a few notab= le examples of our features:

collapse_key - override previous messages to a channel = having the same=C2=A0collapse_key.
time_to_live - timeout bef= ore which the message should be delivered, before it will be dropped.
delay_while_idle - postpone delivery of a message until the user wakes= up their device.

Given the traction these fea= tures have, I would propose including options in the protocol. These could = be specified in the query string of the PUT request, but this doesn't s= cale very well, especially when considering the 1:N relationships.

As such, what would your opinion be on using a minimali= stic JSON syntax?

{
=C2=A0 =C2=A0 "= recipients": "..", // 1:1
=C2=A0 =C2=A0 "reci= pients": ["..", ".."], // 1:N

=C2=A0 =C2=A0 "data": ..., // an object or an= opaque string.

=C2=A0 =C2=A0 "delay_while_id= le": 1, // optional options.
}

We c= an consider standardizing smaller satellite specifications to describe the = available options, and the basic behavior to expect from them.

Thanks,
Peter
--001a11c126c8a10feb04f974f1ba--