From nobody Mon Mar 7 20:25:25 2016 Return-Path: X-Original-To: webpush@ietfc.amsl.com Delivered-To: webpush@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A1A2F1CDD14 for ; Mon, 7 Mar 2016 20:25:24 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Js8-41NcOxi for ; Mon, 7 Mar 2016 20:25:22 -0800 (PST) Received: from gateway26.websitewelcome.com (gateway26.websitewelcome.com [192.185.3.61]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id E33A01CDCE6 for ; Mon, 7 Mar 2016 20:25:22 -0800 (PST) Received: from cm5.websitewelcome.com (cm5.websitewelcome.com [192.185.178.233]) by gateway26.websitewelcome.com (Postfix) with ESMTP id 6D360FE3B0798 for ; Mon, 7 Mar 2016 22:25:22 -0600 (CST) Received: from gator4135.hostgator.com ([192.185.4.147]) by cm5.websitewelcome.com with id TGRJ1s0093AKFgo01GRKGc; Mon, 07 Mar 2016 22:25:22 -0600 Received: from c-76-103-25-115.hsd1.ca.comcast.net ([76.103.25.115]:33158 helo=[10.0.96.12]) by gator4135.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1ad9Cv-000JFh-UV for webpush@ietf.org; Mon, 07 Mar 2016 22:25:18 -0600 From: Shida Schubert Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 7 Mar 2016 20:25:16 -0800 To: webpush@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) 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: 76.103.25.115 X-Exim-ID: 1ad9Cv-000JFh-UV X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: c-76-103-25-115.hsd1.ca.comcast.net ([10.0.96.12]) [76.103.25.115]:33158 X-Source-Auth: shida@agnada.com X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== Archived-At: Subject: [Webpush] WEBPUSH agenda requests for IETF #95 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 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, 08 Mar 2016 04:25:24 -0000 Hi All; IETF95 in Buenos Aires is approaching and the WEBPUSH WG has 2.0 hours = meeting time as the last session on Monday.=20 Draft submission and initial WG agendas are both due March 21st, so if = you are thinking of bringing in a new draft, please let us know ahead of = time. =20 Even if you are bringing a new draft, big chunk of the time will be = dedicated to moving the core protocol forward so please don=E2=80=99t be = disappointed if you only get 5 minutes to discuss the draft.=20 I also like to encourage people to start the discussions prior to the = meeting if you are bringing in new items. The face to face discussion = time is not to present your idea but to discuss issues and come up with = consensus on resolution.=20 Thanks! Shida as co-chair= From nobody Sun Mar 13 16:47:49 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 375ED12D9D7 for ; Sun, 13 Mar 2016 16:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=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 RcpMUIy4JwOt for ; Sun, 13 Mar 2016 16:47:46 -0700 (PDT) Received: from gateway21.websitewelcome.com (gateway21.websitewelcome.com [192.185.45.95]) (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 4469C12D523 for ; Sun, 13 Mar 2016 16:47:46 -0700 (PDT) Received: from cm4.websitewelcome.com (unknown [108.167.139.16]) by gateway21.websitewelcome.com (Postfix) with ESMTP id 9D87C3EAC3F09 for ; Sun, 13 Mar 2016 18:47:45 -0500 (CDT) Received: from gator4135.hostgator.com ([192.185.4.147]) by cm4.websitewelcome.com with id Vbnk1s00E3AKFgo01bnlxm; Sun, 13 Mar 2016 18:47:45 -0500 Received: from c-76-103-25-115.hsd1.ca.comcast.net ([76.103.25.115]:41715 helo=[10.0.96.12]) by gator4135.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1afFjc-0005Tw-DL for webpush@ietf.org; Sun, 13 Mar 2016 18:47:44 -0500 From: Shida Schubert Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Sun, 13 Mar 2016 16:47:42 -0700 To: webpush@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) 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: 76.103.25.115 X-Exim-ID: 1afFjc-0005Tw-DL X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: c-76-103-25-115.hsd1.ca.comcast.net ([10.0.96.12]) [76.103.25.115]:41715 X-Source-Auth: shida@agnada.com X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== Archived-At: Subject: [Webpush] VAPID as a WG item? X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2016 23:47:48 -0000 All; I am wanting to hear people=E2=80=99s opinion on adopting = draft-thomson-webpush-vapid as a WG item.=20 I will need to talk to AD about adding this to a milestone (or as part = of the core protocol milestone) but before I go ahead and do that, I = want to see if people in the WG are; 1. Interested to work on the problem it=E2=80=99s trying to solve. 2. Willing to review and contribute to move this forward. Thanks! Shida as co-chair From nobody Mon Mar 14 04:46:48 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A759C12DA30 for ; Mon, 14 Mar 2016 04:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 3Iy14xD6TgNz for ; Mon, 14 Mar 2016 04:46:44 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::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 657DE12D589 for ; Mon, 14 Mar 2016 04:46:44 -0700 (PDT) Received: by mail-lb0-x233.google.com with SMTP id bc4so234764351lbc.2 for ; Mon, 14 Mar 2016 04:46:44 -0700 (PDT) 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; bh=0ugc4ym/j7lxVtYEeGpVdaaChIdNasZBN3OlEiArt/g=; b=KkpMUwVBQdAjvWArWX07hqbRAbXDlYT2xq3arHu9KgtM6SEwQY2HqBY9gNAKYV04Dy 6rkBJCBXKqaK1TWE0O8rEACwG+TeYRp+HbedKAgNWEdi5+RLw8a5a6GQxuiEnyB62mh6 P51EJClPFl3+RQmou3nzypmrJ0WIj5tq6iplb52vdFkSCGnHCtBGscXt3S+rOpiRioc6 EcxKtSxSlWGM+93+gvBX1InRD5PcUF6jsHdZolHF4owqZqlc012MW+f43rt4avfOBAEN fd6/1EuldDmURph6iOjfLc+LfOCp/UBSv6nuuuh0aOcDGbxIwtjfxeOuTRCmsmk1ymKm pXDw== 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=0ugc4ym/j7lxVtYEeGpVdaaChIdNasZBN3OlEiArt/g=; b=iCL6Xtly+fQ5hhAObq5UzdpRNX+DtTxeClx0xOEVY6L43aUpNDkFToHf7AGeZccYj3 7gBtZL1McSTLcwIGvrPQx+MHGHgc5gDwLGgVL0Sc/oPszzwaLoQW4j9TKPBkReO+sq5S ATNkdUHM5Q9AvclIyB27hdZwmwBxU+Ui67SJxgelJPCZRt4mhuuYQq2njfTTRLNVxw5d 46Zg3L9sZD3DZ8vwAdfBhKcTtCTKcszvphw3Ba1kmi+Jv9NW78LaYQMqbolKxvl56erh Vcepu5iMsbum0Ajxhn3qWyoPAbbk99x95cbMPklWTdFPjotBRFKHAJya58I5it0duyfh hKKQ== X-Gm-Message-State: AD7BkJKQvP2g3OF4ebTCzPZNTp3FG98fA2JJd4euuANkf6zeq6jqWEiO/T7USvs9oDuEt9JLd3WgGp6z1EUTgfHz MIME-Version: 1.0 X-Received: by 10.25.141.82 with SMTP id p79mr8088680lfd.42.1457956002553; Mon, 14 Mar 2016 04:46:42 -0700 (PDT) Received: by 10.25.20.72 with HTTP; Mon, 14 Mar 2016 04:46:42 -0700 (PDT) In-Reply-To: References: Date: Mon, 14 Mar 2016 11:46:42 +0000 Message-ID: From: Peter Beverloo To: Shida Schubert Content-Type: multipart/alternative; boundary=001a11401c7aa1c983052e00d5b0 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] VAPID as a WG item? X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 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, 14 Mar 2016 11:46:46 -0000 --001a11401c7aa1c983052e00d5b0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, we are. In addition, we're also working on an implementation and expect to feed back our experiences there in case anything comes up. Specific to question (1), there may be some overlap with Martin's question of whether to adopt it as the solution to Issue 44. http://www.ietf.org/mail-archive/web/webpush/current/msg00411.html Thanks, Peter On Sun, Mar 13, 2016 at 11:47 PM, Shida Schubert wrote: > > All; > > I am wanting to hear people=E2=80=99s opinion on adopting > draft-thomson-webpush-vapid as a WG item. > > I will need to talk to AD about adding this to a milestone (or as part of > the core protocol milestone) but before I go ahead and do that, I want to > see if people in the WG are; > > 1. Interested to work on the problem it=E2=80=99s trying to solve. > 2. Willing to review and contribute to move this forward. > > Thanks! > Shida as co-chair > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > --001a11401c7aa1c983052e00d5b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, we are.=C2=A0 In addition, we're also workin= g on an implementation and
expect to feed back our experiences th= ere in case anything comes up.

