From nobody Tue Aug 4 13:30: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 63C431AC3E5 for ; Tue, 4 Aug 2015 13:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6UG_pdZ85ME for ; Tue, 4 Aug 2015 13:30:30 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8D6D1AC3D0 for ; Tue, 4 Aug 2015 13:30:29 -0700 (PDT) Received: by labow3 with SMTP id ow3so15351184lab.1 for ; Tue, 04 Aug 2015 13:30:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=vijb7XzxDg9OO8L3irxQcJcGBRj/yNGdtEY9oH6UBbQ=; b=wgI7/uE0MyHKDADbM7RsHIjYjnuoK3K/+okSAIFvxOQv76Zex4vsn9ztMf0baeOojH tTmnfA2P8hH8et2SltR0pGYbW2C24IPm41/pGp7d8s4kloGEI6jcJDKW8ztZnPloXw2U AqKaPvdfnvYhxg/wclquIwxGNAVlBIVLJgPJtUQQ9BX4VUj5FykR7FTlwZdxhNyBxg3b Kg6eDTyTSH4qUAjspa4WPfZDNG9Wk63EmnUll/gx7DNkV3FUZEwNkRmubOAzM+nLCHYM oJFYUMP01w0mL3Kk+zl4Hl1hRM+D50sBAYmLP3Md32Kti1x3eCy002iS3+uu3DT6cPM/ sP/A== MIME-Version: 1.0 X-Received: by 10.112.122.52 with SMTP id lp20mr412123lbb.108.1438720227983; Tue, 04 Aug 2015 13:30:27 -0700 (PDT) Received: by 10.25.197.87 with HTTP; Tue, 4 Aug 2015 13:30:27 -0700 (PDT) Date: Tue, 4 Aug 2015 13:30:27 -0700 Message-ID: From: Martin Thomson To: "webpush@ietf.org" Content-Type: multipart/alternative; boundary=047d7bb043401ec803051c822802 Archived-At: Cc: Costin Manolache Subject: [Webpush] Port numbers 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, 04 Aug 2015 20:30:31 -0000 --047d7bb043401ec803051c822802 Content-Type: text/plain; charset=UTF-8 See https://github.com/webpush-wg/webpush-protocol/issues/37 Costin asked if we could somehow register, recommend, or mandate the use of the port numbers that are used for current push services (5223/5228). These ports are typically given special treatment by network operators, mainly so that they require less frequent keep-alive packets, which saves battery. Since these ports are already registered for other purposes with IANA, my suggestion is that we don't try to formally register them. Instead, I suggest that we include a note saying that certain pre-existing services are treated specially based on the server port number and that new services might be deployed on these same ports to gain the same preferential treatment. The alternative is to try to register one or other port for webpush. In general, I don't believe in port number registrations, but this might be OK. --047d7bb043401ec803051c822802 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

See https://github.com/webpush-= wg/webpush-protocol/issues/37

Costin asked if we could somehow register, recommend, or man= date the use of the port numbers that are used for current push services (5= 223/5228).=C2=A0 These ports are typically given special treatment by netwo= rk operators, mainly so that they require less frequent keep-alive packets,= which saves battery.

Since these ports are already registered for other purposes = with IANA, my suggestion is that we don't try to formally register them= . Instead, I suggest that we include a note saying that certain pre-existin= g services are treated specially based on the server port number and that n= ew services might be deployed on these same ports to gain the same preferen= tial treatment.

The alternative is to try to regis= ter one or other port for webpush.=C2=A0 In general, I don't believe in= port number registrations, but this might be OK.

--047d7bb043401ec803051c822802-- From nobody Tue Aug 4 15:00:34 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 89EB61ACF07 for ; Tue, 4 Aug 2015 15:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17EtYZGHbeYM for ; Tue, 4 Aug 2015 15:00:30 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D9F81ACEF7 for ; Tue, 4 Aug 2015 15:00:30 -0700 (PDT) Received: by iggf3 with SMTP id f3so20862445igg.1 for ; Tue, 04 Aug 2015 15:00:29 -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=+BtMJFJAc4InuFnJh1rPwKhGFf502sxKZvmhJOd9lsk=; b=0p2xvqkRirinUwX4LK9Ba47OlzjQYtrU1x6Ehk4wDmIEfgBSa4/1BfkJ/nYbgHTBgF 5OrRemiNlwfq473XoyXiZeTfsLBXpNQ7bB+iTVxr+kkeaH1NpLmadpbji//YZWbPyspE sPiFYW+ZK8O/P3Hbqrcwbnb/q5iQd9Xa61OnNHx3euv6XhJClR+8Pu6kvSPDds29OXx4 Wj/YjqL7oJnOzTKEkZHrS2T1VkGOPMKeJgLFc9kOzdtPLyl4U2zXio/NDZnh5LG/8z0+ KW7Cxcxce9fyhkuTe5PqvusdKQO9f5JwrCBnPJWl0n2BdCVzKV3YRTrnxeRU37okjr0c pJhQ== MIME-Version: 1.0 X-Received: by 10.50.64.179 with SMTP id p19mr2202209igs.55.1438725629837; Tue, 04 Aug 2015 15:00:29 -0700 (PDT) Received: by 10.107.129.105 with HTTP; Tue, 4 Aug 2015 15:00:29 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 Aug 2015 15:00:29 -0700 Message-ID: From: Costin Manolache To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7bd75cec188ae1051c836acb Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Port numbers 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, 04 Aug 2015 22:00:32 -0000 --047d7bd75cec188ae1051c836acb Content-Type: text/plain; charset=UTF-8 IMHO registering a number would be useful - this is a case where network operators and router makers could help a lot by setting reasonable NAT timeouts. Having a section on network config implications will also help. We may also mention that operators could apply limits on number of connections from an IP in their network to this port, to reduce NAT entries - and for IPv6 they should obviously not block it or timeout it. Another thing to "remind" is that TCP connections should be closed with a FIN or RST packet when possible, and suppressing the RST should be for special cases only. 443 traffic is very different than what will be typical for webpush - a UA may have 100s of TCP connections open to various sites on 443, each can be short lived with little harm if the operator kills it. Costin On Tue, Aug 4, 2015 at 1:30 PM, Martin Thomson wrote: > See https://github.com/webpush-wg/webpush-protocol/issues/37 > > Costin asked if we could somehow register, recommend, or mandate the use > of the port numbers that are used for current push services (5223/5228). > These ports are typically given special treatment by network operators, > mainly so that they require less frequent keep-alive packets, which saves > battery. > > Since these ports are already registered for other purposes with IANA, my > suggestion is that we don't try to formally register them. Instead, I > suggest that we include a note saying that certain pre-existing services > are treated specially based on the server port number and that new services > might be deployed on these same ports to gain the same preferential > treatment. > > The alternative is to try to register one or other port for webpush. In > general, I don't believe in port number registrations, but this might be OK. > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > > --047d7bd75cec188ae1051c836acb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
IMHO registering a number would be useful - this is a case= where network operators and router makers could help a lot=C2=A0
by se= tting reasonable NAT timeouts. Having a section on network config implicati= ons will also help.=C2=A0

We may also mention that= operators could apply limits on number of connections from an IP in their = network to this port,
to reduce NAT entries - and for IPv6 they s= hould obviously not block it or timeout it.=C2=A0

= Another thing to "remind" is that TCP connections should be close= d with a FIN or RST packet when possible, and suppressing=C2=A0
t= he RST should be for special cases only.

443 traff= ic is very different than what will be typical for webpush - a UA may have = 100s of TCP connections open to various sites
on 443, each can be= short lived with little harm if the operator kills it.=C2=A0
Costin

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

See https://github.com/webpush-= wg/webpush-protocol/issues/37

Costin asked if we could somehow register, recommend, or man= date the use of the port numbers that are used for current push services (5= 223/5228).=C2=A0 These ports are typically given special treatment by netwo= rk operators, mainly so that they require less frequent keep-alive packets,= which saves battery.

Since these ports are already registered for other purposes = with IANA, my suggestion is that we don't try to formally register them= . Instead, I suggest that we include a note saying that certain pre-existin= g services are treated specially based on the server port number and that n= ew services might be deployed on these same ports to gain the same preferen= tial treatment.

The alternative is to try to regis= ter one or other port for webpush.=C2=A0 In general, I don't believe in= port number registrations, but this might be OK.


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


