From nobody Wed Oct 7 18:09:15 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C28AE1B2C4C for ; Wed, 7 Oct 2015 18:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id od-KVTP_YxSv for ; Wed, 7 Oct 2015 18:09:11 -0700 (PDT) Received: from gator4135.hostgator.com (gator4135.hostgator.com [192.185.4.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F98D1B2C47 for ; Wed, 7 Oct 2015 18:09:11 -0700 (PDT) Received: from [50.174.96.154] (port=36006 helo=[192.168.1.7]) by gator4135.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.85) (envelope-from ) id 1Zjzhm-000EGP-6m; Wed, 07 Oct 2015 20:09:10 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Shida Schubert In-Reply-To: <4EEA4359-3E21-4DFA-A539-5F26E26ED022@mnot.net> Date: Wed, 7 Oct 2015 15:51:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <87ED7031-E916-467E-8D41-7D8BE67094C3@ntt-at.com> References: <93A7701A-A14E-4CBD-8B4A-D3718DA86935@ntt-at.com> <4EEA4359-3E21-4DFA-A539-5F26E26ED022@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.2104) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator4135.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source-IP: 50.174.96.154 X-Exim-ID: 1Zjzhm-000EGP-6m X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.7]) [50.174.96.154]:36006 X-Source-Auth: shida@agnada.com X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== Archived-At: Cc: Brian Raymor , Martin Thomson , "webpush@ietf.org" Subject: Re: [Webpush] Call for Adoption : encryption draft as a WG item X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2015 01:09:14 -0000 All; I didn=E2=80=99t hear any strong push back on the adoption of the draft = but I also heard some concern about it=E2=80=99s heavy dependency on the = thomson-http-encryption.=20 I think it will be difficult to put the draft thorough IESG without any = way to encrypt the contents, so we need something and the only thing on = the table right now is this draft.=20 If people want to wait until Yokohama to adopt this draft, please voice = it now. When you voice your objection, please come up with a counter = proposal (whether proposing existing mechanism etc.), so we can keep the = discussions rolling. If I don=E2=80=99t hear anything within a week, I will ask Martin to = submit a 00 working group draft. =20 Regards Shida=20 > On Sep 11, 2015, at 7:16 AM, Mark Nottingham wrote: >=20 > Brian et al, >=20 > FWIW - I'm considering doing a Call for Adoption on that draft in the = not-too-distant future, but haven't talked to Barry about it yet.=20 >=20 > That said, one of the factors that will help make that determination = is this WG having a dependency on the work. >=20 > Cheers, >=20 >=20 >> On 10 Sep 2015, at 5:40 pm, Brian Raymor = wrote: >>=20 >>=20 >> On 9 September 2015 at 18:12, Martin Thomson = wrote: >>=20 >>> On 9 September 2015 at 16:55, Brian Raymor = wrote: >>>> Since draft-thomson-webpush-encryption-01 is dependent on = draft-thomson-http-encryption-01, is the intent to liaison with HTTPbis = at IETF 94 and request a mechanism for encrypted content-encoding? This = would be similar to the request from HTTPbis to TLS to address next = protocol negotiation at IETF 85 (Slide 7) - = http://www.ietf.org/proceedings/85/slides/slides-85-tls-1.pdf. >>=20 >>> I think that would be best, though I'd suggest that our area = directors are the best people to consult on the distribution of work. = As it was with ALPN, we give up change control when that happens and = would have to respect the decisions made with respect to that work as it = evolves. >>=20 >> Then, I'd prefer to keep encryption as an optional feature in a = separate draft from the core protocol until there is more clarity. Have = existing solutions also been completely ruled out? I did miss the = earlier HTTPbis discussion at IETF 92 due to schedule conflicts. The = tone/direction of the conversation is a bit hard to assess from the = minutes. >>=20 >>=20 >> ...Brian >> _______________________________________________ >> Webpush mailing list >> Webpush@ietf.org >> https://www.ietf.org/mailman/listinfo/webpush >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 >=20 >=20 >=20 > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush From nobody Fri Oct 9 16:35:51 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7391B4E68 for ; Fri, 9 Oct 2015 16:35:49 -0700 (PDT) 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 WV8gJwSFYQQm for ; Fri, 9 Oct 2015 16:35:47 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0124.outbound.protection.outlook.com [65.55.169.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 679D11B4E65 for ; Fri, 9 Oct 2015 16:35:46 -0700 (PDT) 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=qIhxSbzhSDlW7OLDTBwAeEip0nfwMSthk2t6IwEUW00=; b=EpPQ43v+UJgw6nrfz6Am49dPeOY2Cse2nkLnzuc1IxGko1fln3CifgNvsdug5m/UiWogmEp3IkIhrjZUhBm4Nx261feocRa8jfmoZ5WdgzElbT/Xx0sDF1FNZtgGkq6KQu9D2Q0076lDNz9+NFMhD8zFoXBHrEyIwUrIR/sXJZQ= Received: from BY2PR0301MB0647.namprd03.prod.outlook.com (10.160.63.14) by BY2PR0301MB0645.namprd03.prod.outlook.com (10.160.63.13) with Microsoft SMTP Server (TLS) id 15.1.293.16; Fri, 9 Oct 2015 23:35:42 +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.0293.007; Fri, 9 Oct 2015 23:35:43 +0000 From: Brian Raymor To: "webpush@ietf.org" Thread-Topic: SHOULD return subscription expiration Thread-Index: AdEC1IbmOnDkKo+NR92igeTjFtuajQ== Date: Fri, 9 Oct 2015 23:35:42 +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:a96a:a5fd:fae8:bbf8] x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0645; 5:YDK0US80NkBbTCNHo1F+4U5QuNoDrRQMJb66dy+qlpsRyFMhttTcZmB8jxOXC9PWXOp9xIK21OSD6HF4fSKaLJ2G2rLrTh4yjegSrXZR4T05q0k3+KcU0Gk9blkxwzlWfAcvhzGzqmSxvZN8tbNRSw==; 24:0MU290tzYTjGK+GxVGooLOYURmSf0K6Lo0qAA2f7VgnOUYX1KKHwEc3zZlu/T7bYdoiijToTs/0MnZVvTI3SoAsXeTL97yonNvgHp+oN8gU=; 20:8Z+XMZ1Q1euEWVaTZhJYd12fV9T+xkl/XXyt136k9hZqBqRG3UZ4pl+WJ6TfEnU1h1uPUkG3ZB4CCTUnO1XKpA== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42139001)(42140001); SRVR:BY2PR0301MB0645; 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)(61426024)(61427024); SRVR:BY2PR0301MB0645; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0645; x-forefront-prvs: 0724FCD4CD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(64706001)(40100003)(450100001)(99286002)(2351001)(87936001)(105586002)(5002640100001)(229853001)(5003600100002)(106356001)(54356999)(5008740100001)(101416001)(5005710100001)(10400500002)(10090500001)(8990500004)(5004730100002)(76576001)(74316001)(81156007)(2501003)(10290500002)(86612001)(97736004)(110136002)(46102003)(19580395003)(33656002)(5007970100001)(50986999)(5001920100001)(92566002)(189998001)(102836002)(77096005)(15975445007)(2900100001)(86362001)(5001960100002)(107886002)(122556002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0645; 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2015 23:35:42.9101 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0645 Archived-At: Subject: [Webpush] SHOULD return subscription 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: Fri, 09 Oct 2015 23:35:50 -0000 This is related to editorial changes for - https://github.com/webpush-wg/we= bpush-protocol/issues/32 - There was some discussion on Subscription Expira= tion back in October 2014 on this topic - the thread starts - https://maila= rchive.ietf.org/arch/msg/webpush/GVLOvIIY-GD7vHEUJRoqg_wPdWE - and in that = thread, Martin was prescient in noting "but I realize that the push channel= expiration is going to get confused with message expiry" ;-) Reviewing webpush-00: https://tools.ietf.org/html/draft-ietf-webpush-protocol-00#section-7.3 ... A push service might choose to set a fixed expiration time. If a resource has a known expiration time, expiration information is included in responses to requests that create the resource, or in requests that retrieve a representation of the resource. Expiration is indicated using either the Expires header field, or by setting a "max-age" parameter on a Cache-Control header field (see [RFC7234]). The Cache-Control header field MUST also include the "private" directive. A push service can remove a subscription at any time ... https://tools.ietf.org/html/draft-ietf-webpush-protocol-00#section-6 ... In response to this request, the push server MUST generate a server push for all push messages that have not yet been delivered. In addition, the push service SHOULD return ... expiration information for = the subscription. With more experience from prototypes, is the WG finding the optional Subscr= iption Expiration header to be valuable? Or - should we deprecate the Expir= ation header and just rely on the 400-series status code to signal expirati= on? Especially since the push server is permitted to expire subscriptions a= t will? If we decide to retain the Expiration header, then guidance must be added f= or when a user agent or application server learns that a subscription is ne= ar expiration. Currently, the behavior is unstated in the protocol, althoug= h there is related guidance in the W3C Push API which notes that expiration= time is a MAY - https://w3c.github.io/push-api/#the-pushsubscriptionchange= -event -=20 The pushsubscriptionchange event indicates that a push subscription has= been invalidated, or will soon be =20 invalidated. For example, the push service MAY set an expiration time. = A webapp SHOULD attempt to=20 resubscribe while handling this event, in order to continue receiving p= ush messages. For consistency, the subscription expiration for receipts should also be ad= ded to 6.2. Receiving Push Message Receipts. ...Brian From nobody Fri Oct 9 16:36:07 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 9780A1B4E68 for ; Fri, 9 Oct 2015 16:36:06 -0700 (PDT) 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 gxGL2jIpa8lc for ; Fri, 9 Oct 2015 16:36:05 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0132.outbound.protection.outlook.com [65.55.169.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F15BA1B4E67 for ; Fri, 9 Oct 2015 16:36:04 -0700 (PDT) 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=4ryXjewf24PsWsrGdX0LyNz9PkOJKvKgMu8tiuyupX4=; b=bOge0aJ4JzSy4llJeaJvSS8avd4XIi4ZkeHToloNi2ieXg1NIWHoArG5e+5pF53DR5p98NtILD2CR4En8rWJQ2EguyHWynaaDUUyx7yTZlzHvH26YWQrpLi723/ZrWiJhcSSq+z7IlbfBr/U1+JmZ/e9F/+9esl5xjMYjXrKBAE= Received: from BY2PR0301MB0647.namprd03.prod.outlook.com (10.160.63.14) by BY2PR0301MB0645.namprd03.prod.outlook.com (10.160.63.13) with Microsoft SMTP Server (TLS) id 15.1.293.16; Fri, 9 Oct 2015 23:36:02 +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.0293.007; Fri, 9 Oct 2015 23:36:02 +0000 From: Brian Raymor To: "webpush@ietf.org" Thread-Topic: SHOULD return link references to the push and receipt subscribe resources Thread-Index: AdEC0zA7lvpb2lzuR5C6c24NlklaeA== Date: Fri, 9 Oct 2015 23:36:02 +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:a96a:a5fd:fae8:bbf8] x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0645; 5:IczJApWHsql6RSGpoIY8veev3h9os4P+K/fkARWJzvbW4p/er9oZXAx2ewl4FlDIbTvCkZcMl6Abz34kW5/Q0NCjr95A2DnXyT1T1BoLhCw2GlotqPraOSvTPUV3yQOOHfg1flDSwcJaARshouwGDQ==; 24:vh9dJDTpuKfg84g5fRAnYf1Udtzm9QKm5TVc+h9kT4XMWwG0hEI0N3byIsqtR9BDtQL1U+1z0iogAyvyQCgX2gYtbh2dK6excPiD9bvv2Yw=; 20:bLbxNegy1uRi37oCtb6/XHvJq6EUJrCcIhOOAmicJF41fuLA/W8IHiCXymaoqnZk9FbmzxqrKdIX7s7Jk+63tg== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42139001); SRVR:BY2PR0301MB0645; 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)(61426024)(61427024); SRVR:BY2PR0301MB0645; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0645; x-forefront-prvs: 0724FCD4CD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(12063002)(199003)(189002)(64706001)(40100003)(450100001)(99286002)(2351001)(87936001)(105586002)(5002640100001)(229853001)(5003600100002)(106356001)(54356999)(5008740100001)(101416001)(5005710100001)(10400500002)(10090500001)(8990500004)(5004730100002)(76576001)(74316001)(81156007)(2501003)(10290500002)(86612001)(97736004)(110136002)(46102003)(19580395003)(33656002)(5007970100001)(50986999)(5001920100001)(92566002)(189998001)(102836002)(11100500001)(77096005)(15975445007)(2900100001)(86362001)(5001960100002)(107886002)(122556002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0645; 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2015 23:36:02.4105 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0645 Archived-At: Subject: [Webpush] SHOULD return link references to the push and receipt subscribe resources 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, 09 Oct 2015 23:36:06 -0000 https://tools.ietf.org/html/draft-ietf-webpush-protocol-00#section-6 ... In response to this request, the push server MUST generate a server push for all push messages that have not yet been delivered. In addition, the push service SHOULD return link references to the push and receipt subscribe resources ... What is the rationale for returning the :push and :push:receipt link refere= nces in this response? For example, if a user agent is receiving a push mes= sage, then it has already received and shared the :push link reference with= its application server. Why would it need to receive the :push link refer= ence from the push server again? ...Brian From nobody Sat Oct 10 00:56: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 75BCF1B3494 for ; Sat, 10 Oct 2015 00:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11EleHRg7C_m for ; Sat, 10 Oct 2015 00:56:55 -0700 (PDT) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94D051B348C for ; Sat, 10 Oct 2015 00:56:55 -0700 (PDT) Received: by ykba192 with SMTP id a192so94367097ykb.3 for ; Sat, 10 Oct 2015 00:56:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ON2o1PqKUnzVnk1rC17ygMjjLf0X3r/avv7S09pnSRk=; b=RVEBb8T41+naEv7ZqrhDItIxKSMACS0k6PrK7AhTfr6hnbUPnT/CUBEjqY8BZJoK4M N/Xiwg/9pd3B/+o+P6dzmZH8PMKT+GMJQSw/QYQBCIeePd1IcjujWFwr9nlsll9wzO/1 JsO+A2AcPzG0a2ODEY4g+DUY2u6mv99p21EKlBBbc2a4QqJNFVMfaB8Blzxx/sjkjV7v K2jz9wjY/ry1ne/xUdEElBjqsq9ilMMyY48q94MPcW6+Gxep6M4g06kxPHccMqVGxjz2 gDEPbaykJVMVfo14NH4JVka0yiDUNiErRlckvahijuEcz1I/eJS+SMqms/vPjTIjXQnh Idzw== MIME-Version: 1.0 X-Received: by 10.129.146.208 with SMTP id j199mr13690053ywg.183.1444463814789; Sat, 10 Oct 2015 00:56:54 -0700 (PDT) Received: by 10.13.230.78 with HTTP; Sat, 10 Oct 2015 00:56:54 -0700 (PDT) In-Reply-To: References: Date: Sat, 10 Oct 2015 09:56:54 +0200 Message-ID: From: Martin Thomson To: Brian Raymor Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] SHOULD return subscription 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: Sat, 10 Oct 2015 07:56:57 -0000 Our implementation is currently only reactive when it comes to subscription expiration. That means that we tolerate a break if the server is forced to expire a subscription. Note that the discussion from before was all predicated on a different design, one where individual subscriptions were subjugate to a larger "registration". The current design, even the with the addition of subscription sets, doesn't suffer from the ambiguity problem you described. However, after reviewing the HTTP cache control stuff in more detail, I think that it might be best to remove this feature. The use case (graceful replacement of a subscription), might be important, but I don't think that using response freshness as a proxy for subscription lifetime is correct. If we discover that there is a need, I think that an alternative mechanism will be required. A more direct signal - an explicit "refresh now" message - might be a superior option. The consequence of that is that we will rely on the 4xx responses to inform user agents of when the push service has expired a subscription. For the moment, that's probably OK. The consequential drop in reliability should be low. On 10 October 2015 at 01:35, Brian Raymor wrot= e: > This is related to editorial changes for - https://github.com/webpush-wg/= webpush-protocol/issues/32 - There was some discussion on Subscription Expi= ration back in October 2014 on this topic - the thread starts - https://mai= larchive.ietf.org/arch/msg/webpush/GVLOvIIY-GD7vHEUJRoqg_wPdWE - and in tha= t thread, Martin was prescient in noting "but I realize that the push chann= el expiration is going to get confused with message expiry" ;-) > > Reviewing webpush-00: > > https://tools.ietf.org/html/draft-ietf-webpush-protocol-00#section-7.3 > ... > A push service might choose to set a fixed expiration time. If a > resource has a known expiration time, expiration information is > included in responses to requests that create the resource, or in > requests that retrieve a representation of the resource. > > Expiration is indicated using either the Expires header field, or by > setting a "max-age" parameter on a Cache-Control header field (see > [RFC7234]). The Cache-Control header field MUST also include the > "private" directive. > > A push service can remove a subscription at any time ... > > https://tools.ietf.org/html/draft-ietf-webpush-protocol-00#section-6 > ... > In response to this request, the push server MUST generate a server > push for all push messages that have not yet been delivered. In > addition, the push service SHOULD return ... expiration information fo= r the > subscription. > > With more experience from prototypes, is the WG finding the optional Subs= cription Expiration header to be valuable? Or - should we deprecate the Exp= iration header and just rely on the 400-series status code to signal expira= tion? Especially since the push server is permitted to expire subscriptions= at will? > > If we decide to retain the Expiration header, then guidance must be added= for when a user agent or application server learns that a subscription is = near expiration. Currently, the behavior is unstated in the protocol, altho= ugh there is related guidance in the W3C Push API which notes that expirati= on time is a MAY - https://w3c.github.io/push-api/#the-pushsubscriptionchan= ge-event - > > The pushsubscriptionchange event indicates that a push subscription h= as been invalidated, or will soon be > invalidated. For example, the push service MAY set an expiration time= . A webapp SHOULD attempt to > resubscribe while handling this event, in order to continue receiving= push messages. > > For consistency, the subscription expiration for receipts should also be = added to 6.2. Receiving Push Message Receipts. > > ...Brian > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush From nobody Sat Oct 10 01:00:20 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89AF01A00DC for ; Sat, 10 Oct 2015 01:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2GRGLWauZHc for ; Sat, 10 Oct 2015 01:00:17 -0700 (PDT) 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 365FF1A00BD for ; Sat, 10 Oct 2015 01:00:17 -0700 (PDT) Received: by ykec126 with SMTP id c126so61083792yke.2 for ; Sat, 10 Oct 2015 01:00:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=nlVsRtmZcBi5ACOumXKrlcEPCjY3flSPzWREoPSfDYg=; b=YFK8gEj6LO45y00kbnH25h9uJ3UP+At3N7G4Fk5zVI6Rb8AZl50V1qo0Ev42lZBJIl lSgiQxw0ChXDmeAHKKNrPlnVLlcUe1GYgG63c281f4dgAzpEsZjhp+FTA5qOxYq5HC9H V7tXqB6tli7vxTujcpmRiU2o/h1S/W1BtD8FvPEr1j7RnYQXo1vwbRPWhka8q7Rv7VJ5 xNlOtiT39A6CUmZyznUrB0BXQph0SjrelAEoLJiM4ZTm+7yLZf88waR/KvpSrgMqdNIv 1rmzrGAGMQ3fP+094aMgjB9ILG1923cVfSel05NykrtGr8lJLb0pyPXOlQRBw1M9FoFW YDVg== MIME-Version: 1.0 X-Received: by 10.129.132.80 with SMTP id u77mr12105278ywf.187.1444464016607; Sat, 10 Oct 2015 01:00:16 -0700 (PDT) Received: by 10.13.230.78 with HTTP; Sat, 10 Oct 2015 01:00:16 -0700 (PDT) In-Reply-To: References: Date: Sat, 10 Oct 2015 10:00:16 +0200 Message-ID: From: Martin Thomson To: Brian Raymor Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] SHOULD return link references to the push and receipt subscribe resources X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2015 08:00:18 -0000 On 10 October 2015 at 01:36, Brian Raymor wrot= e: > What is the rationale for returning the :push and :push:receipt link refe= rences in this response? For example, if a user agent is receiving a push m= essage, then it has already received and shared the :push link reference wi= th its application server. Why would it need to receive the :push link ref= erence from the push server again? The idea was to reduce the state commitment requirements on user agents. This way, a client only needs to remember the subscription URI. The server needs to know the mapping to receipt and push resources for each subscription anyway, so this should be trivial to implement. Without it, user agents are forced to remember three URIs for each subscription. From nobody Sun Oct 11 16:18: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 3CC1D1B2ECC for ; Sun, 11 Oct 2015 16:18:13 -0700 (PDT) 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 reGJGyco96q6 for ; Sun, 11 Oct 2015 16:18:08 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0147.outbound.protection.outlook.com [207.46.100.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF3F51B2ECA for ; Sun, 11 Oct 2015 16:18:08 -0700 (PDT) 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=2cqyXoGpdMd2m+q0Y16YSC9JZENIH3bXXtn1OTeJE9M=; b=ZacRtFWUFOtMpJmWxu0CyLApB+2e2aG3sOT5ih46Kb9vOqUhrV1Y7lIBf1RCaHXfV9DEH5RJk0KaMT2eRctpdxmwr89PcnAevVB9fUQqN/oWPwa4kYWG09yoZWM38viztIHgz6/eYhORzALvKHi/W6pSmZmODKu9dkL2w1+E460= 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.286.20; Sun, 11 Oct 2015 23:18:07 +0000 Received: from BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) by BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) with mapi id 15.01.0293.007; Sun, 11 Oct 2015 23:18:07 +0000 From: Brian Raymor To: "Martin Thomson (martin.thomson@gmail.com)" Thread-Topic: [Webpush] SHOULD return link references to the push and receipt subscribe resources Thread-Index: AdEC0zA7lvpb2lzuR5C6c24NlklaeAAXoKoAAFH9YyA= Date: Sun, 11 Oct 2015 23:18:05 +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: [2601:600:8000:5a8:a991:fd36:d5f3:19e] x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0646; 5:fi3FN5WOT26D2RW/w7ghlgpqXOLcWFiLcFZhpqu6eV5A1dgNbMk9fqjCT7TIG00DU/A/zexORhcsNMjjH2D1dC74PKL7gy3QKCXxKuWp/wi2evRTFar+uDLOpfSXXLRY5KQHSmkYYTnp4qcqqL6Quw==; 24:duKE0OQuCmrHi89LvgHLLITLuH80LWiIZS2phL8BFTdOfazov6ksnC7tygXJcx1s0NhEFvUFbJuIW7/X3I9nuA0+VhA1vVHn97+fJ1XPYyA=; 20:8kfpTX1s1ueEfxxvEBVGKG132YZO9FSvY+qC/tMgLjvAzeT97PR1nJVyHNGim2dvQMBi0YgrdVVPZ2cVRwEkDg== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42140001); SRVR:BY2PR0301MB0646; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(5005006)(8121501046)(520078)(3002001)(61426024)(61427024); SRVR:BY2PR0301MB0646; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0646; x-forefront-prvs: 0726B2D7A6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(24454002)(189002)(52314003)(164054003)(12063002)(86362001)(122556002)(19580405001)(5001960100002)(11100500001)(105586002)(87936001)(19580395003)(40100003)(99286002)(64706001)(110136002)(76176999)(81156007)(97736004)(50986999)(33656002)(5003600100002)(5002640100001)(86612001)(74316001)(5005710100001)(10290500002)(54356999)(77096005)(102836002)(5007970100001)(101416001)(76576001)(10400500002)(189998001)(5004730100002)(92566002)(106356001)(10090500001)(5008740100001)(2950100001)(2900100001)(46102003)(8990500004)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0646; 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: 11 Oct 2015 23:18:05.9899 (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] SHOULD return link references to the push and receipt subscribe resources 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, 11 Oct 2015 23:18:13 -0000 DQpPbiAxMCBPY3RvYmVyIDIwMTUsIE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFp bC5jb20+IHdyb3RlOg0KDQo+IFRoZSBpZGVhIHdhcyB0byByZWR1Y2UgdGhlIHN0YXRlIGNvbW1p dG1lbnQgcmVxdWlyZW1lbnRzIG9uIHVzZXIgYWdlbnRzLiAgVGhpcyB3YXksIGEgY2xpZW50IG9u bHkgbmVlZHMgdG8gcmVtZW1iZXIgdGhlIHN1YnNjcmlwdGlvbiA+IFVSSS4gIFRoZSBzZXJ2ZXIg bmVlZHMgdG8ga25vdyB0aGUgbWFwcGluZyB0byByZWNlaXB0IGFuZCBwdXNoIHJlc291cmNlcyBm b3IgZWFjaCBzdWJzY3JpcHRpb24gYW55d2F5LCBzbyB0aGlzIHNob3VsZCBiZSB0cml2aWFsIHRv IA0KPiBpbXBsZW1lbnQuICBXaXRob3V0IGl0LCB1c2VyIGFnZW50cyBhcmUgZm9yY2VkIHRvIHJl bWVtYmVyIHRocmVlIFVSSXMgZm9yIGVhY2ggc3Vic2NyaXB0aW9uLg0KDQpVbmRlciB3aGF0IGNp cmN1bXN0YW5jZXMgd291bGQgdGhlIHVzZXIgYWdlbnQgbmVlZCB0byByZW1lbWJlciB0aGUgOnB1 c2ggYW5kIDpwdXNoOnJlY2VpcHQgVVJJcyBhZnRlciBzaGFyaW5nIHRoZW0gd2l0aCBpdHMgYXBw bGljYXRpb24gc2VydmVyPyAgSSdtIHRyeWluZyB0byB1bmRlcnN0YW5kIHRoZSBzY2VuYXJpbyB0 aGF0IG1vdGl2YXRlZCB0aGUgcmVjb21tZW5kYXRpb24uIA0KDQpUaGFua3MsDQouLi5Ccmlhbg0K From nobody Mon Oct 12 09:54:42 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 383D01A8905 for ; Mon, 12 Oct 2015 09:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSuHJQ2Z3Bpe for ; Mon, 12 Oct 2015 09:54:39 -0700 (PDT) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EDFC1A8900 for ; Mon, 12 Oct 2015 09:54:38 -0700 (PDT) Received: by ykoo7 with SMTP id o7so25352320yko.0 for ; Mon, 12 Oct 2015 09:54:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DQ0cIBEAQuZL8ejHm/esXRYYs+1Kudu9yYP1xYE9FkM=; b=OBBiFdVY2BCtKD6Z6k+bimStseIbi/DMZZaO0Dd3S6K1tc1kiTc37to/N8YSCyAQnJ xBVJNW3lQEfZRh2uZcfcU47WrDNTW9KnlJbDfGh3sBRMCZRdhnIBfldeCfNboafdD3Ds lJ5M0t/TW69E/W22PMBWJhEJv1AUZJ2dBpaYaAgA58JWAsLKTZ/GmXkBhGWxkzbDxbNe C8fXWJV87uZH5RWxCLZqAlYlqg4mSZPwSIehYjZDRPxW6Bnv3mopNN9NOBDsm3U7Krx4 dBbMvglVjiUejz5SopWqC2x7W2PI9Mdd6EJc0VwMw7DDeHiyTusnrkUaRJyGZm5a9ItI TN0Q== MIME-Version: 1.0 X-Received: by 10.129.132.80 with SMTP id u77mr20424486ywf.187.1444668877959; Mon, 12 Oct 2015 09:54:37 -0700 (PDT) Received: by 10.13.230.78 with HTTP; Mon, 12 Oct 2015 09:54:37 -0700 (PDT) In-Reply-To: References: Date: Mon, 12 Oct 2015 18:54:37 +0200 Message-ID: From: Martin Thomson To: Brian Raymor Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] SHOULD return link references to the push and receipt subscribe resources X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 16:54:41 -0000 On 12 October 2015 at 01:18, Brian Raymor wrote: > Under what circumstances would the user agent need to remember the :push and :push:receipt URIs after sharing them with its application server? I'm trying to understand the scenario that motivated the recommendation. It might want to share the subscription with new instances of the application server. In the browser case, you might imagine the application calling `getSubscription()`. That results in the :push and :push:receipt being shared again with the application. From nobody Mon Oct 12 20:12:11 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 253CC1B2F72 for ; Mon, 12 Oct 2015 20:12:11 -0700 (PDT) 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 EpemSSfOPeKm for ; Mon, 12 Oct 2015 20:12:09 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0123.outbound.protection.outlook.com [65.55.169.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A3F51B2F77 for ; Mon, 12 Oct 2015 20:12:08 -0700 (PDT) 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=p0znul9qev1GWp5WX98aCNxS6zo3hpQH7Mpf6/wFLAU=; b=WeBAuA6GP3IzlLFqYcsIeqdkC2jqhruzPzzpiwvYVASZOSSoifQaFLVCh8OniDb/UZYW6sY9M6D7ixSMUEqQIawKi4dCMK5yXH97xE/ddNMSNEbAx5yz9kUsPdMLm7HT0+ALLwjsomCp4/jMV9Yoze4jvFjKjFOk0mJiFzVO5jI= Received: from BY2PR0301MB0647.namprd03.prod.outlook.com (10.160.63.14) by BY2PR0301MB0645.namprd03.prod.outlook.com (10.160.63.13) with Microsoft SMTP Server (TLS) id 15.1.293.16; Tue, 13 Oct 2015 03:12:05 +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.0293.007; Tue, 13 Oct 2015 03:12:05 +0000 From: Brian Raymor To: "Martin Thomson (martin.thomson@gmail.com)" Thread-Topic: [Webpush] SHOULD return subscription expiration Thread-Index: AdEC1IbmOnDkKo+NR92igeTjFtuajQAXLOUAAIy80JA= Date: Tue, 13 Oct 2015 03:12:04 +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: [73.42.172.77] x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0645; 5:Sh5yC3NJbWhJr+GcxD3ZmGkEcxscRckOvK9gXUUrUNO+mPERIAE+xOfYzKTezqrmjs9HA7hP9GN+l5WsxTdl6GO7hLlTPHpdtRvRcsS4tUWDCjvmoIYXK28eQJcEAiykNOIday/fWdo8gCbmhain/Q==; 24:8tUHoROQAVMC9xx6qGE5yLBFMV0KLTU86DUT/dd9FKFfRdmSaZs7ko6Y7hQEFBC4dDNh80vx4yQq3uZ3h/vfQQ0F1vRMluHcGf6Le8v51Ts=; 20:jSM6CR0Uz70gYx5t3j8VyrbEhMf50WXBqBG0fAgqHmokfZrhyxtYy+rp3l0pwweVIdJWKYyl79dKqXRs107VtQ== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42140001); SRVR:BY2PR0301MB0645; 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)(3002001)(61426024)(61427024); SRVR:BY2PR0301MB0645; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0645; x-forefront-prvs: 07283408BE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(51444003)(189002)(199003)(24454002)(40100003)(86612001)(81156007)(10290500002)(64706001)(122556002)(5007970100001)(5004730100002)(97736004)(10090500001)(2900100001)(86362001)(2950100001)(76576001)(5001960100002)(33656002)(92566002)(189998001)(102836002)(8990500004)(50986999)(5003600100002)(15975445007)(19580395003)(110136002)(77096005)(76176999)(19580405001)(10400500002)(105586002)(46102003)(74316001)(101416001)(5005710100001)(5002640100001)(11100500001)(54356999)(106356001)(66066001)(5008740100001)(99286002)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0645; 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2015 03:12:04.8887 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0645 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] SHOULD return subscription 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, 13 Oct 2015 03:12:11 -0000 T24gT2N0b2JlciAxMCwgMjAxNSAxMjo1NyBBTSwgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9t c29uQGdtYWlsLmNvbT4gd3JvdGU6DQoNCj4gSG93ZXZlciwgYWZ0ZXIgcmV2aWV3aW5nIHRoZSBI VFRQIGNhY2hlIGNvbnRyb2wgc3R1ZmYgaW4gbW9yZSBkZXRhaWwsDQo+IEkgdGhpbmsgdGhhdCBp dCBtaWdodCBiZSBiZXN0IHRvIHJlbW92ZSB0aGlzIGZlYXR1cmUuICBUaGUgdXNlIGNhc2UNCj4g KGdyYWNlZnVsIHJlcGxhY2VtZW50IG9mIGEgc3Vic2NyaXB0aW9uKSwgbWlnaHQgYmUgaW1wb3J0 YW50LCBidXQgSQ0KPiBkb24ndCB0aGluayB0aGF0IHVzaW5nIHJlc3BvbnNlIGZyZXNobmVzcyBh cyBhIHByb3h5IGZvciBzdWJzY3JpcHRpb24NCj4gbGlmZXRpbWUgaXMgY29ycmVjdC4NCg0KU2lu Y2UgdGhlcmUgd2VyZSBubyBmdXJ0aGVyIGNvbmNlcm5zIHJhaXNlZCwgSSBzdWJtaXR0ZWQgYSBw dWxsIHJlcXVlc3QgOg0KICAgIGh0dHBzOi8vZ2l0aHViLmNvbS93ZWJwdXNoLXdnL3dlYnB1c2gt cHJvdG9jb2wvcHVsbC80Nw0KZm9yIHRoZSBkZXNpZ24gY2hhbmdlLg0K From nobody Tue Oct 13 15:10:45 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81BBE1A8FD7 for ; Tue, 13 Oct 2015 15:10:36 -0700 (PDT) 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 GJMcS0_S2roB for ; Tue, 13 Oct 2015 15:10:33 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0102.outbound.protection.outlook.com [65.55.169.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F8C01A88C7 for ; Tue, 13 Oct 2015 15:10:33 -0700 (PDT) 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=UXB0VeOtgV6eneBejel32n2jrAPECHB8UsxnGTqGRdY=; b=hOwKyfHh/9MY2TdPQrdHza/hA+TAwi0uyKtkboHdQ9xAU4K8BsjhZopxOIxPL3tBYWjjmTpnrDOz18nMoNKWRBMYTob0rBZqCWUHnn5F47bF1Vz3uVxKRxHnscPw6HhRJlgQw1Iypd7P3RyBwIOrzrH4nsUOf6Q4iy4Xb34+g1A= 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.293.16; Tue, 13 Oct 2015 22:10:07 +0000 Received: from BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) by BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) with mapi id 15.01.0293.007; Tue, 13 Oct 2015 22:10:07 +0000 From: Brian Raymor To: "webpush@ietf.org" Thread-Topic: Message expiration (TTL) and Negative Acknowledgements Thread-Index: AdEGA6AApJ25A8bWSta9W/kXIcP8NQ== Date: Tue, 13 Oct 2015 22:10:07 +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: [2001:4898:80e8::676] x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0646; 5:ZXe8fR2S2XgjaZi27hfX2IAbr0+XZ/CxGoEkfXhMtNz7+Oz1OeZZz0WcLOrkDGdK0KwgMIxdJCtxFe7DeLc7AGWM0pPrIiuEXufne6k9eMGO3sGQLZNt3S8PkgkTky04V+wwZQuaidj2y6z5gEwEqw==; 24:xUrPxk6xP/OXtx0CxAyTqHDQu7LgLk4TG918+hV5FDhJwp6nEOVsyq4RqyIqIANIRGIsyXpjhNmrWXdy/0I5nXJMT3o2+XA6jimyVsYtVho=; 20:G+Dzgl3wf4PFR+/uaYw6gDKrwnMeIUYLXD7z/aTA4LSt/eaB6YFCB5EhVHa5KLHu9f7/0tjt1+jTN6r8RTc0kg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0301MB0646; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(61426024)(61427024); SRVR:BY2PR0301MB0646; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0646; x-forefront-prvs: 07283408BE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(86612001)(50986999)(54356999)(106356001)(86362001)(74316001)(46102003)(105586002)(64706001)(33656002)(92566002)(101416001)(2900100001)(77096005)(15975445007)(87936001)(5002640100001)(102836002)(99286002)(5003600100002)(19580395003)(110136002)(5001960100002)(10400500002)(5005710100001)(107886002)(8990500004)(2501003)(122556002)(10290500002)(189998001)(76576001)(40100003)(5008740100001)(229853001)(5004730100002)(5001920100001)(2351001)(81156007)(5007970100001)(450100001)(11100500001)(10090500001)(97736004)(3826002); 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: 13 Oct 2015 22:10:07.7572 (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: Subject: [Webpush] Message expiration (TTL) and Negative Acknowledgements X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 22:10:36 -0000 At IETF 93, we agreed to limit negative acknowledgements to message deliver= y failures and not message expiration: https://github.com/webpush-wg/webpush-protocol/issues/17 The thought was that the application server can maintain its own clock for = the message expiration based on the TTL exchange where the application serv= er requests a TTL and the push server is allowed to "advertise" a shorter T= TL: Section 6: A push service MAY choose to retain a push message for a shorter duration than that requested. It indicates this by including a TTL header field in the response that includes the actual TTL. This TTL value MUST be less than or equal to the value provided by the application server. I was finishing up my editorial changes and noticed one potential exception= . In Section 7.2, we have some operations guidance: Push services might need to limit the size and number of stored push messages to avoid overloading. In addition to using the 413 (Payload Too Large) status code for too large push messages, a push service MAY expire push messages prior to any advertised expiration time. A push service can reduce the impact [of] push message retention by reduci= ng the time-to-live of push messages. This would be a case where the application server should still receive a ne= gative acknowledgement for expiration because it has no awareness that the = push server could not honor its advertised TTL. It's closer to the failure= case where a push server ceases to retry delivery of a message prior to it= s expiration perhaps due to an unresponsive user agent. Comments? ...Brian From nobody Tue Oct 13 15:14: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 EBCD91A90A5 for ; Tue, 13 Oct 2015 15:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPqj75InxuMj for ; Tue, 13 Oct 2015 15:14:19 -0700 (PDT) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC9161A90A2 for ; Tue, 13 Oct 2015 15:14:19 -0700 (PDT) Received: by ykaz22 with SMTP id z22so5295622yka.2 for ; Tue, 13 Oct 2015 15:14:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=0+qiDgH4fERGln5XD/SFgIxfrL3zQvezEIet/ufmlNM=; b=xK535KYHEeMMTy/HScReM95SSoEr/RSOqsec6RfIQvcUKKR6vq+xyF105bSCf+HvtD Un0rn/+Rel7ua8rVRS3F6GyDfQeY/+tyZ1TNFgEIhBVSDHZcLi9vTInMd3OXHVFH+eLC QbjcRv2DgYWRsDWU5t1TDwAjYBTvpUnrma3QOw/APwCW5goCIQ86zLPg4TtXgM0CjyTU jnJtyyXS2pXNcHJrBNNwO8ItBurgMf4O2Ajsi9HcjMiJK2nGUjB3tRrYGPgWXW5sBQ15 dFplm0WxNtqwm5NpxfkDj8NHGWA/kfdmENIz3rzgbUGPIXMvrc/C/T5AW25XtgWmCt4K u2Zw== MIME-Version: 1.0 X-Received: by 10.129.55.22 with SMTP id e22mr145693ywa.120.1444774458932; Tue, 13 Oct 2015 15:14:18 -0700 (PDT) Received: by 10.13.230.78 with HTTP; Tue, 13 Oct 2015 15:14:18 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Oct 2015 15:14:18 -0700 Message-ID: From: Martin Thomson To: Brian Raymor Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Message expiration (TTL) and Negative Acknowledgements X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 22:14:21 -0000 On 13 October 2015 at 15:10, Brian Raymor wrot= e: > > This would be a case where the application server should still receive a = negative acknowledgement for expiration because it has no awareness that th= e push server could not honor its advertised TTL. It's closer to the failu= re case where a push server ceases to retry delivery of a message prior to = its expiration perhaps due to an unresponsive user agent. This doesn't need to be reported any differently from the case where the push service tried 10 times and gave up. From nobody Tue Oct 13 15:32: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 2A91E1A1B0E for ; Tue, 13 Oct 2015 15:32:08 -0700 (PDT) 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 AXeef_cUtDIM for ; Tue, 13 Oct 2015 15:32:03 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0111.outbound.protection.outlook.com [207.46.100.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 486F41A1AAE for ; Tue, 13 Oct 2015 15:32:03 -0700 (PDT) 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=CRPc/6hZszxaSHuzZXLVAL07Hw6ewfgMOlS4VlaabGw=; b=mUWmthm+vdY+JPhN6NS1aPxhlZXazOdCGa/B+hwDKiZNWqgLnZskD85dlDufq0hd/7JkOD+P91b/9GS6LkMsQ1UvSxaL1bNoJAWbm+34UEdwEsbhP/m8aZXFdmP4uZ1QGSckBgC1dQ7LTGWhpXNgMX2cmqSpakj82CG4Jo8QVE4= 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.293.16; Tue, 13 Oct 2015 22:32:01 +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.0293.007; Tue, 13 Oct 2015 22:32:01 +0000 From: Brian Raymor To: "Martin Thomson (martin.thomson@gmail.com)" Thread-Topic: [Webpush] Message expiration (TTL) and Negative Acknowledgements Thread-Index: AdEGA6AApJ25A8bWSta9W/kXIcP8NQAAOC8AAABNKHA= Date: Tue, 13 Oct 2015 22:32:01 +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: [2001:4898:80e8::676] x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0647; 5:faGll6R5GtOO3oU/X8VijnC6PFSuUyE6USNk8eA1vDNl4BArfrd2VGzBTI1JaGC1BCVu5KAlYTEQPCJg3E7Tjvigj+ZLVYLV5M6KXFxS9mGtIVNJ593RV8QjCOAVuvczclVqySYEjjs8AyJ3OcZMJw==; 24:8vrXbF0Ik/tyGni4bTFwKfPuteRtaenNjQHZfqw1ejFY3Y/c3Xj3DbhyNoU5f4PLkvEPrer/T/0iFnwyfEah/8+DclgHUkpRiEIyqJLK2jk=; 20:m1vu+Dh1eKGyDul7DHz9cRr4LyBA1Yu0+bLUNpv/4Xr1Ls6cdc4fX+NEE/E4wXSY9V4EXPbKcemK07ugl+JFrA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;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)(520078)(5005006)(8121501046)(3002001)(61426024)(61427024); SRVR:BY2PR0301MB0647; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0647; x-forefront-prvs: 07283408BE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(24454002)(377454003)(199003)(189002)(8990500004)(5007970100001)(86612001)(19580395003)(33656002)(64706001)(54356999)(81156007)(10290500002)(92566002)(86362001)(101416001)(74316001)(102836002)(10090500001)(87936001)(2950100001)(5005710100001)(50986999)(99286002)(76176999)(77096005)(2900100001)(97736004)(5008740100001)(105586002)(76576001)(19580405001)(40100003)(5003600100002)(5001960100002)(5004730100002)(189998001)(110136002)(10400500002)(106356001)(11100500001)(122556002)(5002640100001)(46102003)(3826002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0647; 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: 13 Oct 2015 22:32:01.2114 (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] Message expiration (TTL) and Negative Acknowledgements X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 22:32:08 -0000 T24gT2N0b2JlciAxMyAyMDE1IGF0IDM6MTQgUE0sIE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhv bXNvbkBnbWFpbC5jb20+IHdyb3RlOg0KDQo+IA0KPiBPbiAxMyBPY3RvYmVyIDIwMTUgYXQgMTU6 MTAsIEJyaWFuIFJheW1vciA8QnJpYW4uUmF5bW9yQG1pY3Jvc29mdC5jb20+DQo+IHdyb3RlOg0K PiA+DQo+ID4gVGhpcyB3b3VsZCBiZSBhIGNhc2Ugd2hlcmUgdGhlIGFwcGxpY2F0aW9uIHNlcnZl ciBzaG91bGQgc3RpbGwgcmVjZWl2ZSBhDQo+IG5lZ2F0aXZlIGFja25vd2xlZGdlbWVudCBmb3Ig ZXhwaXJhdGlvbiBiZWNhdXNlIGl0IGhhcyBubyBhd2FyZW5lc3MgdGhhdA0KPiB0aGUgcHVzaCBz ZXJ2ZXIgY291bGQgbm90IGhvbm9yIGl0cyBhZHZlcnRpc2VkIFRUTC4gIEl0J3MgY2xvc2VyIHRv IHRoZSBmYWlsdXJlDQo+IGNhc2Ugd2hlcmUgYSBwdXNoIHNlcnZlciBjZWFzZXMgdG8gcmV0cnkg ZGVsaXZlcnkgb2YgYSBtZXNzYWdlIHByaW9yIHRvIGl0cw0KPiBleHBpcmF0aW9uIHBlcmhhcHMg ZHVlIHRvIGFuIHVucmVzcG9uc2l2ZSB1c2VyIGFnZW50Lg0KPiANCj4gVGhpcyBkb2Vzbid0IG5l ZWQgdG8gYmUgcmVwb3J0ZWQgYW55IGRpZmZlcmVudGx5IGZyb20gdGhlIGNhc2Ugd2hlcmUNCj4g dGhlIHB1c2ggc2VydmljZSB0cmllZCAxMCB0aW1lcyBhbmQgZ2F2ZSB1cC4NCg0KVGhlbiwgd2Un cmUgaW4gYWdyZWVtZW50LiBXaGVuIGEgcmVjZWlwdCBpcyByZXF1ZXN0ZWQsIHRoZSBzYW1lIDV4 eCBzdGF0dXMgY29kZSBpcyByZXR1cm5lZCBmb3IgZWl0aGVyIGdpdmluZyB1cCBwcmlvciB0byB0 aGUgb3JpZ2luYWwgZXhwaXJhdGlvbiBvciBsb3dlcmluZyB0aGUgYWR2ZXJ0aXNlZCBtZXNzYWdl IGV4cGlyYXRpb24gYW5kIGZhaWxpbmcgdG8gZGVsaXZlci4NCg== From nobody Tue Oct 13 16:10: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 B819D1A8AD9 for ; Tue, 13 Oct 2015 16:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0Sk_vzrYKFm for ; Tue, 13 Oct 2015 16:10:09 -0700 (PDT) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::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 A0B7C1A8AD3 for ; Tue, 13 Oct 2015 16:10:09 -0700 (PDT) Received: by ykaz22 with SMTP id z22so6302206yka.2 for ; Tue, 13 Oct 2015 16:10:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EHIvfLDQKcW1pAjStyynp6gswPUXrbhd+f2cf7JeGXU=; b=nvX3mFQWnnsrUhUt7mWx6F1iIvQLappSPeLA7xUCK7rGh8GtThnXpfOjtLzOnrpxk6 msjh5wcANi3Kht3XhKHP8MXjJc2sZysbryCagafcMbrxqFmu3brYntS9MfwZ6HN7muak +S6XeHdFZYZLHdgenuCUuK7Dywk/7s7SFZ9q+KMKiZgqsL+Zh7/CXZYpe8+3HAfy36Sm IMmMQKndwMk57OCOymQkgG/HAZKj7sHC2j65E57uPCL0wKcyM+gii4SNb9ThNPuThgGa PJZdNLXLXJOk1UeBl3AhsHMQPd1w+9n1L+P8m1CBoRcP8H948LSPu16TWnPu/9lGZ7O5 ASlA== MIME-Version: 1.0 X-Received: by 10.129.132.80 with SMTP id u77mr25689834ywf.187.1444777808958; Tue, 13 Oct 2015 16:10:08 -0700 (PDT) Received: by 10.13.230.78 with HTTP; Tue, 13 Oct 2015 16:10:08 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Oct 2015 16:10:08 -0700 Message-ID: From: Martin Thomson To: Brian Raymor Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Message expiration (TTL) and Negative Acknowledgements X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 23:10:14 -0000 On 13 October 2015 at 15:32, Brian Raymor wrote: > Then, we're in agreement. When a receipt is requested, the same 5xx status code is returned for either giving up prior to the original expiration or lowering the advertised message expiration and failing to deliver. WFM. Now, if only we could decide on what that 5xx might be (or was your intent to follow-up with a mail on that subject.) From nobody Tue Oct 13 16:39:23 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 3D7B61A90B7 for ; Tue, 13 Oct 2015 16:39:22 -0700 (PDT) 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 oPxIIx1U-YYE for ; Tue, 13 Oct 2015 16:39:20 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0136.outbound.protection.outlook.com [65.55.169.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B0921A90B4 for ; Tue, 13 Oct 2015 16:39:19 -0700 (PDT) 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=O6HD58rmZBGeCYykG/TQ1YWBtueItPwvWYLaTHasRX0=; b=eQ+oQhUkSkwXv6xB7KTgPRqepX72kpNRTt7SEVK9yKyjzrG1n2IKg7ecxKzVQS5+9hRD16f0OFWLlmkHKaFBjikBLEP9oSGtRiSNY1t5VLq/oGTNDLY8gSHRngQW85knbVrKiRn6JxOwQU/6nE67mo7VUhkVKiHJXMlnnRIn3Ok= 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.293.16; Tue, 13 Oct 2015 23:39:16 +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.0293.007; Tue, 13 Oct 2015 23:39:16 +0000 From: Brian Raymor To: "Martin Thomson (martin.thomson@gmail.com)" Thread-Topic: [Webpush] Message expiration (TTL) and Negative Acknowledgements Thread-Index: AdEGA6AApJ25A8bWSta9W/kXIcP8NQAAOC8AAABNKHAAAaYIAAAAW6Ug Date: Tue, 13 Oct 2015 23:39:15 +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: [2001:4898:80e8::676] x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0648; 5:8u99kQ2fKZs5sbJL0g3qXeyMoyahl70Af1ryVfKmzay2p8wnjUjSCCJ6Avl0RqbOOfVh35O0taUxOa1ljbgQOCvjTqtp5qKWnjkoUacLyo4+s9b4pJT35Iocan8Y5X8SgjsCHkjq1Tsvp+HKJemoQQ==; 24:F4Jt7igsfS8alZ96hGxjBdOBqx5TPcRIoedLFTFG53imvGXRyfgxLpXr2kJhBGBfJCqiyRhZpq6l3Hr3YJRY7N6YSR6rmk9pqF8dZx9GzwQ=; 20:2wgqLflg8rcqV0zL0jr5XU3hsgqLoJXGhAOml0bqJkQgNPJHXeTp4OkwXuzqGGQYDwn0I8/2kzk8O8MpUFh32w== 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)(61426024)(61427024); SRVR:BY2PR0301MB0648; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0648; x-forefront-prvs: 07283408BE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(377454003)(31014005)(24454002)(189002)(54356999)(50986999)(76176999)(97736004)(33656002)(101416001)(86612001)(86362001)(5008740100001)(5003600100002)(5002640100001)(64706001)(87936001)(81156007)(2950100001)(5007970100001)(76576001)(110136002)(5004730100002)(189998001)(5001960100002)(2900100001)(8990500004)(10290500002)(10400500002)(5005710100001)(92566002)(11100500001)(10090500001)(46102003)(77096005)(99286002)(15975445007)(102836002)(93886004)(40100003)(19580395003)(19580405001)(106356001)(105586002)(122556002)(74316001)(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: 13 Oct 2015 23:39:15.9232 (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] Message expiration (TTL) and Negative Acknowledgements X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 23:39:22 -0000 T24gT2N0b2JlciAxMyAyMDE1IGF0IDQ6MTAgUE0sIE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhv bXNvbkBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gV0ZNLiAgTm93LCBpZiBvbmx5IHdlIGNvdWxk IGRlY2lkZSBvbiB3aGF0IHRoYXQgNXh4IG1pZ2h0IGJlIChvciB3YXMNCj4geW91ciBpbnRlbnQg dG8gZm9sbG93LXVwIHdpdGggYSBtYWlsIG9uIHRoYXQgc3ViamVjdC4pDQoNCk5leHQgb24gbXkg bGlzdCAuLi4NCg0KSSd2ZSBjcmVhdGVkIGEgcHVsbCByZXF1ZXN0IC0gaHR0cHM6Ly9naXRodWIu Y29tL3dlYnB1c2gtd2cvd2VicHVzaC1wcm90b2NvbC9wdWxsLzQ4IC0gdG8gYWRkcmVzczoNCg0K aHR0cHM6Ly9naXRodWIuY29tL3dlYnB1c2gtd2cvd2VicHVzaC1wcm90b2NvbC9pc3N1ZXMvMTcN Cmh0dHBzOi8vZ2l0aHViLmNvbS93ZWJwdXNoLXdnL3dlYnB1c2gtcHJvdG9jb2wvaXNzdWVzLzE4 DQoNCkkndmUgc2VwYXJhdGVkIHRoZSA1WFggc3RhdHVzIGNvZGUgaW50byBhIG5ldyBpc3N1ZSAt IGh0dHBzOi8vZ2l0aHViLmNvbS93ZWJwdXNoLXdnL3dlYnB1c2gtcHJvdG9jb2wvaXNzdWVzLzQ5 DQoNCi4uLkJyaWFuDQo= From nobody Wed Oct 14 14:09:17 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 018A61A8937 for ; Wed, 14 Oct 2015 14:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvCr2bghfNFf for ; Wed, 14 Oct 2015 14:09:12 -0700 (PDT) Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) (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 BA2581A8930 for ; Wed, 14 Oct 2015 14:09:12 -0700 (PDT) Received: by pabws5 with SMTP id ws5so637775pab.3 for ; Wed, 14 Oct 2015 14:09:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=fIdYiBMbf0sAw1RaGpwPA7QWy91jQReDCzcuSgFGp2E=; b=eETfFDrdQ2TRrTIzYPbD96udtO91ZhbKpikjOOaXzJ2A50Rq3wDVOcdvgcwFaxaGpc 2Q7YNojpi0/rE5M+RG2+ODMJHSoytMib7xhopl8Go88qAb/T0PxbHxvPQv8xwbFVys1q HSIyXzPIL1iVE/+fIOerDlVOJu5t+98kAMkCbFoYJrnZtxML9JUOgmGHNQh4gYwoMs5M DSPWCv/6velT+GB3WQXRiVBXDPGw6R7kaVk/EJgSHP+XAZbt928QhfVY/O4HFnbvGRqz L029upsWSZ2RRpjfnKjbCsyTXuna28pTB2aRR9QXMi/CS0Q+Yi7HpsvzVJIliHqMCYwJ ymoA== X-Gm-Message-State: ALoCoQmzVErB4wIs8fmKr0/uG2TlvkGVC0EVL80VIxgcwpntEHmPlExd38WjLvw1MP8pTXNSN3FO X-Received: by 10.67.4.9 with SMTP id ca9mr5782909pad.90.1444856952102; Wed, 14 Oct 2015 14:09:12 -0700 (PDT) Received: from ?IPv6:2620:101:80fb:224:f03b:fcb1:9736:dcd6? ([2620:101:80fb:224:f03b:fcb1:9736:dcd6]) by smtp.gmail.com with ESMTPSA id sv9sm11324408pbc.44.2015.10.14.14.09.11 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 14 Oct 2015 14:09:11 -0700 (PDT) From: JR Conlin X-Google-Original-From: JR Conlin To: webpush@ietf.org References: X-Enigmail-Draft-Status: N1110 Organization: mozilla Message-ID: <561EC47C.4090803@mozilla.com> Date: Wed, 14 Oct 2015 14:09:16 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:43.0) Gecko/20100101 Thunderbird/43.0a2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Webpush] Message expiration (TTL) and Negative Acknowledgements X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 21:09:16 -0000 I'm not sure if this relates, but there are a few implementation status codes that might be useful. We've seen the following sorts of situations arise and it would be good to have developers aware of them. 301 & 307: The resource has either moved permanently or temporarily. (This may occur if a service in maintenance or if a service was shut down and traffic needs to be reallocated.) In the case of a 301 response, all future traffic should be permanently routed to the new host. 429: This will allow the server to apply "back pressure" to the application service in cases where there may be too many incoming messages in a short period of time. This response would carry a RETRY-AFTER response header indicating the number of seconds that should elapse before the remote server should retry transmission of the message. On 10/13/2015 4:10 PM, Martin Thomson wrote: > On 13 October 2015 at 15:32, Brian Raymor wrote: >> Then, we're in agreement. When a receipt is requested, the same 5xx status code is returned for either giving up prior to the original expiration or lowering the advertised message expiration and failing to deliver. > WFM. Now, if only we could decide on what that 5xx might be (or was > your intent to follow-up with a mail on that subject.) > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush From nobody Wed Oct 14 14:37: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 1562C1A8A20 for ; Wed, 14 Oct 2015 14:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQd434g3zanL for ; Wed, 14 Oct 2015 14:37:57 -0700 (PDT) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E19D1A8A25 for ; Wed, 14 Oct 2015 14:37:51 -0700 (PDT) Received: by ykaz22 with SMTP id z22so34913361yka.2 for ; Wed, 14 Oct 2015 14:37:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XxkpXwQy7VMqikJapvAHU8QDRXc6WlKu6hCtj/5SoZg=; b=fELgz0TAuCb7yQnr0RBhrqU1PEX84h5jYZ46+D16hUCb3ABKqRh1Ysvy7kuskFU37N /qRJnIg5zLVZGTfUDh9h9EN7vK+fvVu1LquHM+/Fw1GutGjh3sQfUhRGhyoDX3zksSjM LCHWbNojTnjNPjvF/CSD8/m79/pnpoIgbhFRv1EG4LN3KcGJ/USPaRJym16hYh1g5J34 dUReUUv53TKEUgCWIj3mBb26sqWFFIViAH74r2u1eWHLeOUkhUvdV6TNSqVMxM+8zATc YMAyynhHx88uJfLS1V6WNzjqHaTby05EoW6UtA6UfK/EfJUT57WXBVUC0i8sCnOlTzrE Dbig== MIME-Version: 1.0 X-Received: by 10.13.255.194 with SMTP id p185mr4436991ywf.207.1444858670348; Wed, 14 Oct 2015 14:37:50 -0700 (PDT) Received: by 10.13.230.78 with HTTP; Wed, 14 Oct 2015 14:37:50 -0700 (PDT) In-Reply-To: <561EC47C.4090803@mozilla.com> References: <561EC47C.4090803@mozilla.com> Date: Wed, 14 Oct 2015 14:37:50 -0700 Message-ID: From: Martin Thomson To: JR Conlin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Message expiration (TTL) and Negative Acknowledgements X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 21:37:58 -0000 On 14 October 2015 at 14:09, JR Conlin wrote: > 429: This will allow the server to apply "back pressure" to the > application service in cases where there may be too many incoming > messages in a short period of time. This response would carry a > RETRY-AFTER response header indicating the number of seconds that should > elapse before the remote server should retry transmission of the message. How is that different from 503? From nobody Wed Oct 14 15:02: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 7A3AB1A896E for ; Wed, 14 Oct 2015 15:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7nKc8Lv7GVH for ; Wed, 14 Oct 2015 15:02:47 -0700 (PDT) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) (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 F034C1A049A for ; Wed, 14 Oct 2015 15:02:44 -0700 (PDT) Received: by pabrc13 with SMTP id rc13so65741146pab.0 for ; Wed, 14 Oct 2015 15:02:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=IOmtuR2B6/AiOeHn8/+UPDuTRJvd0FS7C6I0WFQguwE=; b=CLAdOyse9Vvka4QPsCfkYvOz2tYxpcedQGP2G+EKJlNYDIjL8Jiee2wmnD6yqZdoNi PFDC3a1WiB2FjzsA/DvwnwYn6AYGnCLbQZVTQE70zwuCgMWNDO43zQ1YWvIqtjJliRAu XaiAmZ9Wq79b6CbeVR/c4AqZqREYn7a7soC0U0f4rbweOQShtP7Mt5f4JfjWHK8o8PMg 0lHmAjmb+aUdILw22N0YD8EY6KFt2ewDh4fpbGN+TadRlSj6K8LtH/m3m78pha5wZlDB Jyk8tr6vcIanyTAGMoBBo8DYKgzMRgbxDHrZ9/MZ9enrpSduLuHggfsL/PBk2E1Y1Tq5 JPYA== X-Gm-Message-State: ALoCoQkhXPtTH+hlgIZM0zTxpaGMSeKFzhIG91CBrPvdOvEctenaSS9b6AsF07ogb5ixJS/Nhcmc X-Received: by 10.69.26.101 with SMTP id ix5mr5929265pbd.144.1444860163543; Wed, 14 Oct 2015 15:02:43 -0700 (PDT) Received: from ?IPv6:2620:101:80fb:224:f03b:fcb1:9736:dcd6? ([2620:101:80fb:224:f03b:fcb1:9736:dcd6]) by smtp.gmail.com with ESMTPSA id qn5sm11512309pac.41.2015.10.14.15.02.42 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Oct 2015 15:02:42 -0700 (PDT) To: Martin Thomson References: <561EC47C.4090803@mozilla.com> From: jr conlin X-Enigmail-Draft-Status: N1110 Message-ID: <561ED106.8030806@mozilla.com> Date: Wed, 14 Oct 2015 15:02:46 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:43.0) Gecko/20100101 Thunderbird/43.0a2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Message expiration (TTL) and Negative Acknowledgements X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 22:02:55 -0000 On 10/14/2015 2:37 PM, Martin Thomson wrote: > On 14 October 2015 at 14:09, JR Conlin wrote: >> 429: This will allow the server to apply "back pressure" to the >> application service in cases where there may be too many incoming >> messages in a short period of time. This response would carry a >> RETRY-AFTER response header indicating the number of seconds that should >> elapse before the remote server should retry transmission of the message. > > How is that different from 503? Traditionally (as if that's a thing for the web) 503 tends to be used by intermediary services like load balancers to indicate that "something's amiss with the box I normally talk to". Since it's a 500 class error, it indicates an error state possibly from outside the server. 429 was identified as part of https://tools.ietf.org/html/rfc6585 to be used more as a rate limiter and carries with it the "Retry-After" response header indicating how long the requester should wait before retry. It's a 400 class error, which means it should come from the responding server. Either would work, of course, but it may be that programmers can take advantage of pre-existing handlers in libraries to do the back-off for them, rather than have to code the response themselves. From nobody Wed Oct 14 20:15:26 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 648E21B2F75 for ; Wed, 14 Oct 2015 20:15:25 -0700 (PDT) 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 3Gk9AEsZs1IX for ; Wed, 14 Oct 2015 20:15:24 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0125.outbound.protection.outlook.com [65.55.169.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 659501B2F74 for ; Wed, 14 Oct 2015 20:15:22 -0700 (PDT) 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=BX+UxF5rBTmMO69cfGNPDzEBTkGXeCUlp+rDIYL5rbI=; b=hAtdvpPAQyqED36ye2In1m9Lv7Oo4rlufRxseGSTFUi6jGpbiBy3/PqjqmxwzgcQ2njrO4odRYZ1ix88VB5K0Nqcxv3gi4oAsgvcabRPeFbYsqHVlduESsgMs/ECIo2NP1uW6hE3vwpNRTnzGuytZsGXDBKzoa+nzSg6MwQSvGM= 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.293.16; Thu, 15 Oct 2015 03:15:19 +0000 Received: from BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) by BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) with mapi id 15.01.0293.007; Thu, 15 Oct 2015 03:15:19 +0000 From: Brian Raymor To: "webpush@ietf.org" Thread-Topic: Status Code for Negative Acknowledgements #49 Thread-Index: AdEG9sQd5oxkv1u9Tbuu6yssrGPvWQ== Date: Thu, 15 Oct 2015 03:15:18 +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:3415:f9a5:2f9b:7ea4] x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0646; 5:3E3i6YslzhsqF1HdgXR1UdJOVCtnyhxnzblWto+zYUDcfB/ygjJCTHh/andEg8kjiZUdAcA3epecFKkdUpoTvE7e39vFi/vMLST2TwkRSf5VNqRpyUsaHg87wEEMm2KwevS9EBMKGIbijyjGEsocRg==; 24:mnfJRYU2ZrRRqMwx68nRcoBhYFpDReuPmto4dv6XynTlLg8AiDL5Kqy3W0ofpJWBkFF+windF7mJd9O2D2yZdOmEdqwAJ0RqnkUQRUgPl4k=; 20:zd7EW0QUzauXF1U0Mbr2k14q9of9LVA9pmskvquWGVgWIR8a0O8Xrn31j3jeBZuioBFv259d1zq4IrYqDYqHZA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0301MB0646; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(61426024)(61427024); SRVR:BY2PR0301MB0646; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0646; x-forefront-prvs: 0730093765 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(87936001)(74316001)(54356999)(86612001)(86362001)(46102003)(50986999)(105586002)(92566002)(33656002)(64706001)(106356001)(101416001)(15975445007)(99286002)(77096005)(5002640100001)(102836002)(2900100001)(5003600100002)(97736004)(189998001)(5008740100001)(10290500002)(107886002)(122556002)(76576001)(10400500002)(5005710100001)(8990500004)(5001960100002)(2501003)(110136002)(40100003)(2351001)(81156007)(10090500001)(5004730100002)(229853001)(11100500001)(5007970100001)(5001920100001)(19580395003)(450100001)(3826002); 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: 15 Oct 2015 03:15:18.9320 (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: Subject: [Webpush] Status Code for Negative Acknowledgements #49 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 03:15:25 -0000 For - https://github.com/webpush-wg/webpush-protocol/issues/49 - I've submi= tted a pull request to propose a 512 (Expired Resource) status code - https= ://github.com/webpush-wg/webpush-protocol/pull/50 Based on the Hypertext Transfer Protocol (HTTP) Status Code Registry - htt= p://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml - 50= 9 is the next unassigned 5XX status code, but there may be a conflict with = unregistered use of 509: https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#5xx_Server_Error 509 Bandwidth Limit Exceeded (Apache bw/limited extension) This status code is not specified in any RFCs. Its use is unknown. 510 and 511 are registered, skipping 509 which suggests an earlier attempt = to avoid potential conflicts.=20 ...Brian From nobody Wed Oct 14 20:30:41 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 665EE1B2FB2 for ; Wed, 14 Oct 2015 20:30:39 -0700 (PDT) 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 upAgiai48ug5 for ; Wed, 14 Oct 2015 20:30:37 -0700 (PDT) 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 30E5D1B2FAC for ; Wed, 14 Oct 2015 20:30:37 -0700 (PDT) Received: from [192.168.0.18] (unknown [120.149.147.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 95E8522E1F4 for ; Wed, 14 Oct 2015 23:30:33 -0400 (EDT) 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: Thu, 15 Oct 2015 14:30:30 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "webpush@ietf.org" X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [Webpush] Status Code for Negative Acknowledgements #49 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 03:30:39 -0000 [BCC'ing the HTTP WG] 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 I'm especially concerned about suggestions in the issue to allocate "a = range of status codes" for this purpose.=20 I strongly suspect you don't need a status code, in that the semantics = you're surfacing don't need to be available to HTTP implementations = (e.g., generic servers and clients, intermediaries, caches). You have a = very constrained use case and control over the payload; why can't this = be a header or part of the body? Cheers, > On 15 Oct 2015, at 2:15 pm, Brian Raymor = wrote: >=20 >=20 > For - https://github.com/webpush-wg/webpush-protocol/issues/49 - I've = submitted a pull request to propose a 512 (Expired Resource) status code = - https://github.com/webpush-wg/webpush-protocol/pull/50 >=20 > Based on the Hypertext Transfer Protocol (HTTP) Status Code Registry - = = http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml = - 509 is the next unassigned 5XX status code, but there may be a = conflict with unregistered use of 509: >=20 > = https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#5xx_Server_Error >=20 > 509 Bandwidth Limit Exceeded (Apache bw/limited extension) > This status code is not specified in any RFCs. Its use is unknown. >=20 > 510 and 511 are registered, skipping 509 which suggests an earlier = attempt to avoid potential conflicts.=20 >=20 >=20 >=20 >=20 >=20 >=20 > ...Brian >=20 >=20 > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush -- Mark Nottingham https://www.mnot.net/ From nobody Wed Oct 14 21:45:13 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEECA1B303D for ; Wed, 14 Oct 2015 21:45:11 -0700 (PDT) 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 EMmHJtlu5Hz0 for ; Wed, 14 Oct 2015 21:45:08 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0707.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::707]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF5651B303F for ; Wed, 14 Oct 2015 21:45:06 -0700 (PDT) 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=iCv9dyTMcxB+ECNgNBN6IA/0y50tdGV7V74zbIC4a10=; b=NKKdwY3wHhgudy93z6q6hDH1qHh9bZTnkaSVBnIEd3X6/jnFxClrgfv2R7vn2QEzn1Uj5n/rWHE2zik5zuUV8mFjGMRCWBRrA7wG3erUrUnP/HwPb78vYx+8zdE1VPtYd4smFcBRnCB5BLrIiiRDw/yUcGSR6hmKm6ltKFiEJa0= Received: from BY2PR0301MB0647.namprd03.prod.outlook.com (10.160.63.14) by BY2PR0301MB0645.namprd03.prod.outlook.com (10.160.63.13) with Microsoft SMTP Server (TLS) id 15.1.293.16; Thu, 15 Oct 2015 04:45:01 +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.0293.007; Thu, 15 Oct 2015 04:45:01 +0000 From: Brian Raymor To: Mark Nottingham Thread-Topic: [Webpush] Status Code for Negative Acknowledgements #49 Thread-Index: AdEG9sQd5oxkv1u9Tbuu6yssrGPvWQAAxM4AAAFyNyA= Date: Thu, 15 Oct 2015 04:45:01 +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: [73.42.172.77] x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0645; 5:d/iqE50RuE5Huw4NmW8bWEuNzxArsy1CsAmXFadXc1sDhyjksRDphFJ/6MRQr8P1wsU7vIm+7A7lDFr/6KaZsU/TT4BcHtvCr7J4658Wsrz2wfGYNcvAuFoV29q0QNEcslSA2+YkZ88VQnz9EdsqOg==; 24:cNsKl3BWMc02KRCfmVxDvEb19iMuvi6kMVMApPhB4USBJMfvtZujRjN0NLKX8Fa20lbPGqUtUy5yD/w3LiYt+yxeHko8jsj5T/D6yTcyfUU=; 20:tZBh0B02Dk7p3CflFMepw7VeokykV0kXRKRB14N/LVtl9mR4TNkRXUSSG6lS6wbVR8ekapyzDPk5+zigoXIJmw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0301MB0645; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(8121501046)(5005006)(520078)(3002001)(61426024)(61427024); SRVR:BY2PR0301MB0645; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0645; x-forefront-prvs: 0730093765 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(377454003)(199003)(189002)(24454002)(10290500002)(561944003)(40100003)(50986999)(189998001)(19580395003)(122556002)(5007970100001)(81156007)(64706001)(97736004)(110136002)(2900100001)(33656002)(15975445007)(77096005)(86362001)(2950100001)(86612001)(92566002)(10090500001)(5004730100002)(5003600100002)(8990500004)(76176999)(5001960100002)(102836002)(5002640100001)(105586002)(46102003)(101416001)(5005710100001)(76576001)(106356001)(11100500001)(54356999)(99286002)(19580405001)(74316001)(5008740100001)(66066001)(10400500002)(87936001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0645; 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2015 04:45:01.2952 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0645 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Status Code for Negative Acknowledgements #49 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 04:45:12 -0000 On October 14 2015 at 8:31 PM, Mark Nottingham wrote: > I'm especially concerned about suggestions in the issue to allocate "a ra= nge of > status codes" for this purpose. Let me clarify. There are two issues: https://github.com/webpush-wg/webpush-protocol/issues/49 (Status Code for N= egative Acknowledgements) is related to the proposal for the 512 status cod= e under discussion. https://github.com/webpush-wg/webpush-protocol/issues/42 (Acknowledgement '= status codes') is the source of the confusion about "a range of status code= s"? I completely agree that the title (even with those single quotes) is mi= sleading. The intent is to NOT use HTTP status codes to return information = for this scenario. If developed further, it will probably need to be a head= er field since it's passed in a DELETE. (It's closer in nature to the opaqu= e diagnostic data that can be included in a HTTP/2 GOAWAY.) I've clarified = the title and text in the issue to reflect our true intentions. From nobody Wed Oct 14 22:01:06 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9241B2B2E for ; Wed, 14 Oct 2015 22:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KLN-R6oyMwN for ; Wed, 14 Oct 2015 22:01:03 -0700 (PDT) Received: from gator4135.hostgator.com (gator4135.hostgator.com [192.185.4.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46D411B2B33 for ; Wed, 14 Oct 2015 22:01:03 -0700 (PDT) Received: from [50.174.96.154] (port=46211 helo=[192.168.1.28]) by gator4135.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.85) (envelope-from ) id 1Zmaf0-000F5p-Ez for webpush@ietf.org; Thu, 15 Oct 2015 00:01:02 -0500 From: Shida Schubert Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 14 Oct 2015 22:01:00 -0700 To: webpush@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator4135.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source-IP: 50.174.96.154 X-Exim-ID: 1Zmaf0-000F5p-Ez X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.28]) [50.174.96.154]:46211 X-Source-Auth: shida@agnada.com X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== Archived-At: Subject: [Webpush] Agenda for Yokohama X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 05:01:05 -0000 I'm starting to put together the agenda for the webpush meetings in = Yokohama. =20 Our session is on Tuesday from 13:00-15:00.=20 Please send me request for agenda time. Thanks!=20 Shida= From nobody Thu Oct 15 00:20: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 730A91A0097 for ; Thu, 15 Oct 2015 00:20:57 -0700 (PDT) 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 3ofwgGAZb5-S for ; Thu, 15 Oct 2015 00:20:55 -0700 (PDT) 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 73DE21A0089 for ; Thu, 15 Oct 2015 00:20:55 -0700 (PDT) Received: from [192.168.0.7] (unknown [120.149.147.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4AC9522E1F4; Thu, 15 Oct 2015 03:20:52 -0400 (EDT) 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: Thu, 15 Oct 2015 18:20:50 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Brian Raymor X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Status Code for Negative Acknowledgements #49 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 07:20:57 -0000 Thanks, Brian. The re-statement of #42 is a relief; however, it sounds = like there still needs to be some discussion around #49. Cheers, > On 15 Oct 2015, at 3:45 pm, Brian Raymor = wrote: >=20 >=20 > On October 14 2015 at 8:31 PM, Mark Nottingham wrote: >=20 >> I'm especially concerned about suggestions in the issue to allocate = "a range of >> status codes" for this purpose. >=20 > Let me clarify. There are two issues: >=20 > https://github.com/webpush-wg/webpush-protocol/issues/49 (Status Code = for Negative Acknowledgements) is related to the proposal for the 512 = status code under discussion. >=20 > https://github.com/webpush-wg/webpush-protocol/issues/42 = (Acknowledgement 'status codes') is the source of the confusion about "a = range of status codes"? I completely agree that the title (even with = those single quotes) is misleading. The intent is to NOT use HTTP status = codes to return information for this scenario. If developed further, it = will probably need to be a header field since it's passed in a DELETE. = (It's closer in nature to the opaque diagnostic data that can be = included in a HTTP/2 GOAWAY.) I've clarified the title and text in the = issue to reflect our true intentions. >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Thu Oct 15 09:08: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 560751A92B3 for ; Thu, 15 Oct 2015 09:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TcvMH08zeqmB for ; Thu, 15 Oct 2015 09:07:58 -0700 (PDT) Received: from mail-lf0-f53.google.com (mail-lf0-f53.google.com [209.85.215.53]) (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 5AB8C1A9007 for ; Thu, 15 Oct 2015 09:07:57 -0700 (PDT) Received: by lfaz124 with SMTP id z124so34324494lfa.1 for ; Thu, 15 Oct 2015 09:07:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=53l1TeA548towAwgbizMq+xeuzCYJPdVUecmnq8RFWY=; b=iBqxw1LJAisTsFtJ0yjm7g2oyGfraK9KQEbmdmayeIoaV/gyG7a7knQuaoKXNeJnA3 wzkW9gmL28JJSAJ3rUhpC9krj1T8XYtz7mFkXan0AUIoxqOVq8D0R0GZqgljGk4515+m PjZgtKJ5+dCO8VRn0O6l1PjOBY33Wc5uptr3yeJlJVM99L/mRgmkcmP7NhQonGIi8Bjc sy6GZWExUW6kucnbodnKGE+faFaIPmlU25BSeUcg7qOYufHd1/TpWoTuKTRviohIxsfM Zx0HHD9fF8HYEDHae26is+YONnpRnrOhYnAOwIZTBGX7xELaHlyl1MR7ZEPWKGybrpeW 14vw== X-Gm-Message-State: ALoCoQmJWLPMvgmQLMRQkXSnR7QA8sX6zjF50iebnOLg+jGl0/x/gBFrgx3GMnHE9fVa/dRf+af4 MIME-Version: 1.0 X-Received: by 10.180.104.69 with SMTP id gc5mr10834798wib.69.1444925275506; Thu, 15 Oct 2015 09:07:55 -0700 (PDT) Received: by 10.27.33.18 with HTTP; Thu, 15 Oct 2015 09:07:55 -0700 (PDT) In-Reply-To: <561ED106.8030806@mozilla.com> References: <561EC47C.4090803@mozilla.com> <561ED106.8030806@mozilla.com> Date: Thu, 15 Oct 2015 09:07:55 -0700 Message-ID: From: Benjamin Bangert To: jr conlin Content-Type: multipart/alternative; boundary=f46d043bdbe6c643f0052226e1ee Archived-At: Cc: Martin Thomson , "webpush@ietf.org" Subject: Re: [Webpush] Message expiration (TTL) and Negative Acknowledgements X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 16:08:02 -0000 --f46d043bdbe6c643f0052226e1ee Content-Type: text/plain; charset=UTF-8 So, nacking in the case that we have to clear a client's notifications (too many) feels like it can cause a really nasty infinite loop error. Here's the situation I'm seeing: 1. User hits limit on the most queued messages the Push Service wishes to hold at once for a single client. 2. On the next incoming notification, Push Service clears out the client's notification queue to make space for new notifications. (I believe GCM already will drop a bunch of notifications at once when this happens) 3. We send out NACK's for all the dropped notifications 4. App-Servers get nack's and decide to resend notifications. 5. Go to step 1. What steps are being taken with NACK's to ensure an app-server doesn't do something like this? Is there going to be some status code or something to indicate that these messages shouldn't be retried for some period of time? Or is it going to be up to a Push Service to try and detect these loops, and when they occur, the Push Service is just going to have to fully expire all the clients subscriptions to stop the loop? On Wed, Oct 14, 2015 at 3:02 PM, jr conlin wrote: > On 10/14/2015 2:37 PM, Martin Thomson wrote: > > On 14 October 2015 at 14:09, JR Conlin wrote: > >> 429: This will allow the server to apply "back pressure" to the > >> application service in cases where there may be too many incoming > >> messages in a short period of time. This response would carry a > >> RETRY-AFTER response header indicating the number of seconds that should > >> elapse before the remote server should retry transmission of the > message. > > > > How is that different from 503? > > Traditionally (as if that's a thing for the web) 503 tends to be used by > intermediary services like load balancers to indicate that "something's > amiss with the box I normally talk to". Since it's a 500 class error, it > indicates an error state possibly from outside the server. 429 was > identified as part of https://tools.ietf.org/html/rfc6585 to be used > more as a rate limiter and carries with it the "Retry-After" response > header indicating how long the requester should wait before retry. It's > a 400 class error, which means it should come from the responding server. > > Either would work, of course, but it may be that programmers can take > advantage of pre-existing handlers in libraries to do the back-off for > them, rather than have to code the response themselves. > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > --f46d043bdbe6c643f0052226e1ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So, nacking in the case= that we have to clear a client's notifications (too many) feels like i= t can cause a really nasty infinite loop error.