Specific to questio= n (1), there may be some overlap with Martin's question
of wh= ether to adopt it as the solution to Issue 44.


On Sun, Mar 13, 2016 at 11:47 PM, S= hida Schubert <shida@ntt-at.com> wrote:

All;

I am wanting to hear people=E2=80=99s opinion on adopting draft-thomson-web= push-vapid as a WG item.

I will need to talk to AD about adding this to a milestone (or as part of t= he core protocol milestone) but before I go ahead and do that, I want to se= e if people in the WG are;

1. Interested to work on the problem it=E2=80=99s trying to solve.
2. Willing to review and contribute to move this forward.

Thanks!
Shida as co-chair

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

--001a11401c7aa1c983052e00d5b0-- From nobody Sun Mar 20 23:26:12 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 140BE12D68B; Sun, 20 Mar 2016 23:26:08 -0700 (PDT) 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.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160321062608.8937.41140.idtracker@ietfa.amsl.com> Date: Sun, 20 Mar 2016 23:26:08 -0700 Archived-At: Cc: webpush@ietf.org Subject: [Webpush] I-D Action: draft-ietf-webpush-encryption-02.txt X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 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, 21 Mar 2016 06:26:08 -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 of the IETF. Title : Message Encryption for Web Push Author : Martin Thomson Filename : draft-ietf-webpush-encryption-02.txt Pages : 8 Date : 2016-03-20 Abstract: A message encryption scheme is described for the Web Push protocol. This scheme provides confidentiality and integrity for messages sent from an Application Server to a User Agent. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-webpush-encryption/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-webpush-encryption-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-webpush-encryption-02 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 Sun Mar 20 23:38:24 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D39112D6A1 for ; Sun, 20 Mar 2016 23:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ea79i2mwDn1x for ; Sun, 20 Mar 2016 23:38:21 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001: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 71E1912D63E for ; Sun, 20 Mar 2016 23:28:32 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id o5so115581460iod.2 for ; Sun, 20 Mar 2016 23:28:32 -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; bh=S/KpdAx4ro8vZqenHG/s8uYUYUJjDWVwY4JVhggU9H4=; b=qFye5e9SDc4LjR+Ovkq1YDfl9kfWXfQ2vVrU3xlrBsKmwV/w+NodRH2RcKFts/OswL 1QmUjPXzchMRoNHmd1b0I9ENHC3/m2O0ZWuGbDw5Cgs3lX5ojQLQvmofXAtX/n0hACYF 1J0JCvwROuMjlSwRcqtNubAzPRP5qAFU+QKDm5FHYj0RTp4x6YF2fuhcKl+XW5BiWKgZ RjHiq5o6EcYKznHRo91A3Gon5zW1FUIArbCK6gYDhMajyScMond29EPifyEGO1cHXaPB GAaysSqpT81Qu53LLShCxHCO1zdC7nb4Natf1ZAqFllaWuLVsDRYwY1fLzXU3mM6o+nB +63g== 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; bh=S/KpdAx4ro8vZqenHG/s8uYUYUJjDWVwY4JVhggU9H4=; b=Poygh1aFAm6paHGiug1YXBS7QBLDm9iSX6iU70P1gt3tXoKfp7zccaOp6vIs0hmjYY uyTWZ6J+6SXwAqbEYpJU7jtB1ywtdwYaUrEyUuFmTFrek2dts1KQl90qhID+5Kzhdnxm t8WooaRTBUXZ0geE2VXnjpYPB/aDUMDsAMhV9J7cGYi+yKQucx+L323lldNeyIMugK+c fu/hof94gp1W0C3mcOjP1SRPk/vGAUouVp7ZL8hnGMsqJv1wr1QZ3PTQKQpB292ZBKp8 V+j6FpY4tDdERNL6/OnslG1lYV83ZHwF7a15IKiHnYrWulQAlzKJ5VmA6EUMyxgAFxyL eXyA== X-Gm-Message-State: AD7BkJJf6QG6V7+B9vmD5NL5BCA4ZNyPbYzarENm0JC+RVN5rFVm6zO5qd78GZdbaEldRRU73+ZtMxzHRnYlzQ== MIME-Version: 1.0 X-Received: by 10.107.34.139 with SMTP id i133mr24491137ioi.108.1458541711776; Sun, 20 Mar 2016 23:28:31 -0700 (PDT) Received: by 10.36.43.5 with HTTP; Sun, 20 Mar 2016 23:28:31 -0700 (PDT) In-Reply-To: <20160321062608.8937.41140.idtracker@ietfa.amsl.com> References: <20160321062608.8937.41140.idtracker@ietfa.amsl.com> Date: Mon, 21 Mar 2016 17:28:31 +1100 Message-ID: From: Martin Thomson To: "webpush@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Webpush] I-D Action: draft-ietf-webpush-encryption-02.txt X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 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, 21 Mar 2016 06:38:22 -0000 This updates the draft to reference the updated base specification, which has updated examples, improved padding, and a bunch of things, including actually documenting what is shipping in Chrome and Firefox. ...Deadlines are great, they force me to actually publish rather than relying on github pages. On 21 March 2016 at 17:26, wrote: > Title : Message Encryption for Web Push > Author : Martin Thomson > Filename : draft-ietf-webpush-encryption-02.txt > Pages : 8 > Date : 2016-03-20 > https://tools.ietf.org/html/draft-ietf-webpush-encryption-02 From nobody Mon Mar 21 12:33:17 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 9DF7712DA51; Mon, 21 Mar 2016 12:33:12 -0700 (PDT) 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.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160321193312.12251.71369.idtracker@ietfa.amsl.com> Date: Mon, 21 Mar 2016 12:33:12 -0700 Archived-At: Cc: webpush@ietf.org Subject: [Webpush] I-D Action: draft-ietf-webpush-protocol-04.txt X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 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, 21 Mar 2016 19:33:12 -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 of the IETF. Title : Generic Event Delivery Using HTTP Push Authors : Martin Thomson Elio Damaggio Brian Raymor Filename : draft-ietf-webpush-protocol-04.txt Pages : 31 Date : 2016-03-21 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-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-webpush-protocol-04 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 Thu Mar 24 11:24:00 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 A85BF12DE2F; Fri, 11 Mar 2016 15:05:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160311230539.15028.26523.idtracker@ietfa.amsl.com> Date: Fri, 11 Mar 2016 15:05:39 -0800 Archived-At: X-Mailman-Approved-At: Thu, 24 Mar 2016 11:23:59 -0700 Cc: alissa@cooperw.in, webpush@ietf.org Subject: [Webpush] webpush - Requested session has been scheduled for IETF 95 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 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, 11 Mar 2016 23:05:39 -0000 Dear Shida Schubert, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. webpush Session 1 (2:00:00) Monday, Afternoon Session III 1740-1940 Room Name: Quebracho B size: 75 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Web-Based Push Notifications Area Name: Applications and Real-Time Area Session Requester: Shida Schubert Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: modern appsawg rtcweb tram mmusic httpbis dispatch core Second Priority: netvc perc stir sipcore Third Priority: clue Special Requests: --------------------------------------------------------- From maherrj@googlemail.com Thu Mar 17 20:11:02 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F81012DF08 for ; Thu, 17 Mar 2016 20:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com 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 fEM2OCnxIeqA for ; Thu, 17 Mar 2016 20:11:01 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::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 B7E6D12DF02 for ; Thu, 17 Mar 2016 20:11:00 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id h198so55956944lfh.0 for ; Thu, 17 Mar 2016 20:11:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=mG5gz3f5DdOQcJZxeP2PD9hXgq5h1L9OYMTcDuV1qN8=; b=wvbSPMhqIRZyww8lORxKCkv/RIFQsk1bb5n46b7breXJQJkbIgvmpoB8dUMtKbEfBA MPSTkGBMmmugObrTeePuI7KadXaxiB65K+VTy99dEOTweabKnwptwVH29Bo1e+mHqnBn 9itL+G7ine6A/XLT0cPLCc+aF+yTXoOP7KbjaotV/yYa8dd583M9J5C5f3ARAXtlRhB/ JazNdXzNuGCFJx5R+7voH2R3jkcgK+kgj34wGlDm8RKOFz5tcSJaVEmjDBfBLbanDI4R oV5rSxSTvRJmhxGUpWXBE+R1h556S+rMCoaz6ZUziwsC7h1Nfs1o6cfO2IFrJOj5tGH0 kEdA== 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; bh=mG5gz3f5DdOQcJZxeP2PD9hXgq5h1L9OYMTcDuV1qN8=; b=DQ3nXqbTxs0HmUYOrK2muJ9HWypJvXb4KW1tjPMQA6ggdj4PrtAwABhqh7DNSaZosb f2D5bvfhhpcSzRMhCg+HnMnjhv1slODkz8TsaPwe2D3wepY8G7C5XD2+3xPXmqls2suV LbcHA040afu5YBfsCDliYABZV8KgqSdc7eVTCiboNiqv+9H9a32xBVzCz5T8RIjW+WMc AZ/yN0WH8v/qJ5g2xpGxUQDXvPdWmoTxalReRFCh7bVXP4ckWIev5gBZYR0KYiAdZVE3 h7tVtabUzAEICVT83B3VsSIojB4ZsnngrxMiU/93iVMn/AMuDM6/rRD+9qCrwcxO2S2o ebKw== X-Gm-Message-State: AD7BkJKQcol+6R8bVhLPk4Q6eolGuMScnWQtx7//YisGMcZ2nOSHZDRJ23XLFKXCY83VGXzDP4eYZuQ8kLIxpg== MIME-Version: 1.0 X-Received: by 10.25.152.135 with SMTP id a129mr5048295lfe.40.1458270658621; Thu, 17 Mar 2016 20:10:58 -0700 (PDT) Received: by 10.114.200.208 with HTTP; Thu, 17 Mar 2016 20:10:58 -0700 (PDT) Date: Fri, 18 Mar 2016 11:10:58 +0800 Message-ID: From: Richard Maher To: webpush@ietfa.amsl.com Content-Type: multipart/alternative; boundary=001a114035e297f6eb052e4a18f9 Archived-At: X-Mailman-Approved-At: Thu, 24 Mar 2016 11:23:59 -0700 Subject: Re: [Webpush] Broadcast (was Re: webpush for http2 -02)' X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 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, 18 Mar 2016 03:12:14 -0000 --001a114035e297f6eb052e4a18f9 Content-Type: text/plain; charset=UTF-8 --001a114035e297f6eb052e4a18f9 Content-Type: text/html; charset=UTF-8