--047d7bd75cec188ae1051c836acb-- From nobody Wed Aug 5 13:25: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 A1E291A8025 for ; Wed, 5 Aug 2015 13:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pbikVOyds-P for ; Wed, 5 Aug 2015 13:25:06 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0101.outbound.protection.outlook.com [65.55.169.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3370E1A86E4 for ; Wed, 5 Aug 2015 13:24:56 -0700 (PDT) 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.225.19; Wed, 5 Aug 2015 20:24:54 +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.0225.018; Wed, 5 Aug 2015 20:24:54 +0000 From: Brian Raymor To: "webpush@ietf.org" Thread-Topic: Updated webpush issues and github 'process' Thread-Index: AdDPvATsuyYvPhXTQZGGShZ6QqgXIQ== Date: Wed, 5 Aug 2015 20:24:54 +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:d911:5b60:18ea:2280] x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0646; 5:864PKmLWTuNWQOn9qZShfco0rNXhrMj++jkUVdiEP43aJ5Ii0V7AdS9+LyBlhHay+zX0zYp065uw0pmnFeTh4cLpo6YNDytQH6hmiMfZLxWoZZUwbbbZRwNvraXx1WwzfKUEsyNdRHh8qFkuwVstYQ==; 24:apfokZaJCYoS/7lPrOQyyx1lQKcmOUZuZzW0pmMZ8bs6B1AT2yW9bz49TT1U07YtEtevUx7T4a6hd+Peuwefq+5zzNsox8bBn2jYchanBNI=; 20:8TMlZl+J/10xSFYUkbBgJ6oWwopb6XjZIVx0tqdpLH33zjSJvqJAilY/S01YIzGgPg75ZC1op8sssU6YpsgiIQ== 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:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR0301MB0646; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0646; x-forefront-prvs: 06592CCE58 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(54534003)(199003)(92566002)(229853001)(33656002)(76576001)(62966003)(77156002)(450100001)(46102003)(10090500001)(122556002)(19580395003)(2351001)(40100003)(86612001)(5003600100002)(97736004)(4001540100001)(81156007)(5001960100002)(5001860100001)(110136002)(107886002)(5001920100001)(5001830100001)(64706001)(2420400006)(10400500002)(5005710100001)(74316001)(10290500002)(86362001)(87936001)(2656002)(2501003)(54356999)(189998001)(7110500001)(77096005)(99286002)(2900100001)(68736005)(102836002)(5002640100001)(105586002)(15975445007)(106356001)(101416001)(50986999)(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) 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: 05 Aug 2015 20:24:54.2332 (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] Updated webpush issues and github 'process' 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, 05 Aug 2015 20:25:07 -0000 I have updated the webpush issue tracker - https://github.com/webpush-wg/we= bpush-protocol/issues - based on the IETF93 discussions and open issues on = the mailing list. Please let me know if you have questions (or your favorit= e issue is missing). As Shida presented at IETF93, webpush is using github to organize our work.= Earlier, the TLS WG offered some excellent github guidance - http://www.ie= tf.org/mail-archive/web/tls/current/msg12149.html - that I've modified for = webpush: - The editor will maintain the editor's draft on github in the following repository: https://github.com/webpush-wg/webpush-protocol - Technical changes can be submitted as pull requests and are subject to the usual WG consensus process before being merged. No substantive technical discussion should occur in github. If you cannot submit a pull request, you can send text directly to the list but pull requests are preferred for tracking purposes. The editor may also be tasked by the WG to make technical changes directly, based on WG consensus. - Editorial changes should be submitted as pull requests and the editor may just merge them directly and/or commit editorial changes directly as needed. - If you believe a change has been committed inappropriately, either note this on the list/chairs/editor or if the change is minor, submit your own pull request to back it out. - Revisions will be submitted as internet drafts regularly, and be tagged (see process in [1]). We still maintain a manual change log for major issues, but the commit history is used as a more detailed record. - The git issue tracker will be used to manage outstanding issues, but as above, any substantive discussion should happen on-list. [1] https://github.com/webpush-wg/webpush-protocol/blob/master/SUBMITTING.m= d From nobody Wed Aug 5 16:37:34 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 8617D1B34A6 for ; Wed, 5 Aug 2015 16:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 6YHpNPq2facI for ; Wed, 5 Aug 2015 16:37:30 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0700.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::700]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E6D01B34A3 for ; Wed, 5 Aug 2015 16:37:30 -0700 (PDT) Received: from DM2PR0301MB0656.namprd03.prod.outlook.com (10.160.96.18) by DM2PR0301MB1264.namprd03.prod.outlook.com (10.160.220.11) with Microsoft SMTP Server (TLS) id 15.1.225.19; Wed, 5 Aug 2015 23:37:11 +0000 Received: from DM2PR0301MB0654.namprd03.prod.outlook.com (10.160.96.16) by DM2PR0301MB0656.namprd03.prod.outlook.com (10.160.96.18) with Microsoft SMTP Server (TLS) id 15.1.225.19; Wed, 5 Aug 2015 23:37:10 +0000 Received: from DM2PR0301MB0654.namprd03.prod.outlook.com ([10.160.96.16]) by DM2PR0301MB0654.namprd03.prod.outlook.com ([10.160.96.16]) with mapi id 15.01.0225.018; Wed, 5 Aug 2015 23:37:10 +0000 From: Brian Raymor To: Benjamin Bangert , "webpush@ietf.org" Thread-Topic: [Webpush] TTL of 0 Thread-Index: AdDP0opuNrcMD4cQRM+oMRZJ3QdgcA== Date: Wed, 5 Aug 2015 23:37:10 +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:d911:5b60:18ea:2280] x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0656; 5:7G5j04ocPcuqufL7wmqfVONyWbkG5gF5AoL/sa+g37bIdG+1boahxQc2hMDgOnsVXZiHKRT4Q48+yf8zwbkbRV4NIiIFrDhtuUnXF4kQfZirOcewdDqs7IMIQWaaVjWKrlVeMOhAPTxoDX7rHG5OjQ==; 24:n8f7HRpO1SM3OrH0RIcTxsVxY3dTvjDT554tquZyuIArDSKbV95ZMQyMuz/malJBNeklShTPSD2EdR7GasHg4Y43PV7AubZAL/Glt8YC9Ag=; 20:ogbncoZA+nlr+Jfqq+8lYGDQrQDALWsNbZb0+UnOpGm3+GDNg51lJd+xCcwPPVCPJNrQbUT78sJusGFerm1bUw== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0656; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB1264; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:DM2PR0301MB0656; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0656; x-forefront-prvs: 06592CCE58 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(189002)(377454003)(51444003)(199003)(105586002)(122556002)(19580405001)(101416001)(2900100001)(86362001)(5001830100001)(87936001)(15975445007)(81156007)(19580395003)(2656002)(86612001)(77096005)(5005710100001)(74316001)(33656002)(46102003)(10400500002)(92566002)(102836002)(10090500001)(106356001)(76576001)(5001920100001)(5001770100001)(99286002)(5001860100001)(77156002)(54356999)(68736005)(5003600100002)(5002640100001)(64706001)(4001540100001)(62966003)(97736004)(189998001)(107886002)(40100003)(5001960100002)(2501003)(50986999)(10290500002)(3826002)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0656; H:DM2PR0301MB0654.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) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2015 23:37:10.2325 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0656 X-Microsoft-Exchange-Diagnostics: 1; DM2PR0301MB1264; 2:qA/29AJQosXwa+3ZHqxLNgjjMhCIuVl5GdDnOGyXWgF6cB6cQpSG1kOMITuwNadsum3GvoNoDgpKognvqVD1CmBF0X7jifEVGYvzBhRy4FY5EdM3gSL6tWwesYFhNlgV1vgVdG6DuTPdDDliWB3KIcfIzapmnplE7YV965InWhY=; 3:zqr545SJYsnLxADISS5flM3n8c+BSLQxsqTqFizS3LRjfkHF5gQIFR9ynlSauozMVR/IMHtzyUGIM6qjeSyQYuSwy8rn7Q/rRMhFJ3HgWLlC4WL9UzHa7Mceh5rqdY9Ah69P6CVOph6kxzVVfDuRwg==; 25:GRgbQmTb6tDFIBX5BE0W69bk4fh94Xrrs1IQMv+vlzp1NdXOcLjxfIUTJnmK6bTiHYOymdu+TJUxYV7PLxmi6BJtHQKK/m1WBWHn15NIJCngR42REjHsjcP9ujrNk9wNzFC7gBwEfB91SCylu/mB5oI32Dkig/yiQlGPcyED25cX0tFa5zrtubV7SS5CZXwqlqWsgkBaAbcbB70JimCw/cAXI2zCgaXSDWXg/wl/tqDX0baZ8MwWyVRgQ5f98O/92h9W7D484tPAQSOJYyqa8A==; 23:iqylxEomoltzG+1s7E+iCX3G7Seq82AY0AK6Su0fcMHOe1GT1GOn+C9N2TWNlK5c306u5/ep5HBpTlVajItsbTOoHPqNHHnxYfhVEBxo2ABD4eWdpC0S4ouIJ9Mr+iq17BOgqQcKfgql6Arcermrc9KHBvae14qye2XrgytpEEQqeMop3JYLQB+oVGLL7L39rHEmR2I6BSKmkG5yDKXiPiXFWyrY50fvvE6X9Yjqn3GoXvN4vjUWb8RSIpmzmuxK X-OriginatorOrg: microsoft.com Archived-At: Subject: Re: [Webpush] TTL of 0 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 23:37:33 -0000 T24gVHVlcywgSnVsIDI4LCAyMDE1IGF0IDU6MzEgUE0sIEJlbmphbWluIEJhbmdlcnQgPGJiYW5n ZXJ0QG1vemlsbGEuY29tPiB3cm90ZToNCg0KPiBUaGUgc3BlYyBpbmRpY2F0ZXMgYSBUVEwgb2Yg MCBzaG91bGQgcmVzdWx0IGluIHRoZSBtZXNzYWdlIG5vdCBiZWluZyBkZWxpdmVyZWQgaWYgdGhl IGNsaWVudCBpcyBub3QgY29ubmVjdGVkLg0KPiBIb3dldmVyLCBpdCBkb2Vzbid0IGluZGljYXRl IHdoZXRoZXIgdGhlIFB1c2ggc2VydmVyIGlzIHN0aWxsIHVuZGVyIHRoZSBzYW1lIG9ibGlnYXRp b24gdG8gcHJvdmlkZSBhIExvY2F0aW9uDQo+IGhlYWRlciBpbiB0aGUgcmVzcG9uc2UgaW4gdGhp cyBjYXNlIChJIGFzc3VtZSBpdHMgc3RpbGwgYSAyMDEsIGV2ZW4gdGhvdWdoIGEgcmVzb3VyY2Ug d2FzIG5vdCBjcmVhdGVkPykuDQoNCj4gU2hvdWxkIGEgTG9jYXRpb24gc3RpbGwgYmUgcmV0dXJu ZWQ/IFdoYXQga2luZCBvZiByZWNlaXB0IGlzIGFzc3VtZWQgaW4gdGhpcyBjYXNlIChvciBubyBy ZWNlaXB0IGFuZCBubyBMb2NhdGlvbik/DQoNCkkndmUgY3JlYXRlZCBodHRwczovL2dpdGh1Yi5j b20vd2VicHVzaC13Zy93ZWJwdXNoLXByb3RvY29sL2lzc3Vlcy8zOCB0byB0cmFjayB0aGlzIGlz c3VlLg0KDQpPYnZpb3VzbHksIHRoZSBsYWNrIG9mIGNsYXJpdHkgaXMgcmVsYXRlZCB0byB0aGUg cGhyYXNlICJzdG9yYWdlIGlzIG5vdCBuZWVkZWQiIHdoaWNoIHN1Z2dlc3RzIHRoYXQgYSByZXNv dXJjZSBtaWdodA0Kbm90IGJlIGNyZWF0ZWQ6DQoNCglBYnNlbmNlIG9mIHRoZSBUVEwgaGVhZGVy IGZpZWxkIGlzIGludGVycHJldGVkIGFzIGVxdWl2YWxlbnQgdG8gYQ0KCXplcm8gdmFsdWUuICBQ dXNoIG1lc3NhZ2VzIHdpdGggYSB6ZXJvIFRUTCBpbmRpY2F0ZSB0aGF0IHN0b3JhZ2UgaXMNCglu b3QgbmVlZGVkIGFuZCB0aGF0IHRoZSBtZXNzYWdlIGNhbiBiZSBkcm9wcGVkIGlmIHRoZSB1c2Vy IGFnZW50DQoJaXNuJ3QgaW1tZWRpYXRlbHkgYXZhaWxhYmxlIHRvIHJlY2VpdmUgdGhlIG1lc3Nh Z2UuDQoNCihJIGFsc28gYXBwcmVjaWF0ZSB0aGF0IEdDTSAndGltZV90b19saXZlJyAoaHR0cHM6 Ly9kZXZlbG9wZXJzLmdvb2dsZS5jb20vY2xvdWQtbWVzc2FnaW5nL2Rvd25zdHJlYW0jdHRsKQ0K YW5kIEFQTlMgJ2V4cGlyYXRpb24gZGF0ZScgb2ZmZXIgc2ltaWxhciBzdGF0ZW1lbnRzIHJlZ2Fy ZGluZyBzdG9yYWdlLikNCg0KSSB0aGluayB0aGF0IHRoZSBzY2VuYXJpbyBmb2N1cyBmb3IgVFRM IDAgc2hvdWxkIGJlIG1vcmUgb24gJ25vdyBvciBuZXZlcicgZGVsaXZlcnkgdGhhbiBvbiB0aGUg c3RvcmFnZSBpbXBsaWNhdGlvbnMuDQoNClRoZSBtZXNzYWdlIHJlc291cmNlIGlzIGFsd2F5cyBj cmVhdGVkIGFuZCBzdWJzZXF1ZW50bHkgYXBwZWFycyBhcyB0aGUgOnBhdGggb2YgdGhlIHN5bnRo ZXNpemVkIEdFVCBpbiB0aGUgUFVTSF9QUk9NSVNFOg0KDQogICBQVVNIX1BST01JU0UgW3N0cmVh bSA3OyBwcm9taXNlZCBzdHJlYW0gNF0gK0VORF9IRUFERVJTDQogICAgIDptZXRob2QgICAgICAg ID0gR0VUDQogICAgIDpwYXRoICAgICAgICAgID0gL2QvcURJWUhOY2ZBSVBQXzVJVHZVUnItZDZC R3RZblRSbmsNCiAgICAgOmF1dGhvcml0eSAgICAgPSBwdXNoLmV4YW1wbGUubmV0DQoNCkZvciBU VEwgMCwgdGhlIG1lc3NhZ2UgcmVzb3VyY2UgZG9lcyBub3QgbmVlZCB0byBiZSBzdG9yZWQgZm9y IGFkZGl0aW9uYWwgcmV0cmllcywgYnV0IHNob3VsZCBleGlzdA0KbG9uZyBlbm91Z2ggZm9yIGEg J3Byb21wdCcgVUEgdG8gYWNrbm93bGVkZ2UgcmVjZWlwdCAoREVMRVRFIHRoZSByZXNvdXJjZSkg aWYgdGhlIG1lc3NhZ2Ugd2FzIA0KZGVsaXZlcmVkLiAgT2YgY291cnNlLCB0aGUgVUEgbXVzdCBi ZSBhYmxlIHRvIGhhbmRsZSA0MDQocykgaW4gcmVzcG9uc2UgdG8gREVMRVRFKHMpIGluIGFueSBj YXNlLg0KDQpJJ2QgcHJvcG9zZSB0byByZXdyaXRlIHRoZSBvcmlnaW5hbCB0ZXh0IGFsb25nIHRo ZSBsaW5lcyBvZjoNCg0KCUFic2VuY2Ugb2YgdGhlIFRUTCBoZWFkZXIgZmllbGQgaXMgaW50ZXJw cmV0ZWQgYXMgZXF1aXZhbGVudCB0byBhDQoJemVybyB2YWx1ZS4gIFB1c2ggbWVzc2FnZXMgd2l0 aCBhIHplcm8gVFRMIGluZGljYXRlIHRoYXQgdGhlDQoJYXBwbGljYXRpb24gc2VydmVyIGlzIHJl cXVlc3RpbmcgJ25vdyBvciBuZXZlcicgbWVzc2FnZSBkZWxpdmVyeSANCgl0byB0aGUgdXNlciBh Z2VudC4gIA0KDQpJZiB0aGUgbWVzc2FnZSBpcyBub3QgZGVsaXZlcmVkIGFuZC9vciBhY2tub3ds ZWRnZWQgYW5kIGEgcmVjZWlwdCB3YXMgcmVxdWVzdGVkLCB0aGVuIGV4aXN0aW5nIGxhbmd1YWdl IGNvdmVycyB0aGlzIGNhc2U6DQoNCiAgIFRoZSBwdXNoIHNlcnZlciBNVVNUIHB1c2ggYSByZXNw b25zZSB3aXRoIGEgc3RhdHVzIGNvZGUgb2YgNVhYIChUQkQpDQogICBpZiB0aGUgdXNlciBhZ2Vu dCBmYWlscyB0byBhY2tub3dsZWRnZSB0aGUgcmVjZWlwdCBvZiB0aGUgcHVzaA0KICAgbWVzc2Fn ZSBvciB0aGUgcHVzaCBzZXJ2ZXIgZmFpbHMgdG8gZGVsaXZlciB0aGUgbWVzc2FnZSBwcmlvciB0 byBpdHMNCiAgIGV4cGlyYXRpb24uDQoNCkNvbW1lbnRzPw0KDQouLi5Ccmlhbg0KDQo= From nobody Wed Aug 5 19:33: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 940EE1B2B01 for ; Wed, 5 Aug 2015 19:33: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 NXO-cSjDO7ti for ; Wed, 5 Aug 2015 19:33:57 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07F581B2B00 for ; Wed, 5 Aug 2015 19:33:57 -0700 (PDT) Received: by labkb6 with SMTP id kb6so18492647lab.2 for ; Wed, 05 Aug 2015 19:33:55 -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=gkHKhsQtVsqz/6imyQ2TR33F8+Cw1F18xxisCUrvB2g=; b=cAmD8Xb0MUgHQCQDWvExzUyFuk8NF9A86/qLlUT3FaP6ugWUB0CokT/9Hd3TZTqkBP 3j5NBgivUl0jDWOKUG6BVn3xx6OjvOx/l+zZnqeEt4JRK7rtRGMPb6doOvpObs25+BvV Ukm+KlhmkzsLrWUusIYE5cJi25DYhQkxfbTOaCLvZyDh0aZJYqdoCtFUoHSkhTg3HbEH ldDHi/YhOiJZmpvvoHIv6eZh4bkSHrwCY6KkIfMFCW+8Yt8tqjuHivLVlfw7p69ktZ9I 9PiFS2klLk+qwOe/3ljVduAGI448XmqlH5687OTgtxFXLsAvy0PeDbMv2yRmQOHs9KhG wKKw== MIME-Version: 1.0 X-Received: by 10.112.143.136 with SMTP id se8mr12482491lbb.101.1438828435471; Wed, 05 Aug 2015 19:33:55 -0700 (PDT) Received: by 10.25.197.87 with HTTP; Wed, 5 Aug 2015 19:33:55 -0700 (PDT) In-Reply-To: References: Date: Wed, 5 Aug 2015 19:33:55 -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] TTL of 0 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 02:33:58 -0000 On 5 August 2015 at 16:37, Brian Raymor wrote: > I'd propose to rewrite the original text along the lines of: > > Absence of the TTL header field is interpreted as equivalent to a > zero value. Push messages with a zero TTL indicate that the > application server is requesting 'now or never' message delivery > to the user agent. I think that your answer is good, but I think that this wording could be improved. "now or never" is a little imprecise. I think that the intent is fine in the original, but in addition to your changes, I think that a second paragraph might be a good idea, if just to answer questions like Ben's: If the user agent isn't available to receive the message, then a push message with a zero TTL will not be delivered. Furthermore, acknowledgments for zero TTL push messages could be lost: the push service is permitted to remove the push message resource immediately, which might occur before receiving the acknowledgment DELETE from the user agent. An application server consequently cannot rely on receiving receipt for zero TTL push messages. From nobody Thu Aug 6 17:09: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 01A9D1AD080 for ; Thu, 6 Aug 2015 17:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45DL4CSDWHoo for ; Thu, 6 Aug 2015 17:09:44 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0142.outbound.protection.outlook.com [207.46.100.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD1961B30FE for ; Thu, 6 Aug 2015 17:09:42 -0700 (PDT) Received: from BY2PR0301MB0647.namprd03.prod.outlook.com (10.160.63.14) by BY2PR0301MB0647.namprd03.prod.outlook.com (10.160.63.14) with Microsoft SMTP Server (TLS) id 15.1.225.19; Fri, 7 Aug 2015 00:09:41 +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.0225.018; Fri, 7 Aug 2015 00:09:41 +0000 From: Brian Raymor To: "webpush@ietf.org" Thread-Topic: Per-client subscription resource - 'aggregated subscriptions' Thread-Index: AdDQkdujmhpNdXVITISwDPQKLlKWOQ== Date: Fri, 7 Aug 2015 00:09:41 +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:a991:fd36:d5f3:19e] x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0647; 5:Hb+bBFH3vQPwhaVrxi+ubqJGhdah/WNu0W2fAr5VyVxS8YSXlWXuteNNX2doOJz84Oqqm3RpzJapZATL7eklLxWei62N/49SYtJHAeA5Vn9tk22yFkQNsHmn7lVZ5Jx5Ff9q7XPvjp915kVzOqbFZg==; 24:fOEk+CetC7XYiS6ZnjtoFocYxxgVdzS+BRYrKfoM8ol9O13RAnDuFHJkEhayLW2GOGKKN76V2oMpVTkZs2H5ZP3xHCeK+AHqGGg26fFzZd0=; 20:XPhCUBqua2I4CKxiuF6o3FFBUkeVIn35VuTixf3dOeP1J4UA2+nGXL8zmbzW6PMQhpVzvKB80rw0u+6bCw+RDA== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42139001)(42140001); SRVR:BY2PR0301MB0647; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR0301MB0647; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0647; x-forefront-prvs: 066153096A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(10290500002)(575784001)(19580395003)(15975445007)(77156002)(102836002)(68736005)(46102003)(77096005)(2900100001)(10090500001)(99286002)(122556002)(5003600100002)(450100001)(50986999)(2501003)(74316001)(106356001)(105586002)(40100003)(33656002)(86362001)(92566002)(87936001)(86612001)(2656002)(110136002)(101416001)(107886002)(76576001)(4001540100001)(81156007)(5001920100001)(5001830100001)(5002640100001)(5005710100001)(64706001)(97736004)(189998001)(2351001)(5001960100002)(62966003)(10400500002)(229853001)(5001860100001)(54356999)(3826002)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0647; H:BY2PR0301MB0647.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) 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: 07 Aug 2015 00:09:41.2983 (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: [Webpush] Per-client subscription resource - 'aggregated subscriptions' 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, 07 Aug 2015 00:09:46 -0000 As tracked in https://github.com/webpush-wg/webpush-protocol/issues/41, sub= scription aggregation has been requested multiple times on the mailing list. Further details and scenarios= are in the issue, which I'll not reiterate here. Following the webpush meeting at IETF93, a few of us (Costin, Darshak, Elio= , Martin, Peter, and I) had conversations about the shape of such a feature. I've outlined the basic changes (see bullet points below) to webpush-protoc= ol-00. Note that the list of changes is not intended to be exhaustive. It's the minimal set of information to start the discussi= on in the WG. If we reach consensus in the future, then I'll create a more complete pull request for review. This feature is optional for a push service to implement. 2.1. HTTP Resources * Add push message subscription set push message subscription set: This resource provides read and delete access for a set of message subscriptions. A link relation of type "urn:ietf:params:push:subscriptions" identifies a push message subscription set. 3. Subscribing for Push Messages A user agent sends a POST request to its configured push service resource to create a new subscription. POST /subscribe/ HTTP/1.1 Host: push.example.net * Each subscription response MAY include a urn:ietf:params:push:subscriptio= ns link relation. If included, the push service supports subscription aggre= gation.=20 * The push service MAY return new subscription sets in response to differen= t subscription requests from the same UA. This allows the push service to c= ontrol the grouping. HTTP/1.1 201 Created Date: Thu, 11 Dec 2014 23:56:52 GMT Link:

; rel=3D"urn:ietf:params:push" Link: ; rel=3D"urn:ietf:params:push:receipt" * The new subscription set link relation is returned. Link: ; rel=3D"urn:ietf:params:push:subscriptions" Location: https://push.example.net/s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx Cache-Control: max-age:864000, private 6. Receiving Push Messages * The user agent MAY use either the subscription set or individual subscrip= tions when retrieving messages. * The user agent MAY poll (Prefer: wait=3D0) the subscription set or an ind= ividual subscription. * Add an example for subscription sets - GET /subscriptions/hard-to-guess HEADERS [stream 7] +END_STREAM +END_HEADERS :method =3D GET :path =3D /subscriptions/hard-to-guess :authority =3D push.example.net PUSH_PROMISE [stream 7; promised stream 4] +END_HEADERS :method =3D GET :path =3D /d/qDIYHNcfAIPP_5ITvURr-d6BGtYnTRnk :authority =3D push.example.net HEADERS [stream 4] +END_HEADERS :status =3D 200 date =3D Thu, 11 Dec 2014 23:56:56 GMT last-modified =3D Thu, 11 Dec 2014 23:56:55 GMT cache-control =3D private content-type =3D text/plain;charset=3Dutf8 content-length =3D 36 * The urn:ietf:params:push link relation is included in the HEADERS to diff= erentiate the source of pushed messages. link =3D