Here's the= situation I'm seeing:
1. User hits limit on the most queued m= essages the Push Service wishes to hold at once for a single client.
2. On the next incoming notification, Push Service clears out the client= 's notification queue to make space for new notifications. (I believe G= CM already will drop a bunch of notifications at once when this happens)
3. We send out NACK's for all the dropped notifications
4. App-Servers get nack's and decide to resend notifications.
5. Go to step 1.

What steps are being taken with NACK's t= o ensure an app-server doesn't do something like this? Is there going t= o be some status code or something to indicate that these messages shouldn&= #39;t be retried for some period of time?

Or is it going to be up t= o a Push Service to try and detect these loops, and when they occur, the Pu= sh Service is just going to have to fully expire all the clients subscripti= ons to stop the loop?

On Wed, Oct 14, 2015 at 3:02 PM, jr conlin = <jconlin@mozill= a.com> wrote:
On 10/14/2015 2:37 PM, Martin Thomson wrote:
> On 14 October 2015 at 14:09, JR Conlin <jconlin@mozilla.com> wrote:
>> 429: This will allow the server to apply "back pressure"= to the
>> application service in cases where there may be too many incoming<= br> >> messages in a short period of time. This response would carry a >> RETRY-AFTER response header indicating the number of seconds that = should
>> elapse before the remote server should retry transmission of the m= essage.
>
> How is that different from 503?