--001a114035e297f6eb052e4a18f9-- From nobody Thu Mar 24 11:24:04 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE1EC12D675 for ; Mon, 21 Mar 2016 00:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com 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 p9L4FwGbltoS for ; Mon, 21 Mar 2016 00:06:20 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010: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 D534D12D113 for ; Mon, 21 Mar 2016 00:06:19 -0700 (PDT) Received: by mail-lb0-x232.google.com with SMTP id qe11so66584862lbc.3 for ; Mon, 21 Mar 2016 00:06:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=2qJNzTd74CpBIDpUVW1bn/+0oHSniGbOYWTDWA+3UvE=; b=cNRfPTpDdTsDk2B9QL7kT4Cnv9l9z9G/9JwYu30KkzcSJGHX6tfxiwmXCw2MtwaoOC MEiHM3Z5hxHjgVvEB6RXykMW7ncyQsJ7e4lyN6KXKr4Odw4Ta0GZb5Y3SwvU+gyFXT1q a/vGY3zf9diYDdE7z8d0DM8RJfruMMvy3iVfoLwLAZpVlBCi5LjbnWzdllqtBq+uYspG kEzj4jt0bGvtbW3RaQ/5ta0AYQpwZRSkVsr9+ZF4K3WcUFR8LmTReWFiEeQqHXKemt4L UAYpRgYtAUV0/tAEHBqNwqqxGDaPQDWJ6kjPNlU5J7/dfmEJory0fjGFbbhRtJixk4hp qNeg== 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; bh=2qJNzTd74CpBIDpUVW1bn/+0oHSniGbOYWTDWA+3UvE=; b=WgCF2w8BoGN/Gp+Zkq2jnhcb2TgjPykaBaSV/fsLAKuBVo2B+0krWKzRSMi5LXM2um 9YIuYBkzDODTKmavWVv+57L3mjZIlrjD4m7vhv8DeZ+jNL2i6Qmt0lSWmBA2mZINFCqO u9KTbPklHTBRncYSwSpQy/16nDFfpPPpYAU8yy4mq9PW5X6GqRFx13erAVovXitWu5vz MZ6dlne5LOa4PFXIy3UWtwArrNa8Z+UsIblcMtiA8Ot3lF5z9FZSaSfb8Ec6/6DNTG35 LGwQgZAXPvxuCkzxr0B3k/GXRMY+DKS85wD3Ebl/uHysUczJZUee8hyWL/j25lduRzQ2 skzA== X-Gm-Message-State: AD7BkJJ8kd2/7nFjKd5aXCFjcAllcPjPlnt9bfxSrCHHjJP7wAdTmD0NCJuaB3ZcYGyRVfD/1T+4oAkYSjDzZg== MIME-Version: 1.0 X-Received: by 10.112.136.201 with SMTP id qc9mr7787471lbb.35.1458543977941; Mon, 21 Mar 2016 00:06:17 -0700 (PDT) Received: by 10.114.200.208 with HTTP; Mon, 21 Mar 2016 00:06:17 -0700 (PDT) Date: Mon, 21 Mar 2016 15:06:17 +0800 Message-ID: From: Richard Maher To: Webpush@ietf.org Content-Type: multipart/alternative; boundary=089e011831acb1d265052e89bb92 Archived-At: X-Mailman-Approved-At: Thu, 24 Mar 2016 11:23:59 -0700 Subject: Re: [Webpush] Broadcast (was Re: webpush for http2 -02) X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 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, 21 Mar 2016 07:06:23 -0000 --089e011831acb1d265052e89bb92 Content-Type: text/plain; charset=UTF-8 It looks like it's been a year since "broadcast" was side-lined. Time to get it back on the agenda? Most of the issues solved already by GCM Topics etc? Cheers Richard Maher Benjamin Bangert Wed, 04 March 2015 20:12 UTCShow header After reviewing it, and seeing this, I find myself in agreement. I'd greatly prefer to have a basic protocol in place and some systems using it before broadcast is tackle. On Tue, Feb 24, 2015 at 1:30 PM, Martin Thomson wrote: > The question here for me is how much a protocol can enable this and > how much is best left to services like Notification Hubs, etc... > Those services are offered to those who wish to generate push messages > and as such are less encumbered by a need for standardization. In > fact, much of their value-add derives from the flexibility and > expressiveness of their APIs. They benefit from standardization of a > push protocol in that their downstream interactions become > homogeneous, but a standard for aggregation might only act as a > constraint. > > The intent with the aggregation draft I described was to allow a > single push service provider to provide aggregation capabilities > across its endpoints. That leaves open the possibility of an > aggregator that operates across multiple push services (like the > aforementioned), It's hard to see how that could be driven from > anything but the application side, where standards are less urgent. > > At this stage, my proposal seems more like a half-measure, and I'm > reconsidering whether there is anything worth standardizing on the > aggregation front. Do you think that there is something here worth > pursuing? > > Either way, I think that our efforts are best concentrated on > completing the basic protocol first. > > > On 25 February 2015 at 08:00, Elio Damaggio wrote: > > Hi Martin, > > > > Continuing the discussion on broadcast, from our experience of designing > and operating Azure Notification Hubs, we realized that the major hurdles > for users of a push aggregation system are the following: > > > > 1. Push aggregation have to be regularly synched with other data > stores. > > Aggregation sets are application data, e.g. list of people in "platinum" > status, list of users following a certain sport team, enterprise or social > groups. The protocol has to be amenable to synching operations. In our > experience forcing explicit management of the topics (creation and > deletion) hampers these operations compared to more flexible approaches > where tags are associated to device tokens. Azure Notification Hubs is not > the only system that uses this kind of grouping; Urban Airship and Parse > (now Facebook) have a similar systems. Reference: > https://msdn.microsoft.com/en-us/library/dn530749.aspx. > > > > 2. Topic updates happen from both device and topic perspectives. > > This means that it should be possible to say "add/remove topics A,B, and > C to this user", and also "add/remove users 1,2, and 3 to/from this topic". > In a system where both of this kind of updates happen concurrently, having > to explicitly keep track of topic creation and deletion is burdensome. > > > > 3. Sending to dynamic sets. > > Given the effort that goes into synching topics between the push system > and other stores, it is usually preferable for both the users and the > implementer of the push aggregation system to allow Boolean expressions on > topics to be used as targets. Consider a sports application that sends a > reminder to everyone in Boston about a game between the Red Sox and > Cardinals. If the client app registers tags about interest in teams and > location, then the notification should be targeted to everyone in Boston > who is interested in either the Red Sox or the Cardinals. This condition > can be expressed with the following Boolean expression: (follows_RedSox || > follows_Cardinals) && location_Boston > > > > Notification Hubs, Urban Airship and Parse all support this feature. > Even if this feature is not required to be implemented in all aggregation > servers, it follows that a push endpoint, that is independent of a specific > topic and that takes a target topic (or Boolean expression on topics), is > probably better suited than a topic-specific push URL. > > > > Elio > > > > -----Original Message----- > > From: Webpush [mailto:webpush-bounces@ietf.org] On Behalf Of Martin > Thomson > > Sent: Thursday, February 12, 2015 8:41 PM > > To: Benjamin Bangert > > Cc: webpush@ietf.org > > Subject: [Webpush] Broadcast (was Re: webpush for http2 -02) > > > > On 13 February 2015 at 12:23, Benjamin Bangert > wrote: > >> Section 2: > >> - The diagram is good, but I think adding one variant for broadcast > >> messages would be good. I could see a crypto secured broadcast working > like so: > >> - Broadcast Subscribe (In contrast to normal subscribe) > >> - Browser Agent makes Provide Subscription request to Application, > >> including request (flag) to be issued the broadcast key > >> - Browser stores the broadcast key with the new subscription (rather > >> than generating its own key) > > > > I have proposed a separate document with a different model for > broadcast. In that, clients/browsers/UAs don't drive the subscription to a > broadcast, that broadcast is managed by the application sender. > > I got the sense that there wasn't a whole lot of interest in a broadcast > system in the initial stages. > > > > The advantage there is that you don't have to worry about clients having > to be able to connect to push services that they might not have a > pre-existing relationship with (and therefore federate authorization). The > disadvantage is that it drives more of the responsibility for push fanout > onto the application server. > > > > In your proposal here, how do you see the broadcast subscription being > identified and managed? Would an application request the creation of one > and then distribute it to its clients to subscribe to? > > > > _______________________________________________ > > Webpush mailing list > > Webpush@ietf.org > > https://www.ietf.org/mailman/listinfo/webpush > --089e011831acb1d265052e89bb92 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It looks like it's be= en a year since "broadcast" was side-lined. Time to get it back o= n the agenda?

