From nobody Sun Nov 1 15:58:18 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 E55571B3B8E for ; Sun, 1 Nov 2015 15:58:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhfR9gKftO4Z for ; Sun, 1 Nov 2015 15:58:12 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::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 9C4EF1B3B8B for ; Sun, 1 Nov 2015 15:58:11 -0800 (PST) Received: by wmeg8 with SMTP id g8so46487365wme.0 for ; Sun, 01 Nov 2015 15:58:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1yLDOGx+qQ8fkN/aBbMfNJl4d7AE3l1Phzi82/adbB8=; b=z8aJfRokdeEzbkXZQuMmiEnadX5DRmQPW6z5XAcYpRZ6DBQkHxJ60xH4Za8e1NaD97 okou8DTg323d9GsUfNtvYsymzIpTBN83L2ZlaljVpaHv8Tz2O86F/GOcLJPDtMRGHmnN HuMxR0SbDku7RccYDqVpPVNhJJFgWs2tYg4Jb7K8HHNgJnfJeNslNJ1rNOyT3vrupfdM dxqHdKe6IDH0S/4ineMVDYwzcSsaKlI95TDEaC5Ki/mkqwqgItdOPbrfa1769VDhJvze 1Y26MmM+OsQiR7Mx1pLSjVzodHlBpNHBJoD0pqLL19Cgs7LSVWBHbwSsIc1nM9TRtfTI YYAg== 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=1yLDOGx+qQ8fkN/aBbMfNJl4d7AE3l1Phzi82/adbB8=; b=ARVQ0GXy/vFs3o4en0IB0sV5VL7Pc84v+VSKzjvTs0MCbq2+TPs8BCwb7cJJ6Zocjw PNDDW+XVyqC6Y5g94gvb4wK+0Fh5yggQIGYXgf970Bt1bTUycMVEvbs2NtyHW6mEGarj Ze3akX//90786SFPGiSKCZf3HLzuqY+Xdn66g7TPieLnevEtv9bwdiMI/YN0+CKmQ3R0 RRnXTWi3J2Dss+GIVmO6ZilBGwp4ru67Ih5okrJ+8AJgOsflq2cuozoSBLGpPDUzhE3H YiN4FnivomRl0DvMwTs5hYeV814jnqBlqeYunvcoQ0ef2JnVlmBO9EiNY91FJ3NyaFHM Bk7g== X-Gm-Message-State: ALoCoQlQ0GmU2OA90xnUK/x1jeEd3rMCWZT3nTUy/s3+j3XBusJ9Jz0mC8C00VbcE3EWgumTv20i MIME-Version: 1.0 X-Received: by 10.28.217.18 with SMTP id q18mr10294982wmg.10.1446422289055; Sun, 01 Nov 2015 15:58:09 -0800 (PST) Received: by 10.27.155.207 with HTTP; Sun, 1 Nov 2015 15:58:09 -0800 (PST) In-Reply-To: References: Date: Sun, 1 Nov 2015 15:58:09 -0800 Message-ID: From: Benjamin Bangert To: Brian Raymor Content-Type: multipart/alternative; boundary=001a1146905ebc24590523836eb9 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Provide a method to indicate rate-limit issues 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, 01 Nov 2015 23:58:14 -0000 --001a1146905ebc24590523836eb9 Content-Type: text/plain; charset=UTF-8 Yep, I think this would work fine. On Sat, Oct 31, 2015 at 3:04 PM, Brian Raymor wrote: > On October 31 2015 at 4:24 AM, Benjamin Bangert > wrote: > > > It would be nice to have a uniform way to indicate to an Application > Server that its being rate-limited > > and it should back-off on its sending, in a separate way than using a > 503. 503's are used for a variety > > of issues, separate from rate-limiting, perhaps a different status code, > and/or a header indicating > > when the app-server should resume. > > The earlier proposal from JR - > http://www.ietf.org/mail-archive/web/webpush/current/msg00308.html - was > to include a reference to 429 with Retry-Header: > > https://tools.ietf.org/html/rfc6585 > > The 429 status code indicates that the user has sent too many > requests in a given amount of time ("rate limiting"). > > The response representations SHOULD include details explaining the > condition, and MAY include a Retry-After header indicating how long > to wait before making a new request. > > For example: > > HTTP/1.1 429 Too Many Requests > Content-Type: text/html > Retry-After: 3600 > > Would this address your requirements? > > ...Brian > > > > --001a1146905ebc24590523836eb9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yep, I think this would work fine.

On Sat, Oct 31, 2015 at 3:04 PM= , Brian Raymor <Brian.Raymor@microsoft.com> wrote:<= br>
On October 31 2015 at 4:= 24 AM, Benjamin Bangert <bbanger= t@mozilla.com> wrote:

> It would be nice to have a uniform way to indicate to an Application S= erver that its being rate-limited
> and it should back-off on its sending, in a separate way than using a = 503. 503's are used for a variety
> of issues, separate from rate-limiting, perhaps a different status cod= e, and/or a header indicating
> when the app-server should resume.

The earlier proposal from JR - http://www.ietf.org/mail-archive/web/webpush/current/msg00308.html = - was to include a reference to 429 with Retry-Header:

https://tools.ietf.org/html/rfc6585

=C2=A0 =C2=A0The 429 status code indicates that the user has sent too many<= br> =C2=A0 =C2=A0requests in a given amount of time ("rate limiting")= .

=C2=A0 =C2=A0The response representations SHOULD include details explaining= the
=C2=A0 =C2=A0condition, and MAY include a Retry-After header indicating how= long
=C2=A0 =C2=A0to wait before making a new request.

=C2=A0 =C2=A0For example:

=C2=A0 =C2=A0HTTP/1.1 429 Too Many Requests
=C2=A0 =C2=A0Content-Type: text/html
=C2=A0 =C2=A0Retry-After: 3600

Would this address your requirements?

...Brian




--001a1146905ebc24590523836eb9-- From nobody Sun Nov 1 18:27:46 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 B1C6A1ACEAA for ; Sun, 1 Nov 2015 18:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p32XM8V8z5RI for ; Sun, 1 Nov 2015 18:27:42 -0800 (PST) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::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 48F581ACEAE for ; Sun, 1 Nov 2015 18:27:41 -0800 (PST) Received: by igpw7 with SMTP id w7so40557264igp.1 for ; Sun, 01 Nov 2015 18:27:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=7L/kcENTG1ldRP/0V0SoF24t9It8wEvBpvcXm9Z3dQU=; b=sMdbjtLVqTXFZQ9fLOD9ftwyz9m6/hgldeCrzoiLZ6s14zLFPikFtLa6XYpVHguZ7V kXKP56Vp7gyM4vvLZ21bI/7txPZ8grwV0JMrW4YLQY0isaXSl+ZBPI15F5g5R2eI4l2K gScFMmW5d++klJdfMmGGkZ6n6RXRQyDGx/Dk60KElvgGS9vmV3+nHzFUXUEHX0WvFCnE hLo9v6Ugajr0CqI5BlTP6wJJ3y9v8PlUL6P3kWHQqs2v00/UKwuM9676BOSDraofnvFd +tQfXwduakya7PZkkUS+XXWhEyKNX9N/Zal0sljhtDIf6OovASoUG2MeqohPmKgA3VIh zaOw== MIME-Version: 1.0 X-Received: by 10.50.143.4 with SMTP id sa4mr9071883igb.76.1446431260625; Sun, 01 Nov 2015 18:27:40 -0800 (PST) Received: by 10.107.153.6 with HTTP; Sun, 1 Nov 2015 18:27:40 -0800 (PST) Date: Sun, 1 Nov 2015 18:27:40 -0800 Message-ID: From: Fabio Chiussi To: webpush@ietf.org Content-Type: multipart/alternative; boundary=001a1134bce27b4fdd052385851d Archived-At: Subject: [Webpush] draft-chiussi-webpush-subscription-less-framework-01 and request for feedback on Subscription Management 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, 02 Nov 2015 02:27:44 -0000 --001a1134bce27b4fdd052385851d Content-Type: text/plain; charset=UTF-8 Hi All, I submitted a new draft: draft-chiussi-webpush-subscription-less-framework-01, which I will briefly present at the WG meeting tomorrow. This draft discusses two issues: i) a number of relevant use cases for webpush may benefit from a "relaxed" model of subscription, and ii) there is an emerging need for global management of webpush traffic across applications. As a possible solution for both issues, this draft advocates the introduction of a notion of trusted "Subscription Authority" in charge of controlling webpush traffic to each UA. Beyond the specific solution proposed in this draft, I would like to solicit feedback from the mailing list on the more general issue of Subscription Management, which we can discuss tomorrow at the meeting. Specifically, any comments would be greatly appreciated on the following. 1. For the reasons outlined in the draft, Subscription Management seems a very relevant practical issue that needs to be addressed. 2. In the current core protocol WG document, Subscription Management is only addressed in passing, by assuming some kind of control policy in assigning the subscriptions. At this time, neither the issues and use cases related to Subscription Management, nor the possible solutions have been fully studied in the draft. I think this is simply due to the fact that the core protocol design, for obvious reasons, has been the focus of the work so far, and there has not been sufficient time yet to fully address other relevant issues, such as Subscription Management 3. However, the state of the work on the core protocol design has reached sufficient maturity that the WG should start considering to address some of these other topics as well. Subscription Management seems a critical and urgent one, since it has very important practical ramifications. The solution proposed in this draft is simply one of possible candidates, and Subscription Management certainly deserves a more comprehensive study, and possibly develop a framework for Subscription Management. Because of its practical relevancy, subscription Management should become a WG item. I'll compile any comments that the mailing list may have on these topics, and bring them forward for discussion at the meeting tomorrow. Thanks, Fabio --001a1134bce27b4fdd052385851d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi = All,

=
I submitted a new dr= aft: draft-chiussi-webpush-subscript= ion-less-framework-01, which I will briefly present at the WG meeting tomor= row. This draft discusses two issues: i) a number of relevant use cases for= webpush may benefit from a "relaxed" model of subscription, and = ii) there is an emerging need for global management of webpush traffic acro= ss applications.=C2=A0

As= a possible solution for both issues, this draft advocates the introduction= of a notion of trusted "Subscription Authority" in charge of con= trolling webpush traffic to each UA.

Beyond the specific solution proposed in this draft, I would li= ke to solicit feedback from the mailing list on the more general issue of S= ubscription Management, which we can discuss tomorrow at the meeting. Speci= fically, any comments would be greatly appreciated on the following.
<= div class=3D"gmail_default" style=3D"font-size:large">
1. For the reasons outlined in= the draft, Subscription Management seems a very relevant practical issue t= hat needs to be addressed.

2. In the current core protocol WG document, Subscription Management is o= nly addressed in passing, by assuming some kind of control policy in assign= ing the subscriptions. At this time, neither the issues and use cases relat= ed to Subscription Management, nor the possible solutions have been fully s= tudied in the draft. I think this is simply due to the fact that the core p= rotocol design, for obvious reasons, has been the focus of the work so far,= and there has not been sufficient time yet to fully address other relevant= issues, such as Subscription Management

3. However, the state of the work on the core protocol desi= gn has reached sufficient maturity that the WG should start considering to = address some of these other topics as well. Subscription Management seems a= critical and urgent one, since it has very important practical ramificatio= ns. The solution proposed in this draft is simply one of possible candidate= s, and Subscription Management certainly deserves a more comprehensive stud= y, and possibly develop a framework for Subscription Management. Because of= its practical relevancy, subscription Management should become a WG item.<= /div>

I'll compile any comm= ents that the mailing list may have on these topics, and bring them forward= for discussion at the meeting tomorrow.

Thanks,
Fabio
=

=
--001a1134bce27b4fdd052385851d-- From nobody Sun Nov 1 23:12:22 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 BCC8B1B3378 for ; Sun, 1 Nov 2015 23:12:14 -0800 (PST) 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 riBXk0_KkQqO for ; Sun, 1 Nov 2015 23:12:13 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::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 4D1901B3373 for ; Sun, 1 Nov 2015 23:12:13 -0800 (PST) Received: by lbbec13 with SMTP id ec13so82614520lbb.0 for ; Sun, 01 Nov 2015 23:12:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=loG+brAiHfj+bZ7oiopp2lpVcnzU/zVWbYp8HjD3LkM=; b=chexmhyS4XMIP0D/82dbeuttqwKw+DDOfgR1Ayfk4NT3+0+GKRonmoYJPdTOuhhKPr r9D5NjfIw1laUGBOAu9jM4SGkjS8zSJ5yCYoXAnKXdKj1qJeDoaI/uqZ5hDv9Wy53zPV z32jRfaHM08BY8p4bVeBo89qT3r0uG2KSOKlNmQlhux6c8dd3wniRmjvITKn7r4cfBCC p0ifCY/7zdl9sk0582yFljRLHzizZgMB3reGaHbar7ZtCLzgPFyBZEaRqL9cMFdmeDeh 5ZsgKp3aeervbhHEJipkMzuHEO6WnYJs4Ry+ZcpqBJHm5fGYTZaB7zZhWTtLgfLPLCzc KYvg== 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=loG+brAiHfj+bZ7oiopp2lpVcnzU/zVWbYp8HjD3LkM=; b=BDwq1pIZ+R9he1TiyE6AMEQrDseFW99uN6O32sqAmQyLajUKZ8QzIOlhclLtkT0mhd 4c1lML4ZlIrf/XXW3ayrvjfeecwLQBVwyitmexxqnla68hAWrHJHkWeKPD/PMgR+ObGB lskh51Ri2WZTI+xpYvXuKv3aIA01ovS+daciBeEUD3+4yAJRTb10uWpFcny5zhV4OwZm ulhWVQHdr1H0mA5rYRYN5JsL/NCLtVrIRa6uo01lo/LqSBQI0LcXyYR9eAPyrWW9sDnk aLMeufxwtVCKc85UgGFl+321S6p67KMSE7D545HK2czEGb/9HE5YGyIDfqUy+gVdBXKd E4Dg== X-Gm-Message-State: ALoCoQmzRfJRj2VlQiVLysG2UQLO3oaedgmIOmJiFPdUzpqPa397XO5QGVjLljwlodW7cdnPwant MIME-Version: 1.0 X-Received: by 10.112.181.164 with SMTP id dx4mr9448383lbc.29.1446448331410; Sun, 01 Nov 2015 23:12:11 -0800 (PST) Received: by 10.25.21.98 with HTTP; Sun, 1 Nov 2015 23:12:11 -0800 (PST) Date: Mon, 2 Nov 2015 16:12:11 +0900 Message-ID: From: Peter Beverloo To: "webpush@ietf.org" Content-Type: multipart/alternative; boundary=001a11c3690cfb08fa0523897e74 Archived-At: Subject: [Webpush] ietf-webpush-encryption - untrusted push services 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, 02 Nov 2015 07:12:14 -0000 --001a11c3690cfb08fa0523897e74 Content-Type: text/plain; charset=UTF-8 We don't trust the intermediary. What if they are the attacker? (1) There's a possibility of contributory behaviour with other DH groups. E.g. using an ephemeral key of 0 (or 1) forcing the shared key to be zero, or using one of the 12 "forbidden" Curve25519 values. Since P-256 is a prime-ordered group this doesn't apply today, but it would be a subtle issue if we were to change curves. (2) The client is vulnerable to DoS attacks. Authentication only happens while deciphering the payload with the calculated content encryption key, which can be a heavy operation for lower-end devices. Being able to authenticate the message before doing public key operations would mitigate this. One option is for the UA to create a HMAC key per subscription, which it will transfer to the application server, together with the public key, upon creating a subscription. The application server will then HMAC the whole message -including the ephemeral key- before sending it to the push service. This mitigates both concerns. Thanks, Peter --001a11c3690cfb08fa0523897e74 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We don't trust the intermediary. What if they are the=C2=A0= attacker?

=C2=A0 =C2=A0 (1) There's a possibility of co= ntributory behaviour with other DH groups.

E.g. using an ephemeral key = of 0 (or 1) forcing the shared key to be zero, or using one of the 12 "= ;forbidden" Curve25519 values.
Since P-256 is a prime-ordered grou= p this doesn't apply today, but it would be a subtle issue if we were t= o change curves.

=C2=A0 =C2=A0 (2) The client is vulnerable to DoS att= acks.

Authentication only happens while deciphering the payload with th= e calculated content encryption key, which can be a heavy operation for low= er-end devices. Being able to authenticate the message before doing public = key operations would mitigate this.

One option is for the UA to create a HMAC key per subscription, whic= h it will transfer to the application server, together with the public key,= upon creating a subscription.

The application server will then HMAC th= e whole message -including the ephemeral key- before sending it to the push= service. This mitigates both concerns.

Thanks,
Peter
--001a11c3690cfb08fa0523897e74-- From nobody Mon Nov 2 09:11: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 2A9801B49E0 for ; Mon, 2 Nov 2015 09:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yt0N3d4ysaES for ; Mon, 2 Nov 2015 09:11:10 -0800 (PST) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c: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 414171A6F99 for ; Mon, 2 Nov 2015 09:11:10 -0800 (PST) Received: by wicll6 with SMTP id ll6so54343608wic.0 for ; Mon, 02 Nov 2015 09:11:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ej4zCz+TZQMi/pW+l59h0GBfxOVYFp7USXcEVtaBkFA=; b=QcjHA/qA1yV6xP8dKyiKgKkDMW012QBGbtb+fTKB2EJWF7lqu6Q92Kb4Ro0o/nFF0v EpmVrSx185n6WH3HMDosGJJayDH/pIW1jJ44E5hsP6blukTP6OAhhsPh2WXMJEFGvYhs ZwlZKuGTqsoj5RjweiTKOx9zfE3BMOuKXPJ79uw99XLS3vJuFQpBt9U7AJ46Bz43ZviX hhr/Jo5XiE+jnSSwB4Gk/O1LlLeuRA4YS91VDzpH/Sd2Ihy7dTHI1qeUddiHPjW5j4RD U2pUL9LBa8E5BHW4VQTwSPNGLReat5l10K9R4IS+l2CleJY6NFJ6niGIVBmSn5yKve1o rsng== 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=ej4zCz+TZQMi/pW+l59h0GBfxOVYFp7USXcEVtaBkFA=; b=O9DCoZby4CuZOKN4SGhHm6lq1EHUiD2txylHto00K3HMjdGkaXtsdEha7gI5mUfQR4 EtasbZk8vaBx9/pHncmMw2MrzjTOC0yujyRyX0IROfn34CGc4qIsIn+wCaTquk+fvfbA 6zgZcWw+g/8nQJZtpqGx1Tox1G8seyRTXIf14L973Zj1TxGqRtPJ5KXI/DyqZlq7+B7k xhqenXI+eauEwTLNgWCx9DSBkKEKA8QavpWdltv+gQd/2p98QlyYEJJNyFqOfWBD5qyQ oKyV7gEIZWo5CcBJDdskQl+rLMlUEaaf9jgtGFbLd5iqzH1D8Y/w2dGIjHQZuwRzMOsI 5klQ== X-Gm-Message-State: ALoCoQmNtgvmJWqqTMUMWvQr5Fux8nGpr+zOUU+KRDxtY97UWFhSMaPzSWePuCZWBh9PA94HitTI MIME-Version: 1.0 X-Received: by 10.194.63.7 with SMTP id c7mr24481622wjs.70.1446484268675; Mon, 02 Nov 2015 09:11:08 -0800 (PST) Received: by 10.27.155.207 with HTTP; Mon, 2 Nov 2015 09:11:08 -0800 (PST) In-Reply-To: References: Date: Mon, 2 Nov 2015 09:11:08 -0800 Message-ID: From: Benjamin Bangert To: Fabio Chiussi Content-Type: multipart/alternative; boundary=047d7b86d9cc021406052391ddc7 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] draft-chiussi-webpush-subscription-less-framework-01 and request for feedback on Subscription Management 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, 02 Nov 2015 17:11:13 -0000 --047d7b86d9cc021406052391ddc7 Content-Type: text/plain; charset=UTF-8 Is there a link to this document I can read? Thanks, Ben On Sun, Nov 1, 2015 at 6:27 PM, Fabio Chiussi wrote: > Hi All, > > I submitted a new draft: draft-chiussi-webpush-subscription-less-framework-01, > which I will briefly present at the WG meeting tomorrow. This draft > discusses two issues: i) a number of relevant use cases for webpush may > benefit from a "relaxed" model of subscription, and ii) there is an > emerging need for global management of webpush traffic across applications. > > As a possible solution for both issues, this draft advocates the > introduction of a notion of trusted "Subscription Authority" in charge of > controlling webpush traffic to each UA. > > Beyond the specific solution proposed in this draft, I would like to > solicit feedback from the mailing list on the more general issue of > Subscription Management, which we can discuss tomorrow at the meeting. > Specifically, any comments would be greatly appreciated on the following. > > 1. For the reasons outlined in the draft, Subscription Management seems a > very relevant practical issue that needs to be addressed. > > 2. In the current core protocol WG document, Subscription Management is > only addressed in passing, by assuming some kind of control policy in > assigning the subscriptions. At this time, neither the issues and use cases > related to Subscription Management, nor the possible solutions have been > fully studied in the draft. I think this is simply due to the fact that the > core protocol design, for obvious reasons, has been the focus of the work > so far, and there has not been sufficient time yet to fully address other > relevant issues, such as Subscription Management > > 3. However, the state of the work on the core protocol design has reached > sufficient maturity that the WG should start considering to address some of > these other topics as well. Subscription Management seems a critical and > urgent one, since it has very important practical ramifications. The > solution proposed in this draft is simply one of possible candidates, and > Subscription Management certainly deserves a more comprehensive study, and > possibly develop a framework for Subscription Management. Because of its > practical relevancy, subscription Management should become a WG item. > > I'll compile any comments that the mailing list may have on these topics, > and bring them forward for discussion at the meeting tomorrow. > > Thanks, > Fabio > > > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > > --047d7b86d9cc021406052391ddc7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Is there a link to this document I can read?
=
Thanks,
Ben

On Sun, Nov 1, 2015 at 6:27 PM, Fabio Chiussi <fabiochiussi@gmail.com> wrote:
Hi All,