Traditionally (as if that's a thing for the web) 503 tends to be= used by
intermediary services like load balancers to indicate that "something&= #39;s
amiss with the box I normally talk to". Since it's a 500 class err= or, it
indicates an error state possibly from outside the server. 429 was
identified as part of https://tools.ietf.org/html/rfc6585 t= o be used
more as a rate limiter and carries with it the "Retry-After" resp= onse
header indicating how long the requester should wait before retry. It's=
a 400 class error, which means it should come from the responding server.
Either would work, of course, but it may be that programmers can take
advantage of pre-existing handlers in libraries to do the back-off for
them, rather than have to code the response themselves.

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

--f46d043bdbe6c643f0052226e1ee-- From nobody Thu Oct 15 10:10: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 B23DC1ACD38 for ; Thu, 15 Oct 2015 10:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3xS29fKh3RZ for ; Thu, 15 Oct 2015 10:10:52 -0700 (PDT) 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 6DB9B1ACD22 for ; Thu, 15 Oct 2015 10:10:52 -0700 (PDT) Received: by ykfy204 with SMTP id y204so61066831ykf.1 for ; Thu, 15 Oct 2015 10:10:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+UbgLeOGCZ/uq81nOWk6bUiNv6+VuCDdiyFthoya4aU=; b=jRC8Ng9h+MwbUZx80CEGvhQUVg9dM165P12rtiIFYa8DpNeAX7QcqrYLwYQUkAhAXz KgnKgd2AmqZw7F7HHzghWrf5fkRr5NuP0DJLGPuY8htWwIHQ6sBF64rnywIfGP6xuMY/ d0y+N9B5w0wMzYCr2KFJU+or8Co3geK34zLO2TWCaAtEBfXpqctCstuTyK4I1dJMwLcG kbhCmgfs7q73aWTRo/4ZR6zW9ARQ81rYqf7d/cFu1I+NS0qtJWs87CffGotbqpww4/Vu n2pcvgYYZlEi1iANj4yx58G9Ag12L6J/cRHrBoDLP04ZZXIOucyzAYEMglHQ8hS3yTY4 ElgQ== MIME-Version: 1.0 X-Received: by 10.129.132.80 with SMTP id u77mr7479268ywf.187.1444929051737; Thu, 15 Oct 2015 10:10:51 -0700 (PDT) Received: by 10.13.230.78 with HTTP; Thu, 15 Oct 2015 10:10:51 -0700 (PDT) In-Reply-To: References: <561EC47C.4090803@mozilla.com> <561ED106.8030806@mozilla.com> Date: Thu, 15 Oct 2015 10:10:51 -0700 Message-ID: From: Martin Thomson To: Benjamin Bangert Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: jr conlin , "webpush@ietf.org" Subject: Re: [Webpush] Message expiration (TTL) and Negative Acknowledgements X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 17:10:53 -0000 On 15 October 2015 at 09:07, Benjamin Bangert wrote: > What steps are being taken with NACK's to ensure an app-server doesn't do > something like this? Is there going to be some status code or something to > indicate that these messages shouldn't be retried for some period of time? > > Or is it going to be up to a Push Service to try and detect these loops, and > when they occur, the Push Service is just going to have to fully expire all > the clients subscriptions to stop the loop? What steps do you think are appropriate. I'd have to think some more on it, but I think that the only reasonable option is to have the push service do something. We could recommend the use of Retry-After on nacks. Other than that, I guess that this is something the push service needs to handle. From nobody Thu Oct 15 17:37:08 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 578E21A9008; Thu, 15 Oct 2015 17:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwRp6fR_H2DD; Thu, 15 Oct 2015 17:37:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 348E41A8FD6; Thu, 15 Oct 2015 17:37:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151016003706.3901.51629.idtracker@ietfa.amsl.com> Date: Thu, 15 Oct 2015 17:37:06 -0700 Archived-At: Cc: webpush@ietf.org Subject: [Webpush] I-D Action: draft-ietf-webpush-protocol-01.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: Fri, 16 Oct 2015 00:37:07 -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-01.txt Pages : 22 Date : 2015-10-15 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-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-webpush-protocol-01 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 Fri Oct 16 07:35:38 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F37B1B2C67 for ; Fri, 16 Oct 2015 07:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.788 X-Spam-Level: X-Spam-Status: No, score=-0.788 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, J_CHICKENPOX_22=0.6, 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 gb-nxpzQG88P for ; Fri, 16 Oct 2015 07:35:35 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::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 CF5311B2C61 for ; Fri, 16 Oct 2015 07:35:34 -0700 (PDT) Received: by lbbes7 with SMTP id es7so12235658lbb.2 for ; Fri, 16 Oct 2015 07:35:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Hj6s0kFnRqvi1suq2ban/3rzGVJpU0ZvJyJbFIU6Hxs=; b=cN/iM6RsM60r4gmNVDSUYErLCXfBmG4c92eNgE81RVsw9kliQozJx+v4rpm8+2EkwK UCiXm5k4CHs/vJPEka3Alt64qwR7D6JR7Upa4iKOZS15M1zOqo9M+hoV4SE8xg1tj9WP Kcba3oFA5hASE53LxorNlcj/JZeAEPdsusc2sOwxWPLRPAK2YJiilsOqcWx/+v2VNNgR qkhzT5lNuVmE1Bdsdm1nWxoorkXZv3FDYu/51AbdybxW55qdWsVEFf7HmGOBvSWCJeuA kKk572RPnxyIG8pTMqK7fJx/3Bq79P2aM3ySwR9VUwDy7FC77ct8IrzgP3sJplUsgcnS q4CA== 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=Hj6s0kFnRqvi1suq2ban/3rzGVJpU0ZvJyJbFIU6Hxs=; b=i3n8eLbj+px70Y4W72Hl8I1uSgnVXlXjikfVn6WA5uC/vaXn+9W39jJ5fBMCmh4vw0 5ydKtJMwxco/fhWOFq5jcuABOU7XIYEKObshNYyJTyZokVRtQ8yIx/VedW5GVflKWagr j0K1viakKQXsBGMhjKqkfGQXrZfNTyt8you+/QZnN0vT/qrXsvCjK/G7PZL3TrXEkjGn VguTjabewq+Skq3mmLvhbH9edVJPqQRpsQxRFbpgOc6kWlVMb9RwjNKhIZz5Ic1k4jtb 7ivWbHxiluPmFsecE4I/jyqO5+4TJOFbSZ3k+bcLuY5XVRWYTKIa4pNdGlh/7221261m 2kfA== X-Gm-Message-State: ALoCoQk06mBhy7cMg+GZBMY/8Q6y2xjz6RDo5zieAqOJ/OXWslsEomO7VbL9b223QtXNbtfQh2h9 MIME-Version: 1.0 X-Received: by 10.112.130.225 with SMTP id oh1mr8473650lbb.69.1445006132963; Fri, 16 Oct 2015 07:35:32 -0700 (PDT) Received: by 10.25.21.98 with HTTP; Fri, 16 Oct 2015 07:35:32 -0700 (PDT) Date: Fri, 16 Oct 2015 15:35:32 +0100 Message-ID: From: Peter Beverloo To: "webpush@ietf.org" Content-Type: multipart/alternative; boundary=047d7b343d3241406b052239b5a9 Archived-At: Subject: [Webpush] Comments on draft-thomson-webpush-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, 16 Oct 2015 14:35:37 -0000 --047d7b343d3241406b052239b5a9 Content-Type: text/plain; charset=UTF-8 Hi all - There are a number of concerns I have about thomson-webpush-encryption[1] after implementing support for the draft in Chrome, most of which are related to the generic nature of thomson-http-encryption[2]. The tl;dr is that while I believe that using the "aesgcm128" HTTP content encoding with a single record is good, removing our dependencies on other parts of thomson-http-encryption would significantly simplify webpush. (To start off on a slight tangent, after further discussion with Mozilla we have agreed to support P-256, despite our strong, standing preference for using Curve25519.) (1) Allowing multiple values for the Content-Encoding header. For efficiency reasons, an implementation may use alternative protocols for the push service <--> user agent connection that are not HTTP-based. This is the case for Chrome (and Android), where messages may be received outside of the network stack and content decryption happens by using the header values in combination with an aes128gcm encoding. Supporting multiple values, e.g. encryption and compression, would be problematic. Would it be reasonable to require a single value of "aes128gcm"? (2) Separation of the Encryption and Encryption-Key headers. Given that thomson-webpush-encryption mandates use of a single encryption record, an implementation only _needs_ the "salt" parameter from the Encryption header, and the "dh" parameter from the Encryption-Key header. The "rs" header can be implied, but could still be used to validate the single-record requirement. The fact that both headers support comma-separated lists also seems unnecessary for use with thomson-webpush-encryption. Introducing yet another header it not great, but it would allow us to provide a concise, to-the-point header only having "salt" and "dh" parameters, in which the "rs" can be implied from the message's body. (2a) Ambiguity about the meaning of the "keyid" parameter. Under what circumstances would the subscription id for which a message is received not be sufficient for selecting the keys, i.e. when would there be multiple key pairs per subscription? Is this an artifact of having the required data spread over two headers that both allow comma-separated lists, to match a "salt" with a "dh"? (2b) Disallowing use of explicit keys (for now). thomson-http-encryption also allows use of the "key" parameter for providing an explicit key. While this could be useful for broadcasts in the future, we should explicitly disallow this until we get there. Thanks, Peter [1] https://tools.ietf.org/html/draft-thomson-webpush-encryption-01 [2] https://tools.ietf.org/html/draft-thomson-http-encryption-01 --047d7b343d3241406b052239b5a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all -

There are a number = of concerns I have about thomson-webpush-encryption[1]
after impl= ementing support for the draft in Chrome, most of which are
relat= ed to the generic nature of thomson-http-encryption[2].

The tl;dr is that while I believe that using the "aesgcm128= " HTTP content
encoding with a single record is good, removi= ng our dependencies on other
parts of thomson-http-encryption wou= ld significantly simplify webpush.

(To start= off on a slight tangent, after further discussion with Mozilla
w= e have agreed to support P-256, despite our strong, standing preference
for using Curve25519.)


=C2= =A0 =C2=A0 (1) Allowing multiple values for the Content-Encoding header.

For efficiency reasons, an implementation may use al= ternative protocols
for the push service <--> user agent co= nnection that are not HTTP-based.

This is the case= for Chrome (and Android), where messages may be received
outside= of the network stack and content decryption happens by using
the= header values in combination with an aes128gcm encoding. Supporting
<= div>multiple values, e.g. encryption and compression, would be problematic.=

Would it be reasonable to require a single value = of "aes128gcm"?

=C2=A0 =C2=A0 (2) Separa= tion of the Encryption and Encryption-Key headers.

Given that thomson-webpush-encryption mandates use of a single encryption<= /div>
record, an implementation only _needs_ the "salt" param= eter from the
Encryption header, and the "dh" parameter= from the Encryption-Key header.
The "rs" header can be= implied, but could still be used to validate the
single-record r= equirement.

The fact that both headers support com= ma-separated lists also seems
unnecessary for use with thomson-we= bpush-encryption.

Introducing yet another header i= t not great, but it would allow us to
provide a concise, to-the-p= oint header only having "salt" and "dh"
param= eters, in which the "rs" can be implied from the message's bo= dy.

=C2=A0 =C2=A0 =C2=A0 (2a) Ambiguity about the = meaning of the "keyid" parameter.

Under = what circumstances would the subscription id for which a message is
received not be sufficient for selecting the keys, i.e. when would there=
be multiple key pairs per subscription?

Is this an artifact of having the required data spread over two headers
that both allow comma-separated lists, to match a "salt" = with a "dh"?

=C2=A0 =C2=A0 =C2=A0 (2b) D= isallowing use of explicit keys (for now).

thomson= -http-encryption also allows use of the "key" parameter for
=
providing an explicit key. While this could be useful for broadcasts i= n
the future, we should explicitly disallow this until we get the= re.

Thanks,
Peter

[1] https://tools.ietf.org/html/draft-thomson-webpush-encryption-01=

--047d7b343d3241406b052239b5a9-- From nobody Fri Oct 16 11:36:30 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB2D1AC444 for ; Fri, 16 Oct 2015 11:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxN54XSdlwSw for ; Fri, 16 Oct 2015 11:36:26 -0700 (PDT) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39E841AC44A for ; Fri, 16 Oct 2015 11:36:25 -0700 (PDT) Received: by ykfy204 with SMTP id y204so93119716ykf.1 for ; Fri, 16 Oct 2015 11:36:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xPqWVXFPDD2dEIdQbLlYAuHj1wOchHwFUBq4aF4AwDA=; b=MzhNRNd9YyeBwOxIK5eZrBlF5QS6tPVf9ebE26mMMOLEmgWyjAmR7PwdKDIbyUUCjx +N3MABVT07tlb0/0pLgidQjUfHh6Dwp9xqxCbzz+MycVdEy6hnpgIGmo+WpuwCx8YLea 4QjYEeKjccFBqmgwS5zd/UJOCjAkhyMoGxm3vbPipfjeyZfRYRv/G23buNT+j8WPOjoY /CI/KPzFfu3rDDLyDfJdk4V2IcBAox/f2L0Asd4GAh23Wh1TaabFLWzaBZzHJOs6PdAI 6+LGj9Etxekjy8wsoQq3gjHH9fdmm835pdY3yUAKJCOBq5k4N8WKC2I1SjvfPpPAb42W m97A== MIME-Version: 1.0 X-Received: by 10.129.132.80 with SMTP id u77mr11346935ywf.187.1445020584434; Fri, 16 Oct 2015 11:36:24 -0700 (PDT) Received: by 10.13.230.78 with HTTP; Fri, 16 Oct 2015 11:36:24 -0700 (PDT) In-Reply-To: References: Date: Fri, 16 Oct 2015 11:36:24 -0700 Message-ID: From: Martin Thomson To: Peter Beverloo Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Comments on draft-thomson-webpush-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, 16 Oct 2015 18:36:28 -0000 Thanks for the feedback Peter, I think that I agree with most of this, though we should discuss the header split thing a little more. More inline. On 16 October 2015 at 07:35, Peter Beverloo wrote: > Would it be reasonable to require a single value of "aes128gcm"? I will make that stipulation. (I believe that we assume the value to be set to exactly this, rather than checking that it is, which is probably non-compliant, but it might allow a push service to save some space...) > (2) Separation of the Encryption and Encryption-Key headers. > > Given that thomson-webpush-encryption mandates use of a single encryption > record, an implementation only _needs_ the "salt" parameter from the > Encryption header, and the "dh" parameter from the Encryption-Key header. > The "rs" header can be implied, but could still be used to validate the > single-record requirement. Yeah, this comes down to the generality problem. I think that the split is still useful unfortunately, which isn't ideal (but HTTP/2 allows us to avoid the cost). I've got more on this below, I think that there's a tweak that can eliminate the worst of the cost. > (2a) Ambiguity about the meaning of the "keyid" parameter. > > Under what circumstances would the subscription id for which a message is > received not be sufficient for selecting the keys, i.e. when would there > be multiple key pairs per subscription? > > Is this an artifact of having the required data spread over two headers > that both allow comma-separated lists, to match a "salt" with a "dh"? In this context, it's used to correlate entries between Encryption and Encryption-Key. That's not great. Here's what I propose adding: An application server MUST include exactly one entry in each of the Encryption and Encryption-Key header fields. This allows the `keyid` parameter to be omitted from both header fields. > (2b) Disallowing use of explicit keys (for now). Yup, definitely (probably don't want to ever support that...) From nobody Fri Oct 16 14:20:37 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 E6C241B3401 for ; Fri, 16 Oct 2015 14:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WR31TEr0479w for ; Fri, 16 Oct 2015 14:20:31 -0700 (PDT) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60A131B33FF for ; Fri, 16 Oct 2015 14:20:31 -0700 (PDT) Received: by wijp11 with SMTP id p11so27335967wij.0 for ; Fri, 16 Oct 2015 14:20:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=s0w+qVmLA6luhdyflMq4BIXViEcZ6RjEKNEDK60t4v4=; b=Whg7599eahSbZe9tX7qaYJ1a/PbP0QSWyjdOz7RA3Jz9UR3euCJbpR9yzGxpORkKe0 Elo0KhLRouAAKec2RJc81WBMCyS1GnjKPVTx+bzibnMdrJ5rboeDsdNUC5vuxgP2KV7E piS15BVLiSPmTcJr8ExSehWKLmvzqoTvE7SiM8A/9PhRKrwRgBGJUxEbe0UC4CGLUHLc C6GHqloCbYnDtddBF1VO+oJlFdJG1GFQiwQS2nVtfbsbvu6So8C1ddgUM2IgDZy14qyu euk6ID/Nx3HEnc8zwtmfbQqDbu1LZRUPZkbrL2tHYpojBm1Rg+xzYigaXXanvzJMinej P3Lw== X-Gm-Message-State: ALoCoQlFb7gHQYQUQvmlYboKd6A7lSBT2DIS/4kZVjtLgp4tOc853m9C4MEoMfs84DM00/EhJWfD MIME-Version: 1.0 X-Received: by 10.180.208.100 with SMTP id md4mr7112592wic.41.1445030429793; Fri, 16 Oct 2015 14:20:29 -0700 (PDT) Received: by 10.27.155.207 with HTTP; Fri, 16 Oct 2015 14:20:29 -0700 (PDT) In-Reply-To: References: <561EC47C.4090803@mozilla.com> <561ED106.8030806@mozilla.com> Date: Fri, 16 Oct 2015 14:20:29 -0700 Message-ID: From: Benjamin Bangert To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11c38e267544e505223f5dc4 Archived-At: Cc: jr conlin , "webpush@ietf.org" Subject: Re: [Webpush] Message expiration (TTL) and Negative Acknowledgements X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 21:20:36 -0000 --001a11c38e267544e505223f5dc4 Content-Type: text/plain; charset=UTF-8 I'd prefer to not have to send NACK's in the event that the Push Service has to clear them out for a user that stored too many. But that's possibly not an option? For the NACK's, speaking of server constraints, how many receipts is a Push Service expected to buffer for an App-Server? If an App-Server sends 500k notifications in, and happens to not be connected to the receipt server at the time.... how many of those is the Push Service supposed to hold onto until the app-server starts pulling them? If the stream of NACK's is several magnitudes higher than an App-Server can process them, at what point can a Push Service start dropping NACK's on the floor? On Thu, Oct 15, 2015 at 10:10 AM, Martin Thomson wrote: > On 15 October 2015 at 09:07, Benjamin Bangert > wrote: > > What steps are being taken with NACK's to ensure an app-server doesn't do > > something like this? Is there going to be some status code or something > to > > indicate that these messages shouldn't be retried for some period of > time? > > > > Or is it going to be up to a Push Service to try and detect these loops, > and > > when they occur, the Push Service is just going to have to fully expire > all > > the clients subscriptions to stop the loop? > > > What steps do you think are appropriate. I'd have to think some more > on it, but I think that the only reasonable option is to have the push > service do something. We could recommend the use of Retry-After on > nacks. > > Other than that, I guess that this is something the push service needs > to handle. > --001a11c38e267544e505223f5dc4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'd prefer to not have to send NACK'= ;s in the event that the Push Service has to clear them out for a user that= stored too many. But that's possibly not an option?

For t= he NACK's, speaking of server constraints, how many receipts is a Push = Service expected to buffer for an App-Server? If an App-Server sends 500k n= otifications in, and happens to not be connected to the receipt server at t= he time.... how many of those is the Push Service supposed to hold onto unt= il the app-server starts pulling them?

If the stream of N= ACK's is several magnitudes higher than an App-Server can process them,= at what point can a Push Service start dropping NACK's on the floor?

On Thu, Oct 15, 2015 at 10:10 AM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
On 15 October 2015 at 09:07, Benjamin Bangert <bbangert@mozilla.com> wrote:
> What steps are being taken with NACK's to ensure an app-server doe= sn't do
> something like this? Is there going to be some status code or somethin= g to
> indicate that these messages shouldn't be retried for some period = of time?
>
> Or is it going to be up to a Push Service to try and detect these loop= s, and
> when they occur, the Push Service is just going to have to fully expir= e all
> the clients subscriptions to stop the loop?


What steps do you think are appropriate.=C2=A0 I'd have to think= some more
on it, but I think that the only reasonable option is to have the push
service do something.=C2=A0 We could recommend the use of Retry-After on nacks.

Other than that, I guess that this is something the push service needs
to handle.

--001a11c38e267544e505223f5dc4-- From nobody Fri Oct 16 15:02: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 EFC2C1A212A for ; Fri, 16 Oct 2015 15:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5eH-xmWJkON for ; Fri, 16 Oct 2015 15:02:21 -0700 (PDT) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002: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 98A631A1C02 for ; Fri, 16 Oct 2015 15:02:21 -0700 (PDT) Received: by ykaz22 with SMTP id z22so95077426yka.2 for ; Fri, 16 Oct 2015 15:02:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6luJ03KQD1MWw1ih+nlBLVEudUcIjNeuAn5780bwTa4=; b=ZzoVpN2so+2Dgv+w2nQ8GT0QmtX2KvqbffzjrwAvRlEsPErgMKoEMEUYvu7ks0kurB XGb+nSyiJrQxqVYbex8+hw/gp8noo1wefy2gCdBGWuFSXJRqaVRU9GzCxx34MtOhjjyO yfyw4FPXukB7S1jc++jz9zTFNzcZnyBC2+HQhpHXJfS8LAgnMWD8vyxNpx8yfLVQXpmt 2fOCnfgNY+9vNLYKcIh+aqJDs8j7uaqBHemsp5Kb+ZGg/yr1sDIMzsggw+ynms2IsEVj AacHO5d6ow1az3FUzD7vgJl6FVffgMCjjTQIJc5mlrQDvjyiQG0IO/RhDA+XiP8UgjPY DPzQ== MIME-Version: 1.0 X-Received: by 10.13.196.196 with SMTP id g187mr13410813ywd.98.1445032940836; Fri, 16 Oct 2015 15:02:20 -0700 (PDT) Received: by 10.13.230.78 with HTTP; Fri, 16 Oct 2015 15:02:20 -0700 (PDT) In-Reply-To: References: <561EC47C.4090803@mozilla.com> <561ED106.8030806@mozilla.com> Date: Fri, 16 Oct 2015 15:02:20 -0700 Message-ID: From: Martin Thomson To: Benjamin Bangert Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: jr conlin , "webpush@ietf.org" Subject: Re: [Webpush] Message expiration (TTL) and Negative Acknowledgements X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 22:02:23 -0000 On 16 October 2015 at 14:20, Benjamin Bangert wrote: > For the NACK's, speaking of server constraints, how many receipts is a Push > Service expected to buffer for an App-Server? If an App-Server sends 500k > notifications in, and happens to not be connected to the receipt server at > the time.... how many of those is the Push Service supposed to hold onto > until the app-server starts pulling them? The number is bounded by the number of messages the app server has successfully requested delivery for. If you have 500k outstanding messages from the same app server, then you are hold that much message state; having some proportion of that translate into ack/nack state seems like it should be less state. Of course, if you are shedding load, then I see no reason not to be fairly aggressive about dumping nacks. That's probably worth noting in the operational considerations. > If the stream of NACK's is several magnitudes higher than an App-Server can > process them, at what point can a Push Service start dropping NACK's on the > floor? Inability to deliver an ACK or NACK can be treated exactly like failure to deliver a message, I'd imagine. You can't be expected to hold these forever. From nobody Fri Oct 16 15:05:07 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 3F4AE1A21A6 for ; Fri, 16 Oct 2015 15:05:06 -0700 (PDT) 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 hfFkoSh02Exx for ; Fri, 16 Oct 2015 15:05:04 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0145.outbound.protection.outlook.com [65.55.169.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72C1F1A21A4 for ; Fri, 16 Oct 2015 15:05:04 -0700 (PDT) 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=TZNt6/lh6LYQX6sayqhTNvqWiT8mtdHaU64ytXI0zIs=; b=YjB5yqMCVFP1Oow+2ebau4ZipP7NfjCgkQjypkZuOxnWx4qY/JowkBQnYMMeA0FcJTe2wNfw/nE+kBqlqaDfyKWEtVGPDwbIDpOOYcA5c1gOrhjGXLkQYine8fMNqXoG//UTa/pEfncAAHGiJOrkkD403LIwcgW/cC3tu6vqQBc= Received: from BY2PR0301MB0647.namprd03.prod.outlook.com (10.160.63.14) by BY2PR0301MB0645.namprd03.prod.outlook.com (10.160.63.13) with Microsoft SMTP Server (TLS) id 15.1.293.16; Fri, 16 Oct 2015 22:05:02 +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.0300.010; Fri, 16 Oct 2015 22:05:01 +0000 From: Brian Raymor To: Benjamin Bangert , Martin Thomson Thread-Topic: [Webpush] Message expiration (TTL) and Negative Acknowledgements Thread-Index: AdEGA6AApJ25A8bWSta9W/kXIcP8NQAAOC8AAABNKHAAAaYIAAAuEfkAAAD/aAAAAN7sAAAl5f+AAAIyq4AAOwKAgAAAfB9g Date: Fri, 16 Oct 2015 22:05:01 +0000 Message-ID: References: <561EC47C.4090803@mozilla.com> <561ED106.8030806@mozilla.com> 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:c551:a3ce:7ef9:ac81] x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0645; 5:CAQzmYykCjgu9dAeyB1Dz0kMMC9akR+NbRQJV1aboV/1a4fIdq2lpVxUtNGDS7xVhX3N2TMAUTTU0Vq8aSfdtMthE4YxD9YmC4ACowBVGt5MXcjN+MFcZ9ZT/EGQIiWmSbbkcfmsc0LxwAOKThV9hw==; 24:BFPXOprT9/unULa6sVOlQKDnmep/2oxlY56nxUAWIqw3cuvP/SnUZuMCOVJvW7CETtmsk9/whsnYyS9XguuGHE5CSFUw/1UIKZ5txxMJrsA=; 20:ZJTknJdDa5HFoJXV15vPp+E9FdKLiWBiPKt0kdqfUXQ4G89b8hPyYiDYkSHI9sr2sKUOeXNASskfkWNg3lFF/A== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42140001); SRVR:BY2PR0301MB0645; 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)(3002001)(61426024)(61427024); SRVR:BY2PR0301MB0645; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0645; x-forefront-prvs: 0731AA2DE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(377454003)(199003)(189002)(24454002)(76576001)(54356999)(106356001)(105586002)(5005710100001)(101416001)(93886004)(19580405001)(10400500002)(87936001)(99286002)(74316001)(5008740100001)(97736004)(19580395003)(5007970100001)(10290500002)(81156007)(64706001)(50986999)(5002640100001)(189998001)(40100003)(122556002)(8990500004)(10090500001)(102836002)(5001960100002)(46102003)(86362001)(2900100001)(86612001)(33656002)(5001770100001)(76176999)(2950100001)(77096005)(5003600100002)(92566002)(5004730100002)(3826002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0645; 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: 16 Oct 2015 22:05:01.7749 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0645 Archived-At: Cc: jr conlin , "webpush@ietf.org" Subject: Re: [Webpush] Message expiration (TTL) and Negative Acknowledgements X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 22:05:06 -0000 T24gVGh1LCBPY3RvYmVyIDE2LCAyMDE1IGF0IDI6MzAgUE0sIEJlbmphbWluIEJhbmdlcnQgPGJi YW5nZXJ0QG1vemlsbGEuY29tPiAgd3JvdGU6DQoNCj4gSSdkIHByZWZlciB0byBub3QgaGF2ZSB0 byBzZW5kIE5BQ0sncyBpbiB0aGUgZXZlbnQgdGhhdCB0aGUgUHVzaCBTZXJ2aWNlIGhhcyB0byBj bGVhciB0aGVtIG91dCBmb3IgYSB1c2VyIHRoYXQgc3RvcmVkIHRvbyBtYW55Lg0KPiBCdXQgdGhh dCdzIHBvc3NpYmx5IG5vdCBhbiBvcHRpb24/DQo+IEZvciB0aGUgTkFDSydzLCBzcGVha2luZyBv ZiBzZXJ2ZXIgY29uc3RyYWludHMsIGhvdyBtYW55IHJlY2VpcHRzIGlzIGEgUHVzaCBTZXJ2aWNl IGV4cGVjdGVkIHRvIGJ1ZmZlciBmb3IgYW4gQXBwLVNlcnZlcj8gDQoNClRoYXQgd291bGQgZGVw ZW5kIG9uIHRoZSBzY2FsYWJpbGl0eSBvZiB0aGUgcHVzaCBzZXJ2aWNlLg0KDQpUaGUgcHVzaCBz ZXJ2aWNlIG1heSBhZHZlcnRpc2UgYSBsb3dlciBUVEwgd2hlbiBhY2NlcHRpbmcgYSBwdXNoIG1l c3NhZ2UgZnJvbSBhbiBhcHBsaWNhdGlvbiBzZXJ2ZXIuIFdlJ3ZlIGFncmVlZCB0aGF0IG5vIGFj a25vd2xlZGdlbWVudHMgYXJlIHJldHVybmVkIG9uY2UgdGhlIGFkdmVydGlzZWQgVFRMIGhhcyBl eHBpcmVkLiBBIHB1c2ggc2VydmljZSBjb3VsZCBhbHdheXMgcmV0dXJuIFRUTCB3aXRoIGEgdmFs dWUgb2YgMCB3aGljaCB0aGVuIGRvZXMgbm90IGd1YXJhbnRlZSB0aGF0IGEgcHVzaCByZWNlaXB0 IHdpbGwgYmUgcmV0dXJuZWQuDQoNCkpSIGFsc28gcHJvcG9zZWQgdGhhdCB3ZSBpbmNsdWRlIGEg cmVmZXJlbmNlIHRvIDQyOSB3aXRoIFJldHJ5LUFmdGVyIHRvIGxpbWl0IHRoZSBwdWJsaXNoIHJh dGUgb2YgYW4gYXBwbGljYXRpb24gc2VydmVyLCBzbyBhIHB1c2ggc2VydmljZSBpcyBub3Qgc3Rv cmluZyA1MDBLIG5vdGlmaWNhdGlvbnMgaW4gYSBiYXRjaCBmcm9tIGFuIGFwcGxpY2F0aW9uIHNl cnZlciB0aGF0IGlzIHJlcXVlc3RpbmcgcHVzaCByZWNlaXB0cy4NCg0KPiBJZiB0aGUgc3RyZWFt IG9mIE5BQ0sncyBpcyBzZXZlcmFsIG1hZ25pdHVkZXMgaGlnaGVyIHRoYW4gYW4gQXBwLVNlcnZl ciBjYW4gcHJvY2VzcyB0aGVtLA0KPiBhdCB3aGF0IHBvaW50IGNhbiBhIFB1c2ggU2VydmljZSBz dGFydCBkcm9wcGluZyBOQUNLJ3Mgb24gdGhlIGZsb29yPw0KDQpUaGUgcHVzaCBzZXJ2aWNlIGNh biBleHBpcmUgYSByZWNlaXB0IHN1YnNjcmlwdGlvbiBhdCB3aWxsLiBPdGhlcndpc2UsIHRoZSBw dXNoIHNlcnZpY2UgbmVlZHMgdG8gd2FpdCB1bnRpbCB0aGUgYWR2ZXJ0aXNlZCBUVEwgZXhwaXJl cy4NCg0KDQo= From nobody Fri Oct 16 18: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 BC3E71A8966; Fri, 16 Oct 2015 18:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoTJL7Cnus-b; Fri, 16 Oct 2015 18:31:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4891A8969; Fri, 16 Oct 2015 18:30:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151017013057.18495.101.idtracker@ietfa.amsl.com> Date: Fri, 16 Oct 2015 18:30:57 -0700 Archived-At: Cc: webpush@ietf.org Subject: [Webpush] I-D Action: draft-ietf-webpush-encryption-00.txt X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2015 01:31:01 -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 : Message Encryption for Web Push Author : Martin Thomson Filename : draft-ietf-webpush-encryption-00.txt Pages : 7 Date : 2015-10-16 Abstract: A message encryption scheme is described for the Web Push protocol. This scheme provides confidentiality and integrity for messages sent from an Application Server to a User Agent. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-webpush-encryption/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-webpush-encryption-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 19 10:02: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 8EE8C1A8906 for ; Mon, 19 Oct 2015 10:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUpYPoq6Bnjp for ; Mon, 19 Oct 2015 10:02:11 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::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 CEFC11A8A89 for ; Mon, 19 Oct 2015 10:02:10 -0700 (PDT) Received: by lbbwb3 with SMTP id wb3so87642756lbb.1 for ; Mon, 19 Oct 2015 10:02:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xcJ6DbKH90uqPrE6ocOUMkNNvjZKB6ym/keGfsfoNHU=; b=WeG4Pv+BMzhkPEYVUzr9IJn3BkPKr4/I2r6SyeUm0JtHMNtrRPcCchyQZ5A16DNCDu BhNHRp9zLpdq/w6paXjoR9qkaNEoEBmLzrpGuzdNHUWMczEmiXUGuVZO+qa6teIgZXCM nDgvpzYRRoJNitFDNeDUi0+wlyIs6A0t6Tbc1jMms9MB/np6BXVLYO6MesG9AGKDDt95 zce6DT5NhJIJ3WY2lBRP5XosQRTWt45naYf30FxBdY/prSItyoH4qvb8e9rdutD6peLc RgqReODVHVLg5SRyYgkch3IZvWd2vcEmtsIuzw2MYU1t1lexptWtpyupbC9AkGjMvda7 LSOg== 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=xcJ6DbKH90uqPrE6ocOUMkNNvjZKB6ym/keGfsfoNHU=; b=civ3YAR2bA8a0ktkhfVvvCKEgsjVmP7uKrpkxAG5xeK3t+QjzNVkJAq4mNj/mGbeQ/ foYYSp/GZMou3yHgFy3HArlIAa3Rczc297DyzJtiEI5LPtfMkNzE8hfyX2ReQuve2Txh V0+1xZV4wra5erdM6uyimP96ZciOncLKg2sm1/94pXUhKKDl5wppGCLonC0qJwdSE89G AZrSGoAnntdaBwJHQqB3Ou6UIGLM4ePMX86DSr7kKObZ1JAGoORc+r/B2F56qsv5n4ls Fcaap9OLIXTBiREU/bsblB9Gmwg+A5tcijfbKzyNqREDFqA8XON4wf/omxD/orX9lISZ tbTg== X-Gm-Message-State: ALoCoQmdhNdMAGV9RMJWcgmgRuyvwBkhNwZhtZcsuYhiHreTVPc4ILNZglPcRBOMdIUfGO2otM1l MIME-Version: 1.0 X-Received: by 10.112.12.3 with SMTP id u3mr12141100lbb.30.1445274127488; Mon, 19 Oct 2015 10:02:07 -0700 (PDT) Received: by 10.25.21.98 with HTTP; Mon, 19 Oct 2015 10:02:07 -0700 (PDT) In-Reply-To: References: Date: Mon, 19 Oct 2015 18:02:07 +0100 Message-ID: From: Peter Beverloo To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11c3ef1ef91ed40522781a20 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Comments on draft-thomson-webpush-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: Mon, 19 Oct 2015 17:02:12 -0000 --001a11c3ef1ef91ed40522781a20 Content-Type: text/plain; charset=UTF-8 Thank you for the updates, Martin! On Fri, Oct 16, 2015 at 7:36 PM, Martin Thomson wrote: > Thanks for the feedback Peter, I think that I agree with most of this, > though we should discuss the header split thing a little more. More > inline. > > On 16 October 2015 at 07:35, Peter Beverloo wrote: > > Would it be reasonable to require a single value of "aes128gcm"? > > I will make that stipulation. (I believe that we assume the value to > be set to exactly this, rather than checking that it is, which is > probably non-compliant, but it might allow a push service to save some > space...) > > > (2) Separation of the Encryption and Encryption-Key headers. > > > > Given that thomson-webpush-encryption mandates use of a single encryption > > record, an implementation only _needs_ the "salt" parameter from the > > Encryption header, and the "dh" parameter from the Encryption-Key header. > > The "rs" header can be implied, but could still be used to validate the > > single-record requirement. > > Yeah, this comes down to the generality problem. I think that the > split is still useful unfortunately, which isn't ideal (but HTTP/2 > allows us to avoid the cost). > The expected values are now well defined, so this works for me. I will liaise with our encryption experts. I've got more on this below, I think that there's a tweak that can > eliminate the worst of the cost. > > > (2a) Ambiguity about the meaning of the "keyid" parameter. > > > > Under what circumstances would the subscription id for which a message is > > received not be sufficient for selecting the keys, i.e. when would there > > be multiple key pairs per subscription? > > > > Is this an artifact of having the required data spread over two headers > > that both allow comma-separated lists, to match a "salt" with a "dh"? > > In this context, it's used to correlate entries between Encryption and > Encryption-Key. That's not great. Here's what I propose adding: > > An application server MUST include exactly one entry in each of the > Encryption > and Encryption-Key header fields. This allows the `keyid` parameter to be > omitted from both header fields. > That works for me. Thanks, Peter > > > (2b) Disallowing use of explicit keys (for now). > > Yup, definitely (probably don't want to ever support that...) --001a11c3ef1ef91ed40522781a20 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you for the updates, Martin!

On Fri, Oct 16, 2015 at 7:36 PM, Martin T= homson <martin.thomson@gmail.com> wrote:
Thanks for the feedback Peter, I think that I agree with most of th= is,
though we should discuss the header split thing a little more.=C2=A0 More inline.

On 16 October 2015 at 07:35, Peter Beverloo <beverloo@google.com> wrote:
> Would it be reasonable to require a single value of "aes128gcm&qu= ot;?

I will make that stipulation.=C2=A0 (I believe that we assume the va= lue to
be set to exactly this, rather than checking that it is, which is
probably non-compliant, but it might allow a push service to save some
space...)

>=C2=A0 =C2=A0 =C2=A0(2) Separation of the Encryption and Encryption-Key= headers.
>
> Given that thomson-webpush-encryption mandates use of a single encrypt= ion
> record, an implementation only _needs_ the "salt" parameter = from the
> Encryption header, and the "dh" parameter from the Encryptio= n-Key header.
> The "rs" header can be implied, but could still be used to v= alidate the
> single-record requirement.

Yeah, this comes down to the generality problem.=C2=A0 I think that = the
split is still useful unfortunately, which isn't ideal (but HTTP/2
allows us to avoid the cost).

The expec= ted values are now well defined, so this works for me. I will liaise with o= ur encryption experts.

I've got more on this below, I think that there's a tweak that can<= br> eliminate the worst of the cost.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0(2a) Ambiguity about the meaning of the &quo= t;keyid" parameter.
>
> Under what circumstances would the subscription id for which a message= is
> received not be sufficient for selecting the keys, i.e. when would the= re
> be multiple key pairs per subscription?
>
> Is this an artifact of having the required data spread over two header= s
> that both allow comma-separated lists, to match a "salt" wit= h a "dh"?

In this context, it's used to correlate entries between Encrypti= on and
Encryption-Key.=C2=A0 That's not great.=C2=A0 Here's what I propose= adding:

An application server MUST include exactly one entry in each of the Encrypt= ion
and Encryption-Key header fields.=C2=A0 This allows the `keyid` parameter t= o be
omitted from both header fields.

That w= orks for me.

Thanks,
Peter=C2=A0
=C2=A0

>=C2=A0 =C2=A0 =C2=A0 =C2=A0(2b) Disallowing use of explicit keys (for n= ow).

Yup, definitely (probably don't want to ever support that...)

--001a11c3ef1ef91ed40522781a20-- From nobody Mon Oct 19 11:39:49 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 7F12E1B2BAE; Mon, 19 Oct 2015 11:39:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019183948.28617.19977.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 11:39:48 -0700 Archived-At: Cc: webpush@ietf.org Subject: [Webpush] I-D Action: draft-ietf-webpush-encryption-01.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, 19 Oct 2015 18:39:48 -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 : Message Encryption for Web Push Author : Martin Thomson Filename : draft-ietf-webpush-encryption-01.txt Pages : 7 Date : 2015-10-19 Abstract: A message encryption scheme is described for the Web Push protocol. This scheme provides confidentiality and integrity for messages sent from an Application Server to a User Agent. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-webpush-encryption/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-webpush-encryption-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-webpush-encryption-01 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 Oct 19 11:40:32 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C283B1B2BA2 for ; Mon, 19 Oct 2015 11:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFdQ3hqw-iHh for ; Mon, 19 Oct 2015 11:40:28 -0700 (PDT) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::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 781911B2BA1 for ; Mon, 19 Oct 2015 11:40:28 -0700 (PDT) Received: by yknn9 with SMTP id n9so100606063ykn.0 for ; Mon, 19 Oct 2015 11:40:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cZ2UPRNG4U5zVRCiDyKRmGA3lYY6m8lQFexPkiWBlLQ=; b=jYGhyjzYl9x6MpyRNTMqzeFsO8SZ1McwgHiRr3ljBMc3t8Iqm25moeMyt8PDSmibQI O+voPj2XOavVlavkodq6DOMlld/1hsoBi1YkHaid96yHzR4FdCA66PVNKPtRIEJrZG0e frNUf0OXl3qkGc/K5J7aV3t7P8YDnyr88C0DJE7FvGhPMKBkfmW6MJDxRcI3FrUSVjrP Q9U1D6Ysg6N0Lcr0FAfKZ/lPkykytQaC0iH44uPV9Id+a3+bk26woA1jAAEsIvInL2YJ PEqJsM3Do4QHBN5B62fAYKjcA3o9k4/IAT//+3YvRSFSJqmLzDkqrdrjNKb4VyoXFEPY OCuA== MIME-Version: 1.0 X-Received: by 10.13.255.194 with SMTP id p185mr23520959ywf.207.1445280027821; Mon, 19 Oct 2015 11:40:27 -0700 (PDT) Received: by 10.129.132.145 with HTTP; Mon, 19 Oct 2015 11:40:27 -0700 (PDT) In-Reply-To: References: Date: Mon, 19 Oct 2015 11:40:27 -0700 Message-ID: From: Martin Thomson To: Peter Beverloo Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Comments on draft-thomson-webpush-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: Mon, 19 Oct 2015 18:40:30 -0000 On 19 October 2015 at 10:02, Peter Beverloo wrote: > Thank you for the updates, Martin! I've pushed an update to the draft with these changes, since it's the draft submission cutoff. Nothing else has changed. From nobody Thu Oct 22 14:16: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 B2E651B4219 for ; Thu, 22 Oct 2015 14:16:26 -0700 (PDT) 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 C-TsJ_jN3ODy for ; Thu, 22 Oct 2015 14:16:23 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0103.outbound.protection.outlook.com [207.46.100.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 073281B4218 for ; Thu, 22 Oct 2015 14:16:22 -0700 (PDT) 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=aOAZQgPJwOMgcPggRzTmzf7vSQpp6Q/XK0g/ztBi4TQ=; b=kUVfoF1TPdUMVdAo+Uxdxt7zjrgulJ45rGa3B/hh+qd26t9yEVpBzcti61IO8SEMVrqCjtUBJeveCI4KfVf1Lxgi73xTwOjv5kZxUZs+Hm9tHLBKNmF2KoymGhvNy2D0TZEEQvVisg7Uj2JJkM2QAlT874iKG5v+pNLFOg+kUaQ= 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.306.13; Thu, 22 Oct 2015 21:16:20 +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.0300.010; Thu, 22 Oct 2015 21:16:20 +0000 From: Brian Raymor To: "webpush@ietf.org" Thread-Topic: Subscription Sets - Pull Request Thread-Index: AdENDOKqfSNDm5A+RAKdgWgblmEh8Q== Date: Thu, 22 Oct 2015 21:16:20 +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:b086:624f:3977:518f] x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0648; 5:cJi2WoFOMb3rucpNGHhsgDONI894aOKD/+q41NKYo1UuBQJ5Z6HJEJaNvAh01L4V3+AG27yTbOZIEa6FZYOquzIAIZTJ333pdAYXIkZFKoe7d4PROKdbJWM+N1NhKnxBjxmG6NNfbI/obx8CFmo11w==; 24:b6GohxrKd8Fi9rGMkjW3Y28Cb79vcLr/x5d5I2ZWHqk6zqPqbDjHHh90E5GkcZhLH/gs9vu1HL7JZCMN/5oSnVeZ+6YM5koTnBoEojPJ4f0=; 20:/N2yGDfKMj/4NV4F/PA7Zw7GCroLoUOiFOiH/xMxxtgztkDMdGQw0UYb96mRV8Y9dE5jcI9pPwFd0iKFekTInQ== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42140001); SRVR:BY2PR0301MB0648; 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)(8121501046)(520078)(5005006)(3002001)(102215026)(61426024)(61427024); SRVR:BY2PR0301MB0648; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0648; x-forefront-prvs: 0737B96801 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(199003)(102836002)(11100500001)(92566002)(5002640100001)(2900100001)(15975445007)(19300405004)(81156007)(5004730100002)(5007970100001)(5005710100001)(77096005)(10400500002)(74316001)(97736004)(10290500002)(76576001)(2501003)(8990500004)(450100001)(5008740100001)(40100003)(561944003)(10090500001)(87936001)(33656002)(5001960100002)(122556002)(110136002)(189998001)(5003600100002)(16236675004)(107886002)(101416001)(19580395003)(5001920100001)(19617315012)(86612001)(19625215002)(86362001)(54356999)(99286002)(50986999)(105586002)(2351001)(229853001)(106356001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0648; 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_BY2PR0301MB064742BE4C5A797250D3F19983270BY2PR0301MB0647_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2015 21:16:20.7576 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0648 Archived-At: Subject: [Webpush] Subscription Sets - Pull Request 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, 22 Oct 2015 21:16:26 -0000 --_000_BY2PR0301MB064742BE4C5A797250D3F19983270BY2PR0301MB0647_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've started a pull request for subscription sets for discussion at IETF 94= - https://github.com/webpush-wg/webpush-protocol/pull/53 - I'd appreciate = any early feedback prior to the meeting. The main open issue is how to corr= elate two different subscriptions. The pull request is based on the earlier proposal from IETF 93 - http://www= .ietf.org/mail-archive/web/webpush/current/msg00272.html - and subsequent r= elated issues - https://github.com/webpush-wg/webpush-protocol/issues?q=3Di= s%3Aopen+is%3Aissue+label%3A%22subscription+sets%22 ...Brian --_000_BY2PR0301MB064742BE4C5A797250D3F19983270BY2PR0301MB0647_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

I’ve started a pull request for subscription s= ets for discussion at IETF 94 - https://= github.com/webpush-wg/webpush-protocol/pull/53 - I’d appreciate a= ny early feedback prior to the meeting. The main open issue is how to corre= late two different subscriptions.

 

The pull request is based on the earlier proposal= from IETF 93 - http://www.ietf.org/mail-archive/web/webpush/current/msg00272.html = - and subsequent related issues - https://github.com/webpush-wg/webpush-protocol/issues?q=3Dis%3Aopen+is%= 3Aissue+label%3A%22subscription+sets%22

 

 

…Brian

 

 

--_000_BY2PR0301MB064742BE4C5A797250D3F19983270BY2PR0301MB0647_-- From nobody Thu Oct 22 20:48:20 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2F81ACE53 for ; Thu, 22 Oct 2015 20:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psLvZRH5eQvg for ; Thu, 22 Oct 2015 20:48:16 -0700 (PDT) Received: from gator4135.hostgator.com (gator4135.hostgator.com [192.185.4.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6890F1ACE52 for ; Thu, 22 Oct 2015 20:48:16 -0700 (PDT) Received: from [50.174.96.154] (port=37686 helo=[192.168.1.3]) by gator4135.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.85) (envelope-from ) id 1ZpTKx-0008fG-7E for webpush@ietf.org; Thu, 22 Oct 2015 22:48:15 -0500 From: Shida Schubert Content-Type: multipart/alternative; boundary="Apple-Mail=_78FC8D20-35B7-48EE-B8A0-DD2FFC573F8F" Message-Id: <329B7428-AF84-4405-BEE3-CA2EACD70BF7@ntt-at.com> Date: Thu, 22 Oct 2015 20:48:14 -0700 To: webpush@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator4135.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source-IP: 50.174.96.154 X-Exim-ID: 1ZpTKx-0008fG-7E X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.3]) [50.174.96.154]:37686 X-Source-Auth: shida@agnada.com X-Email-Count: 5 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== Archived-At: Subject: [Webpush] Agenda for IETF94 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, 23 Oct 2015 03:48:18 -0000 --Apple-Mail=_78FC8D20-35B7-48EE-B8A0-DD2FFC573F8F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All; Agenda is uploaded.=20 https://datatracker.ietf.org/meeting/94/agenda/webpush/ = Shida as co-chair= --Apple-Mail=_78FC8D20-35B7-48EE-B8A0-DD2FFC573F8F Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

All;

Agenda is uploaded. 


Shida as co-chair
--Apple-Mail=_78FC8D20-35B7-48EE-B8A0-DD2FFC573F8F-- From nobody Fri Oct 23 14:24: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 4FE291B2A04 for ; Fri, 23 Oct 2015 14:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 T7mrd_i5q8L7 for ; Fri, 23 Oct 2015 14:24:44 -0700 (PDT) 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 8A20A1B29F8 for ; Fri, 23 Oct 2015 14:24:41 -0700 (PDT) Received: by wicll6 with SMTP id ll6so47321911wic.0 for ; Fri, 23 Oct 2015 14:24:40 -0700 (PDT) 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=8xMkUCHc9GnP4v9BV+JrBdmEx0Ws4yikRmhgfKYAJoA=; b=gNIXY3CF+BSstURPoCVCewXBrssObOXqvkdmTfMx+k9nBwAj9Ph+B9Ph8dAh313p6s mPrht9Qpr50A1G8zOupU1bVwjTqNBW8IUGCZoj2CavccbJ3FIiaFmb0PrIZvPo3xER4g o/cQ6zKoDzMzEUiDNRaVCUr08XPmXBqTN++glFGdL2q2sprLfOphIjfkT3mZiyndeCKP OCxoVZxWlwHX44fhMSumqUXYh8cV5ZQGIa/43SXcPKMk0jyCKLPuH0gHBTsBjy9TPxaa AojFBGimzWMK+1c0oEYAYwoKKlw1dGz1hLVz3M41r1qZ3iogzVXR9IqrR5oqv3IFlutw 4C/g== 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=8xMkUCHc9GnP4v9BV+JrBdmEx0Ws4yikRmhgfKYAJoA=; b=fcBe2/7QjWAdwlm7AYX+yNrC8IVsvj0c+WWRd/oDaRiySpb4Aw5/YGgU2/W3W4efY0 xi0azzF8/gU3iVYzgAbZf2RxUp12Fteyrs64IoxwBis3GpVk3Ds/4+JovU3Rlkdg/Jz5 6YESqPXKDa4koXPzTF/tUUH/IN8RIAgjievBbUXt7H3HaWCUwTGUFM17ZdPL+GhnHN3y fmpBWaDmyNRBo4XZW2E1IJLjvgU3tHvU2F/Zpbb1kuGrODOhiVVBlKW3DxH9T3sxDCnU bSo+hgLt/iCMx47fA4lu2dvnJyDqJr6xzHIvFnzmDZx1Gkv6w5EP5UvER+LUF8wJOUrQ ZFYw== X-Gm-Message-State: ALoCoQkcZVEP49+nU+anr0Y6UtI9ppCnFE3H40rlfw9t4ojY3HlAy3AwU89PxOqaYe3oa+rQD0sU MIME-Version: 1.0 X-Received: by 10.194.82.193 with SMTP id k1mr6573581wjy.143.1445635480029; Fri, 23 Oct 2015 14:24:40 -0700 (PDT) Received: by 10.27.155.207 with HTTP; Fri, 23 Oct 2015 14:24:39 -0700 (PDT) In-Reply-To: References: Date: Fri, 23 Oct 2015 14:24:39 -0700 Message-ID: From: Benjamin Bangert To: Brian Raymor Content-Type: multipart/alternative; boundary=047d7bb04a62432fa50522cc3d6f Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Subscription Sets - Pull Request 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, 23 Oct 2015 21:24:47 -0000 --047d7bb04a62432fa50522cc3d6f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable -- copying my comments on the github PR here Why is the receipt URL now included on every PUSH message frame? The client should already know the receipt URL from the original subscription request, no? re: SHOULD for using subscription set URL vs. subscription URL Could this be 'MUST'? Here's my rationale for why. If its should, then I must maintain multiple indexes on every message for a subscription set. One for the subscription URL, and one for the subscription set. At scale, this is extremely expensive. I planned on dumping all notifications to the same subscription set, into a single bucket. If I need to provide access based on the subscription URL separate from the set URL, then I'll need an additional index. As an additional gotcha if its SHOULD, a client may ask for a subscription set and an individual subscription in the set at the same time, which could result in some odd situations where its likely the client will get dupes of messages since the server could dump what it has under both overlapping concerns before any ack's are received. Overall I like how this looks. The PENDING section on how a server might know to attach new subscription requests to an existing subscription set could be resolved by requiring a client upon connecting to immediately request delivery of a notification set before asking for new subscriptions. This way the connection handler can associate the subscription set with the connection, and a server may then associate new subscriptions with the outstanding subscription set request. This could also provide a client with a way to manage 'groups' of subscription sets, since it could assume that the last subscription set it asked for is what new subscriptions on that connection will be attached to. This could be useful for the IoT use-cases where a client might want to have some input on which subscriptions are grouped together. Martin points out that this could also be handled by having a client include a subscription set in the request. I like that approach as well. Cheers, Ben On Thu, Oct 22, 2015 at 2:16 PM, Brian Raymor wrote: > > > I=E2=80=99ve started a pull request for subscription sets for discussion = at IETF > 94 - https://github.com/webpush-wg/webpush-protocol/pull/53 - I=E2=80=99d > appreciate any early feedback prior to the meeting. The main open issue i= s > how to correlate two different subscriptions. > > > > The pull request is based on the earlier proposal from IETF 93 - > http://www.ietf.org/mail-archive/web/webpush/current/msg00272.html - and > subsequent related issues - > https://github.com/webpush-wg/webpush-protocol/issues?q=3Dis%3Aopen+is%3A= issue+label%3A%22subscription+sets%22 > > > > > > =E2=80=A6Brian > > > > > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > > --047d7bb04a62432fa50522cc3d6f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
-- copying my comments on the github PR here
=
Why is the receipt URL now included on every PUSH message frame? = The client should already know the receipt URL from the original subscripti= on request, no?

re: SHOULD for using subscription set URL vs. = subscription URL

Could this be 'MUST'? Here's my rationale for why.= If its=20 should, then I must maintain multiple indexes on every message for a=20 subscription set. One for the subscription URL, and one for the=20 subscription set. At scale, this is extremely expensive. I planned on=20 dumping all notifications to the same subscription set, into a single=20 bucket. If I need to provide access based on the subscription URL=20 separate from the set URL, then I'll need an additional index.

As an additional gotcha if its SHOULD, a client may ask for a subscription set and an individual subscription in the set at the=20 same time, which could result in some odd situations where its likely=20 the client will get dupes of messages since the server could dump what=20 it has under both overlapping concerns before any ack's are received.

Overall I like how this looks. The PENDING section on how a server might know to attach new subscription requests to an existing=20 subscription set could be resolved by requiring a client upon connecting to immediately request delivery of a notification set before asking for new subscriptions. This way the connection handler can associate the=20 subscription set with the connection, and a server may then associate=20 new subscriptions with the outstanding subscription set request. This=20 could also provide a client with a way to manage 'groups' of=20 subscription sets, since it could assume that the last subscription set=20 it asked for is what new subscriptions on that connection will be=20 attached to.

This could be useful for the IoT use-cases where a client might want=20 to have some input on which subscriptions are grouped together.

Martin points out that this could also be handled by having a client in= clude a subscription set in the request. I like that approach as well.
<= /div>
Cheers,
Ben
=20

On Thu, Oct 22, 2015 at 2:16 PM, Brian Raymor <Brian.Raymor@= microsoft.com> wrote:

=C2=A0

I=E2=80=99ve started a pull request for subscription= sets for discussion at IETF 94 - https://github.com/webpush-wg/webpush-protocol/pull/53 - I= =E2=80=99d appreciate any early feedback prior to the meeting. The main ope= n issue is how to correlate two different subscriptions.

=C2=A0

The pull request is based on the earlier proposal from IETF 93 - http://www.ietf.org/mail-archive/web/webpush/current/= msg00272.html - and subsequent related issues - https://github.com/webpush-wg/webpush-protocol/issues?q=3Dis%3Aopen+is%3Ais= sue+label%3A%22subscription+sets%22

=C2=A0

=C2=A0

=E2=80=A6Brian

=C2=A0

=C2=A0


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


--047d7bb04a62432fa50522cc3d6f-- From nobody Fri Oct 23 15:15: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 4C63B1B2D27 for ; Fri, 23 Oct 2015 15:15:14 -0700 (PDT) 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 Zk2x2u59V4Ds for ; Fri, 23 Oct 2015 15:15:12 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0775.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:775]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7F911B2D1C for ; Fri, 23 Oct 2015 15:15:11 -0700 (PDT) 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=vwVgcCQqfP0946IYD9NE6ewGDhY/9IzrV7HzxJVJ85c=; b=EdRaNT1WEQOZNUAR5Q6Qi8rHllnY/KIo4OzJOmkhjT3zkB3vM92XK444Uy0mlcXA+yLTDgoXhHp2pGBGtnrseZsU4b9/RyiUeBIKV8u1UJAlLRq5yGyUV5zfneXRnIPXZVJa6csAPDcUfwB2MeHXGBLRrLwtAgvVJH+aJOJCSBA= 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.306.13; Fri, 23 Oct 2015 22:14:50 +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.0306.003; Fri, 23 Oct 2015 22:14:50 +0000 From: Brian Raymor To: Benjamin Bangert Thread-Topic: [Webpush] Subscription Sets - Pull Request Thread-Index: AdENDOKqfSNDm5A+RAKdgWgblmEh8QAzFaWAAAAhp5A= Date: Fri, 23 Oct 2015 22:14:50 +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: [2601:600:8000:5a8:a991:fd36:d5f3:19e] x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0646; 5:26MnhMyiUnPmiL/HKi3ZB/jWbb5cmkIvDAW+CMvC7h1uIKxsq/KNPAeEORTAMuUtXKteKNynYQV/wwn0dOHf+xqWwCMTo2kgAPdfMtAu7Ee5Notr158+amxjPXHcyTgnZQk/N3PuCFvTFFHR2j+GJQ==; 24:vhLXGFxNuHpeoebvlANt4D1cbUCd7bNxsJEYP2c3eQMg87/RSWBHaxFLZo/LCf8d44R6lnkrr8KY8Gy1Hs+Hzl7VhYhkbu7SM1jw+RkJh+g=; 20:7xcVx6hkm7yWt9u43iRs9j9J6sf42WbwGtlsxbMZ88wH9CqhtfbJPpJGy4+jCsqEbklrCztAtYxZ+XaCoJHuaQ== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42140001); SRVR:BY2PR0301MB0646; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(102215026)(61426024)(61427024); SRVR:BY2PR0301MB0646; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0646; x-forefront-prvs: 0738AF4208 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(189002)(199003)(5003600100002)(86612001)(10090500001)(189998001)(101416001)(74316001)(86362001)(87936001)(40100003)(5890100001)(19580395003)(19580405001)(33656002)(5002640100001)(105586002)(2900100001)(5008740100001)(76176999)(5001960100002)(81156007)(102836002)(54356999)(106356001)(122556002)(76576001)(50986999)(5005710100001)(11100500001)(10290500002)(92566002)(5004730100002)(5007970100001)(97736004)(10400500002)(8990500004)(15975445007)(2950100001)(99286002)(77096005)(110136002)(3826002); 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2015 22:14:50.4397 (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] Subscription Sets - Pull Request 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, 23 Oct 2015 22:15:14 -0000 T24gT2N0b2JlciAyMyAyMDE1IGF0IDI6MjUgUE0sIEJlbmphbWluIEJhbmdlcnQgPGJiYW5nZXJ0 QG1vemlsbGEuY29tPiB3cm90ZToNCg0KPiByZTogU0hPVUxEIGZvciB1c2luZyBzdWJzY3JpcHRp b24gc2V0IFVSTCB2cy4gc3Vic2NyaXB0aW9uIFVSTA0KPiBDb3VsZCB0aGlzIGJlICdNVVNUJz8g DQoNCk1hcnRpbiByZW1lbWJlcmVkIHRoYXQgd2UgZGlzY3Vzc2VkIGEgcmVkaXJlY3QgaW4gUHJh Z3VlOg0KICBodHRwczovL2dpdGh1Yi5jb20vd2VicHVzaC13Zy93ZWJwdXNoLXByb3RvY29sL2lz c3Vlcy81NS4gDQoNCkknbGwgdXBkYXRlIHRoZSBwdWxsIHJlcXVlc3QuIA0KDQo+IFRoZSBQRU5E SU5HIHNlY3Rpb24gb24gaG93IGEgc2VydmVyIG1pZ2h0IGtub3cgdG8gYXR0YWNoIG5ldyBzdWJz Y3JpcHRpb24gcmVxdWVzdHMNCj4gdG8gYW4gZXhpc3Rpbmcgc3Vic2NyaXB0aW9uIHNldCBjb3Vs ZCBiZSByZXNvbHZlZCBieSByZXF1aXJpbmcgYSBjbGllbnQgdXBvbiBjb25uZWN0aW5nDQo+IHRv IGltbWVkaWF0ZWx5IHJlcXVlc3QgZGVsaXZlcnkgb2YgYSBub3RpZmljYXRpb24gc2V0IGJlZm9y ZSBhc2tpbmcgZm9yIG5ldyBzdWJzY3JpcHRpb25zLiANCg0KVGhhdCBzb3VuZHMgbGlrZSB0aGUg cmVnaXN0cmF0aW9uIHN0ZXAgdGhhdCB3ZSBlbGltaW5hdGVkIHByaW9yIHRvIHB1Ymxpc2hpbmcg LTAwLiBBcyB5b3UndmUNCnN1Z2dlc3RlZCBvbiBsaXN0LCB0aGUgY29ycmVsYXRvciBjb3VsZCBi ZSB0aGUgY29ubmVjdGlvbi4gSXQgY291bGQgYWxzbyBiZSBzb21lIGZvcm0gb2YgDQphdXRoZW50 aWNhdGlvbi4gVGhpcyBtYXkgYmUgZGVwZW5kZW50IG9uIHRoZSBwdXNoIHNlcnZpY2UgaW1wbGVt ZW50YXRpb24uDQoNCj4gTWFydGluIHBvaW50cyBvdXQgdGhhdCB0aGlzIGNvdWxkIGFsc28gYmUg aGFuZGxlZCBieSBoYXZpbmcgYSBjbGllbnQgaW5jbHVkZSBhIHN1YnNjcmlwdGlvbg0KPiBzZXQg aW4gdGhlIHJlcXVlc3QuIEkgbGlrZSB0aGF0IGFwcHJvYWNoIGFzIHdlbGwuDQoNCldlIGluaXRp YWxseSBjb25zaWRlcmVkIHRoaXMgYXBwcm9hY2ggaW4gUHJhZ3VlLCBidXQgZGlzY292ZXJlZCB0 aGF0IGl0J3MgZnJhZ2lsZS4gRm9yIGV4YW1wbGUsIHdoYXQgaGFwcGVucyBpZiB0aGUgY2xpZW50 IGRvZXMgbm90IGluY2x1ZGUgdGhlIHJlcXVpcmVkIHN1YnNjcmlwdGlvbiBzZXQgbGluaz8NCiAN Cg== From nobody Fri Oct 23 15:17:02 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B28F31B2D3E for ; Fri, 23 Oct 2015 15:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxYKxPxawEFh for ; Fri, 23 Oct 2015 15:17:00 -0700 (PDT) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002: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 6A9781B2D3C for ; Fri, 23 Oct 2015 15:17:00 -0700 (PDT) Received: by yknn9 with SMTP id n9so134437344ykn.0 for ; Fri, 23 Oct 2015 15:16:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wzrYiSGDt727RRhQ74LwY/2JiKp4i4zhJSURFP9skc4=; b=IGrBJ+1KCxDKlEGhFdi4Wv/h5/dNDj4gnVJOPc4Ap95D4UnTeea+7ONF+cauaZtF5K ++MRPWV4yI2w4WIGSysHLHlDqi6E+JveRmfZhcwuzwkgUvOR4cY7Nh1SEYPNKOMh59yH /F9HOEg1NZ7UJlvIibyHvrJ76wltN5KmhrD6vTrKdbWZCi6RoGbAYTMZGlRf9LgWiSY0 7i1zY4tA+WlmAhkBw+YlI6wBbiaP+RHgYbX8GUAP1Dcqo8kZbHOyKYG3O/I8KeRVoPNR IxhWrLiyCnJ9DeYfKMmHUkgong9Zgm336NUDjJYChGVVd3/tAnsYEC5CWSGesQON+T/6 8HnQ== MIME-Version: 1.0 X-Received: by 10.129.80.85 with SMTP id e82mr8351255ywb.105.1445638619793; Fri, 23 Oct 2015 15:16:59 -0700 (PDT) Received: by 10.129.132.145 with HTTP; Fri, 23 Oct 2015 15:16:59 -0700 (PDT) In-Reply-To: References: Date: Fri, 23 Oct 2015 15:16:59 -0700 Message-ID: From: Martin Thomson To: Brian Raymor Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Benjamin Bangert , "webpush@ietf.org" Subject: Re: [Webpush] Subscription Sets - Pull Request 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, 23 Oct 2015 22:17:01 -0000 On 23 October 2015 at 15:14, Brian Raymor wrote: > We initially considered this approach in Prague, but discovered that it's fragile. For example, what happens if the client does not include the required subscription set link? I don't think that's fragility, that's a feature. If the server thinks that a user agent is acting badly and not including these links, it can (and should) limit the number of subscriptions it is willing to create on a given connection. From nobody Fri Oct 23 16:49: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 E4DFC1B2AC5 for ; Fri, 23 Oct 2015 16:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 nfU47eN79nbJ for ; Fri, 23 Oct 2015 16:49:50 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAA6A1B2AA9 for ; Fri, 23 Oct 2015 16:49:49 -0700 (PDT) Received: by wicll6 with SMTP id ll6so50370514wic.1 for ; Fri, 23 Oct 2015 16:49:48 -0700 (PDT) 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=4Wi+S4xIV5rZ/SYmDOIGwYtahzJyTyaboyJoG7L0Qro=; b=yQO8yoeVkhp4KYphq0OloAzgr0kpAr0kKTP1rpszyfSVl0CO3ds6hP7lD2aPnyNahh OyFFn557E/NR7Tc4cryfMCtgFCjMl8LsSFk5sfd3PGfd1lzeKCu737pFWVud2BryWyQ7 BXG7iFb6QD49eJfCxIFjEPcsUrYIGj0fgHZz4WF+GWEa2URHcNxj/7wUnweapF2B24sp Wpa+yQu8hIUzQvabYMULfyRNzUOoIVHyOH5loBpGOc6NvGddgfLYxAcy1EYyNIZn0ZMm zOVsA8sBy9QxfNFBMaNe4WsTCUbtvyPoEdHx0yZpLARdcC9sL8E++6ve8WxdFm0eJxtJ 5/XQ== 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=4Wi+S4xIV5rZ/SYmDOIGwYtahzJyTyaboyJoG7L0Qro=; b=mvtpP3P8+ChtxZZSTsZ3mc+62MTBGPnseinG4wB6YDSIKSCvDYd7y8F9j+1FxrZlmV 0v1IqxxI2wofuDvh4lfemSTFvgqthDAxDwhrYWYO/2eTRzNYR8ysKvbjRevtLh+X4875 IsgYD0wlxv0cYPi6aZbuAR7mAG9OLPjTOYL+WajeF2LxxbfGBYPtfKaXDDifnJO1wNX6 oEWjBb0zJzcAXaY2Hf3kvdn2pHlg7NomymI84bTox0mbI1yPIS9tZRdAg3vEe8xSBjgh 4YSXP+foQ+gecJfyoyllHOy0u9ZE8f0XhN79k48klvixSa0OzTo6eRwbtIp2viVdlJiV Ml7g== X-Gm-Message-State: ALoCoQmCvAW1aKUP3+K/tmPsZHLEQ26SQWvlHu6xzowf09bQ6I0TzU3Wtn32QGIirlGEsfhKJFLe MIME-Version: 1.0 X-Received: by 10.180.208.100 with SMTP id md4mr7016518wic.41.1445644188366; Fri, 23 Oct 2015 16:49:48 -0700 (PDT) Received: by 10.27.155.207 with HTTP; Fri, 23 Oct 2015 16:49:48 -0700 (PDT) In-Reply-To: References: Date: Fri, 23 Oct 2015 16:49:48 -0700 Message-ID: From: Benjamin Bangert To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11c38e2651dc100522ce44cd Archived-At: Cc: Brian Raymor , "webpush@ietf.org" Subject: Re: [Webpush] Subscription Sets - Pull Request 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, 23 Oct 2015 23:49:52 -0000 --001a11c38e2651dc100522ce44cd Content-Type: text/plain; charset=UTF-8 If the client fails to include it, then the server will make a new subscription set. It's the clients problem that the simultaneous stream limit is going to restrict it to listening to a single subscription set at a time if it wants a free command channel. On Fri, Oct 23, 2015 at 3:16 PM, Martin Thomson wrote: > On 23 October 2015 at 15:14, Brian Raymor > wrote: > > We initially considered this approach in Prague, but discovered that > it's fragile. For example, what happens if the client does not include the > required subscription set link? > > I don't think that's fragility, that's a feature. If the server > thinks that a user agent is acting badly and not including these > links, it can (and should) limit the number of subscriptions it is > willing to create on a given connection. > --001a11c38e2651dc100522ce44cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If the client fails to include it, then the server will ma= ke a new subscription set. It's the clients problem that the simultaneo= us stream limit is going to restrict it to listening to a single subscripti= on set at a time if it wants a free command channel.