Most of the issues solved already by GCM Topics etc?

Cheers Richard Maher

Benjamin Bangert <bbangert@mozilla.com>=C2= =A0Wed, 04 March 2015 20:12 UTCShow header

After reviewing it, and seeing=
 this, I find myself in agreement. I'd
greatly prefer to have a basic protocol in place and some systems using it
before broadcast is tackle.

On Tue, Feb 24, 2015 at 1:30 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> The question here for me is how much a protocol can enable this and
> how much is best left to services like Notification Hubs, etc...
> Those services are offered to those who wish to generate push messages
> and as such are less encumbered by a need for standardization.  In
> fact, much of their value-add derives from the flexibility and
> expressiveness of their APIs. They benefit from standardization of a
> push protocol in that their downstream interactions become
> homogeneous, but a standard for aggregation might only act as a
> constraint.
>
> The intent with the aggregation draft I described was to allow a
> single push service provider to provide aggregation capabilities
> across its endpoints.  That leaves open the possibility of an
> aggregator that operates across multiple push services (like the
> aforementioned),  It's hard to see how that could be driven from
> anything but the application side, where standards are less urgent.
>
> At this stage, my proposal seems more like a half-measure, and I'm
> reconsidering whether there is anything worth standardizing on the
> aggregation front.  Do you think that there is something here worth
> pursuing?
>
> Either way, I think that our efforts are best concentrated on
> completing the basic protocol first.
>
>
> On 25 February 2015 at 08:00, Elio Damaggio <elioda@microsoft.com> wrote:
> > Hi Martin,
> >
> > Continuing the discussion on broadcast, from our experience of de=
signing
> and operating Azure Notification Hubs, we realized that the major hurd=
les
> for users of a push aggregation system are the following:
> >
> > 1.      Push aggregation have to be regularly synched with other =
data
> stores.
> > Aggregation sets are application data, e.g. list of people in &qu=
ot;platinum"
> status, list of users following a certain sport team, enterprise or so=
cial
> groups. The protocol has to be amenable to synching operations. In our
> experience forcing explicit management of the topics (creation and
> deletion) hampers these operations compared to more flexible approache=
s
> where tags are associated to device tokens. Azure Notification Hubs is=
 not
