From nobody Wed Jul 1 09:01:58 2015 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 430011A1BEF for ; Wed, 1 Jul 2015 09:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpCxCpCP26kL for ; Wed, 1 Jul 2015 09:01:55 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::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 E862D1A1EEC for ; Wed, 1 Jul 2015 09:01:52 -0700 (PDT) Received: by igblr2 with SMTP id lr2so100969440igb.0 for ; Wed, 01 Jul 2015 09:01:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XlyUAUN8eGi1KOEfe+XtxTE9VGVo7PrO8GIZnWBf9xo=; b=tVl+j2RiTGAc1ZfmmcYI3ZxDNSVn8bWg21wZreL8sxP78KfA/w77eKVivUYLjCc7Bb P9I4rHINbnw+S71HDR8EYXn435TztTtGml3dgNeGrrhFZH/zufbFgBwPOIiGfAfNU89M lhxJmvn0kGEQnu20XLDUmZ5T7FFq+eYKhxEy7c7xK7QvykGrRV89K4ZIb+vbB3iVz2Nh DaqzDZc4rBBzrWq2n7mQplskEj+0sVwZXR3O2aZ25sOHQnrnKmBCp5nf5p9XX43gxRJh 20uU6cOISxX1aohKxiF/NB7eDJ8fKCJAGFAoMbfi6C5KPjvVXhl1m6QwDxHKd+Wad4sK jMRQ== MIME-Version: 1.0 X-Received: by 10.107.3.227 with SMTP id e96mr38874304ioi.50.1435766512315; Wed, 01 Jul 2015 09:01:52 -0700 (PDT) Received: by 10.36.9.207 with HTTP; Wed, 1 Jul 2015 09:01:52 -0700 (PDT) In-Reply-To: <2FC167C1-58A0-48B8-97C7-3C477D6AA92B@ntt-at.com> References: <0067651F-8C90-44DC-BC27-FF6F4D53F654@ntt-at.com> <2FC167C1-58A0-48B8-97C7-3C477D6AA92B@ntt-at.com> Date: Wed, 1 Jul 2015 09:01:52 -0700 Message-ID: From: Costin Manolache To: Shida Schubert Content-Type: multipart/alternative; boundary=001a113f0c5af276d20519d270b9 Archived-At: Cc: "webpush@ietf.org" , webpush-chairs@tools.ietf.org Subject: Re: [Webpush] Adopting thomson-webpush-protocol-00 as WG item 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, 01 Jul 2015 16:01:57 -0000 --001a113f0c5af276d20519d270b9 Content-Type: text/plain; charset=UTF-8 +1 on adopting https://tools.ietf.org/html/draft-thomson-webpush-encryption-00 - which has the most impact on 3p developers. We do care - the discussion regarding the draft was intended as feedback, sorry if I didn't make it clear - IMHO there are parts of https://tools.ietf.org/id/draft-thomson-webpush-protocol-00.txt that may not work well at scale. Costin On Tue, Jun 30, 2015 at 10:25 AM, Shida Schubert wrote: > All, > > I polled the list for adopting the draft in subject 2 weeks ago but saw no > feedback. I am trying to figure out what to make out of that. > > Seeing the discussion regarding the draft on the list, I am assuming > people do care. > > Do people see reasons why the draft should not be adopted as a starting > point for working on the only milestone for the WG? If so I would > appreciate it if you can share what you want to see in the draft before the > draft is adopted as a WG item. > > Thanks! > Shida (as co-chair) > > > On Jun 14, 2015, at 10:00 PM, Shida Schubert wrote: > > (as WG cochair) > > We have a draft for the core push protocol: > > https://tools.ietf.org/id/draft-thomson-webpush-protocol-00.txt > > As mentioned at the last IETF, the call for adopting the merged draft as > the WG item was to be brought to the list as the two drafts presented at > the last IETF were merged. The draft referenced above is such draft, so I > am here to call the adoption of this draft as WG item. > > Please respond by June 29th as to whether the text is acceptable to adopt > and work on as WG draft, or not. > > Regards > > Shida > > > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > > --001a113f0c5af276d20519d270b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 on =C2=A0adopting=C2=A0https://tools.ietf.org/h= tml/draft-thomson-webpush-encryption-00=C2=A0- which has the most impact on=C2=A0
3p developers.=C2=A0

We do care - the discussion rega= rding the draft was intended as feedback, sorry if I didn't make it cle= ar - IMHO there
are parts of=C2=A0https://tools.ietf.org/id/draft-thomson-webpu= sh-protocol-00.txt=C2=A0th= at may not work well at scale.


Costin




On Tue, Jun 30, 201= 5 at 10:25 AM, Shida Schubert <shida@ntt-at.com> wrote:
All,= =C2=A0

I polled the list for adopting the draft in= subject 2 weeks ago but saw no feedback. I am trying to figure out what to= make out of that.

Seeing the discussion regarding= the draft on the list, I am assuming people do care.=C2=A0

<= /div>
Do people see reasons why the draft should not be adopted as a st= arting point for working on the only milestone for the WG? If so I would ap= preciate it if you can share what you want to see in the draft before the d= raft is adopted as a WG item.=C2=A0

Thanks!=C2=A0<= /div>
=C2=A0Shida (as co-chair)
=C2=A0=

On Jun 14, 2015, at 10:00 PM,= Shida Schubert <s= hida@ntt-at.com> wrote:

(as WG cochair)

We have a draft for the core push protocol:
https://tools.ietf.org/id/draft-thomson-webpush-pro= tocol-00.txt

As mentioned at the last IETF, the call for adoptin= g the merged draft as the WG item was to be brought to the list as the two = drafts presented at the last IETF were merged. The draft referenced above i= s such draft, so I am here to call the adoption of =C2=A0this draft as WG i= tem.

Please respond by June 29th as to whether the text i= s acceptable to adopt and work on as WG draft, or not.=C2=A0

Regards=

Shida


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


--001a113f0c5af276d20519d270b9-- From nobody Thu Jul 2 12:46:13 2015 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 EEF201A8A6A for ; Thu, 2 Jul 2015 12:46:11 -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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DElXqNVrOUnN for ; Thu, 2 Jul 2015 12:46:07 -0700 (PDT) Received: from gator4135.hostgator.com (gator4135.hostgator.com [192.185.4.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C6CA1A8A71 for ; Thu, 2 Jul 2015 12:46:07 -0700 (PDT) Received: from [172.56.38.117] (port=58772 helo=[172.20.10.2]) by gator4135.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.85) (envelope-from ) id 1ZAkQw-000841-De; Thu, 02 Jul 2015 14:46:06 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_F8D3D6EA-9556-4B6F-A8C0-D288131E7F89" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Shida Schubert In-Reply-To: Date: Thu, 2 Jul 2015 12:46:02 -0700 Message-Id: References: <0067651F-8C90-44DC-BC27-FF6F4D53F654@ntt-at.com> <2FC167C1-58A0-48B8-97C7-3C477D6AA92B@ntt-at.com> To: Costin Manolache X-Mailer: Apple Mail (2.2098) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator4135.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source-IP: 172.56.38.117 X-Exim-ID: 1ZAkQw-000841-De X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([172.20.10.2]) [172.56.38.117]:58772 X-Source-Auth: shida@agnada.com X-Email-Count: 2 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== Archived-At: Cc: "webpush@ietf.org" , webpush-chairs@tools.ietf.org Subject: Re: [Webpush] Adopting thomson-webpush-protocol-00 as WG item X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 19:46:12 -0000 --Apple-Mail=_F8D3D6EA-9556-4B6F-A8C0-D288131E7F89 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Good to see some feedbacks :) I am extending the poll until next Wednesday (Jul 10th).=20 Thanks=20 Shida as co-chair > On Jul 1, 2015, at 9:01 AM, Costin Manolache wrote: >=20 > +1 on adopting = https://tools.ietf.org/html/draft-thomson-webpush-encryption-00 = - = which has the most impact on=20 > 3p developers.=20 >=20 > We do care - the discussion regarding the draft was intended as = feedback, sorry if I didn't make it clear - IMHO there > are parts of = https://tools.ietf.org/id/draft-thomson-webpush-protocol-00.txt = that = may not work well at scale. >=20 >=20 > Costin >=20 >=20 >=20 >=20 > On Tue, Jun 30, 2015 at 10:25 AM, Shida Schubert > wrote: > All,=20 >=20 > I polled the list for adopting the draft in subject 2 weeks ago but = saw no feedback. I am trying to figure out what to make out of that. >=20 > Seeing the discussion regarding the draft on the list, I am assuming = people do care.=20 >=20 > Do people see reasons why the draft should not be adopted as a = starting point for working on the only milestone for the WG? If so I = would appreciate it if you can share what you want to see in the draft = before the draft is adopted as a WG item.=20 >=20 > Thanks!=20 > Shida (as co-chair) > =20 >=20 >> On Jun 14, 2015, at 10:00 PM, Shida Schubert > wrote: >>=20 >> (as WG cochair) >>=20 >> We have a draft for the core push protocol: >>=20 >> https://tools.ietf.org/id/draft-thomson-webpush-protocol-00.txt = >>=20 >> As mentioned at the last IETF, the call for adopting the merged draft = as the WG item was to be brought to the list as the two drafts presented = at the last IETF were merged. The draft referenced above is such draft, = so I am here to call the adoption of this draft as WG item. >>=20 >> Please respond by June 29th as to whether the text is acceptable to = adopt and work on as WG draft, or not.=20 >>=20 >> Regards >>=20 >> Shida >=20 >=20 > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush = >=20 >=20 --Apple-Mail=_F8D3D6EA-9556-4B6F-A8C0-D288131E7F89 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Good to see some feedbacks :)

I am extending the poll until next = Wednesday (Jul 10th). 

Thanks 
Shida as = co-chair

On Jul 1, 2015, at 9:01 AM, = Costin Manolache <costin@gmail.com> wrote:

+1 on  adopting https://tools.ietf.org/html/draft-thomson-webpush-encryption-00=  - = which has the most impact on 
3p = developers. 

We do care - the = discussion regarding the draft was intended as feedback, sorry if I = didn't make it clear - IMHO there
are parts = of https://tools.ietf.org/id/draft-thomson-webpush-protocol-00.txt=  that = may not work well at scale.


Costin




On Tue, = Jun 30, 2015 at 10:25 AM, Shida Schubert <shida@ntt-at.com> wrote:
All, 

I polled the list for adopting the draft in subject 2 weeks = ago but saw no feedback. I am trying to figure out what to make out of = that.

Seeing = the discussion regarding the draft on the list, I am assuming people do = care. 

Do = people see reasons why the draft should not be adopted as a starting = point for working on the only milestone for the WG? If so I would = appreciate it if you can share what you want to see in the draft before = the draft is adopted as a WG item. 

Thanks! 
 Shida (as co-chair)
 

On Jun = 14, 2015, at 10:00 PM, Shida Schubert <shida@ntt-at.com> wrote:

(as WG = cochair)

We have a draft for the core push = protocol:

https://tools.ietf.org/id/draft-thomson-webpush-protocol-00.txt=

As mentioned at the last IETF, the = call for adopting the merged draft as the WG item was to be brought to = the list as the two drafts presented at the last IETF were merged. The = draft referenced above is such draft, so I am here to call the adoption = of  this draft as WG item.

Please respond by June 29th as to whether the = text is acceptable to adopt and work on as WG draft, or not. 

Regards

Shida


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



= --Apple-Mail=_F8D3D6EA-9556-4B6F-A8C0-D288131E7F89-- From nobody Fri Jul 3 07:15:38 2015 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 22A6B1A00E9 for ; Fri, 3 Jul 2015 07:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 O9eetxZDjwpp for ; Fri, 3 Jul 2015 07:15:36 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::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 883311A01C6 for ; Fri, 3 Jul 2015 07:15:26 -0700 (PDT) Received: by wgjx7 with SMTP id x7so89453634wgj.2 for ; Fri, 03 Jul 2015 07:15:25 -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=v35RRzxyTzByJJKOPZ5llgflw1Gm0f2HR7a/Z0//OMw=; b=advGAcZ60wiTMb3LW1AlrApiXvYh3BQqgY4C41wSmZ1zYc8Sk7pPVfaFlbb7Ru0c/0 I1oYyeP4HSkzHf35VL6qQLxABJbiFyX6NxJ32FDIxm6ExTV1izXMxB+kWYIOcrut+m8/ UxEfkeHvRra7LoINzV5CDfq6Dynukj8tWbdytScsjEPZEjzWBidverfbcaTEoNrhOx9e aQRxL0m5qM2/O7FEt0rqO5Sgotx+3OiNZcmzWUoTRKTXw0i1PsGQCb6XQPkkaHLKw8Ot wmP5Ax9dHO/dwB1yr2oN2xr7pk6/eDxRXjrR3WHm/Ol7zpxAGqa2nagXCan+jRiL7XUP LmMw== 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=v35RRzxyTzByJJKOPZ5llgflw1Gm0f2HR7a/Z0//OMw=; b=fmydd5zMgKXGGrXhlNcGEirgH05twWnq3giWEqqT6qg2ufUK1KJBTo8gWNMLRi7B+1 vFgbZ8oQsqCz77Mzsv6lMRoPgSXnGClCJaHUev8y0H99wmWlEDDl1sT/uqAoC32GchDk +cbRTBzvJgKcl6SBsfDSghfkywKncrnhM0BJ8m6pLy8R7IBVmvuqvZuWCfLHgMzZiHN7 gUQQXvT8DbfzWmXJpmxJZzlHqnDTptCfLCXTF9XVsN/txbG+cvKEYUNmYfgW7iBMM3WE VM9lnonqwZ5VaVxqUYp2uN6X87XVMKHKTzvtCExzUueHdP2iXEHyXTzeK7FLrbn/AsrF Ofyw== X-Gm-Message-State: ALoCoQkrb2zTn7WGblAwc+3cPi7XOZFxMCSME8ZP0NVYSWNb9nWbntI4gA5wg66Yq9V3xYvjjmSX MIME-Version: 1.0 X-Received: by 10.181.13.230 with SMTP id fb6mr26380263wid.47.1435932925262; Fri, 03 Jul 2015 07:15:25 -0700 (PDT) Received: by 10.28.68.86 with HTTP; Fri, 3 Jul 2015 07:15:25 -0700 (PDT) Date: Fri, 3 Jul 2015 15:15:25 +0100 Message-ID: From: Peter Beverloo To: "webpush@ietf.org" Content-Type: multipart/alternative; boundary=f46d043c05bceea1f60519f92f23 Archived-At: Cc: Ryan Sleevi Subject: [Webpush] draft-thomson-webpush-encryption-00: P-256 or Curve25519 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 14:15:37 -0000 --f46d043c05bceea1f60519f92f23 Content-Type: text/plain; charset=UTF-8 Section five of draft-thomson-webpush-encryption-00 currently mandates usage of the P-256 curve. https://tools.ietf.org/html/draft-thomson-webpush-encryption-00#section-5 I'd like us to change this to use Curve25519 instead. Curve25519 provides better security and performance properties than P-256, is easier to implement correctly and is preferable to use in modern protocols. Looking at the holistic picture - we're asking developers to implement a fair amount of cryptographic logic in their back-end systems. The absence of native AEAD_AES_128_GCM support in popular interpreted languages such as Python and PHP is at least equally burdensome to adopters than the curve we decide use. Thanks, Peter --f46d043c05bceea1f60519f92f23 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
--f46d043c05bceea1f60519f92f23-- From nobody Fri Jul 3 14:38:05 2015 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 2BBD81A90BC for ; Fri, 3 Jul 2015 14:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 SGfLICv0xw1D for ; Fri, 3 Jul 2015 14:38:03 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::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 CAD591A90B3 for ; Fri, 3 Jul 2015 14:38:02 -0700 (PDT) Received: by ykdr198 with SMTP id r198so104569029ykd.3 for ; Fri, 03 Jul 2015 14:38:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MVjJTwMgJrbnZHjMH4rBcnFE4ztX8+3APMQkmtJxOSs=; b=cs6zFh+SdGNgLi2u7LzSlz+P/SHlz3WuD0BbfVcTnTjmHlKHkP2aCKC+kkhI1zR1fK zAehcRPBByPq/1mrcse54Pox/Lly2DnDQ9WLhO8IiAI+2lSh7bQUi9PTcVoEhyoKJypL P7R/S2LPr75ez1/5KQDHVAL3Mg2wBO6UgKV2Ztxb3xRv6YGwfSoHPDIcJUeJnkDUUsD7 liwoKErU0bjdK1XGG2iQovdsVlJDo3MxZy4xbY5Gh8cSlKXttDZV1ljSTLne1EGZruft pSQ+KlMxRU6CBuRCR3EMBNhwrAuKTbwaJ7gWmat8oTEEeNZBbTzL9MPf9ak5AO86V5oM C7ng== MIME-Version: 1.0 X-Received: by 10.170.72.86 with SMTP id o83mr45729951yko.98.1435959482179; Fri, 03 Jul 2015 14:38:02 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Fri, 3 Jul 2015 14:38:02 -0700 (PDT) In-Reply-To: References: Date: Fri, 3 Jul 2015 14:38:02 -0700 Message-ID: From: Martin Thomson To: Peter Beverloo Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Ryan Sleevi , "webpush@ietf.org" Subject: Re: [Webpush] draft-thomson-webpush-encryption-00: P-256 or Curve25519 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 21:38:04 -0000 On 3 July 2015 at 07:15, Peter Beverloo wrote: > I'd like us to change this to use Curve25519 instead. Curve25519 provides > better security and performance properties than P-256, is easier to > implement correctly and is preferable to use in modern protocols. I chose P-256 because it's available. 25519 isn't. Not in any meaningful way. Where it is available is rather exceptional: Go has an implementation, and you can pick up PolarSSL or GNUTLS. I didn't check the tree, but my copy of OpenSSL didn't offer 25519. BoringSSL might, but again, that's fairly exceptional. > Looking at the holistic picture - we're asking developers to implement a > fair amount of cryptographic logic in their back-end systems. The absence of > native AEAD_AES_128_GCM support in popular interpreted languages such as > Python and PHP is at least equally burdensome to adopters than the curve we > decide use. That's a markedly different situation. AES-GCM is widely supported. In this case the languages/libraries that don't support it are the exceptions. I did the research for Python a while back. You can use a trunk version of pycrypto (I wonder if that is as poorly maintained as it appears?) or any of a number of small wrappers, which seems a little risky, I'll admit. It's a little sad that PHP is as bad as it is. (I'm a little surprised that you aren't asking for ChaCha/Poly; the comparison between that and AES-GCM is remarkably similar to the 25519 vs. P-256 story, especially for small messages.) From nobody Thu Jul 9 08:04:15 2015 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 AEC881B2A8B for ; Thu, 9 Jul 2015 08:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.312 X-Spam-Level: * X-Spam-Status: No, score=1.312 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 TpD2sdzoaoQu for ; Thu, 9 Jul 2015 08:04:13 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::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 E84DB1B2A91 for ; Thu, 9 Jul 2015 08:03:58 -0700 (PDT) Received: by wiwl6 with SMTP id l6so21521159wiw.0 for ; Thu, 09 Jul 2015 08:03:57 -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 :content-type; bh=oScozHEsDUYoDb3DcnZF5hjZVp6SsCJow3NE2NScG/E=; b=QflDTb5Qg4E0pNWvmp3Q4kukuMkbzSfZjvboUaVGw5v7R6GKWNqEIDVOoEeN9bLx7E SG3hqwKGZOHUV7+9NzBBFD0xpp3jZryxwNI1xhzXiXP4R1B4AGjiU77FsN5JctzKAEFm UByh1kG3iHcj4BCdWLCJNPx9yu+WAKWfZ8ItWftVMbGQIcZOKM5bK8mXlpbGpXO7WeJ9 HYeA+0rTgTLFP2edFNCRidzasIL1NN7dc33kMpOYKsW91RZXaQea/8dmzhPWVj1vlbjO JZBbzAzyZtHM6F6txc3uGi7ysQd4xs7UVGdxXtfauOYgSpUmJrxK1z9Fq4rhix4DcwpX Kp8g== 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:content-type; bh=oScozHEsDUYoDb3DcnZF5hjZVp6SsCJow3NE2NScG/E=; b=F7DLjYx6xP3rE5OAgCs2Ot/RMqDTL8F36tfQn3vAkoDu8aRo01c3t6Zh8Rwt921NbX zrtknROyjt35bfxodTInbHh0OQQq+TJXl2C6tebMBvY1Lg3tedWIyKX9E1V4aYOUSPzq JW5zf+cwndJV7A2p0kyNrIcj0kpaNJw5KhEMAGoBEVlGnBPCTBZbykVnfla8Vda4JZ3k u1BCWCLVXDd6/sLmRV7YyBamCgCwXAT6o6d5VHdrcX0jkrkKgITbijYadGn5i+gaH7kV GfrwUSb1aV1DwKvN0OJzHJbB2U4CSCF38sgwGjzRaUgCslH6fLPMUa7FjxAqPUBoo3C8 83aQ== X-Gm-Message-State: ALoCoQlUi1NRhPBjcb29Y88H2zZRj5QEjyqq+fcKT2ZmmljYjSKrl3KSkgAng1hE0o6t04/70nar MIME-Version: 1.0 X-Received: by 10.194.205.225 with SMTP id lj1mr30752788wjc.138.1436454237605; Thu, 09 Jul 2015 08:03:57 -0700 (PDT) Received: by 10.28.97.6 with HTTP; Thu, 9 Jul 2015 08:03:57 -0700 (PDT) In-Reply-To: References: Date: Thu, 9 Jul 2015 16:03:57 +0100 Message-ID: From: Peter Beverloo To: "webpush@ietf.org" , Shida Schubert Content-Type: multipart/alternative; boundary=047d7bd6b9e491cc78051a729036 Archived-At: Subject: [Webpush] Fwd: draft-thomson-webpush-encryption-00: P-256 or Curve25519 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 15:04:14 -0000 --047d7bd6b9e491cc78051a729036 Content-Type: text/plain; charset=UTF-8 Forwarding since this message has not shown up in the archives. Shida - are people not subscribed to the list not allowed to post either? ---------- Forwarded message ---------- From: Ryan Sleevi Date: Sat, Jul 4, 2015 at 7:08 AM Subject: Re: [Webpush] draft-thomson-webpush-encryption-00: P-256 or Curve25519 To: Martin Thomson Cc: Peter Beverloo , "webpush@ietf.org" < webpush@ietf.org> On Fri, Jul 3, 2015 at 2:38 PM, Martin Thomson wrote: > I chose P-256 because it's available. 25519 isn't. Not in any > meaningful way. Well, without defining a meaningful way, sure :) Are you talking about libraries or implementations? There are a wide variety of implementations, in a wide variety of languages, generally of higher quality than those of P-256 or AES-GCM. Basically, what's the objective criteria we want to use here? That makes it easier than a popularity contest, and at least helps keeps the debate reasoned and objective. For example, if we're going to say "It's available in PHP", but that requires compiling a bleeding edge trunk, then is that available or not? Because if that does count, then it means that if 'we' (the webpush community) were to contribute a curve25519 implementation to php, then the problem is solved, right? And if not, and we mean something like 'available in the PHP deployed by 80% of the web', then that's also helpful to be explicit about. (I say PHP here, but it just as well could be Java or Android or Python) > Where it is available is rather exceptional: Go has > an implementation, and you can pick up PolarSSL or GNUTLS. > I didn't check the tree, but my copy of OpenSSL didn't offer 25519. > BoringSSL might, but again, that's fairly exceptional. > So I presume you've measured "meaningfully available" as being bundled in a particular cryptographic library. But that seems to be a misdirection, because in the holistic picture, AES-GCM is widely available in cryptographic libraries, except not meaningfully available in most languages. Here, I'm using "meaningfully available" for both AES-GCM and P-256 to mean: Secure implementations (e.g. constant time, no timing leaks, correct), ideally with hardware optimizations. In that criteria, anyone "just grabbing" an implementation of P-256 off the shelf is almost certainly going to do it wrong. Even NSS's implementation, until the past month, was questionable. So that's the problem. We've got this shifting goalpost of trying to say what it means for HKDF/AES-GCM/P-256. Simply having it in a language binding doesn't make it easy for developers if they can't use it because the underlying implementation isn't secure, and that's the state for most languages. And if you're going to roll your own, because of the need to actually _ensure_ well-defined security properties, then Curve25519 is far better for that, as it lacks the many implementation sharp edges of 25519. > I did the research for Python a while back. You can use a trunk > version of pycrypto (I wonder if that is as poorly maintained as it > appears?) or any of a number of small wrappers, which seems a little > risky, I'll admit. It's a little sad that PHP is as bad as it is. > So if the argument is that "If it's available in trunk, then it's meaningfully available for the developer population", does that mean that if a patch existed for NSS, we'd call it meaningfully available? Or if there was a native language implementation for some subset of core languages, in a way that was secure (in the ways that most of the P-256 implementations I've looked at are not), we'd move on? --047d7bd6b9e491cc78051a729036 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Forwarding since this message has not shown up in the= archives.

Shida - are people not subscribed to th= e list not allowed to post either?


---------- Forwarded message ----------
From: Ryan Sleevi <sleevi@google.com>
Date: Sat, Jul 4, 2015 a= t 7:08 AM
Subject: Re: [Webpush] draft-thomson-webpush-encryption-00: P-= 256 or Curve25519
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Peter Beverloo <beverloo@google.com>, "webpush@ietf.org" <webpush@ietf.org>

On Fri= , Jul 3, 2015 at 2:38 PM, Martin Thomson <martin.thomson@gmail.com<= /a>> wrote:
I chose P-256 becau= se it's available.=C2=A0 25519 isn't.=C2=A0 Not in any
meaningful way.=C2=A0

Well, without= defining a meaningful way, sure :) Are you talking about libraries or impl= ementations? There are a wide variety of implementations, in a wide variety= of languages, generally of higher quality than those of P-256 or AES-GCM.<= /div>

Basically, what's the objective criteria we wa= nt to use here? That makes it easier than a popularity contest, and at leas= t helps keeps the debate reasoned and objective. For example, if we're = going to say "It's available in PHP", but that requires compi= ling a bleeding edge trunk, then is that available or not? Because if that = does count, then it means that if 'we' (the webpush community) were= to contribute a curve25519 implementation to php, then the problem is solv= ed, right? And if not, and we mean something like 'available in the PHP= deployed by 80% of the web', then that's also helpful to be explic= it about. (I say PHP here, but it just as well could be Java or Android or = Python)
=C2=A0
Where it is available is rather exceptional: Go has
an implementation, and you can pick up PolarSSL or GNUTLS.=C2=A0

I didn't check the tree, but my copy of OpenSSL didn't offer 25519.=
BoringSSL might, but again, that's fairly exceptional.
=

So I presume you've measured "meaningfu= lly available" as being bundled in a particular cryptographic library.= But that seems to be a misdirection, because in the holistic picture, AES-= GCM is widely available in cryptographic libraries, except not meaningfully= available in most languages.

Here, I'm using = "meaningfully available" for both AES-GCM and P-256 to mean: Secu= re implementations (e.g. constant time, no timing leaks, correct), ideally = with hardware optimizations. In that criteria, anyone "just grabbing&q= uot; an implementation of P-256 off the shelf is almost certainly going to = do it wrong. Even NSS's implementation, until the past month, was quest= ionable.

So that's the problem. We've got = this shifting goalpost of trying to say what it means for HKDF/AES-GCM/P-25= 6. Simply having it in a language binding doesn't make it easy for deve= lopers if they can't use it because the underlying implementation isn&#= 39;t secure, and that's the state for most languages. And if you're= going to roll your own, because of the need to actually _ensure_ well-defi= ned security properties, then Curve25519 is far better for that, as it lack= s the many implementation sharp edges of 25519.
= =C2=A0
I did the research for Python a = while back. You can use a trunk
version of pycrypto (I wonder if that is as poorly maintained as it
appears?) or any of a number of small wrappers, which seems a little
risky, I'll admit.=C2=A0 It's a little sad that PHP is as bad as it= is.

So if the argument is that = "If it's available in trunk, then it's meaningfully available = for the developer population", does that mean that if a patch existed = for NSS, we'd call it meaningfully available? Or if there was a native = language implementation for some subset of core languages, in a way that wa= s secure (in the ways that most of the P-256 implementations I've looke= d at are not), we'd move on?


--047d7bd6b9e491cc78051a729036-- From nobody Thu Jul 9 10:46:20 2015 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 EA31B1A1A56 for ; Thu, 9 Jul 2015 10:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 kdeGpFVdnWsr for ; Thu, 9 Jul 2015 10:46:13 -0700 (PDT) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002: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 9CD8C1A1A25 for ; Thu, 9 Jul 2015 10:46:13 -0700 (PDT) Received: by ykey15 with SMTP id y15so46229106yke.3 for ; Thu, 09 Jul 2015 10:46:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=J+Wvcu9JMnvOHjNjbW/7WV55BnqyIJiAZ+gYy2gHgjU=; b=WD+ockoUPJoM1DcBG+dLsiO7mZd6MzJHR9W0ocr8c+eqhqkRzVNudur/fq1DPl+/r7 3fPSHsJlyoTIJ4KNdmcqpxX3PjmJsdf0Q7E6myV9pnpMZjcSrY/zOOqu7QZO9e5a2vmY S1M+iYz4arFr+ROP1CtZ/IyNI7uoz41e2NtlGrOhq4Il7RNzz2R4ergibekI10XLDqkw jWC4aSrsdRpW54NYXhFaqc3Vs0NwL6DH+isKWH85qzEabuu6ytG1QMTrG3WNRdhQVDao HHxZxY1IA7mnVMRFmM4d7PILXPGIpYOyITObbfSO0/dG5l9MchTGi6xQ92DsESDbjCvP 9YUQ== MIME-Version: 1.0 X-Received: by 10.129.93.136 with SMTP id r130mr19371577ywb.52.1436463973070; Thu, 09 Jul 2015 10:46:13 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Thu, 9 Jul 2015 10:46:13 -0700 (PDT) In-Reply-To: References: Date: Thu, 9 Jul 2015 10:46:13 -0700 Message-ID: From: Martin Thomson To: Ryan Sleevi Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" , Peter Beverloo Subject: Re: [Webpush] draft-thomson-webpush-encryption-00: P-256 or Curve25519 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 17:46:18 -0000 I realized that I didn't reply here. What I meant to say was - and it was a subjective assessment, certainly - that availability is important for something like this. And I was only able to find implementations of 25519 in libraries or languages that were inconvenient for my purposes. On the other hand, I have many options for P-256 that I consider acceptable. I'm sensitive to the fact that the distinction between available and good is important, but with all respect to the tin-foil-hats in the galleries, I consider availability to trump things like 100% constant-time, or being close to ideal performance. I realize that you hold high standards in this area. I prefer to be a little more pragmatic. On 3 July 2015 at 23:08, Ryan Sleevi wrote: > > > On Fri, Jul 3, 2015 at 2:38 PM, Martin Thomson > wrote: >> >> I chose P-256 because it's available. 25519 isn't. Not in any >> meaningful way. > > > Well, without defining a meaningful way, sure :) Are you talking about > libraries or implementations? There are a wide variety of implementations, > in a wide variety of languages, generally of higher quality than those of > P-256 or AES-GCM. > > Basically, what's the objective criteria we want to use here? That makes it > easier than a popularity contest, and at least helps keeps the debate > reasoned and objective. For example, if we're going to say "It's available > in PHP", but that requires compiling a bleeding edge trunk, then is that > available or not? Because if that does count, then it means that if 'we' > (the webpush community) were to contribute a curve25519 implementation to > php, then the problem is solved, right? And if not, and we mean something > like 'available in the PHP deployed by 80% of the web', then that's also > helpful to be explicit about. (I say PHP here, but it just as well could be > Java or Android or Python) > >> >> Where it is available is rather exceptional: Go has >> an implementation, and you can pick up PolarSSL or GNUTLS. >> >> >> I didn't check the tree, but my copy of OpenSSL didn't offer 25519. >> BoringSSL might, but again, that's fairly exceptional. > > > So I presume you've measured "meaningfully available" as being bundled in a > particular cryptographic library. But that seems to be a misdirection, > because in the holistic picture, AES-GCM is widely available in > cryptographic libraries, except not meaningfully available in most > languages. > > Here, I'm using "meaningfully available" for both AES-GCM and P-256 to mean: > Secure implementations (e.g. constant time, no timing leaks, correct), > ideally with hardware optimizations. In that criteria, anyone "just > grabbing" an implementation of P-256 off the shelf is almost certainly going > to do it wrong. Even NSS's implementation, until the past month, was > questionable. > > So that's the problem. We've got this shifting goalpost of trying to say > what it means for HKDF/AES-GCM/P-256. Simply having it in a language binding > doesn't make it easy for developers if they can't use it because the > underlying implementation isn't secure, and that's the state for most > languages. And if you're going to roll your own, because of the need to > actually _ensure_ well-defined security properties, then Curve25519 is far > better for that, as it lacks the many implementation sharp edges of 25519. > >> >> I did the research for Python a while back. You can use a trunk >> version of pycrypto (I wonder if that is as poorly maintained as it >> appears?) or any of a number of small wrappers, which seems a little >> risky, I'll admit. It's a little sad that PHP is as bad as it is. > > > So if the argument is that "If it's available in trunk, then it's > meaningfully available for the developer population", does that mean that if > a patch existed for NSS, we'd call it meaningfully available? Or if there > was a native language implementation for some subset of core languages, in a > way that was secure (in the ways that most of the P-256 implementations I've > looked at are not), we'd move on? > From nobody Thu Jul 9 11:09:03 2015 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 0D8761B2B11 for ; Thu, 9 Jul 2015 11:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 jmJCMhaL024Z for ; Thu, 9 Jul 2015 11:08:58 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::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 C06551B2B0E for ; Thu, 9 Jul 2015 11:08:57 -0700 (PDT) Received: by wgxm20 with SMTP id m20so46955947wgx.3 for ; Thu, 09 Jul 2015 11:08:56 -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:content-type; bh=6ephfjDsAgFb0Elq9yXqrYpRL3rYtm9tpzpMUoEU7I0=; b=mPbyeMT+UOKV5ApSJ0c2G7tXiIWRAfxQKO6iVjzgg8FVKM0KEhu850geJ8McqIACMS eq8w1MTg2uOVTl3ky+e29W5ilgqRK7ojYhTvX/9YqrLwQpGcWVU+wGK2lpdOAq453odV x7A0uKjZr94I4kFxWLJK4p2SZDGTT0tQB05Gw/GZ/767UCq4+NCoAJDR1ujAUR3rRZuT JJJBgLowicn7gift6dnN76av2NQu6UYOrv35D2YG8Yxyxb4VLQ4KedScMA8/MY+iTI8Q QnmI9w3oCX+GENWSdbjGeCYasjf5ADeSX1WVRfeYFx+uc14W4+FUK6HZ702Q74EH6MbE 4BFw== 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=6ephfjDsAgFb0Elq9yXqrYpRL3rYtm9tpzpMUoEU7I0=; b=R+xJnT3uK6m8qHzt0AITxPbjoc/8CSwrwJDmHBvk7ca1YDtC+BaWfjBvgoq7uc7fsO /yWCm93/W8qFRAzzlr+KgT1HSjph9tb4KzPd71GGZdnvvazhwhK67R0eKe+wJC3L+7ft ju3v77wxgOF91uXxHeInze1eTvFWEbqopuqKMND6/pPZnqCnDN0Td/kz26TaBDfBfh4s Ixs9/jf3Sm5LBNYhuRF5ufPR6F0JBAn3zABbzXixks9zsz2/dl5MUkdmoOzmZGxwSea6 F1HwJR9eBPuGWLAbXdzELBCH/2AFHR4EZMRSYWwPNsJFN2Lhr6tkCmdW/CG8ncF6JI5i JlOQ== X-Gm-Message-State: ALoCoQktlo6djxw6R0VTZaeigF+ILtPxG6bW/ESGfs6CyXF3UL7BNq5IKDj5G1llaTIhlEUtp5p3 MIME-Version: 1.0 X-Received: by 10.180.14.193 with SMTP id r1mr120325609wic.47.1436465336483; Thu, 09 Jul 2015 11:08:56 -0700 (PDT) Received: by 10.28.97.6 with HTTP; Thu, 9 Jul 2015 11:08:56 -0700 (PDT) In-Reply-To: References: Date: Thu, 9 Jul 2015 19:08:56 +0100 Message-ID: From: Peter Beverloo To: Martin Thomson Content-Type: multipart/alternative; boundary=f46d04138a9d1d2ef0051a75268d Archived-At: Cc: Ryan Sleevi , "webpush@ietf.org" Subject: Re: [Webpush] draft-thomson-webpush-encryption-00: P-256 or Curve25519 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 18:09:01 -0000 --f46d04138a9d1d2ef0051a75268d Content-Type: text/plain; charset=UTF-8 On Thu, Jul 9, 2015 at 6:46 PM, Martin Thomson wrote: > I realized that I didn't reply here. > > What I meant to say was - and it was a subjective assessment, > certainly - that availability is important for something like this. > And I was only able to find implementations of 25519 in libraries or > languages that were inconvenient for my purposes. On the other hand, > I have many options for P-256 that I consider acceptable. > > I'm sensitive to the fact that the distinction between available and > good is important, but with all respect to the tin-foil-hats in the > galleries, I consider availability to trump things like 100% > constant-time, or being close to ideal performance. I realize that > you hold high standards in this area. I prefer to be a little more > pragmatic. > Pragmatically speaking - the intended audience for implementations are the libraries made available to application server developers. This means that the functionality has to be available in the most popular programming languages in order for people to adopt the functionality. We know that at least PHP and Python will have difficulties supporting the entire stack - notably because AES-GCM is unavailable. That's two major languages right there, and it means that it's unreasonable for us to expect any kind of good near-term adoption. (Ignoring the large players for a moment, who build their own solutions.) I agree that unavailability for OpenSSL is not great - let me follow up there. There seems to be a proposed patch for NSS. On a tangent, agl wrote a Python extension. We could do something similar for a PHP module. Neither will solve AES-GCM unavailability. https://github.com/agl/curve25519-donna Thanks, Peter On 3 July 2015 at 23:08, Ryan Sleevi wrote: > > > > > > On Fri, Jul 3, 2015 at 2:38 PM, Martin Thomson > > > wrote: > >> > >> I chose P-256 because it's available. 25519 isn't. Not in any > >> meaningful way. > > > > > > Well, without defining a meaningful way, sure :) Are you talking about > > libraries or implementations? There are a wide variety of > implementations, > > in a wide variety of languages, generally of higher quality than those of > > P-256 or AES-GCM. > > > > Basically, what's the objective criteria we want to use here? That makes > it > > easier than a popularity contest, and at least helps keeps the debate > > reasoned and objective. For example, if we're going to say "It's > available > > in PHP", but that requires compiling a bleeding edge trunk, then is that > > available or not? Because if that does count, then it means that if 'we' > > (the webpush community) were to contribute a curve25519 implementation to > > php, then the problem is solved, right? And if not, and we mean something > > like 'available in the PHP deployed by 80% of the web', then that's also > > helpful to be explicit about. (I say PHP here, but it just as well could > be > > Java or Android or Python) > > > >> > >> Where it is available is rather exceptional: Go has > >> an implementation, and you can pick up PolarSSL or GNUTLS. > >> > >> > >> I didn't check the tree, but my copy of OpenSSL didn't offer 25519. > >> BoringSSL might, but again, that's fairly exceptional. > > > > > > So I presume you've measured "meaningfully available" as being bundled > in a > > particular cryptographic library. But that seems to be a misdirection, > > because in the holistic picture, AES-GCM is widely available in > > cryptographic libraries, except not meaningfully available in most > > languages. > > > > Here, I'm using "meaningfully available" for both AES-GCM and P-256 to > mean: > > Secure implementations (e.g. constant time, no timing leaks, correct), > > ideally with hardware optimizations. In that criteria, anyone "just > > grabbing" an implementation of P-256 off the shelf is almost certainly > going > > to do it wrong. Even NSS's implementation, until the past month, was > > questionable. > > > > So that's the problem. We've got this shifting goalpost of trying to say > > what it means for HKDF/AES-GCM/P-256. Simply having it in a language > binding > > doesn't make it easy for developers if they can't use it because the > > underlying implementation isn't secure, and that's the state for most > > languages. And if you're going to roll your own, because of the need to > > actually _ensure_ well-defined security properties, then Curve25519 is > far > > better for that, as it lacks the many implementation sharp edges of > 25519. > > > >> > >> I did the research for Python a while back. You can use a trunk > >> version of pycrypto (I wonder if that is as poorly maintained as it > >> appears?) or any of a number of small wrappers, which seems a little > >> risky, I'll admit. It's a little sad that PHP is as bad as it is. > > > > > > So if the argument is that "If it's available in trunk, then it's > > meaningfully available for the developer population", does that mean > that if > > a patch existed for NSS, we'd call it meaningfully available? Or if there > > was a native language implementation for some subset of core languages, > in a > > way that was secure (in the ways that most of the P-256 implementations > I've > > looked at are not), we'd move on? > > > --f46d04138a9d1d2ef0051a75268d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jul 9, 2015 at 6:46 PM, Martin Thomson <martin.thomson@gmail.co= m> wrote:
I realized that I didn't re= ply here.

What I meant to say was - and it was a subjective assessment,
certainly - that availability is important for something like this.
And I was only able to find implementations of 25519 in libraries or
languages that were inconvenient for my purposes.=C2=A0 On the other hand,<= br> I have many options for P-256 that I consider acceptable.

I'm sensitive to the fact that the distinction between available and good is important, but with all respect to the tin-foil-hats in the
galleries, I consider availability to trump things like 100%
constant-time, or being close to ideal performance.=C2=A0 I realize that you hold high standards in this area.=C2=A0 I prefer to be a little more pragmatic.

Pragmatically speaking - the= intended audience for implementations are the libraries made available to = application server developers. This means that the functionality has to be = available in the most popular programming languages in order for people to = adopt the functionality.

We know that at least PHP= and Python will have difficulties supporting the entire stack - notably be= cause AES-GCM is unavailable. That's two major languages right there, a= nd it means that it's unreasonable for us to expect any kind of good ne= ar-term adoption. (Ignoring the large players for a moment, who build their= own solutions.)

I agree that unavailability for O= penSSL is not great - let me follow up there. There seems to be a proposed = patch for NSS.

On a tangent, agl wrote a Python ex= tension. We could do something similar for a PHP module. Neither will solve= AES-GCM unavailability.

Thanks,
Peter

On 3 July 2015 at 23:08, Ryan Sleevi <sleevi@google.com> wrote:
>
>
> On Fri, Jul 3, 2015 at 2:38 PM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>>
>> I chose P-256 because it's available.=C2=A0 25519 isn't.= =C2=A0 Not in any
>> meaningful way.
>
>
> Well, without defining a meaningful way, sure :) Are you talking about=
> libraries or implementations? There are a wide variety of implementati= ons,
> in a wide variety of languages, generally of higher quality than those= of
> P-256 or AES-GCM.
>
> Basically, what's the objective criteria we want to use here? That= makes it
> easier than a popularity contest, and at least helps keeps the debate<= br> > reasoned and objective. For example, if we're going to say "I= t's available
> in PHP", but that requires compiling a bleeding edge trunk, then = is that
> available or not? Because if that does count, then it means that if &#= 39;we'
> (the webpush community) were to contribute a curve25519 implementation= to
> php, then the problem is solved, right? And if not, and we mean someth= ing
> like 'available in the PHP deployed by 80% of the web', then t= hat's also
> helpful to be explicit about. (I say PHP here, but it just as well cou= ld be
> Java or Android or Python)
>
>>
>> Where it is available is rather exceptional: Go has
>> an implementation, and you can pick up PolarSSL or GNUTLS.
>>
>>
>> I didn't check the tree, but my copy of OpenSSL didn't off= er 25519.
>> BoringSSL might, but again, that's fairly exceptional.
>
>
> So I presume you've measured "meaningfully available" as= being bundled in a
> particular cryptographic library. But that seems to be a misdirection,=
> because in the holistic picture, AES-GCM is widely available in
> cryptographic libraries, except not meaningfully available in most
> languages.
>
> Here, I'm using "meaningfully available" for both AES-GC= M and P-256 to mean:
> Secure implementations (e.g. constant time, no timing leaks, correct),=
> ideally with hardware optimizations. In that criteria, anyone "ju= st
> grabbing" an implementation of P-256 off the shelf is almost cert= ainly going
> to do it wrong. Even NSS's implementation, until the past month, w= as
> questionable.
>
> So that's the problem. We've got this shifting goalpost of try= ing to say
> what it means for HKDF/AES-GCM/P-256. Simply having it in a language b= inding
> doesn't make it easy for developers if they can't use it becau= se the
> underlying implementation isn't secure, and that's the state f= or most
> languages. And if you're going to roll your own, because of the ne= ed to
> actually _ensure_ well-defined security properties, then Curve25519 is= far
> better for that, as it lacks the many implementation sharp edges of 25= 519.
>
>>
>> I did the research for Python a while back. You can use a trunk >> version of pycrypto (I wonder if that is as poorly maintained as i= t
>> appears?) or any of a number of small wrappers, which seems a litt= le
>> risky, I'll admit.=C2=A0 It's a little sad that PHP is as = bad as it is.
>
>
> So if the argument is that "If it's available in trunk, then = it's
> meaningfully available for the developer population", does that m= ean that if
> a patch existed for NSS, we'd call it meaningfully available? Or i= f there
> was a native language implementation for some subset of core languages= , in a
> way that was secure (in the ways that most of the P-256 implementation= s I've
> looked at are not), we'd move on?
>

--f46d04138a9d1d2ef0051a75268d-- From nobody Thu Jul 9 11:58:52 2015 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 E42D21B2B57 for ; Thu, 9 Jul 2015 11:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.577 X-Spam-Level: X-Spam-Status: No, score=-0.577 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 S3iPvNNKKxMJ for ; Thu, 9 Jul 2015 11:58:42 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (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 681331A2182 for ; Thu, 9 Jul 2015 11:58:42 -0700 (PDT) Received: by wiga1 with SMTP id a1so320872652wig.0 for ; Thu, 09 Jul 2015 11:58:41 -0700 (PDT) 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=QzQpC0iQ/x1pw8voQOZ9lPFmCRPXckqExvnSYgorK6M=; b=FLXdulJSklAvJiLybl74CtXcvNoxlALfQPxgYwhLs1g3GaahzZ2SKZJN5ngz5rH8iD TP/F+GLzUeyECpScBFjpvxFTjs0smcsG8rTYWwUpaSIL9Pw/Orq5HX5Brxz2jG6AlqR4 PZ6cbmDnXyezg8sqh7aIsOR/E+baxaMBlgu0WoWcS9WMq+KWc2H+bMaHCKEAWPc/743v zsPfTpL7+WPfDKRSDl39ZrWfePnvhMFcjcqD+hH+uxmXNCgucOtoy6YNmFBlfH7LGLw7 1L/pbBf3GB8Wm42Nf0EU1guO5bAGjmQ28NdpNTCqGuqDLYRsDRR+rEVq0mfBfgXnKf9G 5++Q== X-Gm-Message-State: ALoCoQkLlSpuivowDzioeodidkF/M3vtj/nddUs0nOcgAT0gIHjcwobiwL5lQ5OFqfwKAzyXvC61 MIME-Version: 1.0 X-Received: by 10.194.23.36 with SMTP id j4mr33438473wjf.105.1436468321012; Thu, 09 Jul 2015 11:58:41 -0700 (PDT) Received: by 10.27.215.213 with HTTP; Thu, 9 Jul 2015 11:58:40 -0700 (PDT) Date: Thu, 9 Jul 2015 11:58:40 -0700 Message-ID: From: Benjamin Bangert To: "webpush@ietf.org" Content-Type: multipart/alternative; boundary=047d7b3a91b2018cb9051a75d88b Archived-At: Subject: [Webpush] comments on latest draft-thomson-webpush-protocol-00 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 18:58:50 -0000 --047d7b3a91b2018cb9051a75d88b Content-Type: text/plain; charset=UTF-8 -Sec 3: Subscribing What should be done if a client has subscribed to as many subscriptions as a server will allow per authenticated-client? "The push server MUST provide a URI for the push resource corresponding to the push message subscription using a link relation of type "urn:ietf:params:push"." Can this be the same push resource for a single authenticated client? Explanation for this in next bit. -Sec 6: Receiving Push Messages This section appears to require a GET for every single subscription. If you have 80 subscriptions, upon connect, you will send 80 GET's. Also, for the server to maintain all your subscriptions, and optionally subscription expiration information, can make a significant impact on the per-connection memory overhead as all this state will need to be maintained on the server handling all these subscriptions. Just as the receipt subscription URL is likely to be the same for the service as a whole, I would propose allowing a Push Service to provide an authenticated client a single push subscription URL for all subscriptions for that client (the Location handed to App-Servers would of course vary for each subscription). The Push Promise path would then need to be the Location given out, so that the client could determine which subscription each message is for. This would allow for a single GET on connect, to begin receiving all notifications, for all subscriptions the client has setup previously. The client would need to realize that if it is already monitoring a subscription for notifications, and subscribes to another that has the same URL, then it should start expecting those notifications to be associated with the existing http2 stream. As this section currently stands, its quite a bit of data to resume subscription flow on a disconnect, which would be very expensive for mobile clients. Having a per-client subscription resource for *all subscriptions* would allow clients to resume notification flow faster on disconnect, with lower server resource overhead as the entire flow of notifications can resume on a reconnect without waiting for all the individual subscription GET's. It would also help avoid server overloading when large batches of clients come online/offline at once (1k clients at 80 subscriptions each connecting at once is a quick 80k hits, etc.). This change would require 7.3 to be updated, so that expiration of subscriptions can be communicated in some other manner, and the client could DELETE them in some other manner. "A 204 (No Content) status code with no associated server pushes indicates that no messages are presently available. This could be because push messages have expired." This seems to indicate that a response will be returned for a GET to a push subscription if there are no messages, once a response has been returned though, no push promise frames for that GET can be sent (as far as I understand http2 stream semantics at least). If there's no messages for a push subscription, is the intention that a 204 is sent, or that its kept open for push promise frames for eventual notifications? -Sec 6.2: Receiving Push Message Receipts If an application server has sent substantial quantities of notifications, all with push receipts, and has failed to take any action to clear its receipt queue, what should be done to indicate to the App-Server that it isn't allowed to send any more until it clears out its receipt queue? It feels like there should be some way to indicate this, as its possible the App-Server is malfunctioning rather than is being a bad actor. Cheers, Ben --047d7b3a91b2018cb9051a75d88b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
-Sec 3: Subscribing
What should be done if a client ha= s subscribed to as many subscriptions as a server will allow per authentica= ted-client?

"The push server MUST provide a URI for the= =20 push resource corresponding to the push message subscription using a=20 link relation of type "urn:ietf:params:push"."

= Can this be the same push resource for a single authenticated client? Expla= nation for this in next bit.

-Sec 6: Receiving Push Messages
This section appears to require a GET for every single subscrip= tion. If you have 80 subscriptions, upon connect, you will send 80 GET'= s. Also, for the server to maintain all your subscriptions, and optionally = subscription expiration information, can make a significant impact on the p= er-connection memory overhead as all this state will need to be maintained = on the server handling all these subscriptions.

Just as the re= ceipt subscription URL is likely to be the same for the service as a whole,= I would propose allowing a Push Service to provide an authenticated client= a single push subscription URL for all subscriptions for that client (the = Location handed to App-Servers would of course vary for each subscription).= The Push Promise path would then need to be the Location given out, so tha= t the client could determine which subscription each message is for.
This would allow for a single GET on connect, to begin receiving all= notifications, for all subscriptions the client has setup previously. The = client would need to realize that if it is already monitoring a subscriptio= n for notifications, and subscribes to another that has the same URL, then = it should start expecting those notifications to be associated with the exi= sting http2 stream.

As this section currently stands, its quit= e a bit of data to resume subscription flow on a disconnect, which would be= very expensive for mobile clients.

Having a per-client subscription= resource for *all subscriptions* would allow clients to resume notificatio= n flow faster on disconnect, with lower server resource overhead as the ent= ire flow of notifications can resume on a reconnect without waiting for all= the individual subscription GET's. It would also help avoid server ove= rloading when large batches of clients come online/offline at once (1k clie= nts at 80 subscriptions each connecting at once is a quick 80k hits, etc.).=

This change would require 7.3 to be updated, so that expirati= on of subscriptions can be communicated in some other manner, and the clien= t could DELETE them in some other manner.


"A 204 (No Conten= t) status code with no=20 associated server pushes indicates that no messages are presently=20 available. This could be because push messages have expired."

=
This seems to indicate that a response will be returned for a GE= T to a push subscription if there are no messages, once a response has been= returned though, no push promise frames for that GET can be sent (as far a= s I understand http2 stream semantics at least). If there's no messages= for a push subscription, is the intention that a 204 is sent, or that its = kept open for push promise frames for eventual notifications?

-Sec 6.2: Receiving Push Message Receipts

If an ap= plication server has sent substantial quantities of notifications, all with= push receipts, and has failed to take any action to clear its receipt queu= e, what should be done to indicate to the App-Server that it isn't allo= wed to send any more until it clears out its receipt queue?

It= feels like there should be some way to indicate this, as its possible the = App-Server is malfunctioning rather than is being a bad actor.

Cheers,
Ben
--047d7b3a91b2018cb9051a75d88b-- From nobody Mon Jul 13 10:40:32 2015 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 3020C1B2CA7 for ; Mon, 13 Jul 2015 10:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.702 X-Spam-Level: X-Spam-Status: No, score=0.702 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_50=0.8, 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 cjJzl-mDtnMk for ; Mon, 13 Jul 2015 10:40:28 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001: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 9F23C1B2A55 for ; Mon, 13 Jul 2015 10:40:28 -0700 (PDT) Received: by igcqs7 with SMTP id qs7so62980912igc.0 for ; Mon, 13 Jul 2015 10:40:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Zn4YgbOyLHVm7zIoOQVK+2blczXtsYKUTfgXLqEQqLQ=; b=RcTN6Ug8dzkSD44eXWvdAxI6NWWW+tu5qTM4Sun/f7IqBwzBMpUOq9N0CaRRUz/n0Q 5f9idi9Kklzl+xkzLmxUaT/sTvyypt9OzOuKbGHq69a3juJt00K59nmTlTgI+lLiMGnZ lYglJZKSbVQ4SfgWCNaWmxPr0slICErcGksOy+kA3u7Hrkl3xmL6zA+CBI6O+vjNV3lX Uteuo6YCpXWcnnGpIgW5QgZRZ2ABPp61ObcJriDP6apqAVhZ9jkKUoHnRCjitQtstwu1 O4vI2oTgliy4+XqnquhbisQKm5YZPfjY8KI/XJirqN3g5pBokC+868APqMVxCPZ8J42V faxg== MIME-Version: 1.0 X-Received: by 10.107.10.167 with SMTP id 39mr6883141iok.0.1436809228159; Mon, 13 Jul 2015 10:40:28 -0700 (PDT) Received: by 10.36.9.207 with HTTP; Mon, 13 Jul 2015 10:40:28 -0700 (PDT) In-Reply-To: References: Date: Mon, 13 Jul 2015 10:40:28 -0700 Message-ID: From: Costin Manolache To: Benjamin Bangert Content-Type: multipart/alternative; boundary=001a113edc56a79338051ac537f4 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] comments on latest draft-thomson-webpush-protocol-00 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 17:40:31 -0000 --001a113edc56a79338051ac537f4 Content-Type: text/plain; charset=UTF-8 On Thu, Jul 9, 2015 at 11:58 AM, Benjamin Bangert wrote: > -Sec 3: Subscribing > What should be done if a client has subscribed to as many subscriptions as > a server will allow per authenticated-client? > > "The push server MUST provide a URI for the push resource corresponding to > the push message subscription using a link relation of type > "urn:ietf:params:push"." > > Can this be the same push resource for a single authenticated client? > Explanation for this in next bit. > > -Sec 6: Receiving Push Messages > > This section appears to require a GET for every single subscription. If > you have 80 subscriptions, upon connect, you will send 80 GET's. Also, for > the server to maintain all your subscriptions, and optionally subscription > expiration information, can make a significant impact on the per-connection > memory overhead as all this state will need to be maintained on the server > handling all these subscriptions. > > Just as the receipt subscription URL is likely to be the same for the > service as a whole, I would propose allowing a Push Service to provide an > authenticated client a single push subscription URL for all subscriptions > for that client (the Location handed to App-Servers would of course vary > for each subscription). The Push Promise path would then need to be the > Location given out, so that the client could determine which subscription > each message is for. > > This would allow for a single GET on connect, to begin receiving all > notifications, for all subscriptions the client has setup previously. The > client would need to realize that if it is already monitoring a > subscription for notifications, and subscribes to another that has the same > URL, then it should start expecting those notifications to be associated > with the existing http2 stream. > > As this section currently stands, its quite a bit of data to resume > subscription flow on a disconnect, which would be very expensive for mobile > clients. > > Having a per-client subscription resource for *all subscriptions* would > allow clients to resume notification flow faster on disconnect, with lower > server resource overhead as the entire flow of notifications can resume on > a reconnect without waiting for all the individual subscription GET's. It > would also help avoid server overloading when large batches of clients come > online/offline at once (1k clients at 80 subscriptions each connecting at > once is a quick 80k hits, etc.). > +1 - I expressed same concerns on a separate thread. > > This change would require 7.3 to be updated, so that expiration of > subscriptions can be communicated in some other manner, and the client > could DELETE them in some other manner. > > > "A 204 (No Content) status code with no associated server pushes indicates > that no messages are presently available. This could be because push > messages have expired." > > This seems to indicate that a response will be returned for a GET to a > push subscription if there are no messages, once a response has been > returned though, no push promise frames for that GET can be sent (as far as > I understand http2 stream semantics at least). If there's no messages for a > push subscription, is the intention that a 204 is sent, or that its kept > open for push promise frames for eventual notifications? > > -Sec 6.2: Receiving Push Message Receipts > > If an application server has sent substantial quantities of notifications, > all with push receipts, and has failed to take any action to clear its > receipt queue, what should be done to indicate to the App-Server that it > isn't allowed to send any more until it clears out its receipt queue? > > It feels like there should be some way to indicate this, as its possible > the App-Server is malfunctioning rather than is being a bad actor. > > Very good question. AppServer may also get disconnected ( for example a restart or upgrade or network issue ) for some time, and it would miss any receipt for messages previously sent. I think a push server supporting receipts will need to have some persistence or some mechanism to indicate that delivery receipts may have been dropped. GCM persists the receipts and handles re-delivery. The more common problem is the App Server can't handle the rate of receipts - most of the times the webpush server has more resources than an app server, so it can accept far more incoming messages than the App Server can process receipts for. This is even worse if push server provides additional broadcast services. In this case I assume HTTP/2 max number of streams will be reached, and it will act as a flow control for the webpush service sending receipts. Costin --001a113edc56a79338051ac537f4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jul 9, 2015 at 11:58 AM, Benjamin Bangert <= ;bbangert@mozilla= .com> wrote:
-S= ec 3: Subscribing
What should be done if a client has subscribed t= o as many subscriptions as a server will allow per authenticated-client?
"The push server MUST provide a URI for the=20 push resource corresponding to the push message subscription using a=20 link relation of type "urn:ietf:params:push"."

= Can this be the same push resource for a single authenticated client? Expla= nation for this in next bit.

-Sec 6: Receiving Push Messages
This section appears to require a GET for every single subscrip= tion. If you have 80 subscriptions, upon connect, you will send 80 GET'= s. Also, for the server to maintain all your subscriptions, and optionally = subscription expiration information, can make a significant impact on the p= er-connection memory overhead as all this state will need to be maintained = on the server handling all these subscriptions.

Just as the re= ceipt subscription URL is likely to be the same for the service as a whole,= I would propose allowing a Push Service to provide an authenticated client= a single push subscription URL for all subscriptions for that client (the = Location handed to App-Servers would of course vary for each subscription).= The Push Promise path would then need to be the Location given out, so tha= t the client could determine which subscription each message is for.
This would allow for a single GET on connect, to begin receiving all= notifications, for all subscriptions the client has setup previously. The = client would need to realize that if it is already monitoring a subscriptio= n for notifications, and subscribes to another that has the same URL, then = it should start expecting those notifications to be associated with the exi= sting http2 stream.

As this section currently stands, its quit= e a bit of data to resume subscription flow on a disconnect, which would be= very expensive for mobile clients.

Having a per-client subscription= resource for *all subscriptions* would allow clients to resume notificatio= n flow faster on disconnect, with lower server resource overhead as the ent= ire flow of notifications can resume on a reconnect without waiting for all= the individual subscription GET's. It would also help avoid server ove= rloading when large batches of clients come online/offline at once (1k clie= nts at 80 subscriptions each connecting at once is a quick 80k hits, etc.).=

<= div>+1 - I expressed same concerns on a separate thread.=C2=A0
=C2=A0

This change would require 7.3 to be u= pdated, so that expiration of subscriptions can be communicated in some oth= er manner, and the client could DELETE them in some other manner.

"A 204 (No Content) status code with no=20 associated server pushes indicates that no messages are presently=20 available. This could be because push messages have expired."

=
This seems to indicate that a response will be returned for a GE= T to a push subscription if there are no messages, once a response has been= returned though, no push promise frames for that GET can be sent (as far a= s I understand http2 stream semantics at least). If there's no messages= for a push subscription, is the intention that a 204 is sent, or that its = kept open for push promise frames for eventual notifications?

-Sec 6.2: Receiving Push Message Receipts

If an ap= plication server has sent substantial quantities of notifications, all with= push receipts, and has failed to take any action to clear its receipt queu= e, what should be done to indicate to the App-Server that it isn't allo= wed to send any more until it clears out its receipt queue?

It= feels like there should be some way to indicate this, as its possible the = App-Server is malfunctioning rather than is being a bad actor.


Very good question.=C2=A0

AppServer =C2=A0may also get disconnected ( for examp= le a restart or upgrade or network issue ) for some time, and it would miss=
any receipt for messages previously sent.=C2=A0

I think a push server supporting receipts will need to have some p= ersistence or some mechanism to indicate that delivery receipts=C2=A0
=
may have been dropped. GCM persists the receipts and handles re-delive= ry.

The more common problem is the App Server can&= #39;t handle the rate of receipts - most of the times the webpush server ha= s more resources
than an app server, so it can accept far more in= coming messages than the App Server can process receipts for.=C2=A0 This is= even worse if=C2=A0
push server provides additional broadcast se= rvices. In this case I assume HTTP/2 max number of streams will be reached,= and it will=C2=A0
act as a flow control for the webpush service = sending receipts.=C2=A0

Costin
--001a113edc56a79338051ac537f4-- From nobody Mon Jul 13 11:06:15 2015 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 59B231B2CEE for ; Mon, 13 Jul 2015 11:06:13 -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 Z5rP6TGniTkE for ; Mon, 13 Jul 2015 11:06:12 -0700 (PDT) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002: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 DAB981B2CEB for ; Mon, 13 Jul 2015 11:06:11 -0700 (PDT) Received: by ykay190 with SMTP id y190so45931467yka.3 for ; Mon, 13 Jul 2015 11:06:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=FDAmMkigcFwe381TKLA6PVUVIj+o+NofJMLGQ4/jE1g=; b=VU9+6RfJLjvtj5bLaYXKzSc+WX8qvEE5Fsh0rK9hbhvrg9eXzK6CQp+3D7uoZV4N6t kqEM01reWFFIYUEw7+eZgO++WxoEklCmIK8VWA0YkPrv+CAIjbQXIN08HQcptX1T+cLm SSBnLz/9TCgRQoubSFXuhDyrRzMQJz8pkwnAAeKIgw49D7q3vy0nzbqJucr4r6XMv0uB uUJnJjsW0HjO/9xsna993JYW5cGseUHbpKJZwQ6XAbeNJYxhaZBJ+Snoe7NSEBpa0OY5 Q2Kmq/PNDWdC1TPaJm/fStCzn0krmva5Fdp5QHGFoNOyo6CCIyUQ+pgFL1V7m0+oXd72 uRaA== MIME-Version: 1.0 X-Received: by 10.170.112.17 with SMTP id e17mr40264314ykb.57.1436810771148; Mon, 13 Jul 2015 11:06:11 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Mon, 13 Jul 2015 11:06:11 -0700 (PDT) Date: Mon, 13 Jul 2015 11:06:11 -0700 Message-ID: From: Martin Thomson To: Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Benjamin Bangert , "webpush@ietf.org" Subject: Re: [Webpush] Receipts (was comments on latest draft-thomson-webpush-protocol-00) X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 18:06:13 -0000 On 13 July 2015 at 10:40, Costin Manolache wrote: >> -Sec 6.2: Receiving Push Message Receipts >> >> If an application server has sent substantial quantities of notifications, >> all with push receipts, and has failed to take any action to clear its >> receipt queue, what should be done to indicate to the App-Server that it >> isn't allowed to send any more until it clears out its receipt queue? >> >> It feels like there should be some way to indicate this, as its possible >> the App-Server is malfunctioning rather than is being a bad actor. >> > > Very good question. > > AppServer may also get disconnected ( for example a restart or upgrade or > network issue ) for some time, and it would miss > any receipt for messages previously sent. > > I think a push server supporting receipts will need to have some persistence > or some mechanism to indicate that delivery receipts > may have been dropped. GCM persists the receipts and handles re-delivery. My analysis of this was that we have two choices: - assume that the application server can handle receipts as they arrive (I hadn't thought of using max concurrent streams as a form of back pressure) - provide full reliability for acknowledgments in the same way as messages It seems that this is in support of the latter. On the latter, the only conclusion I came to was that the acknowledgment had to be held up to the time where a message would expire. That is, if the push service promises to hold a message for a day, and a message is delivered part-way through that day, then the receipt would be held until the remainder of the day elapses. Anything shorter means that the promise the push server makes is not kept. From nobody Mon Jul 13 14:40:51 2015 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 B7B471A3B9D for ; Fri, 3 Jul 2015 23:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 bOJ7J-s5VS6s for ; Fri, 3 Jul 2015 23:08:33 -0700 (PDT) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::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 06FD01A6EDE for ; Fri, 3 Jul 2015 23:08:33 -0700 (PDT) Received: by ykfy125 with SMTP id y125so110628000ykf.1 for ; Fri, 03 Jul 2015 23:08:32 -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:content-type; bh=b3lY1tsgYqplh5+Q0YCUNtoy37IW92Si7yOVLRQZWVQ=; b=NmGpAAF6b2/PZuHQbcxgzk/TJj53X1IK8p2+lqk3pb8E2RKTreO/haZczZVG19YDwI oiY+at9fjRUFzGrMoecz0E73qEZVlcjLH7uEInhV9P8oDXDUCy1DeyUvFs2GNY0YEZ0U u7K4gwTDL3HkrRZxNcxlSjuWlr9IIxbEnyfTbc0b62NNKo4WT88c3N26s0firLL5BRTC PPWmdW3J2YBOxuRDCgK0pqP6szrH3vfOUgKKHZlfT5BKkT0tj57XTwHbmWaenL+ojXvJ 8aqVZsf2wXnbipJo1iNXAVPVB5YAJor2S5LdrB0SiaDFTi/6AvSM+Eo35KE/RpOi7Hx4 +yYA== 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=b3lY1tsgYqplh5+Q0YCUNtoy37IW92Si7yOVLRQZWVQ=; b=ljpSMSjLzmFgsGozR+FNLmxZpV6Oogg9rrx17S6OexS7BzP/lJ7XdNui0Pp1hsO/s+ qjbIHScAChn6iDpO+tkVP/NrFC6Cm24itjcA3FamtL6vHcRzZbTPeeERULctR3ZT43h6 RNY4CTANg6gWx6o9Q/1Y3GFTb8ExakONV7jKE/ssX2kINl+JliS757u2/F1llfFJWiUx 3MufQTKildFSaAJbCymVwTBHD80GMrMJSTLn/by+8i5sMoknkYt1qjaVrww+Fk0HvT4V LBAT8l0gy2PeEE9bgdp1Txt9KEDsF/oPRVkfwGZy/CTXpUHnkS4T8oi7FfJ1d6+9kqdC Ai4Q== X-Gm-Message-State: ALoCoQm9XmemyF8pjoljmcC1YISFUlSby9+LL8/2r3qLnEIFsZ8uy8wsCXwEo4swa6/+KcJoimAm MIME-Version: 1.0 X-Received: by 10.129.80.4 with SMTP id e4mr47739046ywb.31.1435990112352; Fri, 03 Jul 2015 23:08:32 -0700 (PDT) Received: by 10.37.42.65 with HTTP; Fri, 3 Jul 2015 23:08:32 -0700 (PDT) In-Reply-To: References: Date: Fri, 3 Jul 2015 23:08:32 -0700 Message-ID: From: Ryan Sleevi To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1147fb6c8c5d0c051a068024 Archived-At: X-Mailman-Approved-At: Mon, 13 Jul 2015 14:40:49 -0700 Cc: "webpush@ietf.org" , Peter Beverloo Subject: Re: [Webpush] draft-thomson-webpush-encryption-00: P-256 or Curve25519 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, 04 Jul 2015 06:08:34 -0000 --001a1147fb6c8c5d0c051a068024 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 3, 2015 at 2:38 PM, Martin Thomson wrote: > I chose P-256 because it's available. 25519 isn't. Not in any > meaningful way. Well, without defining a meaningful way, sure :) Are you talking about libraries or implementations? There are a wide variety of implementations, in a wide variety of languages, generally of higher quality than those of P-256 or AES-GCM. Basically, what's the objective criteria we want to use here? That makes it easier than a popularity contest, and at least helps keeps the debate reasoned and objective. For example, if we're going to say "It's available in PHP", but that requires compiling a bleeding edge trunk, then is that available or not? Because if that does count, then it means that if 'we' (the webpush community) were to contribute a curve25519 implementation to php, then the problem is solved, right? And if not, and we mean something like 'available in the PHP deployed by 80% of the web', then that's also helpful to be explicit about. (I say PHP here, but it just as well could be Java or Android or Python) > Where it is available is rather exceptional: Go has > an implementation, and you can pick up PolarSSL or GNUTLS. > I didn't check the tree, but my copy of OpenSSL didn't offer 25519. > BoringSSL might, but again, that's fairly exceptional. > So I presume you've measured "meaningfully available" as being bundled in a particular cryptographic library. But that seems to be a misdirection, because in the holistic picture, AES-GCM is widely available in cryptographic libraries, except not meaningfully available in most languages. Here, I'm using "meaningfully available" for both AES-GCM and P-256 to mean: Secure implementations (e.g. constant time, no timing leaks, correct), ideally with hardware optimizations. In that criteria, anyone "just grabbing" an implementation of P-256 off the shelf is almost certainly going to do it wrong. Even NSS's implementation, until the past month, was questionable. So that's the problem. We've got this shifting goalpost of trying to say what it means for HKDF/AES-GCM/P-256. Simply having it in a language binding doesn't make it easy for developers if they can't use it because the underlying implementation isn't secure, and that's the state for most languages. And if you're going to roll your own, because of the need to actually _ensure_ well-defined security properties, then Curve25519 is far better for that, as it lacks the many implementation sharp edges of 25519. > I did the research for Python a while back. You can use a trunk > version of pycrypto (I wonder if that is as poorly maintained as it > appears?) or any of a number of small wrappers, which seems a little > risky, I'll admit. It's a little sad that PHP is as bad as it is. > So if the argument is that "If it's available in trunk, then it's meaningfully available for the developer population", does that mean that if a patch existed for NSS, we'd call it meaningfully available? Or if there was a native language implementation for some subset of core languages, in a way that was secure (in the ways that most of the P-256 implementations I've looked at are not), we'd move on? --001a1147fb6c8c5d0c051a068024 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jul 3, 2015 at 2:38 PM, Martin Thomson <martin.thomson@= gmail.com> wrote:
I chose = P-256 because it's available.=C2=A0 25519 isn't.=C2=A0 Not in any meaningful way.=C2=A0

Well, without defini= ng a meaningful way, sure :) Are you talking about libraries or implementat= ions? There are a wide variety of implementations, in a wide variety of lan= guages, generally of higher quality than those of P-256 or AES-GCM.

Basically, what's the objective criteria we want to u= se here? That makes it easier than a popularity contest, and at least helps= keeps the debate reasoned and objective. For example, if we're going t= o say "It's available in PHP", but that requires compiling a = bleeding edge trunk, then is that available or not? Because if that does co= unt, then it means that if 'we' (the webpush community) were to con= tribute a curve25519 implementation to php, then the problem is solved, rig= ht? And if not, and we mean something like 'available in the PHP deploy= ed by 80% of the web', then that's also helpful to be explicit abou= t. (I say PHP here, but it just as well could be Java or Android or Python)=
=C2=A0
Where it is available= is rather exceptional: Go has
an implementation, and you can pick up PolarSSL or GNUTLS.=C2=A0

I didn't check the tree, but my copy of OpenSSL didn't offer 25519.=
BoringSSL might, but again, that's fairly exceptional.
=

So I presume you've measured "meaningfully ava= ilable" as being bundled in a particular cryptographic library. But th= at seems to be a misdirection, because in the holistic picture, AES-GCM is = widely available in cryptographic libraries, except not meaningfully availa= ble in most languages.

Here, I'm using "m= eaningfully available" for both AES-GCM and P-256 to mean: Secure impl= ementations (e.g. constant time, no timing leaks, correct), ideally with ha= rdware optimizations. In that criteria, anyone "just grabbing" an= implementation of P-256 off the shelf is almost certainly going to do it w= rong. Even NSS's implementation, until the past month, was questionable= .

So that's the problem. We've got this sh= ifting goalpost of trying to say what it means for HKDF/AES-GCM/P-256. Simp= ly having it in a language binding doesn't make it easy for developers = if they can't use it because the underlying implementation isn't se= cure, and that's the state for most languages. And if you're going = to roll your own, because of the need to actually _ensure_ well-defined sec= urity properties, then Curve25519 is far better for that, as it lacks the m= any implementation sharp edges of 25519.
=C2=A0
I did the research for Python a while back. You can use = a trunk
version of pycrypto (I wonder if that is as poorly maintained as it
appears?) or any of a number of small wrappers, which seems a little
risky, I'll admit.=C2=A0 It's a little sad that PHP is as bad as it= is.

So if the argument is that "I= f it's available in trunk, then it's meaningfully available for the= developer population", does that mean that if a patch existed for NSS= , we'd call it meaningfully available? Or if there was a native languag= e implementation for some subset of core languages, in a way that was secur= e (in the ways that most of the P-256 implementations I've looked at ar= e not), we'd move on?

--001a1147fb6c8c5d0c051a068024-- From nobody Sun Jul 19 13:59:42 2015 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 8996B1B2C45 for ; Sun, 19 Jul 2015 13:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 r7lwBmLFsROD for ; Sun, 19 Jul 2015 13:59:40 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0105.outbound.protection.outlook.com [65.55.169.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ED2C1B2C44 for ; Sun, 19 Jul 2015 13:59:39 -0700 (PDT) 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.219.17; Sun, 19 Jul 2015 20:59:38 +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.0219.018; Sun, 19 Jul 2015 20:59:38 +0000 From: Brian Raymor To: Benjamin Bangert , "webpush@ietf.org" Thread-Topic: [Webpush] comments on latest draft-thomson-webpush-protocol-00 Thread-Index: AQHQunlNOBJiEWdv9EaqCn/Jy0/iyZ3epsDw Date: Sun, 19 Jul 2015 20:59:38 +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; x-originating-ip: [2001:df8:ffff:12:91b1:535b:6221:4bfc] x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0647; 5:+X0wgfuAOxH+CUihNRStZNIZyh3oVNBFS8wyQCFBrMm80aZs/ZMEgfALdUfx0zRkp3LjJIRzlVTVltdDGQlc3+lwPHElbu3zOd8LO+O3UxdqXZztYEm0aLq7UyTs3TKVgC8OyaWHlZ93Y2GwXpIHnQ==; 24:rrdSDF1x5m5QF2NncDi+2EWZ7v+szufIQ8uIpSHKwBGVVVHbiSOyVNcGxpag49yAR2+8xbwiIGMdo0V9SzXyNuBZBy6Tpr/sxifvIm+g2/Y=; 20:BHn0OoAnLRncPU08wgEAzLXtk/+BUheqq2pblJLIDT2X/uxltiKTXPrioATzISHricGvBkIyrHcZw2qb0doR0Q== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42140001); SRVR:BY2PR0301MB0647; by2pr0301mb0647: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR0301MB0647; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0647; x-forefront-prvs: 0642A5E7BA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(2900100001)(2950100001)(77096005)(87936001)(2656002)(86362001)(54356999)(76176999)(50986999)(102836002)(5001770100001)(19580395003)(19580405001)(74316001)(5003600100002)(92566002)(107886002)(5001960100002)(40100003)(33656002)(76576001)(62966003)(230783001)(5002640100001)(189998001)(77156002)(2501003)(46102003)(106116001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0647; H:BY2PR0301MB0647.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 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 Jul 2015 20:59:38.0485 (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: Subject: Re: [Webpush] comments on latest draft-thomson-webpush-protocol-00 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, 19 Jul 2015 20:59:41 -0000 DQpPbiBUaHUsIEp1bCA5LCAyMDE1IGF0IDExOjU4IEFNLCBCZW5qYW1pbiBCYW5nZXJ0IDxiYmFu Z2VydEBtb3ppbGxhLmNvbT4gd3JvdGU6DQoNCj4gIkEgMjA0IChObyBDb250ZW50KSBzdGF0dXMg Y29kZSB3aXRoIG5vIGFzc29jaWF0ZWQgc2VydmVyIHB1c2hlcyBpbmRpY2F0ZXMgdGhhdCBubyBt ZXNzYWdlcyBhcmUgcHJlc2VudGx5IGF2YWlsYWJsZS4gVGhpcyBjb3VsZCBiZSBiZWNhdXNlIHB1 c2ggbWVzc2FnZXMgaGF2ZSBleHBpcmVkLiINCj4gVGhpcyBzZWVtcyB0byBpbmRpY2F0ZSB0aGF0 IGEgcmVzcG9uc2Ugd2lsbCBiZSByZXR1cm5lZCBmb3IgYSBHRVQgdG8gYSBwdXNoIHN1YnNjcmlw dGlvbiBpZiB0aGVyZSBhcmUgbm8gbWVzc2FnZXMsIG9uY2UgYSByZXNwb25zZSBoYXMgYmVlbiBy ZXR1cm5lZCB0aG91Z2gsIG5vIHB1c2ggcHJvbWlzZSBmcmFtZXMgZm9yIHRoYXQNCj4gR0VUIGNh biBiZSBzZW50IChhcyBmYXIgYXMgSSB1bmRlcnN0YW5kIGh0dHAyIHN0cmVhbSBzZW1hbnRpY3Mg YXQgbGVhc3QpLiBJZiB0aGVyZSdzIG5vIG1lc3NhZ2VzIGZvciBhIHB1c2ggc3Vic2NyaXB0aW9u LCBpcyB0aGUgaW50ZW50aW9uIHRoYXQgYSAyMDQgaXMgc2VudCwgb3IgdGhhdCBpdHMga2VwdCBv cGVuIGZvciBwdXNoDQo+IHByb21pc2UgZnJhbWVzIGZvciBldmVudHVhbCBub3RpZmljYXRpb25z PyANCg0KVGhpcyBpcyBhIHNwZWNpYWwgY2FzZSBmb3IgcG9sbGluZzoNCg0KICAgICBBIHVzZXIg YWdlbnQgY2FuIHJlcXVlc3QgdGhlIGNvbnRlbnRzIG9mIHRoZSBwdXNoIG1lc3NhZ2UNCiAgICAg c3Vic2NyaXB0aW9uIHJlc291cmNlIGltbWVkaWF0ZWx5IGJ5IGluY2x1ZGluZyBhIFByZWZlciBo ZWFkZXIgZmllbGQNCiAgICAgW1JGQzcyNDBdIHdpdGggYSAid2FpdCIgcGFyYW1ldGVyIHNldCB0 byAiMCIuDQoNCndoaWNoIGltbWVkaWF0ZWx5IHJldHVybnMgYSAyMDQgaWYgbm8gbWVzc2FnZXMg YXJlIGF2YWlsYWJsZS4NCg0KV291bGQgaXQgYmUgY2xlYXJlciBpZiBzZXBhcmF0ZWQgaW50byBp dHMgb3duIHNlY3Rpb24/DQoNCg== From nobody Mon Jul 20 04:41:40 2015 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 36B191A1DBD; Mon, 20 Jul 2015 04:17:05 -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 zyCrfq2nvTkP; Mon, 20 Jul 2015 04:17:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 307341A1DE1; Mon, 20 Jul 2015 04:16:40 -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.0.4.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150720111640.17395.6613.idtracker@ietfa.amsl.com> Date: Mon, 20 Jul 2015 04:16:40 -0700 Archived-At: X-Mailman-Approved-At: Mon, 20 Jul 2015 04:41:35 -0700 Cc: webpush@ietf.org Subject: [Webpush] I-D Action: draft-ietf-webpush-protocol-00.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: Mon, 20 Jul 2015 11:17:05 -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-00.txt Pages : 21 Date : 2015-07-19 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-00 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 Mon Jul 20 05:00:24 2015 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 E47B81A010E for ; Mon, 20 Jul 2015 05:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qq5XZ2QcqfKs for ; Mon, 20 Jul 2015 05:00:21 -0700 (PDT) Received: from gator4135.hostgator.com (gator4135.hostgator.com [192.185.4.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CE211A700B for ; Mon, 20 Jul 2015 05:00:19 -0700 (PDT) Received: from [31.133.179.191] (port=52625 helo=dhcp-b3bf.meeting.ietf.org) by gator4135.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.85) (envelope-from ) id 1ZH9k2-0005Pi-W3 for webpush@ietf.org; Mon, 20 Jul 2015 07:00:19 -0500 From: Shida Schubert Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Date: Mon, 20 Jul 2015 14:00:17 +0200 To: webpush@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) 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: 31.133.179.191 X-Exim-ID: 1ZH9k2-0005Pi-W3 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (dhcp-b3bf.meeting.ietf.org) [31.133.179.191]:52625 X-Source-Auth: shida@agnada.com X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== Archived-At: Subject: [Webpush] Please send slides for Thursday's session 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, 20 Jul 2015 12:00:22 -0000 To those that are presenting on Thursday; Please try to send the chairs, your slide(s) by Wednesday at 5pm. Many Thanks! Shida as co-chair From nobody Mon Jul 20 09:21:38 2015 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 5B0A21A8A66 for ; Mon, 20 Jul 2015 09:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 GZOzO01Ohpc1 for ; Mon, 20 Jul 2015 09:21:28 -0700 (PDT) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) (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 92CA01A8899 for ; Mon, 20 Jul 2015 09:21:28 -0700 (PDT) Received: by wgbcc4 with SMTP id cc4so41638246wgb.3 for ; Mon, 20 Jul 2015 09:21:27 -0700 (PDT) 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=YWjvo/rF768ZAijmu2bsmNKucmTO0FZm/Kv2Z/IynrY=; b=JQXy8S30JiwJUotNq9vIJmLL9Dq/1OVzerNFL1xqyLWLUIu6n2eU/0SaOEqkZGZ8lw OvAryOl1hRvLwWctcayBfkaaSjFDAmg04I8dkZ0BXNyDewikDBGkUHsRSGLYnW5cQboG VFCr08ZgbmMAf9iprfdyOTJTVs36kDftDY4Pnjm1Ev67i/wuuOml3RHNHIiZrwE2EpDG QcCeXOYsmNxmujdgSfD6KI6A6EQx3gz5qIrzTJTRN9ewTpVGesqDBRn2kU6Vnzf/Ufsd QsI5Yz1T72Q4e32L6tWDeS/SiBmUpG5qYSZ0ulPCrGsjAeZL3WtjeJu30o94mY+gMu2h LTeQ== X-Gm-Message-State: ALoCoQkujRWjQeDCvuLRmIFVxsl1TQa8b4l78BbzG9r9Cohie5i+dgiClhcdT+idOc5qPLR3EbTI MIME-Version: 1.0 X-Received: by 10.194.179.136 with SMTP id dg8mr2395515wjc.49.1437409287311; Mon, 20 Jul 2015 09:21:27 -0700 (PDT) Received: by 10.27.33.81 with HTTP; Mon, 20 Jul 2015 09:21:27 -0700 (PDT) In-Reply-To: References: Date: Mon, 20 Jul 2015 09:21:27 -0700 Message-ID: From: Benjamin Bangert To: Brian Raymor Content-Type: multipart/alternative; boundary=089e01493ae4f7b20f051b50ed5b Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] comments on latest draft-thomson-webpush-protocol-00 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, 20 Jul 2015 16:21:31 -0000 --089e01493ae4f7b20f051b50ed5b Content-Type: text/plain; charset=UTF-8 On Sun, Jul 19, 2015 at 1:59 PM, Brian Raymor wrote: > > On Thu, Jul 9, 2015 at 11:58 AM, Benjamin Bangert > wrote: > > > "A 204 (No Content) status code with no associated server pushes > indicates that no messages are presently available. This could be because > push messages have expired." > > This seems to indicate that a response will be returned for a GET to a > push subscription if there are no messages, once a response has been > returned though, no push promise frames for that > > GET can be sent (as far as I understand http2 stream semantics at > least). If there's no messages for a push subscription, is the intention > that a 204 is sent, or that its kept open for push > > promise frames for eventual notifications? > > This is a special case for polling: > > A user agent can request the contents of the push message > subscription resource immediately by including a Prefer header field > [RFC7240] with a "wait" parameter set to "0". > > which immediately returns a 204 if no messages are available. > > Would it be clearer if separated into its own section? > > I'd prefer to not have this ability at all. When a client is connected, they should get notifications as soon as possible upon identifying themselves. Due to the cost of maintaining connections, and for abuse mitigation, I plan on implementing the server such that a failure to immediately begin notification flow results in the connection being dropped. What's the use-case of a client polling over a long-lived connection (which would also mean we're stuck with connections that *could* have notifications sent, but for some reason the client is forcing us to dump the message to storage rather than delivering it immediately)? As my original proposal in my first thread though, I don't want a GET per subscription, that's way too expensive. A single GET to resume the notification flow for all subscriptions is preferred. --089e01493ae4f7b20f051b50ed5b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Sun, Jul 19, 2015 at 1:59 PM, Brian Raymor <Brian.Raymor@micro= soft.com> wrote:

On Thu, Jul 9, 2015 at 11:58 AM, Benjamin Bangert <bbangert@mozilla.com> wrote:

> "A 204 (No Content) status code with no associated server pushes = indicates that no messages are presently available. This could be because p= ush messages have expired."
> This seems to indicate that a response will be returned for a GET to a= push subscription if there are no messages, once a response has been retur= ned though, no push promise frames for that
> GET can be sent (as far as I understand http2 stream semantics at leas= t). If there's no messages for a push subscription, is the intention th= at a 204 is sent, or that its kept open for push
> promise frames for eventual notifications?

This is a special case for polling:

=C2=A0 =C2=A0 =C2=A0A user agent can request the contents of the push messa= ge
=C2=A0 =C2=A0 =C2=A0subscription resource immediately by including a Prefer= header field
=C2=A0 =C2=A0 =C2=A0[RFC7240] with a "wait" parameter set to &quo= t;0".

which immediately returns a 204 if no messages are available.

Would it be clearer if separated into its own section?


I'd prefer to n= ot have this ability at all. When a client is connected, they should get no= tifications as soon as possible upon identifying themselves. Due to the cos= t of maintaining connections, and for abuse mitigation, I plan on implement= ing the server such that a failure to immediately begin notification flow r= esults in the connection being dropped.

What's the use-case of a client polling over a long-lived connecti= on (which would also mean we're stuck with connections that *could* hav= e notifications sent, but for some reason the client is forcing us to dump = the message to storage rather than delivering it immediately)?

As my original proposal in my first thread thou= gh, I don't want a GET per subscription, that's way too expensive. = A single GET to resume the notification flow for all subscriptions is prefe= rred.

--089e01493ae4f7b20f051b50ed5b-- From nobody Mon Jul 20 09:32:19 2015 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 DE3B41ACDBB for ; Mon, 20 Jul 2015 09:32:16 -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 Zl6ZGijVgH33 for ; Mon, 20 Jul 2015 09:32:12 -0700 (PDT) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::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 7274F1ACDB1 for ; Mon, 20 Jul 2015 09:31:55 -0700 (PDT) Received: by ykfw194 with SMTP id w194so62842430ykf.0 for ; Mon, 20 Jul 2015 09:31:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hpJdKSGDiIEztJDn8Gezz8jM/u8vr5WpZxBaFYXNqtE=; b=GY+ql9S3spU79+J+rc3K5oowjDnOPvAwUzyRjUt0gcNHxOOsTfFvBL0kGB572OYmjV eWrLE5XMkuK4wjksKfQlAXtWYIvzz/xtLj1RcqEgPTMTJPWqw+OM0aedvV6JbvCyELuK +VhHETD7ZcdKhQdBYtf81jhwC4a1oLd9FyX7UCFjDlq4i3YpXra2X5pS9MRac8wwJmPc QDOUkzcaArkWTx2XbOlSkUlOT2+jPEQY5OthUEfNanLJJaXqWG6hxQI42LcOxHT5Hk4u 1AlOvZbK0oNCzk8l2nIbBZr3P68FM9cli3cnUBMVyKlbboO0rvNxbid/NKoLjkPeDbU5 glgw== MIME-Version: 1.0 X-Received: by 10.13.216.210 with SMTP id a201mr29877513ywe.89.1437409914913; Mon, 20 Jul 2015 09:31:54 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Mon, 20 Jul 2015 09:31:54 -0700 (PDT) In-Reply-To: References: Date: Mon, 20 Jul 2015 09:31:54 -0700 Message-ID: From: Martin Thomson To: Benjamin Bangert Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Brian Raymor , "webpush@ietf.org" Subject: Re: [Webpush] comments on latest draft-thomson-webpush-protocol-00 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, 20 Jul 2015 16:32:17 -0000 On 20 July 2015 at 09:21, Benjamin Bangert wrote: > What's the use-case of a client polling over a long-lived connection The use case is for a device that is only periodically online (a constrained device) that wants to check in, then immediately go offline again. From nobody Mon Jul 20 10:38:41 2015 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 DEF701A9023 for ; Mon, 20 Jul 2015 10:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 CLs-FHLwZFm5 for ; Mon, 20 Jul 2015 10:38:37 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (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 BA47F1B2CCE for ; Mon, 20 Jul 2015 10:38:36 -0700 (PDT) Received: by wicgb10 with SMTP id gb10so33125621wic.1 for ; Mon, 20 Jul 2015 10:38:35 -0700 (PDT) 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=iGzrCNy050QmQI1gqzkHI7VJs99wNO9LYO0XyKomkBQ=; b=gTWd1tEbxfXGGecfAGyn/Onwk2lFqp4GWldfo9HyUJKHkPt2XYlsc8eq3WHgYN9Nwo IztRN8lMiKLHpYGD77dID+IPtNprN7MgSyYGbDVc0O5RNKHojMuNFJB/R54PdCLxmcp3 cL4W3U1CVxSjh3YZNOvAHOtlTPWs1Oi3wYEHNxg3+OfBr6ukdn5gaks0unV+eKX0ZWZ1 oGglWaA50mPkL4mLj4idvHEcKrAa5ZPtyONbnBNehawHfWyUZKsuAAJjjoeuV+q0GNQo uKLAzACfLodwroAZxZNxrMkNp39Y28/WgxDU+H38QFjTqXlGh6fwYFQ7/7TZnaGe6V96 nZZw== X-Gm-Message-State: ALoCoQkJpxUqsCuamadm9pcLg7p3VezLs4XyBxyfytGGyzdr4n/WQitdR6B1hC9H/E1k2ZmeTeLx MIME-Version: 1.0 X-Received: by 10.180.72.145 with SMTP id d17mr23890005wiv.69.1437413915483; Mon, 20 Jul 2015 10:38:35 -0700 (PDT) Received: by 10.27.33.81 with HTTP; Mon, 20 Jul 2015 10:38:35 -0700 (PDT) In-Reply-To: References: Date: Mon, 20 Jul 2015 10:38:35 -0700 Message-ID: From: Benjamin Bangert To: Martin Thomson Content-Type: multipart/alternative; boundary=14dae9cc9492d3fbf8051b5201b5 Archived-At: Cc: Brian Raymor , "webpush@ietf.org" Subject: Re: [Webpush] comments on latest draft-thomson-webpush-protocol-00 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, 20 Jul 2015 17:38:39 -0000 --14dae9cc9492d3fbf8051b5201b5 Content-Type: text/plain; charset=UTF-8 On Mon, Jul 20, 2015 at 9:31 AM, Martin Thomson wrote: > On 20 July 2015 at 09:21, Benjamin Bangert wrote: > > What's the use-case of a client polling over a long-lived connection > > The use case is for a device that is only periodically online (a > constrained device) that wants to check in, then immediately go > offline again. > Ah, so after such a request the server can immediately drop the connection (might be useful to mention in the spec). This would presume that it'd be a GET to a single notification subscription URL. If its needed for every single subscription URL, that creates a lot of work for both the client, and the server, which doesn't seem very beneficial for a constrained device to be doing. --14dae9cc9492d3fbf8051b5201b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jul 20, 2015 at 9:31 AM, Martin Thomson <martin.thomson@gmail= .com> wrote:
On 20 July 2015 at 09:21, Benjamin Bangert <bbangert@mozilla.com> wrote:
> What's the use-case of a client polling over a long-lived connecti= on

The use case is for a device that is only periodically online (a
constrained device) that wants to check in, then immediately go
offline again.

Ah, so after such a= request the server can immediately drop the connection (might be useful to= mention in the spec). This would presume that it'd be a GET to a singl= e notification subscription URL. If its needed for every single subscriptio= n URL, that creates a lot of work for both the client, and the server, whic= h doesn't seem very beneficial for a constrained device to be doing.
--14dae9cc9492d3fbf8051b5201b5-- From nobody Mon Jul 20 14:41:36 2015 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 9370C1A1AA2 for ; Mon, 20 Jul 2015 14:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.226 X-Spam-Level: X-Spam-Status: No, score=0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, T_RP_MATCHES_RCVD=-0.01] 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 dFErFaDjJy71 for ; Mon, 20 Jul 2015 14:41:33 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 330401A1A8C for ; Mon, 20 Jul 2015 14:41:33 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id t6KLfVLA007021 for ; Mon, 20 Jul 2015 15:41:31 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Mon, 20 Jul 2015 15:41:30 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([::1]) by EXCHANGE.cablelabs.com ([::1]) with mapi id 14.03.0224.002; Mon, 20 Jul 2015 15:41:30 -0600 From: Darshak Thakore To: "webpush@ietf.org" Thread-Topic: [Webpush] comments on latest draft-thomson-webpush-protocol-00 Thread-Index: AQHQunlLM+hV2NIVmEuOC+Bk2k+U+Z3ju0gAgAFEnICAAALrAP//8eCA Date: Mon, 20 Jul 2015 21:41:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 x-originating-ip: [10.5.0.27] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Webpush] comments on latest draft-thomson-webpush-protocol-00 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, 20 Jul 2015 21:41:34 -0000 It seems like we do want some mechanism that allows a client to retrieve notifications for all subscriptions with a single fetch. For IoT based use cases also this is desirable. I guess this keeps going back to the aggregation-vs-disaggregation discussion. However I=B9m wondering if its possible to define/create a sort of =B3aggregation-on-demand=B2 mode with t= he default being the current =B3disaggregation=B2 mode. For example, once a client/UA has subscribed for the first time and holds 1 subscription, when it wants to create subsequent subscriptions, it can include the first subscription in the request: POST /subscribe/ HTTP/1.1 HOST: push.example.net Link: ; rel=3D=B3urn:ietf:params:push:subcribe=B2 (I=B9m not sure if its ok to use = Link header in a request, if not we need to find something more suitable) When a PS processes this request, it can associate the new subscription with the one provided. (I think the additional data stored by the PS to achieve this should be minimal). The response would contain the new subscription info as currently defined (and maybe something additional to indicate that the new subscription is tied to the one in the request) When receiving PUSH messages, a client/UA can make a single GET request to the primary subscription resource and the server will send push notifications for all subscriptions associated with the primary subscription. For example, the request would be HEADERS [stream 7] +EHD_STREAM +END_HEADERS :method =3D GET :path =3D /s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx :authority =3D push.example.net And the corresponding response would be PUSH_PROMISE [stream 7; promised stream 4] +END_HEADERS :method =3D GET :path =3D /d/qDIYHNcfAIPP_5ITvURr-d6BGtYnTRnk :authority =3D push.example.net HEADERS [stream 4] +END_HEADERS :status =3D 200 =8B=8BOTHER HEADERS =8B=8B :content-loc =3D /s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx DATA [stream 4] +END_STREAM iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB PUSH_PROMISE [stream 7; promised stream 6] +END_HEADERS :method =3D GET :path =3D /d/gjuNJTYuZXkyylOOtjfAEo6ktRHCADui :authority =3D push.example.net HEADERS [stream 6] +END_HEADERS :status =3D 200 =8B=8BOTHER HEADERS =8B=8B :content-loc =3D /s/hJ0jW1ElCjhjfwwh4kTQw7rEYK4QyFFW DATA [stream 6] +END_STREAM {encoded/encrypted-notification-message} =8B=8B additional PUSH messages for other subscriptions =8B=8B In the above example, the responses can include a Content-Location (or some other appropriate) header to indicate the associated subscription for the notification message. This would allow the client/UA to send just one GET request to retrieve (and keep receiving) notifications on all its active subscriptions. A client/UA may even choose to keep certain subscriptions separate and group only a subset of them (this would be useful in IoT like cases) Darshak On 7/20/15, 10:31 AM, "Webpush on behalf of Martin Thomson" wrote: >On 20 July 2015 at 09:21, Benjamin Bangert wrote: >> What's the use-case of a client polling over a long-lived connection > >The use case is for a device that is only periodically online (a >constrained device) that wants to check in, then immediately go >offline again. > >_______________________________________________ >Webpush mailing list >Webpush@ietf.org >https://www.ietf.org/mailman/listinfo/webpush From nobody Mon Jul 20 23:43:41 2015 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 451FB1AD09A for ; Mon, 20 Jul 2015 23:43:39 -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 8GglV0Dq_-Ao for ; Mon, 20 Jul 2015 23:43:36 -0700 (PDT) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002: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 6A40B1AD094 for ; Mon, 20 Jul 2015 23:43:36 -0700 (PDT) Received: by ykay190 with SMTP id y190so157790421yka.3 for ; Mon, 20 Jul 2015 23:43:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=WCJth9L2IBbzcOwE89eCXpRmBVe67L3ZOYuN7lqIjtI=; b=kOfmI3ZK8viKD8MWbbu5pioOcQvLTuJeUf6L1wMaRZLVSjx17QqYbyr4+lkSFzHPTo NjQg0H9YrOJEFPeatswFwbEnaWmEjD+VmxvF3VxOlgVZ+VS6YjMEc05hK4ff7eIly4oi Z6iAUIuZSmDBOdZHCN1ZMckmB6YJg1Msj3vb9kqVuLvRVn+6lvmRICsv/WY80Tf63JGI Mdeq5of3lZyPSLxW4ccoHy8OdVQ/g+nwVKxOtfT17a4Rj6rRoskzucXxoIKkcnd6o32I 7osJzq3A7Am/fasF9k+0wnf/5W4lO4A5ADs9tZzgUbigy+1ELd0zwMRqDyEARsTGNk7X 9eRw== MIME-Version: 1.0 X-Received: by 10.129.36.14 with SMTP id k14mr31329515ywk.64.1437461015012; Mon, 20 Jul 2015 23:43:35 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Mon, 20 Jul 2015 23:43:34 -0700 (PDT) In-Reply-To: References: Date: Mon, 20 Jul 2015 23:43:34 -0700 Message-ID: From: Martin Thomson To: Darshak Thakore Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] comments on latest draft-thomson-webpush-protocol-00 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, 21 Jul 2015 06:43:39 -0000 I think that this might work. If we don't want to go all the way back to something like the registration+subscription model of my earlier proposals, this could work. I think that the nice part of a design like this is that you could treat this like a registration+subscription by refusing to share the primary subscription information with anyone. A potential bit of variation and therefore complexity is that the server might refuse to perform the association. That means that the client would need to be able to recognize this and handle it. The added complexity for the client there is traded for extra flexibility in how the server manages subscriptions. I think that there are a few things that would need to be tweaked here if we do it, but the basic idea could be done. On 20 July 2015 at 14:41, Darshak Thakore wrote: > > It seems like we do want some mechanism that allows a client to retrieve > notifications for all subscriptions with a single fetch. For IoT based us= e > cases also this is desirable. I guess this keeps going back to the > aggregation-vs-disaggregation discussion. However I=C2=B9m wondering if i= ts > possible to define/create a sort of =C2=B3aggregation-on-demand=C2=B2 mod= e with the > default being the current =C2=B3disaggregation=C2=B2 mode. > > For example, once a client/UA has subscribed for the first time and holds > 1 subscription, when it wants to create subsequent subscriptions, it can > include the first subscription in the request: > > POST /subscribe/ HTTP/1.1 > HOST: push.example.net > Link: ; > rel=3D=C2=B3urn:ietf:params:push:subcribe=C2=B2 (I=C2=B9m not sure if its= ok to use Link > header in a request, if not we need to find something more suitable) > > When a PS processes this request, it can associate the new subscription > with the one provided. (I think the additional data stored by the PS to > achieve this should be minimal). The response would contain the new > subscription info as currently defined (and maybe something additional to > indicate that the new subscription is tied to the one in the request) > > When receiving PUSH messages, a client/UA can make a single GET request t= o > the primary subscription resource and the server will send push > notifications for all subscriptions associated with the primary > subscription. > > For example, the request would be > > HEADERS [stream 7] +EHD_STREAM +END_HEADERS > :method =3D GET > :path =3D /s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx > :authority =3D push.example.net > > And the corresponding response would be > > PUSH_PROMISE [stream 7; promised stream 4] +END_HEADERS > :method =3D GET > :path =3D /d/qDIYHNcfAIPP_5ITvURr-d6BGtYnTRnk > :authority =3D push.example.net > > HEADERS [stream 4] +END_HEADERS > :status =3D 200 > =E2=80=B9=E2=80=B9OTHER HEADERS =E2=80=B9=E2=80=B9 > :content-loc =3D /s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx > > DATA [stream 4] +END_STREAM > iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB > > > PUSH_PROMISE [stream 7; promised stream 6] +END_HEADERS > :method =3D GET > :path =3D /d/gjuNJTYuZXkyylOOtjfAEo6ktRHCADui > :authority =3D push.example.net > > HEADERS [stream 6] +END_HEADERS > :status =3D 200 > =E2=80=B9=E2=80=B9OTHER HEADERS =E2=80=B9=E2=80=B9 > :content-loc =3D /s/hJ0jW1ElCjhjfwwh4kTQw7rEYK4QyFFW > > DATA [stream 6] +END_STREAM > {encoded/encrypted-notification-message} > > > =E2=80=B9=E2=80=B9 additional PUSH messages for other subscriptions =E2= =80=B9=E2=80=B9 > > > > In the above example, the responses can include a Content-Location (or > some other appropriate) header to indicate the associated subscription fo= r > the notification message. This would allow the client/UA to send just one > GET request to retrieve (and keep receiving) notifications on all its > active subscriptions. A client/UA may even choose to keep certain > subscriptions separate and group only a subset of them (this would be > useful in IoT like cases) > > > Darshak > > > > > On 7/20/15, 10:31 AM, "Webpush on behalf of Martin Thomson" > wrote: > >>On 20 July 2015 at 09:21, Benjamin Bangert wrote: >>> What's the use-case of a client polling over a long-lived connection >> >>The use case is for a device that is only periodically online (a >>constrained device) that wants to check in, then immediately go >>offline again. >> >>_______________________________________________ >>Webpush mailing list >>Webpush@ietf.org >>https://www.ietf.org/mailman/listinfo/webpush > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush From nobody Tue Jul 21 09:26:32 2015 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 B33F71A0233 for ; Tue, 21 Jul 2015 09:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 qzpfP6yJkpDK for ; Tue, 21 Jul 2015 09:26:25 -0700 (PDT) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (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 5E3711A0110 for ; Tue, 21 Jul 2015 09:26:25 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so126117326wib.0 for ; Tue, 21 Jul 2015 09:26:24 -0700 (PDT) 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=6wDgvY27IT78jic/8h0hjyq8CGdg5ZLfkyo52Qzz9LU=; b=CLgYA/hPZDsK6qEs+Ai4gi/nDpWyoLyiKqiIlcgVrkXDkKCgMLJpENKB5YcToRWnog UZ7qa7SUSrrVw2xg45ov1DPlldPh3jqvnHANiAF+FU9zFlQ1GLmGvOJ4WVeunL7HLcT2 ddSxgH13cljbnDe1wUbZbM7F4WsmO+iLmZrpXW4PautQLqu53TpFxFAE20I6irqU8TCm EYPgoJyulhdjLK6fd7sFpKjqeGyXjSUjqkq5LwKJmrmq1PhYOP6vL+4tlY5ieKSVl/J7 YI98H9GrtqtoAicQyV/5cSRw9LNS69/AiKtbfaHhcuHohvemgGSRCa6J7dUt47CSWWjc pkIQ== X-Gm-Message-State: ALoCoQlrF8NMGlBg6mcBx4G2YYdb8apAzZxZeDFGqSkfsmJlYxgD18cdqX9JTV+itBvmkr1Fsf29 MIME-Version: 1.0 X-Received: by 10.180.72.145 with SMTP id d17mr33716800wiv.69.1437495984033; Tue, 21 Jul 2015 09:26:24 -0700 (PDT) Received: by 10.27.33.81 with HTTP; Tue, 21 Jul 2015 09:26:23 -0700 (PDT) In-Reply-To: References: Date: Tue, 21 Jul 2015 09:26:23 -0700 Message-ID: From: Benjamin Bangert To: Darshak Thakore Content-Type: multipart/alternative; boundary=14dae9cc94927eada7051b651d2d Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] comments on latest draft-thomson-webpush-protocol-00 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, 21 Jul 2015 16:26:30 -0000 --14dae9cc94927eada7051b651d2d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My preference would be for the server to be able to require this, rather than leaving it up to the client. If a server doesn't want to expend the heavy resource cost of treating every single subscription as its own URL, there should be a way for the server to indicate that in its subscription response. For an IoT use-case, where a client might want different sets of subscriptions entirely, and to only check one group of them, it could open a separate h2 connection to retrieve that set. On Mon, Jul 20, 2015 at 2:41 PM, Darshak Thakore wrote: > > It seems like we do want some mechanism that allows a client to retrieve > notifications for all subscriptions with a single fetch. For IoT based us= e > cases also this is desirable. I guess this keeps going back to the > aggregation-vs-disaggregation discussion. However I=C2=B9m wondering if i= ts > possible to define/create a sort of =C2=B3aggregation-on-demand=C2=B2 mod= e with the > default being the current =C2=B3disaggregation=C2=B2 mode. > > For example, once a client/UA has subscribed for the first time and holds > 1 subscription, when it wants to create subsequent subscriptions, it can > include the first subscription in the request: > > POST /subscribe/ HTTP/1.1 > HOST: push.example.net > Link: ; > rel=3D=C2=B3urn:ietf:params:push:subcribe=C2=B2 (I=C2=B9m not sure if its= ok to use Link > header in a request, if not we need to find something more suitable) > > When a PS processes this request, it can associate the new subscription > with the one provided. (I think the additional data stored by the PS to > achieve this should be minimal). The response would contain the new > subscription info as currently defined (and maybe something additional to > indicate that the new subscription is tied to the one in the request) > > When receiving PUSH messages, a client/UA can make a single GET request t= o > the primary subscription resource and the server will send push > notifications for all subscriptions associated with the primary > subscription. > > For example, the request would be > > HEADERS [stream 7] +EHD_STREAM +END_HEADERS > :method =3D GET > :path =3D /s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx > :authority =3D push.example.net > > And the corresponding response would be > > PUSH_PROMISE [stream 7; promised stream 4] +END_HEADERS > :method =3D GET > :path =3D /d/qDIYHNcfAIPP_5ITvURr-d6BGtYnTRnk > :authority =3D push.example.net > > HEADERS [stream 4] +END_HEADERS > :status =3D 200 > =E2=80=B9=E2=80=B9OTHER HEADERS =E2=80=B9=E2=80=B9 > :content-loc =3D /s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx > > DATA [stream 4] +END_STREAM > iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB > > > PUSH_PROMISE [stream 7; promised stream 6] +END_HEADERS > :method =3D GET > :path =3D /d/gjuNJTYuZXkyylOOtjfAEo6ktRHCADui > :authority =3D push.example.net > > HEADERS [stream 6] +END_HEADERS > :status =3D 200 > =E2=80=B9=E2=80=B9OTHER HEADERS =E2=80=B9=E2=80=B9 > :content-loc =3D /s/hJ0jW1ElCjhjfwwh4kTQw7rEYK4QyFFW > > DATA [stream 6] +END_STREAM > {encoded/encrypted-notification-message} > > > =E2=80=B9=E2=80=B9 additional PUSH messages for other subscriptions =E2= =80=B9=E2=80=B9 > > > > In the above example, the responses can include a Content-Location (or > some other appropriate) header to indicate the associated subscription fo= r > the notification message. This would allow the client/UA to send just one > GET request to retrieve (and keep receiving) notifications on all its > active subscriptions. A client/UA may even choose to keep certain > subscriptions separate and group only a subset of them (this would be > useful in IoT like cases) > > > Darshak > > > > > On 7/20/15, 10:31 AM, "Webpush on behalf of Martin Thomson" > wrote: > > >On 20 July 2015 at 09:21, Benjamin Bangert wrote: > >> What's the use-case of a client polling over a long-lived connection > > > >The use case is for a device that is only periodically online (a > >constrained device) that wants to check in, then immediately go > >offline again. > > > >_______________________________________________ > >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 > --14dae9cc94927eada7051b651d2d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My preference would be for the server to be able to r= equire this, rather than leaving it up to the client. If a server doesn'= ;t want to expend the heavy resource cost of treating every single subscrip= tion as its own URL, there should be a way for the server to indicate that = in its subscription response.

For an IoT use-case, where a cli= ent might want different sets of subscriptions entirely, and to only check = one group of them, it could open a separate h2 connection to retrieve that = set.

On = Mon, Jul 20, 2015 at 2:41 PM, Darshak Thakore <d.thakore@cablelabs.c= om> wrote:

It seems like we do want some mechanism that allows a client to retrieve notifications for all subscriptions with a single fetch. For IoT based use<= br> cases also this is desirable. I guess this keeps going back to the
aggregation-vs-disaggregation discussion. However I=C2=B9m wondering if its=
possible to define/create a sort of =C2=B3aggregation-on-demand=C2=B2 mode = with the
default being the current =C2=B3disaggregation=C2=B2 mode.

For example, once a client/UA has subscribed for the first time and holds 1 subscription, when it wants to create subsequent subscriptions, it can include the first subscription in the request:

POST /subscribe/ HTTP/1.1
HOST: push.example.net
Link: </s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx>;
rel=3D=C2=B3urn:ietf:params:push:subcribe=C2=B2 (I=C2=B9m not sure if its o= k to use Link
header in a request, if not we need to find something more suitable)

When a PS processes this request, it can associate the new subscription
with the one provided. (I think the additional data stored by the PS to
achieve this should be minimal). The response would contain the new
subscription info as currently defined (and maybe something additional to indicate that the new subscription is tied to the one in the request)

When receiving PUSH messages, a client/UA can make a single GET request to<= br> the primary subscription resource and the server will send push
notifications for all subscriptions associated with the primary
subscription.

For example, the request would be

HEADERS=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[stream 7] +EHD_STREAM +END_HEADER= S
=C2=A0 :method=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D GET
=C2=A0 :path=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D /s/LBhhw0OohO-Wl4Oi971UGs= B7sdQGUibx
=C2=A0 :authority=C2=A0 =C2=A0 =3D push.example.net

And the corresponding response would be

PUSH_PROMISE=C2=A0 =C2=A0 [stream 7; promised stream 4] +END_HEADERS
=C2=A0 :method=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D GET
=C2=A0 :path=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D /d/qDIYHNcfAIPP_5ITvURr-d= 6BGtYnTRnk
=C2=A0 :authority=C2=A0 =C2=A0 =3D push.example.net

HEADERS=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[stream 4] +END_HEADERS
=C2=A0 :status=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D 200
=C2=A0 =E2=80=B9=E2=80=B9OTHER HEADERS =E2=80=B9=E2=80=B9
=C2=A0 :content-loc=C2=A0 =3D /s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx

DATA=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [stream 4] +END_STREAM
=C2=A0 =C2=A0 =C2=A0iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB


PUSH_PROMISE=C2=A0 =C2=A0 [stream 7; promised stream 6] +END_HEADERS
=C2=A0 :method=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D GE= T
=C2=A0 :path=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =3D /d/gjuNJTYuZXkyylOOtjfAEo6ktRHCADui
=C2=A0 :authority=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D push.example.n= et

HEADERS=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[stream 6] +END_HEADERS
=C2=A0 :status=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D 200
=C2=A0 =E2=80=B9=E2=80=B9OTHER HEADERS =E2=80=B9=E2=80=B9
=C2=A0 :content-loc=C2=A0 =3D /s/hJ0jW1ElCjhjfwwh4kTQw7rEYK4QyFFW

DATA=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [stream 6] +END_STREAM
{encoded/encrypted-notification-message}


=E2=80=B9=E2=80=B9 additional PUSH messages for other subscriptions =E2=80= =B9=E2=80=B9



In the above example, the responses can include a Content-Location (or
some other appropriate) header to indicate the associated subscription for<= br> the notification message. This would allow the client/UA to send just one GET request to retrieve (and keep receiving) notifications on all its
active subscriptions. A client/UA may even choose to keep certain
subscriptions separate and group only a subset of them (this would be
useful in IoT like cases)


Darshak




On 7/20/15, 10:31 AM, "Webpush on behalf of Martin Thomson"
<webp= ush-bounces@ietf.org on behalf of martin.thomson@gmail.com> wrote:

>On 20 July 2015 at 09:21, Benjamin Bangert <bbangert@mozilla.com> wrote:
>> What's the use-case of a client polling over a long-lived conn= ection
>
>The use case is for a device that is only periodically online (a
>constrained device) that wants to check in, then immediately go
>offline again.
>
>_______________________________________________
>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

--14dae9cc94927eada7051b651d2d-- From nobody Tue Jul 21 17:48:21 2015 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 96D9C1A1B2B for ; Tue, 21 Jul 2015 17:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWpgxAYbWgBK for ; Tue, 21 Jul 2015 17:48:16 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::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 293B61A1B12 for ; Tue, 21 Jul 2015 17:48:15 -0700 (PDT) Received: by ietj16 with SMTP id j16so155856317iet.0 for ; Tue, 21 Jul 2015 17:48:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mcQ8uwlboU7isOsmvM5DhXYviDuouG9GituPQkkxI8o=; b=k1gjDECqF/Us3jtxCBZd5tVwW5q+X6iIM7mBZ7s/QPoMAJW8XrNbebtbpuGa+qlcPv RC/Nm3SGcKduvFT+6W5Hx7CSMtKc3KqhDjOKi4GJqJaEUJWOat9EEbTJhrARXPqdgIxj Hh9PjLxy+fqzHS5J6w3UvqFlZYXssJhgoyXSldpJ6JGquGrOuqbZgLPh5TFo6mo2/5pu GwnHyPQ26jnSkkbnpcy72X8N1J5LurDmKzFfsy30jt+d5kgY1Dh57YJa4W2JQiB+nYws tdNVox3+tWUHNVLPQCI27VSif5aUeESswErBucc+ObGUw85U4e5yflQRQ3NTb3bUDEdR BK1A== MIME-Version: 1.0 X-Received: by 10.50.134.226 with SMTP id pn2mr977088igb.21.1437526095296; Tue, 21 Jul 2015 17:48:15 -0700 (PDT) Received: by 10.36.9.207 with HTTP; Tue, 21 Jul 2015 17:48:15 -0700 (PDT) In-Reply-To: References: Date: Tue, 21 Jul 2015 17:48:15 -0700 Message-ID: From: Costin Manolache To: Benjamin Bangert Content-Type: multipart/alternative; boundary=047d7b2e148d44038e051b6c2025 Archived-At: Cc: Darshak Thakore , "webpush@ietf.org" Subject: Re: [Webpush] comments on latest draft-thomson-webpush-protocol-00 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, 22 Jul 2015 00:48:19 -0000 --047d7b2e148d44038e051b6c2025 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think one question is who makes the decision if subscrptions are 'aggregated' or not. And the only answer I know is the push provider - since the push provider is the one bearing the costs and defining the requirements for UAs that connect to it. If we agree that a push provider may require 'aggregation' - all subscriptions from a device, when connecting to such a provider, will need to have something in common, to allow the aggregation. The original "registration + subscription" does it by having a first step where a device gets the common element. It can be simplified by defining the 'registration' as a regular subscription, and allowing each app to have a 'child' subscription. This works nicely if a UA supports profiles/multi-user for example - and may be extended later for more complicated cases, where a UA acts as a proxy for other UAs ( for example a wearable device paired over BT ). The subscription API should allow a way to create 'links' between subscriptions. We do need to finish the separate discussion on sender authentication and registration - but assuming a push service requires sender authentication, this is another 'link' between the app subscription and the server id ( which can be another capability URL or subscription ). I don't think it's a problem if the 'non-aggregated' model - where nothing is shared - is defined even as default, and some push providers may chose to support both, or only one model, depending on their scale and costs. Costin On Tue, Jul 21, 2015 at 9:26 AM, Benjamin Bangert wrote: > My preference would be for the server to be able to require this, rather > than leaving it up to the client. If a server doesn't want to expend the > heavy resource cost of treating every single subscription as its own URL, > there should be a way for the server to indicate that in its subscription > response. > > For an IoT use-case, where a client might want different sets of > subscriptions entirely, and to only check one group of them, it could ope= n > a separate h2 connection to retrieve that set. > > On Mon, Jul 20, 2015 at 2:41 PM, Darshak Thakore > wrote: > >> >> It seems like we do want some mechanism that allows a client to retrieve >> notifications for all subscriptions with a single fetch. For IoT based u= se >> cases also this is desirable. I guess this keeps going back to the >> aggregation-vs-disaggregation discussion. However I=C2=B9m wondering if = its >> possible to define/create a sort of =C2=B3aggregation-on-demand=C2=B2 mo= de with the >> default being the current =C2=B3disaggregation=C2=B2 mode. >> >> For example, once a client/UA has subscribed for the first time and hold= s >> 1 subscription, when it wants to create subsequent subscriptions, it can >> include the first subscription in the request: >> >> POST /subscribe/ HTTP/1.1 >> HOST: push.example.net >> Link: ; >> rel=3D=C2=B3urn:ietf:params:push:subcribe=C2=B2 (I=C2=B9m not sure if it= s ok to use Link >> header in a request, if not we need to find something more suitable) >> >> When a PS processes this request, it can associate the new subscription >> with the one provided. (I think the additional data stored by the PS to >> achieve this should be minimal). The response would contain the new >> subscription info as currently defined (and maybe something additional t= o >> indicate that the new subscription is tied to the one in the request) >> >> When receiving PUSH messages, a client/UA can make a single GET request = to >> the primary subscription resource and the server will send push >> notifications for all subscriptions associated with the primary >> subscription. >> >> For example, the request would be >> >> HEADERS [stream 7] +EHD_STREAM +END_HEADERS >> :method =3D GET >> :path =3D /s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx >> :authority =3D push.example.net >> >> And the corresponding response would be >> >> PUSH_PROMISE [stream 7; promised stream 4] +END_HEADERS >> :method =3D GET >> :path =3D /d/qDIYHNcfAIPP_5ITvURr-d6BGtYnTRnk >> :authority =3D push.example.net >> >> HEADERS [stream 4] +END_HEADERS >> :status =3D 200 >> =E2=80=B9=E2=80=B9OTHER HEADERS =E2=80=B9=E2=80=B9 >> :content-loc =3D /s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx >> >> DATA [stream 4] +END_STREAM >> iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB >> >> >> PUSH_PROMISE [stream 7; promised stream 6] +END_HEADERS >> :method =3D GET >> :path =3D /d/gjuNJTYuZXkyylOOtjfAEo6ktRHCADui >> :authority =3D push.example.net >> >> HEADERS [stream 6] +END_HEADERS >> :status =3D 200 >> =E2=80=B9=E2=80=B9OTHER HEADERS =E2=80=B9=E2=80=B9 >> :content-loc =3D /s/hJ0jW1ElCjhjfwwh4kTQw7rEYK4QyFFW >> >> DATA [stream 6] +END_STREAM >> {encoded/encrypted-notification-message} >> >> >> =E2=80=B9=E2=80=B9 additional PUSH messages for other subscriptions =E2= =80=B9=E2=80=B9 >> >> >> >> In the above example, the responses can include a Content-Location (or >> some other appropriate) header to indicate the associated subscription f= or >> the notification message. This would allow the client/UA to send just on= e >> GET request to retrieve (and keep receiving) notifications on all its >> active subscriptions. A client/UA may even choose to keep certain >> subscriptions separate and group only a subset of them (this would be >> useful in IoT like cases) >> >> >> Darshak >> >> >> >> >> On 7/20/15, 10:31 AM, "Webpush on behalf of Martin Thomson" >> wrote: >> >> >On 20 July 2015 at 09:21, Benjamin Bangert wrote= : >> >> What's the use-case of a client polling over a long-lived connection >> > >> >The use case is for a device that is only periodically online (a >> >constrained device) that wants to check in, then immediately go >> >offline again. >> > >> >_______________________________________________ >> >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 > > --047d7b2e148d44038e051b6c2025 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think one question is who makes the decision if subscrpt= ions are 'aggregated' or not. And the only answer=C2=A0
I know = is the push provider - since the push provider is the one bearing the costs= and defining the=C2=A0
requirements for UAs that connect to it.= =C2=A0

If we agree that a push provider may requir= e 'aggregation' - all subscriptions from a device, when connecting<= /div>
to such a provider, will need to have something in common, to all= ow the aggregation. The original
=C2=A0"registration + subsc= ription" does it by having a first step where a device gets the common= element.=C2=A0
It can be simplified by defining the 'registr= ation' as a regular subscription, and allowing each app to
= =C2=A0have a 'child' subscription. This works nicely if a UA suppor= ts profiles/multi-user for example - and may=C2=A0
be extended la= ter for more complicated cases, where a UA acts as a proxy for other UAs ( = for example=C2=A0
a wearable device paired over BT ).=C2=A0
=

The subscription API should allow a way to create '= links' between subscriptions. We do need to=C2=A0
finish the = separate discussion on sender authentication and registration - but assumin= g a push service
requires sender authentication, this is another = 'link' between the app subscription and the server id (
w= hich can be another capability URL or subscription ).=C2=A0

<= /div>
I don't think it's a problem if the 'non-aggregated&#= 39; model - where nothing is shared - is defined even as default,
and some push providers may chose to support both, or only one model, depe= nding on their scale and costs.

Costin
=

On Tue, Jul 21, 2= 015 at 9:26 AM, Benjamin Bangert <bbangert@mozilla.com> w= rote:
My preference= would be for the server to be able to require this, rather than leaving it= up to the client. If a server doesn't want to expend the heavy resourc= e cost of treating every single subscription as its own URL, there should b= e a way for the server to indicate that in its subscription response.
For an IoT use-case, where a client might want different sets of su= bscriptions entirely, and to only check one group of them, it could open a = separate h2 connection to retrieve that set.

On Mon, Jul 20, 2015 = at 2:41 PM, Darshak Thakore <d.thakore@cablelabs.com> = wrote:

It seems like we do want some mechanism that allows a client to retrieve notifications for all subscriptions with a single fetch. For IoT based use<= br> cases also this is desirable. I guess this keeps going back to the
aggregation-vs-disaggregation discussion. However I=C2=B9m wondering if its=
possible to define/create a sort of =C2=B3aggregation-on-demand=C2=B2 mode = with the
default being the current =C2=B3disaggregation=C2=B2 mode.

For example, once a client/UA has subscribed for the first time and holds 1 subscription, when it wants to create subsequent subscriptions, it can include the first subscription in the request:

POST /subscribe/ HTTP/1.1
 HOST: push.example.net
Link: </s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx>;
rel=3D=C2=B3urn:ietf:params:push:subcribe=C2=B2 (I=C2=B9m not sure if its o= k to use Link
header in a request, if not we need to find something more suitable)

When a PS processes this request, it can associate the new subscription
with the one provided. (I think the additional data stored by the PS to
achieve this should be minimal). The response would contain the new
subscription info as currently defined (and maybe something additional to indicate that the new subscription is tied to the one in the request)

When receiving PUSH messages, a client/UA can make a single GET request to<= br> the primary subscription resource and the server will send push
notifications for all subscriptions associated with the primary
subscription.

For example, the request would be

HEADERS=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[stream 7] +EHD_STREAM +END_HEADER= S
=C2=A0 :method=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D GET
=C2=A0 :path=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D /s/LBhhw0OohO-Wl4Oi971UGs= B7sdQGUibx
 =C2=A0 :authority=C2=A0 =C2=A0 =3D push.example.net

And the corresponding response would be

PUSH_PROMISE=C2=A0 =C2=A0 [stream 7; promised stream 4] +END_HEADERS
=C2=A0 :method=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D GET
=C2=A0 :path=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D /d/qDIYHNcfAIPP_5ITvURr-d= 6BGtYnTRnk
 =C2=A0 :authority=C2=A0 =C2=A0 =3D push.example.net

HEADERS=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[stream 4] +END_HEADERS
=C2=A0 :status=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D 200
=C2=A0 =E2=80=B9=E2=80=B9OTHER HEADERS =E2=80=B9=E2=80=B9
=C2=A0 :content-loc=C2=A0 =3D /s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx

DATA=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [stream 4] +END_STREAM
=C2=A0 =C2=A0 =C2=A0iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB


PUSH_PROMISE=C2=A0 =C2=A0 [stream 7; promised stream 6] +END_HEADERS
=C2=A0 :method=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D GE= T
=C2=A0 :path=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =3D /d/gjuNJTYuZXkyylOOtjfAEo6ktRHCADui
 =C2=A0 :authority=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D push.example.n= et

HEADERS=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[stream 6] +END_HEADERS
=C2=A0 :status=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D 200
=C2=A0 =E2=80=B9=E2=80=B9OTHER HEADERS =E2=80=B9=E2=80=B9
=C2=A0 :content-loc=C2=A0 =3D /s/hJ0jW1ElCjhjfwwh4kTQw7rEYK4QyFFW

DATA=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [stream 6] +END_STREAM
{encoded/encrypted-notification-message}


=E2=80=B9=E2=80=B9 additional PUSH messages for other subscriptions =E2=80= =B9=E2=80=B9



In the above example, the responses can include a Content-Location (or
some other appropriate) header to indicate the associated subscription for<= br> the notification message. This would allow the client/UA to send just one GET request to retrieve (and keep receiving) notifications on all its
active subscriptions. A client/UA may even choose to keep certain
subscriptions separate and group only a subset of them (this would be
useful in IoT like cases)


Darshak




On 7/20/15, 10:31 AM, "Webpush on behalf of Martin Thomson"
<webpush-bounces@ietf.org on behalf of martin.thomson@gmail.com> wrote= :

>On 20 July 2015 at 09:21, Benjamin Bangert <bbangert@mozilla.com> wrote:
>> What's the use-case of a client polling over a long-lived conn= ection
>
>The use case is for a device that is only periodically online (a
>constrained device) that wants to check in, then immediately go
>offline again.
>
>_______________________________________________
>Webpush mailing list
>Webpush@ietf.org<= /a>
>https://www.ietf.org/mailman/listinfo/webpush
_______________________________________________
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


--047d7b2e148d44038e051b6c2025-- From nobody Wed Jul 22 01:16:29 2015 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 323681B3083 for ; Wed, 22 Jul 2015 01:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.227 X-Spam-Level: X-Spam-Status: No, score=0.227 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] 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 ggF0e1RkSf6G for ; Wed, 22 Jul 2015 01:16:26 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 153901B3020 for ; Wed, 22 Jul 2015 01:16:26 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id t6M8GPZQ008827; Wed, 22 Jul 2015 02:16:25 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Wed, 22 Jul 2015 02:16:25 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([::1]) by EXCHANGE.cablelabs.com ([::1]) with mapi id 14.03.0224.002; Wed, 22 Jul 2015 02:16:24 -0600 From: Darshak Thakore To: Benjamin Bangert Thread-Topic: [Webpush] comments on latest draft-thomson-webpush-protocol-00 Thread-Index: AQHQunlLM+hV2NIVmEuOC+Bk2k+U+Z3ju0gAgAFEnICAAALrAP//8eCAgAGe6oCAAKTXAA== Date: Wed, 22 Jul 2015 08:16:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 x-originating-ip: [10.5.0.27] Content-Type: multipart/alternative; boundary="_000_D1D4ACBF70D8dthakorecablelabscom_" MIME-Version: 1.0 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] comments on latest draft-thomson-webpush-protocol-00 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, 22 Jul 2015 08:16:28 -0000 --_000_D1D4ACBF70D8dthakorecablelabscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gbm90IHN1cmUgaG93IHlvdSBjYW4gZm9yY2UgdGhlIFBTIHRvIHJlcXVpcmUgdGhpcy4g SWYgYSBjbGllbnQgbWFrZXMgaW5kZXBlbmRlbnQgc3Vic2NyaXB0aW9uIHJlcXVlc3RzLCBpdCB3 aWxsIHJlY2VpdmUg4oCcdW5hc3NvY2lhdGVk4oCdIHN1YnNjcmlwdGlvbnMgYW5kIHRoZSBjbGll bnQgd2lsbCBiZSByZXF1aXJlZCB0byBkbyBzZXBhcmF0ZSBHRVTigJlzIGZvciBlYWNoIHN1YnNj cmlwdGlvbiAoSSBkb27igJl0IHRoaW5rIGl0IG5lZWRzIHRvIGJlIGEgc2VwYXJhdGUgaDIgY29u bmVjdGlvbiwganVzdCBhIHNlcGFyYXRlIEdFVCkNCg0KSSB3YXMgaW5pdGlhbGx5IHN1Z2dlc3Rp bmcgdGhhdCB3ZSBtYWtlIHRoaXMg4oCcYWdncmVnYXRpb24tb24tZGVtYW5k4oCdIGFzIGEg4oCc c2VydmVyIFNIT1VMRCBzdXBwb3J04oCdIGJ1dCBpZiB3ZSB3YW50IHRvIG1ha2UgaXQgbWFuZGF0 b3J5IGZvciBQU+KAmXMgdG8gc3VwcG9ydCBpdCwgSeKAmW0gZmluZSB3aXRoIGl0Lg0KDQoNCkRh cnNoYWsNCg0KT24gNy8yMS8xNSwgMTA6MjYgQU0sICJCZW5qYW1pbiBCYW5nZXJ0IiA8YmJhbmdl cnRAbW96aWxsYS5jb208bWFpbHRvOmJiYW5nZXJ0QG1vemlsbGEuY29tPj4gd3JvdGU6DQoNCk15 IHByZWZlcmVuY2Ugd291bGQgYmUgZm9yIHRoZSBzZXJ2ZXIgdG8gYmUgYWJsZSB0byByZXF1aXJl IHRoaXMsIHJhdGhlciB0aGFuIGxlYXZpbmcgaXQgdXAgdG8gdGhlIGNsaWVudC4gSWYgYSBzZXJ2 ZXIgZG9lc24ndCB3YW50IHRvIGV4cGVuZCB0aGUgaGVhdnkgcmVzb3VyY2UgY29zdCBvZiB0cmVh dGluZyBldmVyeSBzaW5nbGUgc3Vic2NyaXB0aW9uIGFzIGl0cyBvd24gVVJMLCB0aGVyZSBzaG91 bGQgYmUgYSB3YXkgZm9yIHRoZSBzZXJ2ZXIgdG8gaW5kaWNhdGUgdGhhdCBpbiBpdHMgc3Vic2Ny aXB0aW9uIHJlc3BvbnNlLg0KDQpGb3IgYW4gSW9UIHVzZS1jYXNlLCB3aGVyZSBhIGNsaWVudCBt aWdodCB3YW50IGRpZmZlcmVudCBzZXRzIG9mIHN1YnNjcmlwdGlvbnMgZW50aXJlbHksIGFuZCB0 byBvbmx5IGNoZWNrIG9uZSBncm91cCBvZiB0aGVtLCBpdCBjb3VsZCBvcGVuIGEgc2VwYXJhdGUg aDIgY29ubmVjdGlvbiB0byByZXRyaWV2ZSB0aGF0IHNldC4NCg0KT24gTW9uLCBKdWwgMjAsIDIw MTUgYXQgMjo0MSBQTSwgRGFyc2hhayBUaGFrb3JlIDxkLnRoYWtvcmVAY2FibGVsYWJzLmNvbTxt YWlsdG86ZC50aGFrb3JlQGNhYmxlbGFicy5jb20+PiB3cm90ZToNCg0KSXQgc2VlbXMgbGlrZSB3 ZSBkbyB3YW50IHNvbWUgbWVjaGFuaXNtIHRoYXQgYWxsb3dzIGEgY2xpZW50IHRvIHJldHJpZXZl DQpub3RpZmljYXRpb25zIGZvciBhbGwgc3Vic2NyaXB0aW9ucyB3aXRoIGEgc2luZ2xlIGZldGNo LiBGb3IgSW9UIGJhc2VkIHVzZQ0KY2FzZXMgYWxzbyB0aGlzIGlzIGRlc2lyYWJsZS4gSSBndWVz cyB0aGlzIGtlZXBzIGdvaW5nIGJhY2sgdG8gdGhlDQphZ2dyZWdhdGlvbi12cy1kaXNhZ2dyZWdh dGlvbiBkaXNjdXNzaW9uLiBIb3dldmVyIEnCuW0gd29uZGVyaW5nIGlmIGl0cw0KcG9zc2libGUg dG8gZGVmaW5lL2NyZWF0ZSBhIHNvcnQgb2YgwrNhZ2dyZWdhdGlvbi1vbi1kZW1hbmTCsiBtb2Rl IHdpdGggdGhlDQpkZWZhdWx0IGJlaW5nIHRoZSBjdXJyZW50IMKzZGlzYWdncmVnYXRpb27CsiBt b2RlLg0KDQpGb3IgZXhhbXBsZSwgb25jZSBhIGNsaWVudC9VQSBoYXMgc3Vic2NyaWJlZCBmb3Ig dGhlIGZpcnN0IHRpbWUgYW5kIGhvbGRzDQoxIHN1YnNjcmlwdGlvbiwgd2hlbiBpdCB3YW50cyB0 byBjcmVhdGUgc3Vic2VxdWVudCBzdWJzY3JpcHRpb25zLCBpdCBjYW4NCmluY2x1ZGUgdGhlIGZp cnN0IHN1YnNjcmlwdGlvbiBpbiB0aGUgcmVxdWVzdDoNCg0KUE9TVCAvc3Vic2NyaWJlLyBIVFRQ LzEuMQ0KSE9TVDogcHVzaC5leGFtcGxlLm5ldDxodHRwOi8vcHVzaC5leGFtcGxlLm5ldD4NCkxp bms6IDwvcy9MQmhodzBPb2hPLVdsNE9pOTcxVUdzQjdzZFFHVWlieD47DQpyZWw9wrN1cm46aWV0 ZjpwYXJhbXM6cHVzaDpzdWJjcmliZcKyIChJwrltIG5vdCBzdXJlIGlmIGl0cyBvayB0byB1c2Ug TGluaw0KaGVhZGVyIGluIGEgcmVxdWVzdCwgaWYgbm90IHdlIG5lZWQgdG8gZmluZCBzb21ldGhp bmcgbW9yZSBzdWl0YWJsZSkNCg0KV2hlbiBhIFBTIHByb2Nlc3NlcyB0aGlzIHJlcXVlc3QsIGl0 IGNhbiBhc3NvY2lhdGUgdGhlIG5ldyBzdWJzY3JpcHRpb24NCndpdGggdGhlIG9uZSBwcm92aWRl ZC4gKEkgdGhpbmsgdGhlIGFkZGl0aW9uYWwgZGF0YSBzdG9yZWQgYnkgdGhlIFBTIHRvDQphY2hp ZXZlIHRoaXMgc2hvdWxkIGJlIG1pbmltYWwpLiBUaGUgcmVzcG9uc2Ugd291bGQgY29udGFpbiB0 aGUgbmV3DQpzdWJzY3JpcHRpb24gaW5mbyBhcyBjdXJyZW50bHkgZGVmaW5lZCAoYW5kIG1heWJl IHNvbWV0aGluZyBhZGRpdGlvbmFsIHRvDQppbmRpY2F0ZSB0aGF0IHRoZSBuZXcgc3Vic2NyaXB0 aW9uIGlzIHRpZWQgdG8gdGhlIG9uZSBpbiB0aGUgcmVxdWVzdCkNCg0KV2hlbiByZWNlaXZpbmcg UFVTSCBtZXNzYWdlcywgYSBjbGllbnQvVUEgY2FuIG1ha2UgYSBzaW5nbGUgR0VUIHJlcXVlc3Qg dG8NCnRoZSBwcmltYXJ5IHN1YnNjcmlwdGlvbiByZXNvdXJjZSBhbmQgdGhlIHNlcnZlciB3aWxs IHNlbmQgcHVzaA0Kbm90aWZpY2F0aW9ucyBmb3IgYWxsIHN1YnNjcmlwdGlvbnMgYXNzb2NpYXRl ZCB3aXRoIHRoZSBwcmltYXJ5DQpzdWJzY3JpcHRpb24uDQoNCkZvciBleGFtcGxlLCB0aGUgcmVx dWVzdCB3b3VsZCBiZQ0KDQpIRUFERVJTICAgICAgICAgW3N0cmVhbSA3XSArRUhEX1NUUkVBTSAr RU5EX0hFQURFUlMNCiAgOm1ldGhvZCAgICAgICA9IEdFVA0KICA6cGF0aCAgICAgICAgID0gL3Mv TEJoaHcwT29oTy1XbDRPaTk3MVVHc0I3c2RRR1VpYngNCiAgOmF1dGhvcml0eSAgICA9IHB1c2gu ZXhhbXBsZS5uZXQ8aHR0cDovL3B1c2guZXhhbXBsZS5uZXQ+DQoNCkFuZCB0aGUgY29ycmVzcG9u ZGluZyByZXNwb25zZSB3b3VsZCBiZQ0KDQpQVVNIX1BST01JU0UgICAgW3N0cmVhbSA3OyBwcm9t aXNlZCBzdHJlYW0gNF0gK0VORF9IRUFERVJTDQogIDptZXRob2QgICAgICAgPSBHRVQNCiAgOnBh dGggICAgICAgICA9IC9kL3FESVlITmNmQUlQUF81SVR2VVJyLWQ2Qkd0WW5UUm5rDQogIDphdXRo b3JpdHkgICAgPSBwdXNoLmV4YW1wbGUubmV0PGh0dHA6Ly9wdXNoLmV4YW1wbGUubmV0Pg0KDQpI RUFERVJTICAgICAgICAgW3N0cmVhbSA0XSArRU5EX0hFQURFUlMNCiAgOnN0YXR1cyAgICAgICA9 IDIwMA0KICDigLnigLlPVEhFUiBIRUFERVJTIOKAueKAuQ0KICA6Y29udGVudC1sb2MgID0gL3Mv TEJoaHcwT29oTy1XbDRPaTk3MVVHc0I3c2RRR1VpYngNCg0KREFUQSAgICAgICAgICAgIFtzdHJl YW0gNF0gK0VORF9TVFJFQU0NCiAgICAgaUNoWXVJM2pNenQzaXIyMFA4cl9qZ1JSLWRTdU4xODJ4 N2lCDQoNCg0KUFVTSF9QUk9NSVNFICAgIFtzdHJlYW0gNzsgcHJvbWlzZWQgc3RyZWFtIDZdICtF TkRfSEVBREVSUw0KICA6bWV0aG9kICAgICAgICAgICAgICAgPSBHRVQNCiAgOnBhdGggICAgICAg ICAgICAgICAgID0gL2QvZ2p1TkpUWXVaWGt5eWxPT3RqZkFFbzZrdFJIQ0FEdWkNCiAgOmF1dGhv cml0eSAgICAgICAgICAgID0gcHVzaC5leGFtcGxlLm5ldDxodHRwOi8vcHVzaC5leGFtcGxlLm5l dD4NCg0KSEVBREVSUyAgICAgICAgIFtzdHJlYW0gNl0gK0VORF9IRUFERVJTDQogIDpzdGF0dXMg ICAgICAgPSAyMDANCiAg4oC54oC5T1RIRVIgSEVBREVSUyDigLnigLkNCiAgOmNvbnRlbnQtbG9j ICA9IC9zL2hKMGpXMUVsQ2poamZ3d2g0a1RRdzdyRVlLNFF5RkZXDQoNCkRBVEEgICAgICAgICAg ICBbc3RyZWFtIDZdICtFTkRfU1RSRUFNDQp7ZW5jb2RlZC9lbmNyeXB0ZWQtbm90aWZpY2F0aW9u LW1lc3NhZ2V9DQoNCg0K4oC54oC5IGFkZGl0aW9uYWwgUFVTSCBtZXNzYWdlcyBmb3Igb3RoZXIg c3Vic2NyaXB0aW9ucyDigLnigLkNCg0KDQoNCkluIHRoZSBhYm92ZSBleGFtcGxlLCB0aGUgcmVz cG9uc2VzIGNhbiBpbmNsdWRlIGEgQ29udGVudC1Mb2NhdGlvbiAob3INCnNvbWUgb3RoZXIgYXBw cm9wcmlhdGUpIGhlYWRlciB0byBpbmRpY2F0ZSB0aGUgYXNzb2NpYXRlZCBzdWJzY3JpcHRpb24g Zm9yDQp0aGUgbm90aWZpY2F0aW9uIG1lc3NhZ2UuIFRoaXMgd291bGQgYWxsb3cgdGhlIGNsaWVu dC9VQSB0byBzZW5kIGp1c3Qgb25lDQpHRVQgcmVxdWVzdCB0byByZXRyaWV2ZSAoYW5kIGtlZXAg cmVjZWl2aW5nKSBub3RpZmljYXRpb25zIG9uIGFsbCBpdHMNCmFjdGl2ZSBzdWJzY3JpcHRpb25z LiBBIGNsaWVudC9VQSBtYXkgZXZlbiBjaG9vc2UgdG8ga2VlcCBjZXJ0YWluDQpzdWJzY3JpcHRp b25zIHNlcGFyYXRlIGFuZCBncm91cCBvbmx5IGEgc3Vic2V0IG9mIHRoZW0gKHRoaXMgd291bGQg YmUNCnVzZWZ1bCBpbiBJb1QgbGlrZSBjYXNlcykNCg0KDQpEYXJzaGFrDQoNCg0KDQoNCk9uIDcv MjAvMTUsIDEwOjMxIEFNLCAiV2VicHVzaCBvbiBiZWhhbGYgb2YgTWFydGluIFRob21zb24iDQo8 d2VicHVzaC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzp3ZWJwdXNoLWJvdW5jZXNAaWV0Zi5vcmc+ IG9uIGJlaGFsZiBvZiBtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208bWFpbHRvOm1hcnRpbi50aG9t c29uQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQo+T24gMjAgSnVseSAyMDE1IGF0IDA5OjIxLCBCZW5q YW1pbiBCYW5nZXJ0IDxiYmFuZ2VydEBtb3ppbGxhLmNvbTxtYWlsdG86YmJhbmdlcnRAbW96aWxs YS5jb20+PiB3cm90ZToNCj4+IFdoYXQncyB0aGUgdXNlLWNhc2Ugb2YgYSBjbGllbnQgcG9sbGlu ZyBvdmVyIGEgbG9uZy1saXZlZCBjb25uZWN0aW9uDQo+DQo+VGhlIHVzZSBjYXNlIGlzIGZvciBh IGRldmljZSB0aGF0IGlzIG9ubHkgcGVyaW9kaWNhbGx5IG9ubGluZSAoYQ0KPmNvbnN0cmFpbmVk IGRldmljZSkgdGhhdCB3YW50cyB0byBjaGVjayBpbiwgdGhlbiBpbW1lZGlhdGVseSBnbw0KPm9m ZmxpbmUgYWdhaW4uDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj5XZWJwdXNoIG1haWxpbmcgbGlzdA0KPldlYnB1c2hAaWV0Zi5vcmc8bWFpbHRv OldlYnB1c2hAaWV0Zi5vcmc+DQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by93ZWJwdXNoDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpXZWJwdXNoIG1haWxpbmcgbGlzdA0KV2VicHVzaEBpZXRmLm9yZzxtYWlsdG86V2VicHVz aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vd2VicHVz aA0KDQo= --_000_D1D4ACBF70D8dthakorecablelabscom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5J4oCZbSBub3Qg c3VyZSBob3cgeW91IGNhbiBmb3JjZSB0aGUgUFMgdG8gcmVxdWlyZSB0aGlzLiBJZiBhIGNsaWVu dCBtYWtlcyBpbmRlcGVuZGVudCBzdWJzY3JpcHRpb24gcmVxdWVzdHMsIGl0IHdpbGwgcmVjZWl2 ZSDigJx1bmFzc29jaWF0ZWTigJ0gc3Vic2NyaXB0aW9ucyBhbmQgdGhlIGNsaWVudCB3aWxsIGJl IHJlcXVpcmVkIHRvIGRvIHNlcGFyYXRlIEdFVOKAmXMgZm9yIGVhY2ggc3Vic2NyaXB0aW9uIChJ IGRvbuKAmXQgdGhpbmsgaXQgbmVlZHMNCiB0byBiZSBhIHNlcGFyYXRlIGgyIGNvbm5lY3Rpb24s IGp1c3QgYSBzZXBhcmF0ZSBHRVQpPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIHdh cyBpbml0aWFsbHkgc3VnZ2VzdGluZyB0aGF0IHdlIG1ha2UgdGhpcyDigJxhZ2dyZWdhdGlvbi1v bi1kZW1hbmTigJ0gYXMgYSDigJxzZXJ2ZXIgU0hPVUxEIHN1cHBvcnTigJ0gYnV0IGlmIHdlIHdh bnQgdG8gbWFrZSBpdCBtYW5kYXRvcnkgZm9yIFBT4oCZcyB0byBzdXBwb3J0IGl0LCBJ4oCZbSBm aW5lIHdpdGggaXQuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+RGFyc2hhazwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JD X0JPRFlfU0VDVElPTiI+DQo8ZGl2Pg0KPGRpdj5PbiA3LzIxLzE1LCAxMDoyNiBBTSwgJnF1b3Q7 QmVuamFtaW4gQmFuZ2VydCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJiYW5nZXJ0QG1vemls bGEuY29tIj5iYmFuZ2VydEBtb3ppbGxhLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVU SU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURE SU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJs dHIiPg0KPGRpdj5NeSBwcmVmZXJlbmNlIHdvdWxkIGJlIGZvciB0aGUgc2VydmVyIHRvIGJlIGFi bGUgdG8gcmVxdWlyZSB0aGlzLCByYXRoZXIgdGhhbiBsZWF2aW5nIGl0IHVwIHRvIHRoZSBjbGll bnQuIElmIGEgc2VydmVyIGRvZXNuJ3Qgd2FudCB0byBleHBlbmQgdGhlIGhlYXZ5IHJlc291cmNl IGNvc3Qgb2YgdHJlYXRpbmcgZXZlcnkgc2luZ2xlIHN1YnNjcmlwdGlvbiBhcyBpdHMgb3duIFVS TCwgdGhlcmUgc2hvdWxkIGJlIGEgd2F5IGZvciB0aGUgc2VydmVyDQogdG8gaW5kaWNhdGUgdGhh dCBpbiBpdHMgc3Vic2NyaXB0aW9uIHJlc3BvbnNlLjxicj4NCjxicj4NCjwvZGl2Pg0KRm9yIGFu IElvVCB1c2UtY2FzZSwgd2hlcmUgYSBjbGllbnQgbWlnaHQgd2FudCBkaWZmZXJlbnQgc2V0cyBv ZiBzdWJzY3JpcHRpb25zIGVudGlyZWx5LCBhbmQgdG8gb25seSBjaGVjayBvbmUgZ3JvdXAgb2Yg dGhlbSwgaXQgY291bGQgb3BlbiBhIHNlcGFyYXRlIGgyIGNvbm5lY3Rpb24gdG8gcmV0cmlldmUg dGhhdCBzZXQuPGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPg0KPGRp diBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIE1vbiwgSnVsIDIwLCAyMDE1IGF0IDI6NDEgUE0sIERh cnNoYWsgVGhha29yZSA8c3BhbiBkaXI9Imx0ciI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOmQudGhh a29yZUBjYWJsZWxhYnMuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZC50aGFrb3JlQGNhYmxlbGFicy5j b208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1 b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7 cGFkZGluZy1sZWZ0OjFleCI+DQo8YnI+DQpJdCBzZWVtcyBsaWtlIHdlIGRvIHdhbnQgc29tZSBt ZWNoYW5pc20gdGhhdCBhbGxvd3MgYSBjbGllbnQgdG8gcmV0cmlldmU8YnI+DQpub3RpZmljYXRp b25zIGZvciBhbGwgc3Vic2NyaXB0aW9ucyB3aXRoIGEgc2luZ2xlIGZldGNoLiBGb3IgSW9UIGJh c2VkIHVzZTxicj4NCmNhc2VzIGFsc28gdGhpcyBpcyBkZXNpcmFibGUuIEkgZ3Vlc3MgdGhpcyBr ZWVwcyBnb2luZyBiYWNrIHRvIHRoZTxicj4NCmFnZ3JlZ2F0aW9uLXZzLWRpc2FnZ3JlZ2F0aW9u IGRpc2N1c3Npb24uIEhvd2V2ZXIgScK5bSB3b25kZXJpbmcgaWYgaXRzPGJyPg0KcG9zc2libGUg dG8gZGVmaW5lL2NyZWF0ZSBhIHNvcnQgb2YgwrNhZ2dyZWdhdGlvbi1vbi1kZW1hbmTCsiBtb2Rl IHdpdGggdGhlPGJyPg0KZGVmYXVsdCBiZWluZyB0aGUgY3VycmVudCDCs2Rpc2FnZ3JlZ2F0aW9u wrIgbW9kZS48YnI+DQo8YnI+DQpGb3IgZXhhbXBsZSwgb25jZSBhIGNsaWVudC9VQSBoYXMgc3Vi c2NyaWJlZCBmb3IgdGhlIGZpcnN0IHRpbWUgYW5kIGhvbGRzPGJyPg0KMSBzdWJzY3JpcHRpb24s IHdoZW4gaXQgd2FudHMgdG8gY3JlYXRlIHN1YnNlcXVlbnQgc3Vic2NyaXB0aW9ucywgaXQgY2Fu PGJyPg0KaW5jbHVkZSB0aGUgZmlyc3Qgc3Vic2NyaXB0aW9uIGluIHRoZSByZXF1ZXN0Ojxicj4N Cjxicj4NClBPU1QgL3N1YnNjcmliZS8gSFRUUC8xLjE8YnI+DQpIT1NUOiA8YSBocmVmPSJodHRw Oi8vcHVzaC5leGFtcGxlLm5ldCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+cHVz aC5leGFtcGxlLm5ldDwvYT48YnI+DQpMaW5rOiAmbHQ7L3MvTEJoaHcwT29oTy1XbDRPaTk3MVVH c0I3c2RRR1VpYngmZ3Q7Ozxicj4NCnJlbD3Cs3VybjppZXRmOnBhcmFtczpwdXNoOnN1YmNyaWJl wrIgKEnCuW0gbm90IHN1cmUgaWYgaXRzIG9rIHRvIHVzZSBMaW5rPGJyPg0KaGVhZGVyIGluIGEg cmVxdWVzdCwgaWYgbm90IHdlIG5lZWQgdG8gZmluZCBzb21ldGhpbmcgbW9yZSBzdWl0YWJsZSk8 YnI+DQo8YnI+DQpXaGVuIGEgUFMgcHJvY2Vzc2VzIHRoaXMgcmVxdWVzdCwgaXQgY2FuIGFzc29j aWF0ZSB0aGUgbmV3IHN1YnNjcmlwdGlvbjxicj4NCndpdGggdGhlIG9uZSBwcm92aWRlZC4gKEkg dGhpbmsgdGhlIGFkZGl0aW9uYWwgZGF0YSBzdG9yZWQgYnkgdGhlIFBTIHRvPGJyPg0KYWNoaWV2 ZSB0aGlzIHNob3VsZCBiZSBtaW5pbWFsKS4gVGhlIHJlc3BvbnNlIHdvdWxkIGNvbnRhaW4gdGhl IG5ldzxicj4NCnN1YnNjcmlwdGlvbiBpbmZvIGFzIGN1cnJlbnRseSBkZWZpbmVkIChhbmQgbWF5 YmUgc29tZXRoaW5nIGFkZGl0aW9uYWwgdG88YnI+DQppbmRpY2F0ZSB0aGF0IHRoZSBuZXcgc3Vi c2NyaXB0aW9uIGlzIHRpZWQgdG8gdGhlIG9uZSBpbiB0aGUgcmVxdWVzdCk8YnI+DQo8YnI+DQpX aGVuIHJlY2VpdmluZyBQVVNIIG1lc3NhZ2VzLCBhIGNsaWVudC9VQSBjYW4gbWFrZSBhIHNpbmds ZSBHRVQgcmVxdWVzdCB0bzxicj4NCnRoZSBwcmltYXJ5IHN1YnNjcmlwdGlvbiByZXNvdXJjZSBh bmQgdGhlIHNlcnZlciB3aWxsIHNlbmQgcHVzaDxicj4NCm5vdGlmaWNhdGlvbnMgZm9yIGFsbCBz dWJzY3JpcHRpb25zIGFzc29jaWF0ZWQgd2l0aCB0aGUgcHJpbWFyeTxicj4NCnN1YnNjcmlwdGlv bi48YnI+DQo8YnI+DQpGb3IgZXhhbXBsZSwgdGhlIHJlcXVlc3Qgd291bGQgYmU8YnI+DQo8YnI+ DQpIRUFERVJTJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1tzdHJlYW0gN10gJiM0 MztFSERfU1RSRUFNICYjNDM7RU5EX0hFQURFUlM8YnI+DQombmJzcDsgOm1ldGhvZCZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOz0gR0VUPGJyPg0KJm5ic3A7IDpwYXRoJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOz0gL3MvTEJoaHcwT29oTy1XbDRPaTk3MVVHc0I3c2RRR1VpYng8 YnI+DQombmJzcDsgOmF1dGhvcml0eSZuYnNwOyAmbmJzcDsgPSA8YSBocmVmPSJodHRwOi8vcHVz aC5leGFtcGxlLm5ldCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+DQpwdXNoLmV4 YW1wbGUubmV0PC9hPjxicj4NCjxicj4NCkFuZCB0aGUgY29ycmVzcG9uZGluZyByZXNwb25zZSB3 b3VsZCBiZTxicj4NCjxicj4NClBVU0hfUFJPTUlTRSZuYnNwOyAmbmJzcDsgW3N0cmVhbSA3OyBw cm9taXNlZCBzdHJlYW0gNF0gJiM0MztFTkRfSEVBREVSUzxicj4NCiZuYnNwOyA6bWV0aG9kJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PSBHRVQ8YnI+DQombmJzcDsgOnBhdGgmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PSAvZC9xRElZSE5jZkFJUFBfNUlUdlVSci1kNkJHdFlu VFJuazxicj4NCiZuYnNwOyA6YXV0aG9yaXR5Jm5ic3A7ICZuYnNwOyA9IDxhIGhyZWY9Imh0dHA6 Ly9wdXNoLmV4YW1wbGUubmV0IiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj4NCnB1 c2guZXhhbXBsZS5uZXQ8L2E+PGJyPg0KPGJyPg0KSEVBREVSUyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtbc3RyZWFtIDRdICYjNDM7RU5EX0hFQURFUlM8YnI+DQombmJzcDsgOnN0 YXR1cyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOz0gMjAwPGJyPg0KJm5ic3A7IOKAueKAuU9U SEVSIEhFQURFUlMg4oC54oC5PGJyPg0KJm5ic3A7IDpjb250ZW50LWxvYyZuYnNwOyA9IC9zL0xC aGh3ME9vaE8tV2w0T2k5NzFVR3NCN3NkUUdVaWJ4PGJyPg0KPGJyPg0KREFUQSZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFtzdHJlYW0gNF0gJiM0MztFTkRfU1RSRUFN PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDtpQ2hZdUkzak16dDNpcjIwUDhyX2pnUlItZFN1TjE4 Mng3aUI8YnI+DQo8YnI+DQo8YnI+DQpQVVNIX1BST01JU0UmbmJzcDsgJm5ic3A7IFtzdHJlYW0g NzsgcHJvbWlzZWQgc3RyZWFtIDZdICYjNDM7RU5EX0hFQURFUlM8YnI+DQombmJzcDsgOm1ldGhv ZCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs9 IEdFVDxicj4NCiZuYnNwOyA6cGF0aCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PSAvZC9nanVOSlRZdVpYa3l5bE9PdGpmQUVvNmt0 UkhDQUR1aTxicj4NCiZuYnNwOyA6YXV0aG9yaXR5Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgPSA8YSBocmVmPSJodHRwOi8vcHVzaC5leGFtcGxlLm5ldCIgcmVsPSJu b3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+DQpwdXNoLmV4YW1wbGUubmV0PC9hPjxicj4NCjxi cj4NCkhFQURFUlMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7W3N0cmVhbSA2XSAm IzQzO0VORF9IRUFERVJTPGJyPg0KJm5ic3A7IDpzdGF0dXMmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDs9IDIwMDxicj4NCiZuYnNwOyDigLnigLlPVEhFUiBIRUFERVJTIOKAueKAuTxicj4NCiZu YnNwOyA6Y29udGVudC1sb2MmbmJzcDsgPSAvcy9oSjBqVzFFbENqaGpmd3doNGtUUXc3ckVZSzRR eUZGVzxicj4NCjxicj4NCkRBVEEmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBbc3RyZWFtIDZdICYjNDM7RU5EX1NUUkVBTTxicj4NCntlbmNvZGVkL2VuY3J5cHRlZC1u b3RpZmljYXRpb24tbWVzc2FnZX08YnI+DQo8YnI+DQo8YnI+DQrigLnigLkgYWRkaXRpb25hbCBQ VVNIIG1lc3NhZ2VzIGZvciBvdGhlciBzdWJzY3JpcHRpb25zIOKAueKAuTxicj4NCjxicj4NCjxi cj4NCjxicj4NCkluIHRoZSBhYm92ZSBleGFtcGxlLCB0aGUgcmVzcG9uc2VzIGNhbiBpbmNsdWRl IGEgQ29udGVudC1Mb2NhdGlvbiAob3I8YnI+DQpzb21lIG90aGVyIGFwcHJvcHJpYXRlKSBoZWFk ZXIgdG8gaW5kaWNhdGUgdGhlIGFzc29jaWF0ZWQgc3Vic2NyaXB0aW9uIGZvcjxicj4NCnRoZSBu b3RpZmljYXRpb24gbWVzc2FnZS4gVGhpcyB3b3VsZCBhbGxvdyB0aGUgY2xpZW50L1VBIHRvIHNl bmQganVzdCBvbmU8YnI+DQpHRVQgcmVxdWVzdCB0byByZXRyaWV2ZSAoYW5kIGtlZXAgcmVjZWl2 aW5nKSBub3RpZmljYXRpb25zIG9uIGFsbCBpdHM8YnI+DQphY3RpdmUgc3Vic2NyaXB0aW9ucy4g QSBjbGllbnQvVUEgbWF5IGV2ZW4gY2hvb3NlIHRvIGtlZXAgY2VydGFpbjxicj4NCnN1YnNjcmlw dGlvbnMgc2VwYXJhdGUgYW5kIGdyb3VwIG9ubHkgYSBzdWJzZXQgb2YgdGhlbSAodGhpcyB3b3Vs ZCBiZTxicj4NCnVzZWZ1bCBpbiBJb1QgbGlrZSBjYXNlcyk8YnI+DQo8YnI+DQo8YnI+DQpEYXJz aGFrPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KT24gNy8yMC8xNSwgMTA6MzEgQU0sICZx dW90O1dlYnB1c2ggb24gYmVoYWxmIG9mIE1hcnRpbiBUaG9tc29uJnF1b3Q7PGJyPg0KPGRpdj4N CjxkaXYgY2xhc3M9Img1Ij4mbHQ7PGEgaHJlZj0ibWFpbHRvOndlYnB1c2gtYm91bmNlc0BpZXRm Lm9yZyI+d2VicHVzaC1ib3VuY2VzQGlldGYub3JnPC9hPiBvbiBiZWhhbGYgb2YNCjxhIGhyZWY9 Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iPm1hcnRpbi50aG9tc29uQGdtYWlsLmNv bTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCiZndDtPbiAyMCBKdWx5IDIwMTUgYXQgMDk6MjEs IEJlbmphbWluIEJhbmdlcnQgJmx0OzxhIGhyZWY9Im1haWx0bzpiYmFuZ2VydEBtb3ppbGxhLmNv bSI+YmJhbmdlcnRAbW96aWxsYS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyBXaGF0 J3MgdGhlIHVzZS1jYXNlIG9mIGEgY2xpZW50IHBvbGxpbmcgb3ZlciBhIGxvbmctbGl2ZWQgY29u bmVjdGlvbjxicj4NCiZndDs8YnI+DQomZ3Q7VGhlIHVzZSBjYXNlIGlzIGZvciBhIGRldmljZSB0 aGF0IGlzIG9ubHkgcGVyaW9kaWNhbGx5IG9ubGluZSAoYTxicj4NCiZndDtjb25zdHJhaW5lZCBk ZXZpY2UpIHRoYXQgd2FudHMgdG8gY2hlY2sgaW4sIHRoZW4gaW1tZWRpYXRlbHkgZ288YnI+DQom Z3Q7b2ZmbGluZSBhZ2Fpbi48YnI+DQomZ3Q7PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCiZndDtfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDtXZWJw dXNoIG1haWxpbmcgbGlzdDxicj4NCiZndDs8YSBocmVmPSJtYWlsdG86V2VicHVzaEBpZXRmLm9y ZyI+V2VicHVzaEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby93ZWJwdXNoIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3dlYnB1c2g8L2E+ PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpXZWJwdXNoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpXZWJwdXNo QGlldGYub3JnIj5XZWJwdXNoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vd2VicHVzaCIgcmVsPSJub3JlZmVycmVyIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby93ZWJwdXNo PC9hPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D1D4ACBF70D8dthakorecablelabscom_-- From nobody Wed Jul 22 01:26:06 2015 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 362021A044F for ; Wed, 22 Jul 2015 01:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.227 X-Spam-Level: X-Spam-Status: No, score=0.227 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] 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 QfH8sEgPOl6Q for ; Wed, 22 Jul 2015 01:26:01 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 68BC61A009D for ; Wed, 22 Jul 2015 01:26:01 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id t6M8Q0vL009276; Wed, 22 Jul 2015 02:26:00 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Wed, 22 Jul 2015 02:26:00 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([::1]) by EXCHANGE.cablelabs.com ([::1]) with mapi id 14.03.0224.002; Wed, 22 Jul 2015 02:25:59 -0600 From: Darshak Thakore To: Costin Manolache , Benjamin Bangert Thread-Topic: [Webpush] comments on latest draft-thomson-webpush-protocol-00 Thread-Index: AQHQunlLM+hV2NIVmEuOC+Bk2k+U+Z3ju0gAgAFEnICAAALrAP//8eCAgAGe6oCAAIw5gIAAG00A Date: Wed, 22 Jul 2015 08:25:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 x-originating-ip: [10.5.0.27] Content-Type: multipart/alternative; boundary="_000_D1D4AD8170E0dthakorecablelabscom_" MIME-Version: 1.0 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] comments on latest draft-thomson-webpush-protocol-00 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, 22 Jul 2015 08:26:04 -0000 --_000_D1D4AD8170E0dthakorecablelabscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29tbWVudHMgYmVsb3cNCg0KT24gNy8yMS8xNSwgNjo0OCBQTSwgIkNvc3RpbiBNYW5vbGFjaGUi IDxjb3N0aW5AZ21haWwuY29tPG1haWx0bzpjb3N0aW5AZ21haWwuY29tPj4gd3JvdGU6DQoNCkkg dGhpbmsgb25lIHF1ZXN0aW9uIGlzIHdobyBtYWtlcyB0aGUgZGVjaXNpb24gaWYgc3Vic2NycHRp b25zIGFyZSAnYWdncmVnYXRlZCcgb3Igbm90LiBBbmQgdGhlIG9ubHkgYW5zd2VyDQpJIGtub3cg aXMgdGhlIHB1c2ggcHJvdmlkZXIgLSBzaW5jZSB0aGUgcHVzaCBwcm92aWRlciBpcyB0aGUgb25l IGJlYXJpbmcgdGhlIGNvc3RzIGFuZCBkZWZpbmluZyB0aGUNCnJlcXVpcmVtZW50cyBmb3IgVUFz IHRoYXQgY29ubmVjdCB0byBpdC4NCg0KRFQ+PiBBcyBJIG1lbnRpb25lZCBpbiB0aGUgb3RoZXIg ZW1haWwgKEJlbmphbWlu4oCZcyBlbWFpbCksIEnigJltIG5vdCBzdXJlIGhvdyBhIFBTIGNhbiBm b3JjZSBhIFVBIHRvIGFnZ3JlZ2F0ZSAodW5sZXNzIHRoZSBQUyBzb21laG93IGlkZW50aWZpZXMg dGhlIGNsaWVudCBiYXNlZCBvbiBhdXRoZW50aWNhdGlvbi9jb29raWUvc29tZXRoaW5nLWVsc2Up LiBJIHRoaW5rIHRoZSBQUyBzaG91bGQvbXVzdCBzdXBwb3J0IGl0IGJ1dCBpdCB3b3VsZCBiZSB0 aGUgY2xpZW50L1VB4oCZcyBkZWNpc2lvbiB0byBhZ2dyZWdhdGUuIFdlIGNhbiBwdXQgbGFuZ3Vh Z2UgdG8g4oCcc3Ryb25nbHkgcmVjb21tZW5k4oCdIHRoZSBjbGllbnQvVUEgdG8gYWdncmVnYXRl IGJ1dCBpdCB3b3VsZCBzdGlsbCBiZSB0aGUgY2xpZW504oCZcyBkZWNpc2lvbiB0byBpbmNsdWRl IHRoZSBpbml0aWFsIHN1YnNjcmlwdGlvbiB3aGVuIG1ha2luZyBzdWJzZXF1ZW50IHN1YnNjcmlw dGlvbiByZXF1ZXN0cy4NCg0KDQpJZiB3ZSBhZ3JlZSB0aGF0IGEgcHVzaCBwcm92aWRlciBtYXkg cmVxdWlyZSAnYWdncmVnYXRpb24nIC0gYWxsIHN1YnNjcmlwdGlvbnMgZnJvbSBhIGRldmljZSwg d2hlbiBjb25uZWN0aW5nDQp0byBzdWNoIGEgcHJvdmlkZXIsIHdpbGwgbmVlZCB0byBoYXZlIHNv bWV0aGluZyBpbiBjb21tb24sIHRvIGFsbG93IHRoZSBhZ2dyZWdhdGlvbi4gVGhlIG9yaWdpbmFs DQogInJlZ2lzdHJhdGlvbiArIHN1YnNjcmlwdGlvbiIgZG9lcyBpdCBieSBoYXZpbmcgYSBmaXJz dCBzdGVwIHdoZXJlIGEgZGV2aWNlIGdldHMgdGhlIGNvbW1vbiBlbGVtZW50Lg0KSXQgY2FuIGJl IHNpbXBsaWZpZWQgYnkgZGVmaW5pbmcgdGhlICdyZWdpc3RyYXRpb24nIGFzIGEgcmVndWxhciBz dWJzY3JpcHRpb24sIGFuZCBhbGxvd2luZyBlYWNoIGFwcCB0bw0KIGhhdmUgYSAnY2hpbGQnIHN1 YnNjcmlwdGlvbi4gVGhpcyB3b3JrcyBuaWNlbHkgaWYgYSBVQSBzdXBwb3J0cyBwcm9maWxlcy9t dWx0aS11c2VyIGZvciBleGFtcGxlIC0gYW5kIG1heQ0KYmUgZXh0ZW5kZWQgbGF0ZXIgZm9yIG1v cmUgY29tcGxpY2F0ZWQgY2FzZXMsIHdoZXJlIGEgVUEgYWN0cyBhcyBhIHByb3h5IGZvciBvdGhl ciBVQXMgKCBmb3IgZXhhbXBsZQ0KYSB3ZWFyYWJsZSBkZXZpY2UgcGFpcmVkIG92ZXIgQlQgKS4N Cg0KRFQ+PiBJIHRoaW5rIHdpdGhpbiB0aGUgY29udGV4dCBvZiB0aGUgZmFjdCB0aGF0IGEgY2xp ZW50IGRvZXMgd2FudCB0byDigJxhZ2dyZWdhdGXigJ0sIGFsbCBvZiB0aGUgYWJvdmUgaXMgZG9h YmxlLiBIb3dldmVyIGFzIEkgbWVudGlvbmVkIGFib3ZlLCBpZiBhIGNsaWVudCBkb2VzIG5vdCBz ZW5kIHRoZSDigJxwYXJlbnQgc3Vic2NyaXB0aW9u4oCdIGluZm8gaW4gdGhlIHN1YnNlcXVlbnQg c3Vic2NyaXB0aW9uIHJlcXVlc3RzLCB0aGVyZeKAmXMgbm8gZWFzeSB3YXkgZm9yIGEgUFMgdG8g Zm9yY2UgYWdncmVnYXRpb24uDQoNCg0KDQpUaGUgc3Vic2NyaXB0aW9uIEFQSSBzaG91bGQgYWxs b3cgYSB3YXkgdG8gY3JlYXRlICdsaW5rcycgYmV0d2VlbiBzdWJzY3JpcHRpb25zLiBXZSBkbyBu ZWVkIHRvDQpmaW5pc2ggdGhlIHNlcGFyYXRlIGRpc2N1c3Npb24gb24gc2VuZGVyIGF1dGhlbnRp Y2F0aW9uIGFuZCByZWdpc3RyYXRpb24gLSBidXQgYXNzdW1pbmcgYSBwdXNoIHNlcnZpY2UNCnJl cXVpcmVzIHNlbmRlciBhdXRoZW50aWNhdGlvbiwgdGhpcyBpcyBhbm90aGVyICdsaW5rJyBiZXR3 ZWVuIHRoZSBhcHAgc3Vic2NyaXB0aW9uIGFuZCB0aGUgc2VydmVyIGlkICgNCndoaWNoIGNhbiBi ZSBhbm90aGVyIGNhcGFiaWxpdHkgVVJMIG9yIHN1YnNjcmlwdGlvbiApLg0KDQpEVD4+IFllcywg SSBiZWxpZXZlIHRoYXQgc2hvdWxkIGJlIGRvYWJsZSB3aXRoIHRoZSBpZGVhIGhlcmUuDQoNCg0K SSBkb24ndCB0aGluayBpdCdzIGEgcHJvYmxlbSBpZiB0aGUgJ25vbi1hZ2dyZWdhdGVkJyBtb2Rl bCAtIHdoZXJlIG5vdGhpbmcgaXMgc2hhcmVkIC0gaXMgZGVmaW5lZCBldmVuIGFzIGRlZmF1bHQs DQphbmQgc29tZSBwdXNoIHByb3ZpZGVycyBtYXkgY2hvc2UgdG8gc3VwcG9ydCBib3RoLCBvciBv bmx5IG9uZSBtb2RlbCwgZGVwZW5kaW5nIG9uIHRoZWlyIHNjYWxlIGFuZCBjb3N0cw0KDQpDb3N0 aW4NCg0KT24gVHVlLCBKdWwgMjEsIDIwMTUgYXQgOToyNiBBTSwgQmVuamFtaW4gQmFuZ2VydCA8 YmJhbmdlcnRAbW96aWxsYS5jb208bWFpbHRvOmJiYW5nZXJ0QG1vemlsbGEuY29tPj4gd3JvdGU6 DQpNeSBwcmVmZXJlbmNlIHdvdWxkIGJlIGZvciB0aGUgc2VydmVyIHRvIGJlIGFibGUgdG8gcmVx dWlyZSB0aGlzLCByYXRoZXIgdGhhbiBsZWF2aW5nIGl0IHVwIHRvIHRoZSBjbGllbnQuIElmIGEg c2VydmVyIGRvZXNuJ3Qgd2FudCB0byBleHBlbmQgdGhlIGhlYXZ5IHJlc291cmNlIGNvc3Qgb2Yg dHJlYXRpbmcgZXZlcnkgc2luZ2xlIHN1YnNjcmlwdGlvbiBhcyBpdHMgb3duIFVSTCwgdGhlcmUg c2hvdWxkIGJlIGEgd2F5IGZvciB0aGUgc2VydmVyIHRvIGluZGljYXRlIHRoYXQgaW4gaXRzIHN1 YnNjcmlwdGlvbiByZXNwb25zZS4NCg0KRm9yIGFuIElvVCB1c2UtY2FzZSwgd2hlcmUgYSBjbGll bnQgbWlnaHQgd2FudCBkaWZmZXJlbnQgc2V0cyBvZiBzdWJzY3JpcHRpb25zIGVudGlyZWx5LCBh bmQgdG8gb25seSBjaGVjayBvbmUgZ3JvdXAgb2YgdGhlbSwgaXQgY291bGQgb3BlbiBhIHNlcGFy YXRlIGgyIGNvbm5lY3Rpb24gdG8gcmV0cmlldmUgdGhhdCBzZXQuDQoNCk9uIE1vbiwgSnVsIDIw LCAyMDE1IGF0IDI6NDEgUE0sIERhcnNoYWsgVGhha29yZSA8ZC50aGFrb3JlQGNhYmxlbGFicy5j b208bWFpbHRvOmQudGhha29yZUBjYWJsZWxhYnMuY29tPj4gd3JvdGU6DQoNCkl0IHNlZW1zIGxp a2Ugd2UgZG8gd2FudCBzb21lIG1lY2hhbmlzbSB0aGF0IGFsbG93cyBhIGNsaWVudCB0byByZXRy aWV2ZQ0Kbm90aWZpY2F0aW9ucyBmb3IgYWxsIHN1YnNjcmlwdGlvbnMgd2l0aCBhIHNpbmdsZSBm ZXRjaC4gRm9yIElvVCBiYXNlZCB1c2UNCmNhc2VzIGFsc28gdGhpcyBpcyBkZXNpcmFibGUuIEkg Z3Vlc3MgdGhpcyBrZWVwcyBnb2luZyBiYWNrIHRvIHRoZQ0KYWdncmVnYXRpb24tdnMtZGlzYWdn cmVnYXRpb24gZGlzY3Vzc2lvbi4gSG93ZXZlciBJwrltIHdvbmRlcmluZyBpZiBpdHMNCnBvc3Np YmxlIHRvIGRlZmluZS9jcmVhdGUgYSBzb3J0IG9mIMKzYWdncmVnYXRpb24tb24tZGVtYW5kwrIg bW9kZSB3aXRoIHRoZQ0KZGVmYXVsdCBiZWluZyB0aGUgY3VycmVudCDCs2Rpc2FnZ3JlZ2F0aW9u wrIgbW9kZS4NCg0KRm9yIGV4YW1wbGUsIG9uY2UgYSBjbGllbnQvVUEgaGFzIHN1YnNjcmliZWQg Zm9yIHRoZSBmaXJzdCB0aW1lIGFuZCBob2xkcw0KMSBzdWJzY3JpcHRpb24sIHdoZW4gaXQgd2Fu dHMgdG8gY3JlYXRlIHN1YnNlcXVlbnQgc3Vic2NyaXB0aW9ucywgaXQgY2FuDQppbmNsdWRlIHRo ZSBmaXJzdCBzdWJzY3JpcHRpb24gaW4gdGhlIHJlcXVlc3Q6DQoNClBPU1QgL3N1YnNjcmliZS8g SFRUUC8xLjENCkhPU1Q6IHB1c2guZXhhbXBsZS5uZXQ8aHR0cDovL3B1c2guZXhhbXBsZS5uZXQ+ DQpMaW5rOiA8L3MvTEJoaHcwT29oTy1XbDRPaTk3MVVHc0I3c2RRR1VpYng+Ow0KcmVsPcKzdXJu OmlldGY6cGFyYW1zOnB1c2g6c3ViY3JpYmXCsiAoScK5bSBub3Qgc3VyZSBpZiBpdHMgb2sgdG8g dXNlIExpbmsNCmhlYWRlciBpbiBhIHJlcXVlc3QsIGlmIG5vdCB3ZSBuZWVkIHRvIGZpbmQgc29t ZXRoaW5nIG1vcmUgc3VpdGFibGUpDQoNCldoZW4gYSBQUyBwcm9jZXNzZXMgdGhpcyByZXF1ZXN0 LCBpdCBjYW4gYXNzb2NpYXRlIHRoZSBuZXcgc3Vic2NyaXB0aW9uDQp3aXRoIHRoZSBvbmUgcHJv dmlkZWQuIChJIHRoaW5rIHRoZSBhZGRpdGlvbmFsIGRhdGEgc3RvcmVkIGJ5IHRoZSBQUyB0bw0K YWNoaWV2ZSB0aGlzIHNob3VsZCBiZSBtaW5pbWFsKS4gVGhlIHJlc3BvbnNlIHdvdWxkIGNvbnRh aW4gdGhlIG5ldw0Kc3Vic2NyaXB0aW9uIGluZm8gYXMgY3VycmVudGx5IGRlZmluZWQgKGFuZCBt YXliZSBzb21ldGhpbmcgYWRkaXRpb25hbCB0bw0KaW5kaWNhdGUgdGhhdCB0aGUgbmV3IHN1YnNj cmlwdGlvbiBpcyB0aWVkIHRvIHRoZSBvbmUgaW4gdGhlIHJlcXVlc3QpDQoNCldoZW4gcmVjZWl2 aW5nIFBVU0ggbWVzc2FnZXMsIGEgY2xpZW50L1VBIGNhbiBtYWtlIGEgc2luZ2xlIEdFVCByZXF1 ZXN0IHRvDQp0aGUgcHJpbWFyeSBzdWJzY3JpcHRpb24gcmVzb3VyY2UgYW5kIHRoZSBzZXJ2ZXIg d2lsbCBzZW5kIHB1c2gNCm5vdGlmaWNhdGlvbnMgZm9yIGFsbCBzdWJzY3JpcHRpb25zIGFzc29j aWF0ZWQgd2l0aCB0aGUgcHJpbWFyeQ0Kc3Vic2NyaXB0aW9uLg0KDQpGb3IgZXhhbXBsZSwgdGhl IHJlcXVlc3Qgd291bGQgYmUNCg0KSEVBREVSUyAgICAgICAgIFtzdHJlYW0gN10gK0VIRF9TVFJF QU0gK0VORF9IRUFERVJTDQogIDptZXRob2QgICAgICAgPSBHRVQNCiAgOnBhdGggICAgICAgICA9 IC9zL0xCaGh3ME9vaE8tV2w0T2k5NzFVR3NCN3NkUUdVaWJ4DQogIDphdXRob3JpdHkgICAgPSBw dXNoLmV4YW1wbGUubmV0PGh0dHA6Ly9wdXNoLmV4YW1wbGUubmV0Pg0KDQpBbmQgdGhlIGNvcnJl c3BvbmRpbmcgcmVzcG9uc2Ugd291bGQgYmUNCg0KUFVTSF9QUk9NSVNFICAgIFtzdHJlYW0gNzsg cHJvbWlzZWQgc3RyZWFtIDRdICtFTkRfSEVBREVSUw0KICA6bWV0aG9kICAgICAgID0gR0VUDQog IDpwYXRoICAgICAgICAgPSAvZC9xRElZSE5jZkFJUFBfNUlUdlVSci1kNkJHdFluVFJuaw0KICA6 YXV0aG9yaXR5ICAgID0gcHVzaC5leGFtcGxlLm5ldDxodHRwOi8vcHVzaC5leGFtcGxlLm5ldD4N Cg0KSEVBREVSUyAgICAgICAgIFtzdHJlYW0gNF0gK0VORF9IRUFERVJTDQogIDpzdGF0dXMgICAg ICAgPSAyMDANCiAg4oC54oC5T1RIRVIgSEVBREVSUyDigLnigLkNCiAgOmNvbnRlbnQtbG9jICA9 IC9zL0xCaGh3ME9vaE8tV2w0T2k5NzFVR3NCN3NkUUdVaWJ4DQoNCkRBVEEgICAgICAgICAgICBb c3RyZWFtIDRdICtFTkRfU1RSRUFNDQogICAgIGlDaFl1STNqTXp0M2lyMjBQOHJfamdSUi1kU3VO MTgyeDdpQg0KDQoNClBVU0hfUFJPTUlTRSAgICBbc3RyZWFtIDc7IHByb21pc2VkIHN0cmVhbSA2 XSArRU5EX0hFQURFUlMNCiAgOm1ldGhvZCAgICAgICAgICAgICAgID0gR0VUDQogIDpwYXRoICAg ICAgICAgICAgICAgICA9IC9kL2dqdU5KVFl1WlhreXlsT090amZBRW82a3RSSENBRHVpDQogIDph dXRob3JpdHkgICAgICAgICAgICA9IHB1c2guZXhhbXBsZS5uZXQ8aHR0cDovL3B1c2guZXhhbXBs ZS5uZXQ+DQoNCkhFQURFUlMgICAgICAgICBbc3RyZWFtIDZdICtFTkRfSEVBREVSUw0KICA6c3Rh dHVzICAgICAgID0gMjAwDQogIOKAueKAuU9USEVSIEhFQURFUlMg4oC54oC5DQogIDpjb250ZW50 LWxvYyAgPSAvcy9oSjBqVzFFbENqaGpmd3doNGtUUXc3ckVZSzRReUZGVw0KDQpEQVRBICAgICAg ICAgICAgW3N0cmVhbSA2XSArRU5EX1NUUkVBTQ0Ke2VuY29kZWQvZW5jcnlwdGVkLW5vdGlmaWNh dGlvbi1tZXNzYWdlfQ0KDQoNCuKAueKAuSBhZGRpdGlvbmFsIFBVU0ggbWVzc2FnZXMgZm9yIG90 aGVyIHN1YnNjcmlwdGlvbnMg4oC54oC5DQoNCg0KDQpJbiB0aGUgYWJvdmUgZXhhbXBsZSwgdGhl IHJlc3BvbnNlcyBjYW4gaW5jbHVkZSBhIENvbnRlbnQtTG9jYXRpb24gKG9yDQpzb21lIG90aGVy IGFwcHJvcHJpYXRlKSBoZWFkZXIgdG8gaW5kaWNhdGUgdGhlIGFzc29jaWF0ZWQgc3Vic2NyaXB0 aW9uIGZvcg0KdGhlIG5vdGlmaWNhdGlvbiBtZXNzYWdlLiBUaGlzIHdvdWxkIGFsbG93IHRoZSBj bGllbnQvVUEgdG8gc2VuZCBqdXN0IG9uZQ0KR0VUIHJlcXVlc3QgdG8gcmV0cmlldmUgKGFuZCBr ZWVwIHJlY2VpdmluZykgbm90aWZpY2F0aW9ucyBvbiBhbGwgaXRzDQphY3RpdmUgc3Vic2NyaXB0 aW9ucy4gQSBjbGllbnQvVUEgbWF5IGV2ZW4gY2hvb3NlIHRvIGtlZXAgY2VydGFpbg0Kc3Vic2Ny aXB0aW9ucyBzZXBhcmF0ZSBhbmQgZ3JvdXAgb25seSBhIHN1YnNldCBvZiB0aGVtICh0aGlzIHdv dWxkIGJlDQp1c2VmdWwgaW4gSW9UIGxpa2UgY2FzZXMpDQoNCg0KRGFyc2hhaw0KDQoNCg0KDQpP biA3LzIwLzE1LCAxMDozMSBBTSwgIldlYnB1c2ggb24gYmVoYWxmIG9mIE1hcnRpbiBUaG9tc29u Ig0KPHdlYnB1c2gtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86d2VicHVzaC1ib3VuY2VzQGlldGYu b3JnPiBvbiBiZWhhbGYgb2YgbWFydGluLnRob21zb25AZ21haWwuY29tPG1haWx0bzptYXJ0aW4u dGhvbXNvbkBnbWFpbC5jb20+PiB3cm90ZToNCg0KPk9uIDIwIEp1bHkgMjAxNSBhdCAwOToyMSwg QmVuamFtaW4gQmFuZ2VydCA8YmJhbmdlcnRAbW96aWxsYS5jb208bWFpbHRvOmJiYW5nZXJ0QG1v emlsbGEuY29tPj4gd3JvdGU6DQo+PiBXaGF0J3MgdGhlIHVzZS1jYXNlIG9mIGEgY2xpZW50IHBv bGxpbmcgb3ZlciBhIGxvbmctbGl2ZWQgY29ubmVjdGlvbg0KPg0KPlRoZSB1c2UgY2FzZSBpcyBm b3IgYSBkZXZpY2UgdGhhdCBpcyBvbmx5IHBlcmlvZGljYWxseSBvbmxpbmUgKGENCj5jb25zdHJh aW5lZCBkZXZpY2UpIHRoYXQgd2FudHMgdG8gY2hlY2sgaW4sIHRoZW4gaW1tZWRpYXRlbHkgZ28N Cj5vZmZsaW5lIGFnYWluLg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+V2VicHVzaCBtYWlsaW5nIGxpc3QNCj5XZWJwdXNoQGlldGYub3JnPG1h aWx0bzpXZWJwdXNoQGlldGYub3JnPg0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vd2VicHVzaA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KV2VicHVzaCBtYWlsaW5nIGxpc3QNCldlYnB1c2hAaWV0Zi5vcmc8bWFpbHRvOldl YnB1c2hAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3dl YnB1c2gNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KV2VicHVzaCBtYWlsaW5nIGxpc3QNCldlYnB1c2hAaWV0Zi5vcmc8bWFpbHRvOldlYnB1c2hA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3dlYnB1c2gN Cg0KDQo= --_000_D1D4AD8170E0dthakorecablelabscom_ Content-Type: text/html; charset="utf-8" Content-ID: <6A203AD67D809D44AACE3E1DAC06272A@cablelabs.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5Db21tZW50cyBi ZWxvdzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VD VElPTiI+DQo8ZGl2Pg0KPGRpdj5PbiA3LzIxLzE1LCA2OjQ4IFBNLCAmcXVvdDtDb3N0aW4gTWFu b2xhY2hlJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Y29zdGluQGdtYWlsLmNvbSI+Y29zdGlu QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0 eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJ TjowIDAgMCA1OyI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPkkgdGhpbmsgb25lIHF1 ZXN0aW9uIGlzIHdobyBtYWtlcyB0aGUgZGVjaXNpb24gaWYgc3Vic2NycHRpb25zIGFyZSAnYWdn cmVnYXRlZCcgb3Igbm90LiBBbmQgdGhlIG9ubHkgYW5zd2VyJm5ic3A7DQo8ZGl2Pkkga25vdyBp cyB0aGUgcHVzaCBwcm92aWRlciAtIHNpbmNlIHRoZSBwdXNoIHByb3ZpZGVyIGlzIHRoZSBvbmUg YmVhcmluZyB0aGUgY29zdHMgYW5kIGRlZmluaW5nIHRoZSZuYnNwOzwvZGl2Pg0KPGRpdj5yZXF1 aXJlbWVudHMgZm9yIFVBcyB0aGF0IGNvbm5lY3QgdG8gaXQuJm5ic3A7PC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj5EVCZndDsmZ3Q7IEFzIEkgbWVudGlvbmVkIGluIHRoZSBvdGhlciBlbWFpbCAoQmVu amFtaW7igJlzIGVtYWlsKSwgSeKAmW0gbm90IHN1cmUgaG93IGEgUFMgY2FuIGZvcmNlIGEgVUEg dG8gYWdncmVnYXRlICh1bmxlc3MgdGhlIFBTIHNvbWVob3cgaWRlbnRpZmllcyB0aGUgY2xpZW50 IGJhc2VkIG9uIGF1dGhlbnRpY2F0aW9uL2Nvb2tpZS9zb21ldGhpbmctZWxzZSkuIEkgdGhpbmsg dGhlIFBTIHNob3VsZC9tdXN0IHN1cHBvcnQgaXQgYnV0IGl0IHdvdWxkDQogYmUgdGhlIGNsaWVu dC9VQeKAmXMgZGVjaXNpb24gdG8gYWdncmVnYXRlLiBXZSBjYW4gcHV0IGxhbmd1YWdlIHRvIOKA nHN0cm9uZ2x5IHJlY29tbWVuZOKAnSB0aGUgY2xpZW50L1VBIHRvIGFnZ3JlZ2F0ZSBidXQgaXQg d291bGQgc3RpbGwgYmUgdGhlIGNsaWVudOKAmXMgZGVjaXNpb24gdG8gaW5jbHVkZSB0aGUgaW5p dGlhbCBzdWJzY3JpcHRpb24gd2hlbiBtYWtpbmcgc3Vic2VxdWVudCBzdWJzY3JpcHRpb24gcmVx dWVzdHMuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9T RUNUSU9OIj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FV T1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1 OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2PklmIHdlIGFncmVlIHRoYXQgYSBwdXNoIHByb3ZpZGVyIG1heSBy ZXF1aXJlICdhZ2dyZWdhdGlvbicgLSBhbGwgc3Vic2NyaXB0aW9ucyBmcm9tIGEgZGV2aWNlLCB3 aGVuIGNvbm5lY3Rpbmc8L2Rpdj4NCjxkaXY+dG8gc3VjaCBhIHByb3ZpZGVyLCB3aWxsIG5lZWQg dG8gaGF2ZSBzb21ldGhpbmcgaW4gY29tbW9uLCB0byBhbGxvdyB0aGUgYWdncmVnYXRpb24uIFRo ZSBvcmlnaW5hbDwvZGl2Pg0KPGRpdj4mbmJzcDsmcXVvdDtyZWdpc3RyYXRpb24gJiM0Mzsgc3Vi c2NyaXB0aW9uJnF1b3Q7IGRvZXMgaXQgYnkgaGF2aW5nIGEgZmlyc3Qgc3RlcCB3aGVyZSBhIGRl dmljZSBnZXRzIHRoZSBjb21tb24gZWxlbWVudC4mbmJzcDs8L2Rpdj4NCjxkaXY+SXQgY2FuIGJl IHNpbXBsaWZpZWQgYnkgZGVmaW5pbmcgdGhlICdyZWdpc3RyYXRpb24nIGFzIGEgcmVndWxhciBz dWJzY3JpcHRpb24sIGFuZCBhbGxvd2luZyBlYWNoIGFwcCB0bzwvZGl2Pg0KPGRpdj4mbmJzcDto YXZlIGEgJ2NoaWxkJyBzdWJzY3JpcHRpb24uIFRoaXMgd29ya3MgbmljZWx5IGlmIGEgVUEgc3Vw cG9ydHMgcHJvZmlsZXMvbXVsdGktdXNlciBmb3IgZXhhbXBsZSAtIGFuZCBtYXkmbmJzcDs8L2Rp dj4NCjxkaXY+YmUgZXh0ZW5kZWQgbGF0ZXIgZm9yIG1vcmUgY29tcGxpY2F0ZWQgY2FzZXMsIHdo ZXJlIGEgVUEgYWN0cyBhcyBhIHByb3h5IGZvciBvdGhlciBVQXMgKCBmb3IgZXhhbXBsZSZuYnNw OzwvZGl2Pg0KPGRpdj5hIHdlYXJhYmxlIGRldmljZSBwYWlyZWQgb3ZlciBCVCApLiZuYnNwOzwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+RFQmZ3Q7Jmd0OyBJIHRoaW5rIHdpdGhpbiB0aGUgY29udGV4 dCBvZiB0aGUgZmFjdCB0aGF0IGEgY2xpZW50IGRvZXMgd2FudCB0byDigJxhZ2dyZWdhdGXigJ0s IGFsbCBvZiB0aGUgYWJvdmUgaXMgZG9hYmxlLiBIb3dldmVyIGFzIEkgbWVudGlvbmVkIGFib3Zl LCBpZiBhIGNsaWVudCBkb2VzIG5vdCBzZW5kIHRoZSDigJxwYXJlbnQgc3Vic2NyaXB0aW9u4oCd IGluZm8gaW4gdGhlIHN1YnNlcXVlbnQgc3Vic2NyaXB0aW9uIHJlcXVlc3RzLCB0aGVyZeKAmXMg bm8gZWFzeQ0KIHdheSBmb3IgYSBQUyB0byBmb3JjZSBhZ2dyZWdhdGlvbi4mbmJzcDs8L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNf Qk9EWV9TRUNUSU9OIj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9C TE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzow IDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZSBzdWJzY3JpcHRpb24gQVBJIHNob3VsZCBhbGxv dyBhIHdheSB0byBjcmVhdGUgJ2xpbmtzJyBiZXR3ZWVuIHN1YnNjcmlwdGlvbnMuIFdlIGRvIG5l ZWQgdG8mbmJzcDs8L2Rpdj4NCjxkaXY+ZmluaXNoIHRoZSBzZXBhcmF0ZSBkaXNjdXNzaW9uIG9u IHNlbmRlciBhdXRoZW50aWNhdGlvbiBhbmQgcmVnaXN0cmF0aW9uIC0gYnV0IGFzc3VtaW5nIGEg cHVzaCBzZXJ2aWNlPC9kaXY+DQo8ZGl2PnJlcXVpcmVzIHNlbmRlciBhdXRoZW50aWNhdGlvbiwg dGhpcyBpcyBhbm90aGVyICdsaW5rJyBiZXR3ZWVuIHRoZSBhcHAgc3Vic2NyaXB0aW9uIGFuZCB0 aGUgc2VydmVyIGlkICg8L2Rpdj4NCjxkaXY+d2hpY2ggY2FuIGJlIGFub3RoZXIgY2FwYWJpbGl0 eSBVUkwgb3Igc3Vic2NyaXB0aW9uICkuJm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5EVCZn dDsmZ3Q7IFllcywgSSBiZWxpZXZlIHRoYXQgc2hvdWxkIGJlIGRvYWJsZSB3aXRoIHRoZSBpZGVh IGhlcmUuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNf Qk9EWV9TRUNUSU9OIj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9C TE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzow IDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgZG9uJ3QgdGhpbmsgaXQncyBhIHByb2JsZW0gaWYg dGhlICdub24tYWdncmVnYXRlZCcgbW9kZWwgLSB3aGVyZSBub3RoaW5nIGlzIHNoYXJlZCAtIGlz IGRlZmluZWQgZXZlbiBhcyBkZWZhdWx0LDwvZGl2Pg0KPGRpdj5hbmQgc29tZSBwdXNoIHByb3Zp ZGVycyBtYXkgY2hvc2UgdG8gc3VwcG9ydCBib3RoLCBvciBvbmx5IG9uZSBtb2RlbCwgZGVwZW5k aW5nIG9uIHRoZWlyIHNjYWxlIGFuZCBjb3N0czwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+ DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5 bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lO OjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj5Db3N0aW48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEi Pjxicj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBUdWUsIEp1bCAyMSwgMjAxNSBhdCA5 OjI2IEFNLCBCZW5qYW1pbiBCYW5nZXJ0IDxzcGFuIGRpcj0ibHRyIj4NCiZsdDs8YSBocmVmPSJt YWlsdG86YmJhbmdlcnRAbW96aWxsYS5jb20iIHRhcmdldD0iX2JsYW5rIj5iYmFuZ2VydEBtb3pp bGxhLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21h aWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBz b2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdj5NeSBwcmVmZXJl bmNlIHdvdWxkIGJlIGZvciB0aGUgc2VydmVyIHRvIGJlIGFibGUgdG8gcmVxdWlyZSB0aGlzLCBy YXRoZXIgdGhhbiBsZWF2aW5nIGl0IHVwIHRvIHRoZSBjbGllbnQuIElmIGEgc2VydmVyIGRvZXNu J3Qgd2FudCB0byBleHBlbmQgdGhlIGhlYXZ5IHJlc291cmNlIGNvc3Qgb2YgdHJlYXRpbmcgZXZl cnkgc2luZ2xlIHN1YnNjcmlwdGlvbiBhcyBpdHMgb3duIFVSTCwgdGhlcmUgc2hvdWxkIGJlIGEg d2F5IGZvciB0aGUgc2VydmVyDQogdG8gaW5kaWNhdGUgdGhhdCBpbiBpdHMgc3Vic2NyaXB0aW9u IHJlc3BvbnNlLjxicj4NCjxicj4NCjwvZGl2Pg0KRm9yIGFuIElvVCB1c2UtY2FzZSwgd2hlcmUg YSBjbGllbnQgbWlnaHQgd2FudCBkaWZmZXJlbnQgc2V0cyBvZiBzdWJzY3JpcHRpb25zIGVudGly ZWx5LCBhbmQgdG8gb25seSBjaGVjayBvbmUgZ3JvdXAgb2YgdGhlbSwgaXQgY291bGQgb3BlbiBh IHNlcGFyYXRlIGgyIGNvbm5lY3Rpb24gdG8gcmV0cmlldmUgdGhhdCBzZXQuPGJyPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUi PjxzcGFuIGNsYXNzPSIiPk9uIE1vbiwgSnVsIDIwLCAyMDE1IGF0IDI6NDEgUE0sIERhcnNoYWsg VGhha29yZQ0KPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86ZC50aGFrb3JlQGNh YmxlbGFicy5jb20iIHRhcmdldD0iX2JsYW5rIj5kLnRoYWtvcmVAY2FibGVsYWJzLmNvbTwvYT4m Z3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8L3NwYW4+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxf cXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xp ZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxzcGFuIGNsYXNzPSIiPjxicj4NCkl0IHNlZW1zIGxpa2Ug d2UgZG8gd2FudCBzb21lIG1lY2hhbmlzbSB0aGF0IGFsbG93cyBhIGNsaWVudCB0byByZXRyaWV2 ZTxicj4NCm5vdGlmaWNhdGlvbnMgZm9yIGFsbCBzdWJzY3JpcHRpb25zIHdpdGggYSBzaW5nbGUg ZmV0Y2guIEZvciBJb1QgYmFzZWQgdXNlPGJyPg0KY2FzZXMgYWxzbyB0aGlzIGlzIGRlc2lyYWJs ZS4gSSBndWVzcyB0aGlzIGtlZXBzIGdvaW5nIGJhY2sgdG8gdGhlPGJyPg0KYWdncmVnYXRpb24t dnMtZGlzYWdncmVnYXRpb24gZGlzY3Vzc2lvbi4gSG93ZXZlciBJwrltIHdvbmRlcmluZyBpZiBp dHM8YnI+DQpwb3NzaWJsZSB0byBkZWZpbmUvY3JlYXRlIGEgc29ydCBvZiDCs2FnZ3JlZ2F0aW9u LW9uLWRlbWFuZMKyIG1vZGUgd2l0aCB0aGU8YnI+DQpkZWZhdWx0IGJlaW5nIHRoZSBjdXJyZW50 IMKzZGlzYWdncmVnYXRpb27CsiBtb2RlLjxicj4NCjxicj4NCkZvciBleGFtcGxlLCBvbmNlIGEg Y2xpZW50L1VBIGhhcyBzdWJzY3JpYmVkIGZvciB0aGUgZmlyc3QgdGltZSBhbmQgaG9sZHM8YnI+ DQoxIHN1YnNjcmlwdGlvbiwgd2hlbiBpdCB3YW50cyB0byBjcmVhdGUgc3Vic2VxdWVudCBzdWJz Y3JpcHRpb25zLCBpdCBjYW48YnI+DQppbmNsdWRlIHRoZSBmaXJzdCBzdWJzY3JpcHRpb24gaW4g dGhlIHJlcXVlc3Q6PGJyPg0KPGJyPg0KUE9TVCAvc3Vic2NyaWJlLyBIVFRQLzEuMTxicj4NCjwv c3Bhbj5IT1NUOiA8YSBocmVmPSJodHRwOi8vcHVzaC5leGFtcGxlLm5ldCIgcmVsPSJub3JlZmVy cmVyIiB0YXJnZXQ9Il9ibGFuayI+cHVzaC5leGFtcGxlLm5ldDwvYT48c3BhbiBjbGFzcz0iIj48 YnI+DQpMaW5rOiAmbHQ7L3MvTEJoaHcwT29oTy1XbDRPaTk3MVVHc0I3c2RRR1VpYngmZ3Q7Ozxi cj4NCnJlbD3Cs3VybjppZXRmOnBhcmFtczpwdXNoOnN1YmNyaWJlwrIgKEnCuW0gbm90IHN1cmUg aWYgaXRzIG9rIHRvIHVzZSBMaW5rPGJyPg0KaGVhZGVyIGluIGEgcmVxdWVzdCwgaWYgbm90IHdl IG5lZWQgdG8gZmluZCBzb21ldGhpbmcgbW9yZSBzdWl0YWJsZSk8YnI+DQo8YnI+DQpXaGVuIGEg UFMgcHJvY2Vzc2VzIHRoaXMgcmVxdWVzdCwgaXQgY2FuIGFzc29jaWF0ZSB0aGUgbmV3IHN1YnNj cmlwdGlvbjxicj4NCndpdGggdGhlIG9uZSBwcm92aWRlZC4gKEkgdGhpbmsgdGhlIGFkZGl0aW9u YWwgZGF0YSBzdG9yZWQgYnkgdGhlIFBTIHRvPGJyPg0KYWNoaWV2ZSB0aGlzIHNob3VsZCBiZSBt aW5pbWFsKS4gVGhlIHJlc3BvbnNlIHdvdWxkIGNvbnRhaW4gdGhlIG5ldzxicj4NCnN1YnNjcmlw dGlvbiBpbmZvIGFzIGN1cnJlbnRseSBkZWZpbmVkIChhbmQgbWF5YmUgc29tZXRoaW5nIGFkZGl0 aW9uYWwgdG88YnI+DQppbmRpY2F0ZSB0aGF0IHRoZSBuZXcgc3Vic2NyaXB0aW9uIGlzIHRpZWQg dG8gdGhlIG9uZSBpbiB0aGUgcmVxdWVzdCk8YnI+DQo8YnI+DQpXaGVuIHJlY2VpdmluZyBQVVNI IG1lc3NhZ2VzLCBhIGNsaWVudC9VQSBjYW4gbWFrZSBhIHNpbmdsZSBHRVQgcmVxdWVzdCB0bzxi cj4NCnRoZSBwcmltYXJ5IHN1YnNjcmlwdGlvbiByZXNvdXJjZSBhbmQgdGhlIHNlcnZlciB3aWxs IHNlbmQgcHVzaDxicj4NCm5vdGlmaWNhdGlvbnMgZm9yIGFsbCBzdWJzY3JpcHRpb25zIGFzc29j aWF0ZWQgd2l0aCB0aGUgcHJpbWFyeTxicj4NCnN1YnNjcmlwdGlvbi48YnI+DQo8YnI+DQpGb3Ig ZXhhbXBsZSwgdGhlIHJlcXVlc3Qgd291bGQgYmU8YnI+DQo8YnI+DQpIRUFERVJTJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1tzdHJlYW0gN10gJiM0MztFSERfU1RSRUFNICYjNDM7 RU5EX0hFQURFUlM8YnI+DQombmJzcDsgOm1ldGhvZCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw Oz0gR0VUPGJyPg0KJm5ic3A7IDpwYXRoJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw Oz0gL3MvTEJoaHcwT29oTy1XbDRPaTk3MVVHc0I3c2RRR1VpYng8YnI+DQo8L3NwYW4+Jm5ic3A7 IDphdXRob3JpdHkmbmJzcDsgJm5ic3A7ID0gPGEgaHJlZj0iaHR0cDovL3B1c2guZXhhbXBsZS5u ZXQiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPg0KcHVzaC5leGFtcGxlLm5ldDwv YT48c3BhbiBjbGFzcz0iIj48YnI+DQo8YnI+DQpBbmQgdGhlIGNvcnJlc3BvbmRpbmcgcmVzcG9u c2Ugd291bGQgYmU8YnI+DQo8YnI+DQpQVVNIX1BST01JU0UmbmJzcDsgJm5ic3A7IFtzdHJlYW0g NzsgcHJvbWlzZWQgc3RyZWFtIDRdICYjNDM7RU5EX0hFQURFUlM8YnI+DQombmJzcDsgOm1ldGhv ZCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOz0gR0VUPGJyPg0KJm5ic3A7IDpwYXRoJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOz0gL2QvcURJWUhOY2ZBSVBQXzVJVHZVUnItZDZC R3RZblRSbms8YnI+DQo8L3NwYW4+Jm5ic3A7IDphdXRob3JpdHkmbmJzcDsgJm5ic3A7ID0gPGEg aHJlZj0iaHR0cDovL3B1c2guZXhhbXBsZS5uZXQiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJf YmxhbmsiPg0KcHVzaC5leGFtcGxlLm5ldDwvYT48c3BhbiBjbGFzcz0iIj48YnI+DQo8YnI+DQpI RUFERVJTJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1tzdHJlYW0gNF0gJiM0MztF TkRfSEVBREVSUzxicj4NCiZuYnNwOyA6c3RhdHVzJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 PSAyMDA8YnI+DQombmJzcDsg4oC54oC5T1RIRVIgSEVBREVSUyDigLnigLk8YnI+DQombmJzcDsg OmNvbnRlbnQtbG9jJm5ic3A7ID0gL3MvTEJoaHcwT29oTy1XbDRPaTk3MVVHc0I3c2RRR1VpYng8 YnI+DQo8YnI+DQpEQVRBJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg W3N0cmVhbSA0XSAmIzQzO0VORF9TVFJFQU08YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwO2lDaFl1 STNqTXp0M2lyMjBQOHJfamdSUi1kU3VOMTgyeDdpQjxicj4NCjxicj4NCjxicj4NClBVU0hfUFJP TUlTRSZuYnNwOyAmbmJzcDsgW3N0cmVhbSA3OyBwcm9taXNlZCBzdHJlYW0gNl0gJiM0MztFTkRf SEVBREVSUzxicj4NCiZuYnNwOyA6bWV0aG9kJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOz0gR0VUPGJyPg0KJm5ic3A7IDpwYXRoJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs9IC9k L2dqdU5KVFl1WlhreXlsT090amZBRW82a3RSSENBRHVpPGJyPg0KPC9zcGFuPiZuYnNwOyA6YXV0 aG9yaXR5Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPSA8YSBocmVm PSJodHRwOi8vcHVzaC5leGFtcGxlLm5ldCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFu ayI+DQpwdXNoLmV4YW1wbGUubmV0PC9hPjxzcGFuIGNsYXNzPSIiPjxicj4NCjxicj4NCkhFQURF UlMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7W3N0cmVhbSA2XSAmIzQzO0VORF9I RUFERVJTPGJyPg0KJm5ic3A7IDpzdGF0dXMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs9IDIw MDxicj4NCiZuYnNwOyDigLnigLlPVEhFUiBIRUFERVJTIOKAueKAuTxicj4NCiZuYnNwOyA6Y29u dGVudC1sb2MmbmJzcDsgPSAvcy9oSjBqVzFFbENqaGpmd3doNGtUUXc3ckVZSzRReUZGVzxicj4N Cjxicj4NCkRBVEEmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBbc3Ry ZWFtIDZdICYjNDM7RU5EX1NUUkVBTTxicj4NCntlbmNvZGVkL2VuY3J5cHRlZC1ub3RpZmljYXRp b24tbWVzc2FnZX08YnI+DQo8YnI+DQo8YnI+DQrigLnigLkgYWRkaXRpb25hbCBQVVNIIG1lc3Nh Z2VzIGZvciBvdGhlciBzdWJzY3JpcHRpb25zIOKAueKAuTxicj4NCjxicj4NCjxicj4NCjxicj4N CkluIHRoZSBhYm92ZSBleGFtcGxlLCB0aGUgcmVzcG9uc2VzIGNhbiBpbmNsdWRlIGEgQ29udGVu dC1Mb2NhdGlvbiAob3I8YnI+DQpzb21lIG90aGVyIGFwcHJvcHJpYXRlKSBoZWFkZXIgdG8gaW5k aWNhdGUgdGhlIGFzc29jaWF0ZWQgc3Vic2NyaXB0aW9uIGZvcjxicj4NCnRoZSBub3RpZmljYXRp b24gbWVzc2FnZS4gVGhpcyB3b3VsZCBhbGxvdyB0aGUgY2xpZW50L1VBIHRvIHNlbmQganVzdCBv bmU8YnI+DQpHRVQgcmVxdWVzdCB0byByZXRyaWV2ZSAoYW5kIGtlZXAgcmVjZWl2aW5nKSBub3Rp ZmljYXRpb25zIG9uIGFsbCBpdHM8YnI+DQphY3RpdmUgc3Vic2NyaXB0aW9ucy4gQSBjbGllbnQv VUEgbWF5IGV2ZW4gY2hvb3NlIHRvIGtlZXAgY2VydGFpbjxicj4NCnN1YnNjcmlwdGlvbnMgc2Vw YXJhdGUgYW5kIGdyb3VwIG9ubHkgYSBzdWJzZXQgb2YgdGhlbSAodGhpcyB3b3VsZCBiZTxicj4N CnVzZWZ1bCBpbiBJb1QgbGlrZSBjYXNlcyk8YnI+DQo8YnI+DQo8YnI+DQpEYXJzaGFrPGJyPg0K PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KT24gNy8yMC8xNSwgMTA6MzEgQU0sICZxdW90O1dlYnB1 c2ggb24gYmVoYWxmIG9mIE1hcnRpbiBUaG9tc29uJnF1b3Q7PGJyPg0KPC9zcGFuPg0KPGRpdj4N CjxkaXY+Jmx0OzxhIGhyZWY9Im1haWx0bzp3ZWJwdXNoLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj53ZWJwdXNoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IG9uIGJlaGFsZiBvZg0KPGEg aHJlZj0ibWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1h cnRpbi50aG9tc29uQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxzcGFuIGNsYXNzPSIiPjxicj4N Cjxicj4NCiZndDtPbiAyMCBKdWx5IDIwMTUgYXQgMDk6MjEsIEJlbmphbWluIEJhbmdlcnQgJmx0 OzxhIGhyZWY9Im1haWx0bzpiYmFuZ2VydEBtb3ppbGxhLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJi YW5nZXJ0QG1vemlsbGEuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsgV2hhdCdzIHRo ZSB1c2UtY2FzZSBvZiBhIGNsaWVudCBwb2xsaW5nIG92ZXIgYSBsb25nLWxpdmVkIGNvbm5lY3Rp b248YnI+DQomZ3Q7PGJyPg0KJmd0O1RoZSB1c2UgY2FzZSBpcyBmb3IgYSBkZXZpY2UgdGhhdCBp cyBvbmx5IHBlcmlvZGljYWxseSBvbmxpbmUgKGE8YnI+DQomZ3Q7Y29uc3RyYWluZWQgZGV2aWNl KSB0aGF0IHdhbnRzIHRvIGNoZWNrIGluLCB0aGVuIGltbWVkaWF0ZWx5IGdvPGJyPg0KJmd0O29m ZmxpbmUgYWdhaW4uPGJyPg0KJmd0Ozxicj4NCjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KJmd0O19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0O1dl YnB1c2ggbWFpbGluZyBsaXN0PGJyPg0KJmd0OzxhIGhyZWY9Im1haWx0bzpXZWJwdXNoQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+V2VicHVzaEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7PGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby93ZWJwdXNoIiByZWw9Im5v cmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3dlYnB1c2g8L2E+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpXZWJwdXNoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzpXZWJwdXNoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+V2VicHVzaEBpZXRm Lm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3dlYnB1c2giIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vd2VicHVzaDwvYT48YnI+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpXZWJwdXNoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzpXZWJwdXNoQGlldGYub3JnIj5XZWJwdXNoQGlldGYub3JnPC9hPjxicj4NCjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vd2VicHVzaCIgcmVs PSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby93ZWJwdXNoPC9hPjxicj4NCjxicj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_D1D4AD8170E0dthakorecablelabscom_-- From nobody Wed Jul 22 05:53:40 2015 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 A50581B3317 for ; Wed, 22 Jul 2015 05:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Odt5ZU7iOVoZ for ; Wed, 22 Jul 2015 05:53:33 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c: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 90F331B32F4 for ; Wed, 22 Jul 2015 05:53:22 -0700 (PDT) Received: by wicgb10 with SMTP id gb10so96939241wic.1 for ; Wed, 22 Jul 2015 05:53:21 -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=fE03h32OLRr5QYTvWvLfItE3TPfH7JTZgP/GhPyTtMs=; b=GR6XEgv3X7hjsBrWS2ImNEi9XZThwlM92kQYGgts30+Yfd/fmPhsrCfbFQxZ5DDxsC Y33wLLx7yEF0SKAbbxAgdNTZe9OXkQmiqEbvelNaYMfr4Sm1cPVoGyJHzzc2xmPqNkoE 9YnEsCp8u/6+LsWx8T6fSp+XLowgWQZtRH/RSUz95RK/EufzdZC9SA39e2u/DGxXmre+ pdXfuiFoEAKWc2L0bm+9l5EzGk3ahsVdzWnjOhbZ1t02Y/ButqkWWdVJe+UcBNWlsHe1 OSjdmjj3LhS8A8yX39yfbk5UkvwuKvd3Flz5Wb5pUdOCSNIC+X16DcmYVmWlaDYCVrO/ +yxg== 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=fE03h32OLRr5QYTvWvLfItE3TPfH7JTZgP/GhPyTtMs=; b=fa1MBpmujgknhYe7KVykk24Na4ArwEqL2cmRnKJOjo4l7EpmIUW1U78ouHHYNvaqjL IBVKBqrTsl4WAKUtw/TV+r6w2BuhObL0ri1twdlzA1JM+aVb1sUKc6VnvYDclQTQNl9F P0by8s4T593zlwgzQxMYKtSCBkr/MM18O4YINHLIYonQk6g+ebj+4GaGIc+dD1p2/5EL jkIDsTkKVmBzjpXjAoEZJHtdG2oB0s7t5vFUdyfAXIajwx8p3HI9ajvh8TWs+uwws54V 1G4XczHppXZDjDhtVf5NlLUyi4gyV8J8vjhgjtwM2vq4zCRO5T6RcpqQUXkdrQxM40L8 /EmQ== X-Gm-Message-State: ALoCoQkqhHvXyaMhfQUqWQWZz3dz+VZqcOT8bM46lpmSp43J6I0Zul/EzgDy/JccUl7/goUAc7RE MIME-Version: 1.0 X-Received: by 10.181.13.230 with SMTP id fb6mr5964017wid.47.1437569601256; Wed, 22 Jul 2015 05:53:21 -0700 (PDT) Received: by 10.28.68.195 with HTTP; Wed, 22 Jul 2015 05:53:21 -0700 (PDT) Date: Wed, 22 Jul 2015 13:53:21 +0100 Message-ID: From: Peter Beverloo To: "webpush@ietf.org" Content-Type: multipart/alternative; boundary=f46d043c05bc6c7e7a051b76416d Archived-At: Cc: Costin Manolache , Francesco Nerieri Subject: [Webpush] Web Push prototype availability in Google Cloud Messaging and Chrome 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, 22 Jul 2015 12:53:34 -0000 --f46d043c05bc6c7e7a051b76416d Content-Type: text/plain; charset=UTF-8 Hi all - We would like to announce the public availability of two prototypes based on the drafts produced by this working group. An endpoint for Google Cloud Messaging (GCM) is now available that implements support for section 5 of draft-thomson-webpush-protocol-00[1]: Requesting Push Message Delivery. For now, please only use this for purposes of trying out the demos. https://jmt17.google.com/gcm/demo-webpush-00/$SUBSCRIPTIONID$ Chrome is implementing both draft-thomson-webpush-encryption-01[2] and draft-thomson-http-encryption-01[3] for incoming messages using the W3C Push API. It must be noted that the encryption prototype in Chrome uses Curve25519 rather than P-256 as the ECDH curve, and that the GCM endpoint requires an Authorization header. We hope to formalize this header -and its mechanism- in a proposal draft soon. More information, including examples and a demo website, can be found in the following document. https://docs.google.com/document/d/1kDVLMddPJL6iHLJ6QuqNFc1D5X9rASx0PfDd1llxUE4/edit# Costin, Nero and I will be in Prague starting this evening, so please feel free to approach us and ask questions. Thanks, Peter [1] https://tools.ietf.org/html/draft-thomson-webpush-protocol-00 [2] https://tools.ietf.org/html/draft-thomson-webpush-encryption-01 [3] https://tools.ietf.org/html/draft-thomson-http-encryption-01 --f46d043c05bc6c7e7a051b76416d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all -

We would like to an= nounce the public availability of two prototypes based on the drafts produc= ed by this working group.

An endpoint for Google C= loud Messaging (GCM) is now available that implements support for section 5= of draft-thomson-webpush-protocol-00[1]: Requesting Push Message Delivery.= For now, please only use this for purposes of trying out the demos.
<= div>

Chrome is implementing both draft-thomson= -webpush-encryption-01[2] and draft-thomson-http-encryption-01[3] for incom= ing messages using the W3C Push API.

It must be no= ted that the encryption prototype in Chrome uses Curve25519 rather than P-2= 56 as the ECDH curve, and that the GCM endpoint requires an Authorization h= eader. We hope to formalize this header -and its mechanism- in a proposal d= raft soon.

More information, including examples an= d a demo website, can be found in the following document.


Cost= in, Nero and I will be in Prague starting this evening, so please feel free= to approach us and ask questions.

Thanks,
Peter


--f46d043c05bc6c7e7a051b76416d-- From nobody Wed Jul 22 05:56:55 2015 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 8DB701A03C7 for ; Wed, 22 Jul 2015 05:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cx16zsfIRG6j for ; Wed, 22 Jul 2015 05:56:51 -0700 (PDT) Received: from gator4135.hostgator.com (gator4135.hostgator.com [192.185.4.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CF3E1B3031 for ; Wed, 22 Jul 2015 05:56:49 -0700 (PDT) Received: from [31.133.176.145] (port=60344 helo=dhcp-b091.meeting.ietf.org) by gator4135.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.85) (envelope-from ) id 1ZHtZo-0001K4-PZ for webpush@ietf.org; Wed, 22 Jul 2015 07:56:48 -0500 From: Shida Schubert Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9ED85FB6-1B1D-4D2D-8FC6-6E738AC66334@ntt-at.com> Date: Wed, 22 Jul 2015 14:56:45 +0200 To: webpush@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) 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: 31.133.176.145 X-Exim-ID: 1ZHtZo-0001K4-PZ X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (dhcp-b091.meeting.ietf.org) [31.133.176.145]:60344 X-Source-Auth: shida@agnada.com X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== Archived-At: Subject: [Webpush] Please send in the slides for Webpush session tomorrow!! 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, 22 Jul 2015 12:56:53 -0000 To those that will be presenting tomorrow, please send in your slides by = 5pm today as requested on Monday.=20 For those that will be presenting their drafts for the first time, = please focus on the issues that the draft is trying to address.=20 Many Thanks!=20 Shida as co-chair= From nobody Wed Jul 22 06:16:52 2015 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 1C6191B3364 for ; Wed, 22 Jul 2015 06:16:43 -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 9JBM8A-ZdS4L for ; Wed, 22 Jul 2015 06:16:41 -0700 (PDT) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::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 DD9D41A1B43 for ; Wed, 22 Jul 2015 06:16:40 -0700 (PDT) Received: by ykfw194 with SMTP id w194so111825531ykf.0 for ; Wed, 22 Jul 2015 06:16:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vIo88Fgj3JHihY9os7qI+AC603ylk1yIxRVINR+Gquo=; b=NKqnzOCuiR6ZpTZ1+7hSNJaaYXuNCeIoSDRSAf/NSNfBA96lcOp9zATCMpG3hCrPdz 4eEZsxcCWpg+aYDvlq41QLDpcv2g9he80hE2Y/8opmPlA8HiSgAQbwW5/Tq4dJBpzTKD LzqKtpY+l72enWtFhF0e+TVUblSbx1tWZLz7CmA6G+P/FeuXDgMPfNCCt7bR1D07EtmF r5My4uYOuIXCJI4ZkIQPTZ0FN1C/Ui1MRYFmbl8UZdVr6fHfDiBNOhR1grY9ugFRRMH0 a5VQ33A1TGn7FQEsfFz0sXEMbwvWcU0rs4evVS97xtD5U+kPxeAZqC/5I088xfDvwS2f gKlA== MIME-Version: 1.0 X-Received: by 10.170.57.207 with SMTP id 198mr2366018ykz.118.1437571000281; Wed, 22 Jul 2015 06:16:40 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Wed, 22 Jul 2015 06:16:40 -0700 (PDT) In-Reply-To: References: Date: Wed, 22 Jul 2015 06:16:40 -0700 Message-ID: From: Martin Thomson To: Peter Beverloo Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Costin Manolache , Francesco Nerieri , "webpush@ietf.org" Subject: Re: [Webpush] Web Push prototype availability in Google Cloud Messaging and Chrome 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, 22 Jul 2015 13:16:43 -0000 Thanks Peter. We are at a similar stage with Firefox. Though we've implemented P-256. I look forward to more discussion on curve choice :) On 22 July 2015 at 05:53, Peter Beverloo wrote: > Hi all - > > We would like to announce the public availability of two prototypes based on > the drafts produced by this working group. > > An endpoint for Google Cloud Messaging (GCM) is now available that > implements support for section 5 of draft-thomson-webpush-protocol-00[1]: > Requesting Push Message Delivery. For now, please only use this for purposes > of trying out the demos. > > https://jmt17.google.com/gcm/demo-webpush-00/$SUBSCRIPTIONID$ > > Chrome is implementing both draft-thomson-webpush-encryption-01[2] and > draft-thomson-http-encryption-01[3] for incoming messages using the W3C Push > API. > > It must be noted that the encryption prototype in Chrome uses Curve25519 > rather than P-256 as the ECDH curve, and that the GCM endpoint requires an > Authorization header. We hope to formalize this header -and its mechanism- > in a proposal draft soon. > > More information, including examples and a demo website, can be found in the > following document. > > https://docs.google.com/document/d/1kDVLMddPJL6iHLJ6QuqNFc1D5X9rASx0PfDd1llxUE4/edit# > > Costin, Nero and I will be in Prague starting this evening, so please feel > free to approach us and ask questions. > > Thanks, > Peter > > [1] https://tools.ietf.org/html/draft-thomson-webpush-protocol-00 > [2] https://tools.ietf.org/html/draft-thomson-webpush-encryption-01 > [3] https://tools.ietf.org/html/draft-thomson-http-encryption-01 > > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > From nobody Wed Jul 22 08:27:57 2015 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 A3DA61A004A for ; Wed, 22 Jul 2015 08:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VDbyfMNRdsF for ; Wed, 22 Jul 2015 08:27:53 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c: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 A16E41A0100 for ; Wed, 22 Jul 2015 08:27:52 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so168696906wib.0 for ; Wed, 22 Jul 2015 08:27:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a1trzaQqRszG9Pl/zfRUw9gjdZFQhUWC3i45FyKDT9o=; b=WxAPt+1BtJ098SL+T+EyrbjyKuBSMcgzD0ufT0mISBQZUbdNxsHsl79RbWCxaJUppZ qv5yw9xZ9CquYGGy3CDwk8iUBi9+4nlyTU1h5634eJHg1/hsf1YtoJvB+WY/ba2FUmzR ZbO3whvX3OVGhGuFNVluAXEK4Xa3pu0EvP0ZIkSkdSOXhk8HWpgzGmN/xM+uBPL4RA+u 853mphtnzjKc6F4GbKFuECWAXISwIdHlx8W5wfhOT4xsAdYiA40bfXNQsN5+k7dYByho xWfHRFkUhf0xMzbN3gMeZRaO0/leRo+NOhdaSJ2M5hEKK5PK0IBGxP4a7onJQEZD7eJf I1gw== MIME-Version: 1.0 X-Received: by 10.194.187.170 with SMTP id ft10mr6235178wjc.26.1437578871390; Wed, 22 Jul 2015 08:27:51 -0700 (PDT) Received: by 10.36.9.207 with HTTP; Wed, 22 Jul 2015 08:27:50 -0700 (PDT) In-Reply-To: References: Date: Wed, 22 Jul 2015 08:27:50 -0700 Message-ID: From: Costin Manolache To: Darshak Thakore Content-Type: multipart/alternative; boundary=047d7bb03a92f74a45051b78692d Archived-At: Cc: Benjamin Bangert , "webpush@ietf.org" Subject: Re: [Webpush] comments on latest draft-thomson-webpush-protocol-00 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, 22 Jul 2015 15:27:56 -0000 --047d7bb03a92f74a45051b78692d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 22, 2015 at 1:25 AM, Darshak Thakore wrote: > Comments below > > On 7/21/15, 6:48 PM, "Costin Manolache" wrote: > > I think one question is who makes the decision if subscrptions are > 'aggregated' or not. And the only answer > I know is the push provider - since the push provider is the one bearing > the costs and defining the > requirements for UAs that connect to it. > > > DT>> As I mentioned in the other email (Benjamin=E2=80=99s email), I=E2= =80=99m not sure > how a PS can force a UA to aggregate (unless the PS somehow identifies th= e > client based on authentication/cookie/something-else). > In aggregate model, there is a registration (or subscription) for the UA, and each origin/serviceworker have a subscription associated with the UA. The PS can simply reject subscriptions that don't have an associated parent, and not deliver the the registration/root. Than the UA may chose a different PS, or aggregate. Or: terms of service and abuse detection on PS. There was a thread about PS returning a URL that may require additional user interaction when the UA registers with the PS, and may have separate relation ( like Setup Wizard in android ). For example GCM attempts to determine device type, if it is rooted, etc. I don't think the expectation is that a PS MUST accept arbitrary UAs, free and without any checks or rules. > I think the PS should/must support it but it would be the client/UA=E2=80= =99s > decision to aggregate. We can put language to =E2=80=9Cstrongly recommend= =E2=80=9D the > client/UA to aggregate but it would still be the client=E2=80=99s decisio= n to > include the initial subscription when making subsequent subscription > requests. > > > If we agree that a push provider may require 'aggregation' - all > subscriptions from a device, when connecting > to such a provider, will need to have something in common, to allow the > aggregation. The original > "registration + subscription" does it by having a first step where a > device gets the common element. > It can be simplified by defining the 'registration' as a regular > subscription, and allowing each app to > have a 'child' subscription. This works nicely if a UA supports > profiles/multi-user for example - and may > be extended later for more complicated cases, where a UA acts as a proxy > for other UAs ( for example > a wearable device paired over BT ). > > > DT>> I think within the context of the fact that a client does want to > =E2=80=9Caggregate=E2=80=9D, all of the above is doable. However as I men= tioned above, if a > client does not send the =E2=80=9Cparent subscription=E2=80=9D info in th= e subsequent > subscription requests, there=E2=80=99s no easy way for a PS to force aggr= egation. > I wouldn't be very worried about a small percentage of devices not aggregating - and anything large is usually detectable. Costin > > The subscription API should allow a way to create 'links' between > subscriptions. We do need to > finish the separate discussion on sender authentication and registration = - > but assuming a push service > requires sender authentication, this is another 'link' between the app > subscription and the server id ( > which can be another capability URL or subscription ). > > > DT>> Yes, I believe that should be doable with the idea here. > > > I don't think it's a problem if the 'non-aggregated' model - where > nothing is shared - is defined even as default, > and some push providers may chose to support both, or only one model, > depending on their scale and costs > > > Costin > > On Tue, Jul 21, 2015 at 9:26 AM, Benjamin Bangert > wrote: > >> My preference would be for the server to be able to require this, >> rather than leaving it up to the client. If a server doesn't want to exp= end >> the heavy resource cost of treating every single subscription as its own >> URL, there should be a way for the server to indicate that in its >> subscription response. >> >> For an IoT use-case, where a client might want different sets of >> subscriptions entirely, and to only check one group of them, it could op= en >> a separate h2 connection to retrieve that set. >> >> On Mon, Jul 20, 2015 at 2:41 PM, Darshak Thakore > > wrote: >> >>> >>> It seems like we do want some mechanism that allows a client to retriev= e >>> notifications for all subscriptions with a single fetch. For IoT based >>> use >>> cases also this is desirable. I guess this keeps going back to the >>> aggregation-vs-disaggregation discussion. However I=C2=B9m wondering if= its >>> possible to define/create a sort of =C2=B3aggregation-on-demand=C2=B2 m= ode with the >>> default being the current =C2=B3disaggregation=C2=B2 mode. >>> >>> For example, once a client/UA has subscribed for the first time and hol= ds >>> 1 subscription, when it wants to create subsequent subscriptions, it ca= n >>> include the first subscription in the request: >>> >>> POST /subscribe/ HTTP/1.1 >>> HOST: push.example.net >>> Link: ; >>> rel=3D=C2=B3urn:ietf:params:push:subcribe=C2=B2 (I=C2=B9m not sure if i= ts ok to use Link >>> header in a request, if not we need to find something more suitable) >>> >>> When a PS processes this request, it can associate the new subscription >>> with the one provided. (I think the additional data stored by the PS to >>> achieve this should be minimal). The response would contain the new >>> subscription info as currently defined (and maybe something additional = to >>> indicate that the new subscription is tied to the one in the request) >>> >>> When receiving PUSH messages, a client/UA can make a single GET request >>> to >>> the primary subscription resource and the server will send push >>> notifications for all subscriptions associated with the primary >>> subscription. >>> >>> For example, the request would be >>> >>> HEADERS [stream 7] +EHD_STREAM +END_HEADERS >>> :method =3D GET >>> :path =3D /s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx >>> :authority =3D push.example.net >>> >>> And the corresponding response would be >>> >>> PUSH_PROMISE [stream 7; promised stream 4] +END_HEADERS >>> :method =3D GET >>> :path =3D /d/qDIYHNcfAIPP_5ITvURr-d6BGtYnTRnk >>> :authority =3D push.example.net >>> >>> HEADERS [stream 4] +END_HEADERS >>> :status =3D 200 >>> =E2=80=B9=E2=80=B9OTHER HEADERS =E2=80=B9=E2=80=B9 >>> :content-loc =3D /s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx >>> >>> DATA [stream 4] +END_STREAM >>> iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB >>> >>> >>> PUSH_PROMISE [stream 7; promised stream 6] +END_HEADERS >>> :method =3D GET >>> :path =3D /d/gjuNJTYuZXkyylOOtjfAEo6ktRHCADui >>> :authority =3D push.example.net >>> >>> HEADERS [stream 6] +END_HEADERS >>> :status =3D 200 >>> =E2=80=B9=E2=80=B9OTHER HEADERS =E2=80=B9=E2=80=B9 >>> :content-loc =3D /s/hJ0jW1ElCjhjfwwh4kTQw7rEYK4QyFFW >>> >>> DATA [stream 6] +END_STREAM >>> {encoded/encrypted-notification-message} >>> >>> >>> =E2=80=B9=E2=80=B9 additional PUSH messages for other subscriptions =E2= =80=B9=E2=80=B9 >>> >>> >>> >>> In the above example, the responses can include a Content-Location (or >>> some other appropriate) header to indicate the associated subscription >>> for >>> the notification message. This would allow the client/UA to send just o= ne >>> GET request to retrieve (and keep receiving) notifications on all its >>> active subscriptions. A client/UA may even choose to keep certain >>> subscriptions separate and group only a subset of them (this would be >>> useful in IoT like cases) >>> >>> >>> Darshak >>> >>> >>> >>> >>> On 7/20/15, 10:31 AM, "Webpush on behalf of Martin Thomson" >>> wrote= : >>> >>> >On 20 July 2015 at 09:21, Benjamin Bangert >>> wrote: >>> >> What's the use-case of a client polling over a long-lived connection >>> > >>> >The use case is for a device that is only periodically online (a >>> >constrained device) that wants to check in, then immediately go >>> >offline again. >>> > >>> >_______________________________________________ >>> >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 >> >> > --047d7bb03a92f74a45051b78692d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jul 22, 2015 at 1:25 AM, Darshak Thakore <= d.thakore@cabl= elabs.com> wrote:
Comments below

On 7/21/15, 6:48 PM, "Costin Manolache" <costin@gmail.com> wrote:

I think one question is who makes the decision if subscrpt= ions are 'aggregated' or not. And the only answer=C2=A0
I know is the push provider - since the push provider is the one beari= ng the costs and defining the=C2=A0
requirements for UAs that connect to it.=C2=A0

DT>> As I mentioned in the other email (Benjamin=E2=80=99= s email), I=E2=80=99m not sure how a PS can force a UA to aggregate (unless= the PS somehow identifies the client based on authentication/cookie/someth= ing-else).

In aggregate model,= there is a registration (or subscription) for the UA, and each origin/serv= iceworker have a subscription associated with the UA.=C2=A0

<= /div>
The PS can simply reject subscriptions that don't have an ass= ociated parent, and not deliver the the registration/root. Than the UA
may chose a different PS, or aggregate.

Or: = terms of service and abuse detection on PS.=C2=A0

= There was a thread about PS returning a URL that may require additional use= r interaction when the UA registers with the PS,
and may have sep= arate relation ( like Setup Wizard in android ). For example GCM attempts t= o determine device type, if it is rooted, etc.=C2=A0

I don't think the expectation is that a PS MUST accept arbitrary UAs= , free and without any checks or rules.

=C2=A0
I think the P= S should/must support it but it would be the client/UA=E2=80=99s decision to aggregate. We can put language to = =E2=80=9Cstrongly recommend=E2=80=9D the client/UA to aggregate but it woul= d still be the client=E2=80=99s decision to include the initial subscriptio= n when making subsequent subscription requests.


If we agree that a push provider may require 'aggregation' - a= ll subscriptions from a device, when connecting
to such a provider, will need to have something in common, to allow th= e aggregation. The original
=C2=A0"registration + subscription" does it by having a firs= t step where a device gets the common element.=C2=A0
It can be simplified by defining the 'registration' as a regul= ar subscription, and allowing each app to
=C2=A0have a 'child' subscription. This works nicely if a UA s= upports profiles/multi-user for example - and may=C2=A0
be extended later for more complicated cases, where a UA acts as a pro= xy for other UAs ( for example=C2=A0
a wearable device paired over BT ).=C2=A0

DT>> I think within the context of the fact that a client= does want to =E2=80=9Caggregate=E2=80=9D, all of the above is doable. Howe= ver as I mentioned above, if a client does not send the =E2=80=9Cparent sub= scription=E2=80=9D info in the subsequent subscription requests, there=E2= =80=99s no easy way for a PS to force aggregation.=C2=A0

=
I wouldn't be very worried about a small percentage of devic= es not aggregating - and anything large is usually detectable.

Costin
=C2=A0

The subscription API should allow a way to create 'links' betw= een subscriptions. We do need to=C2=A0
finish the separate discussion on sender authentication and registrati= on - but assuming a push service
requires sender authentication, this is another 'link' between= the app subscription and the server id (
which can be another capability URL or subscription ).=C2=A0

DT>> Yes, I believe that should be doable with the idea h= ere.=C2=A0


I don't think it's a problem if the 'non-aggregated' m= odel - where nothing is shared - is defined even as default,
and some push providers may chose to support both, or only one model, = depending on their scale and costs

Costin

On Tue, Jul 21, 2015 at 9:26 AM, Benjamin Banger= t <bbangert@mozi= lla.com> wrote:
My preference would be for the server to be able to require this, rath= er than leaving it up to the client. If a server doesn't want to expend= the heavy resource cost of treating every single subscription as its own U= RL, there should be a way for the server to indicate that in its subscription response.

For an IoT use-case, where a client might want different sets of subscripti= ons entirely, and to only check one group of them, it could open a separate= h2 connection to retrieve that set.

On Mon, Jul 20, 2015 at 2:41 PM, Darshak T= hakore <d.thakore@cablelabs.com> wrote:

It seems like we do want some mechanism that allows a client to retrieve notifications for all subscriptions with a single fetch. For IoT based use<= br> cases also this is desirable. I guess this keeps going back to the
aggregation-vs-disaggregation discussion. However I=C2=B9m wondering if its=
possible to define/create a sort of =C2=B3aggregation-on-demand=C2=B2 mode = with the
default being the current =C2=B3disaggregation=C2=B2 mode.

For example, once a client/UA has subscribed for the first time and holds 1 subscription, when it wants to create subsequent subscriptions, it can include the first subscription in the request:

POST /subscribe/ HTTP/1.1
HOST: push.example.net
Link: </s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx>;
rel=3D=C2=B3urn:ietf:params:push:subcribe=C2=B2 (I=C2=B9m not sure if its o= k to use Link
header in a request, if not we need to find something more suitable)

When a PS processes this request, it can associate the new subscription
with the one provided. (I think the additional data stored by the PS to
achieve this should be minimal). The response would contain the new
subscription info as currently defined (and maybe something additional to indicate that the new subscription is tied to the one in the request)

When receiving PUSH messages, a client/UA can make a single GET request to<= br> the primary subscription resource and the server will send push
notifications for all subscriptions associated with the primary
subscription.

For example, the request would be

HEADERS=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[stream 7] +EHD_STREAM +END_HEADER= S
=C2=A0 :method=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D GET
=C2=A0 :path=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D /s/LBhhw0OohO-Wl4Oi971UGs= B7sdQGUibx
=C2=A0 :authority=C2=A0 =C2=A0 =3D push.example.net

And the corresponding response would be

PUSH_PROMISE=C2=A0 =C2=A0 [stream 7; promised stream 4] +END_HEADERS
=C2=A0 :method=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D GET
=C2=A0 :path=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D /d/qDIYHNcfAIPP_5ITvURr-d= 6BGtYnTRnk
=C2=A0 :authority=C2=A0 =C2=A0 =3D push.example.net

HEADERS=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[stream 4] +END_HEADERS
=C2=A0 :status=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D 200
=C2=A0 =E2=80=B9=E2=80=B9OTHER HEADERS =E2=80=B9=E2=80=B9
=C2=A0 :content-loc=C2=A0 =3D /s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx

DATA=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [stream 4] +END_STREAM
=C2=A0 =C2=A0 =C2=A0iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB


PUSH_PROMISE=C2=A0 =C2=A0 [stream 7; promised stream 6] +END_HEADERS
=C2=A0 :method=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D GE= T
=C2=A0 :path=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =3D /d/gjuNJTYuZXkyylOOtjfAEo6ktRHCADui
=C2=A0 :authority=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D push.example.net

HEADERS=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[stream 6] +END_HEADERS
=C2=A0 :status=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D 200
=C2=A0 =E2=80=B9=E2=80=B9OTHER HEADERS =E2=80=B9=E2=80=B9
=C2=A0 :content-loc=C2=A0 =3D /s/hJ0jW1ElCjhjfwwh4kTQw7rEYK4QyFFW

DATA=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [stream 6] +END_STREAM
{encoded/encrypted-notification-message}


=E2=80=B9=E2=80=B9 additional PUSH messages for other subscriptions =E2=80= =B9=E2=80=B9



In the above example, the responses can include a Content-Location (or
some other appropriate) header to indicate the associated subscription for<= br> the notification message. This would allow the client/UA to send just one GET request to retrieve (and keep receiving) notifications on all its
active subscriptions. A client/UA may even choose to keep certain
subscriptions separate and group only a subset of them (this would be
useful in IoT like cases)


Darshak




On 7/20/15, 10:31 AM, "Webpush on behalf of Martin Thomson"
<webp= ush-bounces@ietf.org on behalf of martin.thomso= n@gmail.com> wrote:

>On 20 July 2015 at 09:21, Benjamin Bangert <bbangert@mozilla.com> wrote:
>> What's the use-case of a client polling over a long-lived conn= ection
>
>The use case is for a device that is only periodically online (a
>constrained device) that wants to check in, then immediately go
>offline again.
>
>_______________________________________________
>Webpush mailing list
>Webpush@ietf.org<= /a>
>https://www.ietf.org/mailman/listinfo/webpush
_______________________________________________
Webpush mailing list
Webpush@ietf.org<= br> https://www.ietf.org/mailman/listinfo/webpush


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

--047d7bb03a92f74a45051b78692d-- From nobody Wed Jul 22 09:31:21 2015 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 7A1291A8A4E for ; Wed, 22 Jul 2015 09:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 axVBGbAE2d-T for ; Wed, 22 Jul 2015 09:31:04 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (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 A9DAD1A0358 for ; Wed, 22 Jul 2015 09:30:58 -0700 (PDT) Received: by wibud3 with SMTP id ud3so180845587wib.0 for ; Wed, 22 Jul 2015 09:30:57 -0700 (PDT) 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=4KQGS3ovnk9bgDMs+nNRnQxz/kzL//qUyPUwojFHGVA=; b=hbfkccHP4Yd7yk0Bio05BAohLztw8eJVjr7YaXVLnctX6dzGCHeVseczrlllI15laF 3NtBT06beL8+Zifi9166zI8AuTwBOircsC3V+NIFs6pZ6XRuTSc2xZ1+JKeaDFoWJuDU 3S8BmLJZNwM7eN7CcqpSSfTVi9G2duZFQppEYBeglcL83o9p8+hWbR/O9f/jqYDZXaYu gQAYXWQOt85SrBKUdSdGOcPrSy5Zgdn6RLe6l/3PpUiJIz4zMaIZ0y/SFAQE4fURRJtV NoJJXYeoMUoWeodP7Ig9CUro7wHfYYOsMB+pSukIj7ot5EhmGxLYHbrsZeYdM6Ukq/Jy Drnw== X-Gm-Message-State: ALoCoQlP6T+efza/2eThDSvGCX0pM9caAQAFrw+uR1f81fwld5wyqwIUJ0TbRvCgv8QOm/2Fa991 MIME-Version: 1.0 X-Received: by 10.180.211.49 with SMTP id mz17mr8204444wic.69.1437582657354; Wed, 22 Jul 2015 09:30:57 -0700 (PDT) Received: by 10.27.33.81 with HTTP; Wed, 22 Jul 2015 09:30:57 -0700 (PDT) In-Reply-To: References: Date: Wed, 22 Jul 2015 09:30:57 -0700 Message-ID: From: Benjamin Bangert To: Costin Manolache Content-Type: multipart/alternative; boundary=001a11c25f8ca0a463051b794bb5 Archived-At: Cc: Darshak Thakore , "webpush@ietf.org" Subject: Re: [Webpush] comments on latest draft-thomson-webpush-protocol-00 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, 22 Jul 2015 16:31:15 -0000 --001a11c25f8ca0a463051b794bb5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 22, 2015 at 8:27 AM, Costin Manolache wrote: > > > On Wed, Jul 22, 2015 at 1:25 AM, Darshak Thakore > wrote: > >> Comments below >> >> On 7/21/15, 6:48 PM, "Costin Manolache" wrote: >> >> I think one question is who makes the decision if subscrptions are >> 'aggregated' or not. And the only answer >> I know is the push provider - since the push provider is the one bearing >> the costs and defining the >> requirements for UAs that connect to it. >> >> >> DT>> As I mentioned in the other email (Benjamin=E2=80=99s email), I=E2= =80=99m not sure >> how a PS can force a UA to aggregate (unless the PS somehow identifies t= he >> client based on authentication/cookie/something-else). >> > > In aggregate model, there is a registration (or subscription) for the UA, > and each origin/serviceworker have a subscription associated with the UA. > > The PS can simply reject subscriptions that don't have an associated > parent, and not deliver the the registration/root. Than the UA > may chose a different PS, or aggregate. > > Or: terms of service and abuse detection on PS. > > There was a thread about PS returning a URL that may require additional > user interaction when the UA registers with the PS, > and may have separate relation ( like Setup Wizard in android ). For > example GCM attempts to determine device type, if it is rooted, etc. > > I don't think the expectation is that a PS MUST accept arbitrary UAs, fre= e > and without any checks or rules. > I'm associating one h2 connection as being one UA, and treating the first Subscribe operation, or the first Receive Push Messages operation as the registration. Also, I am perhaps misreading the spec in which URL is given out to whom, now that I think about it. In Sec 3, the Subscribe response is such: HTTP/1.1 201 Created Date: Thu, 11 Dec 2014 23:56:52 GMT Link:

; rel=3D"urn:ietf:params:push" Link: ; rel=3D"urn:ietf:params:push:receipt" Location: https://push.example.net/s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx Cache-Control: max-age:864000, private My thought was that the Location link is the one given to the AppServers, and the urn:ietf:params:push link is the 'private URL' that the UA uses to receive push messages. This way, after the initial Subscribe, the PS has associated that h2 connection with the private URL, and new Subscribe requests will return new Location links to give to the AppServer. It also means the UA would need to store the Location for each Subscribe, since the private URL would be unchanging for all later Subscribe requests. On reconnect, receiving push messages by hitting the private URL would then associate the h2 connection again, acting as the registration. If a UA wants to operate independent batches of subscriptions, as the IoT use-case previously cited, it must use entirely separate h2 connections for each batch. The spec includes a Location without identifying its actual use, as my reading of it seems unclear on if the Link is the one given to the AppServer, or if its the Location. This presumes that there is no h2 proxying such that individual requests over the same connection might be on behalf of different UA's. (I really really don't like the thought of an h2 proxy of this nature, because it means it could lie about whether a client is still actually 'alive' to ping frames, and that's given us enough grief with mobile TCP proxies). In this manner, the PS could choose whether to give the same private URL back for all Subscribe requests over the same connection, or not. The additional requirements on the UA: - It must store the Location, since that's the guaranteed unique part - If it gets the same private URL back, it should only use the Receive operation once, and realize all new push messages will come over the existing GET - On reconnect, it MUST send the Receive operation before any new Subscribe operations (since that's treated as 'registration' on reconnect) This way a PS gets to choose, and the associating link is the push link itself. If the thought was that the push Link is the one sent to AppServers, then some of this will need a bit of changing of course. > > >> I think the PS should/must support it but it would be the client/UA=E2= =80=99s >> decision to aggregate. We can put language to =E2=80=9Cstrongly recommen= d=E2=80=9D the >> client/UA to aggregate but it would still be the client=E2=80=99s decisi= on to >> include the initial subscription when making subsequent subscription >> requests. >> > >> >> If we agree that a push provider may require 'aggregation' - all >> subscriptions from a device, when connecting >> to such a provider, will need to have something in common, to allow the >> aggregation. The original >> "registration + subscription" does it by having a first step where a >> device gets the common element. >> It can be simplified by defining the 'registration' as a regular >> subscription, and allowing each app to >> have a 'child' subscription. This works nicely if a UA supports >> profiles/multi-user for example - and may >> be extended later for more complicated cases, where a UA acts as a proxy >> for other UAs ( for example >> a wearable device paired over BT ). >> >> >> DT>> I think within the context of the fact that a client does want to >> =E2=80=9Caggregate=E2=80=9D, all of the above is doable. However as I me= ntioned above, if a >> client does not send the =E2=80=9Cparent subscription=E2=80=9D info in t= he subsequent >> subscription requests, there=E2=80=99s no easy way for a PS to force agg= regation. >> > > I wouldn't be very worried about a small percentage of devices not > aggregating - and anything large is usually detectable. > > > Costin > > >> >> The subscription API should allow a way to create 'links' between >> subscriptions. We do need to >> finish the separate discussion on sender authentication and registration >> - but assuming a push service >> requires sender authentication, this is another 'link' between the app >> subscription and the server id ( >> which can be another capability URL or subscription ). >> >> >> DT>> Yes, I believe that should be doable with the idea here. >> >> >> I don't think it's a problem if the 'non-aggregated' model - where >> nothing is shared - is defined even as default, >> and some push providers may chose to support both, or only one model, >> depending on their scale and costs >> >> >> Costin >> >> On Tue, Jul 21, 2015 at 9:26 AM, Benjamin Bangert >> wrote: >> >>> My preference would be for the server to be able to require this, >>> rather than leaving it up to the client. If a server doesn't want to ex= pend >>> the heavy resource cost of treating every single subscription as its ow= n >>> URL, there should be a way for the server to indicate that in its >>> subscription response. >>> >>> For an IoT use-case, where a client might want different sets of >>> subscriptions entirely, and to only check one group of them, it could o= pen >>> a separate h2 connection to retrieve that set. >>> >>> On Mon, Jul 20, 2015 at 2:41 PM, Darshak Thakore < >>> d.thakore@cablelabs.com> wrote: >>> >>>> >>>> It seems like we do want some mechanism that allows a client to retrie= ve >>>> notifications for all subscriptions with a single fetch. For IoT based >>>> use >>>> cases also this is desirable. I guess this keeps going back to the >>>> aggregation-vs-disaggregation discussion. However I=C2=B9m wondering i= f its >>>> possible to define/create a sort of =C2=B3aggregation-on-demand=C2=B2 = mode with >>>> the >>>> default being the current =C2=B3disaggregation=C2=B2 mode. >>>> >>>> For example, once a client/UA has subscribed for the first time and >>>> holds >>>> 1 subscription, when it wants to create subsequent subscriptions, it c= an >>>> include the first subscription in the request: >>>> >>>> POST /subscribe/ HTTP/1.1 >>>> HOST: push.example.net >>>> Link: ; >>>> rel=3D=C2=B3urn:ietf:params:push:subcribe=C2=B2 (I=C2=B9m not sure if = its ok to use Link >>>> header in a request, if not we need to find something more suitable) >>>> >>>> When a PS processes this request, it can associate the new subscriptio= n >>>> with the one provided. (I think the additional data stored by the PS t= o >>>> achieve this should be minimal). The response would contain the new >>>> subscription info as currently defined (and maybe something additional >>>> to >>>> indicate that the new subscription is tied to the one in the request) >>>> >>>> When receiving PUSH messages, a client/UA can make a single GET reques= t >>>> to >>>> the primary subscription resource and the server will send push >>>> notifications for all subscriptions associated with the primary >>>> subscription. >>>> >>>> For example, the request would be >>>> >>>> HEADERS [stream 7] +EHD_STREAM +END_HEADERS >>>> :method =3D GET >>>> :path =3D /s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx >>>> :authority =3D push.example.net >>>> >>>> And the corresponding response would be >>>> >>>> PUSH_PROMISE [stream 7; promised stream 4] +END_HEADERS >>>> :method =3D GET >>>> :path =3D /d/qDIYHNcfAIPP_5ITvURr-d6BGtYnTRnk >>>> :authority =3D push.example.net >>>> >>>> HEADERS [stream 4] +END_HEADERS >>>> :status =3D 200 >>>> =E2=80=B9=E2=80=B9OTHER HEADERS =E2=80=B9=E2=80=B9 >>>> :content-loc =3D /s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx >>>> >>>> DATA [stream 4] +END_STREAM >>>> iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB >>>> >>>> >>>> PUSH_PROMISE [stream 7; promised stream 6] +END_HEADERS >>>> :method =3D GET >>>> :path =3D /d/gjuNJTYuZXkyylOOtjfAEo6ktRHCADui >>>> :authority =3D push.example.net >>>> >>>> HEADERS [stream 6] +END_HEADERS >>>> :status =3D 200 >>>> =E2=80=B9=E2=80=B9OTHER HEADERS =E2=80=B9=E2=80=B9 >>>> :content-loc =3D /s/hJ0jW1ElCjhjfwwh4kTQw7rEYK4QyFFW >>>> >>>> DATA [stream 6] +END_STREAM >>>> {encoded/encrypted-notification-message} >>>> >>>> >>>> =E2=80=B9=E2=80=B9 additional PUSH messages for other subscriptions = =E2=80=B9=E2=80=B9 >>>> >>>> >>>> >>>> In the above example, the responses can include a Content-Location (or >>>> some other appropriate) header to indicate the associated subscription >>>> for >>>> the notification message. This would allow the client/UA to send just >>>> one >>>> GET request to retrieve (and keep receiving) notifications on all its >>>> active subscriptions. A client/UA may even choose to keep certain >>>> subscriptions separate and group only a subset of them (this would be >>>> useful in IoT like cases) >>>> >>>> >>>> Darshak >>>> >>>> >>>> >>>> >>>> On 7/20/15, 10:31 AM, "Webpush on behalf of Martin Thomson" >>>> >>>> wrote: >>>> >>>> >On 20 July 2015 at 09:21, Benjamin Bangert >>>> wrote: >>>> >> What's the use-case of a client polling over a long-lived connectio= n >>>> > >>>> >The use case is for a device that is only periodically online (a >>>> >constrained device) that wants to check in, then immediately go >>>> >offline again. >>>> > >>>> >_______________________________________________ >>>> >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 >>> >>> >> > --001a11c25f8ca0a463051b794bb5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 22, 2015 at 8:27 AM, Costin Manolache <costin@gmail.com> wrote:


On Wed, Jul 22, 2015 at 1:25 AM, Darshak Thakore <d.thakor= e@cablelabs.com> wrote:
Comments below

On 7/21/15, 6:48 PM, "Costin Manolache" <costin@gmail.com> wrote:

I think one question is who makes the decision if subscrpt= ions are 'aggregated' or not. And the only answer=C2=A0
I know is the push provider - since the push provider is the one beari= ng the costs and defining the=C2=A0
requirements for UAs that connect to it.=C2=A0

DT>> As I mentioned in the other email (Benjamin=E2=80=99= s email), I=E2=80=99m not sure how a PS can force a UA to aggregate (unless= the PS somehow identifies the client based on authentication/cookie/someth= ing-else).

In aggregate= model, there is a registration (or subscription) for the UA, and each orig= in/serviceworker have a subscription associated with the UA.=C2=A0

The PS can simply reject subscriptions that don't have= an associated parent, and not deliver the the registration/root. Than the = UA
may chose a different PS, or aggregate.

Or: terms of service and abuse detection on PS.=C2=A0

There was a thread about PS returning a URL that may require additio= nal user interaction when the UA registers with the PS,
and may h= ave separate relation ( like Setup Wizard in android ). For example GCM att= empts to determine device type, if it is rooted, etc.=C2=A0

<= /div>
I don't think the expectation is that a PS MUST accept arbitr= ary UAs, free and without any checks or rules.

I'm associating one h2 connection as being = one UA, and treating the first Subscribe operation, or the first Receive Pu= sh Messages operation as the registration. Also, I am perhaps misreading th= e spec in which URL is given out to whom, now that I think about it. In Sec= 3, the Subscribe response is such:

HTTP/1.1 201 Created
Date: Thu, 11 Dec 2014 23:56:52 GMT
Link: </p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV>;
        rel=3D"urn:ietf:params:push"
Link: </receipts/xjTG79I3VuptNWS0DsFu4ihT97aE6UQJ>;
        rel=3D"urn:ietf:params:push:receipt"
Location: https://push.example.net/s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx
Cache-Control: max-age:864000, private
My thought was that the Loc= ation link is the one given to the AppServers, and the urn:ietf:params:push= link is the 'private URL' that the UA uses to receive push message= s. This way, after the initial Subscribe, the PS has associated that h2 con= nection with the private URL, and new Subscribe requests will return new Lo= cation links to give to the AppServer. It also means the UA would need to s= tore the Location for each Subscribe, since the private URL would be unchan= ging for all later Subscribe requests.

On reconnect, rece= iving push messages by hitting the private URL would then associate the h2 = connection again, acting as the registration.

If a UA wan= ts to operate independent batches of subscriptions, as the IoT use-case pre= viously cited, it must use entirely separate h2 connections for each batch.=

The spec includes a Location without identifying its act= ual use, as my reading of it seems unclear on if the Link is the one given = to the AppServer, or if its the Location.

This presumes t= hat there is no h2 proxying such that individual requests over the same con= nection might be on behalf of different UA's. (I really really don'= t like the thought of an h2 proxy of this nature, because it means it could= lie about whether a client is still actually 'alive' to ping frame= s, and that's given us enough grief with mobile TCP proxies).

In this manner, the PS could choose whether to give the same priva= te URL back for all Subscribe requests over the same connection, or not. Th= e additional requirements on the UA:
- It must store the Location, since= that's the guaranteed unique part
- If it gets the same private URL= back, it should only use the Receive operation once, and realize all new p= ush messages will come over the existing GET
- On reconnect, = it MUST send the Receive operation before any new Subscribe operations (sin= ce that's treated as 'registration' on reconnect)

=
This way a PS gets to choose, and the associating link is the push lin= k itself. If the thought was that the push Link is the one sent to AppServe= rs, then some of this will need a bit of changing of course.
=
=C2=A0
=C2=A0
I think the PS should/must support it but it wou= ld be the client/UA=E2=80=99s decision to aggregate. We can put language to = =E2=80=9Cstrongly recommend=E2=80=9D the client/UA to aggregate but it woul= d still be the client=E2=80=99s decision to include the initial subscriptio= n when making subsequent subscription requests.


If we agree that a push provider may require 'aggregation' - a= ll subscriptions from a device, when connecting
to such a provider, will need to have something in common, to allow th= e aggregation. The original
=C2=A0"registration + subscription" does it by having a firs= t step where a device gets the common element.=C2=A0
It can be simplified by defining the 'registration' as a regul= ar subscription, and allowing each app to
=C2=A0have a 'child' subscription. This works nicely if a UA s= upports profiles/multi-user for example - and may=C2=A0
be extended later for more complicated cases, where a UA acts as a pro= xy for other UAs ( for example=C2=A0
a wearable device paired over BT ).=C2=A0

DT>> I think within the context of the fact that a client= does want to =E2=80=9Caggregate=E2=80=9D, all of the above is doable. Howe= ver as I mentioned above, if a client does not send the =E2=80=9Cparent sub= scription=E2=80=9D info in the subsequent subscription requests, there=E2= =80=99s no easy way for a PS to force aggregation.=C2=A0

=
I wouldn't be very worried about a small percentage o= f devices not aggregating - and anything large is usually detectable.
=


Costin
=C2=A0

The subscription API should allow a way to create 'links' betw= een subscriptions. We do need to=C2=A0
finish the separate discussion on sender authentication and registrati= on - but assuming a push service
requires sender authentication, this is another 'link' between= the app subscription and the server id (
which can be another capability URL or subscription ).=C2=A0

DT>> Yes, I believe that should be doable with the idea h= ere.=C2=A0


I don't think it's a problem if the 'non-aggregated' m= odel - where nothing is shared - is defined even as default,
and some push providers may chose to support both, or only one model, = depending on their scale and costs

Costin

On Tue, Jul 21, 2015 at 9:26 AM, Benjamin Banger= t <bbangert@mozi= lla.com> wrote:
My preference would be for the server to be able to require this, rath= er than leaving it up to the client. If a server doesn't want to expend= the heavy resource cost of treating every single subscription as its own U= RL, there should be a way for the server to indicate that in its subscription response.

For an IoT use-case, where a client might want different sets of subscripti= ons entirely, and to only check one group of them, it could open a separate= h2 connection to retrieve that set.

On Mon, Jul 20, 2015 at 2:41 PM, Darshak T= hakore <d.thakore@cablelabs.com> wrote:

It seems like we do want some mechanism that allows a client to retrieve notifications for all subscriptions with a single fetch. For IoT based use<= br> cases also this is desirable. I guess this keeps going back to the
aggregation-vs-disaggregation discussion. However I=C2=B9m wondering if its=
possible to define/create a sort of =C2=B3aggregation-on-demand=C2=B2 mode = with the
default being the current =C2=B3disaggregation=C2=B2 mode.

For example, once a client/UA has subscribed for the first time and holds 1 subscription, when it wants to create subsequent subscriptions, it can include the first subscription in the request:

POST /subscribe/ HTTP/1.1
HOST: push.example.net
Link: </s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx>;
rel=3D=C2=B3urn:ietf:params:push:subcribe=C2=B2 (I=C2=B9m not sure if its o= k to use Link
header in a request, if not we need to find something more suitable)

When a PS processes this request, it can associate the new subscription
with the one provided. (I think the additional data stored by the PS to
achieve this should be minimal). The response would contain the new
subscription info as currently defined (and maybe something additional to indicate that the new subscription is tied to the one in the request)

When receiving PUSH messages, a client/UA can make a single GET request to<= br> the primary subscription resource and the server will send push
notifications for all subscriptions associated with the primary
subscription.

For example, the request would be

HEADERS=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[stream 7] +EHD_STREAM +END_HEADER= S
=C2=A0 :method=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D GET
=C2=A0 :path=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D /s/LBhhw0OohO-Wl4Oi971UGs= B7sdQGUibx
=C2=A0 :authority=C2=A0 =C2=A0 =3D push.example.net

And the corresponding response would be

PUSH_PROMISE=C2=A0 =C2=A0 [stream 7; promised stream 4] +END_HEADERS
=C2=A0 :method=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D GET
=C2=A0 :path=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D /d/qDIYHNcfAIPP_5ITvURr-d= 6BGtYnTRnk
=C2=A0 :authority=C2=A0 =C2=A0 =3D push.example.net

HEADERS=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[stream 4] +END_HEADERS
=C2=A0 :status=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D 200
=C2=A0 =E2=80=B9=E2=80=B9OTHER HEADERS =E2=80=B9=E2=80=B9
=C2=A0 :content-loc=C2=A0 =3D /s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx

DATA=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [stream 4] +END_STREAM
=C2=A0 =C2=A0 =C2=A0iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB


PUSH_PROMISE=C2=A0 =C2=A0 [stream 7; promised stream 6] +END_HEADERS
=C2=A0 :method=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D GE= T
=C2=A0 :path=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =3D /d/gjuNJTYuZXkyylOOtjfAEo6ktRHCADui
=C2=A0 :authority=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D push.example.net

HEADERS=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[stream 6] +END_HEADERS
=C2=A0 :status=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D 200
=C2=A0 =E2=80=B9=E2=80=B9OTHER HEADERS =E2=80=B9=E2=80=B9
=C2=A0 :content-loc=C2=A0 =3D /s/hJ0jW1ElCjhjfwwh4kTQw7rEYK4QyFFW

DATA=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [stream 6] +END_STREAM
{encoded/encrypted-notification-message}


=E2=80=B9=E2=80=B9 additional PUSH messages for other subscriptions =E2=80= =B9=E2=80=B9



In the above example, the responses can include a Content-Location (or
some other appropriate) header to indicate the associated subscription for<= br> the notification message. This would allow the client/UA to send just one GET request to retrieve (and keep receiving) notifications on all its
active subscriptions. A client/UA may even choose to keep certain
subscriptions separate and group only a subset of them (this would be
useful in IoT like cases)


Darshak




On 7/20/15, 10:31 AM, "Webpush on behalf of Martin Thomson"
<webp= ush-bounces@ietf.org on behalf of martin.thomso= n@gmail.com> wrote:

>On 20 July 2015 at 09:21, Benjamin Bangert <bbangert@mozilla.com> wrote:
>> What's the use-case of a client polling over a long-lived conn= ection
>
>The use case is for a device that is only periodically online (a
>constrained device) that wants to check in, then immediately go
>offline again.
>
>_______________________________________________
>Webpush mailing list
>Webpush@ietf.org<= /a>
>https://www.ietf.org/mailman/listinfo/webpush
_______________________________________________
Webpush mailing list
Webpush@ietf.org<= br> https://www.ietf.org/mailman/listinfo/webpush


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


--001a11c25f8ca0a463051b794bb5-- From nobody Wed Jul 22 09:45:57 2015 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 63A921A1ADC for ; Wed, 22 Jul 2015 09:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 OIhLU1ir0q3O for ; Wed, 22 Jul 2015 09:45:50 -0700 (PDT) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (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 E057D1A8BC2 for ; Wed, 22 Jul 2015 09:45:44 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so171805320wib.0 for ; Wed, 22 Jul 2015 09:45:43 -0700 (PDT) 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=1ZbXbT7npVm6eMpnTrbtU++2BOZRcSy2QHMLJf5wKPc=; b=RxAS4Pve4qBCLKCoX5V9lto5TaCTiANeJkvCYDH7QlpZEQqxMYFtR7N1GjIIq80ix2 2Jgb+E3engFDbK+T+4+yhp1HuGUxXKRpyKzq3IYWTiaI9PSDI2L/g92LJmM7CbHMYJ41 KnGArLBV2KdYPivBNO2OTWDIHzvzibA99Tm7eWkWqJdvAqO8sCcV3K10z+NZ3a1FEtEM k9Qv2BYyyqkC0z3vkta5JJFxC3AMAdx1BvWtZlIou4DrBb6XyfEX95o8gyZpb0i9Au+Z 5Pe/5J2+gMlwNttoFOBhORoox+RlzUrJeCL0DKIR2l0phpgRmS/IYW9fLIUEY5Lczj9g hXwg== X-Gm-Message-State: ALoCoQnHxcUUGjMRekA0c7k/ZJ91/lZGP7klFGCm4hlLXxwA9oZhTm7QHMJ/brOxnTfU/eeFQAH0 MIME-Version: 1.0 X-Received: by 10.180.72.145 with SMTP id d17mr44142125wiv.69.1437583543530; Wed, 22 Jul 2015 09:45:43 -0700 (PDT) Received: by 10.27.33.81 with HTTP; Wed, 22 Jul 2015 09:45:43 -0700 (PDT) In-Reply-To: References: Date: Wed, 22 Jul 2015 09:45:43 -0700 Message-ID: From: Benjamin Bangert To: Costin Manolache Content-Type: multipart/alternative; boundary=14dae9cc94927292bc051b79801e Archived-At: Cc: Darshak Thakore , "webpush@ietf.org" Subject: Re: [Webpush] comments on latest draft-thomson-webpush-protocol-00 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, 22 Jul 2015 16:45:55 -0000 --14dae9cc94927292bc051b79801e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I should also note, under my scheme, unsubscribe must be handled differently (to include Location), and push messages will also need to include the Location for the UA to identify them correctly. Alternatively, another Link could be added to identify the aggregation URL that should be used, and unsubscribe can operate the same. On Wed, Jul 22, 2015 at 9:30 AM, Benjamin Bangert wrote: > On Wed, Jul 22, 2015 at 8:27 AM, Costin Manolache > wrote: > >> >> >> On Wed, Jul 22, 2015 at 1:25 AM, Darshak Thakore > > wrote: >> >>> Comments below >>> >>> On 7/21/15, 6:48 PM, "Costin Manolache" wrote: >>> >>> I think one question is who makes the decision if subscrptions are >>> 'aggregated' or not. And the only answer >>> I know is the push provider - since the push provider is the one bearin= g >>> the costs and defining the >>> requirements for UAs that connect to it. >>> >>> >>> DT>> As I mentioned in the other email (Benjamin=E2=80=99s email), I= =E2=80=99m not >>> sure how a PS can force a UA to aggregate (unless the PS somehow identi= fies >>> the client based on authentication/cookie/something-else). >>> >> >> In aggregate model, there is a registration (or subscription) for the UA= , >> and each origin/serviceworker have a subscription associated with the UA= . >> >> The PS can simply reject subscriptions that don't have an associated >> parent, and not deliver the the registration/root. Than the UA >> may chose a different PS, or aggregate. >> >> Or: terms of service and abuse detection on PS. >> >> There was a thread about PS returning a URL that may require additional >> user interaction when the UA registers with the PS, >> and may have separate relation ( like Setup Wizard in android ). For >> example GCM attempts to determine device type, if it is rooted, etc. >> >> I don't think the expectation is that a PS MUST accept arbitrary UAs, >> free and without any checks or rules. >> > > I'm associating one h2 connection as being one UA, and treating the first > Subscribe operation, or the first Receive Push Messages operation as the > registration. Also, I am perhaps misreading the spec in which URL is give= n > out to whom, now that I think about it. In Sec 3, the Subscribe response = is > such: > > HTTP/1.1 201 Created > Date: Thu, 11 Dec 2014 23:56:52 GMT > Link:

; > rel=3D"urn:ietf:params:push" > Link: ; > rel=3D"urn:ietf:params:push:receipt" > Location: https://push.example.net/s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx > Cache-Control : max-age:864000, private > > My thought was that the Location link is the one given to the AppServers, > and the urn:ietf:params:push link is the 'private URL' that the UA uses t= o > receive push messages. This way, after the initial Subscribe, the PS has > associated that h2 connection with the private URL, and new Subscribe > requests will return new Location links to give to the AppServer. It also > means the UA would need to store the Location for each Subscribe, since t= he > private URL would be unchanging for all later Subscribe requests. > > On reconnect, receiving push messages by hitting the private URL would > then associate the h2 connection again, acting as the registration. > > If a UA wants to operate independent batches of subscriptions, as the IoT > use-case previously cited, it must use entirely separate h2 connections f= or > each batch. > > The spec includes a Location without identifying its actual use, as my > reading of it seems unclear on if the Link is the one given to the > AppServer, or if its the Location. > > This presumes that there is no h2 proxying such that individual requests > over the same connection might be on behalf of different UA's. (I really > really don't like the thought of an h2 proxy of this nature, because it > means it could lie about whether a client is still actually 'alive' to pi= ng > frames, and that's given us enough grief with mobile TCP proxies). > > In this manner, the PS could choose whether to give the same private URL > back for all Subscribe requests over the same connection, or not. The > additional requirements on the UA: > - It must store the Location, since that's the guaranteed unique part > - If it gets the same private URL back, it should only use the Receive > operation once, and realize all new push messages will come over the > existing GET > - On reconnect, it MUST send the Receive operation before any new > Subscribe operations (since that's treated as 'registration' on reconnect= ) > > This way a PS gets to choose, and the associating link is the push link > itself. If the thought was that the push Link is the one sent to > AppServers, then some of this will need a bit of changing of course. > > > >> >> >>> I think the PS should/must support it but it would be the client/UA=E2= =80=99s >>> decision to aggregate. We can put language to =E2=80=9Cstrongly recomme= nd=E2=80=9D the >>> client/UA to aggregate but it would still be the client=E2=80=99s decis= ion to >>> include the initial subscription when making subsequent subscription >>> requests. >>> >> >>> >>> If we agree that a push provider may require 'aggregation' - all >>> subscriptions from a device, when connecting >>> to such a provider, will need to have something in common, to allow the >>> aggregation. The original >>> "registration + subscription" does it by having a first step where a >>> device gets the common element. >>> It can be simplified by defining the 'registration' as a regular >>> subscription, and allowing each app to >>> have a 'child' subscription. This works nicely if a UA supports >>> profiles/multi-user for example - and may >>> be extended later for more complicated cases, where a UA acts as a prox= y >>> for other UAs ( for example >>> a wearable device paired over BT ). >>> >>> >>> DT>> I think within the context of the fact that a client does want to >>> =E2=80=9Caggregate=E2=80=9D, all of the above is doable. However as I m= entioned above, if a >>> client does not send the =E2=80=9Cparent subscription=E2=80=9D info in = the subsequent >>> subscription requests, there=E2=80=99s no easy way for a PS to force ag= gregation. >>> >> >> I wouldn't be very worried about a small percentage of devices not >> aggregating - and anything large is usually detectable. >> >> >> Costin >> >> >>> >>> The subscription API should allow a way to create 'links' between >>> subscriptions. We do need to >>> finish the separate discussion on sender authentication and registratio= n >>> - but assuming a push service >>> requires sender authentication, this is another 'link' between the app >>> subscription and the server id ( >>> which can be another capability URL or subscription ). >>> >>> >>> DT>> Yes, I believe that should be doable with the idea here. >>> >>> >>> I don't think it's a problem if the 'non-aggregated' model - where >>> nothing is shared - is defined even as default, >>> and some push providers may chose to support both, or only one model, >>> depending on their scale and costs >>> >>> >>> Costin >>> >>> On Tue, Jul 21, 2015 at 9:26 AM, Benjamin Bangert >>> wrote: >>> >>>> My preference would be for the server to be able to require this, >>>> rather than leaving it up to the client. If a server doesn't want to e= xpend >>>> the heavy resource cost of treating every single subscription as its o= wn >>>> URL, there should be a way for the server to indicate that in its >>>> subscription response. >>>> >>>> For an IoT use-case, where a client might want different sets of >>>> subscriptions entirely, and to only check one group of them, it could = open >>>> a separate h2 connection to retrieve that set. >>>> >>>> On Mon, Jul 20, 2015 at 2:41 PM, Darshak Thakore < >>>> d.thakore@cablelabs.com> wrote: >>>> >>>>> >>>>> It seems like we do want some mechanism that allows a client to >>>>> retrieve >>>>> notifications for all subscriptions with a single fetch. For IoT base= d >>>>> use >>>>> cases also this is desirable. I guess this keeps going back to the >>>>> aggregation-vs-disaggregation discussion. However I=C2=B9m wondering = if its >>>>> possible to define/create a sort of =C2=B3aggregation-on-demand=C2=B2= mode with >>>>> the >>>>> default being the current =C2=B3disaggregation=C2=B2 mode. >>>>> >>>>> For example, once a client/UA has subscribed for the first time and >>>>> holds >>>>> 1 subscription, when it wants to create subsequent subscriptions, it >>>>> can >>>>> include the first subscription in the request: >>>>> >>>>> POST /subscribe/ HTTP/1.1 >>>>> HOST: push.example.net >>>>> Link: ; >>>>> rel=3D=C2=B3urn:ietf:params:push:subcribe=C2=B2 (I=C2=B9m not sure if= its ok to use Link >>>>> header in a request, if not we need to find something more suitable) >>>>> >>>>> When a PS processes this request, it can associate the new subscripti= on >>>>> with the one provided. (I think the additional data stored by the PS = to >>>>> achieve this should be minimal). The response would contain the new >>>>> subscription info as currently defined (and maybe something additiona= l >>>>> to >>>>> indicate that the new subscription is tied to the one in the request) >>>>> >>>>> When receiving PUSH messages, a client/UA can make a single GET >>>>> request to >>>>> the primary subscription resource and the server will send push >>>>> notifications for all subscriptions associated with the primary >>>>> subscription. >>>>> >>>>> For example, the request would be >>>>> >>>>> HEADERS [stream 7] +EHD_STREAM +END_HEADERS >>>>> :method =3D GET >>>>> :path =3D /s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx >>>>> :authority =3D push.example.net >>>>> >>>>> And the corresponding response would be >>>>> >>>>> PUSH_PROMISE [stream 7; promised stream 4] +END_HEADERS >>>>> :method =3D GET >>>>> :path =3D /d/qDIYHNcfAIPP_5ITvURr-d6BGtYnTRnk >>>>> :authority =3D push.example.net >>>>> >>>>> HEADERS [stream 4] +END_HEADERS >>>>> :status =3D 200 >>>>> =E2=80=B9=E2=80=B9OTHER HEADERS =E2=80=B9=E2=80=B9 >>>>> :content-loc =3D /s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx >>>>> >>>>> DATA [stream 4] +END_STREAM >>>>> iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB >>>>> >>>>> >>>>> PUSH_PROMISE [stream 7; promised stream 6] +END_HEADERS >>>>> :method =3D GET >>>>> :path =3D /d/gjuNJTYuZXkyylOOtjfAEo6ktRHCADui >>>>> :authority =3D push.example.net >>>>> >>>>> HEADERS [stream 6] +END_HEADERS >>>>> :status =3D 200 >>>>> =E2=80=B9=E2=80=B9OTHER HEADERS =E2=80=B9=E2=80=B9 >>>>> :content-loc =3D /s/hJ0jW1ElCjhjfwwh4kTQw7rEYK4QyFFW >>>>> >>>>> DATA [stream 6] +END_STREAM >>>>> {encoded/encrypted-notification-message} >>>>> >>>>> >>>>> =E2=80=B9=E2=80=B9 additional PUSH messages for other subscriptions = =E2=80=B9=E2=80=B9 >>>>> >>>>> >>>>> >>>>> In the above example, the responses can include a Content-Location (o= r >>>>> some other appropriate) header to indicate the associated subscriptio= n >>>>> for >>>>> the notification message. This would allow the client/UA to send just >>>>> one >>>>> GET request to retrieve (and keep receiving) notifications on all its >>>>> active subscriptions. A client/UA may even choose to keep certain >>>>> subscriptions separate and group only a subset of them (this would be >>>>> useful in IoT like cases) >>>>> >>>>> >>>>> Darshak >>>>> >>>>> >>>>> >>>>> >>>>> On 7/20/15, 10:31 AM, "Webpush on behalf of Martin Thomson" >>>>> >>>>> wrote: >>>>> >>>>> >On 20 July 2015 at 09:21, Benjamin Bangert >>>>> wrote: >>>>> >> What's the use-case of a client polling over a long-lived connecti= on >>>>> > >>>>> >The use case is for a device that is only periodically online (a >>>>> >constrained device) that wants to check in, then immediately go >>>>> >offline again. >>>>> > >>>>> >_______________________________________________ >>>>> >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 >>>> >>>> >>> >> > --14dae9cc94927292bc051b79801e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I should also note, under my scheme, unsubscribe must= be handled differently (to include Location), and push messages will also = need to include the Location for the UA to identify them correctly.

=
Alternatively, another Link could be added to identify the aggregatio= n URL that should be used, and unsubscribe can operate the same.
<= div class=3D"gmail_extra">
On Wed, Jul 22, 20= 15 at 9:30 AM, Benjamin Bangert <bbangert@mozilla.com> wr= ote:
On Wed, Jul 22, 2015 at= 8:27 AM, Costin Manolache <costin@gmail.com> wrote:


On Wed, Jul 22, 2015= at 1:25 AM, Darshak Thakore <d.thakore@cablelabs.com>= wrote:
Comments below

On 7/21/15, 6:48 PM, "Costin Manolache" <costin@gmail.com> wrote:

I think one question is who makes the decision if subscrpt= ions are 'aggregated' or not. And the only answer=C2=A0
I know is the push provider - since the push provider is the one beari= ng the costs and defining the=C2=A0
requirements for UAs that connect to it.=C2=A0

DT>> As I mentioned in the other email (Benjamin=E2=80=99= s email), I=E2=80=99m not sure how a PS can force a UA to aggregate (unless= the PS somehow identifies the client based on authentication/cookie/someth= ing-else).

In aggregate= model, there is a registration (or subscription) for the UA, and each orig= in/serviceworker have a subscription associated with the UA.=C2=A0

The PS can simply reject subscriptions that don't have= an associated parent, and not deliver the the registration/root. Than the = UA
may chose a different PS, or aggregate.

Or: terms of service and abuse detection on PS.=C2=A0

There was a thread about PS returning a URL that may require additio= nal user interaction when the UA registers with the PS,
and may h= ave separate relation ( like Setup Wizard in android ). For example GCM att= empts to determine device type, if it is rooted, etc.=C2=A0

<= /div>
I don't think the expectation is that a PS MUST accept arbitr= ary UAs, free and without any checks or rules.

I'm associating one h2 connection as= being one UA, and treating the first Subscribe operation, or the first Rec= eive Push Messages operation as the registration. Also, I am perhaps misrea= ding the spec in which URL is given out to whom, now that I think about it.= In Sec 3, the Subscribe response is such:

HTTP/1.1 201 Created
Date: Thu, 11 Dec 2014 23:56:52 GMT
Link: </p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV>;
        rel=3D"urn:ietf:params:push"
Link: </receipts/xjTG79I3VuptNWS0DsFu4ihT97aE6UQJ>;
        rel=3D"urn:ietf:params:push:receipt"
Location: https://push.example.net/s/LBhhw0OohO=
-Wl4Oi971UGsB7sdQGUibx
Cache-Control: max-age:864000, private
My thought was that the Loc= ation link is the one given to the AppServers, and the urn:ietf:params:push= link is the 'private URL' that the UA uses to receive push message= s. This way, after the initial Subscribe, the PS has associated that h2 con= nection with the private URL, and new Subscribe requests will return new Lo= cation links to give to the AppServer. It also means the UA would need to s= tore the Location for each Subscribe, since the private URL would be unchan= ging for all later Subscribe requests.

On reconnect, rece= iving push messages by hitting the private URL would then associate the h2 = connection again, acting as the registration.

If a UA wan= ts to operate independent batches of subscriptions, as the IoT use-case pre= viously cited, it must use entirely separate h2 connections for each batch.=

The spec includes a Location without identifying its act= ual use, as my reading of it seems unclear on if the Link is the one given = to the AppServer, or if its the Location.

This presumes t= hat there is no h2 proxying such that individual requests over the same con= nection might be on behalf of different UA's. (I really really don'= t like the thought of an h2 proxy of this nature, because it means it could= lie about whether a client is still actually 'alive' to ping frame= s, and that's given us enough grief with mobile TCP proxies).

In this manner, the PS could choose whether to give the same priva= te URL back for all Subscribe requests over the same connection, or not. Th= e additional requirements on the UA:
- It must store the Location, since= that's the guaranteed unique part
- If it gets the same private URL= back, it should only use the Receive operation once, and realize all new p= ush messages will come over the existing GET
- On reconnect, = it MUST send the Receive operation before any new Subscribe operations (sin= ce that's treated as 'registration' on reconnect)

=
This way a PS gets to choose, and the associating link is the push lin= k itself. If the thought was that the push Link is the one sent to AppServe= rs, then some of this will need a bit of changing of course.
=

=C2=A0
=C2=A0
I think the PS should/must support it = but it would be the client/UA=E2=80=99s decision to aggregate. We can put language to = =E2=80=9Cstrongly recommend=E2=80=9D the client/UA to aggregate but it woul= d still be the client=E2=80=99s decision to include the initial subscriptio= n when making subsequent subscription requests.


If we agree that a push provider may require 'aggregation' - a= ll subscriptions from a device, when connecting
to such a provider, will need to have something in common, to allow th= e aggregation. The original
=C2=A0"registration + subscription" does it by having a firs= t step where a device gets the common element.=C2=A0
It can be simplified by defining the 'registration' as a regul= ar subscription, and allowing each app to
=C2=A0have a 'child' subscription. This works nicely if a UA s= upports profiles/multi-user for example - and may=C2=A0
be extended later for more complicated cases, where a UA acts as a pro= xy for other UAs ( for example=C2=A0
a wearable device paired over BT ).=C2=A0

DT>> I think within the context of the fact that a client= does want to =E2=80=9Caggregate=E2=80=9D, all of the above is doable. Howe= ver as I mentioned above, if a client does not send the =E2=80=9Cparent sub= scription=E2=80=9D info in the subsequent subscription requests, there=E2= =80=99s no easy way for a PS to force aggregation.=C2=A0

=
I wouldn't be very worried about a small percentage o= f devices not aggregating - and anything large is usually detectable.
=


Costin
=C2=A0

The subscription API should allow a way to create 'links' betw= een subscriptions. We do need to=C2=A0
finish the separate discussion on sender authentication and registrati= on - but assuming a push service
requires sender authentication, this is another 'link' between= the app subscription and the server id (
which can be another capability URL or subscription ).=C2=A0

DT>> Yes, I believe that should be doable with the idea h= ere.=C2=A0


I don't think it's a problem if the 'non-aggregated' m= odel - where nothing is shared - is defined even as default,
and some push providers may chose to support both, or only one model, = depending on their scale and costs

Costin

On Tue, Jul 21, 2015 at 9:26 AM, Benjamin Banger= t <bbangert@mozi= lla.com> wrote:
My preference would be for the server to be able to require this, rath= er than leaving it up to the client. If a server doesn't want to expend= the heavy resource cost of treating every single subscription as its own U= RL, there should be a way for the server to indicate that in its subscription response.

For an IoT use-case, where a client might want different sets of subscripti= ons entirely, and to only check one group of them, it could open a separate= h2 connection to retrieve that set.

On Mon, Jul 20, 2015 at 2:41 PM, Darshak T= hakore <d.thakore@cablelabs.com> wrote:

It seems like we do want some mechanism that allows a client to retrieve notifications for all subscriptions with a single fetch. For IoT based use<= br> cases also this is desirable. I guess this keeps going back to the
aggregation-vs-disaggregation discussion. However I=C2=B9m wondering if its=
possible to define/create a sort of =C2=B3aggregation-on-demand=C2=B2 mode = with the
default being the current =C2=B3disaggregation=C2=B2 mode.

For example, once a client/UA has subscribed for the first time and holds 1 subscription, when it wants to create subsequent subscriptions, it can include the first subscription in the request:

POST /subscribe/ HTTP/1.1
HOST: push.example.net
Link: </s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx>;
rel=3D=C2=B3urn:ietf:params:push:subcribe=C2=B2 (I=C2=B9m not sure if its o= k to use Link
header in a request, if not we need to find something more suitable)

When a PS processes this request, it can associate the new subscription
with the one provided. (I think the additional data stored by the PS to
achieve this should be minimal). The response would contain the new
subscription info as currently defined (and maybe something additional to indicate that the new subscription is tied to the one in the request)

When receiving PUSH messages, a client/UA can make a single GET request to<= br> the primary subscription resource and the server will send push
notifications for all subscriptions associated with the primary
subscription.

For example, the request would be

HEADERS=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[stream 7] +EHD_STREAM +END_HEADER= S
=C2=A0 :method=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D GET
=C2=A0 :path=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D /s/LBhhw0OohO-Wl4Oi971UGs= B7sdQGUibx
=C2=A0 :authority=C2=A0 =C2=A0 =3D push.example.net

And the corresponding response would be

PUSH_PROMISE=C2=A0 =C2=A0 [stream 7; promised stream 4] +END_HEADERS
=C2=A0 :method=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D GET
=C2=A0 :path=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D /d/qDIYHNcfAIPP_5ITvURr-d= 6BGtYnTRnk
=C2=A0 :authority=C2=A0 =C2=A0 =3D push.example.net

HEADERS=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[stream 4] +END_HEADERS
=C2=A0 :status=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D 200
=C2=A0 =E2=80=B9=E2=80=B9OTHER HEADERS =E2=80=B9=E2=80=B9
=C2=A0 :content-loc=C2=A0 =3D /s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx

DATA=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [stream 4] +END_STREAM
=C2=A0 =C2=A0 =C2=A0iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB


PUSH_PROMISE=C2=A0 =C2=A0 [stream 7; promised stream 6] +END_HEADERS
=C2=A0 :method=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D GE= T
=C2=A0 :path=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =3D /d/gjuNJTYuZXkyylOOtjfAEo6ktRHCADui
=C2=A0 :authority=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D push.example.net

HEADERS=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[stream 6] +END_HEADERS
=C2=A0 :status=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D 200
=C2=A0 =E2=80=B9=E2=80=B9OTHER HEADERS =E2=80=B9=E2=80=B9
=C2=A0 :content-loc=C2=A0 =3D /s/hJ0jW1ElCjhjfwwh4kTQw7rEYK4QyFFW

DATA=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [stream 6] +END_STREAM
{encoded/encrypted-notification-message}


=E2=80=B9=E2=80=B9 additional PUSH messages for other subscriptions =E2=80= =B9=E2=80=B9



In the above example, the responses can include a Content-Location (or
some other appropriate) header to indicate the associated subscription for<= br> the notification message. This would allow the client/UA to send just one GET request to retrieve (and keep receiving) notifications on all its
active subscriptions. A client/UA may even choose to keep certain
subscriptions separate and group only a subset of them (this would be
useful in IoT like cases)


Darshak




On 7/20/15, 10:31 AM, "Webpush on behalf of Martin Thomson"
<webp= ush-bounces@ietf.org on behalf of martin.thomso= n@gmail.com> wrote:

>On 20 July 2015 at 09:21, Benjamin Bangert <bbangert@mozilla.com> wrote:
>> What's the use-case of a client polling over a long-lived conn= ection
>
>The use case is for a device that is only periodically online (a
>constrained device) that wants to check in, then immediately go
>offline again.
>
>_______________________________________________
>Webpush mailing list
>Webpush@ietf.org<= /a>
>https://www.ietf.org/mailman/listinfo/webpush
_______________________________________________
Webpush mailing list
Webpush@ietf.org<= br> https://www.ietf.org/mailman/listinfo/webpush


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



--14dae9cc94927292bc051b79801e-- From nobody Wed Jul 22 09:58:19 2015 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 857321A8F3E for ; Wed, 22 Jul 2015 09:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 yE5zB-s-Kc4o for ; Wed, 22 Jul 2015 09:58:15 -0700 (PDT) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (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 4B3021A8AFE for ; Wed, 22 Jul 2015 09:58:15 -0700 (PDT) Received: by wicmv11 with SMTP id mv11so89837551wic.0 for ; Wed, 22 Jul 2015 09:58:14 -0700 (PDT) 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=Dm/NTqRjVfhR2W2hbJGruHVAiX1f0ZDBEIS91MCSwrk=; b=ljp0dh2dNtcgLB4Yo7zI1SieINohYRDYtS/Q7c+EAop0YcYpN/LrxXirxme9U9+xdF F6DEL4gB5ckeCKlqtnxRLAaDF0legZnyJEkd9SftWUewOUER6KFRHT5c611UVgyLzOQe aw1bvmeDB106S8VafDyvC9+QR8zO79dQ/J2TfktinrUavpfbgqDqcc0acbT3gtBRuIwu MdavEaBZGXQXWdFHOGMdfTP+4OEILqiKyxvORnbHGZtYN1WayXq3HUhsckeRkBJi0oHk eEwNmbpM2egf0MumAzC4nVyZOVf3Xt5kYJBB9yZgzrmG6n8qqSMDz5TDbphZAgjDMCQl MsVA== X-Gm-Message-State: ALoCoQkamKoGdMzUOZvbbMp7xqCDswsNQExiGQ1ffjZpMfpazaC+AxKQpxsWaS+iV6SHc9Lx4VDs MIME-Version: 1.0 X-Received: by 10.194.77.70 with SMTP id q6mr6942626wjw.70.1437584293900; Wed, 22 Jul 2015 09:58:13 -0700 (PDT) Received: by 10.27.33.81 with HTTP; Wed, 22 Jul 2015 09:58:13 -0700 (PDT) Date: Wed, 22 Jul 2015 09:58:13 -0700 Message-ID: From: Benjamin Bangert To: "webpush@ietf.org" Content-Type: multipart/alternative; boundary=047d7bf0c2962c4e2e051b79ad76 Archived-At: Subject: [Webpush] Push Message TTL 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, 22 Jul 2015 16:58:18 -0000 --047d7bf0c2962c4e2e051b79ad76 Content-Type: text/plain; charset=UTF-8 (Starting new threads for any further comments) https://unicorn-wg.github.io/webpush-protocol/#ttl makes some odd requirements on the Push Service. "Once the Time-To-Live (TTL) period elapses, the push service MUST remove the push message and cease any attempt to deliver it to the user agent. A push service might retain values for a short duration after the TTL period to account for time accounting errors in processing. For instance, distributing a push message within a server cluster might accrue errors due to clock variation, or processing and transit delays" I don't understand the requirement on the Push Service to remove expired messages so aggressively. Of course its not a big deal when a UA connects, to drop expired messages on checking storage instead of delivering them, but why is it not ok for a Push Service to only conduct periodic cleanups weekly (as it chooses fit) to delete expired messages? Cheers, Ben --047d7bf0c2962c4e2e051b79ad76 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
(Starting new threads for any further = comments)

https://unicorn-wg.github.io/webpush-protocol/#ttl makes som= e odd requirements on the Push Service.

"Once the Time-To-Live = (TTL) period elapses, the push service MUST remove the push message and cease any attempt to deliver it to the user agent. A push service might retain values for a short duration after the TTL=20 period to account for time accounting errors in processing. For=20 instance, distributing a push message within a server cluster might=20 accrue errors due to clock variation, or processing and transit delays"= ;

I don't understand the requirement on the Push Service t= o remove expired messages so aggressively. Of course its not a big deal whe= n a UA connects, to drop expired messages on checking storage instead of de= livering them, but why is it not ok for a Push Service to only conduct peri= odic cleanups weekly (as it chooses fit) to delete expired messages?
Cheers,
Ben
=20
--047d7bf0c2962c4e2e051b79ad76-- From nobody Wed Jul 22 10:06:10 2015 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 A8D521A8F39 for ; Wed, 22 Jul 2015 10:06:09 -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 ViAdtU0wegY6 for ; Wed, 22 Jul 2015 10:06:08 -0700 (PDT) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002: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 71D861A8BAF for ; Wed, 22 Jul 2015 10:06:08 -0700 (PDT) Received: by ykfw194 with SMTP id w194so117688614ykf.0 for ; Wed, 22 Jul 2015 10:06:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vkrBJn7NumZhR8/bxCQrdHYzu/CwFFDFWxdS5yzGQpI=; b=IrM5MY9rlwIFGFX1lcbyYUerMuO32L2wrtiHvXt3+ON/cP9S25kk3ODy9XMnBF+p8m O8yB42rEFwwO2LHREchaH7CoUbytNw+O3XghCNPhkyLVfslJbUIR4idz5b4iXmD18xtK EMCUSYoFkH97gk9PGjYajtwNF+pwcUXfMXT4D1B0irA4JWhiAnO5+ITyFyj9aX/j6yWH BKVld/hb3usMdsJNsAPsPMhr/IZoquP3m/nRYcYaDMh+NxepdZQaD5Eji5MFa2s8HKHR sxAPZkc4A4RDc6woyUm+SIaFJl2G/UP3fwOIgUBVYW8geakqX2eJ0e/Sr9JJ+NS5CCne 2MpA== MIME-Version: 1.0 X-Received: by 10.13.233.133 with SMTP id s127mr3615641ywe.154.1437584767874; Wed, 22 Jul 2015 10:06:07 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Wed, 22 Jul 2015 10:06:07 -0700 (PDT) In-Reply-To: References: Date: Wed, 22 Jul 2015 19:06:07 +0200 Message-ID: From: Martin Thomson To: Benjamin Bangert Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Push Message TTL 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, 22 Jul 2015 17:06:09 -0000 On 22 July 2015 at 18:58, Benjamin Bangert wrote: > I don't understand the requirement on the Push Service to remove expired > messages so aggressively. I wanted to avoid situations where messages that are strictly time-bounded (a call notification is a good example) are delivered and acted upon. If an application says TTL: 10, then I would like some certainty that the push service respects that and doesn't deliver the message an hour later. If you don't have a requirement to drop the message, then applications will have to add their own TTL handling (something they might want to do for separate, security reasons, but something that they probably wont). If the application doesn't check for validity, they could do bad things on old information, like trigger a call alert. From nobody Wed Jul 22 10:08:59 2015 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 787EA1A1B66 for ; Wed, 22 Jul 2015 10:08:57 -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 hjoUYIztfjem for ; Wed, 22 Jul 2015 10:08:52 -0700 (PDT) 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 6CC661B2B9B for ; Wed, 22 Jul 2015 10:08:40 -0700 (PDT) Received: by ykax123 with SMTP id x123so198426580yka.1 for ; Wed, 22 Jul 2015 10:08:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GTKAiMwjqdE9DGXPFosYRxaV5WwAeieOrtKclCEBKIg=; b=e+asgg/KLeVMuOTJsNhwa09J52LZJ/TWUv1Ne7Zw6S1QVqcZ+TB/htP4Ch0O36PGwA ZSmz+FT4P9XUdEsRlL3aQfgnYs510J37szG7iqaZH846eX8iJUnyZ77HuRM3DsKYjMQz 59T9nbgcdKZKMt8/W83teppHZ/6yXx02tZ6Xspb/EcUIIWb0MWvXPMBpewev0GCB7Uo6 yXnDaSH79AINns2a67uAtPkWcGRBO9r/RmGwqcz4+XuBZWmETP+4hkcYwbly1koTDJI3 vfc85Q80NVMj/mjwdbUHaq7j7TcH3K9fuCrJ893dFjLnQOuOzMXJabPZDgHiR1veRHxB +PEQ== MIME-Version: 1.0 X-Received: by 10.13.216.210 with SMTP id a201mr3605402ywe.89.1437584919888; Wed, 22 Jul 2015 10:08:39 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Wed, 22 Jul 2015 10:08:39 -0700 (PDT) In-Reply-To: References: Date: Wed, 22 Jul 2015 19:08:39 +0200 Message-ID: From: Martin Thomson To: Benjamin Bangert Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Push Message TTL 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, 22 Jul 2015 17:08:57 -0000 And... Ben just corrected me offline. There is a mode where the push service only does TTL-based cleanup periodically, or when clients connect. That suggests that we might want to relax the requirement to delete the data. However, there might be some privacy implications to retaining the information, so some sort of time bound might be needed. I'll open an issue on the spec. On 22 July 2015 at 19:06, Martin Thomson wrote: > On 22 July 2015 at 18:58, Benjamin Bangert wrote: >> I don't understand the requirement on the Push Service to remove expired >> messages so aggressively. > > > I wanted to avoid situations where messages that are strictly > time-bounded (a call notification is a good example) are delivered and > acted upon. If an application says TTL: 10, then I would like some > certainty that the push service respects that and doesn't deliver the > message an hour later. > > If you don't have a requirement to drop the message, then applications > will have to add their own TTL handling (something they might want to > do for separate, security reasons, but something that they probably > wont). If the application doesn't check for validity, they could do > bad things on old information, like trigger a call alert. From nobody Wed Jul 22 14:44:35 2015 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 B8D491B2F0D for ; Wed, 22 Jul 2015 14:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.227 X-Spam-Level: X-Spam-Status: No, score=0.227 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] 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 IZw47dGu-daJ for ; Wed, 22 Jul 2015 14:44:29 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 8E32F1B2F18 for ; Wed, 22 Jul 2015 14:44:29 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id t6MLiIAm009501; Wed, 22 Jul 2015 15:44:18 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Wed, 22 Jul 2015 15:44:17 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([::1]) by EXCHANGE.cablelabs.com ([::1]) with mapi id 14.03.0224.002; Wed, 22 Jul 2015 15:44:15 -0600 From: Darshak Thakore To: Benjamin Bangert , Costin Manolache Thread-Topic: [Webpush] comments on latest draft-thomson-webpush-protocol-00 Thread-Index: AQHQunlLM+hV2NIVmEuOC+Bk2k+U+Z3ju0gAgAFEnICAAALrAP//8eCAgAGe6oCAAIw5gIAAG00AgADacwCAABGjgP//8t6A Date: Wed, 22 Jul 2015 21:44:14 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 x-originating-ip: [10.5.0.27] Content-Type: multipart/alternative; boundary="_000_D1D5684C71BCdthakorecablelabscom_" MIME-Version: 1.0 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] comments on latest draft-thomson-webpush-protocol-00 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, 22 Jul 2015 21:44:33 -0000 --_000_D1D5684C71BCdthakorecablelabscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 IEkgdGhpbmsgeW91IGhhdmUgaXQgYmFja3dhcmRzIChtYXliZSB3ZSBuZWVkIHRvIGJlIG1vcmUg ZXhwbGljaXQgaW4gdGhlIHNwZWMpLiBUaGUgTG9jYXRpb24gbGluayBpcyB0aGUg4oCccHJpdmF0 ZeKAnSBsaW5rIHRoYXQgdGhlIFVBIGhvbGRzLiBUaGF04oCZcyB0aGUgbGluayB0byB3aGljaCB0 aGUgVUEvY2xpZW50IGlzIGdvaW5nIHRvIG1ha2UgdGhlIHJlcXVlc3QgdG8gZm9yIGdldHRpbmcg dGhlIG5vdGlmaWNhdGlvbnMgIChTZWN0aW9uIDYgc2hvd3MgdGhhdCB0aGUgaDIgR0VUIGlzIGJl aW5nIGRvbmUgYnkgdGhlIFVBL2NsaWVudCB0byB0aGUgIi9zL0xCaGh3ME9vaE8tV2w0T2k5NzFV R3NCN3NkUUdVaWJ4IikuIFRoZSDigJx1cm46aWV0ZjpwYXJhbXM6cHVzaOKAnSBsaW5rIGlzIHRo ZSBvbmUgdGhhdCBpcyBkaXN0cmlidXRlZCB0byB0aGUgYXBwbGljYXRpb24gc2VydmVycyAoYWxv bmcgd2l0IHRoZSAvcmVjZWlwdHMveHh4eCkuIFRoZSBjdXJyZW50IHNwZWMgcmVxdWlyZXMgdGhl IFVBL2NsaWVudCB0byBtYWtlIHNlcGFyYXRlIEdFVOKAmXMgdG8gdGhlIFVSSSBwcm92aWRlZCBp biB0aGUgTG9jYXRpb24gZmllbGQgKGFsYmVpdCBpdCBjYW4gYmUgZG9uZSBvbiB0aGUgc2FtZSBo MiBjb25uZWN0aW9uKS4gQnkgbGlua2luZyB0aGUgc3Vic2NyaXB0aW9ucyB0byB0aGUgcHJpbWFy eSBzdWJzY3JpcHRpb24sIHRoZSBVQS9jbGllbnQgY2FuIG1ha2UgYSBzaW5nbGUgaDIgR0VUIHJl cXVlc3QgdG8gcHJpbWFyeSBzdWJzY3JpcHRpb24gVVJJICh0aGUgb25lIHJldHVybmVkIGluIHRo ZSBMb2NhdGlvbiBoZWFkZXIgb2YgdGhlIHByaW1hcnkgc3Vic2NyaXB0aW9uKSBhbmQgZ2V0IG5v dGlmaWNhdGlvbnMgZm9yIGFsbCBzdWJzZXF1ZW50IHN1YnNjcmlwdGlvbnMuDQoNCg0KT24gNy8y Mi8xNSwgMTA6MzAgQU0sICJCZW5qYW1pbiBCYW5nZXJ0IiA8YmJhbmdlcnRAbW96aWxsYS5jb208 bWFpbHRvOmJiYW5nZXJ0QG1vemlsbGEuY29tPj4gd3JvdGU6DQoNCk9uIFdlZCwgSnVsIDIyLCAy MDE1IGF0IDg6MjcgQU0sIENvc3RpbiBNYW5vbGFjaGUgPGNvc3RpbkBnbWFpbC5jb208bWFpbHRv OmNvc3RpbkBnbWFpbC5jb20+PiB3cm90ZToNCg0KDQpPbiBXZWQsIEp1bCAyMiwgMjAxNSBhdCAx OjI1IEFNLCBEYXJzaGFrIFRoYWtvcmUgPGQudGhha29yZUBjYWJsZWxhYnMuY29tPG1haWx0bzpk LnRoYWtvcmVAY2FibGVsYWJzLmNvbT4+IHdyb3RlOg0KQ29tbWVudHMgYmVsb3cNCg0KT24gNy8y MS8xNSwgNjo0OCBQTSwgIkNvc3RpbiBNYW5vbGFjaGUiIDxjb3N0aW5AZ21haWwuY29tPG1haWx0 bzpjb3N0aW5AZ21haWwuY29tPj4gd3JvdGU6DQoNCkkgdGhpbmsgb25lIHF1ZXN0aW9uIGlzIHdo byBtYWtlcyB0aGUgZGVjaXNpb24gaWYgc3Vic2NycHRpb25zIGFyZSAnYWdncmVnYXRlZCcgb3Ig bm90LiBBbmQgdGhlIG9ubHkgYW5zd2VyDQpJIGtub3cgaXMgdGhlIHB1c2ggcHJvdmlkZXIgLSBz aW5jZSB0aGUgcHVzaCBwcm92aWRlciBpcyB0aGUgb25lIGJlYXJpbmcgdGhlIGNvc3RzIGFuZCBk ZWZpbmluZyB0aGUNCnJlcXVpcmVtZW50cyBmb3IgVUFzIHRoYXQgY29ubmVjdCB0byBpdC4NCg0K RFQ+PiBBcyBJIG1lbnRpb25lZCBpbiB0aGUgb3RoZXIgZW1haWwgKEJlbmphbWlu4oCZcyBlbWFp bCksIEnigJltIG5vdCBzdXJlIGhvdyBhIFBTIGNhbiBmb3JjZSBhIFVBIHRvIGFnZ3JlZ2F0ZSAo dW5sZXNzIHRoZSBQUyBzb21laG93IGlkZW50aWZpZXMgdGhlIGNsaWVudCBiYXNlZCBvbiBhdXRo ZW50aWNhdGlvbi9jb29raWUvc29tZXRoaW5nLWVsc2UpLg0KDQpJbiBhZ2dyZWdhdGUgbW9kZWws IHRoZXJlIGlzIGEgcmVnaXN0cmF0aW9uIChvciBzdWJzY3JpcHRpb24pIGZvciB0aGUgVUEsIGFu ZCBlYWNoIG9yaWdpbi9zZXJ2aWNld29ya2VyIGhhdmUgYSBzdWJzY3JpcHRpb24gYXNzb2NpYXRl ZCB3aXRoIHRoZSBVQS4NCg0KVGhlIFBTIGNhbiBzaW1wbHkgcmVqZWN0IHN1YnNjcmlwdGlvbnMg dGhhdCBkb24ndCBoYXZlIGFuIGFzc29jaWF0ZWQgcGFyZW50LCBhbmQgbm90IGRlbGl2ZXIgdGhl IHRoZSByZWdpc3RyYXRpb24vcm9vdC4gVGhhbiB0aGUgVUENCm1heSBjaG9zZSBhIGRpZmZlcmVu dCBQUywgb3IgYWdncmVnYXRlLg0KDQpPcjogdGVybXMgb2Ygc2VydmljZSBhbmQgYWJ1c2UgZGV0 ZWN0aW9uIG9uIFBTLg0KDQpUaGVyZSB3YXMgYSB0aHJlYWQgYWJvdXQgUFMgcmV0dXJuaW5nIGEg VVJMIHRoYXQgbWF5IHJlcXVpcmUgYWRkaXRpb25hbCB1c2VyIGludGVyYWN0aW9uIHdoZW4gdGhl IFVBIHJlZ2lzdGVycyB3aXRoIHRoZSBQUywNCmFuZCBtYXkgaGF2ZSBzZXBhcmF0ZSByZWxhdGlv biAoIGxpa2UgU2V0dXAgV2l6YXJkIGluIGFuZHJvaWQgKS4gRm9yIGV4YW1wbGUgR0NNIGF0dGVt cHRzIHRvIGRldGVybWluZSBkZXZpY2UgdHlwZSwgaWYgaXQgaXMgcm9vdGVkLCBldGMuDQoNCkkg ZG9uJ3QgdGhpbmsgdGhlIGV4cGVjdGF0aW9uIGlzIHRoYXQgYSBQUyBNVVNUIGFjY2VwdCBhcmJp dHJhcnkgVUFzLCBmcmVlIGFuZCB3aXRob3V0IGFueSBjaGVja3Mgb3IgcnVsZXMuDQoNCkknbSBh c3NvY2lhdGluZyBvbmUgaDIgY29ubmVjdGlvbiBhcyBiZWluZyBvbmUgVUEsIGFuZCB0cmVhdGlu ZyB0aGUgZmlyc3QgU3Vic2NyaWJlIG9wZXJhdGlvbiwgb3IgdGhlIGZpcnN0IFJlY2VpdmUgUHVz aCBNZXNzYWdlcyBvcGVyYXRpb24gYXMgdGhlIHJlZ2lzdHJhdGlvbi4gQWxzbywgSSBhbSBwZXJo YXBzIG1pc3JlYWRpbmcgdGhlIHNwZWMgaW4gd2hpY2ggVVJMIGlzIGdpdmVuIG91dCB0byB3aG9t LCBub3cgdGhhdCBJIHRoaW5rIGFib3V0IGl0LiBJbiBTZWMgMywgdGhlIFN1YnNjcmliZSByZXNw b25zZSBpcyBzdWNoOg0KDQoNCkhUVFAvMS4xIDIwMSBDcmVhdGVkDQpEYXRlOiBUaHUsIDExIERl YyAyMDE0IDIzOjU2OjUyIEdNVA0KTGluazogPC9wL0p6TFEzcmFaSmZGQlIwYXF2T01zTHJ0NTR3 NHJKVXNWPjsNCiAgICAgICAgcmVsPSJ1cm46aWV0ZjpwYXJhbXM6cHVzaCINCkxpbms6IDwvcmVj ZWlwdHMveGpURzc5STNWdXB0TldTMERzRnU0aWhUOTdhRTZVUUo+Ow0KICAgICAgICByZWw9InVy bjppZXRmOnBhcmFtczpwdXNoOnJlY2VpcHQiDQpMb2NhdGlvbjogaHR0cHM6Ly9wdXNoLmV4YW1w bGUubmV0L3MvTEJoaHcwT29oTy1XbDRPaTk3MVVHc0I3c2RRR1VpYngNCkNhY2hlLUNvbnRyb2w6 IG1heC1hZ2U6ODY0MDAwLCBwcml2YXRlDQoNCk15IHRob3VnaHQgd2FzIHRoYXQgdGhlIExvY2F0 aW9uIGxpbmsgaXMgdGhlIG9uZSBnaXZlbiB0byB0aGUgQXBwU2VydmVycywgYW5kIHRoZSB1cm46 aWV0ZjpwYXJhbXM6cHVzaCBsaW5rIGlzIHRoZSAncHJpdmF0ZSBVUkwnIHRoYXQgdGhlIFVBIHVz ZXMgdG8gcmVjZWl2ZSBwdXNoIG1lc3NhZ2VzLiBUaGlzIHdheSwgYWZ0ZXIgdGhlIGluaXRpYWwg U3Vic2NyaWJlLCB0aGUgUFMgaGFzIGFzc29jaWF0ZWQgdGhhdCBoMiBjb25uZWN0aW9uIHdpdGgg dGhlIHByaXZhdGUgVVJMLCBhbmQgbmV3IFN1YnNjcmliZSByZXF1ZXN0cyB3aWxsIHJldHVybiBu ZXcgTG9jYXRpb24gbGlua3MgdG8gZ2l2ZSB0byB0aGUgQXBwU2VydmVyLiBJdCBhbHNvIG1lYW5z IHRoZSBVQSB3b3VsZCBuZWVkIHRvIHN0b3JlIHRoZSBMb2NhdGlvbiBmb3IgZWFjaCBTdWJzY3Jp YmUsIHNpbmNlIHRoZSBwcml2YXRlIFVSTCB3b3VsZCBiZSB1bmNoYW5naW5nIGZvciBhbGwgbGF0 ZXIgU3Vic2NyaWJlIHJlcXVlc3RzLg0KDQpPbiByZWNvbm5lY3QsIHJlY2VpdmluZyBwdXNoIG1l c3NhZ2VzIGJ5IGhpdHRpbmcgdGhlIHByaXZhdGUgVVJMIHdvdWxkIHRoZW4gYXNzb2NpYXRlIHRo ZSBoMiBjb25uZWN0aW9uIGFnYWluLCBhY3RpbmcgYXMgdGhlIHJlZ2lzdHJhdGlvbi4NCg0KSWYg YSBVQSB3YW50cyB0byBvcGVyYXRlIGluZGVwZW5kZW50IGJhdGNoZXMgb2Ygc3Vic2NyaXB0aW9u cywgYXMgdGhlIElvVCB1c2UtY2FzZSBwcmV2aW91c2x5IGNpdGVkLCBpdCBtdXN0IHVzZSBlbnRp cmVseSBzZXBhcmF0ZSBoMiBjb25uZWN0aW9ucyBmb3IgZWFjaCBiYXRjaC4NCg0KVGhlIHNwZWMg aW5jbHVkZXMgYSBMb2NhdGlvbiB3aXRob3V0IGlkZW50aWZ5aW5nIGl0cyBhY3R1YWwgdXNlLCBh cyBteSByZWFkaW5nIG9mIGl0IHNlZW1zIHVuY2xlYXIgb24gaWYgdGhlIExpbmsgaXMgdGhlIG9u ZSBnaXZlbiB0byB0aGUgQXBwU2VydmVyLCBvciBpZiBpdHMgdGhlIExvY2F0aW9uLg0KDQpUaGlz IHByZXN1bWVzIHRoYXQgdGhlcmUgaXMgbm8gaDIgcHJveHlpbmcgc3VjaCB0aGF0IGluZGl2aWR1 YWwgcmVxdWVzdHMgb3ZlciB0aGUgc2FtZSBjb25uZWN0aW9uIG1pZ2h0IGJlIG9uIGJlaGFsZiBv ZiBkaWZmZXJlbnQgVUEncy4gKEkgcmVhbGx5IHJlYWxseSBkb24ndCBsaWtlIHRoZSB0aG91Z2h0 IG9mIGFuIGgyIHByb3h5IG9mIHRoaXMgbmF0dXJlLCBiZWNhdXNlIGl0IG1lYW5zIGl0IGNvdWxk IGxpZSBhYm91dCB3aGV0aGVyIGEgY2xpZW50IGlzIHN0aWxsIGFjdHVhbGx5ICdhbGl2ZScgdG8g cGluZyBmcmFtZXMsIGFuZCB0aGF0J3MgZ2l2ZW4gdXMgZW5vdWdoIGdyaWVmIHdpdGggbW9iaWxl IFRDUCBwcm94aWVzKS4NCg0KSW4gdGhpcyBtYW5uZXIsIHRoZSBQUyBjb3VsZCBjaG9vc2Ugd2hl dGhlciB0byBnaXZlIHRoZSBzYW1lIHByaXZhdGUgVVJMIGJhY2sgZm9yIGFsbCBTdWJzY3JpYmUg cmVxdWVzdHMgb3ZlciB0aGUgc2FtZSBjb25uZWN0aW9uLCBvciBub3QuIFRoZSBhZGRpdGlvbmFs IHJlcXVpcmVtZW50cyBvbiB0aGUgVUE6DQotIEl0IG11c3Qgc3RvcmUgdGhlIExvY2F0aW9uLCBz aW5jZSB0aGF0J3MgdGhlIGd1YXJhbnRlZWQgdW5pcXVlIHBhcnQNCi0gSWYgaXQgZ2V0cyB0aGUg c2FtZSBwcml2YXRlIFVSTCBiYWNrLCBpdCBzaG91bGQgb25seSB1c2UgdGhlIFJlY2VpdmUgb3Bl cmF0aW9uIG9uY2UsIGFuZCByZWFsaXplIGFsbCBuZXcgcHVzaCBtZXNzYWdlcyB3aWxsIGNvbWUg b3ZlciB0aGUgZXhpc3RpbmcgR0VUDQotIE9uIHJlY29ubmVjdCwgaXQgTVVTVCBzZW5kIHRoZSBS ZWNlaXZlIG9wZXJhdGlvbiBiZWZvcmUgYW55IG5ldyBTdWJzY3JpYmUgb3BlcmF0aW9ucyAoc2lu Y2UgdGhhdCdzIHRyZWF0ZWQgYXMgJ3JlZ2lzdHJhdGlvbicgb24gcmVjb25uZWN0KQ0KDQpUaGlz IHdheSBhIFBTIGdldHMgdG8gY2hvb3NlLCBhbmQgdGhlIGFzc29jaWF0aW5nIGxpbmsgaXMgdGhl IHB1c2ggbGluayBpdHNlbGYuIElmIHRoZSB0aG91Z2h0IHdhcyB0aGF0IHRoZSBwdXNoIExpbmsg aXMgdGhlIG9uZSBzZW50IHRvIEFwcFNlcnZlcnMsIHRoZW4gc29tZSBvZiB0aGlzIHdpbGwgbmVl ZCBhIGJpdCBvZiBjaGFuZ2luZyBvZiBjb3Vyc2UuDQoNCg0KDQpJIHRoaW5rIHRoZSBQUyBzaG91 bGQvbXVzdCBzdXBwb3J0IGl0IGJ1dCBpdCB3b3VsZCBiZSB0aGUgY2xpZW50L1VB4oCZcyBkZWNp c2lvbiB0byBhZ2dyZWdhdGUuIFdlIGNhbiBwdXQgbGFuZ3VhZ2UgdG8g4oCcc3Ryb25nbHkgcmVj b21tZW5k4oCdIHRoZSBjbGllbnQvVUEgdG8gYWdncmVnYXRlIGJ1dCBpdCB3b3VsZCBzdGlsbCBi ZSB0aGUgY2xpZW504oCZcyBkZWNpc2lvbiB0byBpbmNsdWRlIHRoZSBpbml0aWFsIHN1YnNjcmlw dGlvbiB3aGVuIG1ha2luZyBzdWJzZXF1ZW50IHN1YnNjcmlwdGlvbiByZXF1ZXN0cy4NCg0KDQpJ ZiB3ZSBhZ3JlZSB0aGF0IGEgcHVzaCBwcm92aWRlciBtYXkgcmVxdWlyZSAnYWdncmVnYXRpb24n IC0gYWxsIHN1YnNjcmlwdGlvbnMgZnJvbSBhIGRldmljZSwgd2hlbiBjb25uZWN0aW5nDQp0byBz dWNoIGEgcHJvdmlkZXIsIHdpbGwgbmVlZCB0byBoYXZlIHNvbWV0aGluZyBpbiBjb21tb24sIHRv IGFsbG93IHRoZSBhZ2dyZWdhdGlvbi4gVGhlIG9yaWdpbmFsDQogInJlZ2lzdHJhdGlvbiArIHN1 YnNjcmlwdGlvbiIgZG9lcyBpdCBieSBoYXZpbmcgYSBmaXJzdCBzdGVwIHdoZXJlIGEgZGV2aWNl IGdldHMgdGhlIGNvbW1vbiBlbGVtZW50Lg0KSXQgY2FuIGJlIHNpbXBsaWZpZWQgYnkgZGVmaW5p bmcgdGhlICdyZWdpc3RyYXRpb24nIGFzIGEgcmVndWxhciBzdWJzY3JpcHRpb24sIGFuZCBhbGxv d2luZyBlYWNoIGFwcCB0bw0KIGhhdmUgYSAnY2hpbGQnIHN1YnNjcmlwdGlvbi4gVGhpcyB3b3Jr cyBuaWNlbHkgaWYgYSBVQSBzdXBwb3J0cyBwcm9maWxlcy9tdWx0aS11c2VyIGZvciBleGFtcGxl IC0gYW5kIG1heQ0KYmUgZXh0ZW5kZWQgbGF0ZXIgZm9yIG1vcmUgY29tcGxpY2F0ZWQgY2FzZXMs IHdoZXJlIGEgVUEgYWN0cyBhcyBhIHByb3h5IGZvciBvdGhlciBVQXMgKCBmb3IgZXhhbXBsZQ0K YSB3ZWFyYWJsZSBkZXZpY2UgcGFpcmVkIG92ZXIgQlQgKS4NCg0KRFQ+PiBJIHRoaW5rIHdpdGhp biB0aGUgY29udGV4dCBvZiB0aGUgZmFjdCB0aGF0IGEgY2xpZW50IGRvZXMgd2FudCB0byDigJxh Z2dyZWdhdGXigJ0sIGFsbCBvZiB0aGUgYWJvdmUgaXMgZG9hYmxlLiBIb3dldmVyIGFzIEkgbWVu dGlvbmVkIGFib3ZlLCBpZiBhIGNsaWVudCBkb2VzIG5vdCBzZW5kIHRoZSDigJxwYXJlbnQgc3Vi c2NyaXB0aW9u4oCdIGluZm8gaW4gdGhlIHN1YnNlcXVlbnQgc3Vic2NyaXB0aW9uIHJlcXVlc3Rz LCB0aGVyZeKAmXMgbm8gZWFzeSB3YXkgZm9yIGEgUFMgdG8gZm9yY2UgYWdncmVnYXRpb24uDQoN Ckkgd291bGRuJ3QgYmUgdmVyeSB3b3JyaWVkIGFib3V0IGEgc21hbGwgcGVyY2VudGFnZSBvZiBk ZXZpY2VzIG5vdCBhZ2dyZWdhdGluZyAtIGFuZCBhbnl0aGluZyBsYXJnZSBpcyB1c3VhbGx5IGRl dGVjdGFibGUuDQoNCg0KQ29zdGluDQoNCg0KVGhlIHN1YnNjcmlwdGlvbiBBUEkgc2hvdWxkIGFs bG93IGEgd2F5IHRvIGNyZWF0ZSAnbGlua3MnIGJldHdlZW4gc3Vic2NyaXB0aW9ucy4gV2UgZG8g bmVlZCB0bw0KZmluaXNoIHRoZSBzZXBhcmF0ZSBkaXNjdXNzaW9uIG9uIHNlbmRlciBhdXRoZW50 aWNhdGlvbiBhbmQgcmVnaXN0cmF0aW9uIC0gYnV0IGFzc3VtaW5nIGEgcHVzaCBzZXJ2aWNlDQpy ZXF1aXJlcyBzZW5kZXIgYXV0aGVudGljYXRpb24sIHRoaXMgaXMgYW5vdGhlciAnbGluaycgYmV0 d2VlbiB0aGUgYXBwIHN1YnNjcmlwdGlvbiBhbmQgdGhlIHNlcnZlciBpZCAoDQp3aGljaCBjYW4g YmUgYW5vdGhlciBjYXBhYmlsaXR5IFVSTCBvciBzdWJzY3JpcHRpb24gKS4NCg0KRFQ+PiBZZXMs IEkgYmVsaWV2ZSB0aGF0IHNob3VsZCBiZSBkb2FibGUgd2l0aCB0aGUgaWRlYSBoZXJlLg0KDQoN CkkgZG9uJ3QgdGhpbmsgaXQncyBhIHByb2JsZW0gaWYgdGhlICdub24tYWdncmVnYXRlZCcgbW9k ZWwgLSB3aGVyZSBub3RoaW5nIGlzIHNoYXJlZCAtIGlzIGRlZmluZWQgZXZlbiBhcyBkZWZhdWx0 LA0KYW5kIHNvbWUgcHVzaCBwcm92aWRlcnMgbWF5IGNob3NlIHRvIHN1cHBvcnQgYm90aCwgb3Ig b25seSBvbmUgbW9kZWwsIGRlcGVuZGluZyBvbiB0aGVpciBzY2FsZSBhbmQgY29zdHMNCg0KQ29z dGluDQoNCk9uIFR1ZSwgSnVsIDIxLCAyMDE1IGF0IDk6MjYgQU0sIEJlbmphbWluIEJhbmdlcnQg PGJiYW5nZXJ0QG1vemlsbGEuY29tPG1haWx0bzpiYmFuZ2VydEBtb3ppbGxhLmNvbT4+IHdyb3Rl Og0KTXkgcHJlZmVyZW5jZSB3b3VsZCBiZSBmb3IgdGhlIHNlcnZlciB0byBiZSBhYmxlIHRvIHJl cXVpcmUgdGhpcywgcmF0aGVyIHRoYW4gbGVhdmluZyBpdCB1cCB0byB0aGUgY2xpZW50LiBJZiBh IHNlcnZlciBkb2Vzbid0IHdhbnQgdG8gZXhwZW5kIHRoZSBoZWF2eSByZXNvdXJjZSBjb3N0IG9m IHRyZWF0aW5nIGV2ZXJ5IHNpbmdsZSBzdWJzY3JpcHRpb24gYXMgaXRzIG93biBVUkwsIHRoZXJl IHNob3VsZCBiZSBhIHdheSBmb3IgdGhlIHNlcnZlciB0byBpbmRpY2F0ZSB0aGF0IGluIGl0cyBz dWJzY3JpcHRpb24gcmVzcG9uc2UuDQoNCkZvciBhbiBJb1QgdXNlLWNhc2UsIHdoZXJlIGEgY2xp ZW50IG1pZ2h0IHdhbnQgZGlmZmVyZW50IHNldHMgb2Ygc3Vic2NyaXB0aW9ucyBlbnRpcmVseSwg YW5kIHRvIG9ubHkgY2hlY2sgb25lIGdyb3VwIG9mIHRoZW0sIGl0IGNvdWxkIG9wZW4gYSBzZXBh cmF0ZSBoMiBjb25uZWN0aW9uIHRvIHJldHJpZXZlIHRoYXQgc2V0Lg0KDQpPbiBNb24sIEp1bCAy MCwgMjAxNSBhdCAyOjQxIFBNLCBEYXJzaGFrIFRoYWtvcmUgPGQudGhha29yZUBjYWJsZWxhYnMu Y29tPG1haWx0bzpkLnRoYWtvcmVAY2FibGVsYWJzLmNvbT4+IHdyb3RlOg0KDQpJdCBzZWVtcyBs aWtlIHdlIGRvIHdhbnQgc29tZSBtZWNoYW5pc20gdGhhdCBhbGxvd3MgYSBjbGllbnQgdG8gcmV0 cmlldmUNCm5vdGlmaWNhdGlvbnMgZm9yIGFsbCBzdWJzY3JpcHRpb25zIHdpdGggYSBzaW5nbGUg ZmV0Y2guIEZvciBJb1QgYmFzZWQgdXNlDQpjYXNlcyBhbHNvIHRoaXMgaXMgZGVzaXJhYmxlLiBJ IGd1ZXNzIHRoaXMga2VlcHMgZ29pbmcgYmFjayB0byB0aGUNCmFnZ3JlZ2F0aW9uLXZzLWRpc2Fn Z3JlZ2F0aW9uIGRpc2N1c3Npb24uIEhvd2V2ZXIgScK5bSB3b25kZXJpbmcgaWYgaXRzDQpwb3Nz aWJsZSB0byBkZWZpbmUvY3JlYXRlIGEgc29ydCBvZiDCs2FnZ3JlZ2F0aW9uLW9uLWRlbWFuZMKy IG1vZGUgd2l0aCB0aGUNCmRlZmF1bHQgYmVpbmcgdGhlIGN1cnJlbnQgwrNkaXNhZ2dyZWdhdGlv bsKyIG1vZGUuDQoNCkZvciBleGFtcGxlLCBvbmNlIGEgY2xpZW50L1VBIGhhcyBzdWJzY3JpYmVk IGZvciB0aGUgZmlyc3QgdGltZSBhbmQgaG9sZHMNCjEgc3Vic2NyaXB0aW9uLCB3aGVuIGl0IHdh bnRzIHRvIGNyZWF0ZSBzdWJzZXF1ZW50IHN1YnNjcmlwdGlvbnMsIGl0IGNhbg0KaW5jbHVkZSB0 aGUgZmlyc3Qgc3Vic2NyaXB0aW9uIGluIHRoZSByZXF1ZXN0Og0KDQpQT1NUIC9zdWJzY3JpYmUv IEhUVFAvMS4xDQpIT1NUOiBwdXNoLmV4YW1wbGUubmV0PGh0dHA6Ly9wdXNoLmV4YW1wbGUubmV0 Pg0KTGluazogPC9zL0xCaGh3ME9vaE8tV2w0T2k5NzFVR3NCN3NkUUdVaWJ4PjsNCnJlbD3Cs3Vy bjppZXRmOnBhcmFtczpwdXNoOnN1YmNyaWJlwrIgKEnCuW0gbm90IHN1cmUgaWYgaXRzIG9rIHRv IHVzZSBMaW5rDQpoZWFkZXIgaW4gYSByZXF1ZXN0LCBpZiBub3Qgd2UgbmVlZCB0byBmaW5kIHNv bWV0aGluZyBtb3JlIHN1aXRhYmxlKQ0KDQpXaGVuIGEgUFMgcHJvY2Vzc2VzIHRoaXMgcmVxdWVz dCwgaXQgY2FuIGFzc29jaWF0ZSB0aGUgbmV3IHN1YnNjcmlwdGlvbg0Kd2l0aCB0aGUgb25lIHBy b3ZpZGVkLiAoSSB0aGluayB0aGUgYWRkaXRpb25hbCBkYXRhIHN0b3JlZCBieSB0aGUgUFMgdG8N CmFjaGlldmUgdGhpcyBzaG91bGQgYmUgbWluaW1hbCkuIFRoZSByZXNwb25zZSB3b3VsZCBjb250 YWluIHRoZSBuZXcNCnN1YnNjcmlwdGlvbiBpbmZvIGFzIGN1cnJlbnRseSBkZWZpbmVkIChhbmQg bWF5YmUgc29tZXRoaW5nIGFkZGl0aW9uYWwgdG8NCmluZGljYXRlIHRoYXQgdGhlIG5ldyBzdWJz Y3JpcHRpb24gaXMgdGllZCB0byB0aGUgb25lIGluIHRoZSByZXF1ZXN0KQ0KDQpXaGVuIHJlY2Vp dmluZyBQVVNIIG1lc3NhZ2VzLCBhIGNsaWVudC9VQSBjYW4gbWFrZSBhIHNpbmdsZSBHRVQgcmVx dWVzdCB0bw0KdGhlIHByaW1hcnkgc3Vic2NyaXB0aW9uIHJlc291cmNlIGFuZCB0aGUgc2VydmVy IHdpbGwgc2VuZCBwdXNoDQpub3RpZmljYXRpb25zIGZvciBhbGwgc3Vic2NyaXB0aW9ucyBhc3Nv Y2lhdGVkIHdpdGggdGhlIHByaW1hcnkNCnN1YnNjcmlwdGlvbi4NCg0KRm9yIGV4YW1wbGUsIHRo ZSByZXF1ZXN0IHdvdWxkIGJlDQoNCkhFQURFUlMgICAgICAgICBbc3RyZWFtIDddICtFSERfU1RS RUFNICtFTkRfSEVBREVSUw0KICA6bWV0aG9kICAgICAgID0gR0VUDQogIDpwYXRoICAgICAgICAg PSAvcy9MQmhodzBPb2hPLVdsNE9pOTcxVUdzQjdzZFFHVWlieA0KICA6YXV0aG9yaXR5ICAgID0g cHVzaC5leGFtcGxlLm5ldDxodHRwOi8vcHVzaC5leGFtcGxlLm5ldD4NCg0KQW5kIHRoZSBjb3Jy ZXNwb25kaW5nIHJlc3BvbnNlIHdvdWxkIGJlDQoNClBVU0hfUFJPTUlTRSAgICBbc3RyZWFtIDc7 IHByb21pc2VkIHN0cmVhbSA0XSArRU5EX0hFQURFUlMNCiAgOm1ldGhvZCAgICAgICA9IEdFVA0K ICA6cGF0aCAgICAgICAgID0gL2QvcURJWUhOY2ZBSVBQXzVJVHZVUnItZDZCR3RZblRSbmsNCiAg OmF1dGhvcml0eSAgICA9IHB1c2guZXhhbXBsZS5uZXQ8aHR0cDovL3B1c2guZXhhbXBsZS5uZXQ+ DQoNCkhFQURFUlMgICAgICAgICBbc3RyZWFtIDRdICtFTkRfSEVBREVSUw0KICA6c3RhdHVzICAg ICAgID0gMjAwDQogIOKAueKAuU9USEVSIEhFQURFUlMg4oC54oC5DQogIDpjb250ZW50LWxvYyAg PSAvcy9MQmhodzBPb2hPLVdsNE9pOTcxVUdzQjdzZFFHVWlieA0KDQpEQVRBICAgICAgICAgICAg W3N0cmVhbSA0XSArRU5EX1NUUkVBTQ0KICAgICBpQ2hZdUkzak16dDNpcjIwUDhyX2pnUlItZFN1 TjE4Mng3aUINCg0KDQpQVVNIX1BST01JU0UgICAgW3N0cmVhbSA3OyBwcm9taXNlZCBzdHJlYW0g Nl0gK0VORF9IRUFERVJTDQogIDptZXRob2QgICAgICAgICAgICAgICA9IEdFVA0KICA6cGF0aCAg ICAgICAgICAgICAgICAgPSAvZC9nanVOSlRZdVpYa3l5bE9PdGpmQUVvNmt0UkhDQUR1aQ0KICA6 YXV0aG9yaXR5ICAgICAgICAgICAgPSBwdXNoLmV4YW1wbGUubmV0PGh0dHA6Ly9wdXNoLmV4YW1w bGUubmV0Pg0KDQpIRUFERVJTICAgICAgICAgW3N0cmVhbSA2XSArRU5EX0hFQURFUlMNCiAgOnN0 YXR1cyAgICAgICA9IDIwMA0KICDigLnigLlPVEhFUiBIRUFERVJTIOKAueKAuQ0KICA6Y29udGVu dC1sb2MgID0gL3MvaEowalcxRWxDamhqZnd3aDRrVFF3N3JFWUs0UXlGRlcNCg0KREFUQSAgICAg ICAgICAgIFtzdHJlYW0gNl0gK0VORF9TVFJFQU0NCntlbmNvZGVkL2VuY3J5cHRlZC1ub3RpZmlj YXRpb24tbWVzc2FnZX0NCg0KDQrigLnigLkgYWRkaXRpb25hbCBQVVNIIG1lc3NhZ2VzIGZvciBv dGhlciBzdWJzY3JpcHRpb25zIOKAueKAuQ0KDQoNCg0KSW4gdGhlIGFib3ZlIGV4YW1wbGUsIHRo ZSByZXNwb25zZXMgY2FuIGluY2x1ZGUgYSBDb250ZW50LUxvY2F0aW9uIChvcg0Kc29tZSBvdGhl ciBhcHByb3ByaWF0ZSkgaGVhZGVyIHRvIGluZGljYXRlIHRoZSBhc3NvY2lhdGVkIHN1YnNjcmlw dGlvbiBmb3INCnRoZSBub3RpZmljYXRpb24gbWVzc2FnZS4gVGhpcyB3b3VsZCBhbGxvdyB0aGUg Y2xpZW50L1VBIHRvIHNlbmQganVzdCBvbmUNCkdFVCByZXF1ZXN0IHRvIHJldHJpZXZlIChhbmQg a2VlcCByZWNlaXZpbmcpIG5vdGlmaWNhdGlvbnMgb24gYWxsIGl0cw0KYWN0aXZlIHN1YnNjcmlw dGlvbnMuIEEgY2xpZW50L1VBIG1heSBldmVuIGNob29zZSB0byBrZWVwIGNlcnRhaW4NCnN1YnNj cmlwdGlvbnMgc2VwYXJhdGUgYW5kIGdyb3VwIG9ubHkgYSBzdWJzZXQgb2YgdGhlbSAodGhpcyB3 b3VsZCBiZQ0KdXNlZnVsIGluIElvVCBsaWtlIGNhc2VzKQ0KDQoNCkRhcnNoYWsNCg0KDQoNCg0K T24gNy8yMC8xNSwgMTA6MzEgQU0sICJXZWJwdXNoIG9uIGJlaGFsZiBvZiBNYXJ0aW4gVGhvbXNv biINCjx3ZWJwdXNoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOndlYnB1c2gtYm91bmNlc0BpZXRm Lm9yZz4gb24gYmVoYWxmIG9mIG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTxtYWlsdG86bWFydGlu LnRob21zb25AZ21haWwuY29tPj4gd3JvdGU6DQoNCj5PbiAyMCBKdWx5IDIwMTUgYXQgMDk6MjEs IEJlbmphbWluIEJhbmdlcnQgPGJiYW5nZXJ0QG1vemlsbGEuY29tPG1haWx0bzpiYmFuZ2VydEBt b3ppbGxhLmNvbT4+IHdyb3RlOg0KPj4gV2hhdCdzIHRoZSB1c2UtY2FzZSBvZiBhIGNsaWVudCBw b2xsaW5nIG92ZXIgYSBsb25nLWxpdmVkIGNvbm5lY3Rpb24NCj4NCj5UaGUgdXNlIGNhc2UgaXMg Zm9yIGEgZGV2aWNlIHRoYXQgaXMgb25seSBwZXJpb2RpY2FsbHkgb25saW5lIChhDQo+Y29uc3Ry YWluZWQgZGV2aWNlKSB0aGF0IHdhbnRzIHRvIGNoZWNrIGluLCB0aGVuIGltbWVkaWF0ZWx5IGdv DQo+b2ZmbGluZSBhZ2Fpbi4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPldlYnB1c2ggbWFpbGluZyBsaXN0DQo+V2VicHVzaEBpZXRmLm9yZzxt YWlsdG86V2VicHVzaEBpZXRmLm9yZz4NCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3dlYnB1c2gNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCldlYnB1c2ggbWFpbGluZyBsaXN0DQpXZWJwdXNoQGlldGYub3JnPG1haWx0bzpX ZWJwdXNoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby93 ZWJwdXNoDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCldlYnB1c2ggbWFpbGluZyBsaXN0DQpXZWJwdXNoQGlldGYub3JnPG1haWx0bzpXZWJwdXNo QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby93ZWJwdXNo DQoNCg0KDQoNCg== --_000_D1D5684C71BCdthakorecablelabscom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4mbmJzcDtJIHRo aW5rIHlvdSBoYXZlIGl0IGJhY2t3YXJkcyAobWF5YmUgd2UgbmVlZCB0byBiZSBtb3JlIGV4cGxp Y2l0IGluIHRoZSBzcGVjKS4gVGhlIExvY2F0aW9uIGxpbmsgaXMgdGhlIOKAnHByaXZhdGXigJ0g bGluayB0aGF0IHRoZSBVQSBob2xkcy4gVGhhdOKAmXMgdGhlIGxpbmsgdG8gd2hpY2ggdGhlIFVB L2NsaWVudCBpcyBnb2luZyB0byBtYWtlIHRoZSByZXF1ZXN0IHRvIGZvciBnZXR0aW5nIHRoZSBu b3RpZmljYXRpb25zICZuYnNwOyhTZWN0aW9uIDYNCiBzaG93cyB0aGF0IHRoZSBoMiBHRVQgaXMg YmVpbmcgZG9uZSBieSB0aGUgVUEvY2xpZW50IHRvIHRoZSAmcXVvdDsvcy88c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMy4zMzMzMzMwMTU0NDE5cHg7IHdpZG93czogMTsiPkxCaGh3ME9vaE8tV2w0 T2k5NzFVR3NCN3NkUUdVaWJ4JnF1b3Q7PC9zcGFuPikuIFRoZSDigJx1cm46aWV0ZjpwYXJhbXM6 cHVzaOKAnSBsaW5rIGlzIHRoZSBvbmUgdGhhdCBpcyBkaXN0cmlidXRlZCB0byB0aGUgYXBwbGlj YXRpb24gc2VydmVycyAoYWxvbmcNCiB3aXQgdGhlIC9yZWNlaXB0cy94eHh4KS4gVGhlIGN1cnJl bnQgc3BlYyByZXF1aXJlcyB0aGUgVUEvY2xpZW50IHRvIG1ha2Ugc2VwYXJhdGUgR0VU4oCZcyB0 byB0aGUgVVJJIHByb3ZpZGVkIGluIHRoZSBMb2NhdGlvbiBmaWVsZCAoYWxiZWl0IGl0IGNhbiBi ZSBkb25lIG9uIHRoZSBzYW1lIGgyIGNvbm5lY3Rpb24pLiBCeSBsaW5raW5nIHRoZSBzdWJzY3Jp cHRpb25zIHRvIHRoZSBwcmltYXJ5IHN1YnNjcmlwdGlvbiwgdGhlIFVBL2NsaWVudCBjYW4NCiBt YWtlIGEgc2luZ2xlIGgyIEdFVCByZXF1ZXN0IHRvIHByaW1hcnkgc3Vic2NyaXB0aW9uIFVSSSAo dGhlIG9uZSByZXR1cm5lZCBpbiB0aGUgTG9jYXRpb24gaGVhZGVyIG9mIHRoZSBwcmltYXJ5IHN1 YnNjcmlwdGlvbikgYW5kIGdldCBub3RpZmljYXRpb25zIGZvciBhbGwgc3Vic2VxdWVudCBzdWJz Y3JpcHRpb25zLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdj4NCjxkaXY+T24gNy8yMi8xNSwg MTA6MzAgQU0sICZxdW90O0JlbmphbWluIEJhbmdlcnQmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0 bzpiYmFuZ2VydEBtb3ppbGxhLmNvbSI+YmJhbmdlcnRAbW96aWxsYS5jb208L2E+Jmd0OyB3cm90 ZTo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJNQUNf T1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0 ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4NCjxk aXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYgY2xh c3M9ImdtYWlsX3F1b3RlIj5PbiBXZWQsIEp1bCAyMiwgMjAxNSBhdCA4OjI3IEFNLCBDb3N0aW4g TWFub2xhY2hlIDxzcGFuIGRpcj0ibHRyIj4NCiZsdDs8YSBocmVmPSJtYWlsdG86Y29zdGluQGdt YWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNvc3RpbkBnbWFpbC5jb208L2E+Jmd0Ozwvc3Bhbj4g d3JvdGU6PGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2lu OjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQp O3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPGRpdiBjbGFzcz0iZ21h aWxfZXh0cmEiPjxicj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj48c3BhbiBjbGFzcz0iIj5P biBXZWQsIEp1bCAyMiwgMjAxNSBhdCAxOjI1IEFNLCBEYXJzaGFrIFRoYWtvcmUNCjxzcGFuIGRp cj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmQudGhha29yZUBjYWJsZWxhYnMuY29tIiB0YXJn ZXQ9Il9ibGFuayI+ZC50aGFrb3JlQGNhYmxlbGFicy5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6 PGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAw cHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRp bmctbGVmdDoxZXgiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQ7Y29sb3I6cmdi KDAsMCwwKTtmb250LXNpemU6MTRweDtmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWYiPg0K PGRpdj5Db21tZW50cyBiZWxvdzwvZGl2Pg0KPHNwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNw YW4+DQo8ZGl2Pg0KPGRpdj5PbiA3LzIxLzE1LCA2OjQ4IFBNLCAmcXVvdDtDb3N0aW4gTWFub2xh Y2hlJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Y29zdGluQGdtYWlsLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmNvc3RpbkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJCT1JERVItTEVGVDojYjVjNGRmIDUg c29saWQ7UEFERElORzowIDAgMCA1O01BUkdJTjowIDAgMCA1Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRp diBkaXI9Imx0ciI+SSB0aGluayBvbmUgcXVlc3Rpb24gaXMgd2hvIG1ha2VzIHRoZSBkZWNpc2lv biBpZiBzdWJzY3JwdGlvbnMgYXJlICdhZ2dyZWdhdGVkJyBvciBub3QuIEFuZCB0aGUgb25seSBh bnN3ZXImbmJzcDsNCjxkaXY+SSBrbm93IGlzIHRoZSBwdXNoIHByb3ZpZGVyIC0gc2luY2UgdGhl IHB1c2ggcHJvdmlkZXIgaXMgdGhlIG9uZSBiZWFyaW5nIHRoZSBjb3N0cyBhbmQgZGVmaW5pbmcg dGhlJm5ic3A7PC9kaXY+DQo8ZGl2PnJlcXVpcmVtZW50cyBmb3IgVUFzIHRoYXQgY29ubmVjdCB0 byBpdC4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N Cjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L3NwYW4+DQo8ZGl2PkRUJmd0OyZndDsgQXMg SSBtZW50aW9uZWQgaW4gdGhlIG90aGVyIGVtYWlsIChCZW5qYW1pbuKAmXMgZW1haWwpLCBJ4oCZ bSBub3Qgc3VyZSBob3cgYSBQUyBjYW4gZm9yY2UgYSBVQSB0byBhZ2dyZWdhdGUgKHVubGVzcyB0 aGUgUFMgc29tZWhvdyBpZGVudGlmaWVzIHRoZSBjbGllbnQgYmFzZWQgb24gYXV0aGVudGljYXRp b24vY29va2llL3NvbWV0aGluZy1lbHNlKS4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9zcGFuPg0KPGRpdj5JbiBhZ2dyZWdhdGUgbW9kZWwsIHRo ZXJlIGlzIGEgcmVnaXN0cmF0aW9uIChvciBzdWJzY3JpcHRpb24pIGZvciB0aGUgVUEsIGFuZCBl YWNoIG9yaWdpbi9zZXJ2aWNld29ya2VyIGhhdmUgYSBzdWJzY3JpcHRpb24gYXNzb2NpYXRlZCB3 aXRoIHRoZSBVQS4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZSBQUyBj YW4gc2ltcGx5IHJlamVjdCBzdWJzY3JpcHRpb25zIHRoYXQgZG9uJ3QgaGF2ZSBhbiBhc3NvY2lh dGVkIHBhcmVudCwgYW5kIG5vdCBkZWxpdmVyIHRoZSB0aGUgcmVnaXN0cmF0aW9uL3Jvb3QuIFRo YW4gdGhlIFVBPC9kaXY+DQo8ZGl2Pm1heSBjaG9zZSBhIGRpZmZlcmVudCBQUywgb3IgYWdncmVn YXRlLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+T3I6IHRlcm1zIG9mIHNlcnZpY2Ug YW5kIGFidXNlIGRldGVjdGlvbiBvbiBQUy4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2PlRoZXJlIHdhcyBhIHRocmVhZCBhYm91dCBQUyByZXR1cm5pbmcgYSBVUkwgdGhhdCBt YXkgcmVxdWlyZSBhZGRpdGlvbmFsIHVzZXIgaW50ZXJhY3Rpb24gd2hlbiB0aGUgVUEgcmVnaXN0 ZXJzIHdpdGggdGhlIFBTLDwvZGl2Pg0KPGRpdj5hbmQgbWF5IGhhdmUgc2VwYXJhdGUgcmVsYXRp b24gKCBsaWtlIFNldHVwIFdpemFyZCBpbiBhbmRyb2lkICkuIEZvciBleGFtcGxlIEdDTSBhdHRl bXB0cyB0byBkZXRlcm1pbmUgZGV2aWNlIHR5cGUsIGlmIGl0IGlzIHJvb3RlZCwgZXRjLiZuYnNw OzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSBkb24ndCB0aGluayB0aGUgZXhwZWN0 YXRpb24gaXMgdGhhdCBhIFBTIE1VU1QgYWNjZXB0IGFyYml0cmFyeSBVQXMsIGZyZWUgYW5kIHdp dGhvdXQgYW55IGNoZWNrcyBvciBydWxlcy48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkknbSBhc3NvY2lhdGluZyBv bmUgaDIgY29ubmVjdGlvbiBhcyBiZWluZyBvbmUgVUEsIGFuZCB0cmVhdGluZyB0aGUgZmlyc3Qg U3Vic2NyaWJlIG9wZXJhdGlvbiwgb3IgdGhlIGZpcnN0IFJlY2VpdmUgUHVzaCBNZXNzYWdlcyBv cGVyYXRpb24gYXMgdGhlIHJlZ2lzdHJhdGlvbi4gQWxzbywgSSBhbSBwZXJoYXBzIG1pc3JlYWRp bmcgdGhlIHNwZWMgaW4gd2hpY2ggVVJMIGlzIGdpdmVuIG91dCB0byB3aG9tLCBub3cgdGhhdCBJ IHRoaW5rDQogYWJvdXQgaXQuIEluIFNlYyAzLCB0aGUgU3Vic2NyaWJlIHJlc3BvbnNlIGlzIHN1 Y2g6PGJyPg0KPGJyPg0KPHByZT5IVFRQLzEuMSAyMDEgQ3JlYXRlZA0KRGF0ZTogVGh1LCAxMSBE ZWMgMjAxNCAyMzo1Njo1MiBHTVQNCkxpbms6ICZsdDsvcC9KekxRM3JhWkpmRkJSMGFxdk9Nc0xy dDU0dzRySlVzViZndDs7DQogICAgICAgIHJlbD0mcXVvdDt1cm46aWV0ZjpwYXJhbXM6cHVzaCZx dW90Ow0KTGluazogJmx0Oy9yZWNlaXB0cy94alRHNzlJM1Z1cHROV1MwRHNGdTRpaFQ5N2FFNlVR SiZndDs7DQogICAgICAgIHJlbD0mcXVvdDt1cm46aWV0ZjpwYXJhbXM6cHVzaDpyZWNlaXB0JnF1 b3Q7DQpMb2NhdGlvbjogPGEgaHJlZj0iaHR0cHM6Ly9wdXNoLmV4YW1wbGUubmV0L3MvTEJoaHcw T29oTy1XbDRPaTk3MVVHc0I3c2RRR1VpYngNCkNhY2hlLUNvbnRyb2wiPmh0dHBzOi8vcHVzaC5l eGFtcGxlLm5ldC9zL0xCaGh3ME9vaE8tV2w0T2k5NzFVR3NCN3NkUUdVaWJ4DQpDYWNoZS1Db250 cm9sPC9hPjogbWF4LWFnZTo4NjQwMDAsIHByaXZhdGU8L3ByZT4NCk15IHRob3VnaHQgd2FzIHRo YXQgdGhlIExvY2F0aW9uIGxpbmsgaXMgdGhlIG9uZSBnaXZlbiB0byB0aGUgQXBwU2VydmVycywg YW5kIHRoZSB1cm46aWV0ZjpwYXJhbXM6cHVzaCBsaW5rIGlzIHRoZSAncHJpdmF0ZSBVUkwnIHRo YXQgdGhlIFVBIHVzZXMgdG8gcmVjZWl2ZSBwdXNoIG1lc3NhZ2VzLiBUaGlzIHdheSwgYWZ0ZXIg dGhlIGluaXRpYWwgU3Vic2NyaWJlLCB0aGUgUFMgaGFzIGFzc29jaWF0ZWQgdGhhdCBoMiBjb25u ZWN0aW9uIHdpdGgNCiB0aGUgcHJpdmF0ZSBVUkwsIGFuZCBuZXcgU3Vic2NyaWJlIHJlcXVlc3Rz IHdpbGwgcmV0dXJuIG5ldyBMb2NhdGlvbiBsaW5rcyB0byBnaXZlIHRvIHRoZSBBcHBTZXJ2ZXIu IEl0IGFsc28gbWVhbnMgdGhlIFVBIHdvdWxkIG5lZWQgdG8gc3RvcmUgdGhlIExvY2F0aW9uIGZv ciBlYWNoIFN1YnNjcmliZSwgc2luY2UgdGhlIHByaXZhdGUgVVJMIHdvdWxkIGJlIHVuY2hhbmdp bmcgZm9yIGFsbCBsYXRlciBTdWJzY3JpYmUgcmVxdWVzdHMuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPjxzcGFuIGlk PSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRU UklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7 IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBk aXI9Imx0ciI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9x dW90ZSI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5PbiByZWNvbm5lY3QsIHJlY2VpdmluZyBw dXNoIG1lc3NhZ2VzIGJ5IGhpdHRpbmcgdGhlIHByaXZhdGUgVVJMIHdvdWxkIHRoZW4gYXNzb2Np YXRlIHRoZSBoMiBjb25uZWN0aW9uIGFnYWluLCBhY3RpbmcgYXMgdGhlIHJlZ2lzdHJhdGlvbi48 YnI+DQo8YnI+DQo8L2Rpdj4NCjxkaXY+SWYgYSBVQSB3YW50cyB0byBvcGVyYXRlIGluZGVwZW5k ZW50IGJhdGNoZXMgb2Ygc3Vic2NyaXB0aW9ucywgYXMgdGhlIElvVCB1c2UtY2FzZSBwcmV2aW91 c2x5IGNpdGVkLCBpdCBtdXN0IHVzZSBlbnRpcmVseSBzZXBhcmF0ZSBoMiBjb25uZWN0aW9ucyBm b3IgZWFjaCBiYXRjaC48YnI+DQo8YnI+DQo8L2Rpdj4NCjxkaXY+VGhlIHNwZWMgaW5jbHVkZXMg YSBMb2NhdGlvbiB3aXRob3V0IGlkZW50aWZ5aW5nIGl0cyBhY3R1YWwgdXNlLCBhcyBteSByZWFk aW5nIG9mIGl0IHNlZW1zIHVuY2xlYXIgb24gaWYgdGhlIExpbmsgaXMgdGhlIG9uZSBnaXZlbiB0 byB0aGUgQXBwU2VydmVyLCBvciBpZiBpdHMgdGhlIExvY2F0aW9uLjxicj4NCjxicj4NCjwvZGl2 Pg0KPGRpdj5UaGlzIHByZXN1bWVzIHRoYXQgdGhlcmUgaXMgbm8gaDIgcHJveHlpbmcgc3VjaCB0 aGF0IGluZGl2aWR1YWwgcmVxdWVzdHMgb3ZlciB0aGUgc2FtZSBjb25uZWN0aW9uIG1pZ2h0IGJl IG9uIGJlaGFsZiBvZiBkaWZmZXJlbnQgVUEncy4gKEkgcmVhbGx5IHJlYWxseSBkb24ndCBsaWtl IHRoZSB0aG91Z2h0IG9mIGFuIGgyIHByb3h5IG9mIHRoaXMgbmF0dXJlLCBiZWNhdXNlIGl0IG1l YW5zIGl0IGNvdWxkIGxpZSBhYm91dCB3aGV0aGVyIGENCiBjbGllbnQgaXMgc3RpbGwgYWN0dWFs bHkgJ2FsaXZlJyB0byBwaW5nIGZyYW1lcywgYW5kIHRoYXQncyBnaXZlbiB1cyBlbm91Z2ggZ3Jp ZWYgd2l0aCBtb2JpbGUgVENQIHByb3hpZXMpLjxicj4NCjxicj4NCjwvZGl2Pg0KPGRpdj5JbiB0 aGlzIG1hbm5lciwgdGhlIFBTIGNvdWxkIGNob29zZSB3aGV0aGVyIHRvIGdpdmUgdGhlIHNhbWUg cHJpdmF0ZSBVUkwgYmFjayBmb3IgYWxsIFN1YnNjcmliZSByZXF1ZXN0cyBvdmVyIHRoZSBzYW1l IGNvbm5lY3Rpb24sIG9yIG5vdC4gVGhlIGFkZGl0aW9uYWwgcmVxdWlyZW1lbnRzIG9uIHRoZSBV QTo8YnI+DQotIEl0IG11c3Qgc3RvcmUgdGhlIExvY2F0aW9uLCBzaW5jZSB0aGF0J3MgdGhlIGd1 YXJhbnRlZWQgdW5pcXVlIHBhcnQ8YnI+DQotIElmIGl0IGdldHMgdGhlIHNhbWUgcHJpdmF0ZSBV UkwgYmFjaywgaXQgc2hvdWxkIG9ubHkgdXNlIHRoZSBSZWNlaXZlIG9wZXJhdGlvbiBvbmNlLCBh bmQgcmVhbGl6ZSBhbGwgbmV3IHB1c2ggbWVzc2FnZXMgd2lsbCBjb21lIG92ZXIgdGhlIGV4aXN0 aW5nIEdFVDxicj4NCjwvZGl2Pg0KPGRpdj4tIE9uIHJlY29ubmVjdCwgaXQgTVVTVCBzZW5kIHRo ZSBSZWNlaXZlIG9wZXJhdGlvbiBiZWZvcmUgYW55IG5ldyBTdWJzY3JpYmUgb3BlcmF0aW9ucyAo c2luY2UgdGhhdCdzIHRyZWF0ZWQgYXMgJ3JlZ2lzdHJhdGlvbicgb24gcmVjb25uZWN0KTxicj4N Cjxicj4NCjwvZGl2Pg0KPGRpdj5UaGlzIHdheSBhIFBTIGdldHMgdG8gY2hvb3NlLCBhbmQgdGhl IGFzc29jaWF0aW5nIGxpbmsgaXMgdGhlIHB1c2ggbGluayBpdHNlbGYuIElmIHRoZSB0aG91Z2h0 IHdhcyB0aGF0IHRoZSBwdXNoIExpbmsgaXMgdGhlIG9uZSBzZW50IHRvIEFwcFNlcnZlcnMsIHRo ZW4gc29tZSBvZiB0aGlzIHdpbGwgbmVlZCBhIGJpdCBvZiBjaGFuZ2luZyBvZiBjb3Vyc2UuPGJy Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCiZuYnNwOzwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9Imdt YWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFw eCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBkaXI9Imx0 ciI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+ PHNwYW4gY2xhc3M9IiI+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9Imdt YWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFw eCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBzdHlsZT0i d29yZC13cmFwOmJyZWFrLXdvcmQ7Y29sb3I6cmdiKDAsMCwwKTtmb250LXNpemU6MTRweDtmb250 LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWYiPg0KPGRpdj5JIHRoaW5rIHRoZSBQUyBzaG91bGQv bXVzdCBzdXBwb3J0IGl0IGJ1dCBpdCB3b3VsZCBiZSB0aGUgY2xpZW50L1VB4oCZcyBkZWNpc2lv biB0byBhZ2dyZWdhdGUuIFdlIGNhbiBwdXQgbGFuZ3VhZ2UgdG8g4oCcc3Ryb25nbHkgcmVjb21t ZW5k4oCdIHRoZSBjbGllbnQvVUEgdG8gYWdncmVnYXRlIGJ1dCBpdCB3b3VsZCBzdGlsbCBiZSB0 aGUgY2xpZW504oCZcyBkZWNpc2lvbiB0byBpbmNsdWRlIHRoZSBpbml0aWFsIHN1YnNjcmlwdGlv biB3aGVuIG1ha2luZw0KIHN1YnNlcXVlbnQgc3Vic2NyaXB0aW9uIHJlcXVlc3RzLjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0 eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigy MDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6YnJl YWstd29yZDtjb2xvcjpyZ2IoMCwwLDApO2ZvbnQtc2l6ZToxNHB4O2ZvbnQtZmFtaWx5OkNhbGli cmksc2Fucy1zZXJpZiI+DQo8c3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3Bhbj4NCjxibG9j a3F1b3RlIHN0eWxlPSJCT1JERVItTEVGVDojYjVjNGRmIDUgc29saWQ7UEFERElORzowIDAgMCA1 O01BUkdJTjowIDAgMCA1Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj5JZiB3ZSBhZ3JlZSB0aGF0IGEgcHVzaCBwcm92aWRlciBtYXkgcmVx dWlyZSAnYWdncmVnYXRpb24nIC0gYWxsIHN1YnNjcmlwdGlvbnMgZnJvbSBhIGRldmljZSwgd2hl biBjb25uZWN0aW5nPC9kaXY+DQo8ZGl2PnRvIHN1Y2ggYSBwcm92aWRlciwgd2lsbCBuZWVkIHRv IGhhdmUgc29tZXRoaW5nIGluIGNvbW1vbiwgdG8gYWxsb3cgdGhlIGFnZ3JlZ2F0aW9uLiBUaGUg b3JpZ2luYWw8L2Rpdj4NCjxkaXY+Jm5ic3A7JnF1b3Q7cmVnaXN0cmF0aW9uICYjNDM7IHN1YnNj cmlwdGlvbiZxdW90OyBkb2VzIGl0IGJ5IGhhdmluZyBhIGZpcnN0IHN0ZXAgd2hlcmUgYSBkZXZp Y2UgZ2V0cyB0aGUgY29tbW9uIGVsZW1lbnQuJm5ic3A7PC9kaXY+DQo8ZGl2Pkl0IGNhbiBiZSBz aW1wbGlmaWVkIGJ5IGRlZmluaW5nIHRoZSAncmVnaXN0cmF0aW9uJyBhcyBhIHJlZ3VsYXIgc3Vi c2NyaXB0aW9uLCBhbmQgYWxsb3dpbmcgZWFjaCBhcHAgdG88L2Rpdj4NCjxkaXY+Jm5ic3A7aGF2 ZSBhICdjaGlsZCcgc3Vic2NyaXB0aW9uLiBUaGlzIHdvcmtzIG5pY2VseSBpZiBhIFVBIHN1cHBv cnRzIHByb2ZpbGVzL211bHRpLXVzZXIgZm9yIGV4YW1wbGUgLSBhbmQgbWF5Jm5ic3A7PC9kaXY+ DQo8ZGl2PmJlIGV4dGVuZGVkIGxhdGVyIGZvciBtb3JlIGNvbXBsaWNhdGVkIGNhc2VzLCB3aGVy ZSBhIFVBIGFjdHMgYXMgYSBwcm94eSBmb3Igb3RoZXIgVUFzICggZm9yIGV4YW1wbGUmbmJzcDs8 L2Rpdj4NCjxkaXY+YSB3ZWFyYWJsZSBkZXZpY2UgcGFpcmVkIG92ZXIgQlQgKS4mbmJzcDs8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8L3NwYW4+DQo8ZGl2PkRUJmd0OyZndDsgSSB0aGluayB3aXRoaW4gdGhl IGNvbnRleHQgb2YgdGhlIGZhY3QgdGhhdCBhIGNsaWVudCBkb2VzIHdhbnQgdG8g4oCcYWdncmVn YXRl4oCdLCBhbGwgb2YgdGhlIGFib3ZlIGlzIGRvYWJsZS4gSG93ZXZlciBhcyBJIG1lbnRpb25l ZCBhYm92ZSwgaWYgYSBjbGllbnQgZG9lcyBub3Qgc2VuZCB0aGUg4oCccGFyZW50IHN1YnNjcmlw dGlvbuKAnSBpbmZvIGluIHRoZSBzdWJzZXF1ZW50IHN1YnNjcmlwdGlvbiByZXF1ZXN0cywgdGhl cmXigJlzIG5vIGVhc3kNCiB3YXkgZm9yIGEgUFMgdG8gZm9yY2UgYWdncmVnYXRpb24uJm5ic3A7 PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L3NwYW4+ DQo8ZGl2Pkkgd291bGRuJ3QgYmUgdmVyeSB3b3JyaWVkIGFib3V0IGEgc21hbGwgcGVyY2VudGFn ZSBvZiBkZXZpY2VzIG5vdCBhZ2dyZWdhdGluZyAtIGFuZCBhbnl0aGluZyBsYXJnZSBpcyB1c3Vh bGx5IGRldGVjdGFibGUuPC9kaXY+DQo8c3BhbiBjbGFzcz0iIj48Zm9udCBjb2xvcj0iIzg4ODg4 OCI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Q29zdGluPC9k aXY+DQo8L2ZvbnQ+PC9zcGFuPg0KPGRpdj4NCjxkaXYgY2xhc3M9Img1Ij4NCjxkaXY+Jm5ic3A7 PC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4 IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFk ZGluZy1sZWZ0OjFleCI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZDtjb2xvcjpy Z2IoMCwwLDApO2ZvbnQtc2l6ZToxNHB4O2ZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZiI+ DQo8c3Bhbj4NCjxkaXY+PC9kaXY+DQo8c3Bhbj4NCjxibG9ja3F1b3RlIHN0eWxlPSJCT1JERVIt TEVGVDojYjVjNGRmIDUgc29saWQ7UEFERElORzowIDAgMCA1O01BUkdJTjowIDAgMCA1Ij4NCjxk aXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGUg c3Vic2NyaXB0aW9uIEFQSSBzaG91bGQgYWxsb3cgYSB3YXkgdG8gY3JlYXRlICdsaW5rcycgYmV0 d2VlbiBzdWJzY3JpcHRpb25zLiBXZSBkbyBuZWVkIHRvJm5ic3A7PC9kaXY+DQo8ZGl2PmZpbmlz aCB0aGUgc2VwYXJhdGUgZGlzY3Vzc2lvbiBvbiBzZW5kZXIgYXV0aGVudGljYXRpb24gYW5kIHJl Z2lzdHJhdGlvbiAtIGJ1dCBhc3N1bWluZyBhIHB1c2ggc2VydmljZTwvZGl2Pg0KPGRpdj5yZXF1 aXJlcyBzZW5kZXIgYXV0aGVudGljYXRpb24sIHRoaXMgaXMgYW5vdGhlciAnbGluaycgYmV0d2Vl biB0aGUgYXBwIHN1YnNjcmlwdGlvbiBhbmQgdGhlIHNlcnZlciBpZCAoPC9kaXY+DQo8ZGl2Pndo aWNoIGNhbiBiZSBhbm90aGVyIGNhcGFiaWxpdHkgVVJMIG9yIHN1YnNjcmlwdGlvbiApLiZuYnNw OzwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0K PGRpdj48YnI+DQo8L2Rpdj4NCjwvc3Bhbj4NCjxkaXY+RFQmZ3Q7Jmd0OyBZZXMsIEkgYmVsaWV2 ZSB0aGF0IHNob3VsZCBiZSBkb2FibGUgd2l0aCB0aGUgaWRlYSBoZXJlLiZuYnNwOzwvZGl2Pg0K PHNwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4+DQo8YmxvY2txdW90ZSBzdHlsZT0iQk9S REVSLUxFRlQ6I2I1YzRkZiA1IHNvbGlkO1BBRERJTkc6MCAwIDAgNTtNQVJHSU46MCAwIDAgNSI+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ SSBkb24ndCB0aGluayBpdCdzIGEgcHJvYmxlbSBpZiB0aGUgJ25vbi1hZ2dyZWdhdGVkJyBtb2Rl bCAtIHdoZXJlIG5vdGhpbmcgaXMgc2hhcmVkIC0gaXMgZGVmaW5lZCBldmVuIGFzIGRlZmF1bHQs PC9kaXY+DQo8ZGl2PmFuZCBzb21lIHB1c2ggcHJvdmlkZXJzIG1heSBjaG9zZSB0byBzdXBwb3J0 IGJvdGgsIG9yIG9ubHkgb25lIG1vZGVsLCBkZXBlbmRpbmcgb24gdGhlaXIgc2NhbGUgYW5kIGNv c3RzPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+ PC9zcGFuPjxzcGFuPg0KPGJsb2NrcXVvdGUgc3R5bGU9IkJPUkRFUi1MRUZUOiNiNWM0ZGYgNSBz b2xpZDtQQURESU5HOjAgMCAwIDU7TUFSR0lOOjAgMCAwIDUiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 IGRpcj0ibHRyIj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkNvc3RpbjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+DQo8ZGl2IGNsYXNz PSJnbWFpbF9xdW90ZSI+T24gVHVlLCBKdWwgMjEsIDIwMTUgYXQgOToyNiBBTSwgQmVuamFtaW4g QmFuZ2VydCA8c3BhbiBkaXI9Imx0ciI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOmJiYW5nZXJ0QG1v emlsbGEuY29tIiB0YXJnZXQ9Il9ibGFuayI+YmJhbmdlcnRAbW96aWxsYS5jb208L2E+Jmd0Ozwv c3Bhbj4gd3JvdGU6PGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0i bWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIw NCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2Pk15IHByZWZl cmVuY2Ugd291bGQgYmUgZm9yIHRoZSBzZXJ2ZXIgdG8gYmUgYWJsZSB0byByZXF1aXJlIHRoaXMs IHJhdGhlciB0aGFuIGxlYXZpbmcgaXQgdXAgdG8gdGhlIGNsaWVudC4gSWYgYSBzZXJ2ZXIgZG9l c24ndCB3YW50IHRvIGV4cGVuZCB0aGUgaGVhdnkgcmVzb3VyY2UgY29zdCBvZiB0cmVhdGluZyBl dmVyeSBzaW5nbGUgc3Vic2NyaXB0aW9uIGFzIGl0cyBvd24gVVJMLCB0aGVyZSBzaG91bGQgYmUg YSB3YXkgZm9yIHRoZSBzZXJ2ZXINCiB0byBpbmRpY2F0ZSB0aGF0IGluIGl0cyBzdWJzY3JpcHRp b24gcmVzcG9uc2UuPGJyPg0KPGJyPg0KPC9kaXY+DQpGb3IgYW4gSW9UIHVzZS1jYXNlLCB3aGVy ZSBhIGNsaWVudCBtaWdodCB3YW50IGRpZmZlcmVudCBzZXRzIG9mIHN1YnNjcmlwdGlvbnMgZW50 aXJlbHksIGFuZCB0byBvbmx5IGNoZWNrIG9uZSBncm91cCBvZiB0aGVtLCBpdCBjb3VsZCBvcGVu IGEgc2VwYXJhdGUgaDIgY29ubmVjdGlvbiB0byByZXRyaWV2ZSB0aGF0IHNldC48YnI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90 ZSI+PHNwYW4+T24gTW9uLCBKdWwgMjAsIDIwMTUgYXQgMjo0MSBQTSwgRGFyc2hhayBUaGFrb3Jl IDxzcGFuIGRpcj0ibHRyIj4NCiZsdDs8YSBocmVmPSJtYWlsdG86ZC50aGFrb3JlQGNhYmxlbGFi cy5jb20iIHRhcmdldD0iX2JsYW5rIj5kLnRoYWtvcmVAY2FibGVsYWJzLmNvbTwvYT4mZ3Q7PC9z cGFuPiB3cm90ZTo8YnI+DQo8L3NwYW4+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUi IHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJn YigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+DQo8c3Bhbj48YnI+DQpJdCBzZWVtcyBs aWtlIHdlIGRvIHdhbnQgc29tZSBtZWNoYW5pc20gdGhhdCBhbGxvd3MgYSBjbGllbnQgdG8gcmV0 cmlldmU8YnI+DQpub3RpZmljYXRpb25zIGZvciBhbGwgc3Vic2NyaXB0aW9ucyB3aXRoIGEgc2lu Z2xlIGZldGNoLiBGb3IgSW9UIGJhc2VkIHVzZTxicj4NCmNhc2VzIGFsc28gdGhpcyBpcyBkZXNp cmFibGUuIEkgZ3Vlc3MgdGhpcyBrZWVwcyBnb2luZyBiYWNrIHRvIHRoZTxicj4NCmFnZ3JlZ2F0 aW9uLXZzLWRpc2FnZ3JlZ2F0aW9uIGRpc2N1c3Npb24uIEhvd2V2ZXIgScK5bSB3b25kZXJpbmcg aWYgaXRzPGJyPg0KcG9zc2libGUgdG8gZGVmaW5lL2NyZWF0ZSBhIHNvcnQgb2YgwrNhZ2dyZWdh dGlvbi1vbi1kZW1hbmTCsiBtb2RlIHdpdGggdGhlPGJyPg0KZGVmYXVsdCBiZWluZyB0aGUgY3Vy cmVudCDCs2Rpc2FnZ3JlZ2F0aW9uwrIgbW9kZS48YnI+DQo8YnI+DQpGb3IgZXhhbXBsZSwgb25j ZSBhIGNsaWVudC9VQSBoYXMgc3Vic2NyaWJlZCBmb3IgdGhlIGZpcnN0IHRpbWUgYW5kIGhvbGRz PGJyPg0KMSBzdWJzY3JpcHRpb24sIHdoZW4gaXQgd2FudHMgdG8gY3JlYXRlIHN1YnNlcXVlbnQg c3Vic2NyaXB0aW9ucywgaXQgY2FuPGJyPg0KaW5jbHVkZSB0aGUgZmlyc3Qgc3Vic2NyaXB0aW9u IGluIHRoZSByZXF1ZXN0Ojxicj4NCjxicj4NClBPU1QgL3N1YnNjcmliZS8gSFRUUC8xLjE8YnI+ DQo8L3NwYW4+SE9TVDogPGEgaHJlZj0iaHR0cDovL3B1c2guZXhhbXBsZS5uZXQiIHJlbD0ibm9y ZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPnB1c2guZXhhbXBsZS5uZXQ8L2E+PHNwYW4+PGJyPg0K TGluazogJmx0Oy9zL0xCaGh3ME9vaE8tV2w0T2k5NzFVR3NCN3NkUUdVaWJ4Jmd0Ozs8YnI+DQpy ZWw9wrN1cm46aWV0ZjpwYXJhbXM6cHVzaDpzdWJjcmliZcKyIChJwrltIG5vdCBzdXJlIGlmIGl0 cyBvayB0byB1c2UgTGluazxicj4NCmhlYWRlciBpbiBhIHJlcXVlc3QsIGlmIG5vdCB3ZSBuZWVk IHRvIGZpbmQgc29tZXRoaW5nIG1vcmUgc3VpdGFibGUpPGJyPg0KPGJyPg0KV2hlbiBhIFBTIHBy b2Nlc3NlcyB0aGlzIHJlcXVlc3QsIGl0IGNhbiBhc3NvY2lhdGUgdGhlIG5ldyBzdWJzY3JpcHRp b248YnI+DQp3aXRoIHRoZSBvbmUgcHJvdmlkZWQuIChJIHRoaW5rIHRoZSBhZGRpdGlvbmFsIGRh dGEgc3RvcmVkIGJ5IHRoZSBQUyB0bzxicj4NCmFjaGlldmUgdGhpcyBzaG91bGQgYmUgbWluaW1h bCkuIFRoZSByZXNwb25zZSB3b3VsZCBjb250YWluIHRoZSBuZXc8YnI+DQpzdWJzY3JpcHRpb24g aW5mbyBhcyBjdXJyZW50bHkgZGVmaW5lZCAoYW5kIG1heWJlIHNvbWV0aGluZyBhZGRpdGlvbmFs IHRvPGJyPg0KaW5kaWNhdGUgdGhhdCB0aGUgbmV3IHN1YnNjcmlwdGlvbiBpcyB0aWVkIHRvIHRo ZSBvbmUgaW4gdGhlIHJlcXVlc3QpPGJyPg0KPGJyPg0KV2hlbiByZWNlaXZpbmcgUFVTSCBtZXNz YWdlcywgYSBjbGllbnQvVUEgY2FuIG1ha2UgYSBzaW5nbGUgR0VUIHJlcXVlc3QgdG88YnI+DQp0 aGUgcHJpbWFyeSBzdWJzY3JpcHRpb24gcmVzb3VyY2UgYW5kIHRoZSBzZXJ2ZXIgd2lsbCBzZW5k IHB1c2g8YnI+DQpub3RpZmljYXRpb25zIGZvciBhbGwgc3Vic2NyaXB0aW9ucyBhc3NvY2lhdGVk IHdpdGggdGhlIHByaW1hcnk8YnI+DQpzdWJzY3JpcHRpb24uPGJyPg0KPGJyPg0KRm9yIGV4YW1w bGUsIHRoZSByZXF1ZXN0IHdvdWxkIGJlPGJyPg0KPGJyPg0KSEVBREVSUyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtbc3RyZWFtIDddICYjNDM7RUhEX1NUUkVBTSAmIzQzO0VORF9I RUFERVJTPGJyPg0KJm5ic3A7IDptZXRob2QmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs9IEdF VDxicj4NCiZuYnNwOyA6cGF0aCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs9IC9z L0xCaGh3ME9vaE8tV2w0T2k5NzFVR3NCN3NkUUdVaWJ4PGJyPg0KPC9zcGFuPiZuYnNwOyA6YXV0 aG9yaXR5Jm5ic3A7ICZuYnNwOyA9IDxhIGhyZWY9Imh0dHA6Ly9wdXNoLmV4YW1wbGUubmV0IiBy ZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj4NCnB1c2guZXhhbXBsZS5uZXQ8L2E+PHNw YW4+PGJyPg0KPGJyPg0KQW5kIHRoZSBjb3JyZXNwb25kaW5nIHJlc3BvbnNlIHdvdWxkIGJlPGJy Pg0KPGJyPg0KUFVTSF9QUk9NSVNFJm5ic3A7ICZuYnNwOyBbc3RyZWFtIDc7IHByb21pc2VkIHN0 cmVhbSA0XSAmIzQzO0VORF9IRUFERVJTPGJyPg0KJm5ic3A7IDptZXRob2QmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDs9IEdFVDxicj4NCiZuYnNwOyA6cGF0aCZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDs9IC9kL3FESVlITmNmQUlQUF81SVR2VVJyLWQ2Qkd0WW5UUm5rPGJyPg0K PC9zcGFuPiZuYnNwOyA6YXV0aG9yaXR5Jm5ic3A7ICZuYnNwOyA9IDxhIGhyZWY9Imh0dHA6Ly9w dXNoLmV4YW1wbGUubmV0IiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj4NCnB1c2gu ZXhhbXBsZS5uZXQ8L2E+PHNwYW4+PGJyPg0KPGJyPg0KSEVBREVSUyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtbc3RyZWFtIDRdICYjNDM7RU5EX0hFQURFUlM8YnI+DQombmJzcDsg OnN0YXR1cyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOz0gMjAwPGJyPg0KJm5ic3A7IOKAueKA uU9USEVSIEhFQURFUlMg4oC54oC5PGJyPg0KJm5ic3A7IDpjb250ZW50LWxvYyZuYnNwOyA9IC9z L0xCaGh3ME9vaE8tV2w0T2k5NzFVR3NCN3NkUUdVaWJ4PGJyPg0KPGJyPg0KREFUQSZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFtzdHJlYW0gNF0gJiM0MztFTkRfU1RS RUFNPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDtpQ2hZdUkzak16dDNpcjIwUDhyX2pnUlItZFN1 TjE4Mng3aUI8YnI+DQo8YnI+DQo8YnI+DQpQVVNIX1BST01JU0UmbmJzcDsgJm5ic3A7IFtzdHJl YW0gNzsgcHJvbWlzZWQgc3RyZWFtIDZdICYjNDM7RU5EX0hFQURFUlM8YnI+DQombmJzcDsgOm1l dGhvZCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDs9IEdFVDxicj4NCiZuYnNwOyA6cGF0aCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PSAvZC9nanVOSlRZdVpYa3l5bE9PdGpmQUVv Nmt0UkhDQUR1aTxicj4NCjwvc3Bhbj4mbmJzcDsgOmF1dGhvcml0eSZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ID0gPGEgaHJlZj0iaHR0cDovL3B1c2guZXhhbXBsZS5u ZXQiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPg0KcHVzaC5leGFtcGxlLm5ldDwv YT48c3Bhbj48YnI+DQo8YnI+DQpIRUFERVJTJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO1tzdHJlYW0gNl0gJiM0MztFTkRfSEVBREVSUzxicj4NCiZuYnNwOyA6c3RhdHVzJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7PSAyMDA8YnI+DQombmJzcDsg4oC54oC5T1RIRVIgSEVBREVS UyDigLnigLk8YnI+DQombmJzcDsgOmNvbnRlbnQtbG9jJm5ic3A7ID0gL3MvaEowalcxRWxDamhq Znd3aDRrVFF3N3JFWUs0UXlGRlc8YnI+DQo8YnI+DQpEQVRBJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgW3N0cmVhbSA2XSAmIzQzO0VORF9TVFJFQU08YnI+DQp7ZW5j b2RlZC9lbmNyeXB0ZWQtbm90aWZpY2F0aW9uLW1lc3NhZ2V9PGJyPg0KPGJyPg0KPGJyPg0K4oC5 4oC5IGFkZGl0aW9uYWwgUFVTSCBtZXNzYWdlcyBmb3Igb3RoZXIgc3Vic2NyaXB0aW9ucyDigLni gLk8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpJbiB0aGUgYWJvdmUgZXhhbXBsZSwgdGhlIHJlc3Bv bnNlcyBjYW4gaW5jbHVkZSBhIENvbnRlbnQtTG9jYXRpb24gKG9yPGJyPg0Kc29tZSBvdGhlciBh cHByb3ByaWF0ZSkgaGVhZGVyIHRvIGluZGljYXRlIHRoZSBhc3NvY2lhdGVkIHN1YnNjcmlwdGlv biBmb3I8YnI+DQp0aGUgbm90aWZpY2F0aW9uIG1lc3NhZ2UuIFRoaXMgd291bGQgYWxsb3cgdGhl IGNsaWVudC9VQSB0byBzZW5kIGp1c3Qgb25lPGJyPg0KR0VUIHJlcXVlc3QgdG8gcmV0cmlldmUg KGFuZCBrZWVwIHJlY2VpdmluZykgbm90aWZpY2F0aW9ucyBvbiBhbGwgaXRzPGJyPg0KYWN0aXZl IHN1YnNjcmlwdGlvbnMuIEEgY2xpZW50L1VBIG1heSBldmVuIGNob29zZSB0byBrZWVwIGNlcnRh aW48YnI+DQpzdWJzY3JpcHRpb25zIHNlcGFyYXRlIGFuZCBncm91cCBvbmx5IGEgc3Vic2V0IG9m IHRoZW0gKHRoaXMgd291bGQgYmU8YnI+DQp1c2VmdWwgaW4gSW9UIGxpa2UgY2FzZXMpPGJyPg0K PGJyPg0KPGJyPg0KRGFyc2hhazxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCk9uIDcvMjAv MTUsIDEwOjMxIEFNLCAmcXVvdDtXZWJwdXNoIG9uIGJlaGFsZiBvZiBNYXJ0aW4gVGhvbXNvbiZx dW90Ozxicj4NCjwvc3Bhbj4NCjxkaXY+DQo8ZGl2PiZsdDs8YSBocmVmPSJtYWlsdG86d2VicHVz aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+d2VicHVzaC1ib3VuY2VzQGlldGYu b3JnPC9hPiBvbiBiZWhhbGYgb2YNCjxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFp bC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208L2E+Jmd0OyB3 cm90ZTo8c3Bhbj48YnI+DQo8YnI+DQomZ3Q7T24gMjAgSnVseSAyMDE1IGF0IDA5OjIxLCBCZW5q YW1pbiBCYW5nZXJ0ICZsdDs8YSBocmVmPSJtYWlsdG86YmJhbmdlcnRAbW96aWxsYS5jb20iIHRh cmdldD0iX2JsYW5rIj5iYmFuZ2VydEBtb3ppbGxhLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZn dDsmZ3Q7IFdoYXQncyB0aGUgdXNlLWNhc2Ugb2YgYSBjbGllbnQgcG9sbGluZyBvdmVyIGEgbG9u Zy1saXZlZCBjb25uZWN0aW9uPGJyPg0KJmd0Ozxicj4NCiZndDtUaGUgdXNlIGNhc2UgaXMgZm9y IGEgZGV2aWNlIHRoYXQgaXMgb25seSBwZXJpb2RpY2FsbHkgb25saW5lIChhPGJyPg0KJmd0O2Nv bnN0cmFpbmVkIGRldmljZSkgdGhhdCB3YW50cyB0byBjaGVjayBpbiwgdGhlbiBpbW1lZGlhdGVs eSBnbzxicj4NCiZndDtvZmZsaW5lIGFnYWluLjxicj4NCiZndDs8YnI+DQo8L3NwYW4+PC9kaXY+ DQo8L2Rpdj4NCiZndDtfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCiZndDtXZWJwdXNoIG1haWxpbmcgbGlzdDxicj4NCiZndDs8YSBocmVmPSJtYWls dG86V2VicHVzaEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPldlYnB1c2hAaWV0Zi5vcmc8L2E+ PGJyPg0KJmd0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v d2VicHVzaCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby93ZWJwdXNoPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KV2VicHVzaCBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86V2VicHVzaEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPldlYnB1c2hAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby93ZWJwdXNoIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3dlYnB1c2g8L2E+PGJy Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjxicj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KV2VicHVzaCBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86V2VicHVzaEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPldlYnB1c2hAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby93ZWJwdXNoIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3dlYnB1c2g8L2E+PGJy Pg0KPGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D1D5684C71BCdthakorecablelabscom_-- From nobody Wed Jul 22 15:22:45 2015 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 D4D9A1B2F54 for ; Wed, 22 Jul 2015 15:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 vcuhjQ1dQ53F for ; Wed, 22 Jul 2015 15:22:39 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (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 977731A6EE8 for ; Wed, 22 Jul 2015 15:22:38 -0700 (PDT) Received: by wibud3 with SMTP id ud3so192876740wib.0 for ; Wed, 22 Jul 2015 15:22:37 -0700 (PDT) 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=YlnfVTTXsSZf1XLuczeFL/dacSCk6Bix+LVRDhrSEq8=; b=bmPatLM44UFeMRkrYG7F1okUx4SaHCTFHufznwpYgUwSnQ3omgUP2+y3ko4tY/2Zsq F3a9kuY3gfc4jNyup2QtNvpI2LuJrdl3zEmJRlrj+yf+aTY5ZFOPswabzu7VyyUc0oOe Gei4iHmWW5d9SQQhv4Mg+VE9QGdVDh5aqtNdsOUe2d5/mkeLqr+SnU+MC3Us7OBc4RX0 KzDIzRWeaBXTf+OSCr2eRy+La28A3spd3Tov/GHuNnhYDsrNs0NbAGaWN1kBoVmzJuqo 9MFBYI0F7lQc10yjZPODoDzdniZeVnSjFWGOC8ZWwYeDQamEBjbjjzr5kiPfgcEGHYNV h7Yw== X-Gm-Message-State: ALoCoQmck1p8L7rxfZmqcMafskfzKpMorR0NPAzPyI2m6kde9jhTDrgvZ3i7IfW3lrIt85eQkF0+ MIME-Version: 1.0 X-Received: by 10.181.25.234 with SMTP id it10mr45217065wid.41.1437603757039; Wed, 22 Jul 2015 15:22:37 -0700 (PDT) Received: by 10.27.33.81 with HTTP; Wed, 22 Jul 2015 15:22:36 -0700 (PDT) In-Reply-To: References: Date: Wed, 22 Jul 2015 15:22:36 -0700 Message-ID: From: Benjamin Bangert To: Darshak Thakore Content-Type: multipart/alternative; boundary=001a1136cbd8444368051b7e3588 Archived-At: Cc: Costin Manolache , "webpush@ietf.org" Subject: Re: [Webpush] comments on latest draft-thomson-webpush-protocol-00 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, 22 Jul 2015 22:22:45 -0000 --001a1136cbd8444368051b7e3588 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yea, that's what I figured on re-reading it. The reason I interpreted it differently is because the urn:ietf:params:push link is *relative*, while the Location is an absolute URI. In our current Push situation, the domain the UA connects to is a different subdomain than the domain used for app-servers to connect to, so a relative URL just seems wrong. I had assumed based on this, that the absolute URL then, would be the only reasonable thing to hand out to an appserver. Either way, it should work fine as I said if the private one is just the same for all subscriptions, or we tack on a new Link for receiving them that is the aggregation link that must be used if present. On Wed, Jul 22, 2015 at 2:44 PM, Darshak Thakore wrote: > I think you have it backwards (maybe we need to be more explicit in the > spec). The Location link is the =E2=80=9Cprivate=E2=80=9D link that the U= A holds. That=E2=80=99s > the link to which the UA/client is going to make the request to for getti= ng > the notifications (Section 6 shows that the h2 GET is being done by the > UA/client to the "/s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx"). The > =E2=80=9Curn:ietf:params:push=E2=80=9D link is the one that is distribute= d to the > application servers (along wit the /receipts/xxxx). The current spec > requires the UA/client to make separate GET=E2=80=99s to the URI provided= in the > Location field (albeit it can be done on the same h2 connection). By > linking the subscriptions to the primary subscription, the UA/client can > make a single h2 GET request to primary subscription URI (the one returne= d > in the Location header of the primary subscription) and get notifications > for all subsequent subscriptions. > > > On 7/22/15, 10:30 AM, "Benjamin Bangert" wrote: > > On Wed, Jul 22, 2015 at 8:27 AM, Costin Manolache > wrote: > >> >> >> On Wed, Jul 22, 2015 at 1:25 AM, Darshak Thakore > > wrote: >> >>> Comments below >>> >>> On 7/21/15, 6:48 PM, "Costin Manolache" wrote: >>> >>> I think one question is who makes the decision if subscrptions are >>> 'aggregated' or not. And the only answer >>> I know is the push provider - since the push provider is the one bearin= g >>> the costs and defining the >>> requirements for UAs that connect to it. >>> >>> >>> DT>> As I mentioned in the other email (Benjamin=E2=80=99s email), I= =E2=80=99m not >>> sure how a PS can force a UA to aggregate (unless the PS somehow identi= fies >>> the client based on authentication/cookie/something-else). >>> >> >> In aggregate model, there is a registration (or subscription) for the >> UA, and each origin/serviceworker have a subscription associated with th= e >> UA. >> >> The PS can simply reject subscriptions that don't have an associated >> parent, and not deliver the the registration/root. Than the UA >> may chose a different PS, or aggregate. >> >> Or: terms of service and abuse detection on PS. >> >> There was a thread about PS returning a URL that may require additional >> user interaction when the UA registers with the PS, >> and may have separate relation ( like Setup Wizard in android ). For >> example GCM attempts to determine device type, if it is rooted, etc. >> >> I don't think the expectation is that a PS MUST accept arbitrary UAs, >> free and without any checks or rules. >> > > I'm associating one h2 connection as being one UA, and treating the > first Subscribe operation, or the first Receive Push Messages operation a= s > the registration. Also, I am perhaps misreading the spec in which URL is > given out to whom, now that I think about it. In Sec 3, the Subscribe > response is such: > > HTTP/1.1 201 Created > Date: Thu, 11 Dec 2014 23:56:52 GMT > Link:

; > rel=3D"urn:ietf:params:push" > Link: ; > rel=3D"urn:ietf:params:push:receipt" > Location: https://push.example.net/s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx > Cache-Control : max-age:864000, private > > My thought was that the Location link is the one given to the AppServers, > and the urn:ietf:params:push link is the 'private URL' that the UA uses t= o > receive push messages. This way, after the initial Subscribe, the PS has > associated that h2 connection with the private URL, and new Subscribe > requests will return new Location links to give to the AppServer. It also > means the UA would need to store the Location for each Subscribe, since t= he > private URL would be unchanging for all later Subscribe requests. > > > On reconnect, receiving push messages by hitting the private URL would > then associate the h2 connection again, acting as the registration. > > If a UA wants to operate independent batches of subscriptions, as the > IoT use-case previously cited, it must use entirely separate h2 connectio= ns > for each batch. > > The spec includes a Location without identifying its actual use, as my > reading of it seems unclear on if the Link is the one given to the > AppServer, or if its the Location. > > This presumes that there is no h2 proxying such that individual requests > over the same connection might be on behalf of different UA's. (I really > really don't like the thought of an h2 proxy of this nature, because it > means it could lie about whether a client is still actually 'alive' to pi= ng > frames, and that's given us enough grief with mobile TCP proxies). > > In this manner, the PS could choose whether to give the same private URL > back for all Subscribe requests over the same connection, or not. The > additional requirements on the UA: > - It must store the Location, since that's the guaranteed unique part > - If it gets the same private URL back, it should only use the Receive > operation once, and realize all new push messages will come over the > existing GET > - On reconnect, it MUST send the Receive operation before any new > Subscribe operations (since that's treated as 'registration' on reconnect= ) > > This way a PS gets to choose, and the associating link is the push link > itself. If the thought was that the push Link is the one sent to > AppServers, then some of this will need a bit of changing of course. > > > >> >> >>> I think the PS should/must support it but it would be the client/UA=E2= =80=99s >>> decision to aggregate. We can put language to =E2=80=9Cstrongly recomme= nd=E2=80=9D the >>> client/UA to aggregate but it would still be the client=E2=80=99s decis= ion to >>> include the initial subscription when making subsequent subscription >>> requests. >>> >> >>> >>> If we agree that a push provider may require 'aggregation' - all >>> subscriptions from a device, when connecting >>> to such a provider, will need to have something in common, to allow the >>> aggregation. The original >>> "registration + subscription" does it by having a first step where a >>> device gets the common element. >>> It can be simplified by defining the 'registration' as a regular >>> subscription, and allowing each app to >>> have a 'child' subscription. This works nicely if a UA supports >>> profiles/multi-user for example - and may >>> be extended later for more complicated cases, where a UA acts as a prox= y >>> for other UAs ( for example >>> a wearable device paired over BT ). >>> >>> >>> DT>> I think within the context of the fact that a client does want to >>> =E2=80=9Caggregate=E2=80=9D, all of the above is doable. However as I m= entioned above, if a >>> client does not send the =E2=80=9Cparent subscription=E2=80=9D info in = the subsequent >>> subscription requests, there=E2=80=99s no easy way for a PS to force ag= gregation. >>> >> >> I wouldn't be very worried about a small percentage of devices not >> aggregating - and anything large is usually detectable. >> >> >> Costin >> >> >>> >>> The subscription API should allow a way to create 'links' between >>> subscriptions. We do need to >>> finish the separate discussion on sender authentication and registratio= n >>> - but assuming a push service >>> requires sender authentication, this is another 'link' between the app >>> subscription and the server id ( >>> which can be another capability URL or subscription ). >>> >>> >>> DT>> Yes, I believe that should be doable with the idea here. >>> >>> >>> I don't think it's a problem if the 'non-aggregated' model - where >>> nothing is shared - is defined even as default, >>> and some push providers may chose to support both, or only one model, >>> depending on their scale and costs >>> >>> >>> Costin >>> >>> On Tue, Jul 21, 2015 at 9:26 AM, Benjamin Bangert >>> wrote: >>> >>>> My preference would be for the server to be able to require this, >>>> rather than leaving it up to the client. If a server doesn't want to e= xpend >>>> the heavy resource cost of treating every single subscription as its o= wn >>>> URL, there should be a way for the server to indicate that in its >>>> subscription response. >>>> >>>> For an IoT use-case, where a client might want different sets of >>>> subscriptions entirely, and to only check one group of them, it could = open >>>> a separate h2 connection to retrieve that set. >>>> >>>> On Mon, Jul 20, 2015 at 2:41 PM, Darshak Thakore < >>>> d.thakore@cablelabs.com> wrote: >>>> >>>>> >>>>> It seems like we do want some mechanism that allows a client to >>>>> retrieve >>>>> notifications for all subscriptions with a single fetch. For IoT base= d >>>>> use >>>>> cases also this is desirable. I guess this keeps going back to the >>>>> aggregation-vs-disaggregation discussion. However I=C2=B9m wondering = if its >>>>> possible to define/create a sort of =C2=B3aggregation-on-demand=C2=B2= mode with >>>>> the >>>>> default being the current =C2=B3disaggregation=C2=B2 mode. >>>>> >>>>> For example, once a client/UA has subscribed for the first time and >>>>> holds >>>>> 1 subscription, when it wants to create subsequent subscriptions, it >>>>> can >>>>> include the first subscription in the request: >>>>> >>>>> POST /subscribe/ HTTP/1.1 >>>>> HOST: push.example.net >>>>> Link: ; >>>>> rel=3D=C2=B3urn:ietf:params:push:subcribe=C2=B2 (I=C2=B9m not sure if= its ok to use Link >>>>> header in a request, if not we need to find something more suitable) >>>>> >>>>> When a PS processes this request, it can associate the new subscripti= on >>>>> with the one provided. (I think the additional data stored by the PS = to >>>>> achieve this should be minimal). The response would contain the new >>>>> subscription info as currently defined (and maybe something additiona= l >>>>> to >>>>> indicate that the new subscription is tied to the one in the request) >>>>> >>>>> When receiving PUSH messages, a client/UA can make a single GET >>>>> request to >>>>> the primary subscription resource and the server will send push >>>>> notifications for all subscriptions associated with the primary >>>>> subscription. >>>>> >>>>> For example, the request would be >>>>> >>>>> HEADERS [stream 7] +EHD_STREAM +END_HEADERS >>>>> :method =3D GET >>>>> :path =3D /s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx >>>>> :authority =3D push.example.net >>>>> >>>>> And the corresponding response would be >>>>> >>>>> PUSH_PROMISE [stream 7; promised stream 4] +END_HEADERS >>>>> :method =3D GET >>>>> :path =3D /d/qDIYHNcfAIPP_5ITvURr-d6BGtYnTRnk >>>>> :authority =3D push.example.net >>>>> >>>>> HEADERS [stream 4] +END_HEADERS >>>>> :status =3D 200 >>>>> =E2=80=B9=E2=80=B9OTHER HEADERS =E2=80=B9=E2=80=B9 >>>>> :content-loc =3D /s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx >>>>> >>>>> DATA [stream 4] +END_STREAM >>>>> iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB >>>>> >>>>> >>>>> PUSH_PROMISE [stream 7; promised stream 6] +END_HEADERS >>>>> :method =3D GET >>>>> :path =3D /d/gjuNJTYuZXkyylOOtjfAEo6ktRHCADui >>>>> :authority =3D push.example.net >>>>> >>>>> HEADERS [stream 6] +END_HEADERS >>>>> :status =3D 200 >>>>> =E2=80=B9=E2=80=B9OTHER HEADERS =E2=80=B9=E2=80=B9 >>>>> :content-loc =3D /s/hJ0jW1ElCjhjfwwh4kTQw7rEYK4QyFFW >>>>> >>>>> DATA [stream 6] +END_STREAM >>>>> {encoded/encrypted-notification-message} >>>>> >>>>> >>>>> =E2=80=B9=E2=80=B9 additional PUSH messages for other subscriptions = =E2=80=B9=E2=80=B9 >>>>> >>>>> >>>>> >>>>> In the above example, the responses can include a Content-Location (o= r >>>>> some other appropriate) header to indicate the associated subscriptio= n >>>>> for >>>>> the notification message. This would allow the client/UA to send just >>>>> one >>>>> GET request to retrieve (and keep receiving) notifications on all its >>>>> active subscriptions. A client/UA may even choose to keep certain >>>>> subscriptions separate and group only a subset of them (this would be >>>>> useful in IoT like cases) >>>>> >>>>> >>>>> Darshak >>>>> >>>>> >>>>> >>>>> >>>>> On 7/20/15, 10:31 AM, "Webpush on behalf of Martin Thomson" >>>>> >>>>> wrote: >>>>> >>>>> >On 20 July 2015 at 09:21, Benjamin Bangert >>>>> wrote: >>>>> >> What's the use-case of a client polling over a long-lived connecti= on >>>>> > >>>>> >The use case is for a device that is only periodically online (a >>>>> >constrained device) that wants to check in, then immediately go >>>>> >offline again. >>>>> > >>>>> >_______________________________________________ >>>>> >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 >>>> >>>> >>> >> > --001a1136cbd8444368051b7e3588 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yea, that's what I figured on re-reading it. The = reason I interpreted it differently is because the urn:ietf:params:push lin= k is *relative*, while the Location is an absolute URI. In our current Push= situation, the domain the UA connects to is a different subdomain than the= domain used for app-servers to connect to, so a relative URL just seems wr= ong.

I had assumed based on this, that the absolute URL then, = would be the only reasonable thing to hand out to an appserver. Either way,= it should work fine as I said if the private one is just the same for all = subscriptions, or we tack on a new Link for receiving them that is the aggr= egation link that must be used if present.

On Wed, Jul 22, 2015 at 2:44 PM, Darshak= Thakore <d.thakore@cablelabs.com> wrote:
=C2=A0I think you have it backwards (maybe we need to be more explicit= in the spec). The Location link is the =E2=80=9Cprivate=E2=80=9D link that= the UA holds. That=E2=80=99s the link to which the UA/client is going to m= ake the request to for getting the notifications =C2=A0(Section 6 shows that the h2 GET is being done by the UA/client to the "/s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx&qu= ot;). The =E2=80=9Curn:ietf:params:push=E2=80=9D link is the one tha= t is distributed to the application servers (along wit the /receipts/xxxx). The current spec requires the UA/client to make s= eparate GET=E2=80=99s to the URI provided in the Location field (albeit it = can be done on the same h2 connection). By linking the subscriptions to the= primary subscription, the UA/client can make a single h2 GET request to primary subscription URI (the one returned= in the Location header of the primary subscription) and get notifications = for all subsequent subscriptions.


On 7/22/15, 10:30 AM, "Benjamin Bangert" <bbangert@mozilla.com> wro= te:

On Wed, Jul 22, 2015 at 8:27 AM, Costin Manolach= e <costin@gmail.com<= /a>> wrote:


On Wed, Jul 22, 2015 at 1:25 AM, Darshak T= hakore <d.thakore@cablelabs.com> wrote:
Comments below

On 7/21/15, 6:48 PM, "Costin Manolache" <costin@gmail.com> wrote:

I think one question is who makes the decision if subscrpt= ions are 'aggregated' or not. And the only answer=C2=A0
I know is the push provider - since the push provider is the one beari= ng the costs and defining the=C2=A0
requirements for UAs that connect to it.=C2=A0

DT>> As I mentioned in the other email (Benjamin=E2=80=99s email= ), I=E2=80=99m not sure how a PS can force a UA to aggregate (unless the PS= somehow identifies the client based on authentication/cookie/something-els= e).

In aggregate model, there is a registration (or subscription) for the = UA, and each origin/serviceworker have a subscription associated with the U= A.=C2=A0

The PS can simply reject subscriptions that don't have an associat= ed parent, and not deliver the the registration/root. Than the UA
may chose a different PS, or aggregate.

Or: terms of service and abuse detection on PS.=C2=A0

There was a thread about PS returning a URL that may require additiona= l user interaction when the UA registers with the PS,
and may have separate relation ( like Setup Wizard in android ). For e= xample GCM attempts to determine device type, if it is rooted, etc.=C2=A0

I don't think the expectation is that a PS MUST accept arbitrary U= As, free and without any checks or rules.

I'm associating one h2 connection as being one UA, and treating th= e first Subscribe operation, or the first Receive Push Messages operation a= s the registration. Also, I am perhaps misreading the spec in which URL is = given out to whom, now that I think about it. In Sec 3, the Subscribe response is such:

HTTP/1.1 201 Created
Date: Thu, 11 Dec 2014 23:56:52 GMT
Link: </p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV>;
        rel=3D"urn:ietf:params:push"
Link: </receipts/xjTG79I3VuptNWS0DsFu4ihT97aE6UQJ>;
        rel=3D"urn:ietf:params:push:receipt"
Location: https://push.example.net/s/LBhhw0OohO=
-Wl4Oi971UGsB7sdQGUibx
Cache-Control: max-age:864000, private
My thought was that the Location link is the one given to the AppServers, a= nd the urn:ietf:params:push link is the 'private URL' that the UA u= ses to receive push messages. This way, after the initial Subscribe, the PS= has associated that h2 connection with the private URL, and new Subscribe requests will return new Location links= to give to the AppServer. It also means the UA would need to store the Loc= ation for each Subscribe, since the private URL would be unchanging for all= later Subscribe requests.

On reconnect, receiving push messages by hitting the private URL would= then associate the h2 connection again, acting as the registration.

If a UA wants to operate independent batches of subscriptions, as the = IoT use-case previously cited, it must use entirely separate h2 connections= for each batch.

The spec includes a Location without identifying its actual use, as my= reading of it seems unclear on if the Link is the one given to the AppServ= er, or if its the Location.

This presumes that there is no h2 proxying such that individual reques= ts over the same connection might be on behalf of different UA's. (I re= ally really don't like the thought of an h2 proxy of this nature, becau= se it means it could lie about whether a client is still actually 'alive' to ping frames, and that's gi= ven us enough grief with mobile TCP proxies).

In this manner, the PS could choose whether to give the same private U= RL back for all Subscribe requests over the same connection, or not. The ad= ditional requirements on the UA:
- It must store the Location, since that's the guaranteed unique part - If it gets the same private URL back, it should only use the Receive oper= ation once, and realize all new push messages will come over the existing G= ET
- On reconnect, it MUST send the Receive operation before any new Subs= cribe operations (since that's treated as 'registration' on rec= onnect)

This way a PS gets to choose, and the associating link is the push lin= k itself. If the thought was that the push Link is the one sent to AppServe= rs, then some of this will need a bit of changing of course.

=C2=A0
=C2=A0
I think the PS should/must support it but it would be the client/UA=E2= =80=99s decision to aggregate. We can put language to =E2=80=9Cstrongly rec= ommend=E2=80=9D the client/UA to aggregate but it would still be the client= =E2=80=99s decision to include the initial subscription when making subsequent subscription requests.


If we agree that a push provider may require 'aggregation' - a= ll subscriptions from a device, when connecting
to such a provider, will need to have something in common, to allow th= e aggregation. The original
=C2=A0"registration + subscription" does it by having a firs= t step where a device gets the common element.=C2=A0
It can be simplified by defining the 'registration' as a regul= ar subscription, and allowing each app to
=C2=A0have a 'child' subscription. This works nicely if a UA s= upports profiles/multi-user for example - and may=C2=A0
be extended later for more complicated cases, where a UA acts as a pro= xy for other UAs ( for example=C2=A0
a wearable device paired over BT ).=C2=A0

DT>> I think within the context of the fact that a client does w= ant to =E2=80=9Caggregate=E2=80=9D, all of the above is doable. However as = I mentioned above, if a client does not send the =E2=80=9Cparent subscripti= on=E2=80=9D info in the subsequent subscription requests, there=E2=80=99s n= o easy way for a PS to force aggregation.=C2=A0
I wouldn't be very worried about a small percentage of devices not= aggregating - and anything large is usually detectable.


Costin
=C2=A0

The subscription API should allow a way to create 'links' betw= een subscriptions. We do need to=C2=A0
finish the separate discussion on sender authentication and registrati= on - but assuming a push service
requires sender authentication, this is another 'link' between= the app subscription and the server id (
which can be another capability URL or subscription ).=C2=A0

DT>> Yes, I believe that should be doable with the idea here.=C2= =A0


I don't think it's a problem if the 'non-aggregated' m= odel - where nothing is shared - is defined even as default,
and some push providers may chose to support both, or only one model, = depending on their scale and costs

Costin

On Tue, Jul 21, 2015 at 9:26 AM, Benjamin Banger= t <bbangert@mozi= lla.com> wrote:
My preference would be for the server to be able to require this, rath= er than leaving it up to the client. If a server doesn't want to expend= the heavy resource cost of treating every single subscription as its own U= RL, there should be a way for the server to indicate that in its subscription response.

For an IoT use-case, where a client might want different sets of subscripti= ons entirely, and to only check one group of them, it could open a separate= h2 connection to retrieve that set.

On Mon, Jul 20, 2015 at 2:41 PM, Darshak T= hakore <d.thakore@= cablelabs.com> wrote:

It seems like we do want some mechanism that allows a client to retrieve notifications for all subscriptions with a single fetch. For IoT based use<= br> cases also this is desirable. I guess this keeps going back to the
aggregation-vs-disaggregation discussion. However I=C2=B9m wondering if its=
possible to define/create a sort of =C2=B3aggregation-on-demand=C2=B2 mode = with the
default being the current =C2=B3disaggregation=C2=B2 mode.

For example, once a client/UA has subscribed for the first time and holds 1 subscription, when it wants to create subsequent subscriptions, it can include the first subscription in the request:

POST /subscribe/ HTTP/1.1
HOST: push.example.net
Link: </s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx>;
rel=3D=C2=B3urn:ietf:params:push:subcribe=C2=B2 (I=C2=B9m not sure if its o= k to use Link
header in a request, if not we need to find something more suitable)

When a PS processes this request, it can associate the new subscription
with the one provided. (I think the additional data stored by the PS to
achieve this should be minimal). The response would contain the new
subscription info as currently defined (and maybe something additional to indicate that the new subscription is tied to the one in the request)

When receiving PUSH messages, a client/UA can make a single GET request to<= br> the primary subscription resource and the server will send push
notifications for all subscriptions associated with the primary
subscription.

For example, the request would be

HEADERS=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[stream 7] +EHD_STREAM +END_HEADER= S
=C2=A0 :method=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D GET
=C2=A0 :path=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D /s/LBhhw0OohO-Wl4Oi971UGs= B7sdQGUibx
=C2=A0 :authority=C2=A0 =C2=A0 =3D push.example.net

And the corresponding response would be

PUSH_PROMISE=C2=A0 =C2=A0 [stream 7; promised stream 4] +END_HEADERS
=C2=A0 :method=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D GET
=C2=A0 :path=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D /d/qDIYHNcfAIPP_5ITvURr-d= 6BGtYnTRnk
=C2=A0 :authority=C2=A0 =C2=A0 =3D push.example.net

HEADERS=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[stream 4] +END_HEADERS
=C2=A0 :status=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D 200
=C2=A0 =E2=80=B9=E2=80=B9OTHER HEADERS =E2=80=B9=E2=80=B9
=C2=A0 :content-loc=C2=A0 =3D /s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx

DATA=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [stream 4] +END_STREAM
=C2=A0 =C2=A0 =C2=A0iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB


PUSH_PROMISE=C2=A0 =C2=A0 [stream 7; promised stream 6] +END_HEADERS
=C2=A0 :method=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D GE= T
=C2=A0 :path=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =3D /d/gjuNJTYuZXkyylOOtjfAEo6ktRHCADui
=C2=A0 :authority=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D push.example.net

HEADERS=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[stream 6] +END_HEADERS
=C2=A0 :status=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D 200
=C2=A0 =E2=80=B9=E2=80=B9OTHER HEADERS =E2=80=B9=E2=80=B9
=C2=A0 :content-loc=C2=A0 =3D /s/hJ0jW1ElCjhjfwwh4kTQw7rEYK4QyFFW

DATA=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [stream 6] +END_STREAM
{encoded/encrypted-notification-message}


=E2=80=B9=E2=80=B9 additional PUSH messages for other subscriptions =E2=80= =B9=E2=80=B9



In the above example, the responses can include a Content-Location (or
some other appropriate) header to indicate the associated subscription for<= br> the notification message. This would allow the client/UA to send just one GET request to retrieve (and keep receiving) notifications on all its
active subscriptions. A client/UA may even choose to keep certain
subscriptions separate and group only a subset of them (this would be
useful in IoT like cases)


Darshak




On 7/20/15, 10:31 AM, "Webpush on behalf of Martin Thomson"
<webp= ush-bounces@ietf.org on behalf of martin.thomso= n@gmail.com> wrote:

>On 20 July 2015 at 09:21, Benjamin Bangert <bbangert@mozilla.com> wrote:
>> What's the use-case of a client polling over a long-lived conn= ection
>
>The use case is for a device that is only periodically online (a
>constrained device) that wants to check in, then immediately go
>offline again.
>
>_______________________________________________
>Webpush mailing list
>Webpush@ietf.org<= /a>
>https://www.ietf.org/mailman/listinfo/webpush
_______________________________________________
Webpush mailing list
Webpush@ietf.org<= br> https://www.ietf.org/mailman/listinfo/webpush


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

--001a1136cbd8444368051b7e3588-- From nobody Wed Jul 22 15:39:51 2015 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 A54971B2F5F for ; Wed, 22 Jul 2015 15:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9a-pOpzAVVpf for ; Wed, 22 Jul 2015 15:39:41 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::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 59E511B2F46 for ; Wed, 22 Jul 2015 15:39:41 -0700 (PDT) Received: by iebmu5 with SMTP id mu5so178355150ieb.1 for ; Wed, 22 Jul 2015 15:39:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bVNMN4tBMJaGxFzlwz59cvAIj1WyJLtc0dIew2asO2o=; b=SBcJfmCxB45dsFMnthTbWR2D7ydmThUsnJCwu44Nfy5qd3TrJ5WoF2tNPhyT7UUvLC NbEBmF/tzfqQte2uxrRfiscmx1BMjmUS6WVbmtNGAq0UrDNJKXppRrsCWbBl8EarO7ly msQD9Nn7xaQiNEsL7T/JVIguG/0sK0l779RmMQ6ki+e1Yh0z+r0+U9lDhoTJt9JXoK66 xqezbBr18tH8YJeLNTWjFBoLa77NjI+jgFBYfG8xnUu4dvbDO2cNY5+OalEiJnNswwtK 4iJ/H5AAr6hRahAFDeitoXwTfK1NJEomyYSsZRtUCbs8sR0C1YZ+zWllpIQ/ixy0LjXN 6j7A== MIME-Version: 1.0 X-Received: by 10.107.154.82 with SMTP id c79mr8891543ioe.64.1437604780377; Wed, 22 Jul 2015 15:39:40 -0700 (PDT) Received: by 10.36.9.207 with HTTP; Wed, 22 Jul 2015 15:39:40 -0700 (PDT) In-Reply-To: References: Date: Wed, 22 Jul 2015 15:39:40 -0700 Message-ID: From: Costin Manolache To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1140fa88430d20051b7e7290 Archived-At: Cc: Benjamin Bangert , "webpush@ietf.org" Subject: Re: [Webpush] Push Message TTL 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, 22 Jul 2015 22:39:46 -0000 --001a1140fa88430d20051b7e7290 Content-Type: text/plain; charset=UTF-8 GCM is doing lazy cleanup - and checks before delivering any message. The cost to delete each expired message at the time it expired would be quite big - the spec should certainly require that expired messages are not delivered, but not how it is implemented. Best time bound would be 'maximum TTL' - it's cheapest in some databases. Costin On Wed, Jul 22, 2015 at 10:08 AM, Martin Thomson wrote: > And... Ben just corrected me offline. There is a mode where the push > service only does TTL-based cleanup periodically, or when clients > connect. That suggests that we might want to relax the requirement to > delete the data. However, there might be some privacy implications to > retaining the information, so some sort of time bound might be needed. > > I'll open an issue on the spec. > > On 22 July 2015 at 19:06, Martin Thomson wrote: > > On 22 July 2015 at 18:58, Benjamin Bangert wrote: > >> I don't understand the requirement on the Push Service to remove expired > >> messages so aggressively. > > > > > > I wanted to avoid situations where messages that are strictly > > time-bounded (a call notification is a good example) are delivered and > > acted upon. If an application says TTL: 10, then I would like some > > certainty that the push service respects that and doesn't deliver the > > message an hour later. > > > > If you don't have a requirement to drop the message, then applications > > will have to add their own TTL handling (something they might want to > > do for separate, security reasons, but something that they probably > > wont). If the application doesn't check for validity, they could do > > bad things on old information, like trigger a call alert. > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > --001a1140fa88430d20051b7e7290 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
GCM is doing lazy cleanup - and checks before delivering a= ny message.
The cost to delete each expired message at the time it expi= red would be quite big -=C2=A0
the spec should certainly require = that expired messages are not delivered, but
not how it is implem= ented. Best time bound would be 'maximum TTL' - it's=C2=A0
<= /div>
cheapest in some databases.

Costin
=

On Wed, Jul= 22, 2015 at 10:08 AM, Martin Thomson <martin.thomson@gmail.com= > wrote:
And... Ben just correc= ted me offline.=C2=A0 There is a mode where the push
service only does TTL-based cleanup periodically, or when clients
connect.=C2=A0 That suggests that we might want to relax the requirement to=
delete the data.=C2=A0 However, there might be some privacy implications to=
retaining the information, so some sort of time bound might be needed.

I'll open an issue on the spec.

On 22 July 2015 at 19:06, Martin Thomson <martin.thomson@gmail.com> wrote:
> On 22 July 2015 at 18:58, Benjamin Bangert <bbangert@mozilla.com> wrote:
>> I don't understand the requirement on the Push Service to remo= ve expired
>> messages so aggressively.
>
>
> I wanted to avoid situations where messages that are strictly
> time-bounded (a call notification is a good example) are delivered and=
> acted upon.=C2=A0 If an application says TTL: 10, then I would like so= me
> certainty that the push service respects that and doesn't deliver = the
> message an hour later.
>
> If you don't have a requirement to drop the message, then applicat= ions
> will have to add their own TTL handling (something they might want to<= br> > do for separate, security reasons, but something that they probably > wont).=C2=A0 If the application doesn't check for validity, they c= ould do
> bad things on old information, like trigger a call alert.

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

--001a1140fa88430d20051b7e7290-- From nobody Wed Jul 22 15:54:14 2015 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 80A3D1B2B47 for ; Wed, 22 Jul 2015 15:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 CEQ4LR8kAo_Z for ; Wed, 22 Jul 2015 15:54:11 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c: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 3CADE1A01EA for ; Wed, 22 Jul 2015 15:54:11 -0700 (PDT) Received: by wibud3 with SMTP id ud3so193602309wib.0 for ; Wed, 22 Jul 2015 15:53:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Gg21iCblRo2QGFpv/O7ecd5fEj8seEVXqOlgnmu1Qfc=; b=ACXdpq5ZwhiQy29GpaLEJLAnqOTOMwoJfOFZBysEB0ID8LZDino2gFZ+xhguHeaBKd HwwkC140vPhXJfbiRyMx1Rewt33leEE916px1tb2cPuxGLhSsHd3pKqekDINXu7LG1fa dFkAIFFgVcp2ta3S8IDf6zpd6U2fFyF2wtZIgWIFz9Bb+z2jMpb2tQ2gtMCbjcaCzII1 ftEHzYzE1nt+h1rHHetkS1xFTcE274ILxHJzs1t/D2fUL3xbUrigYdp2AikPmk/iJBaQ 3PMmRc1GcDkUUy6cXxwPnm+MsFvYho1F1mMHAFABEvVC2FeMN73C/pnFEQC+sY33JE1g VYnQ== 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=Gg21iCblRo2QGFpv/O7ecd5fEj8seEVXqOlgnmu1Qfc=; b=Wt8lroqy88jjc0sLNVOSNfkJe6EtzkJvEUPUsmA5qcpaK+TmJxUD7DFTWtrz3Yd1Nx dBUg5EQZ5x2vzYeqFP9Z2Vj1BGmAGAEb+hB+HzNJasDh0cikacZUgzW1KS1M6MmWwG5B hHun9sy/tYQrDUq89x76koSZFlIQ1DuP1sTSFGiz3iK6pj7Ldjrpl7IohxxpoMnJjxuz HkAvseToogOwH/fLcXjTTx6o/dBR80PnTFuIcIDSXtqeEPJqLwQzU4cpZhg2KG6Nt3jm VLsAcqRM6yEh+lTd8zw+w0+4k59JZPbkMKygG+WAhYcO44db8KWHmHjRonVdJCQtMjyz 2LUw== X-Gm-Message-State: ALoCoQmN8XoFnvg/FBvvy9Yzhgf2RABZexx+gDR7SHUz6a5HV8bkPBVsJ49LL6vqe7in0LuIQTUO X-Received: by 10.180.198.178 with SMTP id jd18mr46071687wic.14.1437605624982; Wed, 22 Jul 2015 15:53:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.69.202 with HTTP; Wed, 22 Jul 2015 15:53:25 -0700 (PDT) In-Reply-To: References: From: nero Date: Wed, 22 Jul 2015 15:53:25 -0700 Message-ID: To: Costin Manolache Content-Type: multipart/alternative; boundary=047d7b624e0e9af4fb051b7ea40f Archived-At: Cc: Benjamin Bangert , Martin Thomson , "webpush@ietf.org" Subject: Re: [Webpush] Push Message TTL 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, 22 Jul 2015 22:54:13 -0000 --047d7b624e0e9af4fb051b7ea40f Content-Type: text/plain; charset=UTF-8 +1 to Costin. There could be batch jobs running to clean up the expired tokens, but you would still have retention longer than TTL for a bunch of messages. The expectation of TTL should not be an expectation of privacy, but an expectation of delivery. The push system might retain messages in the cloud for longer that TTL, but there is a guarantee that the end device will not receive messages with an expired TTL. Further, there could be different implementations, where the expired messages would get delivered to the end device and the expectation would be that those would not get routed to the application. We did not choose the latter in the GCM implementation since it is worse in terms of battery life for portable devices and network traffic. f On Wed, Jul 22, 2015 at 3:39 PM, Costin Manolache wrote: > GCM is doing lazy cleanup - and checks before delivering any message. > The cost to delete each expired message at the time it expired would be > quite big - > the spec should certainly require that expired messages are not delivered, > but > not how it is implemented. Best time bound would be 'maximum TTL' - it's > cheapest in some databases. > > Costin > > On Wed, Jul 22, 2015 at 10:08 AM, Martin Thomson > wrote: > >> And... Ben just corrected me offline. There is a mode where the push >> service only does TTL-based cleanup periodically, or when clients >> connect. That suggests that we might want to relax the requirement to >> delete the data. However, there might be some privacy implications to >> retaining the information, so some sort of time bound might be needed. >> >> I'll open an issue on the spec. >> >> On 22 July 2015 at 19:06, Martin Thomson >> wrote: >> > On 22 July 2015 at 18:58, Benjamin Bangert >> wrote: >> >> I don't understand the requirement on the Push Service to remove >> expired >> >> messages so aggressively. >> > >> > >> > I wanted to avoid situations where messages that are strictly >> > time-bounded (a call notification is a good example) are delivered and >> > acted upon. If an application says TTL: 10, then I would like some >> > certainty that the push service respects that and doesn't deliver the >> > message an hour later. >> > >> > If you don't have a requirement to drop the message, then applications >> > will have to add their own TTL handling (something they might want to >> > do for separate, security reasons, but something that they probably >> > wont). If the application doesn't check for validity, they could do >> > bad things on old information, like trigger a call alert. >> >> _______________________________________________ >> 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 > > -- Francesco Nerieri | Eng. Manager - Mobile | nero@google.com | 650.283.8890 *Quod semper currit sempiterno tempore* --047d7b624e0e9af4fb051b7ea40f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 to Costin. There could be batch jobs running to clean u= p the expired tokens, but you would still have retention longer than TTL fo= r a bunch of messages. The expectation of TTL should not be an expectation = of privacy, but an expectation of delivery.

The push sys= tem might retain messages in the cloud for longer that TTL, but there is a = guarantee that the end device will not receive messages with an expired TTL= .

Further, there could be different implementation= s, where the expired messages would get delivered to the end device and the= expectation would be that those would not get routed to the application.

We did not choose the latter in the GCM implementat= ion since it is worse in terms of battery life for portable devices and net= work traffic.

=C2=A0 f

On Wed, Jul 22, 2015 at 3:39 PM, = Costin Manolache <costin@gmail.com> wrote:
GCM is doing lazy cleanup - and checks bef= ore delivering any message.
The cost to delete each expired message at = the time it expired would be quite big -=C2=A0
the spec should ce= rtainly require that expired messages are not delivered, but
not = how it is implemented. Best time bound would be 'maximum TTL' - it&= #39;s=C2=A0
cheapest in some databases.

<= div>Costin

On Wed, Jul 22, 2015 at 10:08 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
And... Ben just corrected me offline.=C2= =A0 There is a mode where the push
service only does TTL-based cleanup periodically, or when clients
connect.=C2=A0 That suggests that we might want to relax the requirement to=
delete the data.=C2=A0 However, there might be some privacy implications to=
retaining the information, so some sort of time bound might be needed.

I'll open an issue on the spec.

On 22 July 2015 at 19:06, Martin Thomson <martin.thomson@gmail.com> wrote:
> On 22 July 2015 at 18:58, Benjamin Bangert <bbangert@mozilla.com> wrote:
>> I don't understand the requirement on the Push Service to remo= ve expired
>> messages so aggressively.
>
>
> I wanted to avoid situations where messages that are strictly
> time-bounded (a call notification is a good example) are delivered and=
> acted upon.=C2=A0 If an application says TTL: 10, then I would like so= me
> certainty that the push service respects that and doesn't deliver = the
> message an hour later.
>
> If you don't have a requirement to drop the message, then applicat= ions
> will have to add their own TTL handling (something they might want to<= br> > do for separate, security reasons, but something that they probably > wont).=C2=A0 If the application doesn't check for validity, they c= ould do
> bad things on old information, like trigger a call alert.

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


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




--

Francesco Nerieri |=C2=A0Eng. Manager - Mobile |=C2=A0nero@google.com=C2=A0|=C2=A0650.283.8890=C2=A0
Quod semper currit semp= iterno tempore
=
--047d7b624e0e9af4fb051b7ea40f-- From nobody Wed Jul 22 21:19:02 2015 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 4CFD21A0302 for ; Wed, 22 Jul 2015 21:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UP61oglEFcy6 for ; Wed, 22 Jul 2015 21:18:54 -0700 (PDT) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::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 0F7FA1A0248 for ; Wed, 22 Jul 2015 21:18:54 -0700 (PDT) Received: by ykfw194 with SMTP id w194so130214150ykf.0 for ; Wed, 22 Jul 2015 21:18:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ANfugGI10tMiHf0YXgKhZLwvHPOxvjX3oSNbSQToUBQ=; b=Por1EnbStBEJns3UG2ysCJtuihp+A9VxvwC5krOMJ8PhZ4rN7F9wts1hTXr5mRMkH8 RHH6nfXECaloRWDVg658CVAeoBDfOB1u5Q6vg3qttXQ6PkQIq9IAW/QmlD5rY1hVDxXi xuY7LGLnBs61d0trkl0bfhf4ddCQLoIHZ0CFXneRsr8JDNBjYLkR3ixdk9l5t0QTJKXs VUTWAEpV+50J1sZDQSO0IO8cYsKWK0AkFcs2VfNOJz5Lgm4L6AfyUeI+g5YbQ0JrgX9Y qFhpMTCv7wsryEc1SKyV+UiPKpAFMrddF9zdqEWWS9ck4QeVMf7+kxSFIvCWIHxW/sFD 6cWQ== MIME-Version: 1.0 X-Received: by 10.170.86.132 with SMTP id d126mr6172172yka.57.1437625133442; Wed, 22 Jul 2015 21:18:53 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Wed, 22 Jul 2015 21:18:53 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Wed, 22 Jul 2015 21:18:53 -0700 (PDT) In-Reply-To: References: Date: Wed, 22 Jul 2015 21:18:53 -0700 Message-ID: From: Martin Thomson To: Ben Bangert Content-Type: multipart/alternative; boundary=001a113a7f3e6647ca051b832fa1 Archived-At: Cc: Costin Manolache , Darshak Thakore , webpush@ietf.org Subject: Re: [Webpush] comments on latest draft-thomson-webpush-protocol-00 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, 23 Jul 2015 04:19:00 -0000 --001a113a7f3e6647ca051b832fa1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If we take this path, it might be necessary to reverse the slots we use for these two URIs, simply because we would now have a need to identify the subscription in a request to a different resource (though we could avoid that by making the subscription URI the target of a "create subscription" request, it offers no option for the server to reject the proposed grouping). Note that the use of relative URIs was for economy only; the Location header field requires absolute URIs though. Perhaps we should be more explicit and use absolute everywhere to avoid risking confusion. On Jul 23, 2015 12:22 AM, "Benjamin Bangert" wrote: > Yea, that's what I figured on re-reading it. The reason I interpreted it > differently is because the urn:ietf:params:push link is *relative*, while > the Location is an absolute URI. In our current Push situation, the domai= n > the UA connects to is a different subdomain than the domain used for > app-servers to connect to, so a relative URL just seems wrong. > > I had assumed based on this, that the absolute URL then, would be the onl= y > reasonable thing to hand out to an appserver. Either way, it should work > fine as I said if the private one is just the same for all subscriptions, > or we tack on a new Link for receiving them that is the aggregation link > that must be used if present. > > On Wed, Jul 22, 2015 at 2:44 PM, Darshak Thakore > wrote: > >> I think you have it backwards (maybe we need to be more explicit in >> the spec). The Location link is the =E2=80=9Cprivate=E2=80=9D link that = the UA holds. >> That=E2=80=99s the link to which the UA/client is going to make the requ= est to for >> getting the notifications (Section 6 shows that the h2 GET is being don= e >> by the UA/client to the "/s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx"). The >> =E2=80=9Curn:ietf:params:push=E2=80=9D link is the one that is distribut= ed to the >> application servers (along wit the /receipts/xxxx). The current spec >> requires the UA/client to make separate GET=E2=80=99s to the URI provide= d in the >> Location field (albeit it can be done on the same h2 connection). By >> linking the subscriptions to the primary subscription, the UA/client can >> make a single h2 GET request to primary subscription URI (the one return= ed >> in the Location header of the primary subscription) and get notification= s >> for all subsequent subscriptions. >> >> >> On 7/22/15, 10:30 AM, "Benjamin Bangert" wrote: >> >> On Wed, Jul 22, 2015 at 8:27 AM, Costin Manolache >> wrote: >> >>> >>> >>> On Wed, Jul 22, 2015 at 1:25 AM, Darshak Thakore < >>> d.thakore@cablelabs.com> wrote: >>> >>>> Comments below >>>> >>>> On 7/21/15, 6:48 PM, "Costin Manolache" wrote: >>>> >>>> I think one question is who makes the decision if subscrptions are >>>> 'aggregated' or not. And the only answer >>>> I know is the push provider - since the push provider is the one >>>> bearing the costs and defining the >>>> requirements for UAs that connect to it. >>>> >>>> >>>> DT>> As I mentioned in the other email (Benjamin=E2=80=99s email), I= =E2=80=99m not >>>> sure how a PS can force a UA to aggregate (unless the PS somehow ident= ifies >>>> the client based on authentication/cookie/something-else). >>>> >>> >>> In aggregate model, there is a registration (or subscription) for the >>> UA, and each origin/serviceworker have a subscription associated with t= he >>> UA. >>> >>> The PS can simply reject subscriptions that don't have an associated >>> parent, and not deliver the the registration/root. Than the UA >>> may chose a different PS, or aggregate. >>> >>> Or: terms of service and abuse detection on PS. >>> >>> There was a thread about PS returning a URL that may require >>> additional user interaction when the UA registers with the PS, >>> and may have separate relation ( like Setup Wizard in android ). For >>> example GCM attempts to determine device type, if it is rooted, etc. >>> >>> I don't think the expectation is that a PS MUST accept arbitrary UAs, >>> free and without any checks or rules. >>> >> >> I'm associating one h2 connection as being one UA, and treating the >> first Subscribe operation, or the first Receive Push Messages operation = as >> the registration. Also, I am perhaps misreading the spec in which URL is >> given out to whom, now that I think about it. In Sec 3, the Subscribe >> response is such: >> >> HTTP/1.1 201 Created >> Date: Thu, 11 Dec 2014 23:56:52 GMT >> Link:

; >> rel=3D"urn:ietf:params:push" >> Link: ; >> rel=3D"urn:ietf:params:push:receipt" >> Location: https://push.example.net/s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx >> Cache-Control : max-age:864000, private >> >> My thought was that the Location link is the one given to the AppServers= , >> and the urn:ietf:params:push link is the 'private URL' that the UA uses = to >> receive push messages. This way, after the initial Subscribe, the PS has >> associated that h2 connection with the private URL, and new Subscribe >> requests will return new Location links to give to the AppServer. It als= o >> means the UA would need to store the Location for each Subscribe, since = the >> private URL would be unchanging for all later Subscribe requests. >> >> >> On reconnect, receiving push messages by hitting the private URL would >> then associate the h2 connection again, acting as the registration. >> >> If a UA wants to operate independent batches of subscriptions, as the >> IoT use-case previously cited, it must use entirely separate h2 connecti= ons >> for each batch. >> >> The spec includes a Location without identifying its actual use, as my >> reading of it seems unclear on if the Link is the one given to the >> AppServer, or if its the Location. >> >> This presumes that there is no h2 proxying such that individual >> requests over the same connection might be on behalf of different UA's. = (I >> really really don't like the thought of an h2 proxy of this nature, beca= use >> it means it could lie about whether a client is still actually 'alive' t= o >> ping frames, and that's given us enough grief with mobile TCP proxies). >> >> In this manner, the PS could choose whether to give the same private >> URL back for all Subscribe requests over the same connection, or not. Th= e >> additional requirements on the UA: >> - It must store the Location, since that's the guaranteed unique part >> - If it gets the same private URL back, it should only use the Receive >> operation once, and realize all new push messages will come over the >> existing GET >> - On reconnect, it MUST send the Receive operation before any new >> Subscribe operations (since that's treated as 'registration' on reconnec= t) >> >> This way a PS gets to choose, and the associating link is the push link >> itself. If the thought was that the push Link is the one sent to >> AppServers, then some of this will need a bit of changing of course. >> >> >> >>> >>> >>>> I think the PS should/must support it but it would be the client/UA= =E2=80=99s >>>> decision to aggregate. We can put language to =E2=80=9Cstrongly recomm= end=E2=80=9D the >>>> client/UA to aggregate but it would still be the client=E2=80=99s deci= sion to >>>> include the initial subscription when making subsequent subscription >>>> requests. >>>> >>> >>>> >>>> If we agree that a push provider may require 'aggregation' - all >>>> subscriptions from a device, when connecting >>>> to such a provider, will need to have something in common, to allow th= e >>>> aggregation. The original >>>> "registration + subscription" does it by having a first step where a >>>> device gets the common element. >>>> It can be simplified by defining the 'registration' as a regular >>>> subscription, and allowing each app to >>>> have a 'child' subscription. This works nicely if a UA supports >>>> profiles/multi-user for example - and may >>>> be extended later for more complicated cases, where a UA acts as a >>>> proxy for other UAs ( for example >>>> a wearable device paired over BT ). >>>> >>>> >>>> DT>> I think within the context of the fact that a client does want >>>> to =E2=80=9Caggregate=E2=80=9D, all of the above is doable. However as= I mentioned above, >>>> if a client does not send the =E2=80=9Cparent subscription=E2=80=9D in= fo in the subsequent >>>> subscription requests, there=E2=80=99s no easy way for a PS to force a= ggregation. >>>> >>> >>> I wouldn't be very worried about a small percentage of devices not >>> aggregating - and anything large is usually detectable. >>> >>> >>> Costin >>> >>> >>>> >>>> The subscription API should allow a way to create 'links' between >>>> subscriptions. We do need to >>>> finish the separate discussion on sender authentication and >>>> registration - but assuming a push service >>>> requires sender authentication, this is another 'link' between the app >>>> subscription and the server id ( >>>> which can be another capability URL or subscription ). >>>> >>>> >>>> DT>> Yes, I believe that should be doable with the idea here. >>>> >>>> >>>> I don't think it's a problem if the 'non-aggregated' model - where >>>> nothing is shared - is defined even as default, >>>> and some push providers may chose to support both, or only one model, >>>> depending on their scale and costs >>>> >>>> >>>> Costin >>>> >>>> On Tue, Jul 21, 2015 at 9:26 AM, Benjamin Bangert >>> > wrote: >>>> >>>>> My preference would be for the server to be able to require this, >>>>> rather than leaving it up to the client. If a server doesn't want to = expend >>>>> the heavy resource cost of treating every single subscription as its = own >>>>> URL, there should be a way for the server to indicate that in its >>>>> subscription response. >>>>> >>>>> For an IoT use-case, where a client might want different sets of >>>>> subscriptions entirely, and to only check one group of them, it could= open >>>>> a separate h2 connection to retrieve that set. >>>>> >>>>> On Mon, Jul 20, 2015 at 2:41 PM, Darshak Thakore < >>>>> d.thakore@cablelabs.com> wrote: >>>>> >>>>>> >>>>>> It seems like we do want some mechanism that allows a client to >>>>>> retrieve >>>>>> notifications for all subscriptions with a single fetch. For IoT >>>>>> based use >>>>>> cases also this is desirable. I guess this keeps going back to the >>>>>> aggregation-vs-disaggregation discussion. However I=C2=B9m wondering= if its >>>>>> possible to define/create a sort of =C2=B3aggregation-on-demand=C2= =B2 mode with >>>>>> the >>>>>> default being the current =C2=B3disaggregation=C2=B2 mode. >>>>>> >>>>>> For example, once a client/UA has subscribed for the first time and >>>>>> holds >>>>>> 1 subscription, when it wants to create subsequent subscriptions, it >>>>>> can >>>>>> include the first subscription in the request: >>>>>> >>>>>> POST /subscribe/ HTTP/1.1 >>>>>> HOST: push.example.net >>>>>> Link: ; >>>>>> rel=3D=C2=B3urn:ietf:params:push:subcribe=C2=B2 (I=C2=B9m not sure i= f its ok to use >>>>>> Link >>>>>> header in a request, if not we need to find something more suitable) >>>>>> >>>>>> When a PS processes this request, it can associate the new >>>>>> subscription >>>>>> with the one provided. (I think the additional data stored by the PS >>>>>> to >>>>>> achieve this should be minimal). The response would contain the new >>>>>> subscription info as currently defined (and maybe something >>>>>> additional to >>>>>> indicate that the new subscription is tied to the one in the request= ) >>>>>> >>>>>> When receiving PUSH messages, a client/UA can make a single GET >>>>>> request to >>>>>> the primary subscription resource and the server will send push >>>>>> notifications for all subscriptions associated with the primary >>>>>> subscription. >>>>>> >>>>>> For example, the request would be >>>>>> >>>>>> HEADERS [stream 7] +EHD_STREAM +END_HEADERS >>>>>> :method =3D GET >>>>>> :path =3D /s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx >>>>>> :authority =3D push.example.net >>>>>> >>>>>> And the corresponding response would be >>>>>> >>>>>> PUSH_PROMISE [stream 7; promised stream 4] +END_HEADERS >>>>>> :method =3D GET >>>>>> :path =3D /d/qDIYHNcfAIPP_5ITvURr-d6BGtYnTRnk >>>>>> :authority =3D push.example.net >>>>>> >>>>>> HEADERS [stream 4] +END_HEADERS >>>>>> :status =3D 200 >>>>>> =E2=80=B9=E2=80=B9OTHER HEADERS =E2=80=B9=E2=80=B9 >>>>>> :content-loc =3D /s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx >>>>>> >>>>>> DATA [stream 4] +END_STREAM >>>>>> iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB >>>>>> >>>>>> >>>>>> PUSH_PROMISE [stream 7; promised stream 6] +END_HEADERS >>>>>> :method =3D GET >>>>>> :path =3D /d/gjuNJTYuZXkyylOOtjfAEo6ktRHCADui >>>>>> :authority =3D push.example.net >>>>>> >>>>>> HEADERS [stream 6] +END_HEADERS >>>>>> :status =3D 200 >>>>>> =E2=80=B9=E2=80=B9OTHER HEADERS =E2=80=B9=E2=80=B9 >>>>>> :content-loc =3D /s/hJ0jW1ElCjhjfwwh4kTQw7rEYK4QyFFW >>>>>> >>>>>> DATA [stream 6] +END_STREAM >>>>>> {encoded/encrypted-notification-message} >>>>>> >>>>>> >>>>>> =E2=80=B9=E2=80=B9 additional PUSH messages for other subscriptions = =E2=80=B9=E2=80=B9 >>>>>> >>>>>> >>>>>> >>>>>> In the above example, the responses can include a Content-Location (= or >>>>>> some other appropriate) header to indicate the associated >>>>>> subscription for >>>>>> the notification message. This would allow the client/UA to send jus= t >>>>>> one >>>>>> GET request to retrieve (and keep receiving) notifications on all it= s >>>>>> active subscriptions. A client/UA may even choose to keep certain >>>>>> subscriptions separate and group only a subset of them (this would b= e >>>>>> useful in IoT like cases) >>>>>> >>>>>> >>>>>> Darshak >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 7/20/15, 10:31 AM, "Webpush on behalf of Martin Thomson" >>>>>> >>>>>> wrote: >>>>>> >>>>>> >On 20 July 2015 at 09:21, Benjamin Bangert >>>>>> wrote: >>>>>> >> What's the use-case of a client polling over a long-lived >>>>>> connection >>>>>> > >>>>>> >The use case is for a device that is only periodically online (a >>>>>> >constrained device) that wants to check in, then immediately go >>>>>> >offline again. >>>>>> > >>>>>> >_______________________________________________ >>>>>> >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 >>>>> >>>>> >>>> >>> >> > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > > --001a113a7f3e6647ca051b832fa1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

If we take this path, it might be necessary to reverse the s= lots we use for these two URIs, simply because we would now have a need to = identify the subscription in a request to a different resource (though we c= ould avoid that by making the subscription URI the target of a "create= subscription" request, it offers no option for the server to reject t= he proposed grouping).

Note that the use of relative URIs was for economy only; the= Location header field requires absolute URIs though. Perhaps we should be = more explicit and use absolute everywhere to avoid risking confusion.

On Jul 23, 2015 12:22 AM, "Benjamin Bangert= " <bbangert@mozilla.com= > wrote:
Yea, that's what I figured on re-reading it. The reason I= interpreted it differently is because the urn:ietf:params:push link is *re= lative*, while the Location is an absolute URI. In our current Push situati= on, the domain the UA connects to is a different subdomain than the domain = used for app-servers to connect to, so a relative URL just seems wrong.
=
I had assumed based on this, that the absolute URL then, would be= the only reasonable thing to hand out to an appserver. Either way, it shou= ld work fine as I said if the private one is just the same for all subscrip= tions, or we tack on a new Link for receiving them that is the aggregation = link that must be used if present.

=
On Wed, Jul 22, 2015 at 2:44 PM, Darshak Thakore= <d.thakore@cablelabs.com> wrote:
=C2=A0I think you have it backwards (maybe we need to be more explicit= in the spec). The Location link is the =E2=80=9Cprivate=E2=80=9D link that= the UA holds. That=E2=80=99s the link to which the UA/client is going to m= ake the request to for getting the notifications =C2=A0(Section 6 shows that the h2 GET is being done by the UA/client to the "/s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx&qu= ot;). The =E2=80=9Curn:ietf:params:push=E2=80=9D link is the one tha= t is distributed to the application servers (along wit the /receipts/xxxx). The current spec requires the UA/client to make s= eparate GET=E2=80=99s to the URI provided in the Location field (albeit it = can be done on the same h2 connection). By linking the subscriptions to the= primary subscription, the UA/client can make a single h2 GET request to primary subscription URI (the one returned= in the Location header of the primary subscription) and get notifications = for all subsequent subscriptions.


On 7/22/15, 10:30 AM, "Benjamin Bangert" <bbangert@mozilla.com> wro= te:

On Wed, Jul 22, 2015 at 8:27 AM, Costin Manolach= e <costin@gmail.com<= /a>> wrote:


On Wed, Jul 22, 2015 at 1:25 AM, Darshak T= hakore <d.thakore@cablelabs.com> wrote:
Comments below

On 7/21/15, 6:48 PM, "Costin Manolache" <costin@gmail.com> wrote:

I think one question is who makes the decision if subscrpt= ions are 'aggregated' or not. And the only answer=C2=A0
I know is the push provider - since the push provider is the one beari= ng the costs and defining the=C2=A0
requirements for UAs that connect to it.=C2=A0

DT>> As I mentioned in the other email (Benjamin=E2=80=99s email= ), I=E2=80=99m not sure how a PS can force a UA to aggregate (unless the PS= somehow identifies the client based on authentication/cookie/something-els= e).

In aggregate model, there is a registration (or subscription) for the = UA, and each origin/serviceworker have a subscription associated with the U= A.=C2=A0

The PS can simply reject subscriptions that don't have an associat= ed parent, and not deliver the the registration/root. Than the UA
may chose a different PS, or aggregate.

Or: terms of service and abuse detection on PS.=C2=A0

There was a thread about PS returning a URL that may require additiona= l user interaction when the UA registers with the PS,
and may have separate relation ( like Setup Wizard in android ). For e= xample GCM attempts to determine device type, if it is rooted, etc.=C2=A0

I don't think the expectation is that a PS MUST accept arbitrary U= As, free and without any checks or rules.

I'm associating one h2 connection as being one UA, and treating th= e first Subscribe operation, or the first Receive Push Messages operation a= s the registration. Also, I am perhaps misreading the spec in which URL is = given out to whom, now that I think about it. In Sec 3, the Subscribe response is such:

HTTP/1.1 201 Created
Date: Thu, 11 Dec 2014 23:56:52 GMT
Link: </p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV>;
        rel=3D"urn:ietf:params:push"
Link: </receipts/xjTG79I3VuptNWS0DsFu4ihT97aE6UQJ>;
        rel=3D"urn:ietf:params:push:receipt"
Location: https://push.example.net/s/LBhhw0OohO=
-Wl4Oi971UGsB7sdQGUibx
Cache-Control: max-age:864000, private
My thought was that the Location link is the one given to the AppServers, a= nd the urn:ietf:params:push link is the 'private URL' that the UA u= ses to receive push messages. This way, after the initial Subscribe, the PS= has associated that h2 connection with the private URL, and new Subscribe requests will return new Location links= to give to the AppServer. It also means the UA would need to store the Loc= ation for each Subscribe, since the private URL would be unchanging for all= later Subscribe requests.

On reconnect, receiving push messages by hitting the private URL would= then associate the h2 connection again, acting as the registration.

If a UA wants to operate independent batches of subscriptions, as the = IoT use-case previously cited, it must use entirely separate h2 connections= for each batch.

The spec includes a Location without identifying its actual use, as my= reading of it seems unclear on if the Link is the one given to the AppServ= er, or if its the Location.

This presumes that there is no h2 proxying such that individual reques= ts over the same connection might be on behalf of different UA's. (I re= ally really don't like the thought of an h2 proxy of this nature, becau= se it means it could lie about whether a client is still actually 'alive' to ping frames, and that's gi= ven us enough grief with mobile TCP proxies).

In this manner, the PS could choose whether to give the same private U= RL back for all Subscribe requests over the same connection, or not. The ad= ditional requirements on the UA:
- It must store the Location, since that's the guaranteed unique part - If it gets the same private URL back, it should only use the Receive oper= ation once, and realize all new push messages will come over the existing G= ET
- On reconnect, it MUST send the Receive operation before any new Subs= cribe operations (since that's treated as 'registration' on rec= onnect)

This way a PS gets to choose, and the associating link is the push lin= k itself. If the thought was that the push Link is the one sent to AppServe= rs, then some of this will need a bit of changing of course.

=C2=A0
=C2=A0
I think the PS should/must support it but it would be the client/UA=E2= =80=99s decision to aggregate. We can put language to =E2=80=9Cstrongly rec= ommend=E2=80=9D the client/UA to aggregate but it would still be the client= =E2=80=99s decision to include the initial subscription when making subsequent subscription requests.


If we agree that a push provider may require 'aggregation' - a= ll subscriptions from a device, when connecting
to such a provider, will need to have something in common, to allow th= e aggregation. The original
=C2=A0"registration + subscription" does it by having a firs= t step where a device gets the common element.=C2=A0
It can be simplified by defining the 'registration' as a regul= ar subscription, and allowing each app to
=C2=A0have a 'child' subscription. This works nicely if a UA s= upports profiles/multi-user for example - and may=C2=A0
be extended later for more complicated cases, where a UA acts as a pro= xy for other UAs ( for example=C2=A0
a wearable device paired over BT ).=C2=A0

DT>> I think within the context of the fact that a client does w= ant to =E2=80=9Caggregate=E2=80=9D, all of the above is doable. However as = I mentioned above, if a client does not send the =E2=80=9Cparent subscripti= on=E2=80=9D info in the subsequent subscription requests, there=E2=80=99s n= o easy way for a PS to force aggregation.=C2=A0
I wouldn't be very worried about a small percentage of devices not= aggregating - and anything large is usually detectable.


Costin
=C2=A0

The subscription API should allow a way to create 'links' betw= een subscriptions. We do need to=C2=A0
finish the separate discussion on sender authentication and registrati= on - but assuming a push service
requires sender authentication, this is another 'link' between= the app subscription and the server id (
which can be another capability URL or subscription ).=C2=A0

DT>> Yes, I believe that should be doable with the idea here.=C2= =A0


I don't think it's a problem if the 'non-aggregated' m= odel - where nothing is shared - is defined even as default,
and some push providers may chose to support both, or only one model, = depending on their scale and costs

Costin

On Tue, Jul 21, 2015 at 9:26 AM, Benjamin Banger= t <bbangert@mozi= lla.com> wrote:
My preference would be for the server to be able to require this, rath= er than leaving it up to the client. If a server doesn't want to expend= the heavy resource cost of treating every single subscription as its own U= RL, there should be a way for the server to indicate that in its subscription response.

For an IoT use-case, where a client might want different sets of subscripti= ons entirely, and to only check one group of them, it could open a separate= h2 connection to retrieve that set.

On Mon, Jul 20, 2015 at 2:41 PM, Darshak T= hakore <d.thakore@= cablelabs.com> wrote:

It seems like we do want some mechanism that allows a client to retrieve notifications for all subscriptions with a single fetch. For IoT based use<= br> cases also this is desirable. I guess this keeps going back to the
aggregation-vs-disaggregation discussion. However I=C2=B9m wondering if its=
possible to define/create a sort of =C2=B3aggregation-on-demand=C2=B2 mode = with the
default being the current =C2=B3disaggregation=C2=B2 mode.

For example, once a client/UA has subscribed for the first time and holds 1 subscription, when it wants to create subsequent subscriptions, it can include the first subscription in the request:

POST /subscribe/ HTTP/1.1
HOST: push.example.net
Link: </s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx>;
rel=3D=C2=B3urn:ietf:params:push:subcribe=C2=B2 (I=C2=B9m not sure if its o= k to use Link
header in a request, if not we need to find something more suitable)

When a PS processes this request, it can associate the new subscription
with the one provided. (I think the additional data stored by the PS to
achieve this should be minimal). The response would contain the new
subscription info as currently defined (and maybe something additional to indicate that the new subscription is tied to the one in the request)

When receiving PUSH messages, a client/UA can make a single GET request to<= br> the primary subscription resource and the server will send push
notifications for all subscriptions associated with the primary
subscription.

For example, the request would be

HEADERS=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[stream 7] +EHD_STREAM +END_HEADER= S
=C2=A0 :method=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D GET
=C2=A0 :path=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D /s/LBhhw0OohO-Wl4Oi971UGs= B7sdQGUibx
=C2=A0 :authority=C2=A0 =C2=A0 =3D push.example.net

And the corresponding response would be

PUSH_PROMISE=C2=A0 =C2=A0 [stream 7; promised stream 4] +END_HEADERS
=C2=A0 :method=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D GET
=C2=A0 :path=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D /d/qDIYHNcfAIPP_5ITvURr-d= 6BGtYnTRnk
=C2=A0 :authority=C2=A0 =C2=A0 =3D push.example.net

HEADERS=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[stream 4] +END_HEADERS
=C2=A0 :status=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D 200
=C2=A0 =E2=80=B9=E2=80=B9OTHER HEADERS =E2=80=B9=E2=80=B9
=C2=A0 :content-loc=C2=A0 =3D /s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx

DATA=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [stream 4] +END_STREAM
=C2=A0 =C2=A0 =C2=A0iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB


PUSH_PROMISE=C2=A0 =C2=A0 [stream 7; promised stream 6] +END_HEADERS
=C2=A0 :method=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D GE= T
=C2=A0 :path=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =3D /d/gjuNJTYuZXkyylOOtjfAEo6ktRHCADui
=C2=A0 :authority=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D push.example.net

HEADERS=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[stream 6] +END_HEADERS
=C2=A0 :status=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D 200
=C2=A0 =E2=80=B9=E2=80=B9OTHER HEADERS =E2=80=B9=E2=80=B9
=C2=A0 :content-loc=C2=A0 =3D /s/hJ0jW1ElCjhjfwwh4kTQw7rEYK4QyFFW

DATA=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [stream 6] +END_STREAM
{encoded/encrypted-notification-message}


=E2=80=B9=E2=80=B9 additional PUSH messages for other subscriptions =E2=80= =B9=E2=80=B9



In the above example, the responses can include a Content-Location (or
some other appropriate) header to indicate the associated subscription for<= br> the notification message. This would allow the client/UA to send just one GET request to retrieve (and keep receiving) notifications on all its
active subscriptions. A client/UA may even choose to keep certain
subscriptions separate and group only a subset of them (this would be
useful in IoT like cases)


Darshak




On 7/20/15, 10:31 AM, "Webpush on behalf of Martin Thomson"
<webp= ush-bounces@ietf.org on behalf of martin.thomso= n@gmail.com> wrote:

>On 20 July 2015 at 09:21, Benjamin Bangert <bbangert@mozilla.com> wrote:
>> What's the use-case of a client polling over a long-lived conn= ection
>
>The use case is for a device that is only periodically online (a
>constrained device) that wants to check in, then immediately go
>offline again.
>
>_______________________________________________
>Webpush mailing list
>Webpush@ietf.org<= /a>
>https://www.ietf.org/mailman/listinfo/webpush
_______________________________________________
Webpush mailing list
Webpush@ietf.org<= br> https://www.ietf.org/mailman/listinfo/webpush


_______________________________________________
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

--001a113a7f3e6647ca051b832fa1-- From nobody Thu Jul 23 04:10:26 2015 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 853AD1A8ADE for ; Thu, 23 Jul 2015 04:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 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, IXHASH_X1=1.5, 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 e1NgLAgL0lyM for ; Thu, 23 Jul 2015 04:10:18 -0700 (PDT) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::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 19F8F1A8AB8 for ; Thu, 23 Jul 2015 04:10:16 -0700 (PDT) Received: by ykfw194 with SMTP id w194so136328044ykf.0 for ; Thu, 23 Jul 2015 04:10:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2wKv6euIN98Ki9owxXvFNaK5pCHKsS7qNh9BHjEyTIw=; b=Q1yftUevxDOyktZdigC57Sx52xM6BzgUR1ZsD+ggyN7QxCn2SmvxT/KScC3AwGXYBV 4DjFr/ybuXWewaRvxbwEbTEIb0bqcK2Ys/7uiQu7O1vLUBdTCzb5etylFsq8Wij5BoYF ZqwMwkBCYmG6U83DoFfj4s1TYkJufqRukc8pduoWpdH9mO8z1ZbkkaWEGBXcTYBbrH64 euq7OwUdBh0+hrHToOwN1+487GRn+ap8F+soBSF+Nvx6npfh09xG8Rj9+VZ7VjujVopm 6UFNbqgx4sxBLZD0/tyTLiH7qvlEd9H1IjZxS7PnrDxZpCf03WsfuwLOqos0wNrP/R3D wA/g== MIME-Version: 1.0 X-Received: by 10.129.36.14 with SMTP id k14mr7500005ywk.64.1437649815456; Thu, 23 Jul 2015 04:10:15 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Thu, 23 Jul 2015 04:10:15 -0700 (PDT) In-Reply-To: References: Date: Thu, 23 Jul 2015 13:10:15 +0200 Message-ID: From: Martin Thomson To: Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Benjamin Bangert , "webpush@ietf.org" Subject: Re: [Webpush] Push Message TTL 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, 23 Jul 2015 11:10:19 -0000 On 23 July 2015 at 00:39, Costin Manolache wrote: > the spec should certainly require that expired messages are not delivered Yes, I think that this is an important invariant. I've opened the issue, and I think that we're all in agreement regarding cleanup. From nobody Thu Jul 23 04:12:00 2015 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 527441A8A0D for ; Thu, 23 Jul 2015 04:11:58 -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 3Q3Ax-FXkGhL for ; Thu, 23 Jul 2015 04:11:57 -0700 (PDT) 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 EFF171A8A06 for ; Thu, 23 Jul 2015 04:11:56 -0700 (PDT) Received: by ykdu72 with SMTP id u72so216435719ykd.2 for ; Thu, 23 Jul 2015 04:11:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=O/uneJV5pDVw7tmn1rHB0yrYtEcYghBb64o4/SHPTAg=; b=i3wx7v8L+E6Y6PQjbnkpdNQP3ezw0u9cU6WAUHpUZUsJ3PUoxJtvKirYk7Y5BV7M7H Sd+FoGtkB7fIL7DstBdIUqwKU0dvyRrrUM7fpQaQhS6eskc6t5q6EUNJkoou8rXb1dtv La+wAJkSHTyhyQwLc7eMscYXOeyCB0XkuFI4iVY2ReBvuTPrWRzzHMVHV0f5zTes2gVI wYCjI0EnJmuFOM+yDnnr1Dhg7HG6dKp+WrbuIzkkyd/N2i2LCQ9oW5t69jRCi2Yxmdiv PDOoZtXGGwbd3XdlFNp3tWa27/ryTTFtXRSz6DSwWGb7m26jbX85k64iEMN4+KuERf+U OEgw== MIME-Version: 1.0 X-Received: by 10.170.72.86 with SMTP id o83mr7530730yko.98.1437649916439; Thu, 23 Jul 2015 04:11:56 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Thu, 23 Jul 2015 04:11:56 -0700 (PDT) In-Reply-To: References: Date: Thu, 23 Jul 2015 13:11:56 +0200 Message-ID: From: Martin Thomson To: nero Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Costin Manolache , Benjamin Bangert , "webpush@ietf.org" Subject: Re: [Webpush] Push Message TTL 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, 23 Jul 2015 11:11:58 -0000 On 23 July 2015 at 00:53, nero wrote: > Further, there could be different implementations, where the expired > messages would get delivered to the end device and the expectation would be > that those would not get routed to the application. I'm aware that some implementations do this. There were a number of cusswords exchanged when this "feature" was discovered. I think that we can and should mandate non-delivery, with only a small amount of tolerance for clock drift/propagation delay. From nobody Thu Jul 23 05:06:53 2015 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 51C501A92FE for ; Thu, 23 Jul 2015 05:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-8hdkkX84Ys for ; Thu, 23 Jul 2015 05:06:44 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c: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 517581A92E9 for ; Thu, 23 Jul 2015 05:06:31 -0700 (PDT) Received: by wibud3 with SMTP id ud3so21020027wib.1 for ; Thu, 23 Jul 2015 05:06:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=vYkmx7iehWR/o9bfwV7wyXSv9YfKXQY6CnHfKAN4IUQ=; b=nweBU+0p6KVv1ofXLbzEP+5pkO6n72F6AobcGj8eX5Hlk5R4xjk6ibkVz++PK6pnc2 K6EwjueD+Jtl/m4o2sINz0g1MZxcxtJZxtr/JiwiOGoEYmKsCZKU/cRjXzLYkd3odvn/ 9P6rha0+CMRdrfT2JnxemSMXH98q7kqI6Wqlj8yzG0HTI9CW+bdp1qYOWuOxsX61BMSt SNi06r9CkbPOSCEKcSvLjhSD53noO+1q4KXnHmGrLjb5QjBuENH9tJnRZXN0QxaQa9gt lPlYjJkHMyv6FBjwj9Mm6DDEJ8z+xTCULKBo9HInbd2pOZnBFBAJ0A0yTc/0CgDdj1yU mHdQ== X-Received: by 10.194.205.101 with SMTP id lf5mr16737259wjc.37.1437653190089; Thu, 23 Jul 2015 05:06:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.234.232 with HTTP; Thu, 23 Jul 2015 05:06:10 -0700 (PDT) From: Paul Em Date: Thu, 23 Jul 2015 14:06:10 +0200 Message-ID: To: webpush@ietf.org Content-Type: multipart/alternative; boundary=047d7bb03db2b4a0b8051b89b7ef Archived-At: Subject: [Webpush] optional receipts? 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, 23 Jul 2015 12:06:45 -0000 --047d7bb03db2b4a0b8051b89b7ef Content-Type: text/plain; charset=UTF-8 I am currently writing my master thesis about how to map the protocol to existing push services with a relay server and the biggest problem that comes up is that existing services mostly don't have anything like receipts implemented. I think if we want to see the protocol being implemented earlier we should change receipts from MUST to SHOULD. Does this makes sense or do you see receipts as a critical part of the protocol? I see how this could break the process with acknowleding the messages. Would there maybe be better solutions for that, like indicating with a header field that the push service does not support this? Paul --047d7bb03db2b4a0b8051b89b7ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am currently writing my master thesis about how to map t= he protocol to existing push services with a relay server and the biggest p= roblem that comes up is that existing services mostly don't have anythi= ng like receipts implemented.=C2=A0

I think if we w= ant to see the protocol being implemented earlier we should change receipts= from MUST to SHOULD.
Does this makes sense or do you see receipt= s as a critical part of the protocol? I see how this could break the proces= s with acknowleding the messages. Would there maybe be better solutions for= that, like indicating with a header field that the push service does not s= upport this?

Paul
--047d7bb03db2b4a0b8051b89b7ef-- From nobody Thu Jul 23 05:23:45 2015 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 16DC31A92E4 for ; Thu, 23 Jul 2015 05:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 f6i8ohfcRjP2 for ; Thu, 23 Jul 2015 05:23:42 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450: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 EC0151A90D5 for ; Thu, 23 Jul 2015 05:23:41 -0700 (PDT) Received: by wicgb10 with SMTP id gb10so140570277wic.1 for ; Thu, 23 Jul 2015 05:23:40 -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:content-type; bh=DPAzFzWGvoGv+grn2XTPbA2f6o5nvci3ykYYrrMN65s=; b=IGnU27ux3tMnPWYA+oGDfliW03wXV8GqOWji5OEl+gF0WeTPg+KqNgbS8s51UnF9HX iGtyXmAKtAVZF/eMnMICe7lmW71Q6esTqg8byijJQ7BcaHHiclmYpU7L9TDxU2dEnX87 P2LIOWE79gKkHBBvWdY0qxiNRySBjpSnKmlv+FnHjiJU5wwJdqcZUq/mL/tEOxWTooDN ObW+NWyJ6KLvJHPSRKfo7fcAs4uTRQWC37CnbiqdtlV9S23NhwmmWbA5Yp4PjS+TWNfs Ju5S0ZQb9VvpWSyjJ7pLBev0EkfqtdM94469nW/Z0ypsbfbZfg6d2YMsLEyvFUKOswJl AFlg== 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=DPAzFzWGvoGv+grn2XTPbA2f6o5nvci3ykYYrrMN65s=; b=cTMWMBM8+h91NKOV6VhCD+C3DBt43vJuSdYpELMq609ozsN0Lajf1Ea6XnQi1HzqFj TWDh6V2xVUTKtgwEN6W7I4ONWqON9scTNq2D4GxCqmta1+F2LYgvU11Qlc1iGCZwI7VY 2OMO4zsO1zZyBaFdHcm4q0JeCm9UMDTIxYYk7l+6FJcgTfAm8FGJw+YOIr5Llb4Zvv+H cIAnmFpvY6uoPhXvhsr+rVR/DKH99nbkM/M62resbIgS/TQ6qghbzClH58GGVWbx5tmG ugNEu4Y0icsaXRobkUoflGViBPOVa+KU3TCN/v2jNZbI9VO/9FF5Ka+Wkp1KWPbuRhY3 0jWQ== X-Gm-Message-State: ALoCoQmClgpD2fDgit+nyyrfM1JhyCtpO63KBY2MRiSvi/X6hPS1zKAq3XqefJU5C3lH/sd1JHcF MIME-Version: 1.0 X-Received: by 10.194.57.170 with SMTP id j10mr14873068wjq.140.1437654220664; Thu, 23 Jul 2015 05:23:40 -0700 (PDT) Received: by 10.194.69.202 with HTTP; Thu, 23 Jul 2015 05:23:40 -0700 (PDT) Received: by 10.194.69.202 with HTTP; Thu, 23 Jul 2015 05:23:40 -0700 (PDT) In-Reply-To: References: Date: Thu, 23 Jul 2015 05:23:40 -0700 Message-ID: From: nero To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7ba97fa6223f19051b89f529 Archived-At: Cc: Costin Manolache , Benjamin Bangert , webpush@ietf.org Subject: Re: [Webpush] Push Message TTL 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, 23 Jul 2015 12:23:43 -0000 --047d7ba97fa6223f19051b89f529 Content-Type: text/plain; charset=UTF-8 Sgtm On Jul 23, 2015 1:11 PM, "Martin Thomson" wrote: > On 23 July 2015 at 00:53, nero wrote: > > Further, there could be different implementations, where the expired > > messages would get delivered to the end device and the expectation would > be > > that those would not get routed to the application. > > I'm aware that some implementations do this. There were a number of > cusswords exchanged when this "feature" was discovered. I think that > we can and should mandate non-delivery, with only a small amount of > tolerance for clock drift/propagation delay. > --047d7ba97fa6223f19051b89f529 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Sgtm

On Jul 23, 2015 1:11 PM, "Martin Thomson&qu= ot; <martin.thomson@gmail.co= m> wrote:
On = 23 July 2015 at 00:53, nero <nero@goo= gle.com> wrote:
> Further, there could be different implementations, where the expired > messages would get delivered to the end device and the expectation wou= ld be
> that those would not get routed to the application.

I'm aware that some implementations do this.=C2=A0 There were a number = of
cusswords exchanged when this "feature" was discovered.=C2=A0 I t= hink that
we can and should mandate non-delivery, with only a small amount of
tolerance for clock drift/propagation delay.
--047d7ba97fa6223f19051b89f529-- From nobody Thu Jul 23 05:35:53 2015 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 734111AC3CB for ; Thu, 23 Jul 2015 05:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.227 X-Spam-Level: X-Spam-Status: No, score=0.227 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] 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 PSfpNN3YhGOY for ; Thu, 23 Jul 2015 05:35:40 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5B59E1AC3BF for ; Thu, 23 Jul 2015 05:35:11 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id t6NCZ9PV025894; Thu, 23 Jul 2015 06:35:09 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Thu, 23 Jul 2015 06:35:08 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([::1]) by EXCHANGE.cablelabs.com ([::1]) with mapi id 14.03.0224.002; Thu, 23 Jul 2015 06:35:04 -0600 From: Darshak Thakore To: nero , Martin Thomson Thread-Topic: [Webpush] Push Message TTL Thread-Index: AQHQxJ+cnFI492wgB0uiZmvXQBB/tp3oHLuAgAAAtoCAAFx8AIAAA9eAgADOVwCAABQLAP//np6A Date: Thu, 23 Jul 2015 12:35:03 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 x-originating-ip: [10.5.0.27] Content-Type: multipart/alternative; boundary="_000_D1D63B9072B8dthakorecablelabscom_" MIME-Version: 1.0 Archived-At: Cc: Costin Manolache , Benjamin Bangert , "webpush@ietf.org" Subject: Re: [Webpush] Push Message TTL 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, 23 Jul 2015 12:35:41 -0000 --_000_D1D63B9072B8dthakorecablelabscom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 On 7/23/15, 6:23 AM, "Webpush on behalf of nero" on behalf of nero@google.com> wrote: Sgtm On Jul 23, 2015 1:11 PM, "Martin Thomson" > wrote: On 23 July 2015 at 00:53, nero > wr= ote: > Further, there could be different implementations, where the expired > messages would get delivered to the end device and the expectation would = be > that those would not get routed to the application. I'm aware that some implementations do this. There were a number of cusswords exchanged when this "feature" was discovered. I think that we can and should mandate non-delivery, with only a small amount of tolerance for clock drift/propagation delay. --_000_D1D63B9072B8dthakorecablelabscom_ Content-Type: text/html; charset="us-ascii" Content-ID: <512FC192793C6746BD0A7AAC4DAB4041@cablelabs.com> Content-Transfer-Encoding: quoted-printable
+1

On 7/23/15, 6:23 AM, "Webpush on behalf of nero" <webpush-bounces@ietf.org on behalf= of nero@google.com> wrote:

Sgtm

On Jul 23, 2015 1:11 PM, "Martin Thomson&qu= ot; <martin.thomson@gmail.co= m> wrote:
On 23 July 2015 at 00:53, nero <nero@= google.com> wrote:
> Further, there could be different implementations, where the expired > messages would get delivered to the end device and the expectation wou= ld be
> that those would not get routed to the application.

I'm aware that some implementations do this.  There were a number of cusswords exchanged when this "feature" was discovered.  I t= hink that
we can and should mandate non-delivery, with only a small amount of
tolerance for clock drift/propagation delay.
 --_000_D1D63B9072B8dthakorecablelabscom_-- From nobody Thu Jul 23 05:52:55 2015 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 18EC31AC40F for ; Thu, 23 Jul 2015 05:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSmc3iEL5f6w for ; Thu, 23 Jul 2015 05:52:39 -0700 (PDT) Received: from gator4135.hostgator.com (gator4135.hostgator.com [192.185.4.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13A3F1A0173 for ; Thu, 23 Jul 2015 05:51:38 -0700 (PDT) Received: from [31.133.180.17] (port=52110 helo=dhcp-b411.meeting.ietf.org) by gator4135.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.85) (envelope-from ) id 1ZIFyL-0003xG-D6 for webpush@ietf.org; Thu, 23 Jul 2015 07:51:37 -0500 From: Shida Schubert Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <820C2415-697F-404E-98DB-B9164244810B@ntt-at.com> Date: Thu, 23 Jul 2015 14:51:34 +0200 To: webpush@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) 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: 31.133.180.17 X-Exim-ID: 1ZIFyL-0003xG-D6 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (dhcp-b411.meeting.ietf.org) [31.133.180.17]:52110 X-Source-Auth: shida@agnada.com X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== Archived-At: Subject: [Webpush] Minutes from Tuesday's session 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, 23 Jul 2015 12:52:46 -0000 All below is the meeting minutes from Tuesday=E2=80=99s session.=20 I want to thank Roni for taking notes.=20 IETF 93 XRBLOCK WG Meeting=20 Date and Time: 2015.07.21 17:40-18:40 * Action Items *********************************** 1. Actions for draft-ietf-xrblock-rtcp-xr-video-lc 1-1. Chair=20 - Send the draft to SDP directorate - Send the draft to PM directorate - Confirm the WG about taking the draft to WGLC - Start the WGLC if no objection to above 1-2. Rachel - Confirm with Collin what needs to be added back to the draft and = reflect to the draft. 2. Actions for draft-ietf-xrblock-rtcweb-rtcp-xr-metrics 2-1. Chair=20 - Get XML for RFC7003 and send it to Varun - Start the WGLC of the draft once the new draft is posted and = referecend. 2-2. Varun - Write up a new draft and submit. - Change the reference from RFC7003 to the new draft. - Confirm the intent of the errata on RFC6958. Is the diagram correct or = the text? * Detailed Notes **************************************** 1. Note Well, Note Takers, Jabber Scribes, Agenda Bashing - Chairs (5 = min) 2. XRBLOCK WG Status Update - Chairs (5 min)=20 3. RTCWEB Statistics I-D (including errata to RFC 7003) - Varun (20 min) = https://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcweb-rtcp-xr-metrics= / Slide 2: keep as is=20 Slide 3: errata =E2=80=93 keep the errata for RFC6958 Slide 4: Errata RFC7003 =E2=80=93 Ben =E2=80=93 it is not an errata, = maybe do an update =E2=80=93=20 Varun new draft with new structure as in slide 5. Colin and Roni = supported. Ben agreed too that if code-point is changing that it should be done as = a new draft. Chair asked to check with the ML whether this is already implemented.=20 Conclusion : make a new draft. Explain why new in the draft. 4. RTCP XR Block for Loss Concealment Metrics Reporting on Video = Applications - Rachel (15 min) https://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-video-lc/ Colin pointed out that some text was removed in revision that should = have been kept.=20 Conclusion: In the room ready for last call, ask the list and start last = call. Send to sdp review and PM directorate. 5. Next Steps= From nobody Thu Jul 23 07:01:54 2015 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 26E141A1AA7 for ; Thu, 23 Jul 2015 07:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4qe_Mff1ZtD for ; Thu, 23 Jul 2015 07:01:50 -0700 (PDT) Received: from gator4135.hostgator.com (gator4135.hostgator.com [192.185.4.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C85991A1BAE for ; Thu, 23 Jul 2015 07:01:49 -0700 (PDT) Received: from [31.133.180.17] (port=51254 helo=dhcp-b411.meeting.ietf.org) by gator4135.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.85) (envelope-from ) id 1ZIH4G-0006di-WB; Thu, 23 Jul 2015 09:01:49 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Shida Schubert In-Reply-To: <820C2415-697F-404E-98DB-B9164244810B@ntt-at.com> Date: Thu, 23 Jul 2015 16:01:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <820C2415-697F-404E-98DB-B9164244810B@ntt-at.com> To: Shida Schubert X-Mailer: Apple Mail (2.2098) 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: 31.133.180.17 X-Exim-ID: 1ZIH4G-0006di-WB X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (dhcp-b411.meeting.ietf.org) [31.133.180.17]:51254 X-Source-Auth: shida@agnada.com X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== Archived-At: Cc: webpush@ietf.org Subject: Re: [Webpush] Minutes from Tuesday's session 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, 23 Jul 2015 14:01:53 -0000 My apology, just realized that I sent the minutes to the wrong list :( Shida > On Jul 23, 2015, at 2:51 PM, Shida Schubert wrote: >=20 > All below is the meeting minutes from Tuesday=E2=80=99s session.=20 >=20 > I want to thank Roni for taking notes.=20 >=20 >=20 > IETF 93 > XRBLOCK WG Meeting=20 > Date and Time: 2015.07.21 17:40-18:40 >=20 > * Action Items *********************************** >=20 > 1. Actions for draft-ietf-xrblock-rtcp-xr-video-lc >=20 > 1-1. Chair=20 > - Send the draft to SDP directorate > - Send the draft to PM directorate > - Confirm the WG about taking the draft to WGLC > - Start the WGLC if no objection to above >=20 > 1-2. Rachel > - Confirm with Collin what needs to be added back to the draft and = reflect to the draft. >=20 > 2. Actions for draft-ietf-xrblock-rtcweb-rtcp-xr-metrics >=20 > 2-1. Chair=20 > - Get XML for RFC7003 and send it to Varun > - Start the WGLC of the draft once the new draft is posted and = referecend. >=20 > 2-2. Varun > - Write up a new draft and submit. > - Change the reference from RFC7003 to the new draft. > - Confirm the intent of the errata on RFC6958. Is the diagram correct = or the text? >=20 > * Detailed Notes **************************************** >=20 > 1. Note Well, Note Takers, Jabber Scribes, Agenda Bashing - Chairs (5 = min) >=20 > 2. XRBLOCK WG Status Update - Chairs (5 min)=20 >=20 > 3. RTCWEB Statistics I-D (including errata to RFC 7003) - Varun (20 = min) > = https://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcweb-rtcp-xr-metrics= / >=20 > Slide 2: keep as is=20 > Slide 3: errata =E2=80=93 keep the errata for RFC6958 > Slide 4: Errata RFC7003 =E2=80=93 Ben =E2=80=93 it is not an errata, = maybe do an update =E2=80=93=20 > Varun new draft with new structure as in slide 5. Colin and Roni = supported. > Ben agreed too that if code-point is changing that it should be done = as a new draft. > Chair asked to check with the ML whether this is already implemented.=20= >=20 > Conclusion : make a new draft. Explain why new in the draft. >=20 >=20 > 4. RTCP XR Block for Loss Concealment Metrics Reporting on Video = Applications - Rachel (15 min) > https://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-video-lc/ >=20 > Colin pointed out that some text was removed in revision that should = have been kept.=20 >=20 > Conclusion: In the room ready for last call, ask the list and start = last call. Send to sdp review and PM directorate. >=20 >=20 > 5. Next Steps > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush From nobody Thu Jul 23 09:26:30 2015 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 8D8A41A034F for ; Thu, 23 Jul 2015 09:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 Z-8NItKe_d7j for ; Thu, 23 Jul 2015 09:26:26 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 5E3411A00C3 for ; Thu, 23 Jul 2015 09:26:18 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t6NGQGK5001186 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 23 Jul 2015 16:26:17 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t6NGQGob004640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 23 Jul 2015 16:26:16 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t6NGQFjC020125; Thu, 23 Jul 2015 16:26:15 GMT Received: from dhcp-a088.meeting.ietf.org (/31.133.160.136) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 23 Jul 2015 09:26:15 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_62A43F9F-3A52-42D2-80C4-A6F2A22893D1" Date: Thu, 23 Jul 2015 18:26:12 +0200 Message-Id: <25607271-70AC-4700-8049-3A8ECA41F381@oracle.com> To: webpush@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: Martin Thomson Subject: [Webpush] Publishing events to multiple subscribers 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, 23 Jul 2015 16:26:28 -0000 --Apple-Mail=_62A43F9F-3A52-42D2-80C4-A6F2A22893D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 As a follow up to my comment on in the WG meeting today. I wanted to let = the group know that the SCIM WG is considering an event notification = proposal that sends events to subscribers interested in knowing about = events that have occured within a SCIM service. The subscribers may be = individual mobile apps, or they may be partner SCIM service providers in = another administrative domain. You can find the initial proposal here: https://tools.ietf.org/html/draft-hunt-scim-notify-00.=20 This draft specifies some concepts that are not yet part of WebPush and = indeed includes web push as a possible message delivery protocol (and = probably should not be). I see a lot affinity and similarities that show a good design overlap = with what we have been thinking and the current WebPush proposal. I like = the overlap between the SCIM notify draft and the current WebPush work. = As such, I would like to consider re-working the SCIM Notify draft to be = WebPush centric if possible. While not in the current scope, I do want to be able to allow multiple = subscribers to receive events to the same =E2=80=9Csubscription=E2=80=9D. = Similar to the WebPUSH architecture, we have a publication server that = offloads the job of message delivery from the application server and = takes care of delivery to subscribers. SCIM Notify has both 1-1 to cases = (e.g. to mobile apps) and 1:Many cases, where multiple cloud providers = may wish to know about changes that are occurring in a domain. While one-to-many might not be in scope, I would like to at least make = sure this is possible for a future =E2=80=9Cextension=E2=80=9D draft. = This would allow the SCIM notify draft to be simplified and focus = instead on SCIM event definitions rather than having to define delivery. Note: The SCIM WG has not yet adopted this work. At this stage, it is = just a proposal some members are working on. We=E2=80=99ve slowed down = while the WebPUSH work has been progressing. Now seems like a good time = to revisit the proposal. Thanks, Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_62A43F9F-3A52-42D2-80C4-A6F2A22893D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
As a follow up to my comment on in the WG = meeting today. I wanted to let the group know that the SCIM WG is = considering an event notification proposal that sends events to = subscribers interested in knowing about events that have occured within = a SCIM service. The subscribers may be individual mobile apps, or they = may be partner SCIM service providers in another administrative = domain.

You = can find the initial proposal here:
https://tools.ietf.org/html/draft-hunt-scim-notify-00. = ;

This draft = specifies some concepts that are not yet part of WebPush and indeed = includes web push as a possible message delivery protocol (and probably = should not be).

I see a lot affinity and similarities that show a good design = overlap with what we have been thinking and the current WebPush = proposal. I like the overlap between the SCIM notify draft and the = current WebPush work. As such, I would like to consider re-working the = SCIM Notify draft to be WebPush centric if possible.

While not in the current = scope, I do want to be able to allow multiple subscribers to receive = events to the same =E2=80=9Csubscription=E2=80=9D.  Similar to the = WebPUSH architecture, we have a publication server that offloads the job = of message delivery from the application server and takes care of = delivery to subscribers. SCIM Notify has both 1-1 to cases (e.g. to = mobile apps) and 1:Many cases, where multiple cloud providers may wish = to know about changes that are occurring in a domain.

While one-to-many might = not be in scope, I would like to at least make sure this is possible for = a future =E2=80=9Cextension=E2=80=9D draft.  This would allow the = SCIM notify draft to be simplified and focus instead on SCIM event = definitions rather than having to define delivery.

Note: The SCIM WG has = not yet adopted this work. At this stage, it is just a proposal some = members are working on. We=E2=80=99ve slowed down while the WebPUSH work = has been progressing.  Now seems like a good time to revisit the = proposal.

Thanks,


= --Apple-Mail=_62A43F9F-3A52-42D2-80C4-A6F2A22893D1-- From nobody Thu Jul 23 10:06:30 2015 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 AC08D1A8940 for ; Thu, 23 Jul 2015 10:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnoxyUEuzImh for ; Thu, 23 Jul 2015 10:06:26 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1B601A8930 for ; Thu, 23 Jul 2015 10:06:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27540; q=dns/txt; s=iport; t=1437671161; x=1438880761; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=G8PVVvwYLRIDlk4zpxcPBp+S9k8MglDk6Wtcc7A4b8o=; b=jpuWdPxoIzt35fQwAc+018g6OuAuF1XHYCB1a7pXUkWlkBuGoVS88rK0 mn08EjiU1xomsNlrqWM/2OKAfvC75zlm2M/RNo2jYvzAMuZz0GnrOEsYb iAiGt32S7A48DF85EBQFeKQsIrvRrf3pklJNPIxO77GQu9l0e00mpJ14p c=; X-Files: Support for JWA Crypto Algorithms.xlsx : 18750 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CoBQCwHbFV/40NJK1cGYJ8VGkGgx24UYF1hgECHIEyOhIBAQEBAQEBfwuEJAEBAQMYC2YCAQhCAgICMBsBBgMBAQQTDoggDbU6lhkBAQEBAQEBAQEBAQEBAQEBAQEBAQEXi0yEGHWCaS+BFAWFYI8AAYI2gj9mhl6BREaOd4Q5g2Emgg4cgVNvgUeBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,532,1432598400"; d="bin'?xlsx'72,48?scan'72,48,72,48,208?rels'72,48,72,48,208?xml'72,48,72,48,208"; a="171598738" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-7.cisco.com with ESMTP; 23 Jul 2015 17:06:00 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t6NH60kq027593 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 23 Jul 2015 17:06:00 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.123]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Thu, 23 Jul 2015 12:05:59 -0500 From: "Joe Hildebrand (jhildebr)" To: "webpush@ietf.org" Thread-Topic: Survey of algorithms supported by common Web development platforms Thread-Index: AdDFaSBumnmDTCSgQ8Wmg4wTICViEwAO2PwA Date: Thu, 23 Jul 2015 17:05:58 +0000 Message-ID: <72FE5DE0-479C-4852-AA5C-A4F726FEF5A7@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.150701 x-originating-ip: [10.61.68.231] Content-Type: multipart/mixed; boundary="_002_72FE5DE0479C4852AA5CA4F726FEF5A7ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Webpush] FW: Survey of algorithms supported by common Web development platforms 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, 23 Jul 2015 17:06:27 -0000 --_002_72FE5DE0479C4852AA5CA4F726FEF5A7ciscocom_ Content-Type: text/plain; charset="utf-8" Content-ID: <7BCD0B2E13CA744AB30655AF4D4FF39E@emea.cisco.com> Content-Transfer-Encoding: base64 T24gNy8yMy8xNSwgNzowMCBQTSwgIk1pa2UgSm9uZXMiIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29m dC5jb20+IHdyb3RlOg0KDQo+VGhlIGF0dGFjaGVkIHRhYmxlIGNvbnRhaW5zIGEgc3VydmV5IG9m IGFsZ29yaXRobXMgc3VwcG9ydGVkIGJ5IGNvbW1vbiBkZXZlbG9wbWVudCBwbGF0Zm9ybXMgdGhh dCB3YXMgZG9uZSBieSB0aGUgSk9TRSB3b3JraW5nIGdyb3VwIGluIG1pZC0yMDEyLiAgSXQgd2Fz IHVzZWQgdG8gaW5mb3JtIHRoZSBhbGdvcml0aG0gY2hvaWNlcyBpbiB0aGUgSk9TRSBzcGVjaWZp Y2F0aW9ucyBbUkZDIDc1MTUg4oCmIDc1MThdDQo+IGFuZCBpbiBKV1QgW1JGQyA3NTE5XS4NCj4g DQo+QSBsaXN0IG9mIEpPU0UgaW1wbGVtZW50YXRpb25zLCBpbmNsdWRpbmcgSldFIGltcGxlbWVu dGF0aW9ucywgY2FuIGJlIGZvdW5kIGF0DQo+aHR0cDovL29wZW5pZC5uZXQvZGV2ZWxvcGVycy9s aWJyYXJpZXMvI2p3dC4gIEEgYnVuY2ggb2YgaW1wbGVtZW50YXRpb25zIGFyZSBsaXN0ZWQgYXQN Cj5odHRwOi8vand0LmlvLyBhcyB3ZWxsLg0KPiANCj5Ib3BlIHlvdSBmaW5kIHRoaXMgdXNlZnVs IGluIHlvdXIgZGVjaXNpb24gbWFraW5nIGZvciBXZWJQdXNoLg0KPg0KPiANCj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtl DQo+IA0KPlAuUy4gIElmIHVwZGF0ZWQgZGF0YSBjb21lcyBpbiwgSeKAmWQgbG92ZSB0byB1c2Ug aXQgdG8gdXBkYXRlIHRoZSBzdXJ2ZXkuDQoNCi0tIA0KSm9lIEhpbGRlYnJhbmQNCg0KDQoNCg== --_002_72FE5DE0479C4852AA5CA4F726FEF5A7ciscocom_ Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="Support for JWA Crypto Algorithms.xlsx" Content-Description: Support for JWA Crypto Algorithms.xlsx Content-Disposition: attachment; filename="Support for JWA Crypto Algorithms.xlsx"; size=18750; creation-date="Thu, 23 Jul 2015 17:05:58 GMT"; modification-date="Thu, 23 Jul 2015 17:05:58 GMT" Content-ID: Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQDF3RNAiwEAAJQGAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADM VclqwzAQvRf6D0bXEittoZQSp4cuxzaQ9AMUa2KL2JLQTNPk7ztWFtqQBZNAe7GwpXnLDHruPc7r KplBQONsJq7TrkjA5k4bW2TiY/TauRcJkrJaVc5CJhaA4rF/edEbLTxgwtUWM1ES+QcpMS+hVpg6 D5Z3Ji7Uivg1FNKrfKoKkDfd7p3MnSWw1KEGQ/R7zzBRnxUlL3P+vFQyNlYkT8tzDVUmlPeVyRWx UDmzeouk4yYTk4N2+WfN0Cn6AEpjCUB1lfpgmDEMgYiNoZA7OQNU2I505SrlyigMS+Pxiq3vYWh2 9rta1b3zOILRkAxUoDdVs3c5r+SXC9Oxc9P0MEjb1sQWpbUydq37AH88jDIu12cW0viLwC113PwT Hbd/pIP4zoGMz9NHEmGODABpUQGe2e0S9BhzqQLoIfFtLs4u4Cf2ER2kxtwBGZfTe/47qiLoIX6O uEFwHjlFA7SfwjqymuqOZyAIZGATWrsu/4aRI7g94VYwQ5PxGvQObhn/Kf1vAAAA//8DAFBLAwQU AAYACAAAACEAtVUwI/UAAABMAgAACwAIAl9yZWxzLy5yZWxzIKIEAiigAAIAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIySz07DMAzG70i8Q+T7 6m5ICKGlu0xIuyFUHsAk7h+1jaMkQPf2hAOCSmPb0fbnzz9b3u7maVQfHGIvTsO6KEGxM2J712p4 rZ9WD6BiImdpFMcajhxhV93ebF94pJSbYtf7qLKLixq6lPwjYjQdTxQL8exypZEwUcphaNGTGahl 3JTlPYa/HlAtPNXBaggHeweqPvo8+bK3NE1veC/mfWKXToxAnhM7y3blQ2YLqc/bqJpCy0mDFfOc 0xHJ+yJjA54m2lxP9P+2OHEiS4nQSODzPN+Kc0Dr64Eun2ip+L3OPOKnhOFNZPhhwcUPVF8AAAD/ /wMAUEsDBBQABgAIAAAAIQDeCf0oAgEAANQDAAAaAAgBeGwvX3JlbHMvd29ya2Jvb2sueG1sLnJl bHMgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC8k89qwzAMxu+DvYPRfXGSbmWU Or2MQa9b9wAmUeLQxDaW9idvP5NDukDJLqEXgyT8fT/Qp/3hp+/EFwZqnVWQJSkItKWrWtso+Di9 PjyDINa20p2zqGBAgkNxf7d/w05z/ESm9SSiiiUFhtnvpKTSYK8pcR5tnNQu9JpjGRrpdXnWDco8 Tbcy/NWAYqYpjpWCcKw2IE6Dj87/a7u6bkt8ceVnj5avWMhvF85kEDmK6tAgK5haJMfJJonEIK/D 5DeGyZdgshvDZEsw2zVhyOiA1TuHmEK6rGrWXoJ5WhWGhy6GfgoMjfWS/eOa9hxPCS/uYynHd9qH nN1i8QsAAP//AwBQSwMEFAAGAAgAAAAhALq0cdpiAQAAcQIAAA8AAAB4bC93b3JrYm9vay54bWyM Uk1PwzAMvSPxH6LcWdruQ9u0dhICxC4IibGdQ+Ou0dKkSlK6/XvcTC1DcOBkO3559nvJan2qFPkE 66TRKY1HESWgcyOkPqT0fft0N6fEea4FV0ZDSs/g6Dq7vVm1xh4/jDkSJNAupaX39ZIxl5dQcTcy NWjsFMZW3GNpD8zVFrhwJYCvFEuiaMYqLjW9MCztfzhMUcgcHkzeVKD9hcSC4h7Xd6WsHc1WhVSw uygivK5feIV7nxQlijv/KKQHkdIplqaFHwe2qe8bqbC7GEdjyrJB5KslAgreKL9FeT07+pVMkmTW ITsrdhJa932pK8lpL7UwbUonc7T23FdxglUbWnspfIlU8XSR9GfPIA+lT+ksxlvIzq7og4E4JkSi g7q3ztQYX6qLGxSAuV1KTOxGxB3DLzTOGtCYD+jkT/T4Co35gA4usUCEK+Vc5WhVF8ISk+ksCdNZ /1uyLwAAAP//AwBQSwMEFAAGAAgAAAAhAPtipW2UBgAApxsAABMAAAB4bC90aGVtZS90aGVtZTEu eG1s7FlPb9s2FL8P2HcgdG9tJ7YbB3WK2LGbrU0bxG6HHmmZllhTokDSSX0b2uOAAcO6YZcBu+0w bCvQArt0nyZbh60D+hX2SEqyGMtL0gYb1tWHRCJ/fP/f4yN19dqDiKFDIiTlcdurXa56iMQ+H9M4 aHt3hv1LGx6SCsdjzHhM2t6cSO/a1vvvXcWbKiQRQbA+lpu47YVKJZuVivRhGMvLPCExzE24iLCC VxFUxgIfAd2IVdaq1WYlwjT2UIwjIHt7MqE+QUNN0tvKiPcYvMZK6gGfiYEmTZwVBjue1jRCzmWX CXSIWdsDPmN+NCQPlIcYlgom2l7V/LzK1tUK3kwXMbVibWFd3/zSdemC8XTN8BTBKGda69dbV3Zy +gbA1DKu1+t1e7WcngFg3wdNrSxFmvX+Rq2T0SyA7OMy7W61Ua27+AL99SWZW51Op9FKZbFEDcg+ 1pfwG9VmfXvNwRuQxTeW8PXOdrfbdPAGZPHNJXz/SqtZd/EGFDIaT5fQ2qH9fko9h0w42y2FbwB8 o5rCFyiIhjy6NIsJj9WqWIvwfS76ANBAhhWNkZonZIJ9iOIujkaCYs0AbxJcmLFDvlwa0ryQ9AVN VNv7MMGQEQt6r55//+r5U/Tq+ZPjh8+OH/50/OjR8cMfLS1n4S6Og+LCl99+9ufXH6M/nn7z8vEX 5XhZxP/6wye//Px5ORAyaCHRiy+f/PbsyYuvPv39u8cl8G2BR0X4kEZEolvkCB3wCHQzhnElJyNx vhXDEFNnBQ6Bdgnpngod4K05ZmW4DnGNd1dA8SgDXp/dd2QdhGKmaAnnG2HkAPc4Zx0uSg1wQ/Mq WHg4i4Ny5mJWxB1gfFjGu4tjx7W9WQJVMwtKx/bdkDhi7jMcKxyQmCik5/iUkBLt7lHq2HWP+oJL PlHoHkUdTEtNMqQjJ5AWi3ZpBH6Zl+kMrnZss3cXdTgr03qHHLpISAjMSoQfEuaY8TqeKRyVkRzi iBUNfhOrsEzIwVz4RVxPKvB0QBhHvTGRsmzNbQH6Fpx+A0O9KnX7HptHLlIoOi2jeRNzXkTu8Gk3 xFFShh3QOCxiP5BTCFGM9rkqg+9xN0P0O/gBxyvdfZcSx92nF4I7NHBEWgSInpmJEl9eJ9yJ38Gc TTAxVQZKulOpIxr/XdlmFOq25fCubLe9bdjEypJn90SxXoX7D5boHTyL9wlkxfIW9a5Cv6vQ3ltf oVfl8sXX5UUphiqtGxLba5vOO1rZeE8oYwM1Z+SmNL23hA1o3IdBvc4cOkl+EEtCeNSZDAwcXCCw WYMEVx9RFQ5CnEDfXvM0kUCmpAOJEi7hvGiGS2lrPPT+yp42G/ocYiuHxGqPj+3wuh7Ojhs5GSNV YM60GaN1TeCszNavpERBt9dhVtNCnZlbzYhmiqLDLVdZm9icy8HkuWowmFsTOhsE/RBYuQnHfs0a zjuYkbG2u/VR5hbjhYt0kQzxmKQ+0nov+6hmnJTFypIiWg8bDPrseIrVCtxamuwbcDuLk4rs6ivY Zd57Ey9lEbzwElA7mY4sLiYni9FR22s11hoe8nHS9iZwVIbHKAGvS91MYhbAfZOvhA37U5PZZPnC m61MMTcJanD7Ye2+pLBTBxIh1Q6WoQ0NM5WGAIs1Jyv/WgPMelEKlFSjs0mxvgHB8K9JAXZ0XUsm E+KrorMLI9p29jUtpXymiBiE4yM0YjNxgMH9OlRBnzGVcONhKoJ+ges5bW0z5RbnNOmKl2IGZ8cx S0KclludolkmW7gpSLkM5q0gHuhWKrtR7vyqmJS/IFWKYfw/U0XvJ3AFsT7WHvDhdlhgpDOl7XGh Qg5VKAmp3xfQOJjaAdECV7wwDUEFd9TmvyCH+r/NOUvDpDWcJNUBDZCgsB+pUBCyD2XJRN8pxGrp 3mVJspSQiaiCuDKxYo/IIWFDXQObem/3UAihbqpJWgYM7mT8ue9pBo0C3eQU882pZPnea3Pgn+58 bDKDUm4dNg1NZv9cxLw9WOyqdr1Znu29RUX0xKLNqmdZAcwKW0ErTfvXFOGcW62tWEsarzUy4cCL yxrDYN4QJXCRhPQf2P+o8Jn94KE31CE/gNqK4PuFJgZhA1F9yTYeSBdIOziCxskO2mDSpKxp09ZJ Wy3brC+40835njC2luws/j6nsfPmzGXn5OJFGju1sGNrO7bS1ODZkykKQ5PsIGMcY76UFT9m8dF9 cPQOfDaYMSVNMMGnKoGhhx6YPIDktxzN0q2/AAAA//8DAFBLAwQUAAYACAAAACEAQb/4YNkAAADK AQAAIwAAAHhsL3dvcmtzaGVldHMvX3JlbHMvc2hlZXQxLnhtbC5yZWxzrJHBTsMwDEDvSPxD5DtJ uwNCaOkuCGlXGB/gpW4b0TpRbBD7e4J2odMkLpws2/Lzk73dfS2z+aQiMbGH1jZgiEPqI48e3g7P dw9gRJF7nBOThxMJ7Lrbm+0Lzah1SKaYxVQKi4dJNT86J2GiBcWmTFw7QyoLak3L6DKGdxzJbZrm 3pXfDOhWTLPvPZR9vwFzOOW6+W92GoYY6CmFj4VYr6xwiseZKhDLSOrB2nNFzqG1VRbcdY/2Pz1y iaxUXkm1HlpWRhc9d5G39hj5R9KtPtB9AwAA//8DAFBLAwQUAAYACAAAACEA++hdR2ABAAB1AgAA GAAAAHhsL3dvcmtzaGVldHMvc2hlZXQyLnhtbIySwWrDMAyG74O9g/G9cbp16xqSlEEp62Ewxra7 4yiJaWwF213bt5+SkDLopTcJSZ9//XK6PpmW/YLzGm3G51HMGViFpbZ1xr+/trMXznyQtpQtWsj4 GTxf5/d36RHd3jcAgRHB+ow3IXSJEF41YKSPsANLlQqdkYFSVwvfOZDlMGRa8RDHz8JIbflISNwt DKwqrWCD6mDAhhHioJWB9PtGd36iGXULzki3P3QzhaYjRKFbHc4DlDOjkl1t0cmipb1P84VUE3tI rvBGK4ceqxARToxCr3deiZUgUp6WmjbobWcOqoy/zrnI08GcHw1H/y9mvdcF4r4v7MqMx32ruOrd Dl5/OFZCJQ9t+MTjG+i6CXTYRbQg9f0SSXnegFfkHoGix8urGxkkYTtZw7t0tbaetVANTUvO3MiJ I4oDdv3o8omzAkNAM2UNnRfojD2WVYhhSnq5lw+T/wEAAP//AwBQSwMEFAAGAAgAAAAhAPvoXUdg AQAAdQIAABgAAAB4bC93b3Jrc2hlZXRzL3NoZWV0My54bWyMksFqwzAMhu+DvYPxvXG6desakpRB KethMMa2u+MoiWlsBdtd27efkpAy6KU3CUmff/1yuj6Zlv2C8xptxudRzBlYhaW2dca/v7azF858 kLaULVrI+Bk8X+f3d+kR3d43AIERwfqMNyF0iRBeNWCkj7ADS5UKnZGBUlcL3zmQ5TBkWvEQx8/C SG35SEjcLQysKq1gg+pgwIYR4qCVgfT7Rnd+ohl1C85Itz90M4WmI0ShWx3OA5Qzo5JdbdHJoqW9 T/OFVBN7SK7wRiuHHqsQEU6MQq93XomVIFKelpo26G1nDqqMv865yNPBnB8NR/8vZr3XBeK+L+zK jMd9q7jq3Q5efzhWQiUPbfjE4xvougl02EW0IPX9Ekl53oBX5B6BosfLqxsZJGE7WcO7dLW2nrVQ DU1LztzIiSOKA3b96PKJswJDQDNlDZ0X6Iw9llWIYUp6uZcPk/8BAAD//wMAUEsDBBQABgAIAAAA IQBwba3KEQ4AAP9VAAAYAAAAeGwvd29ya3NoZWV0cy9zaGVldDEueG1srJxbc+o4Esfft2q/A8X7 AOZO6uRMDRgOd8xld585xEmogTgLnNt8+m1Zsix1O2pNLS/gyD+1Wq3+S7JN/On3n+dT6Xt8uR6T t8dyUKmVS/HbIXk6vr08lv+1G/3WLZeut/3b0/6UvMWP5V/xtfz753/+49OP5PLn9TWObyWw8HZ9 LL/ebu8P1er18Bqf99dK8h6/wZnn5HLe3+DPy0v1+n6J909ppfOpWq/V2tXz/vhWlhYeLj42kufn 4yEOk8O3c/x2k0Yu8Wl/A/+vr8f3a2btfPAxd95f/vz2/tshOb+Dia/H0/H2KzVaLp0PD5OXt+Sy /3qCfv8MmvtDZjv9g5g/Hw+X5Jo83ypgriodpX3uVXtVsPT509MReiDCXrrEz4/lP4KHXaNbrn7+ lAbo38f4x9U4Lt32X7fxKT7c4icYp3LpryQ5bw974VsPBk3/uRQBP8lCMUZfk+RPYWwC1WrQ7DU1 IprdH27H7/EgPgH9R70B4/xf6QkcgxtV7Yd5nPk0Ssc1upSe4uf9t9Ntk/wYx8eX1xs416w0IVIi YA9Pv8L4eoCRgsYrqdlDcgIb8Fk6H0XGQaD3P9PvH8en2+tjuVvpdDqNZqPTKpcO36635PwfeSIQ XumKdVURvnXFVqvZ7jL1oJ9pg/Ct6gVBpR5w1aBHaTX4VtWa9UqzGTRr7brbUTib1oRv7ahXD9uq Inyrir1KUOulgbnefomRD+CcI0YdZQG+lYW2tuCoBpJPPYbvrJqzmQDyL60gDnQf+ZgGevDhQNfL uuhwMMgGXxyoih3ds6/x9TY6ikR0e51lQpCnAvTY1WyWBEGeBR2/JAiyLBAHyuNepd3m00cMsQxu ngfdSrfb7rA5G2TjLw5Uo20/dQVZDogDPTQ++gp6mb9wkNUUa4hPwtazTBIHqjL47hiTepZD4iCr 4RVYMeOlgRUHqiZMXbqP7jSqynksnSPD/W3/+dMl+VGCJQzcuL7vxYIYPIheiBmx0ahooepZ8oMp EqY4YeYPYQcmw3IJ6l9h3v7+udH9VP0Oc/FBIX2JQJg10mzZyIAircBGQorUbGJIiSYyMqJID1n5 UoCgDo0pgtqZUKLRtr2dFiAoKrMCpGNbmUtETGg6uA0bWRQgTdSjZUFLyMyKIl3UpYgiHRTdNUUa TdvfDUWaqKEtReq2kR0luj2NVEEDWggwNVtCEIrIpCx3D2lBumNoCX0U7hgyOQhrj2X41MOButen BBr2gSRg7tY2UP/DAgJl4FAi4K42glJnRIkeMvKFIihxxiwxYYkpS8xYYk4J1N0FSyxZYsUSEUus WWLDEluW2LkIK/1hUblj+gtrsI4YWYfTnxI4/SUB+w+dubly0zUnpEQb6X8oEVf6U4KkP0VQUo0p gQQyYYkpS8xYYk4J5OmCJZYssWKJiCXWLLFhiS1L7FyElf4wy94x/YU19+xPCZz+koBPnf4BWkRD irTRaj2UiCv/KUHynyIou8csMWGJKUvMWGJOCZz/LLFkiRVLRCyxZokNS2xZYucirPyHafaO+S+s 2dN/gLYU/QIEzd0DicBnrgCU3iFF2mihGUrEpQBKEAVQBCuAJSYsMWWJGUvMJQEXoTpodbRrXFAj SCRL3siKNRKxxJolNiyxZYmdi7A0ADlyRw0Ia/YaQDRQgGANSARkrIczQAkeUqSN1pKhROBTW0Ej PqIE0QBFsAZYYsISU5aYscRcEk4NUCMoIkveyIo1ErHEmiU2LLFliZ2LsDQAQbujBoQ1Zh0oQLAG JAIy1tkboAQPKdJGs95QIhAIbQWN+IgSRAMUwRpgiQlLTFlixhJzScCn7i5ZB6gRFJElb2TFGolY Ys0SG5bYssTORVgagJuYd9SAsMasAwUI1oBErHUAJXhIkRZKzqFEXBqgRA+58kUi4ka7Tq0eSpyx ZCDiGsHZN5EI3J/QSAdd308lYrqLOjRjiTnvyYJHljyyoq6goES8kTVrZCMJ8dRCxy2ooc31VkJm bIMaGsYdY8hSBLR2R0UIa8yqUIAg/wcSsVYFlB0hRVooxYYSMVMMjdqIEkQREnErQjJORUgEblno kSWKoM6gPs9YYs57suCRJY+sqCsothFvZM0a2UiCUYSEzNhSRTCGLEWIJy13lERqjlklihgsCsVY 6wRK+bCAaaM7S0PFuHRRgBBhKMatDAU5paEYc0broklvWuAQFgePzD28WXgwSw9mVeAOVoiHmTVv ZqMQRiSKMqNMVcKZsmUinr+Zj5dh4v8/nqqJX2CgpaOOUrdfwAREJtKOuXjUUTqFyo7JtNDtp6Fi nDKRTZkIuaooMIMyd8wjEx6Z8siMR+YFCErbBY8sFeKS/Yo3E/HIWiHy51zixwobvtKWR3ZOxJYB SOqeMhDm7NWCyoAyVAaSMVeLOpJKKH6yBG2ZTAsxQ8WYOY4SYlSAUBlQl/EkPy6wg6Qy4ZEpj8x4 ZK4QVwYvCsyg0Cw9zKx4MxGPrBVST3+YKIUgQ+4YuS1vd6eQDwJhK0E8kbvjgiAf8Jn7OqoEylAl SMac7Otosg/F7+5ACRaD7sUOFWNGIkDjPVKMGXO6caI+d9FCNy5oi1xkK0Z86YuKJnJo6gPNfKC5 gszuY5cWHszSg1kpxuwZvlyKPOystR3xa10pChp8sg3a6mp5YAm0K4CMYbSFATPsPYUhzHFLBGWo MCQDnzp/6vjmq/h5KRJGC92cGirGlRkjxVjCQAL7UsCg+X/MIxOF5BPhlK8045G5Qly9XHgwSw9m VeAOEnbEI2uF5JHY6JJ8xPEqvPVgdor5IBZ27sOces/cF+bsG0x0UaAMzX3JwGee+yjEofh9NM59 xAwV80Ek0jlnpBh37su2TIbkPotMVEv5bnha0DayO+ORuUJcvVx4MEsPZlXgDgp6xCNrheSR2OiS fMTxmrL1YHaK+SAWdu7DcN4z94U5bt4vYNCAD8TP+MGONe+TG0mSMfXRQWvDUNkRC6EWEd6AjBQE 5jRDLw5kYyaDfB4rM/lcNvFpfeoDzXyguQ+08IGWCvoggdIpY+VjKPKB1grKA7fxqbbNIDMB8Nju MuiDBLC1AP29pxaEOW4dKGBQXg3Ev6OgOb6BNuNhAdMheyBph9GChMw8p1qgDPJ5rPzJ57aJKnG2 PvWBZj7Q3Ada+EBLBUGf9eyALypWPoYiH2itoDxwG59q2wxya8GdALYWxPO5O14o00eCdE9UwKC8 Gohb+WhdaJA7p5IxQ9FC+/ihsmOlOVpfRkUMuij/ohi4jaGTw7jCSifKsWJcCTTxYKYF/qDwzHhk 7tHSwoNZejArxbiiE3nYWWs7+TWyHGNz/NAObKsqOZCdu21bD+Lp3B31QB8IUj0UMGjAB+KJCl4b 0O3RsIBpkX2StGMGq0f0UMAQPVCfqR4k49YDz0xVv0yfUXhmPDJXiMubhQez9GBWijH3Ijg6kYed tbaT64GODdEDi+zcbVt6EP+reUc9pOaY6wbFmNFroBwdKMac+5t4r6QY89qiixJnqBhXVowUY+Zf D60zXxSTb23HpGTi0dbUg5l5MHMPZuHBLD2YlQcTeTBrxeQx3HjU2nowOzdj57t4jnq/+b/u8SS5 gKH5Tp8kN5EmQmXH1ATNd2nHne+Sced71q9sZhrrXmQlE1Xiamvqwcw8mLkHs/Bglh7MyoOJPJi1 YoxLAI9aWw9m52bsfBdP5u6Y7/JBn7kTJPudumTc87tkzFxukfldMu75XTKuHBwpf9z5Lu3kc9NY 1cpLJqrE1dbUg5l5MHMPZuHBLD2YlQcTeTBrxeQR23jU2nowOzdj57t4iGTmu/vf6wUN2xXzfQdN tO/u1xUkX8QjHu0NaFFIi6aqSPy+Q19VdnLrtt8gBctvcEvc85LvADFeHODuj7ACFU3N9ND9o754 cY+Esql8QItCWjTNivJAzPIio4to8zQHKGtpYRwv88rZ6ZVxOjKO18bxRh7b0YNIWdFzR0nQMOqg eT0uXXQF1K8rKJ++B7QopEULVWSPem7d9hsmE8tvMS5Q9jdHXViB/pgzU1BD02lfnBZU+rKt9I7G gBaFWVHPGDJZETqUDdNSUVYfu+hCZZVDWb0IirLjtXG8ydC2Pr01Tu/ksR05cePAX+fyNoMQpB7x Zj4maTT6EJk0QHm2DmhRSItWqsiKRgfdzdpkkNnFdCjsbomLO/9uyUtBq1tdpL5+XUFmt0hRSKlI FVnd6qEbDpsMMruV5o7VrQa+ynTqM6UhU0GB+WjhbuVQllEDWhRaRbZLYofrHemG3A+LXyhpl7r5 VC4TKIdyl3S9rCik1CYrMoIIRVDD9ljsUUyPxWQBZX9rshg1hJV0bck82lpFdpOwidNNgnjcwyZg NGxtNCn0GxrKmh/QotAqsj0Si3EWBNYjAcsg6VFro1sE/YaGco9IUWhRtkfmys16pNZeM4/a6EKv 39BQ7hEpCi3K9shcDVmP5DpnZXaHjJqGco9IUdgwi2yPxBLiPWpqvTFj1CGjpqHcI1IUNswi2yNz /WBjBLBOoG4+BUqL8o2R8m1o5/jykr5b8lo6JN/E+x878BIzXareeVlvPoj9InhOzrThTDoNkDNd OJMuGORMD86kcy4+02g8CCkVtNOowZla0Zl6B6yly3RVm4M3V77vX+LF/vJyfLuWTvEzdKxWgeBe 5Lsv0+Nb8p6WQqp+TW7wAsvsr1d4/WkM22bxKszSc5Lcsj/AMWF3G9++vZeSyxFemJm+0fSx/J5c bpf98QYtPByfHsuXyVM6IcLrQE9xtL/cdHwDiK8uzen0KqSqT0APqvrVrZ//BwAA//8DAFBLAwQU AAYACAAAACEA1ohQeh4IAAD2WwAADQAAAHhsL3N0eWxlcy54bWzsXO1v2jgY/37S/Q9RvncBBm2p gGnQ5jSp601rJ91XAwZ8TWIuMSvsdP/7PbbjxLyEZLyFdt6kLQl++fl5tx/brQ9z37O+4zAiNGjb 1XcV28LBgA5JMG7b357ci2vbihgKhsijAW7bCxzZHzq//9aK2MLDjxOMmQVNBFHbnjA2vXGcaDDB Pore0SkO4JcRDX3E4DUcO9E0xGgY8Uq+59QqlUvHRySwZQs3/qBIIz4Kn2fTiwH1p4iRPvEIW4i2 bMsf3HwaBzREfQ+gzqt1NFBti5e15n0yCGlER+wdNOfQ0YgM8DrKptN0oKVOa0QDFlkDOgsY0ApI JVq9eQ7oS+Dy3+BrXKzTin5Y35EHX6q202kNqEdDiwFpAJn4EiAfyxI95JF+SHixEfKJt5Cfa/yD oGZczicwNv7R4UAknE6rz0tt6Csc99u2G//htYp1uNT2lnYr4s9p2v0YEuRZ3wICgomtz4+81zVK FQd+Wa1UigPP58AWKjV7QKbLQ3ZGMth9DNHaNLBj9JM1pliEgYKn5Nhl41DiIUQyAlklnpfYjWtu IeBDpwX2i+EwcOHFip+fFlOwDwGYWi4zjiyXU3ocokW11iheIaIeGXIU456wSgmZuUrzZvrxDyQY 4jketu3LumhdA1wUXEZft03+9zR99S7v3N7dgQfgur2rIzQKzfYOjvSu28xuVMgYyGifhkMIAzTv pr51Wh4eMRCLkIwn/H9Gp1xIKGPgNDutIUFjGiAPHh3ZynJNiB8gVGjbPh6SmQ9yJ33hmtQ5vJud e4HeBb7CvYnSOw+GTSBuUUNZ1RNtIArO1vIplELFgf6K/IXKS04dh1EKQC5z0zHuIjtbyaeRG9re UTqXeohls1vjf4U+an2oIefUSAdcsEIeW9dB/SxjcxBrY5R0LB24Uuozg1OQLiVLQGyMwbYPsOc9 ciP81ygx8A2wXvORFcx812efwMfDdIZPK9QjBCXxo7Tp8gUYkVWpDvXjSvCoV7LQdOotHmZ+H4eu mA6K3sTXrnA76ftHj4wDH/MJFgASRb6ElOEBExNUEZ5kIWikCOCxDARXKYJLHQG8bKEBnzqmw92H As20f4ByTAo4ukxJCdOE631lJ+my5qNcMeNiulk2k9qS1hodxXw7S2pqaYPvdZrBi4IjG5Rsqsas dAEEn8nL35QYq/elzjstpKSaL7UwMuDrAgMQciyn8/NRtlpp8GDoKUtz4B0PEHSsGHCO9NLgnQe9 suxiwkAlM8djWZZhTCCAkC1ZYwXpcGIMLSqpgc5SMYaXo2oZBFW29RKi6ROeg5EVlsDZpm9ZQIGN rwMoDOC8gILzU6xf0kh42Qx0S5ABdfLa2lJ7i3uWSEAhhB4cTu6ztD8ZvFK1crxLCRTZj4X71c7i RmIIgRv/zCDc/BLiEZmfwr9nhWwJJMB8ZNucRRVwG1ItypXRLHhnokKaRK7G/MtGZVnDD2diStDh rIAikRgVUCyP2T1RzJwFL5GYcuFpEgOPaSyUwNs6y80yGCAGUt6ObzCyIECuuGwIAO3QEMRUFya3 2jrK0ipKMhO2eIa1bXfRUIHgoe6MeIwEfF5bu+JLiavF/6A0KQ+GVi8vEoer5R/wjIXIU10At/Uq 15u6eOCLLkkNLnMpKCFra32AC1QdgCPSikPWG8aQzv6BKsN5uqpUq8PEHz5AckmkqPsylS0qEe05 YiF5jtPaEgGFXFMQ6Z8gYMfBUKtEZ8wjgV4kmqAhfdGKzOSzSqDx2bYwtPJzH0WYt8CHkOQ24+6z 0/NPxMeR9YBfrK/UR4GozPc4xEBUXyr/DDYuL7WXpt5WMgfriTeZ1tuUeEPJmsKEhuQHkJuvKoxx gIV0rC00WAwI+pUy2DTBt3qAFKTTInjhSOJlqL9nESOjxT2K2D1QS5SNJiEJnp+oS+RSFd/IAXtE /uRJI14AKCoNmaXSQd+moqJ6vYU9EvyDzCZtXEFdIYaeDypUPme9dbX5vPX21fJqtV1RFoacUp4r hSQAPAgFEP8YJq1S8QyZZExV9i4EY6oKmR4tdVaovNGC2Gm8EYeNZoyq1UXjrOMNH0vp5pL9QCGt VJ5dd+yFKqZxgAkDWCGKGQO4uwHUNhSvbaLauMlX38L6c9OV1e17K1qs5isxjHRXn2OM4BkawSIz FhMM7xEMmzDgzAPhQr7paGHAa9StLR7moAtjxtP8amtjRhuyT4AYbTDacP75EuMbTN5EHO3ZutKz S97E+AbjG8ShMpNFfKW5dOMbjG84jm/IyambbQ7Lh7b33eZQ7pKJYTacuRaHWgvx4U0zW63LJWen zJamlQsa9mX/m0oQmDSZ2IDHU3ZmY9+26xpWJ6iFLK0yRqfeK2DCGxPe8JOMZsuuvFXmp5aejGaH v87+7HKZ/WpWME2YZIxpIVU5rzApPm0SnwniLFw+WZJ7IdWGnSq5ddZ3LeZW2TAly62jKL3pRMmr sSunPVf1thPm2omiTXIv5UUp8SHECxYCzjT9vO6u5BW3/ARaqZtfxX24Quj32/wKBsPetrAFZ0RP NaW3yrKuwEsp0/CwYgS5KsChU8bveBZ3miVncWFGNMQjNPPYU/Jj206fP4v7J+FIblzqC/lOmWii bafP9/ySy6o4eQvnJe8jWHyF/61ZSNr2v3fdq+btnVu7uK50ry/q73Hjotno3l406r3u7a3brNQq vf/g4Cy/EPsGLofe48JpcTE2XAtVrd9EHlxLHcaDjcE/pt/atvYi4XNlcAC2/FcMwhH7kcWF3Z3/ AQAA//8DAFBLAwQUAAYACAAAACEAgy/oZb8EAAB4DgAAFAAAAHhsL3NoYXJlZFN0cmluZ3MueG1s vFfdkto2FL7vTN/hjK82nQFjNrvdZsA7xAsh+wMMTnbTq46wBahrS44kQ+jT9Fn6ZD3CkDiSl+aq N8z48/nT4XyfjnvXX/IMNlQqJnjfC9odDyhPRMr4qu99/DBqXXmgNOEpyQSnfW9HlXcd/vxTTykN 6MtV31trXbzxfZWsaU5UWxSU45ulkDnR+ChXviokJalaU6rzzO92Opd+Thj3IBEl133v9TmmKTn7 XNKoQoLOuRf2FAt7OryhKpGs0Fhiz9dhzzdw9YpNYxviIqXtP5UNz8YzG7p9iv3bp6ENk2zlM65t eBx3Ly5t8Pehnd805Y0qSILNwlMrKjfUC9EObN9xfH712gUvgq4NYqE2hEXa0LypwHlTknnckGTY 5D6Z/mKnGTZFHDZFbOjtPB4Ef1zYIRFtTQdD5w8aRjfjltPhcJhlZhoSiEpsLtyw5ZLR1phmWU44 DAscQypJBrEmaGUnGwTdq7snG51MbWSAf7drh+RwDDFg9DZyYPRvgtH6XfTQZN0Az3Z67U79vFzs 7ABvkTfJLiJKZ9R+d0s2BG6jgY0PeCoFS234oyIrJ8ZzurTtoqaJaU+GH2xDM/0tiMuiEFLDomSZ BmSYgIwtJJE7v8iINnphO06m6DcRGlTlS1P0+0+vs0VG+PMrdP3In7nYOqoxI5LkMCG5c8opalcc 39t14AEcHqCgxDS5ZwvbOGoiSNREkKqOR5LZIZAQ2LImSuzftGZ3URy0HhuoZPxwjmDrAw4aLJiG Z+oMS80Kp/SU1R3dwZMkxQ8ErJueiIqkjgcm3KxlrJI9h/GCgXg82CNrotZ2Q2pOKJqWk0GM0z9/ n3C76AaWG2rg3s12Gj8MIlNfvR43dN3qWMCpSC9lwz/UTmaHqZkcM7n11IxeSoUTe7zq4aLt3DJf B/qrUad93u7Y1cx2kdwVSN7D1gDdtnMtHm1e9GUKCCRVHBQBQPJDs9bVdQ2a3Iy4OXmO3Gz0aFgF DkoIpaIK6intyIY5qOo/QIeD1QkmGBmHoP1b+xy2TK9B4nPLbE9KOYqwl/Bf7WpQl65tbDK1oRdX kmtnJ7lG0RxwtaWy6tySSdzzWG42GbMionhrkPRzyRCAXEiKT4oSmTiUNZqJ0Q6qj8ptXIVeY2gu eOubouO2aaLsY6ZwFgmeEA13N6NX7tFMxIl9H2BMUAVNGK4BKa6UfMlWpcS7H+s9QyKfiDiN4RME nfYlnMV4U8A9FQWRqZP5oVsNvV3REW+es8bL+1gNCusNlWxT1TnC27squPHgsbMAPjGeiq0Cjv4b 5x77NIN45jD8keEqbx9hD6J1YL/ADM7ATeLYHNV0vMZeZA3+vTsY4VQsxZfvA8mwJ2f4w3xc2v+C DcnwOyPw8CkRGdJerhZ9bzTCb4Kg0zGwHAmuK7uImA2BGXRJcpbtKrhrgP3nBq2AnHEhDejvU+lw TjNK1KEtpoJDEf9XAc2U+0YHXGOSrEyrfUavsaWyqhjEEpRY6i1BaplbETcjKquO4iFqnz5mar/v tA7NONtYhPQqMmr9Kzp8HMzf7/ey9xwzljJBQu8putSUQ4qjIhk+Y4lIoQNbkVx5wTLEROl8IFUB 7fQVWpMkH78cw38BAAD//wMAUEsDBBQABgAIAAAAIQBgQQnkUQEAAGYCAAARAAgBZG9jUHJvcHMv Y29yZS54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACEklFLwzAUhd8F/0PJ e5s201lC28EmexAHghPFt5jcbWVNGpJot39v2m61Q8HH3HPy5ZxLstlBVsEXGFvWKkdJFKMAFK9F qbY5elkvwxQF1jElWFUryNERLJoV11cZ15TXBp5MrcG4EmzgScpSrnO0c05TjC3fgWQ28g7lxU1t JHP+aLZYM75nW8AkjqdYgmOCOYZbYKgHIjohBR+Q+tNUHUBwDBVIUM7iJErwj9eBkfbPC50ycsrS HbXvdIo7Zgvei4P7YMvB2DRN1Ey6GD5/gt9Wj89d1bBU7a44oCITnHIDzNWmWLAKPoI524PJ8Gje 7rBi1q38ujcliPmxWJV7CB78pm2Gf6se2nXoySACn4r2Hc7K62Rxv16igsQJCeNpSNJ1klIypbfp e/v4xf02ZT+Qpwj/Eu9aYkwouaExGRHPgKLLffkzim8AAAD//wMAUEsDBBQABgAIAAAAIQDcWXjt 3AsAALQbAAAnAAAAeGwvcHJpbnRlclNldHRpbmdzL3ByaW50ZXJTZXR0aW5nczEuYmlu7Fd5NNTr G3+tpWsva0mKso+d6DbJdCUma5Yxdt80GPsuxrWEEJUllFHWLINCssSPe8kIRdMokSVZsmXf4ved ln/6655z//id8zs+73ne53ne932e830/Z545z4sFWGAAjMBFIAO0gD5sGQB5eM0LQMAR+MMiAxSB HFAAqrDlCH4FHSNgfg/6BI13AD0doANT+9z3OsKaA5jDPj08M8CeHpzNBx4QnPffg+5HCkZY08Py 0/81s4GRjumI3K+r/97n/5aC8wRtAECT72gCyQw/7V/1zw0UHyfA6jKAK1q0r/8OGm+/Qn5UkYEJ XtyB92jyM/7Xc7v+/zcDv/4ymuDrGqNNLtBuzQnKgfm3mnIHAeAIMAPucH25wHUMATe42mg1fAQo AxVYlGHLABjDUXqQnSPOzemcoxMEgIGdE2SMC4LgVR8fyOubbwQ54dzdAED5erhCAT/URXcTX7y9 KwSMIG93V18f2gkVObkAWBw9cLSv+WdA8QEgf9HInHYvVtj+p9jA867vhetgnoUTDqEDe45oHjjE SotGG2v9QdO9LLQZAOnvCjDQfa+rk3IA/lejxdCBcaUfmz8UAnHJzcEd7+EFeXtDjjIoOx87BAJ4 WnBuB7KMK2np/m3J5nrIjCur//F+DQK6gqHznafsU93RodaKuenHA/vyqntF8eiRd7z8hoICbaXH NKpH+xLQayyEKN6HD4owTGlEU+fJD1USuMwPx7kNUDrnJDQr78cUchee5+Tae/8IKsz9sl9IMOGG 6ru6TEpvZvDmYP9c54tM1cfWqk9cJ11lZWzOZH9KzezPsFR/dz1kTZ44cV7kiW+lgMiWSuGQD1OR 5HzoyOFWDJ5dVvNS6RbmUwtZ2OqG5IOrfE/8pXZkF/3DEPluEblr7X2lqhrIyKmDZGIdMyXiOiQv kXoyd3VwOJhDasdAoOhruO7sRdwii1soau2sMCXpCx6PENdeFhrLTL2/QVqgcyOY5L/tkknEefP4 nxQTv5opfaA1qGF1L2LM95z5GCrmGeT3oeHa0ox5rLPwWuD1hUq/4sd1v5cZuykaChmEXl8XliTE mi0a35vKulQ4+GalM36DNUC8Yy2hWsjp+Zza2gfJHYnZTe0xwoutRqiK7b2XTmZHzaY9cX6mZA4i Ezmyi+YnHQQrZ3hNPXISC8Qt6KrbVUvDVYjSs/ENNX5CnklOT63WGU4FFS/oe27iyQiH7dtkZGcI sw8pZAUbsWbVxCFQkS5vg63YTz+iz/moopeP+lW2bq4GQZoWqfN8fXn2TR2PriFbf0KwI3n4aLnl 0vYe/tET05uJGPvAF0UcOjOK7JbLXMWhunsIZYyUOR9DoZUH0i5XKghIUiN6059Vj2sgVMqP7N28 8oQ36cuBv4fV8Z9Kup7J41YmUrqt7ebt0wxUl1+Js/UyMk2MFmrjwjCvVFAOQ5svMfqGyUEKqR1J 9D6fw2Lvi9jq1d1gt+vgU0oTvNdaSfGxOHZcXC9T/GyrStWqWL3vtRSiYyhKndSSSzHRTTDSbrqk RbEME4mv5Y2au5ZXddPtzCazLb7gM1NdeJFees4frZSXggqzvdpZkTuKoblbsoNBSHnU1Wp9BWtK cPD6IDGh5mWX1A7vE751iprkVo+pv0zRGNnd9nT2VtAn6sbo5mcdl/dx22v1CAkCTrkoLWUHsRid vHqp+ckGRWqdasFPx5Q1jpw/et+GsLPcP1soGbozjWQXHvBxORF0RuK2/VC9+xrXwSHmrFkR54gL bR4VPQycpsdQxhw3KDZxLmJ/JaMlc7v3kpDSovtEh2vjgq7IsRXVluQczdCyyfYsjKoo9RiaiiwJ QllrlKK5yvVetBaYP47ykJ3Jmcc+oJvwzGOgogP8hJd71DhnsuugHFN7BhOH4L/EzG4ru8ZN6B4t XuW8YqLuIeYsG+40nkrKb7BfdKpIS9Pw8NWMI17zZdPC9J8zdZ1R6bpWYtnnuwRtxFUJt7Bj0SzB iNUlng3pmf/c9+eqJuQwmGmIVh2spvz2NAHDXew9oZIBxYakPDtPiBogSh3fOB8e8jdeQ3ihNvq0 9pyWNR8nz+BQE9SRJ4IojMnK647bscdqcHtcGuexlJcuYfdDRuVIMWJLeUmXzff3m5grPVxr7mNj K/QfIVc3IsKj5PND12Jt6UkxUboVciR1FqRXhMtp6WnliZtQtSSdWcNY1VT+aphMHXYIc8amIHDe KiEuhuQ7VBvl1iogkJ2KC3mj3yFDjzBMg67+NmktGU20dS3uHXk09mava/X7qcduTgcnXRyb9WNk 9y/xV82/FkWpJZzscVAdODF8okM6w9Ra5Vl5C7Vo+lHsXKi6TrQ00jPkOrFPkqtL/GKuUIzwZsmi eLzULeiD4dmCSdazc6ph+OcLxd2Ayns3kRJwmPhBVUTW8eohq3jzm+aM/pmHuOxvt41DEg2a1KZn fiNXsbeZ04Ku+TyfEv3dyBGd1RZdPMF3tMyqvMyXHSvMFC4SKxb0kMCr4DLPbyHQoINPooZOfGlJ DZEnsT0/1ZPzEK2W/siXPrkX8fA3pxWmoSKvIWeeuaTDZq+H25uPys95rnuIjSdW5G7dXLiF5M3/ mFgRCZvJyC6ddmEH3KI22XNbTVWMEJ/XKSzRtj76IHnrpic+Mo+D/pXcxscThHp1MYIj1rV//y0J I+uFNm5s+3jSlPxbLcZhLvHocQMc+WQyC1///rHpQ5gUL/a8tpQABcPU7vufPcQa98S0B4exVIiT e4PD7LHtgZgX1xvFywIxhheyeB8vKJFdslSQYvpxFoGCY8r6lkm3CuRlNZC9akTDj+r6lnduFUiQ NkSxTzt7yR5ibVGTXxm1rye31JSfEpPVSyz2fTfixcXn9lfKXWprSX3qQgbVr+BjlbPNK9FNsq91 MOGCdUdND1T5xd/+bbfL6pD9h+XDK6MZF56z1GTdrnfADm6yjwauZ7NgdUsDHpD/LLYgaYxxJAdq XosUPykcJKJjTWd+x1nR33GeyrL4cTmEWkEkYgie1O41jahigzWGiMss8wLYRMaNhltH2XpywyDV Zp2mviWfrfG5Ragef3zYOqi8cmDiLdP91WyImf/0gzhIaUDxiF3LWHuiJ0Gfny+dUkMfX5ckJ3uq bolrdDtVjuRnOprF4fzKUyuJHBMZf7dnuetIeoSmjAy3oxuxCmPD6oy7jbSsyPLrdn7foSkTe/mt 2LvpTLuq6HCMQkKH6ECLpkx6K9Tz6WZ2qt6ogkX3K5qeUozX4H19C4dVaqkZpR1QduRfvWCgq6FE jQhRVdJtIO511jn9CaFdxlxVGYcm8dQ7hCfPnFCUYce9vT749Y023crUZT1tLYxKjg1H0sURtckW 9blmaQfFeEvunp4/fRN03Ve0RgNm790pUB01TrtW2fd5NCi6/uJkpqdZuohM5lgVvUuJkP7BWybu +TddzmLudgukHCnXT7rhUF2h9KhoH26Ss1E9ViFAIPICRUSmi+ry9Wh/epugpudOP5cVa70S57ug 6RlvYVRHg9isVSN1Cd3bsB6M5rgza1VNXcqeDLUMQnOkzyZyl03a9TZYLmasZM4m2pdNWuYH+39W RqfPWmVSl3Int9fmM0Jta5GC9fnH8jc9Ol3UnWs5vtbnO+RvyvW4qLvVcug05JvprQ6XUn2afYQl g9En0Kt2T6hL+ZOnTZYz2DNmW6zLJll6Q65MKQupDERTshrxLOdrOklDq8L9fhuv2xmMx0NEbZoU rarUu1TN8yrDbbYb6vqk74grba8jD4ce2ygJGLJpFJT8fM/szBeRFWQ3auz2Mksxu+29Yy9rM80u oRAHrjxMUX2tvEDNm+d50ebN00lpntOdeSpYZiu7bf9VubivkMS4v3eHjn4HBgBK41r6aGV6wA33 sQHAAZ5dgew3GwLwsxPggT1wBqywTQMbOAB3eO57p/b9aO5gResyD4BD8ItWCY6Ug0UFtuXht6ws 3BHLwUMR8MJD/tue2o+ZtqsGv3j54Mwep0NpTfMudhnYZWCXgV0GdhnYZWCXgV0GdhnYZWCXgf8J A/8FAAD//wMAUEsDBBQABgAIAAAAIQCiocrBnAEAAFwDAAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCi BAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJyTQWsbMRCF74X8h0X3WGs7lGK0CsVp yKGlBjvJWdXOekW0ktBMFru/vtpdHMttcultNO/x+DQjidtDZ4seIhrvKjaflawAp31t3L5ij7v7 6y+sQFKuVtY7qNgRkN3Kq09iE32ASAawSBEOK9YShRXnqFvoFM6S7JLS+NgpSse4575pjIY7r187 cMQXZfmZw4HA1VBfh7dANiWuevrf0NrrgQ+fdseQgKX4GoI1WlG6pfxhdPToGyq+HTRYwXNRJLot 6Ndo6ChLwfOj2GplYZ2CZaMsguDnhngANQxto0xEKXpa9aDJxwLN7zS2BSt+KYQBp2K9ikY5SliD bTqMtQ1IUT77+IItAKHgyTA1xzL35rW5kcvRkIpL4xAwgSThEnFnyAL+bDYq0jvEy5x4ZJh4J5zt wDfP+d5IR2nxsTSR5rcaB5X4/iJa+y4od8z2tfYx+DhuUfCTLL4b94KPYefvFMFpM5dNsW1VhDot 86SfG+IhLSXaIWTdKreH+uT5Vxje0dP0WeT8ZlYuy/REsp7g528h/wAAAP//AwBQSwMEFAAGAAgA AAAhADYCE9FAAgAAHwYAABQAAAB4bC90YWJsZXMvdGFibGUxLnhtbHRU23LaMBB970z/QaP3YuQ0 5DJABkhpkyHAxKTtq7AFVkeWPJKA+O+zvhZR9VGrc/bsro52+PCeCXRk2nAlR5j0+hgxGauEy/0I v23mX24xMpbKhAol2QgXzOCH8edPQ0u3giFgSzPCqbX5fRCYOGUZNT2VMwk3O6UzauGo94HJNaOJ SRmzmQjCfn8QZJRLjHgCshhJmkH2TZkUTgk3uaDF0glqthvhCbnfhCFGVlkqzKs6Rak6QeVQdwoC TEPo8X33BFnDK0hELW2PkLeDTJUGbHtT5iuV3Wgfj4f0YNWcC8s0OpcPxnX/MyUOmTQoVgdpQbGk VJnqC7e5N0P3zCmJ3GE3U0WAaupprKmmGSqH4LJufSxo9pz1kwqXdOMjfW1Jj8zEmucWXODSBj7a dUvrLb9tXPy1Dw9zaYr7xWWiTgZOlh8v2oJiyueaMSEiWwiww3elEl++QZtuFaHfrv6VD3/T4vkq cuGhD37Xwp/pkaLn2cTlEB+HdKOcghfiYkaNFRcN9n1E+F/1u01kohVPHC2vP0j3XdY/1g7cawzS TQvgEYsXfOuQvMYgf01Y2PTCFF5PkG7IL+FMF7lVjorXF6Rrfl14OP8aYkq9fiCd+V8P28LR9fqB dAZewaaKooVD8XoCvmrzTlIlrPfHOJRyZbnW/V+l3U9YRq4VK3MEZ8vDNKuk+gtPcqca/WpHVsEX lvBDBtoGduCca2PrtVNtwzK2ABNehMqNaeGnM9jaDbNGdNGzQsYfAAAA//8DAFBLAQItABQABgAI AAAAIQDF3RNAiwEAAJQGAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsB Ai0AFAAGAAgAAAAhALVVMCP1AAAATAIAAAsAAAAAAAAAAAAAAAAAxAMAAF9yZWxzLy5yZWxzUEsB Ai0AFAAGAAgAAAAhAN4J/SgCAQAA1AMAABoAAAAAAAAAAAAAAAAA6gYAAHhsL19yZWxzL3dvcmti b29rLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhALq0cdpiAQAAcQIAAA8AAAAAAAAAAAAAAAAALAkA AHhsL3dvcmtib29rLnhtbFBLAQItABQABgAIAAAAIQD7YqVtlAYAAKcbAAATAAAAAAAAAAAAAAAA ALsKAAB4bC90aGVtZS90aGVtZTEueG1sUEsBAi0AFAAGAAgAAAAhAEG/+GDZAAAAygEAACMAAAAA AAAAAAAAAAAAgBEAAHhsL3dvcmtzaGVldHMvX3JlbHMvc2hlZXQxLnhtbC5yZWxzUEsBAi0AFAAG AAgAAAAhAPvoXUdgAQAAdQIAABgAAAAAAAAAAAAAAAAAmhIAAHhsL3dvcmtzaGVldHMvc2hlZXQy LnhtbFBLAQItABQABgAIAAAAIQD76F1HYAEAAHUCAAAYAAAAAAAAAAAAAAAAADAUAAB4bC93b3Jr c2hlZXRzL3NoZWV0My54bWxQSwECLQAUAAYACAAAACEAcG2tyhEOAAD/VQAAGAAAAAAAAAAAAAAA AADGFQAAeGwvd29ya3NoZWV0cy9zaGVldDEueG1sUEsBAi0AFAAGAAgAAAAhANaIUHoeCAAA9lsA AA0AAAAAAAAAAAAAAAAADSQAAHhsL3N0eWxlcy54bWxQSwECLQAUAAYACAAAACEAgy/oZb8EAAB4 DgAAFAAAAAAAAAAAAAAAAABWLAAAeGwvc2hhcmVkU3RyaW5ncy54bWxQSwECLQAUAAYACAAAACEA YEEJ5FEBAABmAgAAEQAAAAAAAAAAAAAAAABHMQAAZG9jUHJvcHMvY29yZS54bWxQSwECLQAUAAYA CAAAACEA3Fl47dwLAAC0GwAAJwAAAAAAAAAAAAAAAADPMwAAeGwvcHJpbnRlclNldHRpbmdzL3By aW50ZXJTZXR0aW5nczEuYmluUEsBAi0AFAAGAAgAAAAhAKKhysGcAQAAXAMAABAAAAAAAAAAAAAA AAAA8D8AAGRvY1Byb3BzL2FwcC54bWxQSwECLQAUAAYACAAAACEANgIT0UACAAAfBgAAFAAAAAAA AAAAAAAAAADCQgAAeGwvdGFibGVzL3RhYmxlMS54bWxQSwUGAAAAAA8ADwD0AwAANEUAAAAA --_002_72FE5DE0479C4852AA5CA4F726FEF5A7ciscocom_-- From nobody Thu Jul 23 11:46:30 2015 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 126AC1A00CA for ; Thu, 23 Jul 2015 11:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 0pdELSdXT6rM for ; Thu, 23 Jul 2015 11:46:25 -0700 (PDT) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) (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 90A011A0379 for ; Thu, 23 Jul 2015 11:46:24 -0700 (PDT) Received: by padck2 with SMTP id ck2so453908pad.0 for ; Thu, 23 Jul 2015 11:46:24 -0700 (PDT) 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:organization :message-id:date:user-agent:mime-version:in-reply-to:content-type; bh=M+CkIdAztLLdJdorW4UWfZPYNXctFSkxnfnZ4MS9fdI=; b=EQK9Fe7LWFMpZTVuZKvNEqmLMqvCYDE18d4vCjpb4HCP9QeaNtaQSPLD4lre7H6zM7 muXGMVyvaNKXOLreK9cS8ydyFLjPWPcZ8Uf6SwCkNC/oh8TxbwfLQrJQT2fvbY5SYkLN JAQj18acUlgtc1O0W112QuVR4uSC5mDoAx3q+Y5CfUnxjzMK7q8B6vTSLZdijRtaPyWo 4jSpAbO8mDbnxYV0qv8uvteMX2MNH//1tcDnFxonEQNAjBjLHb3Pu51nQV0mGsEk83aw 7SlRWg3kEXGCLJEUvRdakJfY1wAo3GXrvLg4orE6rtdqrn+A+bakcuilbhzJOqEjnFw6 lzAA== X-Gm-Message-State: ALoCoQlF2/fmxRx1vEoNyX+cC8rMB7ZbHuphfDVXdI6FO+T8LUMW5TTdtXSMIQNjK3Yy+4cAPZww X-Received: by 10.70.89.109 with SMTP id bn13mr12442646pdb.163.1437677183934; Thu, 23 Jul 2015 11:46:23 -0700 (PDT) Received: from ?IPv6:2620:101:80fc:224:7c7a:51e0:443b:253c? ([2620:101:80fc:224:7c7a:51e0:443b:253c]) by smtp.gmail.com with ESMTPSA id qn7sm10374348pab.14.2015.07.23.11.46.22 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 23 Jul 2015 11:46:23 -0700 (PDT) From: JR Conlin X-Google-Original-From: JR Conlin To: webpush@ietf.org References: <25607271-70AC-4700-8049-3A8ECA41F381@oracle.com> X-Enigmail-Draft-Status: N1110 Organization: mozilla Message-ID: <55B1367E.8000706@mozilla.com> Date: Thu, 23 Jul 2015 11:46:22 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:41.0) Gecko/20100101 Thunderbird/41.0a2 MIME-Version: 1.0 In-Reply-To: <25607271-70AC-4700-8049-3A8ECA41F381@oracle.com> Content-Type: multipart/alternative; boundary="------------080204010107020003090508" Archived-At: Subject: Re: [Webpush] Publishing events to multiple subscribers 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, 23 Jul 2015 18:46:29 -0000 This is a multi-part message in MIME format. --------------080204010107020003090508 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Phil, I'm sure others will be far smarter about this, but I'll note that one of the big reasons we passed on broadcast was mostly around the deep complexity of secure key exchange for multiple hosts. Because of privacy reasons, WebPush doesn't want intermediaries to be able to read user data. There's a bit of hand waving even in WebPush, but fundamentally, the creator of the data (the App Server) and the receiver of the data (the App) have both agreed to a key exchange outside of WebPush. This key is (ideally) unique between creator and recipient and never travels across WebPush. This makes matters a tad complicated when you've got multiple recipients, since the data being sent needs to be re-encrypted for each. Now, add in the problem that your specification also uses encryption and data sizes can get fairly out-of-hand. Granted, there's little preventing a single App Server from using the same encryption for all App recipients (aside from the tears of the OpSec team), much like picking a point on the curve where O=P=Q. Of course, this means that the content of the message is a target of attack, and we'll hope that they didn't use the same O=P=Q key selection method. Going back to inadvertent privacy concerns, there's also the potential for social graph disclosure with any broadcast method. For things like server alerts or surf reports, probably not a big deal. For things like political marches or whistle-blower efforts, a bit more of a concern. Hopefully, this won't discourage you from your goal, I simply wanted you to know some of our previous discussion. On 7/23/2015 9:26 AM, Phil Hunt wrote: > As a follow up to my comment on in the WG meeting today. I wanted to > let the group know that the SCIM WG is considering an event > notification proposal that sends events to subscribers interested in > knowing about events that have occured within a SCIM service. The > subscribers may be individual mobile apps, or they may be partner SCIM > service providers in another administrative domain. > > You can find the initial proposal here: > https://tools.ietf.org/html/draft-hunt-scim-notify-00. > > This draft specifies some concepts that are not yet part of WebPush > and indeed includes web push as a possible message delivery protocol > (and probably should not be). > > I see a lot affinity and similarities that show a good design overlap > with what we have been thinking and the current WebPush proposal. I > like the overlap between the SCIM notify draft and the current WebPush > work. As such, I would like to consider re-working the SCIM Notify > draft to be WebPush centric if possible. > > While not in the current scope, I do want to be able to allow multiple > subscribers to receive events to the same “subscription”. Similar to > the WebPUSH architecture, we have a publication server that offloads > the job of message delivery from the application server and takes care > of delivery to subscribers. SCIM Notify has both 1-1 to cases (e.g. to > mobile apps) and 1:Many cases, where multiple cloud providers may wish > to know about changes that are occurring in a domain. > > While one-to-many might not be in scope, I would like to at least make > sure this is possible for a future “extension” draft. This would > allow the SCIM notify draft to be simplified and focus instead on SCIM > event definitions rather than having to define delivery. > > Note: The SCIM WG has not yet adopted this work. At this stage, it is > just a proposal some members are working on. We’ve slowed down while > the WebPUSH work has been progressing. Now seems like a good time to > revisit the proposal. > > Thanks, > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush --------------080204010107020003090508 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi Phil,

I'm sure others will be far smarter about this, but I'll note that one of the big reasons we passed on broadcast was mostly around the deep complexity of secure key exchange for multiple hosts. Because of privacy reasons, WebPush doesn't want intermediaries to be able to read user data. There's a bit of hand waving even in WebPush, but fundamentally, the creator of the data (the App Server) and the receiver of the data (the App) have both agreed to a key exchange outside of WebPush. This key is (ideally) unique between creator and recipient and never travels across WebPush.

This makes matters a tad complicated when you've got multiple recipients, since the data being sent needs to be re-encrypted for each. Now, add in the problem that your specification also uses encryption and data sizes can get fairly out-of-hand.

Granted, there's little preventing a single App Server from using the same encryption for all App recipients (aside from the tears of the OpSec team), much like picking a point on the curve where O=P=Q. Of course, this means that the content of the message is a target of attack, and we'll hope that they didn't use the same O=P=Q key selection method.

Going back to inadvertent privacy concerns, there's also the potential for social graph disclosure with any broadcast method. For things like server alerts or surf reports, probably not a big deal. For things like political marches or whistle-blower efforts, a bit more of a concern.

Hopefully, this won't discourage you from your goal, I simply wanted you to know some of our previous discussion.

On 7/23/2015 9:26 AM, Phil Hunt wrote:
As a follow up to my comment on in the WG meeting today. I wanted to let the group know that the SCIM WG is considering an event notification proposal that sends events to subscribers interested in knowing about events that have occured within a SCIM service. The subscribers may be individual mobile apps, or they may be partner SCIM service providers in another administrative domain.

You can find the initial proposal here:

This draft specifies some concepts that are not yet part of WebPush and indeed includes web push as a possible message delivery protocol (and probably should not be).

I see a lot affinity and similarities that show a good design overlap with what we have been thinking and the current WebPush proposal. I like the overlap between the SCIM notify draft and the current WebPush work. As such, I would like to consider re-working the SCIM Notify draft to be WebPush centric if possible.

While not in the current scope, I do want to be able to allow multiple subscribers to receive events to the same “subscription”.  Similar to the WebPUSH architecture, we have a publication server that offloads the job of message delivery from the application server and takes care of delivery to subscribers. SCIM Notify has both 1-1 to cases (e.g. to mobile apps) and 1:Many cases, where multiple cloud providers may wish to know about changes that are occurring in a domain.

While one-to-many might not be in scope, I would like to at least make sure this is possible for a future “extension” draft.  This would allow the SCIM notify draft to be simplified and focus instead on SCIM event definitions rather than having to define delivery.

Note: The SCIM WG has not yet adopted this work. At this stage, it is just a proposal some members are working on. We’ve slowed down while the WebPUSH work has been progressing.  Now seems like a good time to revisit the proposal.

Thanks,



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

--------------080204010107020003090508-- From nobody Sat Jul 25 14:52:08 2015 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 3B7851A079D for ; Sat, 25 Jul 2015 14:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.399 X-Spam-Level: * X-Spam-Status: No, score=1.399 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_52=0.6, SPF_HELO_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 SSzFgJdwqmIs for ; Sat, 25 Jul 2015 14:52:02 -0700 (PDT) Received: from gator4135.hostgator.com (gator4135.hostgator.com [192.185.4.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E66771A07BD for ; Sat, 25 Jul 2015 14:52:01 -0700 (PDT) Received: from [107.19.189.14] (port=53381 helo=[192.168.10.217]) by gator4135.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.85) (envelope-from ) id 1ZJ7MO-0007Qr-Ts for webpush@ietf.org; Sat, 25 Jul 2015 16:52:01 -0500 From: Shida Schubert Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <8E6E28D7-1552-42E2-BF85-4C9B7FF4BD80@ntt-at.com> Date: Sat, 25 Jul 2015 23:51:12 +0200 To: webpush@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) 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: 107.19.189.14 X-Exim-ID: 1ZJ7MO-0007Qr-Ts X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.10.217]) [107.19.189.14]:53381 X-Source-Auth: shida@agnada.com X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== Archived-At: Subject: [Webpush] Minutes from the Thursday's meeting 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, 25 Jul 2015 21:52:06 -0000 All; Below is the minutes / action items from the Thursday meeting.=20 I want to thank Darshak Thakore for taking notes.=20 ******************************* Webpush IETF 93 Thursday July 23rd 2015 1740-1910 XMPP: webpush@jabber.ietf.org #### Action Items #### 1. Chairs:=20 1.1. Announce the use of github for managing the work. 2. Author of core-protocol draft: 2.1. Send the use-case for Ack=E2=80=99s acknowledgement. 2.2. Look into Server authentication Google is using and see if it can = be=20 adopted. 3. Mike 3.1. Send out report on current status of crypt algorithm supported by=20= common dev platform.=20 #### Summary / Conclusions ####=20 1. Issue about reliability was discussed regarding the core protocol.=20 - There was a general consensus to support =E2=80=9CFull Reliability=E2=80= =9D whereby=20 push and acknowledgement messages are both stored and retried until TTL = expires.=20 - Whether TTL be same for both acknowledgment and push message need to = be debated. - There were some debates about the needs for NACK.=20 - For malformed message (AS > PS), some believed that 5xx or 4xx be = sufficient. - NACK for when TTL expires is something to consider. - Discussion about whether acknowledgement is needed for acknowledgement = itself=20 need to be discussed further. The feeling of the room was relatively = strong=20 inclination not to do this.=20 2. Issue about Crypto=20 - General feeling was because ease of deployment is critical, there was = more=20 voice favoring 256. - Mike was going to send in the current status of the crypto algorithm = supported=20 by common dev platform informing the discussion. 3. Security draft - Will work on them separately. May merge the draft into core-protocol, = may not.=20 AD made a point that neither will progress through IESG unless both = are ready. If milestone is needed, it=E2=80=99s not an issue. #### Detail Notes ####=20 ** Status and Agenda Bashing (Chairs) ********************** Floor: No bashing Shida: Presented use of github for all subsequent work and send out a = note on how to use it (based on the success of httpbis) Peter: Announced the availability of the prototype for web push = (specifically section 5). Included in chrome with the GCM.=20 ** Baseline document (E. Damaggio / Martin Thomson) ******** - ISSUE 1 : Reliabilty -------- Slide 1 - Mobile devices are always offline and PS provide reliable = delivery function. Provided an overview of push messaging functionality. Slide 2 - Talked about acknowledgement of push message delivery and the = need for it for applications (at least some of them) Slide 3 - Currently UA/client is required to ack every message received. = Decided to make it mandatory because complexity associated with making = it optional is probably not worth it Slide 4 - Explained flow of positive ack. (Question from Joe from the = mic - clarifying that the ack is an indication that the application = actually received/processed it).=20 Slide 5 - Scenario 2 - Explained flow of push message timing out before = the UA/client gets a chance to retrieve it. Options are the AS can also = maintain a timer and if it didn=E2=80=99t receive a receipt, it assumes = the message was not delivered. Option 2 is that the PS can send back a = nack =20 Robert Spark: Do you want to be able to tell the diff between the UA = didn=E2=80=99t come online and the UA somehow crashed or something else = happened).=20 Martin Thomson: Currently the AS will keep trying and after a certain = time, give up and determine the client=E2=80=99s offline.=20 Dan Druta: Scenario describes the life cycle of only one message, if the = server sends 2 (in succession) where the next one supersedes the = earlier, how to handle suppression. Let the app handle that, or do = something else?=20 Martin Thomson: There can be a separate draft that allows collapsing and = other processing on top of the main architecture. Phil: What is the correlation between user agent and subscription. = Presented a scenario where multiple UA=E2=80=99s wanting to subscribe to = the same stream. Slide 6 - Scenario 3 - Flow of where PS gives up where for unknown = reasons the UA/client does not ack (maybe because its = unresponsive/broken) Slide 7 - Scenario 4 - Ack failure - PS operators can handle a very = sizable traffic. The AS may not always ask for ack and the question is = how do PS=E2=80=99s handle this.=20 Slide 8 - Reliability of ack=20 Slide 9 - Option 1 for ack reliability - No reliability of ack (only = end-to-end ack). See slide for implications. Mostly unacceptable to = everyone Option 2 - Push reliability only - Push messages are stored up to = the agreed upon TTL messages are retried but ACK=E2=80=99s are not. = assumes that the AS can be offline Option 3 - Full reliability of PS - Push messages are stored and = retried and so are acknowledgements. Use same TTL for messages and = acknowledgements Option 4 - PS chooses between 2 and 3 ???: Is it PS chooses or AS indicates. IF AS chooses then the = implication is that PS does have to implement ack storage and retrying. Slide XX - Proposal - pick one proposing the =E2=80=9CFull = Reliability=E2=80=9D Franchesco: Application level semantics is not the job of the PS, but = the PS should be attempting to deliver and let know that=E2=80=A6.=20 Martin: By default the TTL is 0 of not specified. The PS gets to choose = what max TTL it supports and indicates it by restricting it to the max = TTL it supports in the response to a request that is asking for TTL = higher than PS=E2=80=99s max Costin: Device is expected to be offline for long times. AS=E2=80=99s = may have more stringent requirements and should be coming online more = often. Explained that we may need some sort of storage even for TTL=3D0.=20= Franchsco: There should not be a =E2=80=9Cnack=E2=80=9D. Elios: Commenting on the benefit of =E2=80=9Cnack=E2=80=9D. Makes it = easier for AS to determine how/when to retry. If the message is = poisonous in some way such that UA is not able ack a message. We don=E2=80= =99t want the AS to keep trying it again and instead want the AS to know = that for some reason the message is not acceptable to the UA/client.=20 Martin: =E2=80=9Cnack=E2=80=9D can also be used in cases where the PS = gives up (maybe coz it became overloaded).=20 Franchesco: Arguing against the need for =E2=80=9Cnack" Ellio: Countered with uses for =E2=80=9Cnack=E2=80=9D. AS=E2=80=99s can = have bad code and we want to try to handle such things.=20 Robert: provided example - AS sends a push to PS, the PS sends a push to = the UA and crashes it. The PS should be able to say to the AS =E2=80=9Cdon= =E2=80=99t send that message again" Joe: Maybe there is some other way to tell the dev/user that there=E2=80=99= s issues with the messages being sent Franchesco: Message contains metadata and UA cannot know that message is = poisoned. The only entity that can know is the actual application Andrew: The fact that UA crashed does not mean the message was bad. = Could be UA cannot handle the message size. Low memory / IoT etc. Dan: There are cases where nack is needed and cases where its not = needed.=20 Martin: Trying to find a middle ground. One PS can detect delivery = failure and send a =E2=80=9Cnack=E2=80=9D. Other one can just keep = crashing Ellio: Providing an example of situations in which nack can be = generated. For IoT use cases,if the single purpose clients are not able = to successfully handle messages, you want to know that asap.=20 Costin: We can give the advice that AS=E2=80=99s should not attempt to = send the same message again if it receives a =E2=80=9Cnack=E2=80=9D from = PS. Joe: Concerned if the goal of the WG is clear in terms of what = =E2=80=9Creliability=E2=80=9D features need to be addressed as part of = the solution? The issue of what are we trying to solve, is coming up = again and again and if we can figure out some compromising path. How = stringent are we on specific needs/requirements Franchesco: Agreed that there=E2=80=99s a separate use case where a = =E2=80=9Cnack=E2=80=9D may be useful. Feeling the room by chair: Everyone leaning and ok with full reliability Acknowledging ACK=E2=80=99s=20 Martin: In some of the services the ACK=E2=80=99s actually carry data. = We may handle this in the future Dan: Please covere this.=20 Joe: We =E2=80=9Cpin=E2=80=9D this topic and discuss offline first.=20 Martin: Send the info to the list. -- ISSUE 2 : What Crypto to use? -------- Push Crypto - Martin hoping to get a number of questions answered. Slide 1 - Changes - Summarizes where we are at. the http-encryption = draft updated to match TLS 1.3 changes. The record structure has been = simplified for Push. Currently its required that someone sending a Push = message use a single record and receiver required to check for = truncation.=20 Questions from Martin Q1 - Choice of Curve - P-256 vs 25519 - better deployment vs better = crypto Asked Mike/Peter and Matt Miller to provide comments Mike: Mentioned that he=E2=80=99s speaking on behalf of Microsoft. MS = wants to use P256 because its more deployed Peter: Provided explanation regarding the status of crypto capabilities. = Suggesting to go for 25519. Martin asked if there=E2=80=99s something we = can do to help deployment of 25519. Peter provided an overview of what = Google is doing.=20 Matt Miller: usually P256 is available because its available in openssl. = There=E2=80=99s a large base of Java applications that also has P256 = support. And P-256 also available in all Microsoft crypto libraries = also. Mike: Joe asked question if the same approach is being used for COSE = (the approach for going with P256 now and then be prepared to change as = deployment of 25519 improves) Martin asked question about JWE=E2=80=99s support. Mike to send some = data regarding that.=20 Will have continuing discussion on the list based on info shared Application Server Authentication See Slide - Currently rely on confidentiality of URL=E2=80=99s and DH = shares. concern raised (by David Benjamin) regarding URL leakage. Public = Keys are not treated with sufficient care. Suggesting use of HMAC. = Martin explained how to go about doing it. Bits can be provided to the = AS along with the URI=E2=80=99s by the PS. The AS uses it along with = each message to generate HMAC.=20 Costin - Mentioned that GCM requires authentication. Not decided which = one but its critical to include AS authentication.=20 Martin commented - We can look at what Google has implemented and see = if we can adapt/use that. ** Low Energy Requirements for WebPush (Herve Ruellan) ***** Talk about energy requirements.=20 Slide 1 - Explains where all the energy is consumed in regard to = receiving real-time notifications. Web push is a good first step but can = be improved Slide 2 - TCP Keep-Alive. Required by intermediaries to keep connection = open. Provides stats on what ISP=E2=80=99s require and how much energy = is consumed Slide 3 - HTTP/2 Ping - That will also consume energy Slide 4 - Consecutive notifications - They should be grouped. Similar to = TCP Nagle also. Slide 5 - Asking for comments/ideas on improving energy efficiency Joe: Asking if TCP Keep-Alive is being used (check with Joe regarding = his comment)?=20 Franchesco: The best ISP=E2=80=99s have an hour? for timeout (check if = that=E2=80=99s what he said) Matt Miller: TCP Keep-Alive is useless If you can rely on not depending on the AS and the application to send = the TCP Keep-Alive, it would be better. Don=E2=80=99t rely on = Keep-Alive. Costin: Different ports have different timeouts and we shouldn=E2=80=99t = use 443 for web push. ** Subscription-Less Web Push Framework (Fabio Chiussi) **** Slide 1 - Purpose of draft is to spark discussion on the applicability = of different =E2=80=9Cflavors=E2=80=9D of web-push.=20 Slide 2 - Subscriptionless web push - Asking question/challenging if we = can come up with subscriptions web-push Slide 3 - Current web-push hinges on the UA creating a subscription. For = good reasons.=20 Slide 4 - Use case 1 & 2 -=20 UC1 - waking up dormant UE=E2=80=99s. Need to wake up a UE involving = only the browser. (See slides for details) UC2 - Local Alarms or urgent notifications. User may be willig to give = up some privacy to get notifications without subscription UC3- User knows that upon entering a =E2=80=9Cvenue=E2=80=9D the user = expects a relationship with the provider and the subscription is = implicit as the UE connects to the network. UC4 - Cross-application volume control. (see slide) Slide 5 - are any of the things mentioned reasonable Comment from the floor - Agree with use cases but they all seem to be a = requirement for some form of =E2=80=9Cbroadcast=E2=80=9D. ** Next step *********************************************** Chair: Would people be upset if we merge the encryption draft into the = core protocol draft?=20 Darshak: Commented that encryption must be mandatory but if we can make = it in an adjunct draft that gets delivered alongside (if possible) Martin: Not specifically opposed to having it in a separate draft. Matt Miller: Also ok with having it as a separate draft Alyissa Cooper: Commented that from the process perspective - the core = spec can have a reference to the encryption spec. The IESG and others = will want to have all details regarding the encryption/security. From nobody Tue Jul 28 17:30:41 2015 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 D1C6E1A0162 for ; Tue, 28 Jul 2015 17:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 0LA5TE8YoCgF for ; Tue, 28 Jul 2015 17:30:37 -0700 (PDT) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (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 37FED1A0161 for ; Tue, 28 Jul 2015 17:30:37 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so4327822wib.1 for ; Tue, 28 Jul 2015 17:30:35 -0700 (PDT) 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=clzVM7xkmG5HJsJ7d51hMAe1jaYU8E+bewbRbHVRC9k=; b=XmuLiWsn6HtCRlTo3Z+Osb2OEYVeyx/dxecu07oviED08zr9xwPqgv5/pZ+nK/NNHX 4LDEEcyz0KMBwNKBHy6ZHm0yyf9MyGHJezO2aV1TjGqIXWFCrIPAY8pfIaoEzT6jRwPr qyn+9sxt3WdS7HNRgQo6YnZ5TsgGfz5g6gTJxI3kPUJu5j6mMVg79WOblxxiQryWMDR6 PwqPOHD1Dc7wycPGYnxRMe1gZml/pXfjl4bDVj7OjSxhZjnFjPNUzP2z5qpQQw3OyBTp Rfs4X6Yj1Alqm9tcYgB6IoblRRiKuwVdEYZc0KLn6MMkCWTgqFE45b/NEPXyjCQAAbov eu4g== X-Gm-Message-State: ALoCoQkWncBk4rFSNts6sl8zT8lSJ21DHwZhaLNxG7NzDClTKmt8aYaFfrNdx593Ip0IQce0YZoI MIME-Version: 1.0 X-Received: by 10.180.101.233 with SMTP id fj9mr284764wib.45.1438129835760; Tue, 28 Jul 2015 17:30:35 -0700 (PDT) Received: by 10.27.33.81 with HTTP; Tue, 28 Jul 2015 17:30:35 -0700 (PDT) Date: Tue, 28 Jul 2015 17:30:35 -0700 Message-ID: From: Benjamin Bangert To: "webpush@ietf.org" Content-Type: multipart/alternative; boundary=f46d0442878a007e37051bf8b297 Archived-At: Subject: [Webpush] TTL of 0 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, 29 Jul 2015 00:30:40 -0000 --f46d0442878a007e37051bf8b297 Content-Type: text/plain; charset=UTF-8 The spec indicates a TTL of 0 should result in the message not being delivered if the client is not connected. However, it doesn't indicate whether the Push server is still under the same obligation to provide a Location header in the response in this case (I assume its still a 201, even though a resource was not created?). Should a Location still be returned? What kind of receipt is assumed in this case (or no receipt and no Location)? Cheers, Ben --f46d0442878a007e37051bf8b297 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The spec indicates a TTL of 0 should result= in the message not being delivered if the client is not connected. However= , it doesn't indicate whether the Push server is still under the same o= bligation to provide a Location header in the response in this case (I assu= me its still a 201, even though a resource was not created?).

= Should a Location still be returned? What kind of receipt is assumed in thi= s case (or no receipt and no Location)?

Cheers,
Ben
--f46d0442878a007e37051bf8b297-- From nobody Wed Jul 29 16:09:41 2015 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 44E191B2F7B for ; Wed, 29 Jul 2015 16:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.311 X-Spam-Level: * X-Spam-Status: No, score=1.311 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 pJnT96hFdQgr for ; Wed, 29 Jul 2015 16:09:39 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c: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 EBCDB1B2A06 for ; Wed, 29 Jul 2015 16:09:38 -0700 (PDT) Received: by vkca124 with SMTP id a124so4694323vkc.1 for ; Wed, 29 Jul 2015 16:09:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=Ju0qLXuzP/2bQxOPye5lEv4cD1u0fj+faxCJDR2sVlU=; b=pzrd3SJZzMIsXU+KcTOyzFNmlbnEl72ICRBfpyL07HjD/eh4b4oJsFGj8wEIg7lGTd CisWScpwd5i7LZwVDKmYn9g7QyLJYTJcBIpIH7k/j9QHvYCT9bPPWgDH35j2lxCt5drs jkmfeVbU25RRkLGN8EBACjBDiZ2kxQECbbAZnmumCIeyPdtshubdD/ha+jQg1MeH0kFs C4LUJ4Y/DbAZYlv12MUeucZMEboWy8wKURsH5XoZb2lufDzxj5DH2HcVvKGAF5CIUXgj 17CCZmui/e4oSDjgl7XuW8asGoeS2eZe224y8443M4B2ygUioD8tWavc9X8Ebl4nG6Yx 1djQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=Ju0qLXuzP/2bQxOPye5lEv4cD1u0fj+faxCJDR2sVlU=; b=QLTBiVUX1o96fm1H5ON4/VrA+vrCT32Qr5vqwLmC+ljqKzajpQhQpAE+pm4F+8Be24 p/QvKZhe53cwB6HChGYKVmKV64ZkilMaYyxJp8+fQAooxmuy7wmYhour621oiS5jF5x0 IDmUaMoReXxcpC+449nlNMBUAaPFbWR0es7LACFL0vR1YwjvRPIozwtEiC98kJz0iawG FpkleAdtDxu5OZnANeIUj410/NRzqTZN5eAKl87zAT0nRob2FdALINNMs8Q1P/1MQhEJ Y8KdqGkKhF0m+F9TcFz4W1ODDBESV7xOezRvdWziqYAjoHF5yPMBuh84yhOEOgEtYxBD vHMg== X-Gm-Message-State: ALoCoQkqp+sRyL089Y28OqC5QHlh+c2WGwvKVtBR+NqFLnSlkRyDcich5mu0zuN+T8sbTWEV9LDI X-Received: by 10.52.137.236 with SMTP id ql12mr52086970vdb.48.1438211377980; Wed, 29 Jul 2015 16:09:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.69.201 with HTTP; Wed, 29 Jul 2015 16:09:16 -0700 (PDT) From: Adam Langley Date: Wed, 29 Jul 2015 16:09:16 -0700 Message-ID: To: webpush@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Webpush] Curve25519 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, 29 Jul 2015 23:09:40 -0000 I've been asked by a couple of people to comment here on the choice of elliptic curve as I'm an editor of draft-irtf-cfrg-curves. I believe that new IETF work should be using curve25519 unless it's incremental work on an existing standard where P-256 is dominant. Representing my employer, it is also Google's view that using curve25519 is strongly preferable to P-256 where possible. We're going to take a pretty dim view of new work that uses crufty curves. Although I'm aware that some people have reservations about the construction of P-256 and worry about deliberate weaknesses, I do not. But one doesn't need to believe that in order to recognise that P-256 is complex, slow and fragile. I'm told that availability is a reason cited for wanting to pick P-256 (and PHP was mentioned). But AES-GCM is already (sadly) fairly obscure. Apart from the side-channel concerns in many implementations, AES-GCM is a good choice for an AEAD, but it's likely to present greater implementation problems than curve25519. In practice, I suggest that most implementations will ship their own copies of both AES-GCM and whatever curve is needed and, in that case, curve25519 will be smaller and easier. A Google search for "PHP curve25519" turns up an MIT licensed, pure PHP version as the first result[1]. If people are concerned about the license, or implementations for some other language, then please let me know. The public domain ref10 or TweetNaCl[2] are generally readily portable to any language and are simple and constant-time. Lastly, I think my colleague, David Benjamin, has pointed this out already, but private keys are private and public keys are generally not. It's odd, and that translates as questionable, to depend on the secrecy of a public key for authentication. By my reading of draft-thomson-webpush-encryption-01 [3], that's currently the case. Cheers AGL [1] https://github.com/lt/PHP-Curve25519 [2] http://tweetnacl.cr.yp.to/index.html [3] https://tools.ietf.org/html/draft-thomson-webpush-encryption-01 From nobody Wed Jul 29 19:38:19 2015 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 E07C61A1B53 for ; Wed, 29 Jul 2015 19:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7T4PsLsgvR9 for ; Wed, 29 Jul 2015 19:38:17 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 9EE351A1A94 for ; Wed, 29 Jul 2015 19:38:17 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t6U2cD1B045753 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 29 Jul 2015 21:38:13 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <55B98E15.1000600@nostrum.com> Date: Wed, 29 Jul 2015 21:38:13 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Adam Langley , webpush@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Webpush] Asymmetric Key Use X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 02:38:19 -0000 On 7/29/15 18:09, Adam Langley wrote: > Lastly, I think my colleague, David Benjamin, has pointed this out > already, but private keys are private and public keys are generally > not. It's odd, and that translates as questionable, to depend on the > secrecy of a public key for authentication. By my reading of > draft-thomson-webpush-encryption-01 [3], that's currently the case. Can you be more specific about your misgivings here? Do you have some concrete attack in mind, or are you just wary of novel application of asymmetric keys that don't conform to the traditional public/private model? By my reading, the current proposal is congruent with the use of bearer tokens for authorization, and we understand the properties of that kind of system pretty well. As a consequence, the point that you and David raise seems to be an objection to terminology -- treating "public" as an English word instead of a term of art -- rather than an issue with the way the underlying cryptography is being used. That said, you live and breathe this stuff, while I only make use of it and presume it works. I would expect that, if there is a flaw here, someone with your background would be able to raise a specific, concrete objection. /a From nobody Thu Jul 30 14:21:10 2015 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 36D3E1ACCE8 for ; Thu, 30 Jul 2015 14:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 8dqzT3WPcI8K for ; Thu, 30 Jul 2015 14:21:08 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c: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 3FF981AC3CB for ; Thu, 30 Jul 2015 14:21:08 -0700 (PDT) Received: by vkci6 with SMTP id i6so14856544vkc.3 for ; Thu, 30 Jul 2015 14:21:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=alyTNFgsq8GhspBLcrBexttNqYyBubuvDGynECIyYLw=; b=Nhx2QxGzvSUp4BakUycF5oOxavW+D2eovJ2TY5nlYgiunxK9Wad6dCX3+p0FbGel2w x+ywLThcNrzBF5j3d037etrQWPLJfpJhPMt1ER4e5vV3XixKnN23FBerslurXV59wJMT Kg6yOFFMzNVRrOnswc3t4tj028/oCFLH5DnyyzUG60UpNn+1cFZN2ohGxUYf08HfAAAt 1f/jxvf7hkQvzuvrRwaCII5+BmEMV/SwxekLL4UCO1w86j1jqzsVMDOzv5pRV8u+JSGW 6rZ4E2pOsP5sO4QJAxgytKNdMo8xVGyrQ+vzSiqFRGUs+TMUJm6edHICzii96xs6VaBP i5Xw== 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=alyTNFgsq8GhspBLcrBexttNqYyBubuvDGynECIyYLw=; b=TarRD32KgUzs6LsXglGYcfMv6YyBUuWsRjA06r3v9mcvWuY6gmWXxt2DYtqXDd79w3 KRpfZefqX3dc2n7CICJA4je8iuBH/5DYMO4sn2eQo0m+/yt+nlNf/6VFFCw0OoZnhbLZ ZITcbFpNgmX3uh57HxGNRvX1/EXL0TLGsXPMo3yk/KNnURtJ0IjHeQkZMID4uEQMjXzU g0nQVqWe7CnObf3F9VJu1BCN6PIgo2/ER60aapcMsiarbBQSqQgUZi59vZuQa3b13dFJ XPrNqBhASMkbJ2Kc5Nz8Y8fk8fo0GfSIVzjXlH5PEo5rhQ0HzSUzI9NbD3I48hhy1Y8h qqGg== X-Gm-Message-State: ALoCoQn0eGLP2XzOFNe6iblV1/RXha5VMx7lduqYwT8dnO6JY/whN2iTV1wYnps09y4qJXj0pE+D X-Received: by 10.52.83.66 with SMTP id o2mr63283122vdy.26.1438291267487; Thu, 30 Jul 2015 14:21:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.193.8 with HTTP; Thu, 30 Jul 2015 14:20:45 -0700 (PDT) In-Reply-To: <55B98E15.1000600@nostrum.com> References: <55B98E15.1000600@nostrum.com> From: Adam Langley Date: Thu, 30 Jul 2015 14:20:45 -0700 Message-ID: To: Adam Roach Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: webpush@ietf.org Subject: Re: [Webpush] Asymmetric Key Use X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 21:21:09 -0000 On Wed, Jul 29, 2015 at 7:38 PM, Adam Roach wrote: > Can you be more specific about your misgivings here? Do you have some > concrete attack in mind, or are you just wary of novel application of > asymmetric keys that don't conform to the traditional public/private model? Mostly it's a wariness, but here's a possible concrete problem: Implementations don't consider public keys to be secret. If this protocol is extended in the future and ends up using signatures, then verification of a signature by a public key will often leak side-channel information because all the inputs are "public". It would even be plausible that an implementation of a scalar-multiplication could leak information about the "public" key as long as it didn't leak information about the private one. (Although I'm not aware of any implementations that actually act like that.) But I think the wariness is actually the bigger issue. It's died down recently but, for many years, people would think that "SSL 3.0" was superior to "TLS 1.0" etc because the number's bigger. It's wrong, but I understand where the confusion comes from. People would only enable SSLv3 because it's the "best"! Likewise, if people are worried about implementations in various languages then they are expecting many implementations. When some poor implementation screws up because they didn't understand that the public key is private then I'll, likewise, have quite a lot of sympathy for them. (We also need to ensure that the encoding of secrets in this protocol is constant-time as base64 generally isn't, but that's the case no matter what is used.) Cheers AGL