On Fri, Oct 23, 2015 at 3:16 P= M, Martin Thomson <martin.thomson@gmail.com> wrote:
On 23 October 2015 at 15:= 14, Brian Raymor <Brian.Ra= ymor@microsoft.com> wrote:
> We initially considered this approach in Prague, but discovered that i= t's fragile. For example, what happens if the client does not include t= he required subscription set link?

I don't think that's fragility, that's a feature.=C2=A0 = If the server
thinks that a user agent is acting badly and not including these
links, it can (and should) limit the number of subscriptions it is
willing to create on a given connection.

--001a11c38e2651dc100522ce44cd-- From nobody Fri Oct 23 20:17: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 217651A9040 for ; Fri, 23 Oct 2015 20:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TRjVkqVAHnV for ; Fri, 23 Oct 2015 20:17:20 -0700 (PDT) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::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 1527E1A89C4 for ; Fri, 23 Oct 2015 20:17:20 -0700 (PDT) Received: by ykba4 with SMTP id a4so132814841ykb.3 for ; Fri, 23 Oct 2015 20:17:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qsE0v9po4jZbweyXLiGcpdoKpxVyq+fSx7rVZkozKQo=; b=JXNDMXl/rNNUT8sjLJbyEDa87ZuYxdQXA6TUVmlmkGVUek1H6S96R25cWXhM+KlEJu kd41aoRpXLmalUanJcXoSWoguYAWYE70LlLKF//KsKuL7iPxr3qxQ/oYIUq10ERvmPfM v7WBGAWzKKJi/CWBRzAog24OnP9PYa0PAFftHUyvzlvVZzqLG4kdRePhyIx+pe6+2VKT yaG9FdDKB0C3aAsrnBNsPrfGIcRa1CdCTwVCMQMOV2Y29AfooROeFHjioZbYUolvn84d NWjhkfzOPJfZ40RkDkOOD+V2UGSRJ3m3jcZVelRmGLLZEdBlMqpnn9sGev+Ry/KuQ3QS M/2A== MIME-Version: 1.0 X-Received: by 10.129.79.132 with SMTP id d126mr2112038ywb.159.1445656639414; Fri, 23 Oct 2015 20:17:19 -0700 (PDT) Received: by 10.129.132.145 with HTTP; Fri, 23 Oct 2015 20:17:19 -0700 (PDT) In-Reply-To: References: Date: Fri, 23 Oct 2015 20:17:19 -0700 Message-ID: From: Martin Thomson To: Benjamin Bangert Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Brian Raymor , "webpush@ietf.org" Subject: Re: [Webpush] Subscription Sets - Pull Request X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2015 03:17:22 -0000 That's true, if the server is using limited concurrency, then the client will suffer for forgetting. I think that the answer here is as we already have: a very strong recommendation to do what is necessary to reuse subscription sets. On 23 October 2015 at 16:49, Benjamin Bangert wrote: > If the client fails to include it, then the server will make a new > subscription set. It's the clients problem that the simultaneous stream > limit is going to restrict it to listening to a single subscription set at a > time if it wants a free command channel. > > On Fri, Oct 23, 2015 at 3:16 PM, Martin Thomson > wrote: >> >> On 23 October 2015 at 15:14, Brian Raymor >> wrote: >> > We initially considered this approach in Prague, but discovered that >> > it's fragile. For example, what happens if the client does not include the >> > required subscription set link? >> >> I don't think that's fragility, that's a feature. If the server >> thinks that a user agent is acting badly and not including these >> links, it can (and should) limit the number of subscriptions it is >> willing to create on a given connection. > > From nobody Tue Oct 27 19:30:23 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 53CDA1B413D for ; Tue, 27 Oct 2015 19:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.226 X-Spam-Level: X-Spam-Status: No, score=0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDoT4-bdeL6P for ; Tue, 27 Oct 2015 19:30:20 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 2E00B1B4139 for ; Tue, 27 Oct 2015 19:30:19 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id t9S2UHZx001590; Tue, 27 Oct 2015 20:30:17 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Tue, 27 Oct 2015 20:30:17 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([::1]) by EXCHANGE.cablelabs.com ([::1]) with mapi id 14.03.0224.002; Tue, 27 Oct 2015 20:30:15 -0600 From: Darshak Thakore To: Martin Thomson , Benjamin Bangert Thread-Topic: [Webpush] Subscription Sets - Pull Request Thread-Index: AdENDOKqfSNDm5A+RAKdgWgblmEh8QA/qEyAAAHArAAAABM5gAADPdkAAAc/V4AAuvBsAA== Date: Wed, 28 Oct 2015 02:30:14 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-originating-ip: [10.5.0.27] Content-Type: text/plain; charset="us-ascii" Content-ID: <0EF6EEB8AE38C84EBCD8ABD6212B0622@cablelabs.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Brian Raymor , "webpush@ietf.org" Subject: Re: [Webpush] Subscription Sets - Pull Request 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, 28 Oct 2015 02:30:21 -0000 I like the idea of keeping it as a strong recommendation instead of mandating.=20 There might be legitimate use cases (in IoT) where the client may want multiple subscription sets. Darshak On 10/23/15, 9:17 PM, "Webpush on behalf of Martin Thomson" wrote: >That's true, if the server is using limited concurrency, then the >client will suffer for forgetting. I think that the answer here is as >we already have: a very strong recommendation to do what is necessary >to reuse subscription sets. > >On 23 October 2015 at 16:49, Benjamin Bangert >wrote: >> If the client fails to include it, then the server will make a new >> subscription set. It's the clients problem that the simultaneous stream >> limit is going to restrict it to listening to a single subscription set >>at a >> time if it wants a free command channel. >> >> On Fri, Oct 23, 2015 at 3:16 PM, Martin Thomson >> >> wrote: >>> >>> On 23 October 2015 at 15:14, Brian Raymor >>> wrote: >>> > We initially considered this approach in Prague, but discovered that >>> > it's fragile. For example, what happens if the client does not >>>include the >>> > required subscription set link? >>> >>> I don't think that's fragility, that's a feature. If the server >>> thinks that a user agent is acting badly and not including these >>> links, it can (and should) limit the number of subscriptions it is >>> willing to create on a given connection. >> >> > >_______________________________________________ >Webpush mailing list >Webpush@ietf.org >https://www.ietf.org/mailman/listinfo/webpush From nobody Fri Oct 30 12:24:09 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 8FD061B3AE3 for ; Fri, 30 Oct 2015 12:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 T1pkMOcdgUNo for ; Fri, 30 Oct 2015 12:24:06 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c: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 C96711B3AE2 for ; Fri, 30 Oct 2015 12:24:05 -0700 (PDT) Received: by wikq8 with SMTP id q8so17500869wik.1 for ; Fri, 30 Oct 2015 12:24:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla_com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=iRzVtllCZgb/HzbXpxcYEscXN/pdUu7AVzdk9mLwomY=; b=ldr7kw+rRHou0lerFFrAP2FuNXDGYijRT7Vk62jVCaYfY8c0BhfDkvmxDFo85SSfzu 5fS8MZXgf+xjjaGwtiPdmanzyrJ7MRuh+Kn1odMtx8X8hX76Z0nyhjZ7rqeLpfGoNEuZ DTaj8jmkS3Li3tVkWUVYel73FNNHlCkh2TWPsVy0clDs0yOPP/GhUqaLD0M4HxNDJNSe Xx15MeHBRxe8N7r21tmqrhJQ6zYi/3nsjAxv4ccwnv1YNRZD/is7Jhtt55CVmX4keLOu tvt74Cc0eRgA2WhIekBbHLSDx9+eQin1QY5rvnf5kNfhKb2eUaPzmVPjfRAt08iavr3W tpsQ== 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=iRzVtllCZgb/HzbXpxcYEscXN/pdUu7AVzdk9mLwomY=; b=NOZdVTMEzZjV+OSeAa9woGBc1XdNAekLlrvspRWy4netjJkWTQsrZCpK7qwJWtkBTb OQmo0oH/LDUKZK1MG0VDY7nEDktMIEavoYb8uJiddok6Ql1eTEDf/Ho9ueqxr/MgbQjL 4l7CsGLbWc0QOfrVY0C/8n1ORHxVcF3RF+hpXjloUOX2qT39e+oZUgNf5kkGcdM3sxth 8EPx+1dcMMpkWoiKtv+JakHAm235LFd9VQ4/Wc7HurC8vICud/q7ZUOTFPb2vl+TfYYX kQSfYAOVpwoPiikZz7yZyXFZk0s4h8oeIlSbxKsWJU7YtKqysVtgKCi4LxXc9UqRYbR+ pypQ== X-Gm-Message-State: ALoCoQm8bpNDXGfuXLmoYCP1aok0wV2ctlQpWxQHPq5+lnAiGA2nDTR4+hZm6m6wlSMGo3xAgKz9 MIME-Version: 1.0 X-Received: by 10.194.63.7 with SMTP id c7mr10391651wjs.70.1446233044162; Fri, 30 Oct 2015 12:24:04 -0700 (PDT) Received: by 10.27.155.207 with HTTP; Fri, 30 Oct 2015 12:24:04 -0700 (PDT) Date: Fri, 30 Oct 2015 12:24:04 -0700 Message-ID: From: Benjamin Bangert To: "webpush@ietf.org" Content-Type: multipart/alternative; boundary=047d7b86d9ccdc409c0523575ef6 Archived-At: Subject: [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: Fri, 30 Oct 2015 19:24:07 -0000 --047d7b86d9ccdc409c0523575ef6 Content-Type: text/plain; charset=UTF-8 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. Cheers, Ben --047d7b86d9ccdc409c0523575ef6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It would be nice to have a uniform way to indica= te 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 s= tatus code, and/or a header indicating when the app-server should resume.
Cheers,
Ben
--047d7b86d9ccdc409c0523575ef6-- From nobody Fri Oct 30 13:32:51 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAFFA1A9092 for ; Fri, 30 Oct 2015 13:32:36 -0700 (PDT) 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, 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 4MutnVQr4z4A for ; Fri, 30 Oct 2015 13:32:31 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0732.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80DAB1A908B for ; Fri, 30 Oct 2015 13:32:31 -0700 (PDT) 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=BWFjybeNrFZItCxaEEentz56Z0TtcL+pML06oQhi8t0=; b=OeAAdW2ZNS3UwgXleo4GKth0yRydMn32x488GvK0EOuJdsKIP+TVuQi2jY3Rnec/z+ihyCBxxZABKq9hf7/SboE/94Y5os2+OaJnYSow+NvjK+Fup1leOsCFtHdZuSJaZ6nUUGztshMo0Ekq/S8VJYe5p90MN93X2HQpJmuEwfI= Received: from BN1PR0301MB0626.namprd03.prod.outlook.com (10.160.171.11) by BN1PR0301MB0643.namprd03.prod.outlook.com (10.160.171.16) with Microsoft SMTP Server (TLS) id 15.1.306.13; Fri, 30 Oct 2015 20:32:26 +0000 Received: from BN1PR0301MB0626.namprd03.prod.outlook.com ([10.160.171.11]) by BN1PR0301MB0626.namprd03.prod.outlook.com ([10.160.171.11]) with mapi id 15.01.0312.014; Fri, 30 Oct 2015 20:32:26 +0000 From: Elio Damaggio To: "webpush@ietf.org" Thread-Topic: [Coalesce] Concern about PUT creating a new push message Thread-Index: AdETUDgmcz11BanZQSalBLT5Y90ONw== Date: Fri, 30 Oct 2015 20:32:26 +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=elioda@microsoft.com; x-originating-ip: [2001:4898:80e8:4::2e9] x-microsoft-exchange-diagnostics: 1; BN1PR0301MB0643; 5:57vBhZFWLIundng/EYapcCQlMUd2/TCQOjM8wU8vIpgfOr5FykI/wE3xRnoWLssidYRoGXGvr3YPVgZGw/Q3+YP7WEx+xI2xytZo6TjzA7l1gZOjnNmamZh8Wgg8eizKBm9FKdPqmPtSS/fkLH+t9w==; 24:EKEwHhPG2soW9MwGAVin+fmJkylITt2JPEIzWYW/HVHIK5gu0HSybNirHkJuVm99u52wDwaxgyOcH2igbSlO4ueHpD761pJWTY8ufxoaEGI=; 20:lni2zuBdPGCX4keVr9ugm26PNjoHaHtr6ekBI68/GXwCeR5GD0DqbSJZVpiyVC4P1cf610PIPUbr+fs4pE1Pag== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR0301MB0643; 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)(520078)(5005006)(8121501046)(3002001)(10201501046)(102215026)(61426024)(61427024); SRVR:BN1PR0301MB0643; BCL:0; PCL:0; RULEID:; SRVR:BN1PR0301MB0643; x-forefront-prvs: 07459438AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(199003)(33656002)(106356001)(5008740100001)(561944003)(105586002)(19625215002)(4001430100002)(10710500006)(76576001)(101416001)(54356999)(74316001)(16236675004)(50986999)(99286002)(15975445007)(19580395003)(110136002)(86612001)(86362001)(97736004)(40100003)(19617315012)(5005710100001)(19300405004)(122556002)(189998001)(107886002)(2351001)(5001920100001)(87936001)(10290500002)(229853001)(2501003)(5004730100002)(7110500001)(10090500001)(2900100001)(2420400006)(8990500004)(5001960100002)(102836002)(5007970100001)(5002640100001)(11100500001)(5003600100002)(450100001)(92566002)(10400500002)(81156007)(77096005)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR0301MB0643; H:BN1PR0301MB0626.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_BN1PR0301MB06266C1F50CF432338E98764CB2F0BN1PR0301MB0626_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2015 20:32:26.5553 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR0301MB0643 Archived-At: Cc: Brian Raymor Subject: [Webpush] [Coalesce] Concern about PUT creating a new push message 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, 30 Oct 2015 20:32:37 -0000 --_000_BN1PR0301MB06266C1F50CF432338E98764CB2F0BN1PR0301MB0626_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Reviewing the current proposal for coalescing, I noticed this sentence. + However, a push service is encouraged + to treat an update for a removed push message as though the mess= age + were still present and consequently send the push message to the= user + agent. Permitting an update avoids the additional request requi= red to + retry and the associated delays. In my opinion, if the desired behavior is to be able to "update or insert" = in a logical "slot" (in the current proposal we are using the push message = location), I would prefer to explicitly call it out as something akin to GC= M "collapse-key" (https://developers.google.com/cloud-messaging/concept-opt= ions?hl=3Den#collapsible_and_non-collapsible_messages). The collapse-key is more aligned on what we are planning to implement in Az= ure. While I understand the cost of an additional concept, the current approach = has two negative consequences: 1) Application servers have to consider the optional behaviors on the = send side. a. Note that on the client side (given the raciness of message collaps= ing), server support for collapsing has little impact on the design of the = push handler. 2) It makes acknowledgement harder to process, as now the same push ca= n be acknowledged multiple times. a. This could be solved by returning a different push location in case= the PUT results in an insert, but that complicates the concept of a push i= d, and makes the interface very un-RESTful (?), as we use a PUT on resource= /a, to create a resource in /b. Thoughts? Elio --_000_BN1PR0301MB06266C1F50CF432338E98764CB2F0BN1PR0301MB0626_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Reviewing the current proposal for coalescing, I not= iced this sentence.

 

+        = ;  However, a push service is encouraged

+        = ;  to treat an update for a removed push message as though the message=

+        = ;  were still present and consequently send the push message to the us= er

+        = ;  agent.  Permitting an update avoids the additional request req= uired to

+        = ;  retry and the associated delays.

 

In my opinion, if the desired behavior is to be able= to “update or insert” in a logical “slot” (in the = current proposal we are using the push message location), I would prefer to= explicitly call it out as something akin to GCM “collapse-key” (https://developers.google= .com/cloud-messaging/concept-options?hl=3Den#collapsible_and_non-collapsibl= e_messages).

 

The collapse-key is more aligned on what we are plan= ning to implement in Azure.

 

While I understand the cost of an additional concept= , the current approach has two negative consequences:

1)      Application servers have to consider the optional b= ehaviors on the send side.

a.      Note that on the client side (given the raciness of= message collapsing), server support for collapsing has little impact on th= e design of the push handler.

2)      It makes acknowledgement harder to process, as now = the same push can be acknowledged multiple times.