> the only system that uses this kind of grouping; Urban Airship and Par=
se
> (now Facebook) have a similar systems. Reference:
> https://msdn.microsoft.com/en-us/library/dn530749.aspx.
> >
> > 2.      Topic updates happen from both device and topic perspecti=
ves.
> > This means that it should be possible to say "add/remove top=
ics A,B, and
> C to this user", and also "add/remove users 1,2, and 3 to/fr=
om this topic".
> In a system where both of this kind of updates happen concurrently, ha=
ving
> to explicitly keep track of topic creation and deletion is burdensome.
> >
> > 3.      Sending to dynamic sets.
> > Given the effort that goes into synching topics between the push =
system
> and other stores, it is usually preferable for both the users and the
> implementer of the push aggregation system to allow Boolean expression=
s on
> topics to be used as targets. Consider a sports application that sends=
 a
> reminder to everyone in Boston about a game between the Red Sox and
> Cardinals. If the client app registers tags about interest in teams an=
d
> location, then the notification should be targeted to everyone in Bost=
on
> who is interested in either the Red Sox or the Cardinals. This conditi=
on
> can be expressed with the following Boolean expression: (follows_RedSo=
x ||
> follows_Cardinals) && location_Boston
> >
> > Notification Hubs, Urban Airship and Parse all support this featu=
re.
> Even if this feature is not required to be implemented in all aggregat=
ion
> servers, it follows that a push endpoint, that is independent of a spe=
cific
> topic and that takes a target topic (or Boolean expression on topics),=
 is