<= /div>
I submitted a n= ew draft: draft-chiussi-webpush= -subscription-less-framework-01, which I will briefly present at the WG mee= ting tomorrow. This draft discusses two issues: i) a number of relevant use= cases for webpush may benefit from a "relaxed" model of subscrip= tion, and ii) there is an emerging need for global management of webpush tr= affic across applications.=C2=A0

As a possible solution for both issues, this draft advocates the in= troduction of a notion of trusted "Subscription Authority" in cha= rge of controlling webpush traffic to each UA.

Beyond the specific solution proposed in this draft, = I would like to solicit feedback from the mailing list on the more general = issue of Subscription Management, which we can discuss tomorrow at the meet= ing. Specifically, any comments would be greatly appreciated on the followi= ng.

<= div class=3D"gmail_default" style=3D"font-size:large">1. For the reasons ou= tlined in the draft, Subscription Management seems a very relevant practica= l issue that needs to be addressed.

2. In the current core protocol WG document, Subscription Manage= ment is only addressed in passing, by assuming some kind of control policy = in assigning the subscriptions. At this time, neither the issues and use ca= ses related to Subscription Management, nor the possible solutions have bee= n fully studied in the draft. I think this is simply due to the fact that t= he core protocol design, for obvious reasons, has been the focus of the wor= k so far, and there has not been sufficient time yet to fully address other= relevant issues, such as Subscription Management

3. However, the state of the work on the core prot= ocol design has reached sufficient maturity that the WG should start consid= ering to address some of these other topics as well. Subscription Managemen= t seems a critical and urgent one, since it has very important practical ra= mifications. The solution proposed in this draft is simply one of possible = candidates, and Subscription Management certainly deserves a more comprehen= sive study, and possibly develop a framework for Subscription Management. B= ecause of its practical relevancy, subscription Management should become a = WG item.

I'll compile= any comments that the mailing list may have on these topics, and bring the= m forward for discussion at the meeting tomorrow.

Thanks,
Fabio

<= br>

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


--047d7b86d9cc021406052391ddc7-- From nobody Mon Nov 2 13:30:48 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 465871A0BE8 for ; Mon, 2 Nov 2015 13:30:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 Xinq0Qj9lNee for ; Mon, 2 Nov 2015 13:30:43 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0126.outbound.protection.outlook.com [65.55.169.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BD9C1A8729 for ; Mon, 2 Nov 2015 13:30:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Mwxtqox77xZeEY0e7HCZOPewu9e1hTe4UgRN+0jXE18=; b=JAlFx1fTmzRLQ8UdwdERQ6j2waCi2Xj9Zb5UAT5HTX+gNXa4/ypJqvY5r57RrAP1LtNZbt0E1wP8Af3EIHKRRPc5qlxhTNZlaUJSFDF0GOhREgtqznNHMdjJYiMyrMl0kt3XBXMSSdGOfVD74E75o2Lc+hzx2jzq9f78U/5+dsA= 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.312.18; Mon, 2 Nov 2015 21:30:39 +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.0312.014; Mon, 2 Nov 2015 21:30:39 +0000 From: Brian Raymor To: Benjamin Bangert , Fabio Chiussi Thread-Topic: [Webpush] draft-chiussi-webpush-subscription-less-framework-01 and request for feedback on Subscription Management Thread-Index: AQHRFRYY/SUqv5xNwUCxZ/mO2aXlZZ6I+MEAgABIQRA= Date: Mon, 2 Nov 2015 21:30:39 +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: spf=none (sender IP is ) smtp.mailfrom=Brian.Raymor@microsoft.com; x-originating-ip: [122.210.83.163] x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0647; 5:oITsIUXpDWXLe/dE7Vrfqi7aLsI2WcJp51vyqosI5U+I21vXOQm8C5UVBPjB6Q++0d2P/uWoqZcZ0jvUUjcZ9lQnJkBUZYfDJWs+Nx9QuyrUaD/RdNgjYxX78gf4NjgFWWfQ/sEEFNKMKNU8t3IElg==; 24:2LvlHenpatBNs3BJv7/fpajAPgtwsO3FDQ1GiHuLOQg4/uOb1tgWgOsN/2gsSauiCN8TnFX91e+EqqgPE16D5q87qJR+t3evWNxXx3HBICs=; 20:SEj7D/eLWfKzFamQZRqDR9aQXX22COXzibjQuVYQLi4nOwt+vD2AOLtUA0deQjOUs7zwB17uLxX/5LuwtSRGcA== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42140001); SRVR:BY2PR0301MB0647; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001)(61426024)(61427024); SRVR:BY2PR0301MB0647; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0647; x-forefront-prvs: 0748FF9A04 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(53754006)(189002)(199003)(164054003)(377454003)(76176999)(19580405001)(5002640100001)(16236675004)(19609705001)(106116001)(101416001)(5001770100001)(10290500002)(5003600100002)(105586002)(10090500001)(92566002)(5001960100002)(97736004)(77096005)(8990500004)(99286002)(230783001)(2950100001)(19625215002)(81156007)(15975445007)(2900100001)(54356999)(76576001)(102836002)(5004730100002)(19580395003)(106356001)(19617315012)(74316001)(66066001)(50986999)(33656002)(5008740100001)(189998001)(122556002)(11100500001)(5007970100001)(86362001)(86612001)(19300405004)(40100003)(5005710100001)(87936001)(10400500002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0647; H:BY2PR0301MB0647.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR0301MB0647DA6045C7DB004A1E11D2832C0BY2PR0301MB0647_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2015 21:30:39.7465 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0647 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] draft-chiussi-webpush-subscription-less-framework-01 and request for feedback on Subscription Management 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, 02 Nov 2015 21:30:46 -0000 --_000_BY2PR0301MB0647DA6045C7DB004A1E11D2832C0BY2PR0301MB0647_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtY2hpdXNzaS13ZWJwdXNoLXN1 YnNjcmlwdGlvbi1sZXNzLWZyYW1ld29yay8NCg0KDQpGcm9tOiBXZWJwdXNoIFttYWlsdG86d2Vi cHVzaC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQmVuamFtaW4gQmFuZ2VydA0KU2Vu dDogVHVlc2RheSwgTm92ZW1iZXIgMywgMjAxNSAyOjExIEFNDQpUbzogRmFiaW8gQ2hpdXNzaSA8 ZmFiaW9jaGl1c3NpQGdtYWlsLmNvbT4NCkNjOiB3ZWJwdXNoQGlldGYub3JnDQpTdWJqZWN0OiBS ZTogW1dlYnB1c2hdIGRyYWZ0LWNoaXVzc2ktd2VicHVzaC1zdWJzY3JpcHRpb24tbGVzcy1mcmFt ZXdvcmstMDEgYW5kIHJlcXVlc3QgZm9yIGZlZWRiYWNrIG9uIFN1YnNjcmlwdGlvbiBNYW5hZ2Vt ZW50DQoNCklzIHRoZXJlIGEgbGluayB0byB0aGlzIGRvY3VtZW50IEkgY2FuIHJlYWQ/DQpUaGFu a3MsDQpCZW4NCg0KT24gU3VuLCBOb3YgMSwgMjAxNSBhdCA2OjI3IFBNLCBGYWJpbyBDaGl1c3Np IDxmYWJpb2NoaXVzc2lAZ21haWwuY29tPG1haWx0bzpmYWJpb2NoaXVzc2lAZ21haWwuY29tPj4g d3JvdGU6DQpIaSBBbGwsDQoNCkkgc3VibWl0dGVkIGEgbmV3IGRyYWZ0OiBkcmFmdC1jaGl1c3Np LXdlYnB1c2gtc3Vic2NyaXB0aW9uLWxlc3MtZnJhbWV3b3JrLTAxLCB3aGljaCBJIHdpbGwgYnJp ZWZseSBwcmVzZW50IGF0IHRoZSBXRyBtZWV0aW5nIHRvbW9ycm93LiBUaGlzIGRyYWZ0IGRpc2N1 c3NlcyB0d28gaXNzdWVzOiBpKSBhIG51bWJlciBvZiByZWxldmFudCB1c2UgY2FzZXMgZm9yIHdl YnB1c2ggbWF5IGJlbmVmaXQgZnJvbSBhICJyZWxheGVkIiBtb2RlbCBvZiBzdWJzY3JpcHRpb24s IGFuZCBpaSkgdGhlcmUgaXMgYW4gZW1lcmdpbmcgbmVlZCBmb3IgZ2xvYmFsIG1hbmFnZW1lbnQg b2Ygd2VicHVzaCB0cmFmZmljIGFjcm9zcyBhcHBsaWNhdGlvbnMuDQoNCkFzIGEgcG9zc2libGUg c29sdXRpb24gZm9yIGJvdGggaXNzdWVzLCB0aGlzIGRyYWZ0IGFkdm9jYXRlcyB0aGUgaW50cm9k dWN0aW9uIG9mIGEgbm90aW9uIG9mIHRydXN0ZWQgIlN1YnNjcmlwdGlvbiBBdXRob3JpdHkiIGlu IGNoYXJnZSBvZiBjb250cm9sbGluZyB3ZWJwdXNoIHRyYWZmaWMgdG8gZWFjaCBVQS4NCg0KQmV5 b25kIHRoZSBzcGVjaWZpYyBzb2x1dGlvbiBwcm9wb3NlZCBpbiB0aGlzIGRyYWZ0LCBJIHdvdWxk IGxpa2UgdG8gc29saWNpdCBmZWVkYmFjayBmcm9tIHRoZSBtYWlsaW5nIGxpc3Qgb24gdGhlIG1v cmUgZ2VuZXJhbCBpc3N1ZSBvZiBTdWJzY3JpcHRpb24gTWFuYWdlbWVudCwgd2hpY2ggd2UgY2Fu IGRpc2N1c3MgdG9tb3Jyb3cgYXQgdGhlIG1lZXRpbmcuIFNwZWNpZmljYWxseSwgYW55IGNvbW1l bnRzIHdvdWxkIGJlIGdyZWF0bHkgYXBwcmVjaWF0ZWQgb24gdGhlIGZvbGxvd2luZy4NCg0KMS4g Rm9yIHRoZSByZWFzb25zIG91dGxpbmVkIGluIHRoZSBkcmFmdCwgU3Vic2NyaXB0aW9uIE1hbmFn ZW1lbnQgc2VlbXMgYSB2ZXJ5IHJlbGV2YW50IHByYWN0aWNhbCBpc3N1ZSB0aGF0IG5lZWRzIHRv IGJlIGFkZHJlc3NlZC4NCg0KMi4gSW4gdGhlIGN1cnJlbnQgY29yZSBwcm90b2NvbCBXRyBkb2N1 bWVudCwgU3Vic2NyaXB0aW9uIE1hbmFnZW1lbnQgaXMgb25seSBhZGRyZXNzZWQgaW4gcGFzc2lu ZywgYnkgYXNzdW1pbmcgc29tZSBraW5kIG9mIGNvbnRyb2wgcG9saWN5IGluIGFzc2lnbmluZyB0 aGUgc3Vic2NyaXB0aW9ucy4gQXQgdGhpcyB0aW1lLCBuZWl0aGVyIHRoZSBpc3N1ZXMgYW5kIHVz ZSBjYXNlcyByZWxhdGVkIHRvIFN1YnNjcmlwdGlvbiBNYW5hZ2VtZW50LCBub3IgdGhlIHBvc3Np YmxlIHNvbHV0aW9ucyBoYXZlIGJlZW4gZnVsbHkgc3R1ZGllZCBpbiB0aGUgZHJhZnQuIEkgdGhp bmsgdGhpcyBpcyBzaW1wbHkgZHVlIHRvIHRoZSBmYWN0IHRoYXQgdGhlIGNvcmUgcHJvdG9jb2wg ZGVzaWduLCBmb3Igb2J2aW91cyByZWFzb25zLCBoYXMgYmVlbiB0aGUgZm9jdXMgb2YgdGhlIHdv cmsgc28gZmFyLCBhbmQgdGhlcmUgaGFzIG5vdCBiZWVuIHN1ZmZpY2llbnQgdGltZSB5ZXQgdG8g ZnVsbHkgYWRkcmVzcyBvdGhlciByZWxldmFudCBpc3N1ZXMsIHN1Y2ggYXMgU3Vic2NyaXB0aW9u IE1hbmFnZW1lbnQNCg0KMy4gSG93ZXZlciwgdGhlIHN0YXRlIG9mIHRoZSB3b3JrIG9uIHRoZSBj b3JlIHByb3RvY29sIGRlc2lnbiBoYXMgcmVhY2hlZCBzdWZmaWNpZW50IG1hdHVyaXR5IHRoYXQg dGhlIFdHIHNob3VsZCBzdGFydCBjb25zaWRlcmluZyB0byBhZGRyZXNzIHNvbWUgb2YgdGhlc2Ug b3RoZXIgdG9waWNzIGFzIHdlbGwuIFN1YnNjcmlwdGlvbiBNYW5hZ2VtZW50IHNlZW1zIGEgY3Jp dGljYWwgYW5kIHVyZ2VudCBvbmUsIHNpbmNlIGl0IGhhcyB2ZXJ5IGltcG9ydGFudCBwcmFjdGlj YWwgcmFtaWZpY2F0aW9ucy4gVGhlIHNvbHV0aW9uIHByb3Bvc2VkIGluIHRoaXMgZHJhZnQgaXMg c2ltcGx5IG9uZSBvZiBwb3NzaWJsZSBjYW5kaWRhdGVzLCBhbmQgU3Vic2NyaXB0aW9uIE1hbmFn ZW1lbnQgY2VydGFpbmx5IGRlc2VydmVzIGEgbW9yZSBjb21wcmVoZW5zaXZlIHN0dWR5LCBhbmQg cG9zc2libHkgZGV2ZWxvcCBhIGZyYW1ld29yayBmb3IgU3Vic2NyaXB0aW9uIE1hbmFnZW1lbnQu IEJlY2F1c2Ugb2YgaXRzIHByYWN0aWNhbCByZWxldmFuY3ksIHN1YnNjcmlwdGlvbiBNYW5hZ2Vt ZW50IHNob3VsZCBiZWNvbWUgYSBXRyBpdGVtLg0KDQpJJ2xsIGNvbXBpbGUgYW55IGNvbW1lbnRz IHRoYXQgdGhlIG1haWxpbmcgbGlzdCBtYXkgaGF2ZSBvbiB0aGVzZSB0b3BpY3MsIGFuZCBicmlu ZyB0aGVtIGZvcndhcmQgZm9yIGRpc2N1c3Npb24gYXQgdGhlIG1lZXRpbmcgdG9tb3Jyb3cuDQoN ClRoYW5rcywNCkZhYmlvDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KV2VicHVzaCBtYWlsaW5nIGxpc3QNCldlYnB1c2hAaWV0Zi5vcmc8bWFp bHRvOldlYnB1c2hAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3dlYnB1c2gNCg0K --_000_BY2PR0301MB0647DA6045C7DB004A1E11D2832C0BY2PR0301MB0647_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNoaXVzc2ktd2VicHVzaC1zdWJzY3JpcHRpb24tbGVzcy1m cmFtZXdvcmsvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1jaGl1c3Np LXdlYnB1c2gtc3Vic2NyaXB0aW9uLWxlc3MtZnJhbWV3b3JrLzwvYT48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEg bmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gV2VicHVz aCBbbWFpbHRvOndlYnB1c2gtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+ QmVuamFtaW4gQmFuZ2VydDxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBOb3ZlbWJlciAzLCAy MDE1IDI6MTEgQU08YnI+DQo8Yj5Ubzo8L2I+IEZhYmlvIENoaXVzc2kgJmx0O2ZhYmlvY2hpdXNz aUBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiB3ZWJwdXNoQGlldGYub3JnPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbV2VicHVzaF0gZHJhZnQtY2hpdXNzaS13ZWJwdXNoLXN1YnNjcmlw dGlvbi1sZXNzLWZyYW1ld29yay0wMSBhbmQgcmVxdWVzdCBmb3IgZmVlZGJhY2sgb24gU3Vic2Ny aXB0aW9uIE1hbmFnZW1lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PklzIHRoZXJlIGEgbGluayB0byB0aGlzIGRvY3VtZW50IEkgY2FuIHJlYWQ/PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTdW4sIE5vdiAxLCAyMDE1IGF0IDY6MjcgUE0sIEZh YmlvIENoaXVzc2kgJmx0OzxhIGhyZWY9Im1haWx0bzpmYWJpb2NoaXVzc2lAZ21haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+ZmFiaW9jaGl1c3NpQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxOC4wcHQiPkhpIEFsbCw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjE4LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxOC4wcHQi Pkkgc3VibWl0dGVkIGEgbmV3IGRyYWZ0OiBkcmFmdC1jaGl1c3NpLXdlYnB1c2gtc3Vic2NyaXB0 aW9uLWxlc3MtZnJhbWV3b3JrLTAxLCB3aGljaCBJIHdpbGwgYnJpZWZseSBwcmVzZW50IGF0IHRo ZSBXRyBtZWV0aW5nIHRvbW9ycm93LiBUaGlzIGRyYWZ0IGRpc2N1c3NlcyB0d28gaXNzdWVzOiBp KSBhIG51bWJlciBvZiByZWxldmFudCB1c2UgY2FzZXMgZm9yDQogd2VicHVzaCBtYXkgYmVuZWZp dCBmcm9tIGEgJnF1b3Q7cmVsYXhlZCZxdW90OyBtb2RlbCBvZiBzdWJzY3JpcHRpb24sIGFuZCBp aSkgdGhlcmUgaXMgYW4gZW1lcmdpbmcgbmVlZCBmb3IgZ2xvYmFsIG1hbmFnZW1lbnQgb2Ygd2Vi cHVzaCB0cmFmZmljIGFjcm9zcyBhcHBsaWNhdGlvbnMuJm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxOC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTguMHB0Ij5B cyBhIHBvc3NpYmxlIHNvbHV0aW9uIGZvciBib3RoIGlzc3VlcywgdGhpcyBkcmFmdCBhZHZvY2F0 ZXMgdGhlIGludHJvZHVjdGlvbiBvZiBhIG5vdGlvbiBvZiB0cnVzdGVkICZxdW90O1N1YnNjcmlw dGlvbiBBdXRob3JpdHkmcXVvdDsgaW4gY2hhcmdlIG9mIGNvbnRyb2xsaW5nIHdlYnB1c2ggdHJh ZmZpYyB0byBlYWNoIFVBLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTguMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE4LjBwdCI+QmV5b25kIHRoZSBzcGVjaWZpYyBzb2x1 dGlvbiBwcm9wb3NlZCBpbiB0aGlzIGRyYWZ0LCBJIHdvdWxkIGxpa2UgdG8gc29saWNpdCBmZWVk YmFjayBmcm9tIHRoZSBtYWlsaW5nIGxpc3Qgb24gdGhlIG1vcmUgZ2VuZXJhbCBpc3N1ZSBvZiBT dWJzY3JpcHRpb24gTWFuYWdlbWVudCwgd2hpY2ggd2UgY2FuIGRpc2N1c3MgdG9tb3Jyb3cgYXQg dGhlIG1lZXRpbmcuDQogU3BlY2lmaWNhbGx5LCBhbnkgY29tbWVudHMgd291bGQgYmUgZ3JlYXRs eSBhcHByZWNpYXRlZCBvbiB0aGUgZm9sbG93aW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTguMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE4LjBwdCI+MS4gRm9yIHRo ZSByZWFzb25zIG91dGxpbmVkIGluIHRoZSBkcmFmdCwgU3Vic2NyaXB0aW9uIE1hbmFnZW1lbnQg c2VlbXMgYSB2ZXJ5IHJlbGV2YW50IHByYWN0aWNhbCBpc3N1ZSB0aGF0IG5lZWRzIHRvIGJlIGFk ZHJlc3NlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE4LjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxOC4wcHQiPjIuIEluIHRoZSBjdXJyZW50IGNvcmUgcHJvdG9jb2wg V0cgZG9jdW1lbnQsIFN1YnNjcmlwdGlvbiBNYW5hZ2VtZW50IGlzIG9ubHkgYWRkcmVzc2VkIGlu IHBhc3NpbmcsIGJ5IGFzc3VtaW5nIHNvbWUga2luZCBvZiBjb250cm9sIHBvbGljeSBpbiBhc3Np Z25pbmcgdGhlIHN1YnNjcmlwdGlvbnMuIEF0IHRoaXMgdGltZSwgbmVpdGhlciB0aGUgaXNzdWVz IGFuZA0KIHVzZSBjYXNlcyByZWxhdGVkIHRvIFN1YnNjcmlwdGlvbiBNYW5hZ2VtZW50LCBub3Ig dGhlIHBvc3NpYmxlIHNvbHV0aW9ucyBoYXZlIGJlZW4gZnVsbHkgc3R1ZGllZCBpbiB0aGUgZHJh ZnQuIEkgdGhpbmsgdGhpcyBpcyBzaW1wbHkgZHVlIHRvIHRoZSBmYWN0IHRoYXQgdGhlIGNvcmUg cHJvdG9jb2wgZGVzaWduLCBmb3Igb2J2aW91cyByZWFzb25zLCBoYXMgYmVlbiB0aGUgZm9jdXMg b2YgdGhlIHdvcmsgc28gZmFyLCBhbmQgdGhlcmUgaGFzIG5vdA0KIGJlZW4gc3VmZmljaWVudCB0 aW1lIHlldCB0byBmdWxseSBhZGRyZXNzIG90aGVyIHJlbGV2YW50IGlzc3Vlcywgc3VjaCBhcyBT dWJzY3JpcHRpb24gTWFuYWdlbWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTguMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE4LjBwdCI+My4gSG93ZXZlciwgdGhlIHN0 YXRlIG9mIHRoZSB3b3JrIG9uIHRoZSBjb3JlIHByb3RvY29sIGRlc2lnbiBoYXMgcmVhY2hlZCBz dWZmaWNpZW50IG1hdHVyaXR5IHRoYXQgdGhlIFdHIHNob3VsZCBzdGFydCBjb25zaWRlcmluZyB0 byBhZGRyZXNzIHNvbWUgb2YgdGhlc2Ugb3RoZXIgdG9waWNzIGFzIHdlbGwuIFN1YnNjcmlwdGlv biBNYW5hZ2VtZW50IHNlZW1zDQogYSBjcml0aWNhbCBhbmQgdXJnZW50IG9uZSwgc2luY2UgaXQg aGFzIHZlcnkgaW1wb3J0YW50IHByYWN0aWNhbCByYW1pZmljYXRpb25zLiBUaGUgc29sdXRpb24g cHJvcG9zZWQgaW4gdGhpcyBkcmFmdCBpcyBzaW1wbHkgb25lIG9mIHBvc3NpYmxlIGNhbmRpZGF0 ZXMsIGFuZCBTdWJzY3JpcHRpb24gTWFuYWdlbWVudCBjZXJ0YWlubHkgZGVzZXJ2ZXMgYSBtb3Jl IGNvbXByZWhlbnNpdmUgc3R1ZHksIGFuZCBwb3NzaWJseSBkZXZlbG9wIGEgZnJhbWV3b3JrDQog Zm9yIFN1YnNjcmlwdGlvbiBNYW5hZ2VtZW50LiBCZWNhdXNlIG9mIGl0cyBwcmFjdGljYWwgcmVs ZXZhbmN5LCBzdWJzY3JpcHRpb24gTWFuYWdlbWVudCBzaG91bGQgYmVjb21lIGEgV0cgaXRlbS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE4LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxOC4wcHQiPkknbGwgY29tcGlsZSBhbnkgY29tbWVudHMgdGhhdCB0aGUgbWFpbGlu ZyBsaXN0IG1heSBoYXZlIG9uIHRoZXNlIHRvcGljcywgYW5kIGJyaW5nIHRoZW0gZm9yd2FyZCBm b3IgZGlzY3Vzc2lvbiBhdCB0aGUgbWVldGluZyB0b21vcnJvdy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjE4LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxOC4wcHQiPlRo YW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE4LjBwdCI+RmFiaW88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjE4LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxOC4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KV2VicHVzaCBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86V2VicHVzaEBpZXRmLm9yZyI+V2VicHVzaEBp ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3dlYnB1c2giIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3dlYnB1c2g8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BY2PR0301MB0647DA6045C7DB004A1E11D2832C0BY2PR0301MB0647_-- From nobody Mon Nov 2 15:25: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 1F1A61A89A6 for ; Mon, 2 Nov 2015 15:25:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gShSSesDWPr1 for ; Mon, 2 Nov 2015 15:25:38 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (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 CF6E01A8A7B for ; Mon, 2 Nov 2015 15:25:37 -0800 (PST) Received: by igbdj2 with SMTP id dj2so1858899igb.1 for ; Mon, 02 Nov 2015 15:25:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=i7oWT2Akm6WtopcfP/VkJQh7O04zHvYhY4id4WTizuA=; b=XdOj9KqFpoYUJWAWwsohi5N/M1yHzexMjyEKH2Y6R6VblrseFNzGxG6nXp31H8/8i3 8KAy9mDzx/vNHChgg3FxCBVGF6siI+70PNQzSHpoFkDwnhJMYhomVuYtGjg7U2GcebR7 /oh2+plFeojy3MnyjPAklQi7qtJufefT4LRWcnQm3bt9exrXKGOpER69xWyaGJVZJPC7 pQQAJK3EsXlY+2BkITZVyJJns0Q6LO4hEW8Bej0eujAVSoMSl3vyLNQX2bGmholBKqLD iL3DMTn9WkHR/rrVQA3EeCYwTaZmJASTHqGn33J4/0yJBuz6nf9EB03V7t6w5eLeWpOi as1A== MIME-Version: 1.0 X-Received: by 10.50.60.104 with SMTP id g8mr14431576igr.89.1446506737288; Mon, 02 Nov 2015 15:25:37 -0800 (PST) Received: by 10.107.153.6 with HTTP; Mon, 2 Nov 2015 15:25:37 -0800 (PST) In-Reply-To: References: Date: Mon, 2 Nov 2015 15:25:37 -0800 Message-ID: From: Fabio Chiussi To: Benjamin Bangert Content-Type: multipart/alternative; boundary=047d7b10c95d3dcd800523971852 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] draft-chiussi-webpush-subscription-less-framework-01 and request for feedback on Subscription Management 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, 02 Nov 2015 23:25:40 -0000 --047d7b10c95d3dcd800523971852 Content-Type: text/plain; charset=UTF-8 Hi, Sorry for not adding the link, the document is listed in the WG page. http://datatracker.ietf.org/doc/draft-chiussi-webpush-subscription-less-framework/ Thanks, Fabio On Mon, Nov 2, 2015 at 9:11 AM, Benjamin Bangert wrote: > Is there a link to this document I can read? > > Thanks, > Ben > > On Sun, Nov 1, 2015 at 6:27 PM, Fabio Chiussi > wrote: > >> Hi All, >> >> I submitted a new draft: draft-chiussi-webpush-subscription-less-framework-01, >> which I will briefly present at the WG meeting tomorrow. This draft >> discusses two issues: i) a number of relevant use cases for webpush may >> benefit from a "relaxed" model of subscription, and ii) there is an >> emerging need for global management of webpush traffic across applications. >> >> As a possible solution for both issues, this draft advocates the >> introduction of a notion of trusted "Subscription Authority" in charge of >> controlling webpush traffic to each UA. >> >> Beyond the specific solution proposed in this draft, I would like to >> solicit feedback from the mailing list on the more general issue of >> Subscription Management, which we can discuss tomorrow at the meeting. >> Specifically, any comments would be greatly appreciated on the following. >> >> 1. For the reasons outlined in the draft, Subscription Management seems a >> very relevant practical issue that needs to be addressed. >> >> 2. In the current core protocol WG document, Subscription Management is >> only addressed in passing, by assuming some kind of control policy in >> assigning the subscriptions. At this time, neither the issues and use cases >> related to Subscription Management, nor the possible solutions have been >> fully studied in the draft. I think this is simply due to the fact that the >> core protocol design, for obvious reasons, has been the focus of the work >> so far, and there has not been sufficient time yet to fully address other >> relevant issues, such as Subscription Management >> >> 3. However, the state of the work on the core protocol design has reached >> sufficient maturity that the WG should start considering to address some of >> these other topics as well. Subscription Management seems a critical and >> urgent one, since it has very important practical ramifications. The >> solution proposed in this draft is simply one of possible candidates, and >> Subscription Management certainly deserves a more comprehensive study, and >> possibly develop a framework for Subscription Management. Because of its >> practical relevancy, subscription Management should become a WG item. >> >> I'll compile any comments that the mailing list may have on these topics, >> and bring them forward for discussion at the meeting tomorrow. >> >> Thanks, >> Fabio >> >> >> >> _______________________________________________ >> Webpush mailing list >> Webpush@ietf.org >> https://www.ietf.org/mailman/listinfo/webpush >> >> > --047d7b10c95d3dcd800523971852 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,=