a.      This could be solved by returning a different push = location in case the PUT results in an insert, but that complicates the con= cept of a push id, and makes the interface very un-RESTful (?), as we use a= PUT on resource /a, to create a resource in /b.

 

Thoughts?

 

Elio

--_000_BN1PR0301MB06266C1F50CF432338E98764CB2F0BN1PR0301MB0626_-- From nobody Fri Oct 30 15:16: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 A23651B319C for ; Fri, 30 Oct 2015 15:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 TKrRakcTKOwn for ; Fri, 30 Oct 2015 15:16:19 -0700 (PDT) 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 793A31ACE98 for ; Fri, 30 Oct 2015 15:16:18 -0700 (PDT) Received: by wmff134 with SMTP id f134so21718576wmf.0 for ; Fri, 30 Oct 2015 15:16:16 -0700 (PDT) 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=cmlHn2huX55yDJ/iUh7gsJpgEaBElCaSIzwi+9Aiw+E=; b=HEA6QXNrYalV5HcUBvgj5ck6UbNXLvHPXlbHXOqqFJMKOvARV7leMxI4z+29l/vEzG 1XA67lExcHevZLbykeoO2ToXiUxaTOUjGSWuwElZjJRYZ0M7GQFDuJ1A1cWMnYxlNls5 8iZkgsMqnfxaq+rQkADGsDsPxqJNdYywinME9821n41IDKj7yDhArn0m1wIMMHTUGXgE bjzh43pU/eb2QrMleZncHrVQJCZumSiGYcvwX4+amwME4k/slbDzsLXI9GGz31v6BvHT nhOMjv/TZk6Ulc6TJtWQ2bFS+Iw3I5cIx9SNtcQFAahz3eTNF9hqWI58vPAdJbnsb9qu mfoA== 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=cmlHn2huX55yDJ/iUh7gsJpgEaBElCaSIzwi+9Aiw+E=; b=ejklTE83pXKZ28DhZwc/eWhVSQGsxjfPLkrgqqhhM9G6BsFn6YecJODQhKnJCQNaiS Z+/XvJWBgqv/V7xXxB/6e41RDh6IY9SOx2cNEsyZTmWRETNMnympznHFibjCIjeBmZ8W tCjdrKj8Ga7mLgWpzpqY5YzdGPsnODKKh2SkAH2pDCBK8qDQr5zZdriJLBdZCKwHiHLk 5+4qXTtAG5W4ROg/e+hftruRQMzJ9+ilb1HBgt+RcykVuGsFTXSBmNJcATf/f4SnqfUt LU7dWvSK2m+B9+Kjzr7AUj1JIURP/oRse7oqSSb7qO/MOgZ8az06tqwFKjcT7rt4/PkM DU1Q== X-Gm-Message-State: ALoCoQn0ibZwa9tN78PQz+r2J79MNwk1G/0idKjH5uAE4HW85FSJY25ym7dhbUnFwBd/hN3QnPxC MIME-Version: 1.0 X-Received: by 10.28.217.18 with SMTP id q18mr529347wmg.10.1446243376705; Fri, 30 Oct 2015 15:16:16 -0700 (PDT) Received: by 10.27.155.207 with HTTP; Fri, 30 Oct 2015 15:16:16 -0700 (PDT) In-Reply-To: References: Date: Fri, 30 Oct 2015 15:16:16 -0700 Message-ID: From: Benjamin Bangert To: Elio Damaggio Content-Type: multipart/alternative; boundary=001a1146905eba5481052359c663 Archived-At: Cc: Brian Raymor , "webpush@ietf.org" Subject: Re: [Webpush] [Coalesce] Concern about PUT creating a new push message 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, 30 Oct 2015 22:16:21 -0000 --001a1146905eba5481052359c663 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I implemented this feature in our system and decided that I'd 404 the request. The app-server will have to re-send it as a new request, but the logic involved in making a new message (where it's found that we can't update it) was complex enough that it was cheaper to push the retry to the app-server. Your second point still exists. If a client has pulled the message, but not deleted it when the app-server sends an update then there's two possible behaviors: 1) The new message the app-server sent in just got deleted 2) The delete is ignored because its not the same message anymore In our case we choose option #2, the delete is ignored. We also don't plan on generating a receipt for the failed delete, and when the updated message is delivered, then the delete for it will work and the receipt will be sent= . I implemented this by tracking an additional internal message-id that is replaced everytime the message is updated, this prevents a client from deleting a message it got if it was just updated by the app-server. The side-effect of all this, is that a client will process multiple messages and send only the last receipt. I don't think that's too horrible because its an edge-case, it seems unlikely that it'll be common for an app-server to send in an update at just the right time for this. The logical slot is the unique message ID URL, which seemed adequate. Cheers, Ben On Fri, Oct 30, 2015 at 1:32 PM, Elio Damaggio wrote= : > Hi, > > > > Reviewing the current proposal for coalescing, I noticed this sentence. > > > > + However, a push service is encouraged > > + to treat an update for a removed push message as though the > message > > + were still present and consequently send the push message to > the user > > + agent. Permitting an update avoids the additional request > required to > > + retry and the associated delays. > > > > In my opinion, if the desired behavior is to be able to =E2=80=9Cupdate o= r insert=E2=80=9D > in a logical =E2=80=9Cslot=E2=80=9D (in the current proposal we are using= the push message > location), I would prefer to explicitly call it out as something akin to > GCM =E2=80=9Ccollapse-key=E2=80=9D ( > https://developers.google.com/cloud-messaging/concept-options?hl=3Den#col= lapsible_and_non-collapsible_messages > ). > > > > The collapse-key is more aligned on what we are planning to implement in > Azure. > > > > While I understand the cost of an additional concept, the current approac= h > has two negative consequences: > > 1) Application servers have to consider the optional behaviors on > the send side. > > a. Note that on the client side (given the raciness of message > collapsing), server support for collapsing has little impact on the desig= n > of the push handler. > > 2) It makes acknowledgement harder to process, as now the same push > can be acknowledged multiple times. > > a. This could be solved by returning a different push location in > case the PUT results in an insert, but that complicates the concept of a > push id, and makes the interface very un-RESTful (?), as we use a PUT on > resource /a, to create a resource in /b. > > > > Thoughts? > > > > Elio > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > > --001a1146905eba5481052359c663 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I implemented= this feature in our system and decided that I'd 404 the request. The a= pp-server will have to re-send it as a new request, but the logic involved = in making a new message (where it's found that we can't update it)= was complex enough that it was cheaper to push the retry to the app-server= .