; rel=3D"urn:ietf:params:push" DATA [stream 4] +END_STREAM iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB 7.3. Subscription Expiration * A subscription set MAY be assigned a fixed expiration time by the push se= rvice similar to individual subscriptions.=20 * A push service MAY terminate a subscription set which MUST also result in= the termination of its entire set of individual subscriptions. * A user agent MAY delete a subscription set which MUST result in the delet= ion of its entire set of individual subscriptions. * An individual subscription MAY be deleted or terminated. It MUST be remov= ed from its subscription set.=20 * Question: Is it desirable to allow empty subscription sets or should the = deletion of the last individual subscription also delete the set? * Question: Is the expiration time for the subscription set specific to the= set or related in some way to the individual subscriptions in the set? 8. Security Considerations * Update to include considerations for subscription sets From nobody Fri Aug 7 14:40:34 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 643111A0119 for ; Fri, 7 Aug 2015 14:40:33 -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 nkkesbbqHNOp for ; Fri, 7 Aug 2015 14:40:32 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 230C01A010C for ; Fri, 7 Aug 2015 14:40:32 -0700 (PDT) Received: by labd1 with SMTP id d1so15334978lab.1 for ; Fri, 07 Aug 2015 14:40:30 -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=tABesPuoUlnk7lw36FA7F4N5ZsO8i+ic6x8VZd+nhPs=; b=DmFEkIJPDkLQGFF33aXPycnlD2H1w5TmaHMNSLoaoqgPR2PBuliuwgZ4Qg5bIIQ0by H7ssutRF73PQUM3kGQlEcxERjC57x/bxudu1XJr4YCKF7f4lFnGApWjm0aVQuFupHTdy dtAmbOWcnMjeS/e7T65GSsvq8fTlF/cru88b+kuSvB1MldUJyexzYgkcFg+swXP73Nju /f9RyRsxmFpo/3nLGYzwDT+nTdMS1bCLyMJKlv+5H/rtb3G61zqWhl7CchBYKnjhPArc 01McSx2LA2qxvQ+sMp3IayxQxae+VvXjOBLJ1mG7WCngaMxuj5IC5e96yUilGqFxKu0a qFKw== MIME-Version: 1.0 X-Received: by 10.152.28.229 with SMTP id e5mr10055939lah.110.1438983630579; Fri, 07 Aug 2015 14:40:30 -0700 (PDT) Received: by 10.25.197.87 with HTTP; Fri, 7 Aug 2015 14:40:30 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 Aug 2015 14:40:30 -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] Per-client subscription resource - 'aggregated subscriptions' 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, 07 Aug 2015 21:40:33 -0000 On 6 August 2015 at 17:09, Brian Raymor wrote: > 3. Subscribing for Push Messages You didn't mention how the push service knows to correlate two different subscriptions. It needs that in order to put the two subscriptions in the same set. From nobody Fri Aug 7 16:31: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 6DA7F1A8AD7 for ; Fri, 7 Aug 2015 16:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEmFVZoLkn7I for ; Fri, 7 Aug 2015 16:31:54 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0110.outbound.protection.outlook.com [65.55.169.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 980101A8AC9 for ; Fri, 7 Aug 2015 16:31:51 -0700 (PDT) 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.225.19; Fri, 7 Aug 2015 23:31: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.0225.018; Fri, 7 Aug 2015 23:31:49 +0000 From: Brian Raymor To: Martin Thomson Thread-Topic: [Webpush] Per-client subscription resource - 'aggregated subscriptions' Thread-Index: AQHQ0Vmwt5adK1uaIEKDMJorERwdap4BFB/w Date: Fri, 7 Aug 2015 23:31:49 +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:98cf:1068:eb29:2d8f] x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0646; 5:GCz0ewkf3RGTbClIextHy1GxuGG+JNceZY6JNyjDLnJSCT+aBk27qv//Mxp7qD2xJUh+KQiYXvGEO01Gr4x4/Yt+IZdvH9cfsz7rcrlJOPMnvBEaPuZ9sWSHNiXwYFKh/BDZRbZgBPl21ypyrwgqlg==; 24:iuMG1LKiDaplg/BJ/rjDG3Krl8cIr4Yg/G9Hl7EFgK3EzlwiXx/Krzu68exW5kd0urJDUsaqknJHD4HRkKr6dBC/0KeJXvlVVpJ65lA/RqA=; 20:KlDSYiuf85F5QTJ/XAfO7CGvfhQsZc6qN6LO27Z57kl54++wVh6hF68XxfbyQHazHAlF+ECWphMnnI7aYuGU/g== 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:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR0301MB0646; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0646; x-forefront-prvs: 066153096A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(24454002)(199003)(110136002)(5001960100002)(76576001)(62966003)(77156002)(19580405001)(92566002)(33656002)(122556002)(10090500001)(46102003)(86612001)(40100003)(64706001)(81156007)(2656002)(5001920100001)(86362001)(19580395003)(106356001)(561944003)(4001540100001)(74316001)(10400500002)(54356999)(77096005)(87936001)(5005710100001)(5001860100001)(105586002)(97736004)(5003600100002)(99286002)(102836002)(68736005)(2950100001)(189998001)(2900100001)(10290500002)(106116001)(5002640100001)(101416001)(50986999)(76176999)(5001830100001)(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) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2015 23:31:49.6981 (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] Per-client subscription resource - 'aggregated subscriptions' 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, 07 Aug 2015 23:31:55 -0000 T24gNyBBdWd1c3QgMjAxNSBhdCAyOjQxLCBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25A Z21haWwuY29tPiB3cm90ZToNCg0KPiBZb3UgZGlkbid0IG1lbnRpb24gaG93IHRoZSBwdXNoIHNl cnZpY2Uga25vd3MgdG8gY29ycmVsYXRlIHR3byBkaWZmZXJlbnQgc3Vic2NyaXB0aW9ucy4gIEl0 IG5lZWRzIHRoYXQgaW4gb3JkZXIgdG8gcHV0IHRoZSB0d28gc3Vic2NyaXB0aW9ucyBpbiB0aGUg c2FtZSBzZXQuDQoNCkdvb2QgcG9pbnQuIEluIGVhcmxpZXIgZGlzY3Vzc2lvbnMsIG9uZSBwcm9w b3NhbCB3YXMgdG8gcGFzcyB0aGUgZmlyc3Qgc3Vic2NyaXB0aW9uIHJlc291cmNlIHRoYXQgd2Fz IGNyZWF0ZWQgKGFzIHBhcmVudCkgd2l0aCBzdWJzZXF1ZW50IHN1YnNjcmlwdGlvbiByZXF1ZXN0 cyAoY2hpbGRyZW4pIHRvIHByb3ZpZGUgdGhhdCBjb21tb24gbGluayBiZXR3ZWVuIHRoZSB1c2Vy IGFnZW50IGFuZCBwdXNoIHNlcnZpY2UuIFRoaXMgYWxsb3dlZCB0aGUgdXNlciBhZ2VudCB0byBt YWtlIHRoZSBkZWNpc2lvbiB0byBhZ2dyZWdhdGUgb3Igbm90LiBJZiBpdCBkaWQgbm90IHBhc3Mg YSBwYXJlbnQgc3Vic2NyaXB0aW9uLCB0aGVuIHRoZSBwdXNoIHNlcnZpY2UgY291bGQgbm90IGFn Z3JlZ2F0ZSB0aGUgc2VwYXJhdGUgc3Vic2NyaXB0aW9ucy4gDQoNCk15IHRob3VnaHQgd2FzIHRv IGF2b2lkICdzcGVjaWFsJyBwcm9wZXJ0aWVzIG9uIHRoZSBmaXJzdCBzdWJzY3JpcHRpb24uIFRo ZSBzdWJzY3JpcHRpb24gc2V0IGVuc3VyZXMgYSBjbGVhbiBzZXBhcmF0aW9uIGJldHdlZW4gb3Bl cmF0aW9ucyBvbiBhZ2dyZWdhdGVkIGFuZCBpbmRpdmlkdWFsIHN1YnNjcmlwdGlvbnMuIEZvciBl eGFtcGxlLCB0aGUgdXNlciBhZ2VudCBjYW4gY29udGludWUgdG8gR0VUIChvciBwb2xsKSBhbmQg REVMRVRFIGluZGl2aWR1YWwgc3Vic2NyaXB0aW9ucyAtIGluY2x1ZGluZyB0aGUgZmlyc3Qgb25l LiANCg0KVG8gZW5hYmxlIHRoZSBjdXJyZW50IHByb3Bvc2FsIHdoZXJlIHRoZSBwdXNoIHNlcnZp Y2UgbWFrZXMgdGhlIGRlY2lzaW9uIHRvIGFnZ3JlZ2F0ZSwgdGhlcmUgbXVzdCBiZSBzb21lIGZv cm0gb2YgY2xpZW50IGF1dGhlbnRpY2F0aW9uL2lkZW50aWZpY2F0aW9uIGluY2x1ZGVkIHdpdGgg dGhlIHN1YnNjcmlwdGlvbiByZXF1ZXN0IGluIG9yZGVyIGZvciBhIHB1c2ggc2VydmljZSB0byBj b3JyZWxhdGUgdGhlIHN1YnNjcmlwdGlvbnMuDQoNCkRhcnNoYWsgbm90ZWQgdGhpcyBpbiBhIHBy ZXZpb3VzIG1lc3NhZ2U6DQoJSeKAmW0gbm90IHN1cmUgaG93IGEgUFMgY2FuIGZvcmNlIGEgVUEg dG8gYWdncmVnYXRlICh1bmxlc3MgdGhlIFBTIHNvbWVob3cgaWRlbnRpZmllcyB0aGUgY2xpZW50 IGJhc2VkIG9uIGF1dGhlbnRpY2F0aW9uL2Nvb2tpZS9zb21ldGhpbmctZWxzZSkuDQoNCkkgbWF5 IGJlIHRha2luZyBpdCBvdXQgb2YgY29udGV4dCBhcyAic29tZXRoaW5nLWVsc2UiLCBidXQgQmVu amFtaW4gYWxzbyBjb21tZW50ZWQ6DQoJSSdtIGFzc29jaWF0aW5nIG9uZSBoMiBjb25uZWN0aW9u IGFzIGJlaW5nIG9uZSBVQQ0K From nobody Fri Aug 7 17:44: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 70EC11AC3DC for ; Fri, 7 Aug 2015 17:44:08 -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 YCxp7e8Zxk8a for ; Fri, 7 Aug 2015 17:44:06 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::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 896691AC3E3 for ; Fri, 7 Aug 2015 17:44:06 -0700 (PDT) Received: by labjt7 with SMTP id jt7so58365115lab.0 for ; Fri, 07 Aug 2015 17:44:05 -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=a8I0ZeghSwfpczRFCUL/L7Z01Ufx6rHiTJ+pKZsBEJs=; b=ThFy496S1lGIpzh2qbmEEp6pFTPvGQUXrW91IEJ+DNJO27G/h8tTlSyROCFVT+U0IM Rn7zrkyMgFSy68U1iRXp0hK6WWwHvQVreNJol7OdYK3iqefwqjOnoarfamN38jlyIDjG U/m2S6RzS19zIkZf1v1SLtokF+zs5MYS0XOkw4pFndjKWDESb3oaQpoR4/WPmkw4Yj0r LGPY2e053CkbIlSuWfkXpMWlm4n0Xv8+qeUcXiZLmMdqKvtZT2Zn3HdJFQtEv0jXibb/ 9s4JvbCj7wYxFam/kXwl1V9XqkL9Bf8GiiN4EhD/K0Lq4MzZMtedyO2GEqQoVyCrMAP+ e1DQ== MIME-Version: 1.0 X-Received: by 10.112.209.106 with SMTP id ml10mr10509820lbc.112.1438994644936; Fri, 07 Aug 2015 17:44:04 -0700 (PDT) Received: by 10.25.197.87 with HTTP; Fri, 7 Aug 2015 17:44:04 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 Aug 2015 17:44:04 -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] Per-client subscription resource - 'aggregated subscriptions' 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, 08 Aug 2015 00:44:08 -0000 On 7 August 2015 at 16:31, Brian Raymor wrote: > Darshak noted this in a previous message: > I=E2=80=99m not sure how a PS can force a UA to aggregate (unless= the PS somehow identifies the client based on authentication/cookie/someth= ing-else). I think that I would prefer something more explicit. Having something explicit would allow the UA to opt out of aggregating. > I may be taking it out of context as "something-else", but Benjamin also = commented: > I'm associating one h2 connection as being one UA That's generally considered a bad idea. As the basis for an optimization, maybe, but I wouldn't want to rely on that. From nobody Sat Aug 8 10: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 0AF101B29DB for ; Sat, 8 Aug 2015 10:32:09 -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 ZGQN5fpsK8Tg for ; Sat, 8 Aug 2015 10:32:06 -0700 (PDT) Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com [209.85.213.182]) (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 AFA121B29DC for ; Sat, 8 Aug 2015 10:32:06 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so48803121igb.0 for ; Sat, 08 Aug 2015 10:32:05 -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=kSpREcPWj+DSTQlL7V06288NoY5D01DI5WrgG05zd9g=; b=flvoNK3CGZBId12nzBKtMeS9mvPTpmIRbcjx+vbRqs2sz21RF588N5+Y9PB3c3eDiH XxVy2VAE3DMCzg0g/6udJpkIeDpgerzaH5NVLSsQr2N1lKW9Wohi5QU32j6BdrORE7EQ Nl0AhB3HPFLXGbzKe0vCh5huZdzuipGY9gW0Y1YkG/kTZFLLpH332c7j/yhmo+N22Q+g LbnJ6NlichowqNc4HWZrPr4HgY+uQQKDVw4njTxhrbDALv0esZA8sNPeoV6JvJmDEKzN zMUWnf8FKGdW2oZFD7Au9+rO20A1tOTK5t2SfiGJmEGsQCq37AlJzxpJ2+RalrmlN963 Bjhw== X-Gm-Message-State: ALoCoQmQR/tkJscX9uaR8DtvoXZ7SLuiqFSgSz/uCKsqTQ2plMKuVGjrh55Y9PyfNWq3eyEzTT1D MIME-Version: 1.0 X-Received: by 10.50.43.193 with SMTP id y1mr3979121igl.89.1439055125707; Sat, 08 Aug 2015 10:32:05 -0700 (PDT) Received: by 10.79.93.1 with HTTP; Sat, 8 Aug 2015 10:32:05 -0700 (PDT) In-Reply-To: References: Date: Sat, 8 Aug 2015 10:32:05 -0700 Message-ID: From: Benjamin Bangert To: Martin Thomson Content-Type: multipart/alternative; boundary=089e0111d1be94a44a051cd021d1 Archived-At: Cc: Brian Raymor , "webpush@ietf.org" Subject: Re: [Webpush] Per-client subscription resource - 'aggregated subscriptions' 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, 08 Aug 2015 17:32:09 -0000 --089e0111d1be94a44a051cd021d1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Aug 7, 2015 at 5:44 PM, Martin Thomson wrote: > On 7 August 2015 at 16:31, Brian Raymor > wrote: > > Darshak noted this in a previous message: > > I=E2=80=99m not sure how a PS can force a UA to aggregate (unle= ss the PS > somehow identifies the client based on > authentication/cookie/something-else). > > I think that I would prefer something more explicit. Having something > explicit would allow the UA to opt out of aggregating. > I'm not in favor of anything allowing a UA to opt out of aggregating. Aggregating is a necessary server resource issue, the client should not be able to choose additional ways to impair the server or substantially increase the cost of running a Push Service. > > I may be taking it out of context as "something-else", but Benjamin als= o > commented: > > I'm associating one h2 connection as being one UA > > That's generally considered a bad idea. As the basis for an > optimization, maybe, but I wouldn't want to rely on that. > In what case would a single h2 connection not be a single UA? --089e0111d1be94a44a051cd021d1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Fri, Aug 7, 2015 at 5:44 PM, Martin Thomson <martin.thomson@gmai= l.com> wrote:
On 7 August 2015 at 16:31, Brian Raymor <Brian.Raymor@microsoft.com> wrote:
> Darshak noted this in a previous message:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I=E2=80=99m not sure how a PS can for= ce a UA to aggregate (unless the PS somehow identifies the client based on = authentication/cookie/something-else).

I think that I would prefer something more explicit.=C2=A0 Having so= mething
explicit would allow the UA to opt out of aggregating.

I'm not in favor of anything allowing a UA to opt out of aggregati= ng.=20 Aggregating is a necessary server resource issue, the client should not=20 be able to choose additional ways to impair the server or substantially inc= rease the cost of running a Push Service.
=C2=A0
> I may be taking it out of context as "something-else", but B= enjamin also commented:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I'm associating one h2 connection= as being one UA

That's generally considered a bad idea.=C2=A0 As the basis for a= n
optimization, maybe, but I wouldn't want to rely on that.

In what case would a single h2 connection not be a s= ingle UA?
--089e0111d1be94a44a051cd021d1-- From nobody Sat Aug 8 10:41:12 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0801A00C0 for ; Sat, 8 Aug 2015 10:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.722 X-Spam-Level: X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 p5licl0rCW62 for ; Sat, 8 Aug 2015 10:41:06 -0700 (PDT) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) (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 0254B1A00BD for ; Sat, 8 Aug 2015 10:41:05 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so48498041igb.0 for ; Sat, 08 Aug 2015 10:41:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=4hfZGoYr/WdSXSZwWWH1G7mbnE9zBLgbQaV3BiCgO+I=; b=HHPcllafGB76pA+Uec9A2qv0Lwp5cGcoLnxqgXN0pXqoHSlKwjYEB7j/DyHAVaQfS3 2yaGhaIYvEk0FWYAgJQV64TOkwAgbknUw/oda6eyAUyjI+r0ZEFqIAyaoFrXWZjaardW vTDpswZarv9KAP4zqphpGU2XKtXp/KrkLfXAi9ruCjr09CpteOZDcE8XA4CQVJOpnSMR gh6cFnUQkAg6vGtMxOTPkAAUcQnfQYC6Js3etNkmJ4DD5V0oWjsBFlITMdaHfnzprmMr 1qoE9d/DEJHSwJGlAFja7mZjQ33c3trE/gRANY0ASgeAOXYJ/Sl5sJgKvL0aTMWdNA3+ Nk+w== X-Gm-Message-State: ALoCoQls1NPkZRb9It4HwLcvL3/ki+1fZTFCjTmE0Inqdpne2Z2Ssa+wvswaop1lmjn2C4kcZhKa MIME-Version: 1.0 X-Received: by 10.50.43.193 with SMTP id y1mr4004630igl.89.1439055665379; Sat, 08 Aug 2015 10:41:05 -0700 (PDT) Received: by 10.79.93.1 with HTTP; Sat, 8 Aug 2015 10:41:05 -0700 (PDT) Date: Sat, 8 Aug 2015 10:41:05 -0700 Message-ID: From: Benjamin Bangert To: "webpush@ietf.org" Content-Type: multipart/alternative; boundary=089e0111d1bebf4b1f051cd041c6 Archived-At: Subject: [Webpush] h2 max streams and subscriptions 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, 08 Aug 2015 17:41:10 -0000 --089e0111d1bebf4b1f051cd041c6 Content-Type: text/plain; charset=UTF-8 How does the HTTP 2.0 SETTINGS_MAX_CONCURRENT_STREAMS setting adversely affect the UA under WebPush? For example, in a non-aggregated use-case, each GET for a subscription is given a stream ID, and will count against the max concurrent streams (since the main GET stream is never completed). A common setting in some existing h2 servers is 100 for max streams. Which means if you had 100 subscriptions, you would be unable to get any notifications, as each notification for a PUSH frame is a new stream, and they've all been exhausted. If the max streams case is hit, what should the UA do when new subscriptions are requested? Start unsubscribing from less used ones per a LRU? Return an error that a subscription couldn't be created? Aggregating would alleviate this greatly, since the subscription is a single stream in that case, and the remainder of the concurrent stream allowance is saved for additional commands/notifications. If it's possible for a non-aggregate case though, this seems like it wouldn't be that improbable to run up against the max streams. - Ben --089e0111d1bebf4b1f051cd041c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
How does the HTTP 2.0 SETTINGS_MA= X_CONCURRENT_STREAMS setting adversely affect the UA under WebPush?

=
For example, in a non-aggregated use-case, each GET for a subscriptio= n is given a stream ID, and will count against the max concurrent streams (= since the main GET stream is never completed).

A common settin= g in some existing h2 servers is 100 for max streams. Which means if you ha= d 100 subscriptions, you would be unable to get any notifications, as each = notification for a PUSH frame is a new stream, and they've all been exh= austed.

If the max streams case is hit, what should the UA do = when new subscriptions are requested? Start unsubscribing from less used on= es per a LRU? Return an error that a subscription couldn't be created?<= br>
Aggregating would alleviate this greatly, since the subscripti= on is a single stream in that case, and the remainder of the concurrent str= eam allowance is saved for additional commands/notifications. If it's p= ossible for a non-aggregate case though, this seems like it wouldn't be= that improbable to run up against the max streams.

- Ben
<= /div> --089e0111d1bebf4b1f051cd041c6-- From nobody Sat Aug 8 18:53: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 56CF81A8ABC for ; Sat, 8 Aug 2015 18:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 sNZBgZ4mKKEQ for ; Sat, 8 Aug 2015 18:53:57 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::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 B39651A8A93 for ; Sat, 8 Aug 2015 18:53:56 -0700 (PDT) Received: by lbbpo9 with SMTP id po9so78880021lbb.2 for ; Sat, 08 Aug 2015 18:53:55 -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=SZzFsU0zdzbV5+WusWQvNoTuYEYTr3obRcpOkCoUAyk=; b=Fs23lm3ebmCGhQ71Hi+k56sV+DOPja1Yt3sEWiIvHDpw5JX1sA02JNUR+os63gxmsT Yefxh6zBPOB0omIfUYddnv0EJTB/3tAwmRlyCS/I8xqm39Lt38HxKtny/MoaukMwRJvk 1U1+v+Ocs6M3+NVKvq9Y5Pq/ct5r2jU8JHwzFAlm1UoCbwVimTxrkoT6wz1zkX6bwW1d MHrRMmgfsfbEbEB+TzmvZ0+96NJkJnK344O9ipe0odltpeXtzElgBnPR59AkP36Pyy5l ChW5aUYUcV45nxFqiFDX4QFI9XZZegtyx9hrrVMyGUVigT6/ma+b1WRpONDjj3q8vbXE /FYw== MIME-Version: 1.0 X-Received: by 10.152.23.234 with SMTP id p10mr14691607laf.52.1439085235209; Sat, 08 Aug 2015 18:53:55 -0700 (PDT) Received: by 10.25.162.198 with HTTP; Sat, 8 Aug 2015 18:53:55 -0700 (PDT) In-Reply-To: References: Date: Sat, 8 Aug 2015 18:53:55 -0700 Message-ID: From: Martin Thomson To: Benjamin Bangert Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] h2 max streams and subscriptions 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, 09 Aug 2015 01:53:58 -0000 On 8 August 2015 at 10:41, Benjamin Bangert wrote: > A common setting in some existing h2 servers is 100 for max streams. Which > means if you had 100 subscriptions, you would be unable to get any > notifications, as each notification for a PUSH frame is a new stream, and > they've all been exhausted. The stream limit only applies to streams that you initiate, so the client's setting determines how many concurrent pushes the server can send. The server's setting - exhausted or not - has no effect on that. Obviously, a server that has a low concurrent stream limit can't be used with indepedent (i.e., not aggregated) subscriptions that exceed that number. That might be all the incentive you need to encourage use of aggregation (in the other thread). And I would not recommend opening a second connection to overcome this limit. From nobody Sun Aug 9 10:03: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 969BA1B2D3C for ; Sun, 9 Aug 2015 10:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.578 X-Spam-Level: X-Spam-Status: No, score=-0.578 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhjZNEZRbqfJ for ; Sun, 9 Aug 2015 10:03:27 -0700 (PDT) Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com [209.85.213.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B1BD1B2D39 for ; Sun, 9 Aug 2015 10:03:27 -0700 (PDT) Received: by igfj19 with SMTP id j19so37287444igf.1 for ; Sun, 09 Aug 2015 10:03:26 -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=aq5fqmbYD94QXvhXyyK3++KywGGmoxFisrnwOjtjY7M=; b=DGGHMYoVH75+PD4wH7Cew/0kKiySCzZRSaCr++XxrONKFJOdmokjrzrP0R3qljLzFP GU/x4N3iSsmzC2cdYN7S/KuRI4nBIgqcatc6BgHGGJLiV9P5aLVrBGGfD8KztJyOP3A+ TJdDanAw7yMhqDKzAxK/kWbq4C0yER6uQ7nXt7tISptgXCKS1eh2BflTg8ypw8zbSswd 46dU+jSPLqheNk8CxjHsfsLAXUe+gxZdrEVHjriqGXb8hgSY1Q7PMxO+EKO94IQ7OOR3 3PwH35/RBAHuGJVmnVyjVHipLnLAiPvD0xN61/t4sLI3N8UgVEaTmJQYObUz4iYbFW87 wF8Q== X-Gm-Message-State: ALoCoQnpCno5F5rYpqGFogrDVdYYqyhyc3OXxYyZK7/b9WT04y77/ciC0ilrkoEuNrPMEfnB3DnD MIME-Version: 1.0 X-Received: by 10.50.43.193 with SMTP id y1mr7662749igl.89.1439139806543; Sun, 09 Aug 2015 10:03:26 -0700 (PDT) Received: by 10.79.93.1 with HTTP; Sun, 9 Aug 2015 10:03:26 -0700 (PDT) In-Reply-To: References: Date: Sun, 9 Aug 2015 10:03:26 -0700 Message-ID: From: Benjamin Bangert To: Martin Thomson Content-Type: multipart/alternative; boundary=089e0111d1bef3a6a7051ce3d885 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] h2 max streams and subscriptions 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, 09 Aug 2015 17:03:29 -0000 --089e0111d1bef3a6a7051ce3d885 Content-Type: text/plain; charset=UTF-8 On Sat, Aug 8, 2015 at 6:53 PM, Martin Thomson wrote: > On 8 August 2015 at 10:41, Benjamin Bangert wrote: > > A common setting in some existing h2 servers is 100 for max streams. > Which > > means if you had 100 subscriptions, you would be unable to get any > > notifications, as each notification for a PUSH frame is a new stream, and > > they've all been exhausted. > > > The stream limit only applies to streams that you initiate, so the > client's setting determines how many concurrent pushes the server can > send. The server's setting - exhausted or not - has no effect on > that. > Ah, right. Forgot that the client has its own independent concurrent stream limit. > Obviously, a server that has a low concurrent stream limit can't be > used with indepedent (i.e., not aggregated) subscriptions that exceed > that number. That might be all the incentive you need to encourage > use of aggregation (in the other thread). And I would not recommend > opening a second connection to overcome this limit. > So in such a case, what is expected behavior when the concurrent stream limit is exceeded and a client wishes to make more subscriptions? The current WebPush spec has no language in it indicating what should occur, what action a client should take, etc. when it hits the max stream limit using independent subscriptions. --089e0111d1bef3a6a7051ce3d885 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Aug 8, 2015 at 6:53 PM, Martin Thomson <martin.thomson@gmail.co= m> wrote:
= On 8 August 2015 at 10:41, Benjamin Bangert <bbangert@mozilla.com> wrote:
> A common setting in some existing h2 servers is 100 for max streams. W= hich
> means if you had 100 subscriptions, you would be unable to get any
> notifications, as each notification for a PUSH frame is a new stream, = and
> they've all been exhausted.