Sorry for not adding the= link, the document is listed in the WG page.
http://datatracker.iet= f.org/doc/draft-chiussi-webpush-subscription-less-framework/

Thanks,
Fabio

On Mon, Nov 2= , 2015 at 9:11 AM, Benjamin Bangert <bbangert@mozilla.com> wrote:
Is th= ere a link to this document I can read?

Thanks,
Ben

On Sun, Nov 1, 2015 at 6:27 PM, Fabio Chiussi <fabiochi= ussi@gmail.com> wrote:
Hi All,

I submitted a new draft: draft-chiussi-webpush-subscription-less-framework-01, which I will bri= efly present at the WG meeting tomorrow. This draft discusses two issues: i= ) a number of relevant use cases for webpush may benefit from a "relax= ed" model of subscription, and ii) there is an emerging need for globa= l management of webpush traffic across applications.=C2=A0

As a possible solution for both issues, = this draft advocates the introduction of a notion of trusted "Subscrip= tion Authority" in charge of controlling webpush traffic to each UA.

Beyond the specific soluti= on proposed in this draft, I would like to solicit feedback from the mailin= g list on the more general issue of Subscription Management, which we can d= iscuss tomorrow at the meeting. Specifically, any comments would be greatly= appreciated on the following.

1. For the reasons outlined in the draft, Subscription Management see= ms a very relevant practical issue that needs to be addressed.

2. In the current core protocol WG do= cument, Subscription Management is only addressed in passing, by assuming s= ome kind of control policy in assigning the subscriptions. At this time, ne= ither the issues and use cases related to Subscription Management, nor the = possible solutions have been fully studied in the draft. I think this is si= mply due to the fact that the core protocol design, for obvious reasons, ha= s been the focus of the work so far, and there has not been sufficient time= yet to fully address other relevant issues, such as Subscription Managemen= t

3. However, the state o= f the work on the core protocol design has reached sufficient maturity that= the WG should start considering to address some of these other topics as w= ell. Subscription Management seems a critical and urgent one, since it has = very important practical ramifications. The solution proposed in this draft= is simply one of possible candidates, and Subscription Management certainl= y deserves a more comprehensive study, and possibly develop a framework for= Subscription Management. Because of its practical relevancy, subscription = Management should become a WG item.

I'll compile any comments that the mailing list may have on = these topics, and bring them forward for discussion at the meeting tomorrow= .

Thanks,
Fabio



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



--047d7b10c95d3dcd800523971852-- From nobody Mon Nov 2 17:22: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 7F2501ACDF5 for ; Mon, 2 Nov 2015 17:21:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1sKnX3d1tN2 for ; Mon, 2 Nov 2015 17:21:55 -0800 (PST) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89EAE1ACDB6 for ; Mon, 2 Nov 2015 17:21:55 -0800 (PST) Received: by ykft191 with SMTP id t191so2019752ykf.0 for ; Mon, 02 Nov 2015 17:21:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PKKI56ViIC0MOZtpSHa8GFSA8wyT7p/6XCCCmQGRz6Y=; b=ZkMckXOKk+kYDE7TdAy63ouA1+6z85nEcc+Z+t2VzSPeCIwBZrzOT85bCZm6890uVm sRbYI6rdIg+FOy44HmWmsHjDAWDaK7G3WWMT0+G4JLGHzDmHZmqoESMtsgSUBWhgMPAc ZV8zID4QuNrF3W7stnmp6ftoIRDt/+gmD+kcA7iwrfkYVfKuZerBFS2NwxE6DRm557Oy 5toqx7Orm/Qnpric9KIzXsegdLHfjDRzmLJqbR2OZd0dUUZK+wc2AovNIzKKvYWSEaCz hirYDlck+OPKawiNQPRjkv2u/Pw8/tSq3jw78D44E5xwOI6LVvmjD7f6ufzCaXeWXzek fGxQ== MIME-Version: 1.0 X-Received: by 10.129.131.1 with SMTP id t1mr14284550ywf.207.1446513714892; Mon, 02 Nov 2015 17:21:54 -0800 (PST) Received: by 10.129.132.145 with HTTP; Mon, 2 Nov 2015 17:21:54 -0800 (PST) In-Reply-To: References: Date: Tue, 3 Nov 2015 10:21:54 +0900 Message-ID: From: Martin Thomson To: Peter Beverloo Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] ietf-webpush-encryption - untrusted push services 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, 03 Nov 2015 01:21:59 -0000 On 2 November 2015 at 16:12, Peter Beverloo wrote: > We don't trust the intermediary. What if they are the attacker? I agree, this is the most interesting attack. Requiring https:// as we do removes most opportunities for all other attackers. > (1) There's a possibility of contributory behaviour with other DH > groups. I've done my reading on this now and realize that this is (probably) a bit of a minefield. See http://cr.yp.to/ecdh.html#validate ...and for the opposing view: http://vnhacker.blogspot.jp/2015/09/why-not-validating-curve25519-public.html The curve25519 draft doesn't reflect any of this nuance, which I find interesting. I haven't followed the CFRG discussion, but I did find this thread: http://www.ietf.org/mail-archive/web/cfrg/current/msg06501.html The concern here is that this protocol depends on contributory behaviour. That's a valid concern. At a minimum, we should consider having some considerations on this. A perhaps better approach would be to change the key derivation to remove the dependency on contributory behaviour. I need to think about that a little. This is a subject that needs to be addressed in the http working group soon. > Since P-256 is a prime-ordered group this doesn't apply today, but it would > be a subtle issue if we were to change curves. Yes, 25519. > (2) The client is vulnerable to DoS attacks. If the push service is the attacker, then they have much better DoS options available than what you describe, especially for a battery-powered device. From nobody Tue Nov 3 10:14: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 E51211B345F for ; Tue, 3 Nov 2015 10:14:56 -0800 (PST) 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 dgvKOsXAE71H for ; Tue, 3 Nov 2015 10:14:56 -0800 (PST) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1AC91B345E for ; Tue, 3 Nov 2015 10:14:55 -0800 (PST) Received: by ykek133 with SMTP id k133so30072745yke.2 for ; Tue, 03 Nov 2015 10:14:55 -0800 (PST) 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=NlUZJoj8Sg7Yl7DX82BSqEh+5pJpYPHWXPrOrnYQkt0=; b=OaIycVnsKo348ARw3HCWWLz3EvgB5sjomCGPTT1/ox74p68o1vr5dIW4PEI8GhbVYT qp8XuTl9MSJ1EdNKzyyNJLSz8VjOqgV+H2LdOZaQ47dYKEHtpgJ4a4UO/VdjERBgg/Y1 5Utj0o5Pt0jSJg9UzVVx1+zpw6BM62iD8nyTyelv+7cjwKnJlIckyVBr2OQMFceNhseh 1L97oGI2oglcqDR7o8ay18rBn3j0oW+IZHcLbZ3q/KDmLqkbLwQocbZv7ueV3w9I3S+s ManggCA6CPmHqpKRM9VTleO1qXdRU18X4YTjWC4B1thp54zz4H8JWte5ItLaJ0Ze1aya PoSw== 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=NlUZJoj8Sg7Yl7DX82BSqEh+5pJpYPHWXPrOrnYQkt0=; b=MNhvMEL2QTb4SlCzpuko2KvSAcOQc4poBgSfnqLzdv1isfplivsd54NoxfrGYFs8s8 D4Be3urJkJ2kI3ELVfQ8AahtH3TorGt3wva57LkH+aAhrkkgxlpj64jIEbsGHQW3oqmu /Wmphz0Lq1zEy3ZyaCHzU5eipidyG6EPqE3cRrc5I4VsdFowttZWt1vn8FcknX7uqSzF fy1MuqN690P4bKgr3s3FTGXc/8SsFvJwhrcWSErt0jYnvevjWeOkmYO8seI+Atq4Brgs +JE3QZfCHAKtl33o52XC590BssxOU2RUBW2XWwTqFmyGdbYjN/VbyMFkc/mnBTncibcx M+mQ== X-Gm-Message-State: ALoCoQn7sWQi+/q+WpwPMoB0ZiOeY/4xsCPfOpsyoJyMnDZoLvph43xdb2cEMROI75Jd5v2Qxkrx X-Received: by 10.31.108.216 with SMTP id j85mr19739534vki.134.1446574495101; Tue, 03 Nov 2015 10:14:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.191.70 with HTTP; Tue, 3 Nov 2015 10:14:35 -0800 (PST) In-Reply-To: References: From: Adam Langley Date: Tue, 3 Nov 2015 10:14:35 -0800 Message-ID: To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" , Peter Beverloo Subject: Re: [Webpush] ietf-webpush-encryption - untrusted push services 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, 03 Nov 2015 18:14:57 -0000 On Mon, Nov 2, 2015 at 5:21 PM, Martin Thomson wrote: > The curve25519 draft doesn't reflect any of this nuance, which I find > interesting. It currently specifies that implementations MUST reject small-order points as a defense-in-depth. However, I though that would be relatively uncontroversial and was wrong. Because of that, it'll change. But, still, you can't depend on contributory behaviour. It's just not a property that's guaranteed. Cheers AGL From nobody Tue Nov 3 16:29: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 D6AD71B36E0 for ; Tue, 3 Nov 2015 16:29:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ar2-3h0szmZj for ; Tue, 3 Nov 2015 16:29:45 -0800 (PST) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C079A1B36DB for ; Tue, 3 Nov 2015 16:29:42 -0800 (PST) Received: by ykek133 with SMTP id k133so45999608yke.2 for ; Tue, 03 Nov 2015 16:29:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=jp2q4f4cEWmuavs3PB/RnN1WqGW5QUg7KlMFuoYLw3Y=; b=i8OS9y+QMGHgoSiDSo+e1O7A0D++9/sD4hYNsfvdhI8C2FeMdB1m6e4MQ3m9W24Q7b CSgWZgQ2M23VuPFbkD7peGTR11GIWNBUiw7KiA06v1e8IDcGtS6IJRWrb+fuy48MXgRi QZ9bCxiADpOjX6rsYljsPn5FsqJhFe/T+InOoZ8aUC+OLh9Tjlz1h9WkbGwXc53mI7SF A7lKcsfq0vOc4lbyWJIrTwVwGQaNYS6tTdt2WxshVi//MOfx3sKUNxbJEtx0+xkiXAbg 84b8OuodCijth4waN6einmFxxxvQ96zx5mhr0jIgUc9aUG3enZkkUgU6ldyPm77YsyBg 3/DA== MIME-Version: 1.0 X-Received: by 10.129.79.6 with SMTP id d6mr25762766ywb.120.1446596982103; Tue, 03 Nov 2015 16:29:42 -0800 (PST) Received: by 10.129.132.145 with HTTP; Tue, 3 Nov 2015 16:29:42 -0800 (PST) In-Reply-To: References: Date: Wed, 4 Nov 2015 09:29:42 +0900 Message-ID: From: Martin Thomson To: Adam Langley , "webpush@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Webpush] ietf-webpush-encryption - untrusted push services 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, 04 Nov 2015 00:29:49 -0000 On 4 November 2015 at 03:14, Adam Langley wrote: > But, still, you can't depend on contributory behaviour. It's just not > a property that's guaranteed. Right. I have requested that you put that in the security considerations. I am on the hook to produce a revision to the content encryption draft that addresses the contributory behaviour concern. I expect that to be fairly simple in this case. Expect something in a week or so. From nobody Wed Nov 11 12:26: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 55CAA1A1B64 for ; Wed, 11 Nov 2015 12:26:52 -0800 (PST) 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 AuSIHrjnwJud for ; Wed, 11 Nov 2015 12:26:50 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id C0ED21A1B61 for ; Wed, 11 Nov 2015 12:26:50 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id tABKQoQm000735 for ; Wed, 11 Nov 2015 13:26:50 -0700 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Wed, 11 Nov 2015 13:26:49 -0700 (MST) 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, 11 Nov 2015 13:26:47 -0700 From: Darshak Thakore To: "webpush@ietf.org" Thread-Topic: status code for messages dropped before TTL expiration Thread-Index: AQHRHI4Tneheu7lS5k62ROaDbLSZfA== Date: Wed, 11 Nov 2015 20:26:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-originating-ip: [10.5.0.27] Content-Type: multipart/alternative; boundary="_000_D2689DC35815dthakorecablelabscom_" MIME-Version: 1.0 Archived-At: Subject: [Webpush] status code for messages dropped before TTL expiration 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, 11 Nov 2015 20:26:52 -0000 --_000_D2689DC35815dthakorecablelabscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi all, During the meeting (on Nov 3rd), we had an outstanding question about speci= fying an appropriate HTTP status code (either a 4XX or 5XX) for situations = where a push server ceases to attempt delivery prior to the advertised TTL. Here are couple of ideas to consider (and get the discussion going :) 1. Currently there is a 417 Expectation Failed status code already defin= ed that works in conjunction with the =93Expect=94 header. Maybe we can def= ine an =93expectation=94 for the TTL and send it in the Expect header. Then= if the push server drops the message prematurely, it can send back a 417. = (However there seems to be some history behind the Expect header which may = be an issue) 2. Another option is to use the =93Prefer=94 header (where the TTL would= be a preference) and then define a new 5xx "Preference Not Honored=94 kind= of status code that can be used in a generic way. (However Martin did poin= t out that preferences are a soft fail so having a preference not being app= lied may not be an appropriate reason for a server to send back an error co= de) 3. Alternately we can define a new header (and carry the TTL as one of t= he tokens in the header) and a corresponding status code (preferably a 5XX = code) that is in the same vein as the Expect header with the 417 code. Regards, Darshak --_000_D2689DC35815dthakorecablelabscom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi all,

During the meeting (on Nov 3rd), we had an outstanding question about = specifying an appropriate HTTP status code (either a 4XX or 5XX) for situat= ions where a push server ceases to attempt delivery prior to the advertised TTL.

Here are couple of ideas to consider (and get the discussion going :)<= /div>

  1. Currently there is a 417 Expectation Failed status code already defined= that works in conjunction with the =93Expect=94 header. Maybe we can defin= e an =93expectation=94 for the TTL and send it in the Expect header. Then i= f the push server drops the message prematurely, it can send back a 417. (However there seems to be some history behind the= Expect header which may be an issue)
  2. Another option is to use the = =93Prefer=94 header (where the TTL would be a preference) and then define a= new 5xx "Preference Not Honored=94 kind of status code that can be us= ed in a generic way. (However Martin did point out that preferences are a s= oft fail so having a preference not being applied may not be an appropriate reason for= a server to send back an error code)
  3. Alternately we can define a n= ew header (and carry the TTL as one of the tokens in the header) and a corr= esponding status code (preferably a 5XX code) that is in the same vein as t= he Expect header with the 417 code.

Regards,
Darshak