> probably better suited than a topic-specific push URL.
> >
> > Elio
> >
> > -----Original Message-----
> > From: Webpush [mailto:webpush-bounces@ietf.org] On Behalf Of Martin
> Thomson
> > Sent: Thursday, February 12, 2015 8:41 PM
> > To: Benjamin Bangert
> > Cc: webpush=
@ietf.org
> > Subject: [Webpush] Broadcast (was Re: webpush for http2 -02)
> >
> > On 13 February 2015 at 12:23, Benjamin Bangert <bbangert@mozilla.com>
> wrote:
> >> Section 2:
> >> - The diagram is good, but I think adding one variant for bro=
adcast
> >> messages would be good. I could see a crypto secured broadcas=
t working
> like so:
> >>   - Broadcast Subscribe (In contrast to normal subscribe)
> >>   - Browser Agent makes Provide Subscription request to Appli=
cation,
> >> including request (flag) to be issued the broadcast key
> >>   - Browser stores the broadcast key with the new subscriptio=
n (rather
> >> than generating its own key)
> >
> > I have proposed a separate document with a different model for
> broadcast.  In that, clients/browsers/UAs don't drive the subscrip=
tion to a
> broadcast, that broadcast is managed by the application sender.
> > I got the sense that there wasn't a whole lot of interest in =
a broadcast
> system in the initial stages.
> >
> > The advantage there is that you don't have to worry about cli=
ents having
> to be able to connect to push services that they might not have a
> pre-existing relationship with (and therefore federate authorization).=
  The