The stream limit only applies to streams that you initiate, so the client's setting determines how many concurrent pushes the server can send.=C2=A0 The server's setting - exhausted or not - has no effect on<= br> that.

Ah, right. Forgo= t that the client has=C2=A0 its own independent concurrent stream limit.
=C2=A0
Obviously, a server that has a low concurrent stream limit can't be
used with indepedent (i.e., not aggregated) subscriptions that exceed
that number.=C2=A0 That might be all the incentive you need to encourage use of aggregation (in the other thread).=C2=A0 And I would not recommend opening a second connection to overcome this limit.

So in such a case, = what is expected behavior when the concurrent stream limit is exceeded and = a client wishes to make more subscriptions? The current WebPush spec has no= language in it indicating what should occur, what action a client should t= ake, etc. when it hits the max stream limit using independent subscriptions= .
--089e0111d1bef3a6a7051ce3d885-- From nobody Sun Aug 9 13:40:19 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 951851B2F3A for ; Sun, 9 Aug 2015 13:40: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 qkGLEc7k85cn for ; Sun, 9 Aug 2015 13:40:17 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::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 21BB11B2F2D for ; Sun, 9 Aug 2015 13:40:00 -0700 (PDT) Received: by lbbpu9 with SMTP id pu9so57730361lbb.3 for ; Sun, 09 Aug 2015 13:39:58 -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=fohMC27NJ9i1Z23w9yImO51ZTWZi2W1CSVLK61Nn+Xs=; b=hsPjx3kqLp+/Ol7Tq5pEVwH7puVijppyNPFDJsdPysHFnw8GvqNoexttvVpMDJRIcT VF27OQhJ37Kn+IIdpoi4ErU++BhCuFrVbFrCRlScRVvL00vznVnu1bfAfSkHU+aYjNqv T+daP+AUP4s3dm67ShLcTe206hkPWVmsrclBuViSYxZwEmCJ/ClhyViOfXmvQTMkloYF xxktftl3Ipv3RePzlpwYsxmEeKBbBKe2yqJe4JLQNvAv3aIikdlMyFQtCrU6RsSX4sFd EpvxFjEmUCQuhjsa8nojtsWWP69YtvN7kPZHEdI+J8u+YqiEWkMpNMmfykAoA3gSlbJX 6dnQ== MIME-Version: 1.0 X-Received: by 10.112.219.200 with SMTP id pq8mr17341804lbc.110.1439152798580; Sun, 09 Aug 2015 13:39:58 -0700 (PDT) Received: by 10.25.162.198 with HTTP; Sun, 9 Aug 2015 13:39:58 -0700 (PDT) In-Reply-To: References: Date: Sun, 9 Aug 2015 13:39:58 -0700 Message-ID: From: Martin Thomson To: Benjamin Bangert Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] h2 max streams and subscriptions 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, 09 Aug 2015 20:40:18 -0000 On 9 August 2015 at 10:03, Benjamin Bangert wrote: > So in such a case, what is expected behavior when the concurrent stream > limit is exceeded and a client wishes to make more subscriptions? The > current WebPush spec has no language in it indicating what should occur, > what action a client should take, etc. when it hits the max stream limit > using independent subscriptions. My suggestion would be to document the limit. If a server wants to limit the concurrent streams in order to limit the number of concurrent, independent subscriptions, then that seems like a valid thing to do. I would hope that clients respect this limit and therefore have to treat any additional subscriptions as failed (or at least temporarily inaccessible). See https://github.com/webpush-wg/webpush-protocol/issues/43 From nobody Sun Aug 9 14:34: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 862BA1A1B18 for ; Sun, 9 Aug 2015 14:34:19 -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 P9CHKCfpB6lw for ; Sun, 9 Aug 2015 14:34:17 -0700 (PDT) Received: from mail-io0-f178.google.com (mail-io0-f178.google.com [209.85.223.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 428851A1B13 for ; Sun, 9 Aug 2015 14:34:17 -0700 (PDT) Received: by iodb91 with SMTP id b91so93514869iod.1 for ; Sun, 09 Aug 2015 14:34:16 -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=YBLE/GFFWsxx+YBk/1E+IN8K36X6DE9PMMkz8zyOwBE=; b=U/MUK9RqP3G9iI4hxLG52YWgb4W++5IcHHH202JPqzK+VfGOS4+sji4IGwkcjE6qsx 6ufrtXlRqsyHAwvQQ++9Rq40L/uZ8g+3vCZtoAjl1Gfr8NwHR//UuG1coskj+F7RGSHB jkpyceILBR885mKWnDmrfnPfz/Ls0lnDbvmsbWA/Xys3udqVkeJ1Mt5zqBnGhBRxg3xK irq0WKJZb3qHfULqVRN5fgSvdVjoiLoynJFc2CpPZGekuMzAQ4eGX840KxYX3ipkXzc6 lVqcHmsqDekzAgu4efqwm7KNrN+ug+TQagGhxWXpL/p8brD6khkpeSCgtzZ0GSlvxdk0 xN8w== X-Gm-Message-State: ALoCoQmSfeEYIZqYvP5pBjkLgMm2sPO0aCBdmzvCgZqjw+HZKz6nXKLyCWzu+J1br/K2zbMmpgP9 MIME-Version: 1.0 X-Received: by 10.107.7.11 with SMTP id 11mr17708088ioh.81.1439156056423; Sun, 09 Aug 2015 14:34:16 -0700 (PDT) Received: by 10.79.93.1 with HTTP; Sun, 9 Aug 2015 14:34:16 -0700 (PDT) In-Reply-To: References: Date: Sun, 9 Aug 2015 14:34:16 -0700 Message-ID: From: Benjamin Bangert To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113f8bd28525ab051ce7a1a4 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] h2 max streams and subscriptions 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, 09 Aug 2015 21:34:19 -0000 --001a113f8bd28525ab051ce7a1a4 Content-Type: text/plain; charset=UTF-8 On Sun, Aug 9, 2015 at 1:39 PM, Martin Thomson wrote: > On 9 August 2015 at 10:03, Benjamin Bangert wrote: > > So in such a case, what is expected behavior when the concurrent stream > > limit is exceeded and a client wishes to make more subscriptions? The > > current WebPush spec has no language in it indicating what should occur, > > what action a client should take, etc. when it hits the max stream limit > > using independent subscriptions. > > My suggestion would be to document the limit. If a server wants to > limit the concurrent streams in order to limit the number of > concurrent, independent subscriptions, then that seems like a valid > thing to do. I would hope that clients respect this limit and > therefore have to treat any additional subscriptions as failed (or at > least temporarily inaccessible). > > See https://github.com/webpush-wg/webpush-protocol/issues/43 > I've added an additional note to this issue, indicating that using a setting of 2 for max streams might be one way for a server to ensure aggregate subscriptions are used. --001a113f8bd28525ab051ce7a1a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Aug 9, 2015 at 1:39 PM, Martin Thomson <martin.thomson@gmail.co= m> wrote:
= On 9 August 2015 at 10:03, Benjamin Bangert <bbangert@mozilla.com> wrote:
> So in such a case, what is expected behavior when the concurrent strea= m
> limit is exceeded and a client wishes to make more subscriptions? The<= br> > current WebPush spec has no language in it indicating what should occu= r,
> what action a client should take, etc. when it hits the max stream lim= it
> using independent subscriptions.