--_000_D2689DC35815dthakorecablelabscom_-- From nobody Wed Nov 11 13:23:04 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 602561B3A5B for ; Wed, 11 Nov 2015 13:23:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ximKFoTsw-OQ for ; Wed, 11 Nov 2015 13:23:00 -0800 (PST) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 B7E5D1B3A5A for ; Wed, 11 Nov 2015 13:23:00 -0800 (PST) Received: by ioir85 with SMTP id r85so5595126ioi.1 for ; Wed, 11 Nov 2015 13:23:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JKfodbaL/f5ynFo0zQKzdxCaawSSFOFtkbIm+lM+C0U=; b=W0oTV9ZPHLWvtMTteZl5pjegeSTX+GgRkYmx3koFpv8WQndZ7HGlsQGKVATTYKB5Ij +bntFt2mpo+nmGiYLyTwR0nBVfqj43CUHEhzpO5TGIMN0ElpReXGbp41UY+LtQXJXZ4w j1wFpE/yCKJOkJ2Lo57suRTuEzOnmW6epKLxttZymBK56O5Ep7R4iKX4NZh5Bu6EkrB9 nLeLiIGF3Jksz2pVxL4+6d8BpA+VsxYiXQwUr1qw42w9JyQoHc+XWyAIKk9I1A9UAx4Q J6R+KGuweWU3/YCSLw+BC7ZN3phfHQIWZphniNJTkrZ5zgib5r848j37jxw6NLA7SzTA bn/Q== MIME-Version: 1.0 X-Received: by 10.107.33.203 with SMTP id h194mr6157507ioh.108.1447276980213; Wed, 11 Nov 2015 13:23:00 -0800 (PST) Received: by 10.36.155.139 with HTTP; Wed, 11 Nov 2015 13:23:00 -0800 (PST) In-Reply-To: References: Date: Wed, 11 Nov 2015 13:23:00 -0800 Message-ID: From: Martin Thomson To: Darshak Thakore Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] status code for messages dropped before TTL expiration 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, 11 Nov 2015 21:23:02 -0000 Generally, I think that we wanted to ask http(bis) for opinions. But your suggestion here prompted a thought... On 11 November 2015 at 12:26, Darshak Thakore wrote: > Alternately we can define a new header (and carry the TTL as one of the > tokens in the header) and a corresponding status code (preferably a 5XX > code) that is in the same vein as the Expect header with the 417 code. Maybe we can just use TTL. If it is present (and therefore non-zero) then it's an indication that the TTL hasn't run out, even though the message resource is Not Found/Gone. From nobody Thu Nov 12 12:59: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 974B31A8863 for ; Thu, 12 Nov 2015 12:59:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2k41OZ8CjNb1 for ; Thu, 12 Nov 2015 12:59:37 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 446F61A6FDB for ; Thu, 12 Nov 2015 12:59:37 -0800 (PST) Received: by igvi2 with SMTP id i2so23359156igv.0 for ; Thu, 12 Nov 2015 12:59:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=RWrAcJfEyZm2XMSrpNvBdWU9AsN0RbctUJegEOtbYgU=; b=QMXkh6+ldW9VUwTNWGKCjY6/MYTU89iPX9ejS4MnWKhI5Qh0N9pgPNwzGCiG1t42LB +NYsDCWHeJkJhZKRStjT3N2BtKxFDde+TbnDhuhXvPWqJyKO1sgUA8om5XYt47bggMyo tLnnLScLw0kH7x+J+d9oeT4JBG5Htz0JoaGU6iy7EBwdiaLhyX0db6/qh8itCk196yan OWDn0YlgwRsb52ApsvVBHV/1YDkLqzg4JdQYKNuK1ErVssbpX+axw1B3MiQIM2AiV+ON DCZVmmEdagb9xeWqzWq2t3jxbvJ/zhpFCnH/F7wj9DDafI1pDgEMYfTKmS+VKLHF/OAF 7tVw== MIME-Version: 1.0 X-Received: by 10.50.30.6 with SMTP id o6mr41330987igh.94.1447361976685; Thu, 12 Nov 2015 12:59:36 -0800 (PST) Received: by 10.36.155.139 with HTTP; Thu, 12 Nov 2015 12:59:36 -0800 (PST) Date: Thu, 12 Nov 2015 12:59:36 -0800 Message-ID: From: Martin Thomson To: "webpush@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Webpush] Message update PR 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, 12 Nov 2015 20:59:38 -0000 https://github.com/webpush-wg/webpush-protocol/pull/62 The above pull request and commit is the substance of what we discussed in Yokohama regarding push message updates. This proposes a new header field, Topic, which can be added to a push message. This doesn't really replace messages in the same way that the last one does. Instead, it causes the old message to be acknowledged/deleted at the same time that the new message is created. This avoids all the nasty race conditions we discussed at the meeting. If the old message is being delivered, then this causes it to be acknowledged early; since acknowledgment is idempotent, there are no race conditions. --Martin From nobody Fri Nov 13 14:31: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 07D321B336D for ; Fri, 13 Nov 2015 14:31:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LbrDNtq_E-X for ; Fri, 13 Nov 2015 14:31:00 -0800 (PST) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B74091B336E for ; Fri, 13 Nov 2015 14:31:00 -0800 (PST) Received: by iofh3 with SMTP id h3so111915692iof.3 for ; Fri, 13 Nov 2015 14:31:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=GVmY1qkcZI2R9zbVDFOYpwCfxeJxN4P4uFzEgerdj/o=; b=nfIdzsMQJmaFb1liw4Ix8Fb4JVSiVmQ/hET3Ni89jGcSdeYYGQ3cqH4e7Y2Cjv1RF0 9w3xCBnKuEuDoaF9W1cw2xKegVr6Lv4i6M6d+6nYBCoHdnbSIH2zFq+tYzmYZnFCJWSL MM35qgR+ezhoOfpZphlTdUxSlGeNfvgpzaWW+jyrlrh+2/c6eXMWXexz4wM7SNle5K2A s+yxIIH75+ReHM9ASdAs7K5p+kh5LBeOnsqKkd9S9inKxG61UIIU8QDNycOTXLo3cthg 8c7IJmel8B5hr9jWzSgIuxqjRhCzsKDUyIGDYtf8cywhrGdjpz169OF5eKmf6u/GG601 wt5Q== MIME-Version: 1.0 X-Received: by 10.107.169.29 with SMTP id s29mr24016212ioe.190.1447453860136; Fri, 13 Nov 2015 14:31:00 -0800 (PST) Received: by 10.36.155.139 with HTTP; Fri, 13 Nov 2015 14:31:00 -0800 (PST) Date: Fri, 13 Nov 2015 14:31:00 -0800 Message-ID: From: Martin Thomson To: "webpush@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Webpush] Contributory behaviour fix for -encryption 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, 13 Nov 2015 22:31:02 -0000 I've put together a pull request that addresses at least part of the issue that AGL raised. The meat of the change in the core spec, this is where you need to look: https://github.com/martinthomson/http-encryption/pull/4 The update to the webpush encryption spec is modest: https://github.com/webpush-wg/webpush-encryption/issues/3 And I've implemented the change in my library: https://github.com/martinthomson/encrypted-content-encoding/issues/4 Note that this doesn't deal with the authentication issue that Adam separately identified. That would require changes to the API. I'll follow up with some potential options for that. From nobody Mon Nov 16 16:13:12 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 EDF021A8F4E for ; Mon, 16 Nov 2015 16:13:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6QJcmvKQEBj for ; Mon, 16 Nov 2015 16:13:08 -0800 (PST) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 972131A8BC5 for ; Mon, 16 Nov 2015 16:13:08 -0800 (PST) Received: by iouu10 with SMTP id u10so2637675iou.0 for ; Mon, 16 Nov 2015 16:13:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=OSyXxASoFPZyXrSg9Q4GpduBM5NLGPdTLrvg6+pG7zE=; b=GfrE9mb4Rnd7+ySW7hnAxHw25JEWAqT+X5mJIiPInXBCkNuRvgi79M7n4eFYJSnVGH k43F94mf+e7FkTRlBXTS54UeQSRxLgTKwC+jYa5w5sZEon7OnuNpaUvYDEQEXYHq1Xmd OPuueGwqEWcbsiI03pf6N7nUK9AYl5aW1yCNYaX8szW1iPkjiU2gxZNJa19+zuJjQjO9 6PUyDO2sgs6zcc8Xluo2GoVw8C5OF/jrNmkAthmxkE4crjSZjwgnmBWkIyGElK2OogYy OCJPOM6oXDuLA1mrNI4i97GLFvZX90IXI//3u8u1pkRJvHQugEY5ycw26velZqlmJJPT fwCw== MIME-Version: 1.0 X-Received: by 10.107.33.203 with SMTP id h194mr28371032ioh.108.1447719187973; Mon, 16 Nov 2015 16:13:07 -0800 (PST) Received: by 10.36.155.139 with HTTP; Mon, 16 Nov 2015 16:13:07 -0800 (PST) In-Reply-To: References: Date: Mon, 16 Nov 2015 16:13:07 -0800 Message-ID: From: Martin Thomson To: "webpush@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Webpush] Contributory behaviour fix for -encryption 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, 17 Nov 2015 00:13:10 -0000 On 13 November 2015 at 14:31, Martin Thomson wrote: > Note that this doesn't deal with the authentication issue that Adam > separately identified. That would require changes to the API. I'll > follow up with some potential options for that. I have a strawman fix for the authentication issue up: https://github.com/webpush-wg/webpush-encryption/issues/3 The API necessarily changes too, in case you are interested: https://github.com/w3c/push-api/pull/174 From nobody Tue Nov 17 13:37:48 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 7E41A1AC3A5 for ; Tue, 17 Nov 2015 13:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QdSPRXsMK5T9 for ; Tue, 17 Nov 2015 13:37:45 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0105.outbound.protection.outlook.com [207.46.100.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 220161B30F1 for ; Tue, 17 Nov 2015 13:37:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=uDdCuaOGvYclnrXrYdJ1o+tZQKfC5JrGC0JCvQqJJnQ=; b=fSyZNBITYfCT8o/Tf3GQo6IVZi+vM7iZvSsPbATPYBcP5L4kFJD8gZa1zNyylzpnSWXgPW04H5ITTsh4Uuc2DAtz0E84jjSDzxTf1in1WW58UztvkTKwegrUpNw6tbjj57+H6TSmHZhm4RX35L8P93icFdb/HwneXNj3Dagj8g0= Received: from BY2PR0301MB0647.namprd03.prod.outlook.com (10.160.63.14) by BY2PR0301MB0646.namprd03.prod.outlook.com (10.160.63.139) with Microsoft SMTP Server (TLS) id 15.1.325.17; Tue, 17 Nov 2015 21:37:44 +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.0325.019; Tue, 17 Nov 2015 21:37:44 +0000 From: Brian Raymor To: "Martin Thomson (martin.thomson@gmail.com)" , Darshak Thakore Thread-Topic: [Webpush] status code for messages dropped before TTL expiration Thread-Index: AQHRHI4Tneheu7lS5k62ROaDbLSZfJ6XVSwAgAAIpkA= Date: Tue, 17 Nov 2015 21:37:43 +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: spf=none (sender IP is ) smtp.mailfrom=Brian.Raymor@microsoft.com; x-originating-ip: [131.107.147.163] x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0646; 5:IVDdymBMSNYEXXRsFGl4TSv3RMg2pqGzIU2ZyXRedB+qenagMEI1hHckQyAo1xvAqCsk7zYKP9quGrXce5lf19xoYA6o1Qd8tMVrfIwcK9f7oCiRYY84CLZ4tD5/wUsBkZgYHqp0d3cSfm7mJ+8V2Q==; 24:5NebSB3ssUAVNQhFs39LV0G/RwQCKMahayPQtj39HQk+7jg5lNGnqAYPS6Kt2y3QWBGcONPlkm95sEZEDyqYUdXiZ4/5byYP1y5O7o1LxIc=; 20:5XXgsL2URhDpULZAtXBlrMiGrIDG1Z5O6vcwpWPCjNeEm+YmMrS1r1eGjP2R/Sf6DXyhl6H3eAqRwcziqsTn3A== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0301MB0646; x-o365eop-header: O365_EOP: Allow for Unauthenticated Relay x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(8121501046)(5005006)(520078)(10201501046)(3002001)(61426024)(61427024); SRVR:BY2PR0301MB0646; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0646; x-forefront-prvs: 07630F72AD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(189002)(199003)(51444003)(24454002)(77096005)(86362001)(5002640100001)(8990500004)(106356001)(10400500002)(10290500002)(86612001)(5005710100001)(106116001)(105586002)(5003600100002)(99286002)(87936001)(5008740100001)(5007970100001)(11100500001)(586003)(54356999)(2950100001)(66066001)(5001920100001)(2900100001)(189998001)(5001960100002)(102836002)(5001770100001)(76176999)(97736004)(81156007)(50986999)(33656002)(101416001)(40100003)(10090500001)(5004730100002)(74316001)(76576001)(92566002)(19580395003)(19580405001)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0646; H:BY2PR0301MB0647.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2015 21:37:43.9024 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0646 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] status code for messages dropped before TTL expiration 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, 17 Nov 2015 21:37:46 -0000 On November 11 2015 at 1:23 PM, Martin Thomson w= rote: > Generally, I think that we wanted to ask http(bis) for opinions. =20 Yes. I have drafted a message and will forward to httpbis today. > Maybe we can just use TTL. If it is present (and therefore non-zero) > then it's an indication that the TTL hasn't run out, even though the > message resource is Not Found/Gone. This is a reasonable mitigation. It's a cleaner variation to the 4XX + Ackn= owledgement-Data header field proposed in the IETF 94 presentation, since the TTL is more clearly related= to the failure. In addition, if we decide to adopt Acknowledgement-Data later, this ensures= that: 1. The data remains opaque. There are no reserved documented values to sign= al failure. 2. The data remains application specific. The push service is not a source = of Acknowledgement-Data - only the user agent. From nobody Wed Nov 18 02:19: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 508C81B2BBF for ; Wed, 18 Nov 2015 02:19:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.636 X-Spam-Level: X-Spam-Status: No, score=-0.636 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585] 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 jMLPca9dAk8C for ; Wed, 18 Nov 2015 02:19:39 -0800 (PST) Received: from inari-msr.crf.canon.fr (inari-msr.crf.canon.fr [194.2.158.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E42DB1ACEC0 for ; Wed, 18 Nov 2015 02:19:38 -0800 (PST) Received: from mir-bsr.corp.crf.canon.fr (mir-bsr.corp.crf.canon.fr [172.19.77.99]) by inari-msr.crf.canon.fr (8.13.8/8.13.8) with ESMTP id tAIAJa47027759 for ; Wed, 18 Nov 2015 11:19:36 +0100 Received: from Antiope.crf.canon.fr (antiope.fesl2.crf.canon.fr [172.19.70.56]) by mir-bsr.corp.crf.canon.fr (8.13.8/8.13.8) with ESMTP id tAIAJatd032759 for ; Wed, 18 Nov 2015 11:19:36 +0100 Received: from timor.intra-usr.crf.canon.fr (172.20.5.234) by Antiope.crf.canon.fr (172.19.70.56) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 18 Nov 2015 11:19:36 +0100 To: From: =?UTF-8?Q?Herv=c3=a9_Ruellan?= Message-ID: <564C50B7.7070505@crf.canon.fr> Date: Wed, 18 Nov 2015 11:19:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [172.20.5.234] X-ClientProxiedBy: Antiope.crf.canon.fr (172.19.70.56) To Antiope.crf.canon.fr (172.19.70.56) Archived-At: Subject: [Webpush] Use Case related to subscription sets 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, 18 Nov 2015 10:19:40 -0000 Hi all, We, at Canon, have a use case that is dependent on the rules relating subscriptions and subscription sets. In this use case, a device (e.g. a camera) connects to a push-server through a proxy (e.g. a mobile phone). The communication between the camera and the proxy uses an appropriate protocol (most possibly not HTTP). A notification goes from the push-server to the proxy (acting as a user-agent) through WebPush, then from the proxy to the device through the appropriate protocol. We plan to use the same proxy for several devices. We would like to allow a device to change from a proxy to another seamlessly (e.g. going from the mobile phone to a PC when coming home). When a device moves from a proxy to another, we would like it to keep the same subscription. This means that each device would need to have its own subscription set to contain its subscription (or subscriptions). Supporting this use case means that a client, here the proxy, is allowed to have several subscription sets. However, this number would be quite limited as we think only a few devices would connect through the same proxy. This scenario is of importance for us, and we would like the WG to take it into account in the definition of subscription sets. Cheers, Hervé Ruellan From nobody Wed Nov 18 10:21: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 E98FE1A1B92 for ; Wed, 18 Nov 2015 10:21:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 HFi3NFVla-CV for ; Wed, 18 Nov 2015 10:20:59 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::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 7C3FD1A1B8F for ; Wed, 18 Nov 2015 10:20:59 -0800 (PST) Received: by wmec201 with SMTP id c201so85498647wme.1 for ; Wed, 18 Nov 2015 10:20:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PWTFc/KfCjB7V3ZTSejtD9hr8ggzOISVy1r7rOgwk9k=; b=WAXg5lADTioVonVxyx9vn5aUj4hcq8SH4DqvqlK+83A8UuSaPzD+uKssouVIOncf2H j8ZtapxSuKwws2VhXeWoYCtTtxfcBvqc5J917tZGXJAqBGgpExiztu0Zwe/nzMb7uVyl BxfZcmMhsijvHzK5HYRb36GiJmJ90PzCvhaBMdsjvKsxqhzJsaFRlMtCmcghQ7ehyzZe WBYQGnxWX46XIjuwIO8V0ZMNbCPKdorhoypm0j+Bj4dHtblG9z6RSaU6ZOsysXd5qfqp uVkdeMb1+BIzWP10705KP/8TTJlupjvN+Oqyqm1HZl/ui0j3yvk6Vuvjl8H5lUHqZsqL RFYA== 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=PWTFc/KfCjB7V3ZTSejtD9hr8ggzOISVy1r7rOgwk9k=; b=CDkWCqfZIyiqJHx0VQ3umKuvBYMiDsd+51w+o+YQD8rfk1RbWpDWsmeQDJnhpc9ms5 6SEgKOxAlThg1757BWb8vkb6JM+AQQ80iADkbWLT2PduAflDAmFO6pIbtRF1xGUJDznF pVv+CuAN5XinWaX6mD8bIa22MDOUORJUnRJS8jYTzmh7Bd26TAcOJuDPO7Kk+phVHCDL BZ0krc9e42FGekAC778ZoC9+jO6adVcWxih7b59Z57yY88gbgBBuaptmy5O13d8QpBf6 P4JKwlj/WQBgCMDchWzjaiHVpVhURwpLsW09M3cpJ3JBHXNrqTWo2PPWdj8NZpIu0r2/ Rw9w== X-Gm-Message-State: ALoCoQn7hvUb5pcoqpC5siaXmHiRuF7gkh569xq+dM8v2SH2iWAZImcU++qmdaoEnUwlps9k3HoX MIME-Version: 1.0 X-Received: by 10.194.8.227 with SMTP id u3mr3598943wja.38.1447870857849; Wed, 18 Nov 2015 10:20:57 -0800 (PST) Received: by 10.27.155.196 with HTTP; Wed, 18 Nov 2015 10:20:57 -0800 (PST) In-Reply-To: <564C50B7.7070505@crf.canon.fr> References: <564C50B7.7070505@crf.canon.fr> Date: Wed, 18 Nov 2015 10:20:57 -0800 Message-ID: From: Benjamin Bangert To: =?UTF-8?Q?Herv=C3=A9_Ruellan?= Content-Type: multipart/alternative; boundary=047d7b5d9c0729ce510524d4b479 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Use Case related to subscription sets 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, 18 Nov 2015 18:21:02 -0000 --047d7b5d9c0729ce510524d4b479 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm not sure any changes would be needed as is. If a Push Server is limiting the concurrent streams, the proxy could just open several connections, one for each device its proxying for that devices subscription set. When the device disconnects from the proxy, it would shut down that Push Service connection, and the device could query the Push Service directly. We currently field many connections from single IP's (proxies), and don't plan on enforcing connection limits for a single IP since mobile proxies are quite common. Cheers, Ben On Wed, Nov 18, 2015 at 2:19 AM, Herv=C3=A9 Ruellan wrote: > Hi all, > > We, at Canon, have a use case that is dependent on the rules relating > subscriptions and subscription sets. > > In this use case, a device (e.g. a camera) connects to a push-server > through a proxy (e.g. a mobile phone). The communication between the came= ra > and the proxy uses an appropriate protocol (most possibly not HTTP). A > notification goes from the push-server to the proxy (acting as a > user-agent) through WebPush, then from the proxy to the device through th= e > appropriate protocol. > > We plan to use the same proxy for several devices. We would like to allow > a device to change from a proxy to another seamlessly (e.g. going from th= e > mobile phone to a PC when coming home). When a device moves from a proxy = to > another, we would like it to keep the same subscription. This means that > each device would need to have its own subscription set to contain its > subscription (or subscriptions). > > Supporting this use case means that a client, here the proxy, is allowed > to have several subscription sets. However, this number would be quite > limited as we think only a few devices would connect through the same pro= xy. > > This scenario is of importance for us, and we would like the WG to take i= t > into account in the definition of subscription sets. > > Cheers, > > Herv=C3=A9 Ruellan > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > --047d7b5d9c0729ce510524d4b479 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm not sure any changes would be = needed as is. If a Push Server is limiting the concurrent streams, the prox= y could just open several connections, one for each device its proxying for= that devices subscription set.

When the device disconnects fr= om the proxy, it would shut down that Push Service connection, and the devi= ce could query the Push Service directly.

We currently field m= any connections from single IP's (proxies), and don't plan on enfor= cing connection limits for a single IP since mobile proxies are quite commo= n.

Cheers,
Ben
On Wed, Nov 18, 2015 at 2:19 AM, Herv=C3=A9 Ru= ellan <herve.ruellan@crf.canon.fr> wrote:
Hi all,

We, at Canon, have a use case that is dependent on the rules relating subsc= riptions and subscription sets.

In this use case, a device (e.g. a camera) connects to a push-server throug= h a proxy (e.g. a mobile phone). The communication between the camera and t= he proxy uses an appropriate protocol (most possibly not HTTP). A notificat= ion goes from the push-server to the proxy (acting as a user-agent) through= WebPush, then from the proxy to the device through the appropriate protoco= l.

We plan to use the same proxy for several devices. We would like to allow a= device to change from a proxy to another seamlessly (e.g. going from the m= obile phone to a PC when coming home). When a device moves from a proxy to = another, we would like it to keep the same subscription. This means that ea= ch device would need to have its own subscription set to contain its subscr= iption (or subscriptions).

Supporting this use case means that a client, here the proxy, is allowed to= have several subscription sets. However, this number would be quite limite= d as we think only a few devices would connect through the same proxy.