Your second point still exists. If a client has pulled the m= essage, but not deleted it when the app-server sends an update then there&= #39;s two possible behaviors:
1) The new message the app-server se= nt in just got deleted
2) The delete is ignored because its not th= e same message anymore

In our case we choose option #2, the de= lete is ignored. We also don't plan on generating a receipt for the fai= led delete, and when the updated message is delivered, then the delete for = it will work and the receipt will be sent.

I implemented this = by tracking an additional internal message-id that is replaced everytime th= e message is updated, this prevents a client from deleting a message it got= if it was just updated by the app-server.

The side-effect of = all this, is that a client will process multiple messages and send only the= last receipt. I don't think that's too horrible because its an edg= e-case, it seems unlikely that it'll be common for an app-server to sen= d in an update at just the right time for this.

The logical sl= ot is the unique message ID URL, which seemed adequate.

Cheers= ,
Ben


On Fri, Oct 30, 2015 at 1:32 PM= , Elio Damaggio <elioda@microsoft.com> wrote:

Hi,

=C2=A0

Reviewing the current proposal for coalescing, I not= iced this sentence.

=C2=A0

+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 However, a push service is encouraged

+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 to treat an update for a removed push message as though the message<= /u>

+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 were still present and consequently send the push message to the user

+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 agent.=C2=A0 Permitting an update avoids the additional request require= d to