My suggestion would be to document the limit. If a server wants to limit the concurrent streams in order to limit the number of
concurrent, independent subscriptions, then that seems like a valid
thing to do. I would hope that clients respect this limit and
therefore have to treat any additional subscriptions as failed (or at
least temporarily inaccessible).

See https://github.com/webpush-wg/webpush-pr= otocol/issues/43

I've added an a= dditional note to this issue, indicating that using a setting of 2 for max = streams might be one way for a server to ensure aggregate subscriptions are= used.
--001a113f8bd28525ab051ce7a1a4-- From nobody Sun Aug 9 14:40:01 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 150461A1B5F for ; Sun, 9 Aug 2015 14:40:00 -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 bdcx20pjyZiB for ; Sun, 9 Aug 2015 14:39:59 -0700 (PDT) Received: from mail-la0-x243.google.com (mail-la0-x243.google.com [IPv6:2a00:1450:4010:c03::243]) (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 C784C1A1A79 for ; Sun, 9 Aug 2015 14:39:58 -0700 (PDT) Received: by labqg3 with SMTP id qg3so7902218lab.0 for ; Sun, 09 Aug 2015 14:39:57 -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=eMjr74/mZSr4vxQ0Amwgk4zE8ZUIGfrnQBwilnAb9WU=; b=a10gpIGnLI4Ol0rV9+4AkVF+EHNc+6n3y/VtJSBm34IeCXlGXIsHEbR3k+u1bGpa7t +UXFA+1qqY1QobDGseimT7kLfc3CJjd07Z76h2LFS9Jww7myAEA6eUKiIWUAo/S5kDMI 4pXYT1q3doPTK3hVXF+yhXhTepsV3ROoGbu6ZIk560lWH09rBgES2CjA/CelNu01P0Ml jTUjswaiYfXSKcleUYCWbDJl8JWLMDoBniLrsnyTQ11D75dMLpyIH8L0jdLgS8ySQ7nX 6N1xZDiTTftwMo8P6Vk6SxnkSBgWqnYVP485rgcLSp1QGrL86o0k6IpRMlnFSdmiGnet A5Pw== MIME-Version: 1.0 X-Received: by 10.112.209.106 with SMTP id ml10mr17442265lbc.112.1439156397138; Sun, 09 Aug 2015 14:39:57 -0700 (PDT) Received: by 10.25.162.198 with HTTP; Sun, 9 Aug 2015 14:39:57 -0700 (PDT) In-Reply-To: References: Date: Sun, 9 Aug 2015 14:39:57 -0700 Message-ID: From: Martin Thomson To: Benjamin Bangert Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] h2 max streams and subscriptions 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, 09 Aug 2015 21:40:00 -0000 On 9 August 2015 at 14:34, Benjamin Bangert wrote: > I've added an additional note to this issue, indicating that using a setting > of 2 for max streams might be one way for a server to ensure aggregate > subscriptions are used. Right. Note that it also has the side-effect of serlializing requests for new subscriptions; which you might consider to be good or bad depending on your perspective. From nobody Tue Aug 18 13:47: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 C0A981A9301 for ; Tue, 18 Aug 2015 13:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUtNv-IbGWPV for ; Tue, 18 Aug 2015 13:47:13 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0109.outbound.protection.outlook.com [207.46.100.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2898D1ABD36 for ; Tue, 18 Aug 2015 13:47:12 -0700 (PDT) Received: from BY2PR0301MB0648.namprd03.prod.outlook.com (10.160.63.140) by BY2PR0301MB1528.namprd03.prod.outlook.com (10.163.27.154) with Microsoft SMTP Server (TLS) id 15.1.231.21; Tue, 18 Aug 2015 20:47:12 +0000 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.231.21; Tue, 18 Aug 2015 20:47:11 +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.0231.024; Tue, 18 Aug 2015 20:47:12 +0000 From: Brian Raymor To: Peter Beverloo , Costin Manolache , "webpush@ietf.org" Thread-Topic: [webpush-protocol] Sender and client authentication (#44) Thread-Index: AQHQ1twqKurFanwYbEKUE78yf16Tr54SPVfA Date: Tue, 18 Aug 2015 20:47:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brian.Raymor@microsoft.com; x-originating-ip: [131.107.192.203] x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0648; 5:UD2C3fobgIvOOeIiomMtrsoEuJ2zG0r86OT/ZqXGULy4cypMHt+lLOf48wkil+d8zRC2o5yl396kYGGyqVTpDGp27iO9SYbipnfqB5uTuGLEtLg+4dFfN/FhccAsZHhbjodbvGIokUgYNPHX4PvRnQ==; 24:8QuoJ0z1N9L9xVBvQJmzzPA/rhZItc/z75IGEYDxYLme8P8MoDOZ03bkNqlQ8iGne0tSX41ACfpGl4Jsrby+E7vi4UYpmhS/QCQb7Gwsa34=; 20:JdGdDvmJXUZvRrKGV+ryASkvl/9MhfU2Yql6aw23tyXaa48GzSHfnezkpdsEE88kuLU4nfFIct5fUo2pE2+AFw== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42139001); SRVR:BY2PR0301MB0648; UriScan:; BCL:0; PCL:0; RULEID:(42139001); SRVR:BY2PR0301MB1528; x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(8121501046)(5005006)(3002001); SRVR:BY2PR0301MB0648; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0648; x-forefront-prvs: 067270ECAF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(377454003)(189002)(19580405001)(4001540100001)(2656002)(189998001)(122556002)(97736004)(5001960100002)(81156007)(74316001)(76576001)(5003600100002)(19580395003)(5002640100001)(5001770100001)(5001860100001)(107886002)(33656002)(46102003)(10290500002)(86362001)(2900100001)(15975445007)(8990500004)(40100003)(77156002)(102836002)(77096005)(68736005)(101416001)(2950100001)(5001830100001)(62966003)(99286002)(54356999)(105586002)(10090500001)(106116001)(92566002)(5005710100001)(76176999)(50986999)(2501003)(86612001)(106356001)(10400500002)(87936001)(66066001)(64706001); 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-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2015 20:47:11.8965 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0648 X-Microsoft-Exchange-Diagnostics: 1; BY2PR0301MB1528; 2:kK848WOes2HMF1CBtZHs+F/IwAf8SMRJ0SeuNQmkFmoycvCRa0MK4GVfxDm7o1npmveqfhW3AF4UxVRaPGDHD+smakLAzZjuLryYQfOaZVEYPs6d8oesVwb8zx4ZaiQo1RYAloIaSYSMR8gsDpXMDspeGIU2ZwIK4MRTHDs5qI0=; 3:GEqe0yRoW0hNjGx6eHIPsF2p/xla+sE15ndc41B11A2A+CoRLxcExWvXPnpZ+XcNznQA/Xc/vFchOrRJz5Y5OFd8FtUWSV8vKTJLS0VDBld5EokAXsH4riBWuMuMoYjad0a2zKxZFcrKFveL0kZtYP5A6cuye4sC+O20U4gGroI=; 25:PicPFQo0ZewFCyYAo5hrCvlXfPoXcJA9CP3fY42W1qoSG2OpGCR2z/ClwddZPnHY9zVceAuWtpRd+/MqepPBS9m1UI2RhhQ5gLCMdOBdyR7S3TdFowj2BwY1s83zuMKGRujZ0l4yk0Mgwe/BGzV1RJHr7otwSPmdDYymLsRe4t3aoCQRcbhAqidNfA7hvn+wzME9xDilpZV8mI0d24xwSufB2cvTVIKmQu2L3JPsWluEN+g2Goqf5aE176BrPdzATM9lya40N1nJDTmjhbrLFQ==; 23:1TWluRru6y1lscwY73mpcHcC8iV3jmiteSwAsDbyvrn7omJ5KZ+m3Guby+W5jxjgENUiNX4Qn4bNkbRLLMQeoLfZ6jafIr8Qc0UJ8bhuRVK9jgzgISOwoN9wArODqhVgR2sU1rP2Vz2Uf5J1zbQ6aqmFF0eOapt+QHngmyhPsrjXO2V3mJJ//5gLLfkxT+cg X-OriginatorOrg: microsoft.com Archived-At: Subject: [Webpush] FW: [webpush-protocol] Sender and client authentication (#44) 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, 18 Aug 2015 20:47:14 -0000 Q29zdGluIG9wZW5lZCBhIG5ldyBkZXNpZ24gaXNzdWUgb24gZ2l0aHViIC0gaHR0cHM6Ly9naXRo dWIuY29tL3dlYnB1c2gtd2cvd2VicHVzaC1wcm90b2NvbC9pc3N1ZXMvNDQgLSBJJ20gZm9yd2Fy ZGluZyBpdCB0byB0aGUgbWFpbGluZyBsaXN0IGZvciBhd2FyZW5lc3MgYW5kIGZ1cnRoZXIgZGlz Y3Vzc2lvbi4NCg0KUGV0ZXIgLSBhcmUgeW91IHN0aWxsIGNvbnNpZGVyaW5nIGEgZHJhZnQ/IEVh cmxpZXIgLSBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3dlYnB1c2gvSW8x eXltVjI2bm1OeTNLNF9PMDFSN3ZONmRJIC0geW91IG1lbnRpb25lZCB0aGF0IHlvdSB3ZXJlIHdv cmtpbmcgb24gDQphbiBlYXJseSBkcmFmdCByZWxhdGVkIHRvOg0KDQoNCiAgPiBUaGUgbGFyZ2Ug b3BlbiB0b3BpYyBmb3IgdXMgaXMgZW5jcnlwdGlvbiwgYW5kIGhvdyB0aGlzIHRpZXMgaW4gdG8N CiAgPiBvbmUtdG8tbWFueSBkaXN0cmlidXRpb24gb2YgbWVzc2FnZXMgYnkgdGhlIHB1c2ggc2Vy dmljZS4gQWxzbyByZWxhdGVkIHRvDQogID4gdGhpcyBpcyB0aGUgc3ViamVjdCBvZiBhdXRoZW50 aWNhdGlvbiwgbm90YWJseSBvZiB0aGUgc2VuZGVyIChhcHBsaWNhdGlvbg0KICA+IHNlcnZlciku DQoNCg0KRnJvbTogQ29zdGluIE1hbm9sYWNoZSBbbWFpbHRvOm5vdGlmaWNhdGlvbnNAZ2l0aHVi LmNvbV0gDQpTZW50OiBGcmlkYXksIEF1Z3VzdCAxNCwgMjAxNSAyOjU3IFBNDQpUbzogd2VicHVz aC13Zy93ZWJwdXNoLXByb3RvY29sIDx3ZWJwdXNoLXByb3RvY29sQG5vcmVwbHkuZ2l0aHViLmNv bT4NClN1YmplY3Q6IFt3ZWJwdXNoLXByb3RvY29sXSBTZW5kZXIgYW5kIGNsaWVudCBhdXRoZW50 aWNhdGlvbiAoIzQ0KQ0KDQpQdXNoIHNlcnZpY2VzIG1heSByZXF1aXJlIGF1dGhlbnRpY2F0aW9u IG9mIFVBLCB3aGVuIHRoZXkgY29ubmVjdCB0byB0aGUgcHVzaCBzZXJ2aWNlIHRvIHN1YnNjcmli ZSBvciBwb2xsLCBhbmQgb2YgYXBwbGljYXRpb24gc2VydmVycy4NClRoZSBzcGVjIHNob3VsZCBk ZWZpbmUgb25lIHN1Y2ggbWVjaGFuaXNtIC0gZm9yIGV4YW1wbGUgYnkgdXNpbmcgYSBrZXkgcGFp ciBmb3IgZWFjaCBVQSBhbmQgZm9yIGVhY2ggYXBwbGljYXRpb24gc2VydmVyLCBhbmQgdXNpbmcg b25lIG9mIHRoZSBjb21tb24gbWVjaGFuaXNtcyAtIFRMUyBjbGllbnQgYXV0aCwgSldUIHRva2Vu cyAtIHRvIGF1dGhlbnRpY2F0ZS4NClVzaW5nIGEga2V5IHBhaXIgYWxzbyBhbGxvd3MgQXBwbGlj YXRpb25TZXJ2ZXJzIHRvIHRhbGsgd2l0aCBtdWx0aXBsZSBwdXNoIHNlcnZpY2VzIHVzaW5nIGEg c2luZ2xlIGlkZW50aXR5LiANClRoZSBrZXkgb2YgdGhlIHNlbmRlciBjYW4gYmUgbWFkZSBhdmFp bGFibGUgdG8gdGhlIFVBIGFuZCB3ZWJhcHBsaWNhdGlvbiBieSB0aGUgcHVzaCBzZXJ2aWNlIC0g b3IgY2FuIGJlIHVzZWQgYXMgYW4gZXh0cmEgYXV0aGVudGljYXRpb24gaW4gdGhlIGVuY3J5cHRl ZCBjb250ZW50IC0gZm9yIGV4YW1wbGUgc2lnbmluZyB0aGUgZXBoZW1lcmFsIGtleS4NCuKAlA0K UmVwbHkgdG8gdGhpcyBlbWFpbCBkaXJlY3RseSBvciB2aWV3IGl0IG9uIEdpdEh1Yi4NCg== From nobody Thu Aug 27 16:08: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 7F6651A8A6C for ; Thu, 27 Aug 2015 16:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 OmeXOB6UMK6x for ; Thu, 27 Aug 2015 16:08:18 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0738.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::738]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 948FB1A88E1 for ; Thu, 27 Aug 2015 16:08:18 -0700 (PDT) Received: from BY2PR0301MB0645.namprd03.prod.outlook.com (10.160.63.13) by BY2PR0301MB0600.namprd03.prod.outlook.com (10.160.125.22) with Microsoft SMTP Server (TLS) id 15.1.256.15; Thu, 27 Aug 2015 23:08:16 +0000 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.256.15; Thu, 27 Aug 2015 23:08:15 +0000 Received: from BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) by BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) with mapi id 15.01.0256.013; Thu, 27 Aug 2015 23:08:15 +0000 From: Brian Raymor To: "webpush@ietf.org" Thread-Topic: Editorial changes to Section 5.2 Push Message Time-To-Live Thread-Index: AdDhHJJ1elr2SsD4S3+lZ2ATAw3HmQ== Date: Thu, 27 Aug 2015 23:08:14 +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; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [131.107.192.113] x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0645; 5:Fbe5st4wjAlgLEFA+NL03eozsYPBPxOMuu2BTINBZXquUIxZu1Fa98zgbcdPOVeynuim/9mDx7dquaEYtFiCVxS0tbJuf4eS9a/7rAvSvxaRfJmcUlhqWQt4LK+ODxN7cRPZO4WH2suhQpB/mxPuNQ==; 24:0Bp47MLR4Jo+SXJFKyG57c/bFU4ROfPa1muz9wJ2JKQNCHBmL/wM0mDiWA4d5biXz/EkIFAgYFQbvnhTvJcqji6qD84/pM8x6qu5pqsqmPo=; 20:oRZ4/5IHivHuDFE4DfHv32N9XYPqh92xln8TiQnHpqzT8ZE08pDc1vKgCaYvTtAX7lQP9Sr4gD57DtkgiNVeYA== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0645; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0600; x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(8121501046)(5005006)(3002001); SRVR:BY2PR0301MB0645; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0645; x-forefront-prvs: 06818431B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(164054003)(199003)(87936001)(66066001)(64706001)(8990500004)(5005710100001)(50986999)(2900100001)(229853001)(15975445007)(10400500002)(99286002)(10290500002)(86362001)(54356999)(10090500001)(106356001)(558084003)(81156007)(2351001)(4001540100001)(101416001)(122556002)(105586002)(76576001)(5001960100002)(450100001)(74316001)(86612001)(33656002)(5003600100002)(68736005)(102836002)(40100003)(189998001)(5002640100001)(5004730100002)(77156002)(5001830100001)(19580395003)(77096005)(5007970100001)(62966003)(2656002)(97736004)(230783001)(46102003)(5001860100001)(110136002)(2501003)(92566002)(107886002); 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Aug 2015 23:08:14.3648 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0645 X-Microsoft-Exchange-Diagnostics: 1; BY2PR0301MB0600; 2:jzinUVp3XwwFrSlLFVRQzKqPSthgdJWcSAA6ZNKSZRBxEqiGr+JR2pp/Ed2epdHaSb5lVYyYxHsP4hslQ3K4AB1TNnlIrqPWyu7KJ2TqXpAbFHUqMWfgxjofsr7jW5qgpFu7md7RVNjyLj3MfK1xr/PSz7qSZsYOjwZndsltAcU=; 3:HcqpREGGFMbqPmDQjoOMf/rL45xgULNKjvewDN7PIlcZLyvtm3jVTWnTXC8xQBVagqyYa715ATvtH1cAdGxpoMnRSRvvnf43fz+FQmJ8Q2t8pIWwCtpgSwago/3cJ94A16But3PuPbYv0j7MAOrQig==; 25:APV3N9mf7STMpxXdfgfWLOx1WGrCf5H5Dwb9/ys0198iASmAeSMv2xIuPeqN9q1ySIM9RWp47Ae+x+nFrccJxasK+xi/oeKY/Ve9fncCh+l+qheOCSfEAWobR9V7btZkPg8iohvkAzR7x92EIFftcFknBH58xu1AwP5RVaTKxY4dpPMM6JRYHOGwyIDZ4JOJ2LlmSpaOmgVSLuAn+g4axXaeTOUz7TbTpkkh77JZTj02BWR1bT8Gzw971ZnVFl1QKmK/bUy9iWsCJpbSXrPPOQ==; 23:sjBlUSKSsswsk/5Sv3GNUZsmtPEqu2IurqnJ9/vZk3JD56WpzaMA5+Nr0wfMJglA+W7Q68svHEgk3XSoMru1swWDEDq5JV/PQcRS3zh/40IDke0UiSgDN9Me62nUuTxXGfhJv8N3/Z3m/fngQgKt18h2EcCMA2OLc5UbxB7DbqEwwnI9bhpBXcvbpr4HzBWQ X-OriginatorOrg: microsoft.com Archived-At: Subject: [Webpush] Editorial changes to Section 5.2 Push Message Time-To-Live 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, 27 Aug 2015 23:08:20 -0000 I've created a pull request for editorial changes related to TTL discussion= s on the mailing list: https://github.com/webpush-wg/webpush-protocol/pull/45 This addresses issues #35 and #38. Please let me know if there are additional comments before I merge tomorrow= . Thanks, ...Brian From nobody Thu Aug 27 17:16:00 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00FE91AD35A for ; Wed, 19 Aug 2015 02:16:18 -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 UqMEdU7qGfcu for ; Wed, 19 Aug 2015 02:16:16 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 481C51AD367 for ; Wed, 19 Aug 2015 02:16:15 -0700 (PDT) Received: by igxp17 with SMTP id p17so100834281igx.1 for ; Wed, 19 Aug 2015 02:16:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=XxV2kUID8RA3q7RUVj8ahz9AaTq2rz1qxj9CY6SiP0I=; b=RZCmBDPlsY9zGM7HmhDGqmxYuOSE01oukyYk7ux0zA9opuHhzcPjhrogyPpyxHg4pH 7hawwBPTDAzytNxOqdIVrAkYoQ2T0IOANgv+cjWTHi5MhStak6ShFDbz7B8f/0dPNMew 8Uam3tH1CCS1RTXlm+UN2WzDJH7suYngpXIGgOicHf4D+zmELOcv8esAeU9LAsr+4jte Xy0IFQftmTVPaxBsE9NRYjMUzHvsMxy554xHa3xJpcKgPzO1Acrwmb7Hks155GaP2uCW RHd9N7K34SORz4dAiIzfBF0EfvTGMpzvi28z99KxSZqzlbLzcScWNUAGP0PWKahEuh9/ lWWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=XxV2kUID8RA3q7RUVj8ahz9AaTq2rz1qxj9CY6SiP0I=; b=NFyIzFiNUKvM5kq56MrOahNmt/UrnJANf7qqgwCuVA+llr8kNDLdAPRkKcJrDw7lLN dzQhcj/MKCkDxzKYO9s78Z+R6XR/ZAIzBife4BYiqOY/OuczHKEdaHY6Bb2QJHCO5M5l dvGSGMjG7NXvlwyFQxhS4+1F0O+8k90/wU6xnYcoXIBZVt4gokZFF6S1k741mICVmHiB VGoFDwBhqVDqaB8tDjlFC8VtpyLTlQXWc9JzccLjKORn9HUYfYUD7ooJKESDBkvEvm0G HXC3aAmiXCYmKGoAjU5zLHzmoBqh6i0PGwCzyhyflT9aD0qRG/as03ku+IaCvDGq4pVM qKdA== X-Gm-Message-State: ALoCoQnkVozSVhcXte68QQ4wgX2AXTZemRWXwOMRoC7dlMJ0ihCPuijZTcYg+atgOPzoLMb/n6mI X-Received: by 10.50.143.43 with SMTP id sb11mr11322372igb.69.1439975774582; Wed, 19 Aug 2015 02:16:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.167 with HTTP; Wed, 19 Aug 2015 02:15:54 -0700 (PDT) In-Reply-To: References: From: Miguel Garcia Date: Wed, 19 Aug 2015 10:15:54 +0100 Message-ID: To: Brian Raymor Content-Type: multipart/alternative; boundary=001a1135e91a87bb6e051da67c2f Archived-At: X-Mailman-Approved-At: Thu, 27 Aug 2015 17:16:00 -0700 Cc: Costin Manolache , "webpush@ietf.org" , Peter Beverloo Subject: Re: [Webpush] FW: [webpush-protocol] Sender and client authentication (#44) 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, 19 Aug 2015 09:16:18 -0000 --001a1135e91a87bb6e051da67c2f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Just a quick note to mention that Peter is OOO and will only be back next week. He is still considering a draft indeed. On Tue, Aug 18, 2015 at 9:47 PM, Brian Raymor wrote: > Costin opened a new design issue on github - > https://github.com/webpush-wg/webpush-protocol/issues/44 - I'm forwarding > it to the mailing list for awareness and further discussion. > > Peter - are you still considering a draft? Earlier - > https://mailarchive.ietf.org/arch/msg/webpush/Io1yymV26nmNy3K4_O01R7vN6dI > - you mentioned that you were working on > an early draft related to: > > > > The large open topic for us is encryption, and how this ties in to > > one-to-many distribution of messages by the push service. Also relate= d > to > > this is the subject of authentication, notably of the sender > (application > > server). > > > From: Costin Manolache [mailto:notifications@github.com] > Sent: Friday, August 14, 2015 2:57 PM > To: webpush-wg/webpush-protocol > Subject: [webpush-protocol] Sender and client authentication (#44) > > Push services may require authentication of UA, when they connect to the > push service to subscribe or poll, and of application servers. > The spec should define one such mechanism - for example by using a key > pair for each UA and for each application server, and using one of the > common mechanisms - TLS client auth, JWT tokens - to authenticate. > Using a key pair also allows ApplicationServers to talk with multiple pus= h > services using a single identity. > The key of the sender can be made available to the UA and webapplication > by the push service - or can be used as an extra authentication in the > encrypted content - for example signing the ephemeral key. > =E2=80=94 > Reply to this email directly or view it on GitHub. > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > --001a1135e91a87bb6e051da67c2f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just a quick note to mention that Peter is OOO and will on= ly be back next week. He is still considering a draft indeed.