This scenario is of importance for us, and we would like the WG to take it = into account in the definition of subscription sets.

Cheers,

Herv=C3=A9 Ruellan

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

--047d7b5d9c0729ce510524d4b479-- From nobody Wed Nov 18 11:31:16 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 D10B71A9053 for ; Wed, 18 Nov 2015 11:31:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 cfqqPzwTasxg for ; Wed, 18 Nov 2015 11:31:13 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 782BA1A9037 for ; Wed, 18 Nov 2015 11:31:13 -0800 (PST) Received: by iofh3 with SMTP id h3so65077930iof.3 for ; Wed, 18 Nov 2015 11:31:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ef8QSYbuTPcMaWT/jrzwL4UHH2Soz1QVu8zoAvwd024=; b=WT+KOgqdzNuEcCm8EMSmVGsdVkKyGA0SYgHw6NcpvegdMrbeklXNOVle0GpK9URoF3 6cdZNrdp0UMWRN2C2/aJHgLKQlHIR9btc/IX5c5CF4MH1zKtIJg5IQv+g5rnEOoq6jSt laDprjMXLGEUxE0/QCGqo71nswV+5sxEEYrws+YF7orrwdgNPkbN2aJ/ER2ZBreaL3hQ 4U6fqvqAP4GOmy1CIQV6zfhe0NDLb8kUuArkU2K/djXoSu7vN3rfTU22n0NaR3Cn+D6/ 20GsUzFIPF3CovEXl1vas4+Q29Fuy5kXkBgTYWRj2VbhneRT87YeF+5a11XbRI9Wf6ac +jIw== MIME-Version: 1.0 X-Received: by 10.107.33.203 with SMTP id h194mr4324980ioh.108.1447875072651; Wed, 18 Nov 2015 11:31:12 -0800 (PST) Received: by 10.36.155.139 with HTTP; Wed, 18 Nov 2015 11:31:12 -0800 (PST) In-Reply-To: References: <564C50B7.7070505@crf.canon.fr> Date: Wed, 18 Nov 2015 11:31:12 -0800 Message-ID: From: Martin Thomson To: Benjamin Bangert Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" , =?UTF-8?Q?Herv=C3=A9_Ruellan?= Subject: Re: [Webpush] Use Case related to subscription sets 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, 18 Nov 2015 19:31:15 -0000 On 18 November 2015 at 10:20, Benjamin Bangert wrote: > I'm not sure any changes would be needed as is. If a Push Server is limiting > the concurrent streams, the proxy could just open several connections, one > for each device its proxying for that devices subscription set. The HTTP/2 RFC is pretty clear about having multiple connections. A very simple solution here is to have the client use some sort of explicit correlator, as we have discussed. Then there is no need for multiple connections. Of course, if the push service were disinclined to permit multiple subscription sets then this wouldn't work, but that's probably OK here. n.b., the concurrent stream limit isn't a good signal to use for negotiation, it's only a way of ensuring compliance in the presence of bad actors. From nobody Wed Nov 18 21:19: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 75BDF1A87E7 for ; Wed, 18 Nov 2015 21:19:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMvDxOM3wocW for ; Wed, 18 Nov 2015 21:19:18 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0140.outbound.protection.outlook.com [207.46.100.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9C121A87E4 for ; Wed, 18 Nov 2015 21:19:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xvLkjLH5uSvFQ/MQQw5fzkd6g/yMzrFAkGFI77ZYHr4=; b=Yu44J/yp8SMrslFBley7DLjkXa+1Z2tlP8mgqKRiLzVb6smBdJHvvd1W2Ht2U9Tloaq5zfuFE/NQdW7Tiiy59aGuiJHYDc7TqrEGoFEUkjg8zM/BJWazgqPvZJdciJTkpVXFTvxJu1zh+MLQyh76XFDps6u2gmVrRpgrqOlenuY= 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.325.17; Thu, 19 Nov 2015 05:19:15 +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.0325.019; Thu, 19 Nov 2015 05:19:15 +0000 From: Brian Raymor To: "ietf-http-wg@w3.org" Thread-Topic: Proposed 5xx status code for WebPush Thread-Index: AdEiKZSOTaxBoz5DQE60FwrGEiCRlw== Date: Thu, 19 Nov 2015 05:19:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brian.Raymor@microsoft.com; x-originating-ip: [2601:600:8000:5a8:e5b7:a59d:eae2:8193] x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0647; 5:Hs2NLVSIoG7ijVDE+Hdfz9OGdJSv8baedTRZAEBFkCx26/ZZYBtLpouki120VvNAqscHEuIkQZMmOqBgZKdJEls0t2pzyIrbaT0S7VjBRplDfZohfm+gsP5kFGbsJMR7cwms+f11cJ18cka8nlxFZg==; 24:/KZVM0uZiTHlWg+ijEonmpyL7pOmtSZcicfysa52OL7arPWGusJzO6q9lFxJpRHO63U73h+7hODODrcHlUS90ri3b4Ib1Y8jvOA5aENNfWs=; 20:2EHylANYfGPHNPLc3tj4g+HF9itZKsLC4odOfvRh6EDDTjcSioNwUCH0SnJ7atBqkyVF1gUo8hzHi92RK5k5gQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0301MB0647; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001)(61426024)(61427024); SRVR:BY2PR0301MB0647; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0647; x-forefront-prvs: 07658B8EA3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(45074003)(86612001)(2900100001)(74316001)(189998001)(87936001)(15975445007)(86362001)(5003600100002)(5001920100001)(8990500004)(5005710100001)(110136002)(102836003)(5008740100001)(11100500001)(40100003)(97736004)(5002640100001)(5004730100002)(122556002)(81156007)(5001960100002)(6116002)(54356999)(2501003)(5007970100001)(99286002)(33656002)(19580395003)(2351001)(77096005)(101416001)(10090500001)(10290500002)(229853001)(50986999)(92566002)(76576001)(10400500002)(586003)(105586002)(106356001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0647; H:BY2PR0301MB0647.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Nov 2015 05:19:15.7600 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0647 Archived-At: Cc: "webpush@ietf.org" Subject: [Webpush] Proposed 5xx status code for WebPush 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, 19 Nov 2015 05:19:22 -0000 In WebPush (https://datatracker.ietf.org/doc/draft-ietf-webpush-protocol/),= an application server can request that the push service acknowledge that it has delivered a message t= o a user agent. The push service indicates success (positive acknowledgement) by returning a 410 (Gone) to t= he application server. The push service also needs to indicate failure (negative acknowledgement) = due to the following cases: 1. The user agent failed to acknowledge receipt of the message and the push= service has ceased to attempt re-delivery of the message prior to its advertised expiration (TTL header field).=20 2. The push service expired the message prior to its advertised expiration = due to operational constraints. The following approaches have been explored: 1. Reusing 404 (for positive acknowledgement) and 410 (for negative acknowl= edgement).=20 2. Use 417 (Expectation Failed) http://www.ietf.org/mail-archive/web/webpush/current/msg00351.html Currently there is a 417 Expectation Failed status code already defined= that works in conjunction with the "Expect" header. Maybe we can define an "expectation" for the TTL and send it in the Exp= ect header. Then if the push server drops the message prematurely, it can send back a 417. (However there seems to be some hi= story behind the Expect header which may be an issue) 3. Combine 410 (Gone) with a non-zero TTL header field to indicate failure http://www.ietf.org/mail-archive/web/webpush/current/msg00352.html Maybe we can just use TTL. If it is present (and therefore non-zero) t= hen it's an indication that the TTL hasn't run out, even though the message resource is Not Found/Gone. 4. Define a new 512 (Expired Resource) status code Issue - https://github.com/webpush-wg/webpush-protocol/issues/49 Pull request - https://github.com/webpush-wg/webpush-protocol/pull/50 Mark Nottingham commented earlier: Status codes must be potentially applicable to *all* resources, not u= se case specific (as this seems to be). See: http://httpwg.github.io/specs/rfc7231.html#considerations.for.new.s= tatus.codes When it is necessary to express semantics for a response that are not defined by current status codes, a new status code can be registered. Status codes are generic; they are potentially applicable to any resource, not just one particular media type, kind of resource, or application of HTTP. As such, it is preferred that new status codes be registered in a document that isn't specific to a single application. While we completely agree with Mark's assessment that this use case is sp= ecific to WebPush at this time, the sense was that this should be in the class of 5xx Server Error codes.= Unfortunately, after review there were no existing codes related to this use case. We discussed the propose= d status code and potential mitigations at IETF 94 and agreed to broaden the discussion to the HTTPbi= s mailing list. Thoughts? Does anyone else have a similar use case? ...Brian =20 From nobody Thu Nov 19 10:02: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 9163B1B33B0 for ; Thu, 19 Nov 2015 10:02:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edwRLcfEiMpt for ; Thu, 19 Nov 2015 10:02:49 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (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 4CC081B33A5 for ; Thu, 19 Nov 2015 10:02:49 -0800 (PST) Received: by igcph11 with SMTP id ph11so130098902igc.1 for ; Thu, 19 Nov 2015 10:02:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HHW5KH5rWdn89eedg3X+gnBvY1BIN44+LlpYNXSb6Wg=; b=kA8+TWO41e4o60lS1zK7wYL3Rwydj7akW/pSgSsPMiuABGYttWhJMeufq+4NgkSB/V OvJsN5YQiJ+5/AJqTt4nNulK4DPqvJkpimiVMQhQ2VVr2huuWAVzB6MygAnNTPBEhE9F yZY39jzCWLDoF9zqlgyblisIijOGwZHM2sJW0+mKSiLNrGKZ8+m2XWSMrrHTEK6U/G3W 0ISBlRQwnvb2/+DL26dviduapB7q4qjwd1cbVoVnTD44xmPMELm6lNGk4LuRkdaTYJze eanYcLdPQgIS0by6qzm+ILOVHFYlIIx7A65YD9i7b0/WmvdkoCVenVrVU2krTgjfQKJW 7atA== MIME-Version: 1.0 X-Received: by 10.50.221.36 with SMTP id qb4mr15432232igc.77.1447956168347; Thu, 19 Nov 2015 10:02:48 -0800 (PST) Received: by 10.36.155.139 with HTTP; Thu, 19 Nov 2015 10:02:48 -0800 (PST) In-Reply-To: References: Date: Thu, 19 Nov 2015 10:02:48 -0800 Message-ID: From: Martin Thomson To: Cyrus Daboo Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Brian Raymor , HTTP Working Group , "webpush@ietf.org" Subject: Re: [Webpush] Proposed 5xx status code for WebPush 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, 19 Nov 2015 18:02:52 -0000 On 19 November 2015 at 09:00, Cyrus Daboo wrote: > It seems a little odd for "success" to be indicated by a 4xx code. Why not > just return a 204 (No Content) for that case? I like this. 204 indicates that the content was removed (successfully). A 404/410 indicates that the resource was discarded. Obviously, the 204 state might be immediately followed by the removal of the resource, but we don't need to separately report that. From nobody Thu Nov 19 20:58:25 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 A89E01A6F01 for ; Thu, 19 Nov 2015 20:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 Bw50WfgHq9S9 for ; Thu, 19 Nov 2015 20:58:22 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1831B1A6EE6 for ; Thu, 19 Nov 2015 20:58:21 -0800 (PST) Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8174522E260; Thu, 19 Nov 2015 23:58:19 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Mark Nottingham In-Reply-To: Date: Fri, 20 Nov 2015 15:58:16 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <0FEA24D5-A07A-465A-83CF-64B76DE5F724@mnot.net> References: To: Brian Raymor X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "ietf-http-wg@w3.org" , "webpush@ietf.org" Subject: Re: [Webpush] Proposed 5xx status code for WebPush 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, 20 Nov 2015 04:58:24 -0000 Hey Brian, I think the other thing that needs to be discussed here is why this = needs to be a status code.=20 Generally, we use a status code when we need to expose semantics to = generic HTTP software -- i.e., it's not specific to the payload, = resource, or type thereof.=20 I know that you want to keep webpush as payload "agnostic" (to = perpetuate English misuse even further), but a webpush resource *is* a = specific kind of resource, so it seems to be like these semantics should = be in the payload body, or failing that a HTTP header. really-really-wanting-to-avoid-building-another-webdav-ly yours, > On 19 Nov 2015, at 4:19 pm, Brian Raymor = wrote: >=20 >=20 > In WebPush = (https://datatracker.ietf.org/doc/draft-ietf-webpush-protocol/), an = application server can > request that the push service acknowledge that it has delivered a = message to a user agent. The push service > indicates success (positive acknowledgement) by returning a 410 (Gone) = to the application server. >=20 > The push service also needs to indicate failure (negative = acknowledgement) due to the following cases: >=20 > 1. The user agent failed to acknowledge receipt of the message and the = push service has ceased to attempt re-delivery of > the message prior to its advertised expiration (TTL header = field).=20 > 2. The push service expired the message prior to its advertised = expiration due to operational constraints. >=20 > The following approaches have been explored: >=20 > 1. Reusing 404 (for positive acknowledgement) and 410 (for negative = acknowledgement).=20 >=20 > 2. Use 417 (Expectation Failed) > http://www.ietf.org/mail-archive/web/webpush/current/msg00351.html >=20 > Currently there is a 417 Expectation Failed status code already = defined that works in conjunction with the "Expect" header. > Maybe we can define an "expectation" for the TTL and send it in the = Expect header. Then if the push server drops the message > prematurely, it can send back a 417. (However there seems to be = some history behind the Expect header which may be an issue) >=20 > 3. Combine 410 (Gone) with a non-zero TTL header field to indicate = failure > http://www.ietf.org/mail-archive/web/webpush/current/msg00352.html >=20 > Maybe we can just use TTL. If it is present (and therefore = non-zero) then it's an indication that the TTL hasn't run out, even = though the > message resource is Not Found/Gone. >=20 > 4. Define a new 512 (Expired Resource) status code >=20 > Issue - https://github.com/webpush-wg/webpush-protocol/issues/49 > Pull request - = https://github.com/webpush-wg/webpush-protocol/pull/50 >=20 > Mark Nottingham commented earlier: >=20 > Status codes must be potentially applicable to *all* resources, = not use case specific (as this seems to be). See: > = http://httpwg.github.io/specs/rfc7231.html#considerations.for.new.status.c= odes >=20 > When it is necessary to express semantics for a response that are = not > defined by current status codes, a new status code can be = registered. > Status codes are generic; they are potentially applicable to any > resource, not just one particular media type, kind of resource, or > application of HTTP. As such, it is preferred that new status = codes > be registered in a document that isn't specific to a single > application. >=20 > While we completely agree with Mark's assessment that this use case = is specific to WebPush at this time, > the sense was that this should be in the class of 5xx Server Error = codes. Unfortunately, after review there > were no existing codes related to this use case. We discussed the = proposed status code and potential > mitigations at IETF 94 and agreed to broaden the discussion to the = HTTPbis mailing list. >=20 > Thoughts? Does anyone else have a similar use case? >=20 > ...Brian >=20 >=20 >=20 >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Fri Nov 20 02:40:27 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 0685B1B2D12 for ; Fri, 20 Nov 2015 02:40:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585] 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 pD7PnNz0L_I5 for ; Fri, 20 Nov 2015 02:40:25 -0800 (PST) Received: from inari-msr.crf.canon.fr (inari-msr.crf.canon.fr [194.2.158.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A8951B2D21 for ; Fri, 20 Nov 2015 02:40:24 -0800 (PST) Received: from mir-msr.corp.crf.canon.fr (mir-msr.corp.crf.canon.fr [172.19.77.98]) by inari-msr.crf.canon.fr (8.13.8/8.13.8) with ESMTP id tAKAeM0F006358; Fri, 20 Nov 2015 11:40:22 +0100 Received: from Antiope.crf.canon.fr (antiope.fesl2.crf.canon.fr [172.19.70.56]) by mir-msr.corp.crf.canon.fr (8.13.8/8.13.8) with ESMTP id tAKAeMsN029800; Fri, 20 Nov 2015 11:40:22 +0100 Received: from timor.intra-usr.crf.canon.fr (172.20.5.234) by Antiope.crf.canon.fr (172.19.70.56) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 20 Nov 2015 11:40:21 +0100 To: Benjamin Bangert References: <564C50B7.7070505@crf.canon.fr> From: =?UTF-8?Q?Herv=c3=a9_Ruellan?= Message-ID: <564EF895.4020200@crf.canon.fr> Date: Fri, 20 Nov 2015 11:40:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [172.20.5.234] X-ClientProxiedBy: Antiope.crf.canon.fr (172.19.70.56) To Antiope.crf.canon.fr (172.19.70.56) Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Use Case related to subscription sets 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, 20 Nov 2015 10:40:27 -0000 On 18/11/15 19:20, Benjamin Bangert wrote: > I'm not sure any changes would be needed as is. If a Push Server is > limiting the concurrent streams, the proxy could just open several > connections, one for each device its proxying for that devices > subscription set. The main concern for us is a Push Server enforcing only one subscription set for a client: in our use case, this client would be the proxy (from the WebPush point of view). However, we could have several devices "hidden" behind this proxy, and we want to keep them independent. Its true that a Push Server putting a severe limit to the number of concurrent streams could also be a problem. Using several HTTP/2 connections would probably not be a good solution: as Martin pointed out, this is not allowed by the HTTP/2 spec. Moreover, a Push Server strongly limiting the number of concurrent streams would also probably check that a client doesn't using several connections. > When the device disconnects from the proxy, it would shut down that Push > Service connection, and the device could query the Push Service directly. > > We currently field many connections from single IP's (proxies), and > don't plan on enforcing connection limits for a single IP since mobile > proxies are quite common. > > Cheers, > Ben Cheers, Hervé > > On Wed, Nov 18, 2015 at 2:19 AM, Hervé Ruellan > > wrote: > > Hi all, > > We, at Canon, have a use case that is dependent on the rules > relating subscriptions and subscription sets. > > In this use case, a device (e.g. a camera) connects to a push-server > through a proxy (e.g. a mobile phone). The communication between the > camera and the proxy uses an appropriate protocol (most possibly not > HTTP). A notification goes from the push-server to the proxy (acting > as a user-agent) through WebPush, then from the proxy to the device > through the appropriate protocol. > > We plan to use the same proxy for several devices. We would like to > allow a device to change from a proxy to another seamlessly (e.g. > going from the mobile phone to a PC when coming home). When a device > moves from a proxy to another, we would like it to keep the same > subscription. This means that each device would need to have its own > subscription set to contain its subscription (or subscriptions). > > Supporting this use case means that a client, here the proxy, is > allowed to have several subscription sets. However, this number > would be quite limited as we think only a few devices would connect > through the same proxy. > > This scenario is of importance for us, and we would like the WG to > take it into account in the definition of subscription sets. > > Cheers, > > Hervé Ruellan > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > > From nobody Fri Nov 20 08:42:31 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 B26D61B3898 for ; Fri, 20 Nov 2015 08:42:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 pHmvydcucvKx for ; Fri, 20 Nov 2015 08:42:27 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 8DFEA1B3899 for ; Fri, 20 Nov 2015 08:42:23 -0800 (PST) Received: by wmww144 with SMTP id w144so28337108wmw.0 for ; Fri, 20 Nov 2015 08:42:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WOKBOAFJIN+WWheZBAIDbyT48Pg2EHbnCuwffMtuacw=; b=Ud4Qm8m4PuWKVklnHKaU2Dhs8cVh/VQGIuXV2IAjj8RuUmyVT+Zyykm7BDNFona5AR AkpwfdJxs+HRwogzCnpmbqGlxEY0YTfeclziLfBXZG53Ze4C9re4O2mwGBhZUs3LAuSZ ooJSVZi4vP8AcLK64xWFPiK3n+6KIaVtaFdW4Wt+e80FrMS1hK7xX3oCOFoCMgLn92ug tdUnkusWidiIEHICchtRCkZUmNSaYsxyizi/HhcO0TpJGf6k+CufaVX7GAe/IHPGAuAy /XiNvP53j4NvTWNq9Ex7Xy+lzku+KD7GCj4w4ITuT6FzfTjzoYfITdN5U0JNek0ZSg7n +c9Q== 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=WOKBOAFJIN+WWheZBAIDbyT48Pg2EHbnCuwffMtuacw=; b=ZG9aVkGGfr5uzVvjCOqNbut5SEbz7+bkI/BFcAOSxRkEH8v0nAA09dR6GLmPqE8JIS e8XSZhSs7dIyg3UW4Zm1DBtAnpZDAIixHchGbaSHRJJM9eRwfxLQ9QYUndPcTeZ2bTII W1UPWND5RLD34P1g69JzdHnKd0BSP+KsZ+UWDW+I/CIeW7bVc/5udUDJra6IyHXbtFIV gxYwbmuUxXHZO46EamnpH3UHOhcNkr9JdrHNl+lA24Iieqo/+IbmbWZwuehKIU7ZUcAz nPFrqMxsCrY0IEy75CdoUI0plQ2fZKmLGnBPhrWsmKRmW3zP9Z5KywVM/nA5FbNvtyye ZCGA== X-Gm-Message-State: ALoCoQky9DoiaFKvPcdQGOJ2zD8KPD1vhG6/NLJ6BHO7EYfxRMCpKkGOjGAJTkF3pFHSYtW1POsZ MIME-Version: 1.0 X-Received: by 10.194.175.230 with SMTP id cd6mr9972303wjc.100.1448037741928; Fri, 20 Nov 2015 08:42:21 -0800 (PST) Received: by 10.27.179.194 with HTTP; Fri, 20 Nov 2015 08:42:21 -0800 (PST) In-Reply-To: <564EF895.4020200@crf.canon.fr> References: <564C50B7.7070505@crf.canon.fr> <564EF895.4020200@crf.canon.fr> Date: Fri, 20 Nov 2015 08:42:21 -0800 Message-ID: From: Benjamin Bangert To: =?UTF-8?Q?Herv=C3=A9_Ruellan?= Content-Type: multipart/alternative; boundary=089e013cc3003ac7b50524fb8fbc Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Use Case related to subscription sets 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, 20 Nov 2015 16:42:29 -0000 --089e013cc3003ac7b50524fb8fbc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Nov 20, 2015 at 2:40 AM, Herv=C3=A9 Ruellan wrote: > > > On 18/11/15 19:20, Benjamin Bangert wrote: > >> I'm not sure any changes would be needed as is. If a Push Server is >> limiting the concurrent streams, the proxy could just open several >> connections, one for each device its proxying for that devices >> subscription set. >> > > The main concern for us is a Push Server enforcing only one subscription > set for a client: in our use case, this client would be the proxy (from t= he > WebPush point of view). However, we could have several devices "hidden" > behind this proxy, and we want to keep them independent. > If a Push Server chooses to constrain concurrent streams, that's entirely within its right to do so. One solution for this use-case may be to have the proxy register the subscription sets for each of the devices using it, then switch to a polling model, polling each registered subscription set in turn periodically, though that could bump into request limiting. If a proxy is going to put additional load on a Push Server, then the people running the proxy should run the Push Server as well so that they can shoulder the burden of their use. Since most push servers, as far as I know, will be using SSL, I don't know how a proxy could even function since it would need to MITM the secured connection which is obviously not good. Either way, this situation and use-case seems accounted for by the spec as it is, since those wishing to handle this scenario may run their own Push Server without a low concurrent stream max, and unsecured so that a proxy may function. Cheers, Ben --089e013cc3003ac7b50524fb8fbc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Nov 20, 2015 at 2:40 AM, Herv=C3=A9 Ruellan <herve.ruellan@cr= f.canon.fr> wrote:


On 18/11/15 19:20, Benjamin Bangert wrote:
I'm not sure any changes would be needed as is. If a Push Server is
limiting the concurrent streams, the proxy could just open several
connections, one for each device its proxying for that devices
subscription set.

 The main concern for us is a Push Server enforcing only one subscription se= t for a client: in our use case, this client would be the proxy (from the W= ebPush point of view). However, we could have several devices "hidden&= quot; behind this proxy, and we want to keep them independent.

If a Push Server chooses to constrain concurrent st= reams, that's entirely within its right to do so. One solution for this= use-case may be to have the proxy register the subscription sets for each = of the devices using it, then switch to a polling model, polling each regis= tered subscription set in turn periodically, though that could bump into re= quest limiting.

If a proxy is going to put additional loa= d on a Push Server, then the people running the proxy should run the Push S= erver as well so that they can shoulder the burden of their use.

Since most push servers, as far as I know, will be using SSL, I don= 't know how a proxy could even function since it would need to MITM the= secured connection which is obviously not good.

Either w= ay, this situation and use-case seems accounted for by the spec as it is, s= ince those wishing to handle this scenario may run their own Push Server wi= thout a low concurrent stream max, and unsecured so that a proxy may functi= on.

Cheers,
Ben
--089e013cc3003ac7b50524fb8fbc-- From nobody Fri Nov 20 08:56: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 2E87D1B390D for ; Fri, 20 Nov 2015 08:56:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GfS6hVIwzLVU for ; Fri, 20 Nov 2015 08:56:11 -0800 (PST) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 E52041B390C for ; Fri, 20 Nov 2015 08:56:10 -0800 (PST) Received: by ioc74 with SMTP id 74so129255098ioc.2 for ; Fri, 20 Nov 2015 08:56:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bpvZK2xQvMiiYV74bvZon35n1C8EU1usa1AClq2zGnA=; b=ibKC6UxAWPvTtcYB98XLy3XlpcpEOIdTTNmwW0QvPw4KrJbT+jmLbazipOXlRJveDh 4u7m7DfMclRepeFlwimjLOHcc/tPygf4nCef8BalkYQJo6YDEInC+0Gh2I1c4f1F1l52 lcEYWSBUn67vQ8slDfxzU2oB2M+eQAWMrcCLjSHBkzBd9jS4lxxAmvZ5N4YozvNmvlwF E13g7rnwsrTgDlkGHRzDm1qIxg8MmiBMY/CA6SXhfYkLLPd2HZmyKrKQQd/Le9tuq+oM ZEXS+V5mrHbKiDCy0txVAaBN37LkMdscFLpEO0TB8b1DYKMl6lqaPlUOZCnETwKsSa5q Ztjg== MIME-Version: 1.0 X-Received: by 10.107.33.203 with SMTP id h194mr13636991ioh.108.1448038570289; Fri, 20 Nov 2015 08:56:10 -0800 (PST) Received: by 10.36.155.139 with HTTP; Fri, 20 Nov 2015 08:56:10 -0800 (PST) In-Reply-To: References: <564C50B7.7070505@crf.canon.fr> <564EF895.4020200@crf.canon.fr> Date: Fri, 20 Nov 2015 08:56:10 -0800 Message-ID: From: Martin Thomson To: Benjamin Bangert Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" , =?UTF-8?Q?Herv=C3=A9_Ruellan?= Subject: Re: [Webpush] Use Case related to subscription sets 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, 20 Nov 2015 16:56:12 -0000 On 20 November 2015 at 08:42, Benjamin Bangert wrote: > Either way, this situation and use-case seems accounted for by the spec as > it is, since those wishing to handle this scenario may run their own Push > Server without a low concurrent stream max, and unsecured so that a proxy > may function. That's only true if there were an explicit correlator. In Herve's case, the presence of multiple clients is hidden from the push service. In any case, I will generate a pull request that adds the explicit correlator. It's not at all complicated, I've just been working through some of the encryption pieces. From nobody Fri Nov 20 09:49: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 1C81F1B3A5F for ; Fri, 20 Nov 2015 09:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.702 X-Spam-Level: X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6UAIdk5a16q for ; Fri, 20 Nov 2015 09:49:54 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0774.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:774]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADB1B1B3A61 for ; Fri, 20 Nov 2015 09:49:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7BUCsMEZRL2PzAiSZo5dobN1avULZ3pfbjdYv7zOcBM=; b=El1VeWjgJ/4/jhf9JBxJdbABrqooTpWli/DZUWrK+SThWVYNC2zgsDOsEEfN4vgSM3nSQVXgcNYMgqKJO3RrW2oCdv5H23/jw6AXEC/Zaq1MeYQ5abBQFVtID2IAkMddp0EIwnu4kj2hxtyI6Y3hJWFlCvPBmUwYMb22HKXZCNs= Received: from BY2PR0301MB0647.namprd03.prod.outlook.com (10.160.63.14) by BY2PR0301MB0648.namprd03.prod.outlook.com (10.160.63.140) with Microsoft SMTP Server (TLS) id 15.1.325.17; Fri, 20 Nov 2015 17:49:33 +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.0325.019; Fri, 20 Nov 2015 17:49:33 +0000 From: Brian Raymor To: Benjamin Bangert , =?utf-8?B?SGVydsOpIFJ1ZWxsYW4=?= Thread-Topic: [Webpush] Use Case related to subscription sets Thread-Index: AQHRIeqmRM5eVbt/pk6X9PcfmrGbf56iF+eAgAKj+YCAAGUkgIAADnDw Date: Fri, 20 Nov 2015 17:49:33 +0000 Message-ID: References: <564C50B7.7070505@crf.canon.fr> <564EF895.4020200@crf.canon.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brian.Raymor@microsoft.com; x-originating-ip: [2601:600:8000:5a8:f944:677b:e7d6:ab35] x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0648; 5:PlkicXnhsCILeOwOP66B9klh9thM4fxg4YmXVeAuO9GZjDlmHXEvliUNGOMAZHMK+raDWOoeFuie5qa3xuWzK7/dImo2wHAobag6w10kcecd6NSq2E0yXnWVD37CqPIa34y2fP7sVFrRMY9zMRc6cA==; 24:mje8RMLPa2gX7Z1kN7s2uA2LDtIKmLH9K3L5xPwpw3Z4OPJUmka2QF1KhXYOndZUkVwQWcQKIFbVFTU49wpnORHfIjWrA0gcjSejCJwmg3k=; 20:idr3cfzo1kMzA1GrdA6xk8GKBOJwNoNaSPLx8ncp+KsDGt1QTfmX8GE0znLAv4NEL+zqPeVB/82m1qKtizZAYw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0301MB0648; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(10201501046)(61426024)(61427024); SRVR:BY2PR0301MB0648; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0648; x-forefront-prvs: 07665BE9D1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(24454002)(189002)(377454003)(76176999)(101416001)(93886004)(5007970100001)(77096005)(102836003)(92566002)(33656002)(74316001)(189998001)(122556002)(2900100001)(99286002)(5002640100001)(10290500002)(5005710100001)(5008740100001)(106356001)(97736004)(8990500004)(106116001)(11100500001)(10400500002)(586003)(105586002)(5001770100001)(81156007)(5004730100002)(10090500001)(6116002)(5001960100002)(2950100001)(5003600100002)(86612001)(19580395003)(87936001)(19580405001)(76576001)(50986999)(54356999)(40100003)(86362001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0648; H:BY2PR0301MB0647.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2015 17:49:33.3155 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0648 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Use Case related to subscription sets 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, 20 Nov 2015 17:49:58 -0000 DQpPbiBGcmksIE5vdiAyMCwgMjAxNSBhdCA4OjQzIEFNLCBCZW5qYW1pbiBCYW5nZXJ0IDxiYmFu Z2VydEBtb3ppbGxhLmNvbT4gd3JvdGU6DQo+IFNpbmNlIG1vc3QgcHVzaCBzZXJ2ZXJzLCBhcyBm YXIgYXMgSSBrbm93LCB3aWxsIGJlIHVzaW5nIFNTTCwgSSBkb24ndCBrbm93IGhvdyBhIHByb3h5 IGNvdWxkIGV2ZW4gZnVuY3Rpb24NCj4gc2luY2UgaXQgd291bGQgbmVlZCB0byBNSVRNIHRoZSBz ZWN1cmVkIGNvbm5lY3Rpb24gd2hpY2ggaXMgb2J2aW91c2x5IG5vdCBnb29kLg0KDQpUaGUgbW9i aWxlIHBob25lICgicHJveHkiKSBhY3RzIGFzIHRoZSB1c2VyIGFnZW50IGluIHRoaXMgY2FzZSB3 aXRoIGEgSFRUUFMgY29ubmVjdGlvbiB0byB0aGUgcHVzaCBzZXJ2aWNlLiBBIGRpZmZlcmVudCBw cm90b2NvbCB0aGFuIEhUVFAgbWF5IGJlIHJlcXVpcmVkIGJldHdlZW4gcGhvbmUgYW5kIHRoZSBj YW1lcmEuIFNvdW5kcyBzaW1pbGFyIHRvIGEgZmllbGQgZ2F0ZXdheSBzY2VuYXJpbz8NCg0KPiBF aXRoZXIgd2F5LCB0aGlzIHNpdHVhdGlvbiBhbmQgdXNlLWNhc2Ugc2VlbXMgYWNjb3VudGVkIGZv ciBieSB0aGUgc3BlYyBhcyBpdCBpcywgc2luY2UgdGhvc2Ugd2lzaGluZyB0byBoYW5kbGUNCj4g dGhpcyBzY2VuYXJpbyBtYXkgcnVuIHRoZWlyIG93biBQdXNoIFNlcnZlciB3aXRob3V0IGEgbG93 IGNvbmN1cnJlbnQgc3RyZWFtIG1heCwgYW5kIHVuc2VjdXJlZCBzbyB0aGF0IGENCj4gcHJveHkg bWF5IGZ1bmN0aW9uLg0KDQpSZWdhcmRpbmcgInVuc2VjdXJlZCIsIFNlY3Rpb24gOSByZXF1aXJl cyBIVFRQUyAtIFRoaXMgcHJvdG9jb2wgTVVTVCB1c2UgSFRUUCBvdmVyIFRMUyBbUkZDMjgxOF0u DQo= From nobody Mon Nov 23 01:56: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 4C2591A701C for ; Mon, 23 Nov 2015 01:56:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.636 X-Spam-Level: X-Spam-Status: No, score=-0.636 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585] 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 Spr5hSRBW6RB for ; Mon, 23 Nov 2015 01:56:33 -0800 (PST) Received: from inari-msr.crf.canon.fr (inari-msr.crf.canon.fr [194.2.158.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6AF81A701A for ; Mon, 23 Nov 2015 01:56:32 -0800 (PST) Received: from mir-msr.corp.crf.canon.fr (mir-msr.corp.crf.canon.fr [172.19.77.98]) by inari-msr.crf.canon.fr (8.13.8/8.13.8) with ESMTP id tAN9uUUA028877; Mon, 23 Nov 2015 10:56:30 +0100 Received: from Antiope.crf.canon.fr (antiope.fesl2.crf.canon.fr [172.19.70.56]) by mir-msr.corp.crf.canon.fr (8.13.8/8.13.8) with ESMTP id tAN9uUXn002402; Mon, 23 Nov 2015 10:56:30 +0100 Received: from timor.intra-usr.crf.canon.fr (172.20.7.3) by Antiope.crf.canon.fr (172.19.70.62) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 23 Nov 2015 10:56:29 +0100 From: =?UTF-8?Q?Herv=c3=a9_Ruellan?= To: Brian Raymor References: <564C50B7.7070505@crf.canon.fr> <564EF895.4020200@crf.canon.fr> Message-ID: <5652E2CD.8090709@crf.canon.fr> Date: Mon, 23 Nov 2015 10:56:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [172.20.7.3] X-ClientProxiedBy: Antiope.crf.canon.fr (172.19.70.62) To Antiope.crf.canon.fr (172.19.70.62) Archived-At: Cc: Benjamin Bangert , "webpush@ietf.org" Subject: Re: [Webpush] Use Case related to subscription sets 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, 23 Nov 2015 09:56:34 -0000 On 20/11/15 18:49, Brian Raymor wrote: > > On Fri, Nov 20, 2015 at 8:43 AM, Benjamin Bangert > wrote: > > Since most push servers, as far as I know, will be using SSL, I > don't know how a proxy could even function > > since it would need to MITM the secured connection which is > obviously not good. > > The mobile phone ("proxy") acts as the user agent in this case with a > HTTPS connection to the push service. A different protocol than HTTP > may be required between phone and the camera. Sounds similar to a > field gateway scenario? Yes, the HTTPS connection is between the mobile phone and the push server. And another protocol is used between the camera and the phone. > > Either way, this situation and use-case seems accounted for by the > spec as it is, since those wishing to handle > > this scenario may run their own Push Server without a low concurrent > stream max, and unsecured so that a > > proxy may function. > > Regarding "unsecured", Section 9 requires HTTPS - This protocol MUST > use HTTP over TLS [RFC2818]. For our scenario, we would like to be able to use a generic push server. I agree that the spec supports the use-case, but we would also like the implementations to support the use-case. A short mention of the use-case in the spec would be really helpful. The consequences for an implementation would be to allow a user agent to create a *few* subscription sets, and not limit it to *1*, and also to allow a user agent to open a *few* streams to subscription resources. Hervé From nobody Mon Nov 23 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 BDC0A1A92EB for ; Mon, 23 Nov 2015 09:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 i8jvuNpHioyB for ; Mon, 23 Nov 2015 09:31:17 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 592D81A92EF for ; Mon, 23 Nov 2015 09:31:17 -0800 (PST) Received: by wmww144 with SMTP id w144so106274227wmw.1 for ; Mon, 23 Nov 2015 09:31:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4YJxVlTCfqyhYB25x22kaPdW4I0gzRX8MT4JC/sbbEc=; b=UNHZ+IHAEzheFRLdZef6+wI8nx8H9bVCRwYszbJFSQqHRa5hfYrUHs8AVjkEs1cUvP GT+07eSu8HVIso4GLXgZxSzoS4Yi4VfWksKEe4HpQKaQ+Ly0xfcoQ59o3IBGqNhJ2IZf 796GSdMsamEbf0zZk1Wd27tPYTgdLP9Awd2C2HYcvLM9NKGK4mt2ZVzyUBOjc6OYLtCA 89TIBgEj4R3x5tQyn4UJKLjKjQMVl9FPJD5iHLR8A7xGodu3OGJMITkYQXUu3Jnlp6Xt akiNzubLFqtJqL9jgXNsFUYX+0o52BgC9KRtOFdnG+qIHylTGTNkRUJnuKD7Dwc7bPAD v0qA== 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=4YJxVlTCfqyhYB25x22kaPdW4I0gzRX8MT4JC/sbbEc=; b=aEsSwbfgNAMgKMVw6vbknWoS3yq8u9D3dyQc96L30y3RgNueDQAOgKcaQBL6JQX4IQ AJlkVPZMp55L/rXp8sdliQLCTl4xigv1fcjynbypsj2PSb8VxOBmdA3h3NlXZO4+O2zg eAII9k/PHF84YV4xzObt/s2Qc2PBhtoxRyV/IYSPfmy3GeP5QFZnVxWuHRYQk92/Dh+C 5wUzYROufBelzJciaYqRM+nvTmfMQTl6W+qLDBJ38M5vLnffYH75CvRWDyNOiFTV5apg vCheWNMgBpwnNnPpy/h5Al6EjvGq5wfbcPRvIiXUzsjCDCEWo9sHyc+Ni9yf5Ihhiqdb B/9Q== X-Gm-Message-State: ALoCoQkAGLM0zAw0P0IlqbR9M/tDDmPm0j7udtIZJf291z2TZUJjbFNcGZMiVF9KSBoaScLFVkPi MIME-Version: 1.0 X-Received: by 10.28.127.141 with SMTP id a135mr16891152wmd.69.1448299875530; Mon, 23 Nov 2015 09:31:15 -0800 (PST) Received: by 10.27.179.194 with HTTP; Mon, 23 Nov 2015 09:31:15 -0800 (PST) In-Reply-To: <5652E2CD.8090709@crf.canon.fr> References: <564C50B7.7070505@crf.canon.fr> <564EF895.4020200@crf.canon.fr> <5652E2CD.8090709@crf.canon.fr> Date: Mon, 23 Nov 2015 09:31:15 -0800 Message-ID: From: Benjamin Bangert To: =?UTF-8?Q?Herv=C3=A9_Ruellan?= Content-Type: multipart/alternative; boundary=001a11420af49c1224052538979f Archived-At: Cc: Brian Raymor , "webpush@ietf.org" Subject: Re: [Webpush] Use Case related to subscription sets 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, 23 Nov 2015 17:31:20 -0000 --001a11420af49c1224052538979f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Nov 23, 2015 at 1:56 AM, Herv=C3=A9 Ruellan wrote: > > On 20/11/15 18:49, Brian Raymor wrote: > >> >> On Fri, Nov 20, 2015 at 8:43 AM, Benjamin Bangert >> wrote: >> > Since most push servers, as far as I know, will be using SSL, I >> don't know how a proxy could even function >> > since it would need to MITM the secured connection which is >> obviously not good. >> >> The mobile phone ("proxy") acts as the user agent in this case with a >> HTTPS connection to the push service. A different protocol than HTTP >> may be required between phone and the camera. Sounds similar to a >> field gateway scenario? >> > > Yes, the HTTPS connection is between the mobile phone and the push server= . > And another protocol is used between the camera and the phone. > > > Either way, this situation and use-case seems accounted for by the >> spec as it is, since those wishing to handle >> > this scenario may run their own Push Server without a low concurrent >> stream max, and unsecured so that a >> > proxy may function. >> >> Regarding "unsecured", Section 9 requires HTTPS - This protocol MUST >> use HTTP over TLS [RFC2818]. >> > > For our scenario, we would like to be able to use a generic push server. = I > agree that the spec supports the use-case, but we would also like the > implementations to support the use-case. > A short mention of the use-case in the spec would be really helpful. The > consequences for an implementation would be to allow a user agent to crea= te > a *few* subscription sets, and not limit it to *1*, and also to allow a > user agent to open a *few* streams to subscription resources. Implementation-wise, the only reason a client using our service is restricted to one active subscription set at a time is due to the concurrent stream limit setting. It is however, just that, a setting. Someone could use our eventual implementation and set the stream limit setting to whatever they want to support at scale. Our specific deployment will restrict our clients to 2 concurrent streams via this setting. I'm assuming there will be multiple implementations out there to choose from if you don't want to implement your own, and many/most of them will likely implement the ability to restrict subscription sets in a similar manner... merely by setting a config flag. Cheers, Ben --001a11420af49c1224052538979f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Nov 23, 2015 at 1:56 AM, Herv=C3=A9 Ruellan <herve.ruellan@cr= f.canon.fr> wrote:

On 20/11/15 18:49, Brian Raymor wrote:

On Fri, Nov 20, 2015 at 8:43 AM, Benjamin Bangert
<bbangert@mozi= lla.com> wrote:
> Since most push servers, as far as I know, will be using SSL, I
don't know how a proxy could even function
> since it would need to MITM the secured connection which is
obviously not good.

The mobile phone ("proxy") acts as the user agent in this case wi= th a
HTTPS connection to the push service. A different protocol than HTTP
may be required between phone and the camera. Sounds similar to a
field gateway scenario?

 Yes, the HTTPS connection is between the mobile phone and the push server. = And another protocol is used between the camera and the phone.

> Either way, this situation and use-case seems accounted for by the
spec as it is, since those wishing to handle
> this scenario may run their own Push Server without a low concurrent stream max, and unsecured so that a
> proxy may function.

Regarding "unsecured", Section 9 requires HTTPS - This protocol M= UST
use HTTP over TLS [RFC2818].

 For our scenario, we would like to be able to use a generic push server. I = agree that the spec supports the use-case, but we would also like the imple= mentations to support the use-case.
A short mention of the use-case in the spec would be really helpful. The co= nsequences for an implementation would be to allow a user agent to create a= *few* subscription sets, and not limit it to *1*, and also to allow a user= agent to open a *few* streams to subscription resources.

Implementation-wise, the only reason a client using our service is restric= ted to one active subscription set at a time is due to the concurrent strea= m limit setting. It is however, just that, a setting.

Som= eone could use our eventual implementation and set the stream limit setting= to whatever they want to support at scale. Our specific deployment will re= strict our clients to 2 concurrent streams via this setting.

<= div>I'm assuming there will be multiple implementations out there to ch= oose from if you don't want to implement your own, and many/most of the= m will likely implement the ability to restrict subscription sets in a simi= lar manner... merely by setting a config flag.