+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 retry and the associated delays.

=C2=A0

In my opinion, if the desired behavior is to be able= to =E2=80=9Cupdate or insert=E2=80=9D in a logical =E2=80=9Cslot=E2=80=9D = (in the current proposal we are using the push message location), I would p= refer to explicitly call it out as something akin to GCM =E2=80=9Ccollapse-= key=E2=80=9D (https:/= /developers.google.com/cloud-messaging/concept-options?hl=3Den#collapsible_= and_non-collapsible_messages).

=C2=A0

The collapse-key is more aligned on what we are plan= ning to implement in Azure.

=C2=A0

While I understand the cost of an additional concept= , the current approach has two negative consequences:

1)= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Application servers have to consider the optional beha= viors on the send side.

a.=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Note that on the client side (given the raciness of me= ssage collapsing), server support for collapsing has little impact on the d= esign of the push handler.

2)= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 It makes acknowledgement harder to process, as now the= same push can be acknowledged multiple times.

a.=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 This could be solved by returning a different push loc= ation in case the PUT results in an insert, but that complicates the concep= t of a push id, and makes the interface very un-RESTful (?), as we use a PU= T on resource /a, to create a resource in /b.

=C2=A0

Thoughts?

=C2=A0

Elio


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


--001a1146905eba5481052359c663-- From nobody Fri Oct 30 22:45:51 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0591A01AA for ; Fri, 30 Oct 2015 22:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tc0d4rQuwzEk for ; Fri, 30 Oct 2015 22:45:49 -0700 (PDT) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002: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 117511A0196 for ; Fri, 30 Oct 2015 22:45:48 -0700 (PDT) Received: by ykek133 with SMTP id k133so96423115yke.2 for ; Fri, 30 Oct 2015 22:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=2uQWYSOdilBSVtjJ3jrvlYIKh0wLCSMFN4v3mrWm4qo=; b=UbC5XvSwUStsT3FcMqhzgQHmzLkee78e4ysFtiLTlle99/5KW+0u/0NQeZ1uisVmQy I8RIhmdE1X1SDKba2J0rKAAutMVptXy1Bgku7KJA2+aWH1B37JmTRo1W4FJp9BF+3Qqu snHTYnuWEKTDB+j58628FN1jjoF0nbjOAOzbp84E1MN0y4S5PAqO4Rt3ZtMLem2crg5F vWyzdbr+dPWRSCtFXinaH0sRzOVV5TazQUPSb2c53e/TBVL0APbuhk9lNmA7MQd/HxNH 0Fb+EFtidsg9Ku4tVST+OnPwT8wZeMs93fVzTXMlO6S4dSLv8EJk1ULnRZLaQTcI3LmN 3CzQ== MIME-Version: 1.0 X-Received: by 10.129.79.132 with SMTP id d126mr8898015ywb.159.1446270348373; Fri, 30 Oct 2015 22:45:48 -0700 (PDT) Received: by 10.129.132.145 with HTTP; Fri, 30 Oct 2015 22:45:48 -0700 (PDT) In-Reply-To: References: Date: Sat, 31 Oct 2015 14:45:48 +0900 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" , Elio Damaggio Subject: Re: [Webpush] [Coalesce] Concern about PUT creating a new push message X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2015 05:45:51 -0000 There is an alternative, which is to have the collapse be a POST to a push message URL. If the message is present, the contents are updated, if the message was acknowledged, then a new message is created. Would that work? The only real downside to this is that it isn't idempotent. On 31 October 2015 at 07:16, Benjamin Bangert wrote: > I implemented this feature in our system and decided that I'd 404 the > request. The app-server will have to re-send it as a new request, but the > logic involved in making a new message (where it's found that we can't > update it) was complex enough that it was cheaper to push the retry to th= e > app-server. > > Your second point still exists. If a client has pulled the message, but n= ot > deleted it when the app-server sends an update then there's two possible > behaviors: > 1) The new message the app-server sent in just got deleted > 2) The delete is ignored because its not the same message anymore > > In our case we choose option #2, the delete is ignored. We also don't pla= n > on generating a receipt for the failed delete, and when the updated messa= ge > is delivered, then the delete for it will work and the receipt will be se= nt. > > I implemented this by tracking an additional internal message-id that is > replaced everytime the message is updated, this prevents a client from > deleting a message it got if it was just updated by the app-server. > > The side-effect of all this, is that a client will process multiple messa= ges > and send only the last receipt. I don't think that's too horrible because > its an edge-case, it seems unlikely that it'll be common for an app-serve= r > to send in an update at just the right time for this. > > The logical slot is the unique message ID URL, which seemed adequate. > > Cheers, > Ben > > > On Fri, Oct 30, 2015 at 1:32 PM, Elio Damaggio wro= te: >> >> Hi, >> >> >> >> Reviewing the current proposal for coalescing, I noticed this sentence. >> >> >> >> + However, a push service is encouraged >> >> + to treat an update for a removed push message as though the >> message >> >> + were still present and consequently send the push message to >> the user >> >> + agent. Permitting an update avoids the additional request >> required to >> >> + retry and the associated delays. >> >> >> >> In my opinion, if the desired behavior is to be able to =E2=80=9Cupdate = or insert=E2=80=9D >> in a logical =E2=80=9Cslot=E2=80=9D (in the current proposal we are usin= g the push message >> location), I would prefer to explicitly call it out as something akin to= GCM >> =E2=80=9Ccollapse-key=E2=80=9D >> (https://developers.google.com/cloud-messaging/concept-options?hl=3Den#c= ollapsible_and_non-collapsible_messages). >> >> >> >> The collapse-key is more aligned on what we are planning to implement in >> Azure. >> >> >> >> While I understand the cost of an additional concept, the current approa= ch >> has two negative consequences: >> >> 1) Application servers have to consider the optional behaviors on t= he >> send side. >> >> a. Note that on the client side (given the raciness of message >> collapsing), server support for collapsing has little impact on the desi= gn >> of the push handler. >> >> 2) It makes acknowledgement harder to process, as now the same push >> can be acknowledged multiple times. >> >> a. This could be solved by returning a different push location in >> case the PUT results in an insert, but that complicates the concept of a >> push id, and makes the interface very un-RESTful (?), as we use a PUT on >> resource /a, to create a resource in /b. >> >> >> >> Thoughts? >> >> >> >> Elio >> >> >> _______________________________________________ >> Webpush mailing list >> Webpush@ietf.org >> https://www.ietf.org/mailman/listinfo/webpush >> > > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > From nobody Fri Oct 30 22:46: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 51FD01A01E2 for ; Fri, 30 Oct 2015 22:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prub3e1qEzoc for ; Fri, 30 Oct 2015 22:46:23 -0700 (PDT) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002: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 8F51A1A01AA for ; Fri, 30 Oct 2015 22:46:23 -0700 (PDT) Received: by ykek133 with SMTP id k133so96429309yke.2 for ; Fri, 30 Oct 2015 22:46:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=3CWw/0w7ohNpQd+izUM0CJEYEVXl1XBJk/nl4SJ68Gs=; b=CP9cviM+qxHAXnDBZaLCCLoPqHI7L1gMkoQ1avGKEax0w5KR+xnlikmtfU/qbJ4uKK jfZM26yNuOQlZ1wC1bK1YFReoDnMD/6VFofCZ8wtNPDthvxs4gGi+1+kT+BF8fXLC9Cj K9i6kUk+LAv7sGRR8057MiSkW0bZlY+6uZ9yYUBhH1NmLnzVuQbEDY9mIJVRuKekbLgH en9vfEpe6LF2YRxz0NNU9CBUfQiuygjYdD2WXCHdIOtLgtDUbB57nSsZkom8GfPl0ein fx9PxWsJPrawCcpNVNh7vd2lPKMN/UbWZnbd5Ij2lPWQxYLvCXU3cGh+4lMnCoMhrstX 3C3A== MIME-Version: 1.0 X-Received: by 10.13.230.201 with SMTP id p192mr8808437ywe.43.1446270382967; Fri, 30 Oct 2015 22:46:22 -0700 (PDT) Received: by 10.129.132.145 with HTTP; Fri, 30 Oct 2015 22:46:22 -0700 (PDT) In-Reply-To: References: Date: Sat, 31 Oct 2015 14:46:22 +0900 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" , Elio Damaggio Subject: Re: [Webpush] [Coalesce] Concern about PUT creating a new push message X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2015 05:46:25 -0000 Oh, and it means that the recipient won't receive the collapse key. Though we could add something for that too. On 31 October 2015 at 14:45, Martin Thomson wrot= e: > There is an alternative, which is to have the collapse be a POST to a > push message URL. If the message is present, the contents are > updated, if the message was acknowledged, then a new message is > created. Would that work? > > The only real downside to this is that it isn't idempotent. > > On 31 October 2015 at 07:16, Benjamin Bangert wrot= e: >> I implemented this feature in our system and decided that I'd 404 the >> request. The app-server will have to re-send it as a new request, but th= e >> logic involved in making a new message (where it's found that we can't >> update it) was complex enough that it was cheaper to push the retry to t= he >> app-server. >> >> Your second point still exists. If a client has pulled the message, but = not >> deleted it when the app-server sends an update then there's two possible >> behaviors: >> 1) The new message the app-server sent in just got deleted >> 2) The delete is ignored because its not the same message anymore >> >> In our case we choose option #2, the delete is ignored. We also don't pl= an >> on generating a receipt for the failed delete, and when the updated mess= age >> is delivered, then the delete for it will work and the receipt will be s= ent. >> >> I implemented this by tracking an additional internal message-id that is >> replaced everytime the message is updated, this prevents a client from >> deleting a message it got if it was just updated by the app-server. >> >> The side-effect of all this, is that a client will process multiple mess= ages >> and send only the last receipt. I don't think that's too horrible becaus= e >> its an edge-case, it seems unlikely that it'll be common for an app-serv= er >> to send in an update at just the right time for this. >> >> The logical slot is the unique message ID URL, which seemed adequate. >> >> Cheers, >> Ben >> >> >> On Fri, Oct 30, 2015 at 1:32 PM, Elio Damaggio wr= ote: >>> >>> Hi, >>> >>> >>> >>> Reviewing the current proposal for coalescing, I noticed this sentence. >>> >>> >>> >>> + However, a push service is encouraged >>> >>> + to treat an update for a removed push message as though the >>> message >>> >>> + were still present and consequently send the push message to >>> the user >>> >>> + agent. Permitting an update avoids the additional request >>> required to >>> >>> + retry and the associated delays. >>> >>> >>> >>> In my opinion, if the desired behavior is to be able to =E2=80=9Cupdate= or insert=E2=80=9D >>> in a logical =E2=80=9Cslot=E2=80=9D (in the current proposal we are usi= ng the push message >>> location), I would prefer to explicitly call it out as something akin t= o GCM >>> =E2=80=9Ccollapse-key=E2=80=9D >>> (https://developers.google.com/cloud-messaging/concept-options?hl=3Den#= collapsible_and_non-collapsible_messages). >>> >>> >>> >>> The collapse-key is more aligned on what we are planning to implement i= n >>> Azure. >>> >>> >>> >>> While I understand the cost of an additional concept, the current appro= ach >>> has two negative consequences: >>> >>> 1) Application servers have to consider the optional behaviors on = the >>> send side. >>> >>> a. Note that on the client side (given the raciness of message >>> collapsing), server support for collapsing has little impact on the des= ign >>> of the push handler. >>> >>> 2) It makes acknowledgement harder to process, as now the same pus= h >>> can be acknowledged multiple times. >>> >>> a. This could be solved by returning a different push location in >>> case the PUT results in an insert, but that complicates the concept of = a >>> push id, and makes the interface very un-RESTful (?), as we use a PUT o= n >>> resource /a, to create a resource in /b. >>> >>> >>> >>> Thoughts? >>> >>> >>> >>> Elio >>> >>> >>> _______________________________________________ >>> Webpush mailing list >>> Webpush@ietf.org >>> https://www.ietf.org/mailman/listinfo/webpush >>> >> >> >> _______________________________________________ >> Webpush mailing list >> Webpush@ietf.org >> https://www.ietf.org/mailman/listinfo/webpush >> From nobody Sat Oct 31 15:04: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 41A271B3BC7 for ; Sat, 31 Oct 2015 15:04:58 -0700 (PDT) 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 WR1vI0LEsJzy for ; Sat, 31 Oct 2015 15:04:56 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0147.outbound.protection.outlook.com [207.46.100.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E4F71B3BC5 for ; Sat, 31 Oct 2015 15:04:56 -0700 (PDT) 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=eZPJZNeZuKZ6CO09i7ob1QlkcJ36lyL/ZKWo3Fs1F4w=; b=UMCxAdzA1knMcCacIb7nHLW/X/Da/hViWzyu7QRE2OOO/Xqz3/1smylvF90f2l41VerToWliOErElAk2ve9sNpBSBxeXrWf5Zmp1O0vLr/zaXGwKahavNA6kBi1hTqc+C3AA+nIEcfit9nvrAJ2Fc8s5JpLGA+B4unvsRizzA0Y= 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; Sat, 31 Oct 2015 22:04:55 +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; Sat, 31 Oct 2015 22:04:55 +0000 From: Brian Raymor To: Benjamin Bangert , "webpush@ietf.org" Thread-Topic: [Webpush] Provide a method to indicate rate-limit issues Thread-Index: AQHRE0iQWJvjfricNEGNDNBvA190dJ6GJLgA Date: Sat, 31 Oct 2015 22:04:54 +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:B+k4/iP681wWBluy8U5pVo/5PX/xWT53YoqnQUnFAw12r7vOkZSNu9bVHN3CxuhtO0O84OzeMQwDxLFj9Wr0EokqeAjErvpRv4erw9gDJo7UDnIHzgkRkFZb1CdVhmvL+L0EPMkGE+n2fG6AXhU8jA==; 24:sU5ImGoo+9l7at7ZaKfvl5YmozHctTz/uYT9RS5/50I1CnziOgHWdYQyyk3Iw6vGVI4WIDgXJ032Ie8UV6/PN5N6iNtxP0R2blRew7OK9rg=; 20:JKeHVvAILYBF4/14ceNoTNkDmbhzPLIwRsNZSn6Agqf886zQU+jMY+SSCwka3DZyHOBDcFAo0+6maHqEHONGyg== 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)(8121501046)(5005006)(520078)(3002001)(10201501046)(61426024)(61427024); SRVR:BY2PR0301MB0647; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0647; x-forefront-prvs: 07467C4D33 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(199003)(189002)(377454003)(5002640100001)(50986999)(5003600100002)(76176999)(105586002)(8990500004)(10090500001)(10290500002)(106116001)(106356001)(15975445007)(107886002)(101416001)(99286002)(5001960100002)(97736004)(54356999)(5001770100001)(92566002)(2501003)(77096005)(2950100001)(76576001)(2900100001)(102836002)(81156007)(561944003)(19580405001)(11100500001)(5007970100001)(189998001)(5008740100001)(5004730100002)(19580395003)(66066001)(33656002)(86362001)(74316001)(122556002)(5005710100001)(10400500002)(86612001)(40100003)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0647; 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: 31 Oct 2015 22:04:54.7557 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0647 Archived-At: Subject: Re: [Webpush] 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: Sat, 31 Oct 2015 22:04:58 -0000 T24gT2N0b2JlciAzMSAyMDE1IGF0IDQ6MjQgQU0sIEJlbmphbWluIEJhbmdlcnQgPGJiYW5nZXJ0 QG1vemlsbGEuY29tPiB3cm90ZToNCg0KPiBJdCB3b3VsZCBiZSBuaWNlIHRvIGhhdmUgYSB1bmlm b3JtIHdheSB0byBpbmRpY2F0ZSB0byBhbiBBcHBsaWNhdGlvbiBTZXJ2ZXIgdGhhdCBpdHMgYmVp bmcgcmF0ZS1saW1pdGVkDQo+IGFuZCBpdCBzaG91bGQgYmFjay1vZmYgb24gaXRzIHNlbmRpbmcs IGluIGEgc2VwYXJhdGUgd2F5IHRoYW4gdXNpbmcgYSA1MDMuIDUwMydzIGFyZSB1c2VkIGZvciBh IHZhcmlldHkNCj4gb2YgaXNzdWVzLCBzZXBhcmF0ZSBmcm9tIHJhdGUtbGltaXRpbmcsIHBlcmhh cHMgYSBkaWZmZXJlbnQgc3RhdHVzIGNvZGUsIGFuZC9vciBhIGhlYWRlciBpbmRpY2F0aW5nDQo+ IHdoZW4gdGhlIGFwcC1zZXJ2ZXIgc2hvdWxkIHJlc3VtZS4NCg0KVGhlIGVhcmxpZXIgcHJvcG9z YWwgZnJvbSBKUiAtIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi93ZWJwdXNo L2N1cnJlbnQvbXNnMDAzMDguaHRtbCAtIHdhcyB0byBpbmNsdWRlIGEgcmVmZXJlbmNlIHRvIDQy OSB3aXRoIFJldHJ5LUhlYWRlcjoNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY1 ODUNCg0KICAgVGhlIDQyOSBzdGF0dXMgY29kZSBpbmRpY2F0ZXMgdGhhdCB0aGUgdXNlciBoYXMg c2VudCB0b28gbWFueQ0KICAgcmVxdWVzdHMgaW4gYSBnaXZlbiBhbW91bnQgb2YgdGltZSAoInJh dGUgbGltaXRpbmciKS4NCg0KICAgVGhlIHJlc3BvbnNlIHJlcHJlc2VudGF0aW9ucyBTSE9VTEQg aW5jbHVkZSBkZXRhaWxzIGV4cGxhaW5pbmcgdGhlDQogICBjb25kaXRpb24sIGFuZCBNQVkgaW5j bHVkZSBhIFJldHJ5LUFmdGVyIGhlYWRlciBpbmRpY2F0aW5nIGhvdyBsb25nDQogICB0byB3YWl0 IGJlZm9yZSBtYWtpbmcgYSBuZXcgcmVxdWVzdC4NCg0KICAgRm9yIGV4YW1wbGU6DQoNCiAgIEhU VFAvMS4xIDQyOSBUb28gTWFueSBSZXF1ZXN0cw0KICAgQ29udGVudC1UeXBlOiB0ZXh0L2h0bWwN CiAgIFJldHJ5LUFmdGVyOiAzNjAwDQoNCldvdWxkIHRoaXMgYWRkcmVzcyB5b3VyIHJlcXVpcmVt ZW50cz8gDQoNCi4uLkJyaWFuDQoNCg0KDQo=