On Tue, Aug 18, 2015 at 9= :47 PM, Brian Raymor <Brian.Raymor@microsoft.com> w= rote:
Costin opened a new design issue on= github - https://github.com/webpush-wg/webp= ush-protocol/issues/44 - I'm forwarding it to the mailing list for = awareness and further discussion.

Peter - are you still considering a draft? Earlier - https://mailarchive.ietf.org/arch/msg/webpush/Io1= yymV26nmNy3K4_O01R7vN6dI - you mentioned that you were working on
an early draft related to:


=C2=A0 > The large open topic for us is encryption, and how this ties in= to
=C2=A0 > one-to-many distribution of messages by the push service. Also = related to
=C2=A0 > this is the subject of authentication, notably of the sender (a= pplication
=C2=A0 > server).


From: Costin Manolache [mailto:= notifications@github.com]
Sent: Friday, August 14, 2015 2:57 PM
To: webpush-wg/webpush-protocol <webpush-protocol@noreply.github.com>
Subject: [webpush-protocol] Sender and client authentication (#44)

Push services may require authentication of UA, when they connect to the pu= sh service to subscribe or poll, and of application servers.
The spec should define one such mechanism - for example by using a key pair= for each UA and for each application server, and using one of the common m= echanisms - TLS client auth, JWT tokens - to authenticate.
Using a key pair also allows ApplicationServers to talk with multiple push = services using a single identity.
The key of the sender can be made available to the UA and webapplication by= the push service - or can be used as an extra authentication in the encryp= ted content - for example signing the ephemeral key.
=E2=80=94
Reply to this email directly or view it on GitHub.
_______________________________________________
Webpush mailing list
Webpush@ietf.org
https://www.ietf.org/mailman/listinfo/webpush

--001a1135e91a87bb6e051da67c2f--