> disadvantage is that it drives more of the responsibility for push fan=
out
> onto the application server.
> >
> > In your proposal here, how do you see the broadcast subscription =
being
> identified and managed?  Would an application request the creation of =
one
> and then distribute it to its clients to subscribe to?
> >
> > _______________________________________________
> > Webpush mailing list
> > Webpush@iet=
f.org
> > https://www.ietf.org/mailman/listinfo/webpush
>
--089e011831acb1d265052e89bb92-- From nobody Mon Mar 28 14:13:23 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C9D12D155 for ; Mon, 28 Mar 2016 14:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=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 omVbaVNX5DUA for ; Mon, 28 Mar 2016 14:13:18 -0700 (PDT) Received: from gateway20.websitewelcome.com (gateway20.websitewelcome.com [192.185.52.45]) (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 D985012D13A for ; Mon, 28 Mar 2016 14:13:18 -0700 (PDT) Received: from cm6.websitewelcome.com (cm6.websitewelcome.com [108.167.139.19]) by gateway20.websitewelcome.com (Postfix) with ESMTP id CFC4A189015EC for ; Mon, 28 Mar 2016 16:11:18 -0500 (CDT) Received: from gator4135.hostgator.com ([192.185.4.147]) by cm6.websitewelcome.com with id bZBH1s00S3AKFgo01ZBJNE; Mon, 28 Mar 2016 21:11:18 +0000 Received: from garage-jp.static.monkeybrains.net ([199.116.72.155]:49872 helo=[10.1.0.182]) by gator4135.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1akeRR-000Pr9-AO for webpush@ietf.org; Mon, 28 Mar 2016 16:11:17 -0500 From: Shida Schubert Content-Type: multipart/alternative; boundary="Apple-Mail=_78F75E83-FC1D-4EB3-942B-10F2D4785782" Message-Id: Date: Mon, 28 Mar 2016 14:11:15 -0700 To: webpush@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) 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: 199.116.72.155 X-Exim-ID: 1akeRR-000Pr9-AO X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: garage-jp.static.monkeybrains.net ([10.1.0.182]) [199.116.72.155]:49872 X-Source-Auth: shida@agnada.com X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== Archived-At: Subject: [Webpush] Agenda for the BA's session X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 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, 28 Mar 2016 21:13:22 -0000 --Apple-Mail=_78F75E83-FC1D-4EB3-942B-10F2D4785782 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All; Agenda for the session next Monday is online. https://datatracker.ietf.org/meeting/95/agenda/webpush/ = For those presenting issues/drafts, please send in the slides or = whatever materials you will be using by Sunday night addressed at = webpush-chairs@tools.ietf .org. Thanks!=20 Shida= --Apple-Mail=_78F75E83-FC1D-4EB3-942B-10F2D4785782 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
All;

Agenda for the session next Monday is online.


For those presenting issues/drafts, please send in the slides or whatever materials you will be using by Sunday night addressed at webpush-chairs@tools.ietf.org.

Thanks! 
Shida
--Apple-Mail=_78F75E83-FC1D-4EB3-942B-10F2D4785782--