Cheers,
Ben
--001a11420af49c1224052538979f-- From nobody Mon Nov 23 10:16:49 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 8D4971ACCF4 for ; Mon, 23 Nov 2015 10:16:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5uRn5kDu6AA for ; Mon, 23 Nov 2015 10:16:45 -0800 (PST) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 863ED1ACCF0 for ; Mon, 23 Nov 2015 10:16:45 -0800 (PST) Received: by igbxm8 with SMTP id xm8so63077945igb.1 for ; Mon, 23 Nov 2015 10:16:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Gnp9Alo+G77FP7Sckk15SCErohKEWER9eJcPBtSase8=; b=Cs7H0o0duJ3YTiwEW5oFNbrzPcXq2EojUmAWPFoKx9Wmrfa0tx1kyAVGG9wIhAV6K3 eUc97C9s6zFDfE1jYOvfd/EC13Gr3CBXktu8dii0B6BSSDe4d77RRvVZF+Fqg2+Bx2c6 pKWH4Nwr2FhhH8aUfP7u1+eRJHXeBs+ZwOLKw/D8o10eyaImO+0++H6zU1gwdAnNk13a 5sag+3pQ7bMrtFBDVGgDIgVEIr2c1aJoAYYxwFRLpektoXvDijOOCj56aHpzhcbfMULb Djo5XMVF9bazKy1GTpiAP3nZiiLOP1DIcZqqqTqp+bYAPtnLlOsjlygweZlPiIuheLaS DxAg== MIME-Version: 1.0 X-Received: by 10.50.183.11 with SMTP id ei11mr16097338igc.94.1448302604933; Mon, 23 Nov 2015 10:16:44 -0800 (PST) Received: by 10.36.155.139 with HTTP; Mon, 23 Nov 2015 10:16:44 -0800 (PST) In-Reply-To: References: <564C50B7.7070505@crf.canon.fr> <564EF895.4020200@crf.canon.fr> <5652E2CD.8090709@crf.canon.fr> Date: Mon, 23 Nov 2015 10:16:44 -0800 Message-ID: From: Martin Thomson To: Benjamin Bangert Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Brian Raymor , "webpush@ietf.org" , =?UTF-8?Q?Herv=C3=A9_Ruellan?= Subject: Re: [Webpush] Use Case related to subscription sets 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, 23 Nov 2015 18:16:47 -0000 As Ben says here, I think that the question of limits is something that is specific to a service. The concurrent stream limit is a valid way of limiting load, certainly. However, I don't think that it makes the problem go away. It's a second order solution in the sense that it attempts to address the consequences of bad behaviour. I would rather have a service reject attempts to create unlinked subscriptions. An explicit link between subscriptions isn't that hard to do. I've created a pull request that illustrates how simple it would be to accommodate Herv=C3=A9's request. https://github.com/webpush-wg/webpush-protocol/pull/67 On 23 November 2015 at 09:31, Benjamin Bangert wrote= : > On Mon, Nov 23, 2015 at 1:56 AM, Herv=C3=A9 Ruellan > wrote: >> >> >> On 20/11/15 18:49, Brian Raymor wrote: >>> >>> >>> On Fri, Nov 20, 2015 at 8:43 AM, Benjamin Bangert >>> wrote: >>> > Since most push servers, as far as I know, will be using SSL, I >>> don't know how a proxy could even function >>> > since it would need to MITM the secured connection which is >>> obviously not good. >>> >>> The mobile phone ("proxy") acts as the user agent in this case with a >>> HTTPS connection to the push service. A different protocol than HTTP >>> may be required between phone and the camera. Sounds similar to a >>> field gateway scenario? >> >> >> Yes, the HTTPS connection is between the mobile phone and the push serve= r. >> And another protocol is used between the camera and the phone. >> >>> > Either way, this situation and use-case seems accounted for by the >>> spec as it is, since those wishing to handle >>> > this scenario may run their own Push Server without a low concurrent >>> stream max, and unsecured so that a >>> > proxy may function. >>> >>> Regarding "unsecured", Section 9 requires HTTPS - This protocol MUST >>> use HTTP over TLS [RFC2818]. >> >> >> For our scenario, we would like to be able to use a generic push server.= I >> agree that the spec supports the use-case, but we would also like the >> implementations to support the use-case. >> A short mention of the use-case in the spec would be really helpful. The >> consequences for an implementation would be to allow a user agent to cre= ate >> a *few* subscription sets, and not limit it to *1*, and also to allow a = user >> agent to open a *few* streams to subscription resources. > > > Implementation-wise, the only reason a client using our service is > restricted to one active subscription set at a time is due to the concurr= ent > stream limit setting. It is however, just that, a setting. > > Someone could use our eventual implementation and set the stream limit > setting to whatever they want to support at scale. Our specific deploymen= t > will restrict our clients to 2 concurrent streams via this setting. > > I'm assuming there will be multiple implementations out there to choose f= rom > if you don't want to implement your own, and many/most of them will likel= y > implement the ability to restrict subscription sets in a similar manner..= . > merely by setting a config flag. > > Cheers, > Ben > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > From nobody Mon Nov 23 13:13:43 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 8F1331B2C1F for ; Thu, 19 Nov 2015 08:21:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 mSUtrRpTcYX0 for ; Thu, 19 Nov 2015 08:21:44 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CBA11B2C56 for ; Thu, 19 Nov 2015 08:21:43 -0800 (PST) Received: by wmec201 with SMTP id c201so33796049wme.0 for ; Thu, 19 Nov 2015 08:21:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gryning-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bsfBbPiWhUZLWlVrbicjRaAdczTo4y1mH196iNg+RVc=; b=kptqN5/gmvR5KP7mHug1XoAmixzFlVKFGbz88YIoqlRifa66WdOd+C/f1kaVENjBB0 sdArqXNXmCn+BBPa0pS8LZG5sGf3zaZXEP7ZzAnSgE8zyxS2RfcEiCHt9mAlgyjSoatW rf56Mv23I6RDjlatojGvpoIMF7+W3Irer302HTlF3qEIaIkRocGw9ry9mXUG2YrCIX+n OVGZGIt9lYGm2bmtoTE/mHAixMXXlAhMYXgRE34hgJoHfcT4+thNoKRGDJdp7Do3+VK1 vMTleKPJ20BL391DOiiuQ5mEi70Fz4eDHJpIgiM3nZ0QIqGDJBEtL53d61SlRQ1vovLf Zg6Q== 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=bsfBbPiWhUZLWlVrbicjRaAdczTo4y1mH196iNg+RVc=; b=aPqtw87YYtme9t+QDhGwidGta7Wj9SN8nTswiksqZj868E8yHJPGJE8FLC7oEkWrmd zNNE9BN94hz8PabnUGzV6F04oggsmZYIxzeK+CeByFj/l9tftX5LoTpvYRptQ7o0Fa6X YnAm+Oti0CW2S8nG84q2pkIRVN8kOfQEvNUelJFbYj3YP+ot/cgy4f0vpjQTszQj4G5m ShZ9iZaEkU1x2EWxaGYfqdH78zK629rdUxRoMWUL0kA+j3D5QYUkgcQOdGLts+R+Icb1 KC9wwGLnFv9TtU8kK9iyXE68ySQjygolZKF5tlFGpni+a+72LU8F5uJRiakUexMy4ux6 zeYA== X-Gm-Message-State: ALoCoQnWBb8YVm58NnNmTgXpNWYaM6JqTwKi7lqsV/qIBxuYNEagpiCxdfWFFqhN91DzwITyMS/p MIME-Version: 1.0 X-Received: by 10.194.90.169 with SMTP id bx9mr9192099wjb.1.1447950101316; Thu, 19 Nov 2015 08:21:41 -0800 (PST) Received: by 10.28.171.86 with HTTP; Thu, 19 Nov 2015 08:21:41 -0800 (PST) X-Originating-IP: [132.185.153.5] In-Reply-To: References: Date: Thu, 19 Nov 2015 16:21:41 +0000 Message-ID: From: "c^" To: Brian Raymor Content-Type: multipart/alternative; boundary=047d7bfd0df8711c830524e727e7 Archived-At: X-Mailman-Approved-At: Mon, 23 Nov 2015 13:13:41 -0800 Cc: "ietf-http-wg@w3.org" , "webpush@ietf.org" Subject: Re: [Webpush] Proposed 5xx status code for WebPush 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, 19 Nov 2015 16:21:49 -0000 --047d7bfd0df8711c830524e727e7 Content-Type: text/plain; charset=UTF-8 A few thoughts I shared privately with Martin in Yokohama: My starting assumption is that the resource is created on the push service, and the push service is authoritative as to it's status. -------------------- 410: Makes sense as in the draft to provide a normalised response; 1 response for absolute completion, I have administratively removed this resource and I do not intend to return it. 5xx: Indicating a failed DELETE to remove the relationship of subscriber /d/bbb resource isn't what I'd expect. Given we are simulating a GET from the application to assert the status of a resource, where the stated use of 'gone' is used to indicate having administratively/intentionally removed this resource. To then return a 5xx in the contrary case, indicating that there is a server issue in asserting a response to something it should be answering authoritatively for doesn't seem correct. I would argue that a 200/202 would be more appropriate as the push service was unable to remove all references to the resource described as the DELETE failed; and the negative of having something removed would be a successful response. This could be extended to be more specific using a warning ( https://tools.ietf.org/html/rfc7234#section-5.5) body or header. New 4xx: Finally, an alternative 4xx such as 404/409 might be applicable as a contrary to the the 410. A new 4xx that indicates I had a representation; but it is now expired and I can't reconcile this. This said 404 still makes logical sense when considered as the response to a simulated get. e.g. push service has now removed this asset, but not deliberately/administratively. Expiration could be indicated as part of the body or header or as a warning. -------------------- Hope this helps and doesn't re-open old threads. CraigT On 19 November 2015 at 05:19, Brian Raymor wrote: > > In WebPush (https://datatracker.ietf.org/doc/draft-ietf-webpush-protocol/), > an application server can > request that the push service acknowledge that it has delivered a message > to a user agent. The push service > indicates success (positive acknowledgement) by returning a 410 (Gone) to > the application server. > > The push service also needs to indicate failure (negative acknowledgement) > due to the following cases: > > 1. The user agent failed to acknowledge receipt of the message and the > push service has ceased to attempt re-delivery of > the message prior to its advertised expiration (TTL header field). > 2. The push service expired the message prior to its advertised expiration > due to operational constraints. > > The following approaches have been explored: > > 1. Reusing 404 (for positive acknowledgement) and 410 (for negative > acknowledgement). > > 2. Use 417 (Expectation Failed) > http://www.ietf.org/mail-archive/web/webpush/current/msg00351.html > > Currently there is a 417 Expectation Failed status code already > defined that works in conjunction with the "Expect" header. > Maybe we can define an "expectation" for the TTL and send it in the > Expect header. Then if the push server drops the message > prematurely, it can send back a 417. (However there seems to be some > history behind the Expect header which may be an issue) > > 3. Combine 410 (Gone) with a non-zero TTL header field to indicate failure > http://www.ietf.org/mail-archive/web/webpush/current/msg00352.html > > Maybe we can just use TTL. If it is present (and therefore non-zero) > then it's an indication that the TTL hasn't run out, even though the > message resource is Not Found/Gone. > > 4. Define a new 512 (Expired Resource) status code > > Issue - https://github.com/webpush-wg/webpush-protocol/issues/49 > Pull request - https://github.com/webpush-wg/webpush-protocol/pull/50 > > Mark Nottingham commented earlier: > > Status codes must be potentially applicable to *all* resources, not > use case specific (as this seems to be). See: > > http://httpwg.github.io/specs/rfc7231.html#considerations.for.new.status.codes > > When it is necessary to express semantics for a response that are not > defined by current status codes, a new status code can be registered. > Status codes are generic; they are potentially applicable to any > resource, not just one particular media type, kind of resource, or > application of HTTP. As such, it is preferred that new status codes > be registered in a document that isn't specific to a single > application. > > While we completely agree with Mark's assessment that this use case is > specific to WebPush at this time, > the sense was that this should be in the class of 5xx Server Error > codes. Unfortunately, after review there > were no existing codes related to this use case. We discussed the > proposed status code and potential > mitigations at IETF 94 and agreed to broaden the discussion to the > HTTPbis mailing list. > > Thoughts? Does anyone else have a similar use case? > > ...Brian > > > > > --047d7bfd0df8711c830524e727e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A few thoughts I shared pr= ivately with Martin in Yokohama:

<= /div>

My starting assumption=C2=A0is that th= e resource is created on the push service, and the push service is authorit= ative as to it's status.
--------------------

410: Makes= sense as in the draft to provide a normalised response; 1 response for abs= olute completion, I have administratively removed this resource and I do no= t intend to return it.

5xx: Indicating a failed DELETE to remove the re= lationship of subscriber /d/bbb resource isn't what I'd expect. Giv= en we are simulating a GET from the application to assert the status of a r= esource, where the stated use of 'gone' is used to indicate having = administratively/intentionally removed this resource. To then return a 5xx = in the contrary case, indicating that there is a server issue in asserting = a response to something it should be answering authoritatively for doesn= 9;t seem correct. I would argue that a 200/202 would be more appropriate as= the push service was unable to remove all references to the resource descr= ibed as the DELETE failed; and the negative of having something removed wou= ld be a successful response. This could be extended to be more specific usi= ng a warning (h= ttps://tools.ietf.org/html/rfc7234#section-5.5) body or header.

New= 4xx:=C2=A0
Finally, an alternative 4x= x such as 404/409 might be applicable as a contrary to the the 410. A new 4= xx that indicates I had a representation; but it is now expired and I can&#= 39;t reconcile this. This said 404 still makes logical sense when considere= d as the response to a simulated get. e.g. push service has now removed thi= s asset, but not deliberately/administratively. Expiration could be indicat= ed as part of the body or header or as a warning.

--------------------

Hope this helps and doesn'= ;t re-open old threads.

= CraigT

On 19 November 2015 at 05:19, Bria= n Raymor <Brian.Raymor@microsoft.com> wrote:

In WebPush (https://datatracker.ietf.or= g/doc/draft-ietf-webpush-protocol/), an application server can
request that the push service acknowledge that it has delivered a message t= o a user agent. The push service
indicates success (positive acknowledgement) by returning a 410 (Gone) to t= he application server.

The push service also needs to indicate failure (negative acknowledgement) = due to the following cases:

1. The user agent failed to acknowledge receipt of the message and the push= service has ceased to attempt re-delivery of
=C2=A0 =C2=A0 =C2=A0the message=C2=A0 prior to its advertised expiration (T= TL header field).
2. The push service expired the message prior to its advertised expiration = due to operational constraints.

The following approaches have been explored:

1. Reusing 404 (for positive acknowledgement) and 410 (for negative acknowl= edgement).

2. Use 417 (Expectation Failed)
=C2=A0 =C2=A0 http://www.ietf.org/= mail-archive/web/webpush/current/msg00351.html

=C2=A0 =C2=A0 Currently there is a 417 Expectation Failed status code alrea= dy defined that works in conjunction with the "Expect" header. =C2=A0 =C2=A0 Maybe we can define an "expectation" for the TTL an= d send it in the Expect header. Then if the push server drops the message =C2=A0 =C2=A0 prematurely, it can send back a 417. (However there seems to = be some history behind the Expect header which may be an issue)

3. Combine 410 (Gone) with a non-zero TTL header field to indicate failure<= br> =C2=A0 =C2=A0 http://www.ietf.org/= mail-archive/web/webpush/current/msg00352.html

=C2=A0 =C2=A0 Maybe we can just use TTL.=C2=A0 If it is present (and theref= ore non-zero) then it's an indication that the TTL hasn't run out, = even though the
=C2=A0 =C2=A0 message resource is Not Found/Gone.

4. Define a new 512 (Expired Resource) status code

=C2=A0 =C2=A0 Issue=C2=A0 - https://github.c= om/webpush-wg/webpush-protocol/issues/49
=C2=A0 =C2=A0 Pull request -=C2=A0 https://git= hub.com/webpush-wg/webpush-protocol/pull/50

=C2=A0 =C2=A0 Mark Nottingham commented earlier:

=C2=A0 =C2=A0 =C2=A0 Status codes must be potentially applicable to *all* r= esources, not use case specific (as this seems to be). See:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 http://httpwg.github.io/specs/rfc7231.html#considerations.for.new.sta= tus.codes

=C2=A0 =C2=A0 =C2=A0When it is necessary to express semantics for a respons= e that are not
=C2=A0 =C2=A0 =C2=A0defined by current status codes, a new status code can = be registered.
=C2=A0 =C2=A0 =C2=A0Status codes are generic; they are potentially applicab= le to any
=C2=A0 =C2=A0 =C2=A0resource, not just one particular media type, kind of r= esource, or
=C2=A0 =C2=A0 =C2=A0application of HTTP.=C2=A0 As such, it is preferred tha= t new status codes
=C2=A0 =C2=A0 =C2=A0be registered in a document that isn't specific to = a single
=C2=A0 =C2=A0 =C2=A0application.

=C2=A0 While we completely agree with Mark's assessment that this use c= ase is specific to WebPush at this time,
=C2=A0 the sense was that this should be in the class of 5xx Server Error c= odes. Unfortunately, after review there
=C2=A0 were no existing codes related to this use case. We discussed the pr= oposed status code and potential
=C2=A0 mitigations at IETF 94 and agreed to broaden the discussion to the H= TTPbis mailing list.

Thoughts? Does anyone else have a similar use case?

...Brian





--047d7bfd0df8711c830524e727e7-- From nobody Mon Nov 23 13:13: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 050D21B2CD1 for ; Thu, 19 Nov 2015 09:00:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585, 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 eHlNdT9Rull9 for ; Thu, 19 Nov 2015 09:00:22 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF3E61B2CC8 for ; Thu, 19 Nov 2015 09:00:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 35CF8279BE51; Thu, 19 Nov 2015 12:00:17 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m129graVenmZ; Thu, 19 Nov 2015 12:00:16 -0500 (EST) Received: from [17.149.232.135] (unknown [17.149.232.135]) by daboo.name (Postfix) with ESMTPSA id E39D3279BE46; Thu, 19 Nov 2015 12:00:15 -0500 (EST) Date: Thu, 19 Nov 2015 12:00:12 -0500 From: Cyrus Daboo To: Brian Raymor , ietf-http-wg@w3.org Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=909 Archived-At: X-Mailman-Approved-At: Mon, 23 Nov 2015 13:13:50 -0800 Cc: webpush@ietf.org Subject: Re: [Webpush] Proposed 5xx status code for WebPush 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, 19 Nov 2015 17:00:24 -0000 Hi Brian, --On November 19, 2015 at 5:19:15 AM +0000 Brian Raymor wrote: > In WebPush > (https://datatracker.ietf.org/doc/draft-ietf-webpush-protocol/), an > application server can request that the push service acknowledge that it > has delivered a message to a user agent. The push service indicates > success (positive acknowledgement) by returning a 410 (Gone) to the > application server. It seems a little odd for "success" to be indicated by a 4xx code. Why not just return a 204 (No Content) for that case? If you do that, then you can use 410 for the case where the server has stopped processing the push, and 503 for the "operation" failure. If you need more fine-grained error reporting, then consider using as the way to do that rather than inventing lots of new status codes. -- Cyrus Daboo From nobody Mon Nov 23 13:47: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 A23D31B34E5 for ; Mon, 23 Nov 2015 13:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eces0w2WWHJr for ; Mon, 23 Nov 2015 13:47:11 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0776.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:776]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB1131B34EE for ; Mon, 23 Nov 2015 13:47:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BISTdtVghC8T5P8wczzR1BPetI6TwBC0XOCVlFHhA/U=; b=itQeE7aA8M/i6gViuyexS/pylDXs5wmp1v2Zhdc/M7Sfz11T8OZ8szO5AWIWSZi5KdrAEk5nhdKkjFdG46Q2ct1DWkizGl2KolWpqjZ98mUIJ+LSIdk/fEpAd87Z9wu9hfcyR1IacfHbIEeekOpx9L1drMPp1g2YQD+X2qjM/rA= Received: from BY2PR0301MB0647.namprd03.prod.outlook.com (10.160.63.14) by BY2PR0301MB0648.namprd03.prod.outlook.com (10.160.63.140) with Microsoft SMTP Server (TLS) id 15.1.331.20; Mon, 23 Nov 2015 21:46:48 +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.0331.019; Mon, 23 Nov 2015 21:46:48 +0000 From: Brian Raymor To: Martin Thomson , Benjamin Bangert Thread-Topic: [Webpush] Use Case related to subscription sets Thread-Index: AQHRIeqmRM5eVbt/pk6X9PcfmrGbf56iF+eAgAKj+YCAAGUkgIAADnDwgAQ3KYCAAH8PgIAADLUAgAAosSA= Date: Mon, 23 Nov 2015 21:46:48 +0000 Message-ID: References: <564C50B7.7070505@crf.canon.fr> <564EF895.4020200@crf.canon.fr> <5652E2CD.8090709@crf.canon.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brian.Raymor@microsoft.com; x-originating-ip: [73.42.172.77] x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0648; 5:dlWir77pgh1Fzj28kuwVaMZFk00lZFqwbO0lRbTwlcfPOusqXd+rwC2dW5/0XlyX+IhjRS9g+8abrcdQy80eRD2AJOkHC0kyqg8nK7fcFvN2IXQcDZ6kWmUqyv0Ym1cj0NSs1VuogumbzNrT7MoKnA==; 24:6Npt1+GargxAMj8/OzYX+X8XtH4omWXIn16F4FdbfNltvtNue4JbcG3dgKDHCdm80o/xG0VP49mClR6x55zlhFkpRVRKuJA8XHKCJIf8z84= x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42140001); SRVR:BY2PR0301MB0648; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001)(61426024)(61427024); SRVR:BY2PR0301MB0648; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0648; x-forefront-prvs: 07697999E6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(52604005)(199003)(189002)(99286002)(101416001)(93886004)(106356001)(106116001)(54356999)(33656002)(5007970100001)(5008740100001)(76576001)(5005710100001)(10090500001)(76176999)(66066001)(97736004)(2950100001)(105586002)(10290500002)(77096005)(15975445007)(5001960100002)(8990500004)(5004730100002)(10400500002)(189998001)(11100500001)(92566002)(86362001)(102836003)(19580395003)(6116002)(5002640100001)(40100003)(3846002)(5003600100002)(2900100001)(5001770100001)(586003)(87936001)(81156007)(50986999)(122556002)(74316001)(86612001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0648; H:BY2PR0301MB0647.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2015 21:46:48.1163 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0648 Archived-At: Cc: "webpush@ietf.org" , =?utf-8?B?SGVydsOpIFJ1ZWxsYW4=?= Subject: Re: [Webpush] Use Case related to subscription sets 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, 23 Nov 2015 21:47:13 -0000 DQo+IEFuIGV4cGxpY2l0IGxpbmsgYmV0d2VlbiBzdWJzY3JpcHRpb25zIGlzbid0IHRoYXQgaGFy ZCB0byBkby4gIEkndmUNCj4gY3JlYXRlZCBhIHB1bGwgcmVxdWVzdCB0aGF0IGlsbHVzdHJhdGVz IGhvdyBzaW1wbGUgaXQgd291bGQgYmUgdG8NCj4gYWNjb21tb2RhdGUgSGVydsOpJ3MgcmVxdWVz dC4NCg0KPiBodHRwczovL2dpdGh1Yi5jb20vd2VicHVzaC13Zy93ZWJwdXNoLXByb3RvY29sL3B1 bGwvNjcNCg0KVGhhbmtzIGZvciBjcmVhdGluZyB0aGUgcHVsbCByZXF1ZXN0LCBNYXJ0aW4uIEkn dmUgYWRkZWQgc3BlY2lmaWMgY29tbWVudHMgdGhlcmUuDQoNClRoZSBxdWVzdGlvbiBpcyB3aGV0 aGVyIHRoZSBXRyBwcmVmZXJzICJ1c2VyIGFnZW50IGRlY2lkZXMiIC0gd2hpY2ggaXMgdGhlIGNh c2UNCndoZXJlIHRoZSBwdXNoIHNlcnZpY2UgYWR2ZXJ0aXNlcyB0aGUgYXZhaWxhYmlsaXR5IG9m IHNldHMgaW4gaXRzIHJlc3BvbnNlIHRvDQp0aGUgZmlyc3Qgc3Vic2NyaXB0aW9uIHJlcXVlc3Qg YW5kIHRoZSB1c2VyIGFnZW50IGNhbiB0aGVuIGRlY2lkZSB3aGV0aGVyIHRvDQpwYXNzIHRoZSBw dXNoOnNldCB3aXRoIHN1YnNlcXVlbnQgc3Vic2NyaXB0aW9uIHJlcXVlc3RzIGZvciBhZ2dyZWdh dGlvbi4gVGhpcyBpcw0KZGVmaW5pdGVseSBhIHZlcnkgZmxleGlibGUgYXBwcm9hY2ggYWx0aG91 Z2ggd2l0aCBhICBmZXcgbW9yZSBtb3ZpbmcgcGFydHMuDQoNCkluIHByZXZpb3VzIGRpc2N1c3Np b25zLCBvbmUgb2YgdGhlIGNvbmNlcm5zIGFib3V0ICJ1c2VyIGFnZW50IGRlY2lkZXMiIGlzIHdo YXQNCmhhcHBlbnMgaWYgYSBwdXNoIHNlcnZpY2Ugc3Ryb25nbHkgd2FudHMgdG8gcmVxdWlyZSBh Z2dyZWdhdGlvbiwgYnV0IHRoZSB1c2VyIGFnZW50DQpmYWlscyB0byBpbmNsdWRlIHRoZSBhZHZl cnRpc2VkIHB1c2g6c2V0IHdpdGggaXRzIHN1YnNlcXVlbnQgc3Vic2NyaXB0aW9uIHJlcXVlc3Rz Pw0KVGhpcyB3YXMgb25lIG9mIHRoZSBtb3RpdmF0aW9ucyBmb3IgdGhlIGN1cnJlbnQgYXBwcm9h Y2ggb2YgInB1c2ggc2VydmljZSBkZWNpZGVzIi4NCg0KUGVyaGFwcyB0aGUgY29tYmluYXRpb24g b2YgInVzZXIgYWdlbnQgZGVjaWRlcyIgd2l0aCAicHVzaCBzZXJ2aWNlICplbmNvdXJhZ2VzKiIN CmJ5IGxpbWl0aW5nIGNvbmN1cnJlbnQgSFRUUC8yIHN0cmVhbXMgaXMgdGhlIHBvdGVudGlhbCBj b21wcm9taXNlLg0KDQoNCg== From nobody Mon Nov 23 15:13:40 2015 Return-Path: X-Original-To: webpush@ietf.org Delivered-To: webpush@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 96EC91B33A7; Mon, 23 Nov 2015 15:13:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151123231338.2373.90941.idtracker@ietfa.amsl.com> Date: Mon, 23 Nov 2015 15:13:38 -0800 Archived-At: Cc: webpush@ietf.org Subject: [Webpush] I-D Action: draft-ietf-webpush-protocol-02.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, 23 Nov 2015 23:13:38 -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-02.txt Pages : 27 Date : 2015-11-23 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-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-webpush-protocol-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 23 15:20: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 275E91B352E for ; Mon, 23 Nov 2015 15:20:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmwlvh4GwuRc for ; Mon, 23 Nov 2015 15:20:00 -0800 (PST) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::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 8EB461B352C for ; Mon, 23 Nov 2015 15:20:00 -0800 (PST) Received: by iofh3 with SMTP id h3so3085149iof.3 for ; Mon, 23 Nov 2015 15:20:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ds9FKDQh/bF3fLzfY1cAZxAYahbczvQG4YEgljlqvyk=; b=tOOJ6bZIqay8kiSKZ1VXA1DpamYorkkgTuo3R5mOjFWgvkKCU2SF1FzbQs1dew2BRe FE0wQqcdr5yROuhZoqh7B/gnj4fR4e5Ckh2j9bGBqBBZoKbPp5XWdoGgmBqrNkOnsmdd +mym8Eh1DG1L5PKikPAPwvrH/lv+eyM2uSb0TKHkrTq/yAQdCgZjQmw6nPLG4h43YYH8 sHJ0TaUHX1EkEuor7an7Rf1GHkCO4usvhTE8OXCq3VOWLZx9htr9pncV2u3YOneFLoYE gCZ2Zb59qg2BJimhdLEAWzxQp6V0lq5KbWFT/qbE0zrgb+0hYAg6xEd76ixASFcmQk3w UVvA== MIME-Version: 1.0 X-Received: by 10.107.26.144 with SMTP id a138mr15155260ioa.100.1448320799909; Mon, 23 Nov 2015 15:19:59 -0800 (PST) Received: by 10.36.155.139 with HTTP; Mon, 23 Nov 2015 15:19:59 -0800 (PST) In-Reply-To: References: <564C50B7.7070505@crf.canon.fr> <564EF895.4020200@crf.canon.fr> <5652E2CD.8090709@crf.canon.fr> Date: Mon, 23 Nov 2015 15:19:59 -0800 Message-ID: From: Martin Thomson To: Brian Raymor Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Benjamin Bangert , "webpush@ietf.org" , =?UTF-8?Q?Herv=C3=A9_Ruellan?= Subject: Re: [Webpush] Use Case related to subscription sets 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, 23 Nov 2015 23:20:02 -0000 On 23 November 2015 at 13:46, Brian Raymor wrote: > Perhaps the combination of "user agent decides" with "push service *encourages*" > by limiting concurrent HTTP/2 streams is the potential compromise. That's where I'm headed. Though I'm also adding "spec *encourages*" by using the word MUST. I don't think that we get any gains for the important scenarios if we don't provide at least some encouragement to aggregate into a set. I've added text to the PR that explains what the push service might do to punish user agents that don't allow for aggregation. It's relying on the same magical anti-DoS stuff again, which is hardly ever perfect, but often adequate in practice. Here I expect that looking at the connection will work to catch genuine but innocent mistakes. The bad guys are always going to be harder to pin down. From nobody Mon Nov 23 15:44:01 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 C8A001AD0C6 for ; Mon, 23 Nov 2015 15:43:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9EK1wp9m_3Hk for ; Mon, 23 Nov 2015 15:43:58 -0800 (PST) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E3571AD09D for ; Mon, 23 Nov 2015 15:43:58 -0800 (PST) Received: by ioir85 with SMTP id r85so3671812ioi.1 for ; Mon, 23 Nov 2015 15:43:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=HOvPAbNBn7lgJBFbEOjY5iaZ87vXanwrCaX+lBbDZbQ=; b=zDG1Cte+aW5NrBP5tVGzProuxHlsof+xPd9m1rZEMoP4F7TwuCBJf73WjWkw9UGbcz 0eagJiuZOals729bEx0Acm9DNt2qcmre5vsxPShyHpGOBuz2awDmTeYEzIZzRZKqQrum AhCt1vEVsVeRZtS23h94SHj7NjXC0B87Qo3HujfdeO2iFKZPB/cfiFnPOX5bEniNueUK LAF8e3oLtbqESrZggrQB4LP50dYVbOpucgXMJvwtUR4kYq5ZVyFDoQmnf4KsXfyZzJ8P tl9FTDHcVoeGq7pvTcYEWmQ0audQid+27en81PUVwER/Y0VllqUOl56/msHmBz9Y/FXL 3rkw== MIME-Version: 1.0 X-Received: by 10.107.26.144 with SMTP id a138mr15224557ioa.100.1448322237596; Mon, 23 Nov 2015 15:43:57 -0800 (PST) Received: by 10.36.155.139 with HTTP; Mon, 23 Nov 2015 15:43:57 -0800 (PST) Date: Mon, 23 Nov 2015 15:43:57 -0800 Message-ID: From: Martin Thomson To: "webpush@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Webpush] Voluntary application server identification 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, 23 Nov 2015 23:44:00 -0000 I did a little write up of the options that I think are most likely solutions for issue #44: https://martinthomson.github.io/webpush-vapid/ (Submission as an I-D is imminent.) All the relevant considerations are covered in the draft. I started out by describing a single option, but realized that addressing the alternatives was probably wise. In doing so, I think that some combination of alternatives might not be as crazy as I first thought. Some are clearly less good. In particular, request signing has been proposed, but I think that putting a signature validation on the critical path is not a great idea. The other options are much better in this regard. From nobody Tue Nov 24 08:45: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 169751B2CC2 for ; Tue, 24 Nov 2015 08:45:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.963 X-Spam-Level: X-Spam-Status: No, score=-1.963 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.585, 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 vmEOxAI3RZuQ for ; Tue, 24 Nov 2015 08:45:07 -0800 (PST) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::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 BA21D1B2CA3 for ; Tue, 24 Nov 2015 08:45:06 -0800 (PST) Received: by lfdl133 with SMTP id l133so28366039lfd.2 for ; Tue, 24 Nov 2015 08:45:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OExRWCuXsxL4BLA2E4Yod9P9LaKBeTtY88ID7yGXUjU=; b=FyFKhnKLZ8p9FP2AOJltIkh/HRG4ocucPIpdrORMPRgsdaHVv0QpV+Coa0lpJp/Okv cjI/evDwvm9Ryp5K+aFzxasbxcHLpvoaG7gA9RWMZ9S1Br8TYQVxMl7XOfC6DVDvJzKK pe08EV9EXplh1M11Vccejh2lAKaDz6haCoOmMEuwVH0dqFweZTiZS0Mz3PtjBn90I74S ieiEgbEwltTQ69So4AKitEPXu5wg3D8GRuD4NjvEafDrjn/BA5gdnRikFZMNt6CV7nsv HXDtMZpb7yDiXfVlppum57FqY7WS4P/50vYK5pHoKgAS1ntunGhGjYyZNDNGJm0Vll5h HAzw== 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=OExRWCuXsxL4BLA2E4Yod9P9LaKBeTtY88ID7yGXUjU=; b=PBlLcWf63fI5YTnfmyRBPbH1aHBlzufQDOvrzqNzHV9rzCX1bxLVWzpvO8a4UHm5OI RdT+uYylkNLK1Nquc2G1IwyH5JeVc9C9fW+izVsDkl9LfXDDYqM+Wmy69s601VcA5QxZ MiJbLVb6dKP3Wj7rzlvgzHP1+lRbgB8OriZNy4qkwGkMWQP+2OoPit5ran6AcDdLEBUC Xkgd00iI+5UXs7E8MTqZpI0uGjvnB3bWZTX9z2dnaS+WhVz7RqTI3ccyXf8+ubdfn8oS Q2T0Qz+0CfvXlvL+CXdsk6v1Jcuo9johKOSrILvVl3COoDEarI0Er+FbuO6e68uyHJvA QN+g== X-Gm-Message-State: ALoCoQmQRdU0HmVDXV9qof5lH9qE1ZZUiTyr0rQ7ZV5baoLOE6/pZ4kQmHpfD/EH6q5uXsNIqHFm MIME-Version: 1.0 X-Received: by 10.25.161.211 with SMTP id k202mr14544088lfe.161.1448383504815; Tue, 24 Nov 2015 08:45:04 -0800 (PST) Received: by 10.25.166.78 with HTTP; Tue, 24 Nov 2015 08:45:04 -0800 (PST) In-Reply-To: References: Date: Tue, 24 Nov 2015 16:45:04 +0000 Message-ID: From: Peter Beverloo To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1141189c4de5e605254c109c Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Voluntary application server identification 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, 24 Nov 2015 16:45:09 -0000 --001a1141189c4de5e605254c109c Content-Type: text/plain; charset=UTF-8 Hi Martin, Thank you for writing this up. Something that server identification would enable is the ability for subscriptions to be associated with a given application server, i.e. not only relying on endpoint secrecy. The proposed solution, having a TLS client certificate, has the benefit that the certificate's public key could serve as a token for this association. Not all alternative solutions have similar shareable tokens. Both server identification and subscription association are important for us, and, at least initially, mechanisms that we will mandate use of. If this proposal works for everybody, we may have to consider a status code through which the push service can indicate this. (I realize that this, unfortunately, stands in contrast to your statement that requiring authentication is unwanted. I personally believe that the benefits of authentication outweigh the privacy implications - self signed certificates w/o data fields only act as a persistent token. I see no problem with other push services not mandating this, of course.) Let me produce a similar proposal, building on yours, to further explore subscription association. Thanks, Peter On Mon, Nov 23, 2015 at 11:43 PM, Martin Thomson wrote: > I did a little write up of the options that I think are most likely > solutions for issue #44: > https://martinthomson.github.io/webpush-vapid/ > > (Submission as an I-D is imminent.) > > All the relevant considerations are covered in the draft. I started > out by describing a single option, but realized that addressing the > alternatives was probably wise. In doing so, I think that some > combination of alternatives might not be as crazy as I first thought. > > Some are clearly less good. In particular, request signing has been > proposed, but I think that putting a signature validation on the > critical path is not a great idea. The other options are much better > in this regard. > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > --001a1141189c4de5e605254c109c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Martin,

Thank you for wri= ting this up.

Something that server identification= would enable is the ability for
subscriptions to be associated w= ith a given application server, i.e.
not only relying on endpoint= secrecy.

The proposed solution, having a TLS clie= nt certificate, has the benefit
that the certificate's public= key could serve as a token for this
association. Not all alterna= tive solutions have similar shareable tokens.

Both= server identification and subscription association are important for
=
us, and, at least initially, mechanisms that we will mandate use of. I= f
this proposal works for everybody, we may have to consider a st= atus code
through which the push service can indicate this.
=

(I realize that this, unfortunately, stands in contrast= to your statement
that requiring authentication is unwanted. I p= ersonally believe that the
benefits of authentication outweigh th= e privacy implications - self
signed certificates w/o data fields= only act as a persistent token. I see
no problem with other push= services not mandating this, of course.)

Let me p= roduce a similar proposal, building on yours, to further explore
= subscription association.

Thanks,
Peter<= /div>


On Mon, Nov 23, 2015 at 11:43 PM, Martin Thomson <martin.t= homson@gmail.com> wrote:
I = did a little write up of the options that I think are most likely
solutions for issue #44:
=C2=A0 https://martinthomson.github.io/webpush-vapid/<= /a>

(Submission as an I-D is imminent.)

All the relevant considerations are covered in the draft.=C2=A0 I started out by describing a single option, but realized that addressing the
alternatives was probably wise.=C2=A0 In doing so, I think that some
combination of alternatives might not be as crazy as I first thought.

Some are clearly less good.=C2=A0 In particular, request signing has been proposed, but I think that putting a signature validation on the
critical path is not a great idea.=C2=A0 The other options are much better<= br> in this regard.

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

--001a1141189c4de5e605254c109c-- From nobody Tue Nov 24 09:03: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 94FA01B2DD7 for ; Tue, 24 Nov 2015 09:03:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6WlZ0HSawfu for ; Tue, 24 Nov 2015 09:03:12 -0800 (PST) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 413F81B2DBD for ; Tue, 24 Nov 2015 09:03:12 -0800 (PST) Received: by igvg19 with SMTP id g19so99669894igv.1 for ; Tue, 24 Nov 2015 09:03:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=L3Vbw+8S7Nln3daCgLqXdJ2uZQUj400Df4vO/J4pJtQ=; b=txDYmaToSlJhGsmFkpnm8MjfKv6GmIfPCWmY1kw0bNlBfOxSTK4vTV7rg4b7WgEEtO h9yWYSJF/d219SXQ0RJxm/2JUDL5BPmH2EiYeLVjeFfJtElkt2Gpw6P/KDt3pssmj97F 6nmhv4Q4l22B7wzlrZQT4dnzjkq4mBoOrLX/aIObwE9wuc2xLEZPam0PAObFUPKE5VxX zrIfw57JK8XcUUlkE4zLGoNwBOFCpCw+/7RiUmmtJJwtjVxg24Txv6yxujn8r/Sbja1O GoDeJercKK9zlgIE6L49NM90JwN/pwtCEsqBX6Xmvh+R6of8lorUBU3jjPImExwMoYZr SNTA== MIME-Version: 1.0 X-Received: by 10.50.30.6 with SMTP id o6mr19263957igh.94.1448384591528; Tue, 24 Nov 2015 09:03:11 -0800 (PST) Received: by 10.36.155.139 with HTTP; Tue, 24 Nov 2015 09:03:11 -0800 (PST) In-Reply-To: References: Date: Tue, 24 Nov 2015 09:03:11 -0800 Message-ID: From: Martin Thomson To: Peter Beverloo Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Voluntary application server identification 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, 24 Nov 2015 17:03:13 -0000 On 24 November 2015 at 08:45, Peter Beverloo wrote: > The proposed solution, having a TLS client certificate, has the benefit > that the certificate's public key could serve as a token for this > association. Not all alternative solutions have similar shareable tokens. All the signature-based options have this property (though the -cavage option would need to be enhanced a little, unless you require the additional step below). > Both server identification and subscription association are important for > us, and, at least initially, mechanisms that we will mandate use of. If > this proposal works for everybody, we may have to consider a status code > through which the push service can indicate this. This is a good point. The idea being that you could have an application feed the public key it's application server will use to the .subscribe() method on the API. That would propagate up to the push service and the push service would drop push messages that weren't signed with the corresponding private key. I didn't want to introduce too many new concepts at once, but this is a good idea. I'd like to keep it optional, of course. From nobody Tue Nov 24 10:21:56 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 71D5A1A1A69 for ; Tue, 24 Nov 2015 10:21:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.636 X-Spam-Level: X-Spam-Status: No, score=-0.636 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585] 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 e0krEaE8xCoA for ; Tue, 24 Nov 2015 10:21:54 -0800 (PST) Received: from inari-msr.crf.canon.fr (inari-msr.crf.canon.fr [194.2.158.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2EC61A0856 for ; Tue, 24 Nov 2015 10:21:53 -0800 (PST) Received: from mir-bsr.corp.crf.canon.fr (mir-bsr.corp.crf.canon.fr [172.19.77.99]) by inari-msr.crf.canon.fr (8.13.8/8.13.8) with ESMTP id tAOILoRY010031; Tue, 24 Nov 2015 19:21:50 +0100 Received: from Antiope.crf.canon.fr (antiope.fesl2.crf.canon.fr [172.19.70.56]) by mir-bsr.corp.crf.canon.fr (8.13.8/8.13.8) with ESMTP id tAOILnZA023163; Tue, 24 Nov 2015 19:21:50 +0100 Received: from timor.intra-usr.crf.canon.fr (172.20.7.3) by Antiope.crf.canon.fr (172.19.70.56) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 24 Nov 2015 19:21:49 +0100 From: =?UTF-8?Q?Herv=c3=a9_Ruellan?= To: Martin Thomson References: <564C50B7.7070505@crf.canon.fr> <564EF895.4020200@crf.canon.fr> <5652E2CD.8090709@crf.canon.fr> Message-ID: <5654AABC.3000000@crf.canon.fr> Date: Tue, 24 Nov 2015 19:21:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [172.20.7.3] X-ClientProxiedBy: Antiope.crf.canon.fr (172.19.70.56) To Antiope.crf.canon.fr (172.19.70.56) Archived-At: Cc: Benjamin Bangert , Brian Raymor , "webpush@ietf.org" Subject: Re: [Webpush] Use Case related to subscription sets 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, 24 Nov 2015 18:21:55 -0000 Thanks for the pull request. I find it a good compromise: it covers our use-case while still encouraging UA to reuse subscription sets. Hervé On 24/11/15 00:19, Martin Thomson wrote: > On 23 November 2015 at 13:46, Brian Raymor wrote: > > Perhaps the combination of "user agent decides" with "push service *encourages*" > > by limiting concurrent HTTP/2 streams is the potential compromise. > > That's where I'm headed. Though I'm also adding "spec *encourages*" > by using the word MUST. I don't think that we get any gains for the > important scenarios if we don't provide at least some encouragement to > aggregate into a set. > > I've added text to the PR that explains what the push service might do > to punish user agents that don't allow for aggregation. It's relying > on the same magical anti-DoS stuff again, which is hardly ever > perfect, but often adequate in practice. > > Here I expect that looking at the connection will work to catch > genuine but innocent mistakes. The bad guys are always going to be > harder to pin down. >