From nobody Wed Jun 1 04:46:23 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 831F612D0F3 for ; Wed, 1 Jun 2016 04:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTealJcdKq4R for ; Wed, 1 Jun 2016 04:46:19 -0700 (PDT) Received: from inari-msr.crf.canon.fr (inari-msr.crf.canon.fr [194.2.158.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C10412B041 for ; Wed, 1 Jun 2016 04:46:18 -0700 (PDT) Received: from mir-msr.corp.crf.canon.fr (mir-msr.corp.crf.canon.fr [172.19.77.98]) by inari-msr.crf.canon.fr (8.13.8/8.13.8) with ESMTP id u51BkG7u006662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Jun 2016 13:46:16 +0200 Received: from Antiope.crf.canon.fr (antiope.fesl2.crf.canon.fr [172.19.70.56]) by mir-msr.corp.crf.canon.fr (8.13.8/8.13.8) with ESMTP id u51BkGnf031250; Wed, 1 Jun 2016 13:46:16 +0200 Received: from Antiope.crf.canon.fr (172.19.70.62) by Antiope.crf.canon.fr (172.19.70.62) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 1 Jun 2016 13:46:15 +0200 Received: from Antiope.crf.canon.fr ([fe80::5c25:f890:ae73:d15a]) by Antiope.crf.canon.fr ([fe80::5c25:f890:ae73:d15a%12]) with mapi id 15.00.0995.032; Wed, 1 Jun 2016 13:46:15 +0200 From: RUELLAN Herve To: Peter Beverloo , "webpush@ietf.org" Thread-Topic: [Webpush] Non-blocking comments on -05 Thread-Index: AQHRu3RPtv1gb54CNUWyRYz7Gkh/JZ/UfYOQ Date: Wed, 1 Jun 2016 11:46:14 +0000 Message-ID: <6af49c2baf1b4e4f884b812d573b947e@Antiope.crf.canon.fr> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.5.242] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Webpush] Non-blocking comments on -05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 11:46:21 -0000 SGVsbG8gZXZlcnlvbmUsDQoNCkkgYWxzbyBoYXZlIHNvbWUgY29tbWVudHMgb24gdGhlIHNwZWMs IG5vbmUgb2Ygd2hpY2ggYXJlIGJsb2NraW5nIGZvciB0aGUgV0dMQy4NCg0KSSBhbHNvIGdlbmVy YXRlZCBhIHB1bGwtcmVxdWVzdCBmb3IgZWRpdG9yaWFsIHRoaW5nczoNCmh0dHBzOi8vZ2l0aHVi LmNvbS93ZWJwdXNoLXdnL3dlYnB1c2gtcHJvdG9jb2wvcHVsbC85Mw0KDQpBbmQgYW5vdGhlciBv bmUgZm9yIGNoYW5naW5nIHRoZSBVUklzIHVzZWQgaW4gdGhlIGV4YW1wbGVzIGFuZCBtYWtpbmcg dGhlbSBtb3JlIGV4cGxpY2l0ICh3aGljaCBJIHRoaW5rIGlzIGhlbHBmdWwgZm9yIGEgZmlyc3Qt dGltZSByZWFkZXIgb2YgdGhlIHNwZWMpOg0KaHR0cHM6Ly9naXRodWIuY29tL3dlYnB1c2gtd2cv d2VicHVzaC1wcm90b2NvbC9wdWxsLzk0DQoNCg0KMS4gU29tZSBvZiB0aGUgVVJOcyB1c2VkIG1h eSBiZSBjb25mdXNpbmcuIFJlbmFtaW5nIHRoZW0gY291bGQgaGVscCBtYWtlIHRoaW5ncyBjbGVh cmVyLg0KDQpUaGUgcHVzaCBtZXNzYWdlIHN1YnNjcmlwdGlvbiBzZXQgVVJOLCAidXJuOmlldGY6 cGFyYW1zOnB1c2g6c2V0IiwgY291bGQgYmUgY2hhbmdlZCB0byAidXJuOmlldGY6cGFyYW1zOnB1 c2g6c3ViOnNldCIsIHRvIGJldHRlciBzaG93IGl0IGlzIHJlbGF0ZWQgdG8gcHVzaCBtZXNzYWdl IHN1YnNjcmlwdGlvbiByZXNvdXJjZXMgYW5kIG5vdCBkaXJlY3RseSB0byBwdXNoIHJlc291cmNl cy4NCg0KVGhlIHJlY2VpcHQgc3Vic2NyaXB0aW9uIFVSTiwgInVybjppZXRmOnBhcmFtczpwdXNo OnJlY2VpcHQiLCBjb3VsZCBiZSBjaGFuZ2VkIHRvICJ1cm46aWV0ZjpwYXJhbTpwdXNoOnJlY2Vp cHQ6c3ViIiwgdG8gYmV0dGVyIHNob3cgaXQgY29ycmVzcG9uZHMgdG8gYSByZWNlaXB0ICpzdWJz Y3JpcHRpb24qIHJlc291cmNlIGFuZCBub3QgdG8gYSByZWNlaXB0IHJlc291cmNlIChldmVuIGlm IHRoZXNlIGRvbid0IGV4aXN0KS4NCg0KDQoyLiBXaGF0IGRvZXMgYSBwdXNoIHNlcnZlciB0aGF0 IHJlY2VpdmVzIGEgcmVxdWVzdCBmb3IgYSBwdXNoIG1lc3NhZ2Ugd2l0aCAiUHJlZmVyOiByZXNw b25kLWFzeW5jIiBidXQgZG9lc24ndCB3YW50IHRvIHByb3ZpZGUgYSByZWNlaXB0IHN1YnNjcmlw dGlvbiwgb3IgZG9lc24ndCBzdXBwb3J0IHByb3ZpZGluZyByZWNlaXB0cz8gSXMgdGhpcyBhbGxv d2VkIGluIHRoZSBmaXJzdCBwbGFjZT8NCg0KDQozLiBBZGRzIGluIDUuMSBhIHBhcmFncmFwaCBz aW1pbGFyIHRvIHRoZSB0aGlyZCBvbmUgb2YgNC4xIChjb250YWluaW5nIHNvbWUgbW9kaWZpY2F0 aW9ucyBmcm9tIG15IGVkaXRvcmlhbCBwdWxsLXJlcXVlc3QpOg0KDQpBbiBhcHBsaWNhdGlvbiBz ZXJ2ZXIgTUFZIG9taXQgdGhlIHJlY2VpcHQgc3Vic2NyaXB0aW9uIGlmIGl0IGlzIHVuYWJsZSB0 byByZWNlaXZlIHJlY2VpcHRzIGluIGFuIGFnZ3JlZ2F0ZWQgd2F5IGZvciB0aGUgbGlmZXRpbWUg b2YgdGhlIHB1c2ggbWVzc2FnZXMuIFRoaXMgbWlnaHQgYmUgbmVjZXNzYXJ5IGlmIHRoZSBhcHBs aWNhdGlvbiBzZXJ2ZXIgaXMgZm9yd2FyZGluZyBwdXNoIG1lc3NhZ2VzIGZyb20gb3RoZXIgc2Vy dmVycy4NCg0KDQo0LiBJbiA1LjQsIHJlcGxhY2U6DQoNCkEgMjAxIChDcmVhdGVkKSByZXNwb25z ZSBpbmRpY2F0ZXMuLi4NCg0Kd2l0aDoNCg0KQSAyMDEgKENyZWF0ZWQpIHJlc3BvbnNlIG9yIGEg MjAyIChBY2NlcHRlZCkgcmVzcG9uc2UgaW5kaWNhdGVzLi4uDQoNCg0KNS4gSW4gNiwgaW4gdGhl IGxhc3QgcGFyYWdyYXBoIChhbmQgc2ltaWxhcmx5IGluIDYuMSksIHJlcGxhY2U6DQoNCkEgMjA0 IChObyBDb250ZW50KSBzdGF0dXMgY29kZSB3aXRoIG5vIGFzc29jaWF0ZWQgc2VydmVyIHB1c2hl cy4uLg0KDQp3aXRoOg0KDQpBIDIwNCAoTm8gQ29udGVudCkgc3RhdHVzIGNvZGUgc2VudCBpbiBy ZXNwb25zZSB0byB0aGUgaW5pdGlhbCByZXF1ZXN0IHdpdGggbm8gYXNzb2NpYXRlZCBzZXJ2ZXIg cHVzaGVzLi4uDQoNCg0KNi4gSW4gNi4xLCBtYXliZSBlbXBoYXNpemUgdGhlIGRpZmZlcmVuY2Ug b24gdGhlIGxvY2F0aW9uIG9mIHRoZSBsaW5rIGhlYWRlciAoUFVTSF9QUk9NSVNFIHZzIHJlc3Bv bnNlKSBhbmQgZ2l2ZSBzb21lIHJlYXNvbiBmb3IgdGhpcyBkaWZmZXJlbmNlLg0KDQoNCjcuIElu IDYuMywgd2hhdCBpcyB0aGUgc3RhdHVzIGNvZGUgZm9yIGEgbWVzc2FnZSBub3Qgc3VjY2Vzc2Z1 bGx5IGRlbGl2ZXJlZCBhdCBpdHMgZXhwaXJhdGlvbiB0aW1lPw0KDQoNCjguIFRoZSBkcmFmdCBp cyBub3QgY2xlYXIgb24gaG93IEdFVCB0byBzdWJzY3JpcHRpb24gcmVzb3VyY2VzIChvciBzdWJz Y3JpcHRpb24gc2V0KSBhcmUgaGFuZGxlZC4gSXQgaXMgc3RhdGVkIHRoYXQgdGhlIHB1c2ggc2Vy dmljZSBkb2VzIG5vdCByZXNwb25kIHRvIHRoaXMgcmVxdWVzdC4gSG93ZXZlciB0aGUgbGFzdCBw YXJhZ3JhcGggb2YgNiB0ZWxscyBhYm91dCB1c2luZyBhIDIwNCAoTm8gQ29udGVudCkgc3RhdHVz IGNvZGUgd2hlbiBubyBtZXNzYWdlcyBhcmUgYXZhaWxhYmxlLCBhbmQgdGhpcyBpcyBzdGF0ZWQg YWdhaW4gYnkgcGFyYWdyYXBoIDQgb2YgNy4yLiBJcyBpdCBvbmx5IGZvciB0aGUgY2FzZSB3aGVu ICJQcmVmZXI6IHdhaXQ9MCIgaGVhZGVyIGZpZWxkIGlzIHVzZWQ/IE9yIGNhbiB0aGUgcHVzaCBz ZXJ2ZXIgdXNlIGl0IHRvIGNsb3NlIHRoZSBjb25uZWN0aW9uPw0KDQoNCjkuIEluIDcuNSwgYWRk IGEgcGFyYWdyYXBoIGZvciB0aGUgY2xpZW50IHByb3h5aW5nIHNjZW5hcmlvOg0KDQpJdCBzaG91 bGQgYmUgbm90ZWQgdGhhdCBzb21lIHVzZXIgYWdlbnQgbWlnaHQgbmVlZCB0byB1c2Ugc2V2ZXJh bCBzdWJzY3JpcHRpb24gc2V0cyBpZiB0aGV5IGFyZSBmb3J3YXJkaW5nIHN1YnNjcmlwdGlvbiBy ZXF1ZXN0cyBmcm9tIG90aGVyIHNlcnZlcnMuDQoNCg0KDQpUaGFua3MgZm9yIGFsbCB0aGUgd29y ayBvbiB0aGUgc3BlYywNCg0KSGVydsOpDQo= From nobody Wed Jun 1 04:49:12 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 573B312D0F3 for ; Wed, 1 Jun 2016 04:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaF3aAulwGxg for ; Wed, 1 Jun 2016 04:49:08 -0700 (PDT) Received: from inari-msr.crf.canon.fr (inari-msr.crf.canon.fr [194.2.158.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D58FC12D186 for ; Wed, 1 Jun 2016 04:49:07 -0700 (PDT) Received: from mir-msr.corp.crf.canon.fr (mir-msr.corp.crf.canon.fr [172.19.77.98]) by inari-msr.crf.canon.fr (8.13.8/8.13.8) with ESMTP id u51Bn5MQ006886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Jun 2016 13:49:05 +0200 Received: from Antiope.crf.canon.fr (antiope.fesl2.crf.canon.fr [172.19.70.56]) by mir-msr.corp.crf.canon.fr (8.13.8/8.13.8) with ESMTP id u51Bn3b8031458; Wed, 1 Jun 2016 13:49:03 +0200 Received: from Antiope.crf.canon.fr (172.19.70.62) by Antiope.crf.canon.fr (172.19.70.62) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 1 Jun 2016 13:49:03 +0200 Received: from Antiope.crf.canon.fr ([fe80::5c25:f890:ae73:d15a]) by Antiope.crf.canon.fr ([fe80::5c25:f890:ae73:d15a%12]) with mapi id 15.00.0995.032; Wed, 1 Jun 2016 13:49:03 +0200 From: RUELLAN Herve To: Peter Beverloo , Shida Schubert Thread-Topic: [Webpush] WGLC for draft-ietf-webpush-protocol-05 Thread-Index: AQHRr6Fj4mGDNkbLfEC8/cauecXCIZ+8PB2AgArigwCAAA3/gIABIeeAgAoQWICAAQl6AIABLuyA Date: Wed, 1 Jun 2016 11:49:02 +0000 Message-ID: <65b3ac726b70495db4bb0c2df33c19dc@Antiope.crf.canon.fr> References: <7BE6135D-961D-4D6E-B6FC-99BA27B1B0C4@ntt-at.com> <4B69453E-54AD-414A-BDC3-18E175AA25BC@ntt-at.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.5.242] Content-Type: multipart/alternative; boundary="_000_65b3ac726b70495db4bb0c2df33c19dcAntiopecrfcanonfr_" MIME-Version: 1.0 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] WGLC for draft-ietf-webpush-protocol-05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 11:49:11 -0000 --_000_65b3ac726b70495db4bb0c2df33c19dcAntiopecrfcanonfr_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbHNvIHNoYXJlZCBzb21lIGNvbW1lbnRzIGFuZCBzZW50IHNvbWUgcHVsbC1yZXF1ZXN0cy4g SSB0aGluayB0aGUgZHJhZnQgaXMgaW4gYSBwcmV0dHkgZ29vZCBzaGFwZSBhbmQgbm9uZSBvZiBt eSBjb21tZW50cyBvciBzdWdnZXN0aW9ucyBhcmUgYmxvY2tpbmcgZm9yIGl0cyBhZHZhbmNlbWVu dC4NCg0KVGhhbmtzLA0KDQpIZXJ2w6kNCg0KRnJvbTogV2VicHVzaCBbbWFpbHRvOndlYnB1c2gt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBldGVyIEJldmVybG9vDQpTZW50OiBtYXJk aSAzMSBtYWkgMjAxNiAyMTo0Mw0KVG86IFNoaWRhIFNjaHViZXJ0IDxzaGlkYUBudHQtYXQuY29t Pg0KQ2M6IHdlYnB1c2hAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbV2VicHVzaF0gV0dMQyBmb3Ig ZHJhZnQtaWV0Zi13ZWJwdXNoLXByb3RvY29sLTA1DQoNCkkgaGF2ZSBqdXN0IHNoYXJlZCBzb21l IGNvbW1lbnRzLCBidXQgbm9uZSBvZiB0aGVtIGFyZSBzaWduaWZpY2FudCBlbm91Z2ggdG8gZGVm ZXIgV0dMQy4NCg0KQXMgc3VjaCwgSSBjYW4gZGVmaW5pdGVseSBzdXBwb3J0IHRoZSBkcmFmdCBh cy1pcy4NCg0KVGhhbmtzLA0KUGV0ZXINCg0KT24gVHVlLCBNYXkgMzEsIDIwMTYgYXQgNDo1MiBB TSwgU2hpZGEgU2NodWJlcnQgPHNoaWRhQG50dC1hdC5jb208bWFpbHRvOnNoaWRhQG50dC1hdC5j b20+PiB3cm90ZToNCkFsbDsNCg0KV2UgaGF2ZSBoZWFyZCB2ZXJ5IGxpdHRsZSByZWdhcmRpbmcg dGhlIGFjdHVhbCBjb250ZW50cyBvZiB0aGUgZHJhZnQgYW5kIFdHTEMgaXMgb3ZlciB0aGlzIHdl ZWsuDQoNCkFzIG5vdGVkIHdoZW4gSSBzdGFydGVkIHRoZSBsYXN0IGNhbGwsIHBsZWFzZSBzaG93 IHlvdXIgc3VwcG9ydCBieSBwcm92aWRpbmcgYWNrbm93bGVkZ2VtZW50KHMpIGlmIHlvdSBhcmUg aGFwcHkgd2l0aCB0aGUgZHJhZnQgYXMgaXMuDQoNClRoYW5rcyENClNoaWRhDQoNCk9uIE1heSAy NCwgMjAxNiwgYXQgMTE6MTEgQU0sIENvc3RpbiBNYW5vbGFjaGUgPGNvc3RpbkBnbWFpbC5jb208 bWFpbHRvOmNvc3RpbkBnbWFpbC5jb20+PiB3cm90ZToNCg0KKzEgLSB3ZSBkaXNjdXNzZWQgbXkg Y29uY2VybnMgb24gZmxvdyBjb250cm9sIGZvciBwdXNoIHByb21pc2VzLCBhbmQgSSB0aGluayBp dCdzIHJlYXNvbmFibGUgdG8gaGF2ZSB0aGVtIGFkZHJlc3NlZCBlaXRoZXINCmFzIHBhcnQgb2Yg aHR0cDIgb3IgYXMgYSBzZXBhcmF0ZSBkb2N1bWVudC4NCg0KT3RoZXIgdGhhbiB0aGF0IEkgdGhp bmsgaXQncyByZWFzb25hYmxlIGFuZCBzdGFibGUgYmFzZSAtIGV4dGVuc2lvbnMgYW5kIGZlYXR1 cmVzIGNhbiBiZSBhZGRlZCBvbiB0b3Agb2YgaXQuDQoNCkNvc3Rpbg0KDQoNCk9uIE1vbiwgTWF5 IDIzLCAyMDE2IGF0IDU6NTMgUE0gUmljaGFyZCBNYWhlciA8bWFoZXJyakBnb29nbGVtYWlsLmNv bTxtYWlsdG86bWFoZXJyakBnb29nbGVtYWlsLmNvbT4+IHdyb3RlOg0KUGxlYXNlIHNlZSBlbWJl ZGRlZCBjb21tZW50czogLQ0KDQpPbiBUdWUsIE1heSAyNCwgMjAxNiBhdCA4OjAzIEFNLCBTaGlk YSBTY2h1YmVydCA8c2hpZGFAbnR0LWF0LmNvbTxtYWlsdG86c2hpZGFAbnR0LWF0LmNvbT4+IHdy b3RlOg0KDQpIaSBSaWNoYXJkOw0KDQpUaGFuayB5b3UgZm9yIHlvdXIgZmVlZGJhY2suDQoNCkN1 cnJlbnRseSBkZXZlbG9wZXJzIG5lZWQgdG8gZWl0aGVyIGRlYWwgd2l0aCBkaWZmZXJlbnQgc3Bl Yy9hcGkgZm9yIGVhY2ggb2YgdGhlIHB1c2ggbm90aWZpY2F0aW9uIHByb3ZpZGVycyAoR0NNLCBB enVyZSwgQVBOIGV0Yy4pIHRvIGNvbW11bmljYXRlIHRvIHRoZWlyIHN1YnNjcmliZXJzIG9yIHVz ZSB0aGlyZCBwYXJ0eSBzZXJ2aWNlICh1cmJhbiBhaXJzaGlwIGV0Yy4pLCB3aGljaCBpcyBmaW5l IGZvciBuYXRpdmUgYXBwcyBidXQgZ2V0cyBhIGxpdHRsZSBtb3JlIGNvbXBsaWNhdGVkIHdpdGgg dGhlIGJyb3dzZXIuDQoNCkluY29udmVuaWVudCBidXQgZmVhdHVyZSBkZXRlY3Rpb24gaXMgbm90 IHRoZSBlbmQgb2YgdGhlIHdvcmxkLg0KDQpUaGUgSUVURiBoYXMgYWdyZWVkIHRoYXQgd2UgbmVl ZCBhIHN0YW5kYXJkaXplZCBwcm90b2NvbCBmb3IgdGhpcyBhbmQgdGhhdOKAmXMgd2hhdCB3ZSBh cmUgY2hhcnRlcmVkIHRvIHdvcmsgb24uDQoNCkEgbXVjaCBiZXR0ZXIgaWRlYSBlc3BlY2lhbGx5 IGNvbnNpZGVyaW5nIHRoZSBudW1iZXIgb2YgUHVzaCBTZXJ2aWNlcyB0aGF0IGRvbid0IGhhcHBl biB0byBhbHNvIG1hbnVmYWN0dXJlIGEgYnJvd3Nlci4gQnV0IGxldCdzIGdldCBpdCBhcyBmaXQt Zm9yLXB1cnBvc2UgYW5kIGFzIGV4dGVuc2l2ZSBhcyB3ZSBjYW4sIGVoPyBIb3cgbWFueSBkaWZm ZXJlbnQgc3BlY2lmaWNhdGlvbnMgaGF2ZSB0aGVyZSBiZWVuIHNvIGZhciBkZWFsaW5nIHdpdGgg U2VydmVyIFB1c2gsIFNpbXBsZSBQdXNoLCBldGMuIEVhY2ggdGltZSB3aXRoIGRldmVsb3BlcnMg aGF2aW5nIHRvIGRlcHJlY2F0ZSBhbmQgcmUtdG9vbCA6LSgNCg0KDQpBcyBmb3IgQnJvYWRjYXN0 aW5nLCBmcm9tIG15IHNoYWxsb3cgdW5kZXJzdGFuZGluZyBpc27igJl0IGl0IG1lcmVseSB0aGUg c2FtZSBwYXlsb2FkIHNlbnQgdG8gc2V0IG9yIGFsbCBvZiBzdWJzY3JpYmVycz8NCg0KSSBmaW5k IHRoYXQgbGV2ZWwgb2YgbmFpdmV0eSBhc3RvdW5kaW5nIGluIGFueW9uZSB3aG8gaXMgaW52b2x2 ZWQgaW4gZm9ybXVsYXRpb24gb2YgdGhpcyBzdGFuZGFyZC4gV2h5IGRvIHlvdSBzZWVrIHRvIGRl bGliZXJhdGVseSBpZ25vcmUgdGhlIGNsaWVudC1iYXNlZCBzdWJzY3JpcHRpb24gZmVhdHVyZSB3 aGVyZSBhbnkgYW5kIGFsbCBjbGllbnQtdG8tdG9waWMgbWFwcGluZyBpcyBtYWludGFpbmVkIHNv bGVseSBieSB0aGUgUHVzaCBTZXJ2aWNlIGFuZCB3aGVyZSB0aGUgQXBwbGljYXRpb24gU2VydmVy IGlzIG9ibGl2aW91cyB0byBjb25zdW1lcnMgYW5kIGZyZWVkIHRoZSBuZWVkIGZvciBhIGxvY2Fs IG1hcHBpbmcgZGF0YWJhc2U/IFRoZSBVc2UtQ2FzZXMgYXJlIGNsZWFyOiAtIFNwb3J0cyByZXN1 bHRzLCBXZWF0aGVyIFVwZGF0ZXMsIFN0b2NrIFByaWNlcywgU2VjdXJpdHkgQWxlcnRzLCBqdXN0 IHRvIG5hbWUgYSBmZXcuIFRoZSBzdHJhdGVneSBmb3IgZW5jcnlwdGluZyBhbiBhdXRoZW50aWNh dGluZyB0aGUgcGF5bG9hZC9ib2R5IGlzIGFsc28gY2xlYXIoaXNoKTogLSBodHRwczovL2dpdGh1 Yi5jb20vc2xpZ2h0bHlvZmYvU2VydmljZVdvcmtlci9pc3N1ZXMvOTAxDQoNCldoeSBkbyB5b3Ug cGVvcGxlIGNvbnRpbnVlIHRvIHNheSAiV2hhdCBlbGVwaGFudD8iDQoNCkluIHdoaWNoIGNhc2Us IEkgYmVsaWV2ZSBpdCBjYW4gYmUgaGFuZGxlZCBhcyBhbiBpbXBsZW1lbnRhdGlvbiBtYXR0ZXIg bGlrZWx5IGF0IHRoZSBhcHBsaWNhdGlvbiBzaWRlLg0KDQogRm9yIHNvbWUgb3RoZXIgdXNlIGNh c2VzLCBtYW5hZ2luZyBzdWJzY3JpcHRpb25zIG9uIHRoZSBzZXJ2ZXIgaXMgaW5kZWVkIGFuIG9w dGlvbi4gSG9yc2VzIGZvciBjb3Vyc2VzOiAtDQogaHR0cHM6Ly9kZXZlbG9wZXJzLmdvb2dsZS5j b20vY2xvdWQtbWVzc2FnaW5nL3RvcGljLW1lc3NhZ2luZyNtYW5hZ2luZ190b3BpY19zdWJzY3Jp cHRpb25zX2Zyb21fdGhlX3NlcnZlcg0KDQpUaGUgcHJvdG9jb2wgY2FuIGJlIGV4dGVuZGVkIGF0 IGxhdGVyIHN0YWdlIGlmIHdnIGFncmVlcyBpdCBpcyBzb21ldGhpbmcgdGhhdCBpcyBuZWNlc3Nh cnkgYnV0IEkgaGF2ZW7igJl0IGhlYXJkIGFueWJvZHkgZWxzZSBhdCB0aGUgbWVldGluZyBvciBv biB0aGUgbWFpbGluZyBsaXN0IGV4cHJlc3NpbmcgdGhpcyBmZWF0dXJlIGlzIGEgc2hvdy1zdG9w cGVyLg0KDQpJIHNvcnJ5IHRvIGFwcGVhciBibHVudCBidXQgaWYgdGhlIG90aGVyIG1lbWJlcnMg b2YgdGhlIGNsb2lzdGVyZWQgc3RhciBjaGFtYmVyIHRoYXQgaXMgYWRqdWRpY2F0aW5nIG9uIHRo aXMgYXJlIGVxdWFsbHkgaWdub3JhbnQgb2YgdGhlIGJ1c2luZXNzIHJlcXVpcmVtZW50cyB0aGVu IHRoZXJlIGlzIG5vIHN1cnByaXNlIHRoZXkgaGF2ZW4ndCBjb21lIHVwIHdpdGggYSBzb2x1dGlv bi4NCg0KQnV0ICpwbGVhc2UqIGRvbid0IGxpc3RlbiB0byBtZS4gSnVzdCBsb29rIGF0IHdoYXQg c29sdXRpb25zIHRoYXQgYXJlIGFscmVhZHkgaW4gdGhlIHdpbGQgd2l0aCBuYXRpdmUgYXBwcy4g V2h5IHdvbid0IHlvdSBsZXQgSFRNTDUgV2ViIEFwcCBkZXZlbG9wZXJzIGNvbXBldGUgb24gYW4g ZXZlbiBwbGF5aW5nIGZpZWxkIGFuZCBjcmVhdGUgQXBwcyB0aGF0IHNhdGlzZnkgdGhlc2UgY29t bW9uIHJlcXVpcmVtZW50cz8NCg0KVGhlIE1CT05FIHBlb3BsZSBzZWVtIHRvIGhhdmUgbWFkZSBw cm9ncmVzcyBvdmVyIHRoZSB5ZWFycyBhbmQgd2UgYWxsIGtub3cgdGhhdCB5b3VyIEFwcGxpY2F0 aW9uIFNlcnZlcnMgd2l0aCBzaW1wbHkgYmUgb3ZlcndoZWxtZWQgaWYgeW91IHRpY2tsZSBwb3Rl bnRpYWxseSBtaWxsaW9ucyBvZiBjbGllbnRzIHNvIGxldCdzIGdldCBvbiB3aXRoIHRoZSBzb2x1 dGlvbj8NCg0KDQpBbnl3YXksIEkgd291bGQgdmVyeSBtdWNoIGFwcHJlY2lhdGUgaXQsIGlmIHlv dSBjYW4gcmVmcmFpbiB0aGUgY29tbWVudHMgdG8gdGhlIHRlY2huaWNhbCBjb250ZW50cyBvZiB0 aGUgZHJhZnQuDQoNCkFyZSB5b3UgdGVsbGluZyBtZSB0aGF0IHBvaW50aW5nIG91dCBvbWlzc2lv bnMgYW5kIHNjb3BlIGRlZmljaWVuY2llcyBpcyBub3Qgd2VsY29tZWQ/DQoNCkVpdGhlciB3YXkg NS40IGlzIGNvbXBsZXRlbHkgd3JvbmcuIFlvdSd2ZSBiZWVuIHRvbGQuDQoNCg0KVGhhbmtzDQpT aGlkYQ0KDQpPbiBNYXkgMTYsIDIwMTYsIGF0IDY6NTAgUE0sIFJpY2hhcmQgTWFoZXIgPG1haGVy cmpAZ29vZ2xlbWFpbC5jb208bWFpbHRvOm1haGVycmpAZ29vZ2xlbWFpbC5jb20+PiB3cm90ZToN Cg0KIjUuNCBVcGRhdGluZyBQdXNoIE1lc3NhZ2VzIiBpcyBiYXNlZCBvbiB0aGUgbWlzY29uY2Vw dGlvbiB0aGF0ICJUb3BpY3MiIGFyZSAiQ29sbGFwc2UgS2V5cyIuIFRoZSBzdGFuZGFyZCBhcyBw cm9wb3NlZCBoYXMgYmVlbiBzdXBlcnNlZGVkIGJ5IGV2ZW50IG9uIHRoZSBncm91bmQgYnkgZXN0 YWJsaXNoZWQsIHN1Y2Nlc3NmdWwsIGFuZCBtb3JlIGltcG9ydGFudGx5IHNjYWxhYmxlIHNvbHV0 aW9uczogLQ0KDQpHb29nbGUgQ2xvdWQgTWVzc2FnaW5nOiAtDQpodHRwczovL2RldmVsb3BlcnMu Z29vZ2xlLmNvbS9jbG91ZC1tZXNzYWdpbmcvdG9waWMtbWVzc2FnaW5nDQoNCkF6dXJlIE5vdGlm aWNhdGlvbiBIdWJzOiAtDQogaHR0cHM6Ly9ibG9ncy53aW5kb3dzLmNvbS9idWlsZGluZ2FwcHMv MjAxMy8wOS8xNi9kZWxpdmVyaW5nLXB1c2gtbm90aWZpY2F0aW9ucy10by1taWxsaW9ucy1vZi1k ZXZpY2VzLXdpdGgtd2luZG93cy1henVyZS1ub3RpZmljYXRpb24taHVicy8NCg0KV2hldGhlciB0 aGUgVG9waWNzIGFyZSBpZGVudGlmaWVkIHZpYSBIVFRQIGhlYWRlcnMgb3IgSlNPTiBUb2tlbnMg aXMgdGhlIG9ubHkgbW9vdCBwb2ludC4gV2hhdCBpcyBjbGVhciBpcyB0aGF0IHRoZSBwcm9wb3Nl ZCBwcm90b2NvbCBhdHRlbXB0cyB0byBjb25mbGF0ZSB0aGUgVG9waWMgYW5kIENvbGxhcHNlIEtl eSBmZWF0dXJlczogLQ0KaHR0cHM6Ly9kZXZlbG9wZXJzLmdvb2dsZS5jb20vY2xvdWQtbWVzc2Fn aW5nL2NvbmNlcHQtb3B0aW9ucyNjb2xsYXBzaWJsZV9hbmRfbm9uLWNvbGxhcHNpYmxlX21lc3Nh Z2VzDQoNClRoZSBmYWN0IHRoYXQgcXVpbnRlc3NlbnRpYWwgUHVzaCBOb3RpZmljYXRpb24gZmVh dHVyZSAiQnJvYWRjYXN0aW5nIiBoYXMgYmVlbiBkZXNjb3BlZCBmcm9tIHRoaXMgcHJvdG9jb2wg bXVzdCBiZSBzdWZmaWNpZW50IHRvIHJlamVjdCB0aGUgcHJvcG9zYWwuDQoNClBsZWFzZSBkbyBu b3QgbWFrZSB0aGUgc2FtZSBtaXN0YWtlIHRoYXQgeW91IG1hZGUgd2l0aCBHZW9mZW5jZXMuIElF VEYgYW5kIFczQyBjcmVkaWJpbGl0eSBoYXMgYWxyZWFkeSBzdWZmZXJlZCBlbm91Z2guDQoNCk9u IFR1ZSwgTWF5IDE3LCAyMDE2IGF0IDI6MzIgQU0sIFNoaWRhIFNjaHViZXJ0IDxzaGlkYUBudHQt YXQuY29tPG1haWx0bzpzaGlkYUBudHQtYXQuY29tPj4gd3JvdGU6DQpBbGw7DQoNCkFzIGRpc2N1 c3NlZCBhdCB0aGUgSUVURiA5NSwgYXMgbGFzdCBpc3N1ZSBzdXJyb3VuZGluZyB0aGUgc3Vic2Ny aXB0aW9uIHJlLXVzZSBpcyBhZGRyZXNzZWQsIHdlIGFyZSBzdGFydGluZyBhIFdvcmtpbmcgR3Jv dXAgTGFzdCBDYWxsIGZvciB0aGUgd2VicHVzaCBwcm90b2NvbC4NCg0KaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtd2VicHVzaC1wcm90b2NvbC0wNQ0KDQpJZiB5b3UgaGF2 ZSBhbnkgaXNzdWVzIG9yIHF1ZXN0aW9ucyByZWdhcmRpbmcgdGhlIGRyYWZ0IHBsZWFzZSBzdWJt aXQgaXQgdG8gdGhlIGxpc3QsIHdoZW4gcmFpc2luZyBpc3N1ZXMgcGxlYXNlIHByb3ZpZGUgY29u c3RydWN0aXZlIHJlc29sdXRpb24gd2hlbiBwb3NzaWJsZS4NCg0KUGxlYXNlIGFja25vd2xlZGdl IG9uIHRoZSBsaXN0IGV2ZW4gd2hlbiB5b3UgYXJlIGNvbnRlbnQvaGFwcHkgd2l0aCB0aGUgc3Rh dHVzIG9mIHRoZSBkcmFmdC4NCg0KVGhlIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIHdpbGwgZW5k IG9uIEp1bmUgNnRoICgzIHdlZWtzKS4NCg0KU2hpZGENCkFzIGNvLWNoYWlyDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpXZWJwdXNoIG1haWxpbmcg bGlzdA0KV2VicHVzaEBpZXRmLm9yZzxtYWlsdG86V2VicHVzaEBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vd2VicHVzaA0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KV2VicHVzaCBtYWlsaW5nIGxpc3QNCldl YnB1c2hAaWV0Zi5vcmc8bWFpbHRvOldlYnB1c2hAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3dlYnB1c2gNCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KV2VicHVzaCBtYWlsaW5nIGxpc3QNCldlYnB1c2hA aWV0Zi5vcmc8bWFpbHRvOldlYnB1c2hAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3dlYnB1c2gNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpXZWJwdXNoIG1haWxpbmcgbGlzdA0KV2VicHVzaEBpZXRmLm9yZzxt YWlsdG86V2VicHVzaEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vd2VicHVzaA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCldlYnB1c2ggbWFpbGluZyBsaXN0DQpXZWJwdXNoQGlldGYub3JnPG1haWx0bzpXZWJw dXNoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby93ZWJw dXNoDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CldlYnB1c2ggbWFpbGluZyBsaXN0DQpXZWJwdXNoQGlldGYub3JnPG1haWx0bzpXZWJwdXNoQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby93ZWJwdXNoDQoN Cg== --_000_65b3ac726b70495db4bb0c2df33c19dcAntiopecrfcanonfr_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmhvZW56Yg0KCXttc28t c3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44 NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgYWxzbyBzaGFyZWQgc29tZSBjb21tZW50cyBhbmQg c2VudCBzb21lIHB1bGwtcmVxdWVzdHMuIEkgdGhpbmsgdGhlIGRyYWZ0IGlzIGluIGEgcHJldHR5 IGdvb2Qgc2hhcGUgYW5kIG5vbmUgb2YgbXkgY29tbWVudHMgb3Igc3VnZ2VzdGlvbnMgYXJlIGJs b2NraW5nIGZvciBpdHMNCiBhZHZhbmNlbWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPkhlcnbDqTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFdlYnB1c2ggW21haWx0bzp3ZWJwdXNoLWJvdW5j ZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlBldGVyIEJldmVybG9vPGJyPg0KPGI+ U2VudDo8L2I+IG1hcmRpIDMxIG1haSAyMDE2IDIxOjQzPGJyPg0KPGI+VG86PC9iPiBTaGlkYSBT Y2h1YmVydCAmbHQ7c2hpZGFAbnR0LWF0LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IHdlYnB1c2hA aWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtXZWJwdXNoXSBXR0xDIGZvciBkcmFm dC1pZXRmLXdlYnB1c2gtcHJvdG9jb2wtMDU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZlIGp1c3Qgc2hhcmVkIHNvbWUgY29tbWVudHMs IGJ1dCBub25lIG9mIHRoZW0gYXJlIHNpZ25pZmljYW50IGVub3VnaCB0byBkZWZlciBXR0xDLjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgc3VjaCwgSSBj YW4gZGVmaW5pdGVseSBzdXBwb3J0IHRoZSBkcmFmdCBhcy1pcy48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGV0ZXI8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBNYXkgMzEsIDIwMTYgYXQg NDo1MiBBTSwgU2hpZGEgU2NodWJlcnQgJmx0OzxhIGhyZWY9Im1haWx0bzpzaGlkYUBudHQtYXQu Y29tIiB0YXJnZXQ9Il9ibGFuayI+c2hpZGFAbnR0LWF0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QWxsOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5XZSBoYXZlIGhlYXJkIHZlcnkgbGl0dGxlIHJlZ2FyZGluZyB0aGUgYWN0dWFsIGNvbnRl bnRzIG9mIHRoZSBkcmFmdCBhbmQgV0dMQyBpcyBvdmVyIHRoaXMgd2Vlay48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgbm90ZWQgd2hlbiBJ IHN0YXJ0ZWQgdGhlIGxhc3QgY2FsbCwgcGxlYXNlIHNob3cgeW91ciBzdXBwb3J0IGJ5IHByb3Zp ZGluZyBhY2tub3dsZWRnZW1lbnQocykgaWYgeW91IGFyZSBoYXBweSB3aXRoIHRoZSBkcmFmdCBh cyBpcy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhhbmtzISZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPlNoaWRhPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIE1heSAyNCwgMjAxNiwgYXQgMTE6MTEgQU0sIENvc3RpbiBNYW5vbGFjaGUgJmx0 OzxhIGhyZWY9Im1haWx0bzpjb3N0aW5AZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+Y29zdGlu QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+JiM0MzsxIC0gd2UgZGlzY3Vzc2VkIG15IGNvbmNlcm5zIG9uIGZsb3cg Y29udHJvbCBmb3IgcHVzaCBwcm9taXNlcywgYW5kIEkgdGhpbmsgaXQncyByZWFzb25hYmxlIHRv IGhhdmUgdGhlbSBhZGRyZXNzZWQgZWl0aGVyJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+YXMgcGFydCBvZiBodHRwMiBvciBhcyBhIHNlcGFyYXRlIGRv Y3VtZW50LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PdGhlciB0aGFuIHRoYXQgSSB0aGluayBpdCdzIHJlYXNvbmFibGUgYW5kIHN0 YWJsZSBiYXNlIC0gZXh0ZW5zaW9ucyBhbmQgZmVhdHVyZXMgY2FuIGJlIGFkZGVkIG9uIHRvcCBv ZiBpdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Q29zdGluPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gTW9uLCBNYXkgMjMsIDIwMTYgYXQgNTo1MyBQTSBSaWNoYXJkIE1haGVyICZs dDs8YSBocmVmPSJtYWlsdG86bWFoZXJyakBnb29nbGVtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi Pm1haGVycmpAZ29vZ2xlbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QbGVhc2Ugc2Vl IGVtYmVkZGVkIGNvbW1lbnRzOiAtPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBNYXkgMjQsIDIwMTYgYXQg ODowMyBBTSwgU2hpZGEgU2NodWJlcnQgJmx0OzxhIGhyZWY9Im1haWx0bzpzaGlkYUBudHQtYXQu Y29tIiB0YXJnZXQ9Il9ibGFuayI+c2hpZGFAbnR0LWF0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5IaSBSaWNoYXJkOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGFuayB5b3UgZm9yIHlvdXIgZmVlZGJhY2suPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkN1cnJlbnRseSBkZXZlbG9w ZXJzIG5lZWQgdG8gZWl0aGVyIGRlYWwgd2l0aCBkaWZmZXJlbnQgc3BlYy9hcGkgZm9yIGVhY2gg b2YgdGhlIHB1c2ggbm90aWZpY2F0aW9uIHByb3ZpZGVycyAoR0NNLCBBenVyZSwgQVBOIGV0Yy4p IHRvIGNvbW11bmljYXRlIHRvIHRoZWlyIHN1YnNjcmliZXJzIG9yIHVzZSB0aGlyZCBwYXJ0eSBz ZXJ2aWNlICh1cmJhbiBhaXJzaGlwIGV0Yy4pLCB3aGljaCBpcyBmaW5lIGZvciBuYXRpdmUNCiBh cHBzIGJ1dCBnZXRzIGEgbGl0dGxlIG1vcmUgY29tcGxpY2F0ZWQgd2l0aCB0aGUgYnJvd3Nlci4g PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SW5jb252ZW5pZW50IGJ1dCBmZWF0dXJlIGRldGVjdGlvbiBpcyBub3QgdGhlIGVu ZCBvZiB0aGUgd29ybGQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIElFVEYgaGFzIGFncmVlZCB0aGF0IHdlIG5lZWQgYSBz dGFuZGFyZGl6ZWQgcHJvdG9jb2wgZm9yIHRoaXMgYW5kIHRoYXTigJlzIHdoYXQgd2UgYXJlIGNo YXJ0ZXJlZCB0byB3b3JrIG9uLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEgbXVjaCBiZXR0ZXIgaWRlYSBlc3Bl Y2lhbGx5IGNvbnNpZGVyaW5nIHRoZSBudW1iZXIgb2YgUHVzaCBTZXJ2aWNlcyB0aGF0IGRvbid0 IGhhcHBlbiB0byBhbHNvIG1hbnVmYWN0dXJlIGEgYnJvd3Nlci4gQnV0IGxldCdzIGdldCBpdCBh cyBmaXQtZm9yLXB1cnBvc2UgYW5kIGFzIGV4dGVuc2l2ZSBhcyB3ZSBjYW4sIGVoPyBIb3cgbWFu eSBkaWZmZXJlbnQgc3BlY2lmaWNhdGlvbnMgaGF2ZSB0aGVyZSBiZWVuDQogc28gZmFyIGRlYWxp bmcgd2l0aCBTZXJ2ZXIgUHVzaCwgU2ltcGxlIFB1c2gsIGV0Yy4gRWFjaCB0aW1lIHdpdGggZGV2 ZWxvcGVycyBoYXZpbmcgdG8gZGVwcmVjYXRlIGFuZCByZS10b29sIDotKDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgZm9y IEJyb2FkY2FzdGluZywgZnJvbSBteSBzaGFsbG93IHVuZGVyc3RhbmRpbmcgaXNu4oCZdCBpdCBt ZXJlbHkgdGhlIHNhbWUgcGF5bG9hZCBzZW50IHRvIHNldCBvciBhbGwgb2Ygc3Vic2NyaWJlcnM/ DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JIGZpbmQgdGhhdCBsZXZlbCBvZiBuYWl2ZXR5IGFzdG91bmRpbmcgaW4gYW55 b25lIHdobyBpcyBpbnZvbHZlZCBpbiBmb3JtdWxhdGlvbiBvZiB0aGlzIHN0YW5kYXJkLiBXaHkg ZG8geW91IHNlZWsgdG8gZGVsaWJlcmF0ZWx5IGlnbm9yZSB0aGUgY2xpZW50LWJhc2VkIHN1YnNj cmlwdGlvbiBmZWF0dXJlIHdoZXJlIGFueSBhbmQgYWxsIGNsaWVudC10by10b3BpYyBtYXBwaW5n IGlzIG1haW50YWluZWQgc29sZWx5DQogYnkgdGhlIFB1c2ggU2VydmljZSBhbmQgd2hlcmUgdGhl IEFwcGxpY2F0aW9uIFNlcnZlciBpcyBvYmxpdmlvdXMgdG8gY29uc3VtZXJzIGFuZCBmcmVlZCB0 aGUgbmVlZCBmb3IgYSBsb2NhbCBtYXBwaW5nIGRhdGFiYXNlPyBUaGUgVXNlLUNhc2VzIGFyZSBj bGVhcjogLSBTcG9ydHMgcmVzdWx0cywgV2VhdGhlciBVcGRhdGVzLCBTdG9jayBQcmljZXMsIFNl Y3VyaXR5IEFsZXJ0cywganVzdCB0byBuYW1lIGEgZmV3LiBUaGUgc3RyYXRlZ3kgZm9yDQogZW5j cnlwdGluZyBhbiBhdXRoZW50aWNhdGluZyB0aGUgcGF5bG9hZC9ib2R5IGlzIGFsc28gY2xlYXIo aXNoKTogLSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9zbGlnaHRseW9mZi9TZXJ2 aWNlV29ya2VyL2lzc3Vlcy85MDEiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2dpdGh1Yi5jb20v c2xpZ2h0bHlvZmYvU2VydmljZVdvcmtlci9pc3N1ZXMvOTAxPC9hPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaHkgZG8geW91IHBlb3BsZSBj b250aW51ZSB0byBzYXkgJnF1b3Q7V2hhdCBlbGVwaGFudD8mcXVvdDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB3aGljaCBj YXNlLCBJIGJlbGlldmUgaXQgY2FuIGJlIGhhbmRsZWQgYXMgYW4gaW1wbGVtZW50YXRpb24gbWF0 dGVyIGxpa2VseSBhdCB0aGUgYXBwbGljYXRpb24gc2lkZS4NCjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO0ZvciBz b21lIG90aGVyIHVzZSBjYXNlcywgbWFuYWdpbmcgc3Vic2NyaXB0aW9ucyBvbiB0aGUgc2VydmVy IGlzIGluZGVlZCBhbiBvcHRpb24uIEhvcnNlcyBmb3IgY291cnNlczogLTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjVwdCI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vZGV2ZWxvcGVycy5nb29n bGUuY29tL2Nsb3VkLW1lc3NhZ2luZy90b3BpYy1tZXNzYWdpbmcjbWFuYWdpbmdfdG9waWNfc3Vi c2NyaXB0aW9uc19mcm9tX3RoZV9zZXJ2ZXIiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuNXB0Ij5odHRwczovL2RldmVsb3BlcnMuZ29vZ2xlLmNvbS9jbG91ZC1tZXNz YWdpbmcvdG9waWMtbWVzc2FnaW5nI21hbmFnaW5nX3RvcGljX3N1YnNjcmlwdGlvbnNfZnJvbV90 aGVfc2VydmVyPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhlIHByb3RvY29sIGNhbiBiZSBleHRlbmRlZCBhdCBsYXRlciBzdGFnZSBp ZiB3ZyBhZ3JlZXMgaXQgaXMgc29tZXRoaW5nIHRoYXQgaXMgbmVjZXNzYXJ5IGJ1dCBJIGhhdmVu 4oCZdCBoZWFyZCBhbnlib2R5IGVsc2UgYXQgdGhlIG1lZXRpbmcgb3Igb24gdGhlIG1haWxpbmcg bGlzdCBleHByZXNzaW5nIHRoaXMgZmVhdHVyZSBpcyBhIHNob3ctc3RvcHBlci4gJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SSBzb3JyeSB0byBhcHBlYXIgYmx1bnQgYnV0IGlmIHRoZSBvdGhlciBtZW1iZXJzIG9m IHRoZSBjbG9pc3RlcmVkIHN0YXIgY2hhbWJlciB0aGF0IGlzIGFkanVkaWNhdGluZyBvbiB0aGlz IGFyZSBlcXVhbGx5IGlnbm9yYW50IG9mIHRoZSBidXNpbmVzcyByZXF1aXJlbWVudHMgdGhlbiB0 aGVyZSBpcyBubyBzdXJwcmlzZSB0aGV5IGhhdmVuJ3QgY29tZSB1cCB3aXRoIGEgc29sdXRpb24u PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ1 dCAqcGxlYXNlKiBkb24ndCBsaXN0ZW4gdG8gbWUuIEp1c3QgbG9vayBhdCB3aGF0IHNvbHV0aW9u cyB0aGF0IGFyZSBhbHJlYWR5IGluIHRoZSB3aWxkIHdpdGggbmF0aXZlIGFwcHMuIFdoeSB3b24n dCB5b3UgbGV0IEhUTUw1IFdlYiBBcHAgZGV2ZWxvcGVycyBjb21wZXRlIG9uIGFuIGV2ZW4gcGxh eWluZyBmaWVsZCBhbmQgY3JlYXRlIEFwcHMgdGhhdCBzYXRpc2Z5IHRoZXNlIGNvbW1vbiByZXF1 aXJlbWVudHM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoZSBNQk9ORSBwZW9wbGUgc2VlbSB0byBoYXZlIG1hZGUgcHJvZ3Jlc3Mgb3ZlciB0 aGUgeWVhcnMgYW5kIHdlIGFsbCBrbm93IHRoYXQgeW91ciBBcHBsaWNhdGlvbiBTZXJ2ZXJzIHdp dGggc2ltcGx5IGJlIG92ZXJ3aGVsbWVkIGlmIHlvdSB0aWNrbGUgcG90ZW50aWFsbHkgbWlsbGlv bnMgb2YgY2xpZW50cyBzbyBsZXQncyBnZXQgb24gd2l0aCB0aGUgc29sdXRpb24/Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Bbnl3YXksIEkgd291bGQgdmVyeSBtdWNoIGFwcHJlY2lhdGUgaXQsIGlmIHlvdSBjYW4g cmVmcmFpbiB0aGUgY29tbWVudHMgdG8gdGhlIHRlY2huaWNhbCBjb250ZW50cyBvZiB0aGUgZHJh ZnQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+QXJlIHlvdSB0ZWxsaW5nIG1lIHRoYXQgcG9pbnRpbmcgb3V0IG9t aXNzaW9ucyBhbmQgc2NvcGUgZGVmaWNpZW5jaWVzIGlzIG5vdCB3ZWxjb21lZD88bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RWl0aGVyIHdheSA1 LjQgaXMgY29tcGxldGVseSB3cm9uZy4gWW91J3ZlIGJlZW4gdG9sZC48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo YW5rczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPlNoaWRhPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1heSAxNiwg MjAxNiwgYXQgNjo1MCBQTSwgUmljaGFyZCBNYWhlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1haGVy cmpAZ29vZ2xlbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWhlcnJqQGdvb2dsZW1haWwuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mcXVvdDs1LjQgVXBkYXRpbmcgUHVzaCBNZXNzYWdlcyZxdW90OyBpcyBiYXNlZCBvbiB0 aGUgbWlzY29uY2VwdGlvbiB0aGF0ICZxdW90O1RvcGljcyZxdW90OyBhcmUgJnF1b3Q7Q29sbGFw c2UgS2V5cyZxdW90Oy4gVGhlIHN0YW5kYXJkIGFzIHByb3Bvc2VkIGhhcyBiZWVuIHN1cGVyc2Vk ZWQgYnkgZXZlbnQgb24gdGhlIGdyb3VuZCBieSBlc3RhYmxpc2hlZCwgc3VjY2Vzc2Z1bCwgYW5k IG1vcmUgaW1wb3J0YW50bHkgc2NhbGFibGUgc29sdXRpb25zOiAtPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Hb29nbGUgQ2xvdWQgTWVzc2FnaW5nOiAtPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVm PSJodHRwczovL2RldmVsb3BlcnMuZ29vZ2xlLmNvbS9jbG91ZC1tZXNzYWdpbmcvdG9waWMtbWVz c2FnaW5nIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kZXZlbG9wZXJzLmdvb2dsZS5jb20vY2xv dWQtbWVzc2FnaW5nL3RvcGljLW1lc3NhZ2luZzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXp1cmUgTm90aWZpY2F0aW9uIEh1YnM6IC08 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxhIGhyZWY9Imh0dHBzOi8vYmxvZ3Mud2luZG93cy5jb20vYnVpbGRpbmdhcHBzLzIwMTMvMDkv MTYvZGVsaXZlcmluZy1wdXNoLW5vdGlmaWNhdGlvbnMtdG8tbWlsbGlvbnMtb2YtZGV2aWNlcy13 aXRoLXdpbmRvd3MtYXp1cmUtbm90aWZpY2F0aW9uLWh1YnMvIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly9ibG9ncy53aW5kb3dzLmNvbS9idWlsZGluZ2FwcHMvMjAxMy8wOS8xNi9kZWxpdmVyaW5n LXB1c2gtbm90aWZpY2F0aW9ucy10by1taWxsaW9ucy1vZi1kZXZpY2VzLXdpdGgtd2luZG93cy1h enVyZS1ub3RpZmljYXRpb24taHVicy88L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoZXRoZXIgdGhlIFRvcGljcyBhcmUgaWRlbnRpZmll ZCB2aWEgSFRUUCBoZWFkZXJzIG9yIEpTT04gVG9rZW5zIGlzIHRoZSBvbmx5IG1vb3QgcG9pbnQu IFdoYXQgaXMgY2xlYXIgaXMgdGhhdCB0aGUgcHJvcG9zZWQgcHJvdG9jb2wgYXR0ZW1wdHMgdG8g Y29uZmxhdGUgdGhlIFRvcGljIGFuZCBDb2xsYXBzZSBLZXkgZmVhdHVyZXM6IC08bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBz Oi8vZGV2ZWxvcGVycy5nb29nbGUuY29tL2Nsb3VkLW1lc3NhZ2luZy9jb25jZXB0LW9wdGlvbnMj Y29sbGFwc2libGVfYW5kX25vbi1jb2xsYXBzaWJsZV9tZXNzYWdlcyIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vZGV2ZWxvcGVycy5nb29nbGUuY29tL2Nsb3VkLW1lc3NhZ2luZy9jb25jZXB0LW9w dGlvbnMjY29sbGFwc2libGVfYW5kX25vbi1jb2xsYXBzaWJsZV9tZXNzYWdlczwvYT48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGZhY3Qg dGhhdCBxdWludGVzc2VudGlhbCBQdXNoIE5vdGlmaWNhdGlvbiBmZWF0dXJlICZxdW90O0Jyb2Fk Y2FzdGluZyZxdW90OyBoYXMgYmVlbiBkZXNjb3BlZCBmcm9tIHRoaXMgcHJvdG9jb2wgbXVzdCBi ZSBzdWZmaWNpZW50IHRvIHJlamVjdCB0aGUgcHJvcG9zYWwuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSBkbyBub3QgbWFrZSB0aGUg c2FtZSBtaXN0YWtlIHRoYXQgeW91IG1hZGUgd2l0aCBHZW9mZW5jZXMuIElFVEYgYW5kIFczQyBj cmVkaWJpbGl0eSBoYXMgYWxyZWFkeSBzdWZmZXJlZCBlbm91Z2guPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgTWF5IDE3LCAyMDE2 IGF0IDI6MzIgQU0sIFNoaWRhIFNjaHViZXJ0ICZsdDs8YSBocmVmPSJtYWlsdG86c2hpZGFAbnR0 LWF0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNoaWRhQG50dC1hdC5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkFsbDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+QXMgZGlzY3Vzc2VkIGF0IHRoZSBJRVRGIDk1LCBhcyBsYXN0IGlzc3VlIHN1cnJv dW5kaW5nIHRoZSBzdWJzY3JpcHRpb24gcmUtdXNlIGlzIGFkZHJlc3NlZCwgd2UgYXJlIHN0YXJ0 aW5nIGEgV29ya2luZyBHcm91cCBMYXN0IENhbGwgZm9yIHRoZSB3ZWJwdXNoIHByb3RvY29sLiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi13ZWJwdXNo LXByb3RvY29sLTA1IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtd2VicHVzaC1wcm90b2NvbC0wNTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgeW91IGhhdmUgYW55IGlzc3VlcyBv ciBxdWVzdGlvbnMgcmVnYXJkaW5nIHRoZSBkcmFmdCBwbGVhc2Ugc3VibWl0IGl0IHRvIHRoZSBs aXN0LCB3aGVuIHJhaXNpbmcgaXNzdWVzIHBsZWFzZSBwcm92aWRlIGNvbnN0cnVjdGl2ZSByZXNv bHV0aW9uIHdoZW4gcG9zc2libGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSBhY2tub3dsZWRnZSBvbiB0aGUgbGlzdCBldmVuIHdo ZW4geW91IGFyZSBjb250ZW50L2hhcHB5IHdpdGggdGhlIHN0YXR1cyBvZiB0aGUgZHJhZnQuJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoZSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCB3aWxsIGVuZCBvbiBKdW5lIDZ0aCAoMyB3ZWVr cykuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlNoaWRhPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5BcyBjby1jaGFpcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpXZWJwdXNoIG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpXZWJwdXNoQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+V2VicHVzaEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3dlYnB1c2giIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3dlYnB1c2g8L2E+PG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCldlYnB1c2ggbWFpbGluZyBsaXN0 PGJyPg0KPGEgaHJlZj0ibWFpbHRvOldlYnB1c2hAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5X ZWJwdXNoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vd2VicHVzaCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vd2VicHVzaDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpXZWJwdXNoIG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9Im1haWx0bzpXZWJwdXNoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+V2VicHVzaEBp ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3dlYnB1c2giIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3dlYnB1c2g8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCldlYnB1c2ggbWFpbGluZyBs aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOldlYnB1c2hAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5XZWJwdXNoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vd2VicHVzaCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vd2VicHVzaDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpXZWJwdXNoIG1haWxpbmcgbGlzdDxi cj4NCjxhIGhyZWY9Im1haWx0bzpXZWJwdXNoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+V2Vi cHVzaEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3dlYnB1c2giIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3dlYnB1c2g8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KV2VicHVzaCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo cmVmPSJtYWlsdG86V2VicHVzaEBpZXRmLm9yZyI+V2VicHVzaEBpZXRmLm9yZzwvYT48YnI+DQo8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3dlYnB1c2giIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3dlYnB1 c2g8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_65b3ac726b70495db4bb0c2df33c19dcAntiopecrfcanonfr_-- From nobody Wed Jun 1 05:56:52 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0EB012D1B6 for ; Wed, 1 Jun 2016 05:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WNSZSuooEso for ; Wed, 1 Jun 2016 05:56:50 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0707412D1AF for ; Wed, 1 Jun 2016 05:56:50 -0700 (PDT) Received: by mail-qg0-x235.google.com with SMTP id p34so37163742qgp.1 for ; Wed, 01 Jun 2016 05:56:49 -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; bh=/gZlkAcXKFslIW3eO4f2MNwyFD9tsWz/a/97YLVgwKA=; b=cLNA55N4d2sW+QBrZ5Q37xpBvHIzd5oOyvzJUvrFtmMqCo6p9qySIs7S32JrZIsO5M rZ5wTBCcTed4eWNWh869l/VbDrrgb7gpuQIISjRoQABWDCy9goGzmw4TNDcOLriqNxhI AR5xjr4Z0MSaPOmi5ZreEmOhcolYlN/VIYFbFSple8aezS5aiAMXmoPf9oZohzFQ0CBb 3aR53yKJG+Kv0dhlP9oFb8HryGG5SuJGx8HySy5gK7+V4B+9cFiM94DcJItcKHnnh9QY DLkqIaXvAAgqQHqJNiYGzP7zrPK1oILybn95y5amK2um6Wsg5/W3ubKJDV0TI4vsOsqy TDLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=/gZlkAcXKFslIW3eO4f2MNwyFD9tsWz/a/97YLVgwKA=; b=UXuqY9ZkmLorLgHfyeQHmYSoyQvCHq3NezpC11QL0XT0ebjkvdNjU3lGv6kviXt7nB EK+j9VS/BxMiN1+05/7/fqfVhrOl7PvyJJuoR33txEzRQSHONVQP++HN69Xu1xIajEtv cjvsNNWYwrEuq78fVnhOyGjH/2p9pBMMwbwBRaxgETr5kj1mHQjvzHKNnHoKYnWeIIIU 2swb2wOuUNss+PjsMfMV3ufZUU/4AFxeGL8Gse2IA7rkdMpIBQ6gDu/eh5+QLOhPvcLM 2GvZGAwnZIUC7qr9qYFJpa6w7yu6hx68yISUdJ/Ut/WsDXkPlNwuC6f3LyzISfshr6oS 5SEw== X-Gm-Message-State: ALyK8tIRne39pesH+xJzYRgJS3vCkdysaE8L00Mwl2egqpw5DwwfiIG1XvfMjc2dJD5Z/0NIjqPjkeRA+4aR2g== MIME-Version: 1.0 X-Received: by 10.140.253.85 with SMTP id y82mr34344974qhc.94.1464785809174; Wed, 01 Jun 2016 05:56:49 -0700 (PDT) Received: by 10.140.104.110 with HTTP; Wed, 1 Jun 2016 05:56:49 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Jun 2016 22:56:49 +1000 Message-ID: From: Martin Thomson To: Brian Raymor Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" , Peter Beverloo Subject: Re: [Webpush] Non-blocking comments on -05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 12:56:52 -0000 On 1 June 2016 at 13:42, Brian Raymor wrote: > There was some early discussion in https://github.com/webpush-wg/webpush-protocol/issues/24. > > There were no major objections at the time. It just felt odd to have a special case for TTL=0 in comparison to TTL=1. That's right, I remember now. Costin has said as much on the PR that I generated. If Peter is OK with this explanation, I will just close the PR. From nobody Wed Jun 1 06:01:23 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9FFE12D1BE for ; Wed, 1 Jun 2016 06:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzhzKd7Gb6v6 for ; Wed, 1 Jun 2016 06:01:21 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC1B812D111 for ; Wed, 1 Jun 2016 06:01:20 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id w16so12297323lfd.2 for ; Wed, 01 Jun 2016 06:01:20 -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; bh=RzsFdTuuUto9RvAxii0VJC6zYp3SNvcMOHG0blo9z20=; b=eu/Vf33DvqnWonB48QlGj0o9AaL6UV4QRjBeCWCqj7NqaTXVqlbQOuN2b+j/ryXD+E 4VJeVzhC+yrOgiCzvpruSsjTS2nDuB60CpBPaS886GFqFEIKxW4ktwLCL/dozkYBmNQz 3UIqC+94LSrcob2wdMMSczchdXx9cPPllisHA93xzeKAKtatYImqbUFUwpeQnqCAY36/ nOvof7a0h4kcpknP+aVdUxKlHgSAnCI8KP0NyQnVFqlOEUFTpCf+HX3p8zO7pa74fBUK K1szPGK2MlKrNMnery0gn39+VIkeMZ1tVw3fZsOPeIeqVfavvgdO18zzQec5hVdbK0n2 K08A== 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; bh=RzsFdTuuUto9RvAxii0VJC6zYp3SNvcMOHG0blo9z20=; b=Xb1pdUgOwfPg8W7svXtF/+3TM84d8iOqJeLBOVlXNq6oepvQWy4SOIKMwWfZraVZG9 lK/o/VC5LPlaQ+vFQxem+SkYWwGXqnGRO0BlX9FTt/lSTxp1sbSISp2KQefRZqMg9js9 mXQH3N2Lddq/1Of1w5emV2AOTI7tYDyv3ptz1Dsrmfeff9aE+zLp3Ddo/Eumb1v7EIow 5KaoZf7gmvscWbDli6USGFPJpxav5F0Tl4yLQeFcYjw2Wef9jBjnCPDDhURQprUxoCsN AJbeuKbjbpWycdOm8eC5Bp+TDQNRP7ryRaJ/ZorphI/57wDeS1VEZb8zI7FEjj9rSXC4 UPIQ== X-Gm-Message-State: ALyK8tJoSorxcSNCHUO3s8GwaMIS7HtdvseKMFs9E1e+u0ZGiYEepPXbs76APEshctyqeeO4ha+aeT32tibW+/f6 X-Received: by 10.25.166.71 with SMTP id p68mr1670446lfe.48.1464786078784; Wed, 01 Jun 2016 06:01:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.167.82 with HTTP; Wed, 1 Jun 2016 06:01:17 -0700 (PDT) In-Reply-To: References: From: Peter Beverloo Date: Wed, 1 Jun 2016 14:01:17 +0100 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11410a1ee6378f0534371568 Archived-At: Cc: Brian Raymor , "webpush@ietf.org" Subject: Re: [Webpush] Non-blocking comments on -05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 13:01:22 -0000 --001a11410a1ee6378f0534371568 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jun 1, 2016 at 1:56 PM, Martin Thomson wrote: > On 1 June 2016 at 13:42, Brian Raymor wrote: > > There was some early discussion in > https://github.com/webpush-wg/webpush-protocol/issues/24. > > > > There were no major objections at the time. It just felt odd to have a > special case for TTL=3D0 in comparison to TTL=3D1. > > That's right, I remember now. Costin has said as much on the PR that > I generated. If Peter is OK with this explanation, I will just close > the PR. > I will defer to Costin=E2=80=94 no-change resolution works for me. Thanks, Peter --001a11410a1ee6378f0534371568 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 1, 2016 at 1:56 PM, Martin Thomson <martin.thomson@gmail.com> w= rote:
On 1 June 2016 at 13:42, B= rian Raymor <Brian.Raymor@= microsoft.com> wrote:
> There was some early discussion in https://github.com/web= push-wg/webpush-protocol/issues/24.
>
> There were no major objections at the time. It just felt odd to have a= special case for TTL=3D0 in comparison to TTL=3D1.

That's right, I remember now.=C2=A0 Costin has said as much on t= he PR that
I generated.=C2=A0 If Peter is OK with this explanation, I will just close<= br> the PR.

I will defer to Costin=E2=80=94= no-change resolution works for me.

Thanks,
<= div>Peter

--001a11410a1ee6378f0534371568-- From nobody Wed Jun 1 07:43:26 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEC412D50F for ; Wed, 1 Jun 2016 07:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WfkgzF3xpUbT for ; Wed, 1 Jun 2016 07:43:23 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE33212D59F for ; Wed, 1 Jun 2016 07:43:22 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id g64so16534694pfb.2 for ; Wed, 01 Jun 2016 07:43:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KUAwqj3phZpSmMAaaAuV4NrqDFMSzuxg+G8WFvl9fPY=; b=tQMBnyB95gu+6XSEmEu0FCkrW7+i9rASi8Fh+W8NN7tm7/e8HnelHHK0GIUA9DI5jd Oc3lkkUi1lImG5uc43RjlhJ1wwQvIg4rU3+uDDnqSZ19YKREAX72B87Zbdo8VZb1drdb rEIOk/22P43k8/YDkpJCsLCqazIoT3/vQWxMtvlwCqjCR9uvKh1sD5Wxr8lErTc9nuUt R3w0LI4IxNAVngYg+iZoI51tho6HmmGwV4jpmtGmm+GKO9Z7WFAV4yRFy/bSUtXWxIhy iQc6xgj9E/Y5NopOeF1QW97+nLAVtyzFsvm7UPzPcyQPY3jWAKhjicduMWEW6c+d/a5M W8qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KUAwqj3phZpSmMAaaAuV4NrqDFMSzuxg+G8WFvl9fPY=; b=Pozgr7WMw9dXt2/JrbvRlJzLaUpZMUW+0uV7VBKFICf8pxt5dxPcHVYhBbZX5M8Iyl H/msC/9GhQd9Khq63YgkqsvDzpr99jCE50pNbNA7H2Y2tGXKGNaGrw3p/JX/F+aNAfKa aGBtWzPPDb+ziFR5MwJc3Vj2gnd5Cqzv9oVs301b7lq4OOrw4BgHhNNFRCP8Dg2vwav5 L3dyTz74U0lAo7aCq7pOrJvpeJnYdytt/74rjVSh4Qq67X0EvZbn0rlMHcClT28UC2DA 42dtbH7zU/LpocFlrqT9DbiZG2sXrhAr53m1F0ZMUlNBBa8rMEX6CKoWXiR9HKRsF9cV 0ikA== X-Gm-Message-State: ALyK8tJnRSK1a/9fKLvWGPTYPdd4WVmfYP52sUxCmNPlItyYiAbYjd3JxbdU4k5MvdSsaj8qrQIGgPTXQ7XsaQ== X-Received: by 10.98.100.132 with SMTP id y126mr9504246pfb.101.1464792202515; Wed, 01 Jun 2016 07:43:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Costin Manolache Date: Wed, 01 Jun 2016 14:43:12 +0000 Message-ID: To: Peter Beverloo , Martin Thomson Content-Type: multipart/alternative; boundary=94eb2c0989aee69b91053438825d Archived-At: Cc: Brian Raymor , "webpush@ietf.org" Subject: Re: [Webpush] Non-blocking comments on -05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 14:43:25 -0000 --94eb2c0989aee69b91053438825d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If encoding what is needed for receipt in the message ID works for other implementations, I think we should keep it. I agree that requiring storage for TTL=3D0 defea= ts the purpose, ttl=3D0 should be the fastest and lowest cost way to deliver a message. In GCM we do send receipts for TTL=3D0, but it's easy to disable them for webpush. Costin On Wed, Jun 1, 2016 at 6:01 AM Peter Beverloo wrote: > On Wed, Jun 1, 2016 at 1:56 PM, Martin Thomson > wrote: > >> On 1 June 2016 at 13:42, Brian Raymor wrote= : >> > There was some early discussion in >> https://github.com/webpush-wg/webpush-protocol/issues/24. >> > >> > There were no major objections at the time. It just felt odd to have a >> special case for TTL=3D0 in comparison to TTL=3D1. >> >> That's right, I remember now. Costin has said as much on the PR that >> I generated. If Peter is OK with this explanation, I will just close >> the PR. >> > > I will defer to Costin=E2=80=94 no-change resolution works for me. > > Thanks, > Peter > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > --94eb2c0989aee69b91053438825d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If =C2=A0encoding what is needed for receipt=C2=A0in the=C2=A0message ID works for=C2=A0other= implementations,
I= =C2=A0think we should keep it. I agree that= requiring storage for TTL=3D0 defeats the=C2=A0
purpose, = ttl=3D0 should be the fastest and lowest cost way to deliver a message.

In GCM we do send receipts for TTL=3D0, but it&#= 39;s easy to disable them for webpush.

Costin

On Wed, Jun 1, 2016 at 6:= 01 AM Peter Beverloo <beverloo@go= ogle.com> wrote:
On Wed, Jun 1, = 2016 at 1:56 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 1 June 2016 at 13:42, Brian Raymo= r <Brian= .Raymor@microsoft.com> wrote:
> There was some early discussion in http= s://github.com/webpush-wg/webpush-protocol/issues/24.
>
> There were no major objections at the time. It just felt odd to have a= special case for TTL=3D0 in comparison to TTL=3D1.

That's right, I remember now.=C2=A0 Costin has said as much on t= he PR that
I generated.=C2=A0 If Peter is OK with this explanation, I will just close<= br> the PR.

<= div class=3D"gmail_extra">
I will defer to C= ostin=E2=80=94 no-change resolution works for me.

= Thanks,
Peter

_______________________________________________
Webpush mailing list
Webpush@ietf.org<= br> https://www.ietf.org/mailman/listinfo/webpush
--94eb2c0989aee69b91053438825d-- From nobody Wed Jun 1 12:52:04 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E058112D5E6 for ; Wed, 1 Jun 2016 12:52:01 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OiRPkTT7UNY5 for ; Wed, 1 Jun 2016 12:51:59 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A228212D563 for ; Wed, 1 Jun 2016 12:51:59 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id e62so103516343ita.1 for ; Wed, 01 Jun 2016 12:51:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=/19ZdBqNepnZBuUgJnjmbRUgPtzxwg1EknBuT/amPMA=; b=Ak7d5+MqEL2c9mZhjKFx0He/qEec/Khz+LtJehYTzKe++N4arV/wbmzDOnzusBOv9w WI6nzXC8Fhza6BbH7f0kjpl7Ro+s09tRKEWkoOo6RvBYqb/uc3Avu/G2sDvR6uuqe1TJ 4KdCTY8XTX1Kc8inmPeG81VeHShVrgjE03g8Lnr8xHnoWGFceS5gQK7Zz2r5/vsy/PWF rcUc5h0jYKwRlPeS6p3VESOOuAe2M6Wp7lvkKf9v2U6RXo5zPJm56+bGxTtM7B5SK9AZ PFUtS9h3epmwwHBjadqAWR3l0TWbo5LEa+Xismb2IZ/hiRwtZ6IV4EMhZ5ugUPz9AOmx +hfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=/19ZdBqNepnZBuUgJnjmbRUgPtzxwg1EknBuT/amPMA=; b=Qmgi6nckAS8CY8GDiFHEXwj4s0+1X6C5vBT/AZ1Z7+/JIsPpRsuOoDRSFmx9qByWw6 45iy8v/WghT/OLGg6lEjBcP4ZUKj9pN5jNaSjUJ1YdLt9SInKzx65f/nwjm0UaLsrcET GZKPr/weUELjeGbL83ZOte2HjLdESIMkjyS26u2Oa+BUEaNIfZs8A5ysWAd/nzlakrNf H84kWTQKG4BhTCoquI09Xf21FMfRH8bNKMOLpU6yn36TJSiV8pMW0CHiN5kwwyNygv+r dg7jH0lcbJ6Wg3xr70A3g2fIvyMEw2oPa+h2zWOjl+BOTJ7W65IM1OIj/Zer02zDTU7n G7mQ== X-Gm-Message-State: ALyK8tKSi9fCpDWohHVDHufBKHkpEpq4q9LP/o0ldjuxpAnZSYx5QlDANCDD1UABuFzCjDAvVVL3UdzR1TfcZw== X-Received: by 10.36.135.201 with SMTP id f192mr22418511ite.50.1464810718966; Wed, 01 Jun 2016 12:51:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.43.197 with HTTP; Wed, 1 Jun 2016 12:51:19 -0700 (PDT) From: Idel Pivnitskiy Date: Wed, 1 Jun 2016 22:51:19 +0300 Message-ID: To: webpush@ietf.org Content-Type: multipart/alternative; boundary=94eb2c1124649137f705343cd2ed Archived-At: Subject: [Webpush] Proposal: different push message resource URIs for AS and UA X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 19:52:02 -0000 --94eb2c1124649137f705343cd2ed Content-Type: text/plain; charset=UTF-8 Hi all, push message: The push service creates a push message resource to > identify push messages that have been accepted for delivery > (Section 5 ). The push message resource is also deleted by the > user agent to acknowledge receipt (Section 6.2 ) of a push message. > > And later in the draft we can see that PS returns the same URI for AS and UA: /d/qDIYHNcfAIPP_5ITvURr-d6BGtYnTRnk > > It gets ability for an AS to send DELETE request to this URI. Consequently, it may cause acknowledgement for a PS and sending a push message delivery receipt to the AS. Yes, this is a strange behaviour for a proper AS, but a push message resource URI could be intercepted. Even if the channel between an AS and a PS is encrypted, attacker can get it from the AS log files. So, I think that the push message resource URIs must be different for AS and UA, to prevent this attack by design. In addition, it will get possibility to provide deletion of sent push messages for an AS. In case, when push message are not actual at all, but TTL value was to high. Best regards, Idel Pivnitskiy -- Twitter: @idelpivnitskiy GitHub: @idelpivnitskiy --94eb2c1124649137f705343cd2ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

push message:  The push service creates a push message resourc=
e to
      identify push messages that have been accepted for delivery
      (Section 5).  The push message resource is also deleted by =
the
      user agent to acknowledge receipt (Section 6.2) of a push=
 message.

And later in the draft we c= an see that PS returns the same URI for AS and UA:

/d/qDIYHNcfAIPP_5ITvURr-d6BGtYnTRnk
=

It gets ability for an AS to send DELETE r= equest to this URI.=C2=A0Consequently, it may cause acknowledgement for a P= S and sending a push message delivery receipt to the AS.
Yes, thi= s is a strange behaviour for a proper AS, but a push message resource URI c= ould be intercepted. Even if the channel between an AS and a PS=C2=A0is enc= rypted, attacker can get it from the AS log files. So, I think that the pus= h message resource URIs must be different for AS and UA, to prevent this at= tack by design.

In addition, it will get possibili= ty to provide deletion of sent push messages for an AS. In case, when push = message are not actual at all, but TTL value was to high.

=
Best regards,
Idel Pivnitskiy
--
Twitter: @idelpivnitskiy
GitHub:=C2=A0@idelpivnitskiy
--94eb2c1124649137f705343cd2ed-- From nobody Wed Jun 1 16:34:58 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B48EF12B005 for ; Wed, 1 Jun 2016 16:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfQ4D4BR7a2t for ; Wed, 1 Jun 2016 16:34:54 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0114.outbound.protection.outlook.com [65.55.169.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 325B512B05D for ; Wed, 1 Jun 2016 16:34:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FZPOMCjcTB2OWztKcQT6vbfNEg1DqauobsrYDKwXC6U=; b=ETpsy6eozdCP8nW+jh+to96PVP33M/iP62OJI6CwwViLbU+2REUTtD9iitqa+kWLwKZgpdAGuCcoYAa/3rpqnjeht5NUx4Wy8tNIFfg+5eCe+dq4N8SatMbAPnqR4eVUhIH+hHuuaIh4HtaRP5DoDu2zQHC18dNzsP6d4rMOszg= Received: from CO2PR03MB2407.namprd03.prod.outlook.com (10.166.93.137) by CO2PR03MB2408.namprd03.prod.outlook.com (10.166.93.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.506.9; Wed, 1 Jun 2016 23:34:51 +0000 Received: from CO2PR03MB2407.namprd03.prod.outlook.com ([10.166.93.137]) by CO2PR03MB2407.namprd03.prod.outlook.com ([10.166.93.137]) with mapi id 15.01.0506.011; Wed, 1 Jun 2016 23:34:52 +0000 From: Brian Raymor To: RUELLAN Herve , Peter Beverloo , "webpush@ietf.org" Thread-Topic: [Webpush] Non-blocking comments on -05 Thread-Index: AQHRu3RQwDJq8LaJ6EaFkMQ0Dd4KCZ/Uf30AgAC+IgA= Date: Wed, 1 Jun 2016 23:34:51 +0000 Message-ID: References: <6af49c2baf1b4e4f884b812d573b947e@Antiope.crf.canon.fr> In-Reply-To: <6af49c2baf1b4e4f884b812d573b947e@Antiope.crf.canon.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: crf.canon.fr; dkim=none (message not signed) header.d=none; crf.canon.fr; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [24.16.23.27] x-ms-office365-filtering-correlation-id: 2bb809c6-4d2d-4993-03e2-08d38a75545c x-microsoft-exchange-diagnostics: 1; CO2PR03MB2408; 5:tpYmhR9jEWPpemzdkUM/OJLvMA2ftVVqu4AOQ5O3pXrmlMpUhKdWDjvUuLvnvwYfmgJ3QT8jCIVg0EzoAFVpEedBe3tgdDa2akqdX2NXUnyU7Xa4LOFBpJLXUpjSmpb3uYmsTUY7ZH+Lz5lcxNBTsQ==; 24:e5ondQKvPtkfM575uet3sgpZaiLdNUn9or4BwGCYhJVEFTog5rN5doux9tc/g0FksMu9JqvG31bevtqzV95TcNIK6FyKpACYXiOtNKWx9ys=; 7:msI63tUM3ur+ynF/Ibtls4Le+TG/jIst0bw1lUswJEGgRFGR6XkCeX3JRMuhI9RCt9zvY1t0sCzhmuNa5jSjZ+kCqC8saOby3Ind9UMAo1+bbOg/wUvkiAt2RisZpHH++Mxceq27X15DZIsnxDG4BaPT9GprjAUd5mh2/jVPRivtK59mMeluVSeo0DFHsaY9XKc5FTo9DhG2Yz2w+xLqUg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR03MB2408; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CO2PR03MB2408; BCL:0; PCL:0; RULEID:; SRVR:CO2PR03MB2408; x-forefront-prvs: 096029FF66 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(69224002)(377454003)(24454002)(81166006)(586003)(106116001)(8936002)(6116002)(102836003)(66066001)(2900100001)(15975445007)(77096005)(3846002)(122556002)(5003600100002)(5004730100002)(87936001)(5002640100001)(99286002)(50986999)(76176999)(2950100001)(33656002)(10400500002)(76576001)(3280700002)(19580395003)(5005710100001)(10290500002)(19580405001)(107886002)(5008740100001)(10090500001)(5001770100001)(86362001)(74316001)(2906002)(54356999)(2501003)(3660700001)(92566002)(189998001)(8676002)(9686002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR03MB2408; H:CO2PR03MB2407.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jun 2016 23:34:51.6745 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR03MB2408 Archived-At: Subject: Re: [Webpush] Non-blocking comments on -05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 23:34:57 -0000 DQpIZXJ2ZSwNCg0KVGhhbmtzIGZvciBhbGwgdGhlIGZlZWRiYWNrIGFuZCBzdWdnZXN0aW9ucy4g SGVyZSBhcmUgc29tZSBwYXJ0aWFsIHJlc3BvbnNlcy4NCg0KT24gSnVuZSAxLCAyMDE2LCBhdCA0 OjQ2IEFNLCBIZXJ2ZSBSdWVsbGFuIDwgSGVydmUuUnVlbGxhbkBjcmYuY2Fub24uZnI+IHdyb3Rl Og0KDQo+IEFuZCBhbm90aGVyIG9uZSBmb3IgY2hhbmdpbmcgdGhlIFVSSXMgdXNlZCBpbiB0aGUg ZXhhbXBsZXMgYW5kIG1ha2luZyB0aGVtIG1vcmUgZXhwbGljaXQgKHdoaWNoIEkgdGhpbmsgaXMg aGVscGZ1bCBmb3IgYSBmaXJzdC10aW1lIHJlYWRlciBvZiB0aGUgc3BlYyk6DQo+IGh0dHBzOi8v Z2l0aHViLmNvbS93ZWJwdXNoLXdnL3dlYnB1c2gtcHJvdG9jb2wvcHVsbC85NA0KDQpDb21tZW50 cyBpbiBodHRwczovL2dpdGh1Yi5jb20vd2VicHVzaC13Zy93ZWJwdXNoLXByb3RvY29sL3B1bGwv OTQjaXNzdWVjb21tZW50LTIyMzE1MjcwOA0KDQo+IDEuIFNvbWUgb2YgdGhlIFVSTnMgdXNlZCBt YXkgYmUgY29uZnVzaW5nLiBSZW5hbWluZyB0aGVtIGNvdWxkIGhlbHAgbWFrZSB0aGluZ3MgY2xl YXJlci4NCg0KPiBUaGUgcHVzaCBtZXNzYWdlIHN1YnNjcmlwdGlvbiBzZXQgVVJOLCAidXJuOmll dGY6cGFyYW1zOnB1c2g6c2V0IiwgY291bGQgYmUgY2hhbmdlZCB0byAidXJuOmlldGY6cGFyYW1z OnB1c2g6c3ViOnNldCIsDQo+IHRvIGJldHRlciBzaG93IGl0IGlzIHJlbGF0ZWQgdG8gcHVzaCBt ZXNzYWdlIHN1YnNjcmlwdGlvbiByZXNvdXJjZXMgYW5kIG5vdCBkaXJlY3RseSB0byBwdXNoIHJl c291cmNlcy4NCg0KPiBUaGUgcmVjZWlwdCBzdWJzY3JpcHRpb24gVVJOLCAidXJuOmlldGY6cGFy YW1zOnB1c2g6cmVjZWlwdCIsIGNvdWxkIGJlIGNoYW5nZWQgdG8gInVybjppZXRmOnBhcmFtOnB1 c2g6cmVjZWlwdDpzdWIiLA0KPiB0byBiZXR0ZXIgc2hvdyBpdCBjb3JyZXNwb25kcyB0byBhIHJl Y2VpcHQgKnN1YnNjcmlwdGlvbiogcmVzb3VyY2UgYW5kIG5vdCB0byBhIHJlY2VpcHQgcmVzb3Vy Y2UgKGV2ZW4gaWYgdGhlc2UgZG9uJ3QgZXhpc3QpLg0KDQpJIGRvbid0IGhhdmUgc3Ryb25nIGZl ZWxpbmdzIGFib3V0IG1ha2luZyB0aGlzIGNoYW5nZSBub3cuIEknbGwgd2FpdCB0byBzZWUgaWYg dGhlcmUncyBmdXJ0aGVyIHN1cHBvcnQgb24gdGhlIG1haWxpbmcgbGlzdC4NCg0KPiAyLiBXaGF0 IGRvZXMgYSBwdXNoIHNlcnZlciB0aGF0IHJlY2VpdmVzIGEgcmVxdWVzdCBmb3IgYSBwdXNoIG1l c3NhZ2Ugd2l0aCAiUHJlZmVyOiByZXNwb25kLWFzeW5jIg0KPiBidXQgZG9lc24ndCB3YW50IHRv IHByb3ZpZGUgYSByZWNlaXB0IHN1YnNjcmlwdGlvbiwgb3IgZG9lc24ndCBzdXBwb3J0IHByb3Zp ZGluZyByZWNlaXB0cz8gSXMgdGhpcyBhbGxvd2VkIGluIHRoZSBmaXJzdCBwbGFjZT8NCg0KVGhl IHB1c2ggc2VydmljZSBpcyByZXF1aXJlZCB0byBzdXBwb3J0IHJlY2VpcHQgc3Vic2NyaXB0aW9u cy4NCg0KICAgVGhlIHB1c2ggc2VydmljZSBNVVNUIGFsc28gcHJvdmlkZSBhIFVSSSBmb3IgdGhl IHJlY2VpcHQNCiAgICBzdWJzY3JpcHRpb24gcmVzb3VyY2UgaW4gYSBsaW5rIHJlbGF0aW9uIG9m IHR5cGUNCiAgInVybjppZXRmOnBhcmFtczpwdXNoOnJlY2VpcHQiLg0KDQoNCg== From nobody Wed Jun 1 16:51:03 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 052BD12D531; Wed, 1 Jun 2016 16:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=o8xerhZ6; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=WGl+s0C0 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 8ZkjXlinqJ1n; Wed, 1 Jun 2016 16:51:00 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20FF512D571; Wed, 1 Jun 2016 16:51:00 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 56171207BE; Wed, 1 Jun 2016 19:50:59 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Wed, 01 Jun 2016 19:50:59 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=S1mqP Xji1qA10+WJeL5tqoO9vYw=; b=o8xerhZ6iPwNt7xp3CtdNgpfR3Vpkn/FFrSSq +TKz2awuG4lL7FLozoWW1e8hCNtRRnDZ6XHzF2UuDKzbw+PX7Am/o3GpSq0q57Pb jkmQL3YEzB4n7q/7ZLbllifb3JRiyOsyYThOzPOTI6l4gW5hm4aM+jT9lug4Yevl AkW3GI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=S1mqPXji1qA10+WJeL5tqoO9vYw=; b=WGl+s 0C0JpCaHkSwlki5dzNhAduuYUzkL4H4QKBxwcjqY+gcbvQ8SNHbDtFL6m9bbYLAD SpC999bAPsbSGMsqpoN7GhDdIY6I9ArVQO1quEiryN9rILrnnhZkRQEg3aY9HBnx b36Fll9h1IdShOj3g8hULpNFQa+/QLKQuFOMfg= X-Sasl-enc: SRzGpTXXGXvO4dH9MZHogWy9A5rA5TzS2t9QeES4Zofi 1464825058 Received: from dhcp-171-68-20-157.cisco.com (dhcp-171-68-20-157.cisco.com [171.68.20.157]) by mail.messagingengine.com (Postfix) with ESMTPA id CD3E5F2A03; Wed, 1 Jun 2016 19:50:58 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_50E1EE67-B37B-4696-8473-6D2B445C9B3C" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: Date: Wed, 1 Jun 2016 16:50:59 -0700 Message-Id: References: <7BE6135D-961D-4D6E-B6FC-99BA27B1B0C4@ntt-at.com> <4B69453E-54AD-414A-BDC3-18E175AA25BC@ntt-at.com> <4467b402-a69f-fc0e-f699-00ca9f9f14e8@mozilla.com> To: webpush-chairs@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Cc: webpush@ietf.org Subject: Re: [Webpush] WGLC for draft-ietf-webpush-protocol-05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 23:51:02 -0000 --Apple-Mail=_50E1EE67-B37B-4696-8473-6D2B445C9B3C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii (off-list) I think at this point it would be appropriate for me to send Richard a = message off-list to ask him to refrain from unprofessional behavior on = the list, per BCP 25. What do you think? Thanks, Alissa > On May 31, 2016, at 6:36 PM, Richard Maher = wrote: >=20 > So with the WGLC drawing to a close, I make that a whole 3 people, = excluding the authors, with anything positive to say about this draft = standard. Does that not tell you something? Or is "3" what passes for = quorum with you people? >=20 > Do you lot get paid per specification? Number of pages? Or do you = actually get tasked with delivering a spec that industry-standard, = feature-rich, and scalable solutions can be built upon? Or perhaps "Just = describe whatever Autopush does"? >=20 > Disbelief. >=20 > On Wed, Jun 1, 2016 at 7:50 AM, JR Conlin > wrote: > I noted my opinion in the follow up. Basically, while the spec goes = into great detail about other aspects of the protocol, sets are left = mostly as "they may exist", and "it's up to the PS and UA". I will also = admit that I was initially confused because I hadn't noticed it was only = between UA and PS, but a second read caught that. >=20 > I am fine as is, because I don't think that outside groups will be = impacted by my concern, nor do I believe that they would fail to = implement a solution if they misunderstood it. >=20 > On May 31, 2016 4:25 PM, "Brian Raymor" > wrote: >=20 > On May 31, 2016, at 12:01 PM, JR Conlin > wrote: >=20 > Thanks for your feedback. >=20 > > There are some aspects of the published spec that are optional and = seem a bit "hand wavey"* (e.g. "subscription sets") >=20 > How do you feel this could be improved? What details are missing from = your perspective? >=20 > > I believe that the recommendation for expired or removed push = subscription endpoints was to return 410, not 404 (see section 7.3). I = note that 7.3.1 suggests 410 for expired subscription sets, so it might = help if things were consistent. >=20 > Good catch. > 7.3.1 should be 404 and not 410. > 410 (Gone) is returned when a push service decides to cease delivery = attempts before the TTL expires. > 404 (Not Found) is returned when a push services expires a = subscription or set. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush = >=20 >=20 > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush --Apple-Mail=_50E1EE67-B37B-4696-8473-6D2B445C9B3C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
(off-list)

I think at this point it would be = appropriate for me to send Richard a message off-list to ask him to = refrain from unprofessional behavior on the list, per BCP 25. What do = you think?

Thanks,
Alissa

On = May 31, 2016, at 6:36 PM, Richard Maher <maherrj@googlemail.com> wrote:

So with the WGLC = drawing to a close, I make that a whole 3 people, excluding the authors, = with anything positive to say about this draft standard. Does that not = tell you something? Or is "3" what passes for quorum with you = people?

Do you lot = get paid per specification? Number of pages? Or do you actually get = tasked with delivering a spec that industry-standard, feature-rich, and = scalable solutions can be built upon? Or perhaps "Just describe whatever = Autopush does"?
Disbelief.

On Wed, Jun 1, 2016 at 7:50 AM, JR = Conlin <jconlin@mozilla.com> wrote:

I noted my opinion in the follow up. Basically, while the = spec goes into great detail about other aspects of the protocol, sets = are left mostly as "they may exist", and "it's up to the PS and = UA".  I will also admit that I was initially confused because I = hadn't noticed it was only between UA and PS, but a second read caught = that.

I am fine as is, because I don't = think that outside groups will be impacted by my concern, nor do I = believe that they would fail to implement a solution if they = misunderstood it.

On May 31, 2016 4:25 PM, "Brian Raymor" = <Brian.Raymor@microsoft.com> wrote:

On May 31, 2016, at 12:01 PM, JR Conlin <jconlin@mozilla.com> wrote:

Thanks for your feedback.

> There are some aspects of the published spec that are optional and = seem a bit "hand wavey"* (e.g. "subscription sets")

 How do you feel this could be improved? What details are missing from = your perspective?

> I believe that the recommendation for expired or removed push = subscription endpoints was to return 410, not 404 (see section 7.3). I = note that 7.3.1 suggests 410 for expired subscription sets, so it might = help if things were consistent.

 Good catch.
7.3.1 should be 404 and not 410.
410 (Gone) is returned when a push service decides to cease delivery = attempts before the TTL expires.
404 (Not Found) is returned when a push services expires a subscription = or set.







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


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

= --Apple-Mail=_50E1EE67-B37B-4696-8473-6D2B445C9B3C-- From nobody Wed Jun 1 19:11:43 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D88612D63B for ; Wed, 1 Jun 2016 19:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jv3LxiJRZH-4 for ; Wed, 1 Jun 2016 19:11:40 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E7B712D582 for ; Wed, 1 Jun 2016 19:11:40 -0700 (PDT) Received: by mail-qg0-x22c.google.com with SMTP id p34so47504355qgp.1 for ; Wed, 01 Jun 2016 19:11:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=7xuaodf9nKTq0de/kb+dD2FjaQEUVXIKe4733QPkK9E=; b=f02TN/XNmH5/VLVHJmL8ySwiM8c2UUSSmlfYTScb02XNqVQXsFKLiC7/VZcqphk+Hf mRfI8NByHdmBXSyU6aD4zleXATNpgae31OSer74zWgHUXcYrUEzGGIX1tq2s3rZlXW7F zAJi6QB4LcEWHszHAg8Uh9dw5H2GM3sWYaBp31eJO9BCCl9p9VkxLZe2FomytfkXnba9 UrwdMAa0/wYSu1HjAc15OCZq3fwitLiYk9FbjSWbF/eNqT3pcqa9piQjYVBEYYaxLUgb rpF6rDeAOTRHTPrdgBB3oPJVpQvX5wSLco4uE4yJXH/lhlyxgT2Iml1mPwhmJwpj7rt3 V0Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=7xuaodf9nKTq0de/kb+dD2FjaQEUVXIKe4733QPkK9E=; b=b64P5b0fRT35qskFyyB+Vx9pSktm3nVQSwuyVlz7YDAPcNr0n0QJxhhI7NLFadP/fc eHv4PyR4WW0GPx049IsRwBG9XYcSkgPbUhTTFaSBxyBNCguFn42wRrIRn3aNh35j7zU6 Mi+lwpMDW6zvrxyLlACH2phgI9II0zTmNIFDqpcW+HTKFGOvwK9HUjJPyWhL9+NkALBG duO1hiH1Nsw4W2sYIqh8H1s2JRVcEovt8MyKkLvS/DEAJNySy43DE53laAP41iKkFtwh BMleQ5xU7MLoiY7ROtWJPO7mL4xmaoeTxG5B6X3S6MknWM/dJySEZ4R1cgDhCtZ6xiy8 iq0A== X-Gm-Message-State: ALyK8tLPdEFGjZe36JOhk98f54hkr4wU4CMnFKJkx/oL6IcJR6h5dMjVkU1UFOW+yO3eJ+w4VsdbHn0Tfp3wfQ== MIME-Version: 1.0 X-Received: by 10.140.32.198 with SMTP id h64mr38267782qgh.53.1464833499555; Wed, 01 Jun 2016 19:11:39 -0700 (PDT) Received: by 10.140.104.110 with HTTP; Wed, 1 Jun 2016 19:11:39 -0700 (PDT) In-Reply-To: References: Date: Thu, 2 Jun 2016 12:11:39 +1000 Message-ID: From: Martin Thomson To: Idel Pivnitskiy Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Proposal: different push message resource URIs for AS and UA X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 02:11:42 -0000 On 2 June 2016 at 05:51, Idel Pivnitskiy wrote: > It gets ability for an AS to send DELETE request to this URI. Consequently, > it may cause acknowledgement for a PS and sending a push message delivery > receipt to the AS. I think that this is a feature, not a bug. If the AS wants to abandon a push message, this gives it a way. The other feature that a single URI provides is the fact that UA and AS can agree about the identity of a push message if that is ever needed. (We don't expose this in the push API, so it's not useful in that context, of course.) From nobody Wed Jun 1 19:13:44 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFA6612D64C for ; Wed, 1 Jun 2016 19:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A_r7e6_pZyij for ; Wed, 1 Jun 2016 19:13:40 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::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 03EFD12D63D for ; Wed, 1 Jun 2016 19:13:40 -0700 (PDT) Received: by mail-qg0-x231.google.com with SMTP id 52so52373589qgy.0 for ; Wed, 01 Jun 2016 19:13:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=vB+i7WGr3BgA5UanthtlWwEZuKihurzvFIHWcv17vAc=; b=mJiGBsl0AYCw+2k/jpIpeXAxoX5zf4LOjw7a2zW9kRiDfD10H/r9QfOSQCoZOL64t/ QuFZ4jMr6EmDWkJu2Ysid/vL6N5UYEKR2LBLDEAXJ+VtXdMaYQAX03GiZPXJLc7RHe+x GEx6OOZiiMM9//Scq2xDWjW4w8CHOpAw2Jg0D1f82er+KYqBpXFNI8tSnXHWO/USaJBH PeW+PC9Fm+7M1nbFPza238re0oT+vc6nPWkAyDEEXo5C7ayl84pWzE218LiTWfFAiYU1 VsFH9KXAu/i5pIRYcROOdg/IWckSy/5mX/3KVkzfKm6tmOsTBKvJ4g7tn1okmtJzOjsV w9Xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=vB+i7WGr3BgA5UanthtlWwEZuKihurzvFIHWcv17vAc=; b=dIxd7fTioAT+7HDS/wsMu4FiKjD3SzpUYuFOZ4hR5eiJ7/EY27SUi4BE+HVoDgUtNK JfsfK0r5EkBf2b6qu5S0AG8Tt1qTUysiuz7+28rB0Um9yR7jtKHJzQmCmnRpeip9p9BS 6zrdjrCGs5Y3yJ2URzTPxfBujuWneFn81i/0CG1jgL6CLC/xY6TfHmiY75ImbeYTEH3V jHy7pshj787D75Tvm5uiwP4q38A3Kc+Rsp3yaBi6LknpnzhPomTXEYdyuieg5mVR9eyd 3/oC5/JBfirjiTiBGoE3Xxux+ro5M6+CZVKxqtOi4N3ti6GfNR5VgAKGs8Wq0FWzIT0d JQvw== X-Gm-Message-State: ALyK8tIuzYLo/5e3j5dBC6biEcbST16D5vh7nH4/VX3gqGRwitzZQlN7Reknkt/CxhVxs+6JjSdnT6ArB2pE3Q== MIME-Version: 1.0 X-Received: by 10.140.163.212 with SMTP id j203mr40806449qhj.40.1464833619148; Wed, 01 Jun 2016 19:13:39 -0700 (PDT) Received: by 10.140.104.110 with HTTP; Wed, 1 Jun 2016 19:13:39 -0700 (PDT) In-Reply-To: <6af49c2baf1b4e4f884b812d573b947e@Antiope.crf.canon.fr> References: <6af49c2baf1b4e4f884b812d573b947e@Antiope.crf.canon.fr> Date: Thu, 2 Jun 2016 12:13:39 +1000 Message-ID: From: Martin Thomson To: RUELLAN Herve Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" , Peter Beverloo Subject: Re: [Webpush] Non-blocking comments on -05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 02:13:42 -0000 On 1 June 2016 at 21:46, RUELLAN Herve wrote: > 2. What does a push server that receives a request for a push message with "Prefer: respond-async" but doesn't want to provide a receipt subscription, or doesn't support providing receipts? Is this allowed in the first place? This is handled in RFC7240. It ignores the Prefer header. I believe that existing implementations do this very well :) From nobody Wed Jun 1 21:37:23 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4FA12D629 for ; Wed, 1 Jun 2016 21:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=n88vpQAf; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=kFrCVioX 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 aJIVRfD7AQjO for ; Wed, 1 Jun 2016 21:37:15 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A801712B020 for ; Wed, 1 Jun 2016 21:37:15 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id F1CFA2142F for ; Thu, 2 Jun 2016 00:37:14 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Thu, 02 Jun 2016 00:37:14 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=frRry XRCHrToSfzDsiBwVcGhLa8=; b=n88vpQAfMjeQifE6LsJEERkDsDpWMd9ySr2uy 2YKvRHTdWZ08L12dyLCi/gRzLg0vO/rYzmpG5ocbKpQsWhRfKrFsVU2u7EWuwD19 tgeFJbmOBp5wq4f87ycMa0dpuDt9NXP96nkHC9mTOvoDWzzwWol6WVsDCXzNAgeE F/XGQ4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=frRryXRCHrToSfzDsiBwVcGhLa8=; b=kFrCV ioX0ktKUbkSDOIQlOjHnZmlTVuFwc6ErF2yu1pvcywXuNIP+zjNY/d9Idq2DBZt6 JUMbNpDIyqlvmAAQtB/Y5UmurfO0phCiPd1VT9XHPreot5htk5TinMw4Nj/+Y4Fu Bxm67JvJPpOyymiA3qx+hQKtnAZzOuEBi1y2kY= X-Sasl-enc: tQL5BQ3XdYbSrB9B/OcpKELf6XXi5LIVuFAFtwRT+Z/a 1464842234 Received: from [192.168.1.82] (c-24-6-61-198.hsd1.ca.comcast.net [24.6.61.198]) by mail.messagingengine.com (Postfix) with ESMTPA id 05BF3CC023 for ; Thu, 2 Jun 2016 00:37:13 -0400 (EDT) From: Alissa Cooper Content-Type: multipart/alternative; boundary="Apple-Mail=_DECCE635-C434-4ED2-BA6C-C50CC445CD66" Message-Id: <6CB583C1-3D7F-4E42-9586-38937F5C8B05@cooperw.in> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Date: Wed, 1 Jun 2016 21:37:12 -0700 References: <7BE6135D-961D-4D6E-B6FC-99BA27B1B0C4@ntt-at.com> <4B69453E-54AD-414A-BDC3-18E175AA25BC@ntt-at.com> <4467b402-a69f-fc0e-f699-00ca9f9f14e8@mozilla.com> To: webpush@ietf.org In-Reply-To: X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Webpush] WGLC for draft-ietf-webpush-protocol-05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 04:37:18 -0000 --Apple-Mail=_DECCE635-C434-4ED2-BA6C-C50CC445CD66 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Whoops. Obviously this went to the list rather than off it, but Shida = and I are now in touch about this. Alissa > On Jun 1, 2016, at 4:50 PM, Alissa Cooper wrote: >=20 > (off-list) >=20 > I think at this point it would be appropriate for me to send Richard a = message off-list to ask him to refrain from unprofessional behavior on = the list, per BCP 25. What do you think? >=20 > Thanks, > Alissa >=20 >> On May 31, 2016, at 6:36 PM, Richard Maher > wrote: >>=20 >> So with the WGLC drawing to a close, I make that a whole 3 people, = excluding the authors, with anything positive to say about this draft = standard. Does that not tell you something? Or is "3" what passes for = quorum with you people? >>=20 >> Do you lot get paid per specification? Number of pages? Or do you = actually get tasked with delivering a spec that industry-standard, = feature-rich, and scalable solutions can be built upon? Or perhaps "Just = describe whatever Autopush does"? >>=20 >> Disbelief. >>=20 >> On Wed, Jun 1, 2016 at 7:50 AM, JR Conlin > wrote: >> I noted my opinion in the follow up. Basically, while the spec goes = into great detail about other aspects of the protocol, sets are left = mostly as "they may exist", and "it's up to the PS and UA". I will also = admit that I was initially confused because I hadn't noticed it was only = between UA and PS, but a second read caught that. >>=20 >> I am fine as is, because I don't think that outside groups will be = impacted by my concern, nor do I believe that they would fail to = implement a solution if they misunderstood it. >>=20 >> On May 31, 2016 4:25 PM, "Brian Raymor" > wrote: >>=20 >> On May 31, 2016, at 12:01 PM, JR Conlin > wrote: >>=20 >> Thanks for your feedback. >>=20 >> > There are some aspects of the published spec that are optional and = seem a bit "hand wavey"* (e.g. "subscription sets") >>=20 >> How do you feel this could be improved? What details are missing from = your perspective? >>=20 >> > I believe that the recommendation for expired or removed push = subscription endpoints was to return 410, not 404 (see section 7.3). I = note that 7.3.1 suggests 410 for expired subscription sets, so it might = help if things were consistent. >>=20 >> Good catch. >> 7.3.1 should be 404 and not 410. >> 410 (Gone) is returned when a push service decides to cease delivery = attempts before the TTL expires. >> 404 (Not Found) is returned when a push services expires a = subscription or set. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Webpush mailing list >> Webpush@ietf.org >> https://www.ietf.org/mailman/listinfo/webpush = >>=20 >>=20 >> _______________________________________________ >> Webpush mailing list >> Webpush@ietf.org >> https://www.ietf.org/mailman/listinfo/webpush >=20 > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush --Apple-Mail=_DECCE635-C434-4ED2-BA6C-C50CC445CD66 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Whoops. Obviously this went to the list = rather than off it, but Shida and I are now in touch about = this.

Alissa

On Jun 1, 2016, at 4:50 PM, Alissa Cooper = <alissa@cooperw.in> wrote:

(off-list)

I think at this point it would be appropriate for me to send = Richard a message off-list to ask him to refrain from unprofessional = behavior on the list, per BCP 25. What do you think?

Thanks,
Alissa

On May 31, 2016, at 6:36 PM, = Richard Maher <maherrj@googlemail.com> wrote:

So with the WGLC = drawing to a close, I make that a whole 3 people, excluding the authors, = with anything positive to say about this draft standard. Does that not = tell you something? Or is "3" what passes for quorum with you = people?

Do you lot = get paid per specification? Number of pages? Or do you actually get = tasked with delivering a spec that industry-standard, feature-rich, and = scalable solutions can be built upon? Or perhaps "Just describe whatever = Autopush does"?
Disbelief.

On Wed, Jun 1, 2016 at 7:50 AM, JR = Conlin <jconlin@mozilla.com> wrote:

I noted my opinion in the follow up. Basically, while the = spec goes into great detail about other aspects of the protocol, sets = are left mostly as "they may exist", and "it's up to the PS and = UA".  I will also admit that I was initially confused because I = hadn't noticed it was only between UA and PS, but a second read caught = that.

I am fine as is, because I don't = think that outside groups will be impacted by my concern, nor do I = believe that they would fail to implement a solution if they = misunderstood it.

On May 31, 2016 4:25 PM, "Brian Raymor" = <Brian.Raymor@microsoft.com> wrote:

On May 31, 2016, at 12:01 PM, JR Conlin <jconlin@mozilla.com> wrote:

Thanks for your feedback.

> There are some aspects of the published spec that are optional and = seem a bit "hand wavey"* (e.g. "subscription sets")

 How do you feel this could be improved? What details are missing from = your perspective?

> I believe that the recommendation for expired or removed push = subscription endpoints was to return 410, not 404 (see section 7.3). I = note that 7.3.1 suggests 410 for expired subscription sets, so it might = help if things were consistent.

 Good catch.
7.3.1 should be 404 and not 410.
410 (Gone) is returned when a push service decides to cease delivery = attempts before the TTL expires.
404 (Not Found) is returned when a push services expires a subscription = or set.







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


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

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

= --Apple-Mail=_DECCE635-C434-4ED2-BA6C-C50CC445CD66-- From nobody Thu Jun 2 00:01:25 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D807912B02D for ; Thu, 2 Jun 2016 00:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mozilla-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpp1YxG-9anX for ; Thu, 2 Jun 2016 00:01:17 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23B3412D580 for ; Thu, 2 Jun 2016 00:01:17 -0700 (PDT) Received: by mail-pa0-x229.google.com with SMTP id um11so3539849pab.0 for ; Thu, 02 Jun 2016 00:01:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Bmr9EuGwV1dBrcs8k2rNoFai1YIJwhLaRIYI+O9J9fc=; b=0rnt8jciebPBkrNhgFY7ipWO1vKouYPOUKtywLXHlDdsz7OGVPO8KvIx5E4hZi4TPy FHYZPMiMuC+gQ1EbNbRTy1hC12LwdeognEMkocpKaQuptDnezLfAHoXQDTqKZr1oM5et 2d2MLcm9rg58zm6lHSPigqEqGBjS+cb3mwpJvVai4wTZVXLPTYbAComwMkVKCy4jF6OK IGuUSejxxBQ/5nCm76z5HbDNh7fVUE+gZ04P8GpGxyDTNO6XKjCeVJLX+gQ/w4uhgPcS nwltlZtPn35liOWnUgS5eS3s7QJvUqvUufvv+be7HgaQ6PnSkIl5gw+A5ZWtUeYP+7dp FvpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Bmr9EuGwV1dBrcs8k2rNoFai1YIJwhLaRIYI+O9J9fc=; b=XuN0G5UYMO7DrH7QwImjth9AKx+oMatP9tyCCKQKMC6xNtkrvuYlu7W3CFfWpgkVaG 822s7SwX88HnhfKAY+kftlCSndo/goT6EqX+WP8aP7K4EFS9YePY45v1YQnPWLSl3TAP 6YNCpzU6RJERcKZ5dlrGEZeivBTMGMIlNCi//9QkyvprfKXMU+ZMnB/YWMGhdIYkbyAO kZv6HWbRx/57SHYKXLYSNsWIXL09wIWqCaknwLz+69CGfsMhKUoTqIKh23fHB2tvVxbS ZxhQbqw05KssGQ4QdGHWqhu7RjBxapT8qRCquRgW0eGCAP9enhTXS37zJcHzV3DWj734 ChGA== X-Gm-Message-State: ALyK8tIrfvgd2U+wE8OmRA2ppGcP9vL2GHqCbh5jik8secljsyat1s+tY1Vpw9FzHHziQh71 X-Received: by 10.66.22.134 with SMTP id d6mr3162670paf.35.1464850876479; Thu, 02 Jun 2016 00:01:16 -0700 (PDT) Received: from [172.20.10.2] ([172.56.38.248]) by smtp.gmail.com with ESMTPSA id 7sm17477370pfe.3.2016.06.02.00.01.14 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 02 Jun 2016 00:01:15 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Kit Cambridge In-Reply-To: Date: Thu, 2 Jun 2016 00:01:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <989D9268-BE9A-47F7-9181-C0F323D1DA1F@mozilla.com> References: <6af49c2baf1b4e4f884b812d573b947e@Antiope.crf.canon.fr> To: Martin Thomson X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Brian Raymor , Peter Beverloo , "webpush@ietf.org" , RUELLAN Herve Subject: Re: [Webpush] Non-blocking comments on -05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 07:01:24 -0000 Hi all, First, I'd like to echo Peter's "thank you". I'm very grateful for all = your work in putting this standard together and marshaling feedback, = here and on GitHub! In addition to the comments from Peter, JR, and = Herv=E9, I have a few questions and suggestions. None of them block the = WGLC. In section 4.1, I'm not clear what "unable to receive push messages that = are aggregated for the lifetime of the subscription" means. If the UA is = forwarding requests, could it still disaggregate messages sent to a = subscription set before delivering them to the other clients? In section 5.1... * It might help to include the `Link: ; = rel=3D"urn:ietf:params:push:receipt"` header in the `POST` example. The = prose suggests a symmetry with subscription sets, but I was confused how = the app server specifies the receipt subscription URL on the first = reading. * I agree with Peter that clarifying whether receipts are sent for TTL=3D0= messages would be nice. * Does it make sense for the push server to use a 400-class status code = in a receipt to report a nack? For example, if the UA failed to decrypt = the message, or the app threw an exception. IIUC, the spec allows 204 = for successful deliveries and 410 for expired messages, but it's not = clear if the PS can send other statuses in receipts. * I'm also curious to hear implementer feedback about receipts in = general. In section 5.4... * Could we restrict the `Topic` grammar to just `token`? ISTM base64url = already fits this definition. * If the replaced and new message specify TTLs, and the new TTL is = shorter...does it just replace the old TTL? (This is implied by "the = information that is stored for the push message is updated", as well as = the restriction that the response TTL must be <=3D request TTL, but I = wanted to double-check). In section 6, are non-zero `wait` values allowed? (I'm assuming not, = since the UA can disconnect at any time). In section 6.2... * Is there a way for the push server to indicate to the UA how long it's = willing to wait for acks before re-delivering? (For instance, so that = the UA can batch acks for a burst of incoming messages. Or does this not = make sense with H2?) * Can a UA "nack" a message, or would this be implementation-specific? = (Related to my note above about reporting nacks to the AS in the receipt = subscription). In section 7.2, could we consider allowing push servers to reject = messages < 4k? If the PS is proxying the message to a third-party = server, which Mozilla's server does on iOS and Android, it might not be = able to control the size limit. In section 7.3.1, if the UA deletes a subscription that belongs to a = subscription set, does it receive a 410 for the deleted subscription on = the subscription set stream? Cheers, - kit From nobody Thu Jun 2 01:04:41 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 944F312D0F5 for ; Thu, 2 Jun 2016 01:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vMwr_6ZLkhL for ; Thu, 2 Jun 2016 01:04:37 -0700 (PDT) Received: from inari-msr.crf.canon.fr (inari-msr.crf.canon.fr [194.2.158.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5492C12D12A for ; Thu, 2 Jun 2016 01:04:34 -0700 (PDT) Received: from mir-msr.corp.crf.canon.fr (mir-msr.corp.crf.canon.fr [172.19.77.98]) by inari-msr.crf.canon.fr (8.13.8/8.13.8) with ESMTP id u5284WxW013237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jun 2016 10:04:32 +0200 Received: from Antiope.crf.canon.fr (antiope.fesl2.crf.canon.fr [172.19.70.56]) by mir-msr.corp.crf.canon.fr (8.13.8/8.13.8) with ESMTP id u5284VVi000850; Thu, 2 Jun 2016 10:04:31 +0200 Received: from Antiope.crf.canon.fr (172.19.70.62) by Antiope.crf.canon.fr (172.19.70.62) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 2 Jun 2016 10:04:31 +0200 Received: from Antiope.crf.canon.fr ([fe80::5c25:f890:ae73:d15a]) by Antiope.crf.canon.fr ([fe80::5c25:f890:ae73:d15a%12]) with mapi id 15.00.0995.032; Thu, 2 Jun 2016 10:04:31 +0200 From: RUELLAN Herve To: "martin.thomson@gmail.com" Thread-Topic: [Webpush] Non-blocking comments on -05 Thread-Index: AQHRu3RPtv1gb54CNUWyRYz7Gkh/JZ/UfYOQgADSzoCAAGICAA== Date: Thu, 2 Jun 2016 08:04:30 +0000 Message-ID: <1464854666.5342.6.camel@crf.canon.fr> References: <6af49c2baf1b4e4f884b812d573b947e@Antiope.crf.canon.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Evolution 3.12.11 (3.12.11-1.fc21) x-originating-ip: [172.20.5.129] Content-Type: text/plain; charset="utf-8" Content-ID: <9A86621614E27C46BDE5911E699109B8@crf.canon.fr> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "webpush@ietf.org" , "beverloo@google.com" Subject: Re: [Webpush] Non-blocking comments on -05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 08:04:39 -0000 T24gV2VkLCAyMDE2LTA2LTAxIGF0IDIzOjM0ICswMDAwLCBCcmlhbiBSYXltb3Igd3JvdGU6DQo+ IDIuIFdoYXQgZG9lcyBhIHB1c2ggc2VydmVyIHRoYXQgcmVjZWl2ZXMgYSByZXF1ZXN0IGZvciBh IHB1c2ggbWVzc2FnZQ0Kd2l0aCAiUHJlZmVyOiByZXNwb25kLWFzeW5jIg0KPiA+IGJ1dCBkb2Vz bid0IHdhbnQgdG8gcHJvdmlkZSBhIHJlY2VpcHQgc3Vic2NyaXB0aW9uLCBvciBkb2Vzbid0DQpz dXBwb3J0IHByb3ZpZGluZyByZWNlaXB0cz8gSXMgdGhpcyBhbGxvd2VkIGluIHRoZSBmaXJzdCBw bGFjZT8NCj4gDQo+IFRoZSBwdXNoIHNlcnZpY2UgaXMgcmVxdWlyZWQgdG8gc3VwcG9ydCByZWNl aXB0IHN1YnNjcmlwdGlvbnMuIA0KPiANCj4gICAgVGhlIHB1c2ggc2VydmljZSBNVVNUIGFsc28g cHJvdmlkZSBhIFVSSSBmb3IgdGhlIHJlY2VpcHQgDQo+ICAgICBzdWJzY3JpcHRpb24gcmVzb3Vy Y2UgaW4gYSBsaW5rIHJlbGF0aW9uIG9mIHR5cGUgDQo+ICAgInVybjppZXRmOnBhcmFtczpwdXNo OnJlY2VpcHQiLiANCj4gDQoNClRoaXMgc2VudGVuY2UgY291bGQgYmUgaW50ZXJwcmV0ZWQgZWl0 aGVyIGFzIG1ha2luZyBzdXBwb3J0IGZvciByZWNlaXB0DQpzdWJzY3JpcHRpb25zIG1hbmRhdG9y eSBvciBhcyBiZWluZyBhIG1hbmRhdG9yeSBwYXJ0IG9mIHRoZSAyMDINCihBY2NlcHRlZCkgcmVz cG9uc2UsIGltcGx5aW5nIHRoYXQgdGhlIHB1c2ggc2VydmljZSBjYW4gYWxzbyByZXNwb25kDQp3 aXRoIGEgMjAxIChDcmVhdGVkKSBldmVuIHdoZW4gdGhlIFByZWZlciBoZWFkZXIgZmllbGQgaXMg cHJlc2VudC4NCg0KT24gVGh1LCAyMDE2LTA2LTAyIGF0IDEyOjEzICsxMDAwLCBNYXJ0aW4gVGhv bXNvbiB3cm90ZToNCj4gT24gMSBKdW5lIDIwMTYgYXQgMjE6NDYsIFJVRUxMQU4gSGVydmUgPEhl cnZlLlJ1ZWxsYW5AY3JmLmNhbm9uLmZyPiB3cm90ZToNCj4gPiAyLiBXaGF0IGRvZXMgYSBwdXNo IHNlcnZlciB0aGF0IHJlY2VpdmVzIGEgcmVxdWVzdCBmb3IgYSBwdXNoIG1lc3NhZ2Ugd2l0aCAi UHJlZmVyOiByZXNwb25kLWFzeW5jIiBidXQgZG9lc24ndCB3YW50IHRvIHByb3ZpZGUgYSByZWNl aXB0IHN1YnNjcmlwdGlvbiwgb3IgZG9lc24ndCBzdXBwb3J0IHByb3ZpZGluZyByZWNlaXB0cz8g SXMgdGhpcyBhbGxvd2VkIGluIHRoZSBmaXJzdCBwbGFjZT8NCj4gDQo+IFRoaXMgaXMgaGFuZGxl ZCBpbiBSRkM3MjQwLiAgSXQgaWdub3JlcyB0aGUgUHJlZmVyIGhlYWRlci4gIEkgYmVsaWV2ZQ0K PiB0aGF0IGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBkbyB0aGlzIHZlcnkgd2VsbCA6KQ0KDQpB cyB0d28gYXV0aG9ycyBvZiB0aGUgc3BlYyBoYXZlIGRpdmVyZ2VudCBvcGluaW9ucywgSSB0aGlu ayB0aGF0IGEgY2xlYXINCnN0YXRlbWVudCB3b3VsZCBiZSBoZWxwZnVsIDstKS4NCkkndmUgY3Jl YXRlZCBhIHB1bGwgcmVxdWVzdCBzdGF0aW5nIHRoYXQgc3VwcG9ydCBmb3IgcHVzaCByZWNlaXB0 cyBpcw0Kbm90IG1hbmRhdG9yeSwgYnV0IEkndmUgbm90IHN0cm9uZyBvcGluaW9uIG9uIHRoZSBz dWJqZWN0Lg0KDQpodHRwczovL2dpdGh1Yi5jb20vd2VicHVzaC13Zy93ZWJwdXNoLXByb3RvY29s L3B1bGwvOTUNCg0KSGVydsOpDQo= From nobody Thu Jun 2 02:09:43 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1DA12D67A for ; Thu, 2 Jun 2016 02:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIBMbLZ0aWEB for ; Thu, 2 Jun 2016 02:09:39 -0700 (PDT) Received: from inari-msr.crf.canon.fr (inari-msr.crf.canon.fr [194.2.158.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5633F12D5DD for ; Thu, 2 Jun 2016 02:09:39 -0700 (PDT) Received: from mir-bsr.corp.crf.canon.fr (mir-bsr.corp.crf.canon.fr [172.19.77.99]) by inari-msr.crf.canon.fr (8.13.8/8.13.8) with ESMTP id u5299aVe018073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jun 2016 11:09:36 +0200 Received: from Antiope.crf.canon.fr (antiope.fesl2.crf.canon.fr [172.19.70.56]) by mir-bsr.corp.crf.canon.fr (8.13.8/8.13.8) with ESMTP id u5299a5Q001167; Thu, 2 Jun 2016 11:09:36 +0200 Received: from Antiope.crf.canon.fr (172.19.70.56) by Antiope.crf.canon.fr (172.19.70.56) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 2 Jun 2016 11:09:35 +0200 Received: from Antiope.crf.canon.fr ([fe80::5c25:f890:ae73:d15a]) by Antiope.crf.canon.fr ([fe80::5c25:f890:ae73:d15a%12]) with mapi id 15.00.0995.032; Thu, 2 Jun 2016 11:09:35 +0200 From: RUELLAN Herve To: "kcambridge@mozilla.com" Thread-Topic: [Webpush] Non-blocking comments on -05 Thread-Index: AQHRu3RPtv1gb54CNUWyRYz7Gkh/JZ/UfYOQgADSzoCAAFBvAIAAI8UA Date: Thu, 2 Jun 2016 09:09:35 +0000 Message-ID: <1464858574.5342.12.camel@crf.canon.fr> References: <6af49c2baf1b4e4f884b812d573b947e@Antiope.crf.canon.fr> <989D9268-BE9A-47F7-9181-C0F323D1DA1F@mozilla.com> In-Reply-To: <989D9268-BE9A-47F7-9181-C0F323D1DA1F@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Evolution 3.12.11 (3.12.11-1.fc21) x-originating-ip: [172.20.5.129] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Brian.Raymor@microsoft.com" , "martin.thomson@gmail.com" , "webpush@ietf.org" , "beverloo@google.com" Subject: Re: [Webpush] Non-blocking comments on -05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 09:09:41 -0000 SGkgS2l0LA0KDQpPbiBUaHUsIDIwMTYtMDYtMDIgYXQgMDA6MDEgLTA3MDAsIEtpdCBDYW1icmlk Z2Ugd3JvdGU6DQo+IEhpIGFsbCwNCj4gDQo+IEZpcnN0LCBJJ2QgbGlrZSB0byBlY2hvIFBldGVy J3MgInRoYW5rIHlvdSIuIEknbSB2ZXJ5IGdyYXRlZnVsIGZvciBhbGwgeW91ciB3b3JrIGluIHB1 dHRpbmcgdGhpcyBzdGFuZGFyZCB0b2dldGhlciBhbmQgbWFyc2hhbGluZyBmZWVkYmFjaywgaGVy ZSBhbmQgb24gR2l0SHViISBJbiBhZGRpdGlvbiB0byB0aGUgY29tbWVudHMgZnJvbSBQZXRlciwg SlIsIGFuZCBIZXJ2w6ksIEkgaGF2ZSBhIGZldyBxdWVzdGlvbnMgYW5kIHN1Z2dlc3Rpb25zLiBO b25lIG9mIHRoZW0gYmxvY2sgdGhlIFdHTEMuDQo+IA0KPiBJbiBzZWN0aW9uIDQuMSwgSSdtIG5v dCBjbGVhciB3aGF0ICJ1bmFibGUgdG8gcmVjZWl2ZSBwdXNoIG1lc3NhZ2VzIHRoYXQgYXJlIGFn Z3JlZ2F0ZWQgZm9yIHRoZSBsaWZldGltZSBvZiB0aGUgc3Vic2NyaXB0aW9uIiBtZWFucy4gSWYg dGhlIFVBIGlzIGZvcndhcmRpbmcgcmVxdWVzdHMsIGNvdWxkIGl0IHN0aWxsIGRpc2FnZ3JlZ2F0 ZSBtZXNzYWdlcyBzZW50IHRvIGEgc3Vic2NyaXB0aW9uIHNldCBiZWZvcmUgZGVsaXZlcmluZyB0 aGVtIHRvIHRoZSBvdGhlciBjbGllbnRzPw0KPiANCg0KVGhlIHVzZSBjYXNlIGhlcmUgaXMgdGhh dCB0aGUgdXNlciBhZ2VudCBpcyBhY3RpbmcgYXMgYSBwcm94eSBmb3INCmFub3RoZXIgY2xpZW50 IGZvciBtb25pdG9yaW5nIGEgc3Vic2NyaXB0aW9uLiBUaGlzIGNhbiBiZSBmb3IgZXhhbXBsZSBh DQpjYW1lcmEgdXNpbmcgYSBtb2JpbGUgcGhvbmUgdG8gbW9uaXRvciBpdHMgc3Vic2NyaXB0aW9u LiBUaGUNCnN1YnNjcmlwdGlvbiBzaG91bGQgYmUgbGlua2VkIHRvIHRoZSBjbGllbnQgYW5kIG5v dCB0aGUgdXNlciBhZ2VudCB0bw0KYWxsb3cgdGhlIGNsaWVudCB0byB1c2UgYW5vdGhlciB1c2Vy IGFnZW50IGFzIGEgcHJveHkgd2l0aG91dCBjaGFuZ2luZw0KdGhlIHN1YnNjcmlwdGlvbi4NCg0K SSBqdXN0IGNyZWF0ZWQgYSBwdWxsIHJlcXVlc3QgZm9yIHRyeWluZyB0byBtYWtlIHRoaXMgdXNl IGNhc2UgY2xlYXJlcjoNCmh0dHBzOi8vZ2l0aHViLmNvbS93ZWJwdXNoLXdnL3dlYnB1c2gtcHJv dG9jb2wvcHVsbC85Ng0KDQpDaGVlcnMsDQoNCkhlcnbDqQ0K From nobody Thu Jun 2 05:13:45 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96A9C12D6C7 for ; Thu, 2 Jun 2016 05:13:44 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyFF-G1jieMi for ; Thu, 2 Jun 2016 05:13:42 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 B04FD12D6C3 for ; Thu, 2 Jun 2016 05:13:42 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id z123so49439038itg.0 for ; Thu, 02 Jun 2016 05:13:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PoeRB3PeHBaVeU6aSUVy5sMuz1RtYWuXAa5gIZGOs2s=; b=RiN6QDQgPZdt8tHDXKL6rd7uQgZjZ/o/hF+EsyPm1aKMmp1AAsnh9n9bB2GhdA6B6m FT22XkLkwG8P/zN6k3sapGciwdA8H9WTMk2qllqS0dp+NMs2tjM+mEtRsG+AtPc8qEnM /NkCZ7Z23JxfuGhE1ViuVacpX4cGemajuE7aUtK+5Z0PdPCSUJJOwJtz037bth0nNMg2 Q57RWlzoSwzE4b4DYX7AJlPNQvOjw0NAM9QYr69SnDBj9fyPyIbTK/WZL+4/Fq69/psF tAOOPXBc7/DG76kJ8t8YUQczI972JrtMaebCedhXRfpQAf81NBUv7qYJDAaiUBAAobSQ mbXA== 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; bh=PoeRB3PeHBaVeU6aSUVy5sMuz1RtYWuXAa5gIZGOs2s=; b=CMuajsqJHKrFmUP9eHjkvNrLJYUBeuo0lnDJQbzPQmJJeRSjUkKzTikOdRDmQmwRdj q3C6liOmzdg7avs6vb/I2wGTBz0vdkRnX314kLl09BG8w+Za2/2QQl/59+RNWMtEAAgS c7r08uqL4yg5TxpIH4KSWxVlaRIwugSOeH5HPK8jKxBB6uotff7+lF7RoB1GXNy5OLGq DwWty6iCn6n1gf86BdyC4foqyxC3QSUwe03V54zD2c1amWl7v+S07FW3UuJSV4hEqrbh KOOYZQduhXeR+0qdXIuIYCOywMT8ZYHsXPvnfZSM6rA6+vDD5udC0QBCVRrcvAe7mCOD f8yw== X-Gm-Message-State: ALyK8tKnN5hWx6Hbl/vfWvWYARwvVHyH0vta9RvFEDBpsBYNxlIBsNlkRHILlqRNXuHEDiIZKsG36ZumYAkKfg== X-Received: by 10.36.94.68 with SMTP id h65mr3173822itb.45.1464869622035; Thu, 02 Jun 2016 05:13:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.43.197 with HTTP; Thu, 2 Jun 2016 05:13:02 -0700 (PDT) In-Reply-To: References: From: Idel Pivnitskiy Date: Thu, 2 Jun 2016 15:13:02 +0300 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11448a9676bf3c05344a8953 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Proposal: different push message resource URIs for AS and UA X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 12:13:44 -0000 --001a11448a9676bf3c05344a8953 Content-Type: text/plain; charset=UTF-8 > > If the AS wants to abandon a push message, this gives it a way. > It's not clear in the draft. Also here is no clarification about how acks should be implemented. Some implementations, for example, might ignore (or respond with a error) DELETE /d/... requests for push messages which aren't sent to the UA yet. Looks like a hack and will not work with each implementation. The other feature that a single URI provides is the fact that UA and > AS can agree about the identity of a push message if that is ever > needed. (We don't expose this in the push API, so it's not useful in > that context, of course.) In most cases receiving receipt is enough for AS. I can't imagine situation when I need identity exact push message, if AS has already received delivery receipt. In any case, identification of push messages requires additional communications between UA and AS, which increase power consumption. It a little bit mismatches with the goal of the draft. But ok, if we want to keep this feature, we may describe that the first (or last) n symbols of a push message resource should be identical for AS and UA. But the whole URI must be different. Just to prevent unexpected behaviour and completely delineate the opportunities of AS and UA. Best regards, Idel Pivnitskiy -- Twitter: @idelpivnitskiy GitHub: @idelpivnitskiy On Thu, Jun 2, 2016 at 5:11 AM, Martin Thomson wrote: > On 2 June 2016 at 05:51, Idel Pivnitskiy > wrote: > > It gets ability for an AS to send DELETE request to this URI. > Consequently, > > it may cause acknowledgement for a PS and sending a push message delivery > > receipt to the AS. > > I think that this is a feature, not a bug. If the AS wants to abandon > a push message, this gives it a way. > > The other feature that a single URI provides is the fact that UA and > AS can agree about the identity of a push message if that is ever > needed. (We don't expose this in the push API, so it's not useful in > that context, of course.) > --001a11448a9676bf3c05344a8953 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=C2=A0If= the AS wants to abandon=C2=A0a pus= h message, this gives it a way.

It= 9;s not clear in the draft. Also here is no clarification about how acks sh= ould be implemented. Some implementations, for example, might ignore (or re= spond with a error) DELETE /d/... requests for push messages which aren'= ;t sent to the UA yet. Looks like a hack and will not work with each implem= entation.

The other feature that a single URI provides is the fact that UA and
AS can = agree about the identity of a push message if that is ever
needed.=C2=A0 (We do= n't expose this in the push API, so it's not useful in
that context, of = course.)

In most cases receiving rec= eipt is enough for AS. I can't imagine situation when I need identity e= xact push message, if AS has already received delivery receipt. In any case= , identification of push messages requires additional communications betwee= n UA and AS, which increase power consumption. It a little bit mismatches w= ith the goal of the draft.
But ok, if we want to keep this featur= e, we may describe that the first (or last) n symbols of=C2=A0a push messag= e resource should be identical for AS and UA. But the whole URI must be dif= ferent. Just to prevent unexpected behaviour and=C2=A0completely delineate = the opportunities of AS and UA.

Best regards,
Idel Pivnitskiy
--
GitHub:=C2=A0@idelpivnitskiy
<= /div>

On Thu, Jun 2, 2016 at 5:11 AM, Martin Thoms= on <martin.thomson@gmail.com> wrote:
On 2 June 2016 at 05:51, Idel Pivnitskiy <idel.pivnitskiy@gmail.com> wro= te:
> It gets ability for an AS to send DELETE request to this URI. Conseque= ntly,
> it may cause acknowledgement for a PS and sending a push message deliv= ery
> receipt to the AS.

I think that this is a feature, not a bug.=C2=A0 If the AS wants to = abandon
a push message, this gives it a way.

The other feature that a single URI provides is the fact that UA and
AS can agree about the identity of a push message if that is ever
needed.=C2=A0 (We don't expose this in the push API, so it's not us= eful in
that context, of course.)

--001a11448a9676bf3c05344a8953-- From nobody Thu Jun 2 05:33:02 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9147512D135 for ; Thu, 2 Jun 2016 05:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmuLozkHdHD9 for ; Thu, 2 Jun 2016 05:32:59 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1802B12D187 for ; Thu, 2 Jun 2016 05:32:59 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id p194so44765667iod.1 for ; Thu, 02 Jun 2016 05:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=4rFf0NXJGwjYrkkxThGs1Ey1MmG0a20pVG5PeWbi27c=; b=HmtTCfQLrsTAXDzUCrJjkN0Jtzd/UrjQHolH0UI/kacOOZvoU45fZgvCogGciyYzXr UFxb0j/+ZejajE+cEkWeTqA3Ekuj7XRrebiAcF3vZ4BLkfgM3sN7OZn4lhs1iGeDrs6j PY6Prw54gj0mNbwOIpPx5x+EM9IPFploB4QNKDKmVpZnrxCfn0E6qkLYqhXZwbNQPTSh KYAIwANpc2EYEoQ0pveRoYdHtsYvS/N+m3Api859pvuljb1d0SueyKznX9gq7/W+gDXm bPyJfzWsmF+BKdVwmzcZmdMO9laWzy8+5YI4sbYgobRltI8ti/Ql68Vhy7k++lxj5JSl LciA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=4rFf0NXJGwjYrkkxThGs1Ey1MmG0a20pVG5PeWbi27c=; b=Kpajl4oDwUsAB2sFINe06zo3LnV3NVdv8waZjCN+5yQ0+gJitmr05VL7al6ndLwkaa ZTeu5kNq0LhV4aW4o04LG0Cn2vYpvflPQojKYzb7EsR1b9wtjAi03Dkk4FFvyh6xJPjM bq2qA/Azv2QkgCA8C6JK+oNYzWtC129ClQ8S00PdojMk2r37E2OQof6rc1l77VW2v/Ar WRAZRl0vVhQsHdOvRPR3tpw9Zk9B3tBaHHqq210iDpVrzEjuDzaQywVYDOeEXfjevql2 /1jVYXnD74D3oqwF5VuDcXzubodpQmHDWKNV6Ido+87N0Vr/wGGPb+RG+ymzYjwxz1K7 s/QA== X-Gm-Message-State: ALyK8tL4p2jTY2/VmYY6cKJX4PF3mM4X+HEt6lWth2ZvNQuU4LYIj7gaYxJ6ynUKUFO42L9thL7fBiyOW/rXJA== X-Received: by 10.107.31.13 with SMTP id f13mr2814615iof.180.1464870778461; Thu, 02 Jun 2016 05:32:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.43.197 with HTTP; Thu, 2 Jun 2016 05:32:19 -0700 (PDT) From: Idel Pivnitskiy Date: Thu, 2 Jun 2016 15:32:19 +0300 Message-ID: To: webpush@ietf.org Content-Type: multipart/alternative; boundary=001a1141bbd464638205344acec1 Archived-At: Subject: [Webpush] Replace term 'Application server' X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 12:33:01 -0000 --001a1141bbd464638205344acec1 Content-Type: text/plain; charset=UTF-8 Hi all, Agree with Peter, that server side is not needed for communication: Nothing precludes an application from not needing a server side at all. I > don't think we should change the term, but perhaps we can consider > slightly rephrasing the definition as: > > "The component of an application that *usually* runs on a server and > requests the delivery of a push message." > Relevant commit: https://github.com/webpush-wg/webpush-protocol/pull/90/commits/e0222007081cbf4c96e7c285d54154840d374b6d According to the rapid growth of IoT devices, WebPush protocol could get a popularity for power efficient M2M communications. In this case would be better not to fix client-server architecture/terms and use something like sender/receiver (or something similar) instead of AS/UA. Best regards, Idel Pivnitskiy -- Twitter: @idelpivnitskiy GitHub: @idelpivnitskiy --001a1141bbd464638205344acec1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

Agree with Peter, th= at server side is not needed for communication:

Nothing precludes an application = from not needing a server side at all. I
don't think we should change the term, but perhaps we can consider
slightly rephrasing the definition as:<= /div>

"The component of an application that *usually* runs on a server a= nd
requests the delivery of a push mes= sage."

Relevant commit:=C2=A0https://github.com/webpush-wg/webpush= -protocol/pull/90/commits/e0222007081cbf4c96e7c285d54154840d374b6d

According to the rapid growth of IoT devices, WebPush = protocol could get a popularity for power efficient M2M communications. In = this case would be better not to fix client-server architecture/terms and u= se something like sender/receiver (or something similar) instead of AS/UA.<= /div>

Best regards,
Idel Pivnitskiy
= --
GitHub:=C2=A0@idelpivnitskiy
--001a1141bbd464638205344acec1-- From nobody Thu Jun 2 08:40:36 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E55012D592 for ; Thu, 2 Jun 2016 08:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgj1X8i18MTH for ; Thu, 2 Jun 2016 08:40:31 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5735012D1EA for ; Thu, 2 Jun 2016 08:40:31 -0700 (PDT) Received: by mail-pa0-x232.google.com with SMTP id te7so3305469pab.3 for ; Thu, 02 Jun 2016 08:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=d8cqrrsA9FMNWH0rFsZ+0mnxH6L2jRsAS/e5U3KbRC4=; b=qph64vLxwgw2zG764rzZEDttpSDxmTjJ8BqhdHWQX6Xi3oulK61VqjCusgj2vQJdWi koOItosfnJb7qCNWN+vF9cEkw7WG3s1v3CLj3qcZZ0UxkspsbmlqygI/VyvUOpgGyzjm tdWbA32d0wanhTLQqLc50u9/D4o8HFEqkMd9QJT0Vjjg0Fu1PMVWWRScKlRE1qXlfjFS KYFHymgSM8pJbGe40uOQUqCJZGD0GaneaV5EC29zmMz+/ntQGd6h0unJHNgcu1XULSX7 2cNKSMowqcmkwvKtkCQyx4yaGD0WTW6YZvnzUUrzGnaqFWgag35OsKbFt1FSPgQKnM85 vyoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=d8cqrrsA9FMNWH0rFsZ+0mnxH6L2jRsAS/e5U3KbRC4=; b=GnQHiFen7fhYFB2LkjMLVaI7uA9btybaSZ8+0azbrhBcIvIbbvXMNGHozrawtrkul/ wMmVT60Mbjt6gtBhSAAm74RJm7eSTdU1yaJiKO1Rm8N++ZOpVE/Krw9h82SU2bJs8o7B 5dSPl95VncJHUr0aLNwoARevsIyYpZVsL+2NxZFVeWVhVTT9u0XGM8OZCe9hhOqxFufN SFxbvJroarCHBbAvQhHAJ2Lffj4UeLa/2cyWqMXcbq1tx8tr/SQNbDj3qWbTqkZzpJi9 IB5c7MtJhDl/uU2aMkOGubXbWaiuqqMTMvmjQwqX3ZmREWin/+2FR6ehKeX7JFPhcvCk UnSQ== X-Gm-Message-State: ALyK8tJEbc9Fja+nodksfeHzgGNyEgcqS45ghB8k4ectObKlgoagu3pLyQdT+Fdp2Q3wmB3PIxhP/bXWIIFe7Q== X-Received: by 10.66.237.69 with SMTP id va5mr6449985pac.49.1464882030934; Thu, 02 Jun 2016 08:40:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Costin Manolache Date: Thu, 02 Jun 2016 15:40:21 +0000 Message-ID: To: Idel Pivnitskiy , webpush@ietf.org Content-Type: multipart/alternative; boundary=001a113808bc17807505344d6d5d Archived-At: Subject: Re: [Webpush] Replace term 'Application server' X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 15:40:34 -0000 --001a113808bc17807505344d6d5d Content-Type: text/plain; charset=UTF-8 M2M is a bit more complicated due to authentication and secrecy of push endpoint. Some PS will require senders to authenticate with VAPID - while others will rely only on the fact that AS can keep the push endpoint secret. In M2M it is very hard to keep the endpoints and authenticator secret - and impossible to keep the sender private key secret. However it is possible to extend the protocol for M2M, with a future draft - there are several ways. The cleanest change (IMHO) is to relax the requirement of a single subscription per service worker - in a M2M case there are multiple senders, and each will need either a different endpoint/keys ( sharing the authenticator and encryption keys among multiple devices defeats their purpose ), and each sender will have a separate VAPID key that will need to be authorized. There are other options as well, but I think it is cleaner to handle this in a separate document. Costin On Thu, Jun 2, 2016 at 5:33 AM Idel Pivnitskiy wrote: > Hi all, > > Agree with Peter, that server side is not needed for communication: > > Nothing precludes an application from not needing a server side at all. I >> don't think we should change the term, but perhaps we can consider >> slightly rephrasing the definition as: >> >> "The component of an application that *usually* runs on a server and >> requests the delivery of a push message." >> > > Relevant commit: > https://github.com/webpush-wg/webpush-protocol/pull/90/commits/e0222007081cbf4c96e7c285d54154840d374b6d > > According to the rapid growth of IoT devices, WebPush protocol could get a > popularity for power efficient M2M communications. In this case would be > better not to fix client-server architecture/terms and use something like > sender/receiver (or something similar) instead of AS/UA. > > Best regards, > Idel Pivnitskiy > -- > Twitter: @idelpivnitskiy > GitHub: @idelpivnitskiy > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > --001a113808bc17807505344d6d5d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
M2M is a bit more complicated due to authentication and se= crecy of push endpoint.

Some PS will require senders to = authenticate with VAPID - while others will rely only on the=C2=A0
fact that AS can keep the push endpoint secret. In M2M it is very hard to= keep the=C2=A0
endpoints and authenticator secret - and impossib= le to keep the sender private key secret.=C2=A0

Ho= wever it is possible to extend the protocol for M2M, with a future draft - = there=C2=A0
are several ways. The cleanest change (IMHO) is to re= lax the requirement of a single
subscription per service worker -= in a M2M case there are multiple senders, and=C2=A0
each will ne= ed either a different endpoint/keys ( sharing the authenticator and encrypt= ion
keys among multiple devices defeats their purpose ), and each= sender will have a separate
VAPID key that will need to be autho= rized.=C2=A0There are other options as well= , but I think it=C2=A0
is = cleaner to handle this in a separate document.

= Costin=C2=A0

<= div class=3D"gmail_quote">
On Thu, Jun 2, 2016 at 5:33 AM I= del Pivnitskiy <idel.pivnit= skiy@gmail.com> wrote:
Hi all,

Agree with Peter, that se= rver side is not needed for communication:

Nothing precludes an application from = not needing a server side at all. I
do= n't think we should change the term, but perhaps we can consider
<= div style=3D"font-size:12.8px">slightly rephrasing the definition as:
=

&= quot;The component of an application that *usually* runs on a server and
requests the delivery of a push message.= "


According to the rapid growth of IoT dev= ices, WebPush protocol could get a popularity for power efficient M2M commu= nications. In this case would be better not to fix client-server architectu= re/terms and use something like sender/receiver (or something similar) inst= ead of AS/UA.

Best regards,
Idel Pivnitskiy
--
=
GitHub:=C2=A0@idelpivnitskiy
_______________________________________________
Webpush mailing list
Webpush@ietf.org<= br> https://www.ietf.org/mailman/listinfo/webpush
--001a113808bc17807505344d6d5d-- From nobody Thu Jun 2 14:56:46 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5140B12D8CE for ; Thu, 2 Jun 2016 14:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10WGo_LphiRC for ; Thu, 2 Jun 2016 14:56:43 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF94512D8C9 for ; Thu, 2 Jun 2016 14:56:42 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id t40so59116887ioi.0 for ; Thu, 02 Jun 2016 14:56:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JaU35OjaMIoXskaIoIfmMrl53OhqPcq60XLI4+vy3bA=; b=XDJ8XQrCM5k7LrUbKc1i0+DUmQleEb4ace6Fe7SK+xJb1x/aNhAMYoUCf+awK8a97Y rNl1DToooxPE+Q0W2XmlnHhluL2ajjKWll+iOFZ5v2AiePrtLRGcHGnEU8PROIezxDCA 7uf/l6wWJBAes/7mKDGbth7VykvfYhpbwsJRmOe84wbzDd60A+87GO7Zu1mtF1oBU61Z BZryYdVCblFk0hAkPL74rli2ANaAN8bHc7ntTGWAIig036eAuHdn0KkimnCYvHHnoAER cv1hrWIygXykfejZaDb+4v2vD2XcEYRLUq8ufaqEOPKIwD1Fk/zVtnt0tFdGr3tN0Yj2 JsFA== 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; bh=JaU35OjaMIoXskaIoIfmMrl53OhqPcq60XLI4+vy3bA=; b=KtSlhUwb5osfg+pLnVHxVwAw79J7X1+R+3nGuOrBE9IKjnYVzcllhfbJhWR59dWSzF +UdmdN5hJpcOoASJHRtobO9mx/avg/a1OMLV7DYGXgxnPpLJlimjFQc/1WXswlhwSBKT tpVI2L+eFKy9lXmtqCEX4AIbQypl3YOpoI3ReUzPwFGaqbHWvq/YKAOjDD9a4eRGOcHw dwkdnPMKi+n5n12KefAzGlqbw5xgu23Iow81ByuNbd/A/+ffrvy3Lf5kLzJihqQqLPt/ HCeqj7XgqiRN1y3vkPBX5MHAPZhhRzmlWJWNTZ727Uy7RA0rG02Z08RVeSHFk/AzVPck D7hw== X-Gm-Message-State: ALyK8tInykp4l7TgZa+0kxa+9GH63rSF175P7oWWwXvH0w2cKKbNURqGG0WfBvqUfNYwQ+k1A+4Onn93fyb+Qw== X-Received: by 10.107.62.196 with SMTP id l187mr1065304ioa.185.1464904602242; Thu, 02 Jun 2016 14:56:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.43.197 with HTTP; Thu, 2 Jun 2016 14:56:02 -0700 (PDT) In-Reply-To: References: From: Idel Pivnitskiy Date: Fri, 3 Jun 2016 00:56:02 +0300 Message-ID: To: Costin Manolache Content-Type: multipart/alternative; boundary=94eb2c061062726826053452ae6c Archived-At: Cc: webpush@ietf.org Subject: Re: [Webpush] Replace term 'Application server' X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 21:56:45 -0000 --94eb2c061062726826053452ae6c Content-Type: text/plain; charset=UTF-8 Hi Costin, Agree with you. Thanks for the explanation. Idel -- Twitter: @idelpivnitskiy GitHub: @idelpivnitskiy On Thu, Jun 2, 2016 at 6:40 PM, Costin Manolache wrote: > M2M is a bit more complicated due to authentication and secrecy of push > endpoint. > > Some PS will require senders to authenticate with VAPID - while others > will rely only on the > fact that AS can keep the push endpoint secret. In M2M it is very hard to > keep the > endpoints and authenticator secret - and impossible to keep the sender > private key secret. > > However it is possible to extend the protocol for M2M, with a future draft > - there > are several ways. The cleanest change (IMHO) is to relax the requirement > of a single > subscription per service worker - in a M2M case there are multiple > senders, and > each will need either a different endpoint/keys ( sharing the > authenticator and encryption > keys among multiple devices defeats their purpose ), and each sender will > have a separate > VAPID key that will need to be authorized. There are other options as > well, but I think it > is cleaner to handle this in a separate document. > > Costin > > On Thu, Jun 2, 2016 at 5:33 AM Idel Pivnitskiy > wrote: > >> Hi all, >> >> Agree with Peter, that server side is not needed for communication: >> >> Nothing precludes an application from not needing a server side at all. I >>> don't think we should change the term, but perhaps we can consider >>> slightly rephrasing the definition as: >>> >>> "The component of an application that *usually* runs on a server and >>> requests the delivery of a push message." >>> >> >> Relevant commit: >> https://github.com/webpush-wg/webpush-protocol/pull/90/commits/e0222007081cbf4c96e7c285d54154840d374b6d >> >> According to the rapid growth of IoT devices, WebPush protocol could get >> a popularity for power efficient M2M communications. In this case would be >> better not to fix client-server architecture/terms and use something like >> sender/receiver (or something similar) instead of AS/UA. >> >> Best regards, >> Idel Pivnitskiy >> -- >> Twitter: @idelpivnitskiy >> GitHub: @idelpivnitskiy >> _______________________________________________ >> Webpush mailing list >> Webpush@ietf.org >> https://www.ietf.org/mailman/listinfo/webpush >> > --94eb2c061062726826053452ae6c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Costin,

Agree with you. Thanks for t= he explanation.

Idel
<= div dir=3D"ltr">
--
GitHub:=C2= =A0@idelpiv= nitskiy

On Thu, Jun 2, 2016 at 6:40 PM, Costin Manol= ache <costin@gmail.com> wrote:
M2M is a bit more complicated due to authentication an= d secrecy of push endpoint.

Some PS will require senders= to authenticate with VAPID - while others will rely only on the=C2=A0
fact that AS can keep the push endpoint secret. In M2M it is very har= d to keep the=C2=A0
endpoints and authenticator secret - and impo= ssible to keep the sender private key secret.=C2=A0

However it is possible to extend the protocol for M2M, with a future draf= t - there=C2=A0
are several ways. The cleanest change (IMHO) is t= o relax the requirement of a single
subscription per service work= er - in a M2M case there are multiple senders, and=C2=A0
each wil= l need either a different endpoint/keys ( sharing the authenticator and enc= ryption
keys among multiple devices defeats their purpose ), and = each sender will have a separate
VAPID key that will need to be a= uthorized.=C2=A0There are other options as = well, but I think it=C2=A0
is cleaner to handle this in a separate document.

Costin=C2=A0
<= br>
On Th= u, Jun 2, 2016 at 5:33 AM Idel Pivnitskiy <idel.pivnitskiy@gmail.com> wrote:<= br>
=
Hi all,

Agree with Peter, th= at server side is not needed for communication:

Nothing precludes an application = from not needing a server side at all. I
don't think we should change the term, but perhaps we can consider
slightly rephrasing the definition as:<= /div>

"The component of an application that *usually* runs on a server a= nd
requests the delivery of a push mes= sage."


According to the rapid growth of IoT= devices, WebPush protocol could get a popularity for power efficient M2M c= ommunications. In this case would be better not to fix client-server archit= ecture/terms and use something like sender/receiver (or something similar) = instead of AS/UA.

Best regards,
Idel Pivnitskiy
--
GitHub:=C2=A0@idelpivnitskiy
_______________________________________________
Webpush mailing list
Webpush@ietf.org<= br> https://www.ietf.org/mailman/listinfo/webpush

--94eb2c061062726826053452ae6c-- From nobody Thu Jun 2 16:00:17 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8275212D8F5 for ; Thu, 2 Jun 2016 16:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrbKcisgsddQ for ; Thu, 2 Jun 2016 16:00:14 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0139.outbound.protection.outlook.com [65.55.169.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98CA912D0C5 for ; Thu, 2 Jun 2016 16:00:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=aoZ6ZZvjOyzk+R23LMA8pbYpNkFBbNl06P5MrwK+KDY=; b=OAxKp7MHL+FUPAXScb7K7710BcvcRK9RyFMIoBAFg+tLPDiFI2CIl0ndb0Rl52QonQ6i5TsnLm1urjPQExT5vzaIf602NX0IMCD332uhE1nm3O+pvOb4SOPQH3bF5LOme1YQufi4/2ypeEdpOS9FI+VNZgy/nSFdqH7Pwe//+uE= Received: from CO2PR03MB2407.namprd03.prod.outlook.com (10.166.93.137) by CO2PR03MB2405.namprd03.prod.outlook.com (10.166.93.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.506.9; Thu, 2 Jun 2016 23:00:11 +0000 Received: from CO2PR03MB2407.namprd03.prod.outlook.com ([10.166.93.137]) by CO2PR03MB2407.namprd03.prod.outlook.com ([10.166.93.137]) with mapi id 15.01.0506.011; Thu, 2 Jun 2016 23:00:11 +0000 From: Brian Raymor To: Kit Cambridge , Martin Thomson Thread-Topic: [Webpush] Non-blocking comments on -05 Thread-Index: AQHRu3RQwDJq8LaJ6EaFkMQ0Dd4KCZ/Uf30AgADyW4CAAFBvAIABBhjw Date: Thu, 2 Jun 2016 23:00:10 +0000 Message-ID: References: <6af49c2baf1b4e4f884b812d573b947e@Antiope.crf.canon.fr> <989D9268-BE9A-47F7-9181-C0F323D1DA1F@mozilla.com> In-Reply-To: <989D9268-BE9A-47F7-9181-C0F323D1DA1F@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: mozilla.com; dkim=none (message not signed) header.d=none;mozilla.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [24.16.23.27] x-ms-office365-filtering-correlation-id: 7ed567f9-6611-47c2-d293-08d38b39a673 x-microsoft-exchange-diagnostics: 1; CO2PR03MB2405; 5:FCuPaX9WX1JJlWoscWUGC0nFp8/LaiJU8VSXEiriKMRrZx7y8OFKt8KMILeHcuA5Dvr9RLbZ2/re2c6MvBveNt/IrYx5RqUAtfmccGIHH2d68jSR4XAzVLGlvHTx7iY0vAVAWpliS6in3fN+PJH36A==; 24:DOXwG9cGoOSJClq/VRyXC+HD3rfgal8BKzKQGd/8I0JlA7QyPTDRSFCixG1VW7zVHIrSH0TNkrR4jDVjg5W75WARRT5N2kHqZVHkc6MpzK8=; 7:Y16tI6a3ir96uKNoMijBgcx5Sr4kOJh12MkmYasziYAB/kpL/UwcKrQZ7MKir45cOt/+/5FTTH1k/wfPwvarIVU6tzRN/rWBcegnHsBqlxLiUUTbwYfkYAR4apOjccvxpmE8ldrgiB1KwPLe4Imozcr9g42Xww9YLL4VP7FqZayB8Rl04pFrTAsUrJu6db/zNem/LIrMUNYqnK6zS7KXjx0a6AeLWS7+c4Lpw+k5cDc= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR03MB2405; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105)(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CO2PR03MB2405; BCL:0; PCL:0; RULEID:; SRVR:CO2PR03MB2405; x-forefront-prvs: 0961DF5286 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51914003)(377454003)(24454002)(66066001)(50986999)(76576001)(76176999)(3280700002)(54356999)(33656002)(2900100001)(74316001)(9686002)(4326007)(3660700001)(586003)(93886004)(102836003)(6116002)(2906002)(3846002)(2950100001)(5003600100002)(122556002)(10090500001)(5002640100001)(19580395003)(11100500001)(189998001)(81166006)(86362001)(10290500002)(77096005)(15975445007)(8936002)(5008740100001)(8676002)(106116001)(99286002)(5005710100001)(10400500002)(5001770100001)(19580405001)(5004730100002)(87936001)(92566002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR03MB2405; H:CO2PR03MB2407.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jun 2016 23:00:10.8720 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR03MB2405 Archived-At: Cc: Peter Beverloo , "webpush@ietf.org" , RUELLAN Herve Subject: Re: [Webpush] Non-blocking comments on -05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 23:00:16 -0000 Kit - Thanks for the comments. On Thursday, June 2, 2016 12:02 AM, Kit Cambridge = wrote: > Does it make sense for the push server to use a 400-class status code in = a receipt to report a nack? For example, if the UA failed to decrypt the me= ssage, > or the app threw an exception. IIUC, the spec allows 204 for successful d= eliveries and 410 for expired messages, but it's not clear if the PS can se= nd other > statuses in receipts. Earlier, Elio proposed Acknowledgement Data for this scenario - https://git= hub.com/webpush-wg/webpush-protocol/issues/42 & https://github.com/webpush-wg/webpush-protocol/pull/57 - which allows th= e user agent to return opaque data to its application server. This was presented and discussed at IETF 94. It was closed with an agreemen= t to re-open if there was more customer data to justify the use cases: https://datatracker.ietf.org/doc/minutes-94-webpush/ * Discuss use cases for PR #57 and account for the results in a future upd= ate From nobody Thu Jun 2 20:39:40 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FBE212D0FA for ; Thu, 2 Jun 2016 20:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMdRfZBPQMyz for ; Thu, 2 Jun 2016 20:39:33 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0104.outbound.protection.outlook.com [65.55.169.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2964F12D61D for ; Thu, 2 Jun 2016 20:39:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rYGIlP/zi2OcaDgDNia+P4ODCYN/75J2NqjmRalsfxA=; b=QBxqr6z3ZFGfZNKurf+W0kdyGnHMTyHwZCTqotek3CnKzGDT1VX2vZf15RZYpNkLS1gzz1XgVUfpWzWOF5XMNVDZ0Jrn5sKqrj6Qvo9IuecsD8oxOOmBhqalxDo8/nPAADtmUgAIVZZ3mLiknTC7YDIYoxJcDNehacw1Mlqr1og= Received: from CO2PR03MB2407.namprd03.prod.outlook.com (10.166.93.137) by CO2PR03MB2405.namprd03.prod.outlook.com (10.166.93.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.506.9; Fri, 3 Jun 2016 03:39:30 +0000 Received: from CO2PR03MB2407.namprd03.prod.outlook.com ([10.166.93.137]) by CO2PR03MB2407.namprd03.prod.outlook.com ([10.166.93.137]) with mapi id 15.01.0506.011; Fri, 3 Jun 2016 03:39:30 +0000 From: Brian Raymor To: Kit Cambridge , Martin Thomson Thread-Topic: [Webpush] Non-blocking comments on -05 Thread-Index: AQHRu3RQwDJq8LaJ6EaFkMQ0Dd4KCZ/Uf30AgADyW4CAAFBvAIABV54Q Date: Fri, 3 Jun 2016 03:39:30 +0000 Message-ID: References: <6af49c2baf1b4e4f884b812d573b947e@Antiope.crf.canon.fr> <989D9268-BE9A-47F7-9181-C0F323D1DA1F@mozilla.com> In-Reply-To: <989D9268-BE9A-47F7-9181-C0F323D1DA1F@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: mozilla.com; dkim=none (message not signed) header.d=none;mozilla.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [24.16.23.27] x-ms-office365-filtering-correlation-id: 44237dac-20e4-4e3e-1cc0-08d38b60abc0 x-microsoft-exchange-diagnostics: 1; CO2PR03MB2405; 5:GxrmvKJ9qagnhXT2PhGoysSkro3tkdHjaQ46HfezpciX3QECI3dx2IRO7Ucz2gcn5NRdfjxiJ2qaGjAqCpMsDoUF7ImjXzXtXpZtkWXRuua+sAMzYr9Ei0afz+xVyvp+L/VXw0kHjfO60V0ZXw3flw==; 24:oUJV78rvQwouob10pyLuF14ooTpTcqj6tL17rVZtUzxUjuVZVZyXx+PsYEwRhyzzMMq1N2flMG7cz872jrXvBxORHrzOkXhiDFYPllAxuEo=; 7:j2rODdAn3CT555LjAUnwpwFvoum/pAWGtz5ql+/SbGCQY6sAtkfgNHG6njzkIJ5drcdc92+tnRtROnDQv4ldbEjGHvyUY1Ks/scTyN5HShBv5VVBvSndQ7gMczZ7ukSF4cfaVPeUywhgx+JcI+r9xUZXvFJIZsb4PGXChlsujDkJ8jxmLgrCMSv/3psNLZu0Q3kZoiNItd3VqUx1VOLI8wxTHlRXFNTPa9pRCSol3yiJxsdAXoL4H7IhdWahHhYx x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR03MB2405; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CO2PR03MB2405; BCL:0; PCL:0; RULEID:; SRVR:CO2PR03MB2405; x-forefront-prvs: 0962D394D2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(66066001)(76576001)(50986999)(3280700002)(54356999)(76176999)(33656002)(2900100001)(74316001)(9686002)(4326007)(3660700001)(586003)(93886004)(6116002)(102836003)(2906002)(3846002)(2950100001)(5003600100002)(122556002)(92566002)(10090500001)(5002640100001)(19580395003)(11100500001)(189998001)(86362001)(81166006)(10290500002)(77096005)(15975445007)(8676002)(8936002)(5008740100001)(5005710100001)(106116001)(99286002)(5004730100002)(10400500002)(5001770100001)(19580405001)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR03MB2405; H:CO2PR03MB2407.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jun 2016 03:39:30.3206 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR03MB2405 Archived-At: Cc: Peter Beverloo , "webpush@ietf.org" , RUELLAN Herve Subject: Re: [Webpush] Non-blocking comments on -05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 03:39:37 -0000 On Thursday, June 2, 2016 12:02 AM, Kit Cambridge = wrote: > In section 4.1, I'm not clear what "unable to receive push messages that = are aggregated for the lifetime of the subscription" means. > If the UA is forwarding requests, could it still disaggregate messages se= nt to a subscription set before delivering them to the other clients? This change was introduced for Canon's scenario - http://www.ietf.org/mail-= archive/web/webpush/current/msg00357.html. Herve has a pending pull request - https://github.com/webpush-wg/webpush-pr= otocol/pull/96 - with editorial updates to 4.1: https://github.com/webpush-wg/webpush-protocol/pull/96/commits/55b6b5efc1= 6ab4db8363770279c87c0412a8cc12=20 Does this offer enough clarification?=20 ...Brian From nobody Thu Jun 2 20:58:57 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3DC12D655 for ; Thu, 2 Jun 2016 20:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.696 X-Spam-Level: X-Spam-Status: No, score=-0.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TRACKER_ID=1.306] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHxUEq7OsB-5 for ; Thu, 2 Jun 2016 20:58:52 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0712.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:712]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7D4912D658 for ; Thu, 2 Jun 2016 20:58:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RmMLI8LdJiH/YnK3a1a48zckr3YzBQovpsJ9ntkFF8M=; b=TRMAGsDMV1gfRh7rQc8a1ycVh8Up54AMI/F/bwaEJzv4F1yFIQcLmR3Qor7DyMBUIwQgEFO8FQtZ1rpsSCEpr8x2EzO0vKJsTLyPnmXoYqnEZOJN+0Hg4x6Y26hIMEcqVxNev534YvHpWPuonXFcG4ZdQHDb8X6pf/f50saiFd8= Received: from CO2PR03MB2407.namprd03.prod.outlook.com (10.166.93.137) by CO2PR03MB2405.namprd03.prod.outlook.com (10.166.93.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.506.9; Fri, 3 Jun 2016 03:58:35 +0000 Received: from CO2PR03MB2407.namprd03.prod.outlook.com ([10.166.93.137]) by CO2PR03MB2407.namprd03.prod.outlook.com ([10.166.93.137]) with mapi id 15.01.0506.011; Fri, 3 Jun 2016 03:58:35 +0000 From: Brian Raymor To: Kit Cambridge , Martin Thomson Thread-Topic: [Webpush] Non-blocking comments on -05 Thread-Index: AQHRu3RQwDJq8LaJ6EaFkMQ0Dd4KCZ/Uf30AgADyW4CAAFBvAIABWfHA Date: Fri, 3 Jun 2016 03:58:35 +0000 Message-ID: References: <6af49c2baf1b4e4f884b812d573b947e@Antiope.crf.canon.fr> <989D9268-BE9A-47F7-9181-C0F323D1DA1F@mozilla.com> In-Reply-To: <989D9268-BE9A-47F7-9181-C0F323D1DA1F@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: mozilla.com; dkim=none (message not signed) header.d=none;mozilla.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [24.16.23.27] x-ms-office365-filtering-correlation-id: 2e91db40-9cc8-4ab9-bcd9-08d38b635660 x-microsoft-exchange-diagnostics: 1; CO2PR03MB2405; 5:oUaZ+OJTymEHhKwxdkQ7/PqH8eSRyaJ+v3+zuhZrd9LcZEjXzxA+d4YNN9/Q3QYfQGIlYwniDcSoJow0FC8njIvkvursXVhch3Z082ygt+vhHk+n0r8NfdrYLCKEGVN57lbQXP9c990kg2khxCQjLg==; 24:K+aoSsC7Hi0H/bbrV+TMc4yhvzYpxcJhZfCgV4FMbcdB72T5j+XxjdYof0biXvQYICakoKO0HI+zuayKrrMWP6O9ZSKHV3qdktZ0m9SP/Go=; 7:JQK2kHtT62VbAQS4w0sX56ss9+EsQyo4BZ052dzIMX+II2myga+nkSOBOPMT455Zazjk7GoDQx3YNemBgY13IoaSsj/lTixagOhGNdsluHuxZC+9pjd/vjW4ueF5MQrFkCwo+xo8YNseE/i6vaQy8QVGlNwZhYXRszbB8RnVikLxB1YS/elOTKcOvfOMVGtyH81zkBw7gA7JNO4gOJ7VhSfPMHvzaGD1bSmVIXQdmN1oQSnXplvSnURh7vahZtjX x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR03MB2405; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CO2PR03MB2405; BCL:0; PCL:0; RULEID:; SRVR:CO2PR03MB2405; x-forefront-prvs: 0962D394D2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(11100500001)(5002640100001)(10090500001)(19580395003)(92566002)(2950100001)(122556002)(5003600100002)(106116001)(5005710100001)(99286002)(8676002)(8936002)(5008740100001)(5004730100002)(10400500002)(87936001)(19580405001)(5001770100001)(10290500002)(86362001)(189998001)(81166006)(575784001)(77096005)(15975445007)(76176999)(33656002)(54356999)(66066001)(3280700002)(50986999)(76576001)(6116002)(102836003)(93886004)(2906002)(3846002)(4326007)(9686002)(2900100001)(74316001)(586003)(3660700001)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR03MB2405; H:CO2PR03MB2407.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jun 2016 03:58:35.4075 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR03MB2405 Archived-At: Cc: Peter Beverloo , "webpush@ietf.org" , RUELLAN Herve Subject: Re: [Webpush] Non-blocking comments on -05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 03:58:54 -0000 On Thursday, June 2, 2016 12:02 AM, Kit Cambridge = wrote: > In section 5.1... > * It might help to include the `Link: ; = rel=3D"urn:ietf:params:push:receipt"` header in the `POST` example. > The prose suggests a symmetry with subscription sets, but I was confused = how the app server specifies the receipt subscription URL on the first read= ing. To be clear, you're requesting a new example for subsequent POSTS that pass= the push:receipt which would be similar to the example for subscription se= ts in section 4.1.1? Something like: For subsequent receipt requests to the same origin [RFC6454], the application server SHOULD include the returned receipt subscription in a link relation of type "urn:ietf:params:push:receipt". This gives the push service an option to aggregate the receipts. POST /push/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1 Host: push.example.net Prefer: respond-async Link: ; rel=3D"urn:ietf:params:push:receipt" TTL: 15 Content-Type: text/plain;charset=3Dutf8 Content-Length: 36 iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB The push service SHOULD return the same receipt subscription in its respons= e, although it MAY return a new receipt subscription if it is unable to reuse the one provided by the application server. HTTP/1.1 202 Accepted Date: Thu, 11 Dec 2014 24:56:55 GMT Link: ; rel=3D"urn:ietf:params:push:receipt" Location: https://push.example.net/message/xDIYHNcfAIPP_5ITvURr-d6BGt > * I agree with Peter that clarifying whether receipts are sent for TTL=3D= 0 messages would be nice. See the discussion in https://github.com/webpush-wg/webpush-protocol/pull/9= 1 We've iterated on zero TTL quite a bit. Do you have any suggestions on how = to further clarify: A Push message with a zero TTL is immediately delivered if the user agent is available to receive the message. After delivery, the push service is permitted to immediately remove a push message with a zero TTL. This might occur before the user agent acknowledges receipt of the message by performing a HTTP DELETE on the push message resource. Consequently, an application server cannot rely on receiving acknowledgement receipts for zero TTL push messages. From nobody Thu Jun 2 21:07:56 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 552EF12D15C for ; Thu, 2 Jun 2016 21:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUf_aVPuZULF for ; Thu, 2 Jun 2016 21:07:53 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0129.outbound.protection.outlook.com [65.55.169.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EED6512D11F for ; Thu, 2 Jun 2016 21:07:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=blH+CBdxcESgHEgYz9f3utoVwLLe+eSiz4dABXIu8qA=; b=leTz/vkp3cCFmHwHQ1kqM4/wuS37QbzzVr7t8+rLhoJAca1de9OcZhkUt4pScQQISw1mdXwcoim7WO1UpizIlS8o+VfMW+9aENQINCyML2eG6+18BN0MEqU1YMoSDF6J5L4MmINZ7hfu84PowpHwkOUwPYyqQbOH+2kzWQ6ZL90= Received: from CO2PR03MB2407.namprd03.prod.outlook.com (10.166.93.137) by CO2PR03MB2405.namprd03.prod.outlook.com (10.166.93.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.506.9; Fri, 3 Jun 2016 04:07:51 +0000 Received: from CO2PR03MB2407.namprd03.prod.outlook.com ([10.166.93.137]) by CO2PR03MB2407.namprd03.prod.outlook.com ([10.166.93.137]) with mapi id 15.01.0506.011; Fri, 3 Jun 2016 04:07:51 +0000 From: Brian Raymor To: RUELLAN Herve , "martin.thomson@gmail.com" Thread-Topic: [Webpush] Non-blocking comments on -05 Thread-Index: AQHRu3RQwDJq8LaJ6EaFkMQ0Dd4KCZ/Uf30AgADyW4CAAGIGAIABTcpw Date: Fri, 3 Jun 2016 04:07:51 +0000 Message-ID: References: <6af49c2baf1b4e4f884b812d573b947e@Antiope.crf.canon.fr> <1464854666.5342.6.camel@crf.canon.fr> In-Reply-To: <1464854666.5342.6.camel@crf.canon.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: crf.canon.fr; dkim=none (message not signed) header.d=none; crf.canon.fr; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [24.16.23.27] x-ms-office365-filtering-correlation-id: 288cf00a-3fa6-4074-e234-08d38b64a187 x-microsoft-exchange-diagnostics: 1; CO2PR03MB2405; 5:0MsFkpFB68QVUkLHdPvS9E2hMSKTAT8khCFaV3Ra4baxUvfoD8U0qQDosBNB97sSnEzztTb8S/Uty+Sv+ovTldBYUG9/6ANk7zRrlHcKZO8pIk9pomEH/JLm13x2L91rSh0hyPuZLgcUndz8Y3nkYQ==; 24:w7fW3UCSQTTFIAM5JrUUydncdUZj8fCtHm8lGB7Ua1S2O0aNwvW6dLb3bZyySdxegw3ZoEQkzm4jUtwnSC3j83xzY5JUPHCC8lRhQOhBymQ=; 7:V5YyKGy6yAdaQ6AuqAVZMIeawu87sq3JZF1kiUfGNAovDQyFHqViGSjfEBLO0PzNuJ1IpOGAsv/E1AsF+I5Feq7UVmO9BvRmNj+eNVQXwv2b1naepjr9Orc9TLnlXaMsx6anq0A3iCAwVovHLq/XwTY/qmaJcQ1ykQsXeNaa64BqX566eOaC7ga1FI91GcKfXjfk6CJo1AmkIK4eLpeQVW0+4wveo1ghM8FzIQkYFf1YSmnoca7+l39a/asEgfmo x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR03MB2405; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CO2PR03MB2405; BCL:0; PCL:0; RULEID:; SRVR:CO2PR03MB2405; x-forefront-prvs: 0962D394D2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51444003)(377424004)(13464003)(377454003)(24454002)(66066001)(76576001)(50986999)(3280700002)(54356999)(76176999)(33656002)(2501003)(2900100001)(74316001)(9686002)(4326007)(3660700001)(586003)(6116002)(93886004)(102836003)(2906002)(3846002)(2950100001)(5003600100002)(122556002)(92566002)(5002640100001)(10090500001)(19580395003)(11100500001)(189998001)(86362001)(81166006)(10290500002)(77096005)(15975445007)(8936002)(5008740100001)(8676002)(5005710100001)(106116001)(99286002)(5004730100002)(10400500002)(5001770100001)(87936001)(19580405001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR03MB2405; H:CO2PR03MB2407.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jun 2016 04:07:51.0368 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR03MB2405 Archived-At: Cc: "webpush@ietf.org" , "beverloo@google.com" Subject: Re: [Webpush] Non-blocking comments on -05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 04:07:55 -0000 DQpQbGVhc2Ugc2VlIG15IGNvbW1lbnRzIGluICBodHRwczovL2dpdGh1Yi5jb20vd2VicHVzaC13 Zy93ZWJwdXNoLXByb3RvY29sL3B1bGwvOTUgYW5kDQpodHRwczovL2dpdGh1Yi5jb20vd2VicHVz aC13Zy93ZWJwdXNoLXByb3RvY29sL3B1bGwvOTcgLSB3aGljaCBhcmUgYm90aCBub3cgY2xvc2Vk Lg0KDQpXZSBhZ3JlZWQgdGhhdCByZWNlaXB0cyAib24gZGVtYW5kIiB3ZXJlIHJlcXVpcmVkIHNv bWUgdGltZSBhZ28uIEkgY2FuIGNlcnRhaW5seSB0aWdodGVuIHVwIHRoZSBsYW5ndWFnZSB0bw0K cmVtb3ZlIGFueSBhbWJpZ3VpdHkgaW50cm9kdWNlZCBieSB0aGUgdXNlIG9mIFByZWZlcjogdG8g c2ltcGxpZnkgdGhlIGZsb3cuIFRoZXJlIHdhcyBuZXZlcg0KYW4gaW50ZW50aW9uIG9yIHJlbGF0 ZWQgZGlzY3Vzc2lvbiB0byBtYWtlIHRoaXMgZmVhdHVyZSBvcHRpb25hbC4gDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBXZWJwdXNoIFttYWlsdG86d2VicHVzaC1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUlVFTExBTiBIZXJ2ZQ0KU2VudDogVGh1cnNkYXksIEp1 bmUgMiwgMjAxNiAxOjA1IEFNDQpUbzogbWFydGluLnRob21zb25AZ21haWwuY29tDQpDYzogd2Vi cHVzaEBpZXRmLm9yZzsgYmV2ZXJsb29AZ29vZ2xlLmNvbQ0KU3ViamVjdDogUmU6IFtXZWJwdXNo XSBOb24tYmxvY2tpbmcgY29tbWVudHMgb24gLTA1DQoNCk9uIFdlZCwgMjAxNi0wNi0wMSBhdCAy MzozNCArMDAwMCwgQnJpYW4gUmF5bW9yIHdyb3RlOg0KPiAyLiBXaGF0IGRvZXMgYSBwdXNoIHNl cnZlciB0aGF0IHJlY2VpdmVzIGEgcmVxdWVzdCBmb3IgYSBwdXNoIG1lc3NhZ2UNCndpdGggIlBy ZWZlcjogcmVzcG9uZC1hc3luYyINCj4gPiBidXQgZG9lc24ndCB3YW50IHRvIHByb3ZpZGUgYSBy ZWNlaXB0IHN1YnNjcmlwdGlvbiwgb3IgZG9lc24ndA0Kc3VwcG9ydCBwcm92aWRpbmcgcmVjZWlw dHM/IElzIHRoaXMgYWxsb3dlZCBpbiB0aGUgZmlyc3QgcGxhY2U/DQo+IA0KPiBUaGUgcHVzaCBz ZXJ2aWNlIGlzIHJlcXVpcmVkIHRvIHN1cHBvcnQgcmVjZWlwdCBzdWJzY3JpcHRpb25zLiANCj4g DQo+ICAgIFRoZSBwdXNoIHNlcnZpY2UgTVVTVCBhbHNvIHByb3ZpZGUgYSBVUkkgZm9yIHRoZSBy ZWNlaXB0IA0KPiAgICAgc3Vic2NyaXB0aW9uIHJlc291cmNlIGluIGEgbGluayByZWxhdGlvbiBv ZiB0eXBlIA0KPiAgICJ1cm46aWV0ZjpwYXJhbXM6cHVzaDpyZWNlaXB0Ii4gDQo+IA0KDQpUaGlz IHNlbnRlbmNlIGNvdWxkIGJlIGludGVycHJldGVkIGVpdGhlciBhcyBtYWtpbmcgc3VwcG9ydCBm b3IgcmVjZWlwdA0Kc3Vic2NyaXB0aW9ucyBtYW5kYXRvcnkgb3IgYXMgYmVpbmcgYSBtYW5kYXRv cnkgcGFydCBvZiB0aGUgMjAyDQooQWNjZXB0ZWQpIHJlc3BvbnNlLCBpbXBseWluZyB0aGF0IHRo ZSBwdXNoIHNlcnZpY2UgY2FuIGFsc28gcmVzcG9uZA0Kd2l0aCBhIDIwMSAoQ3JlYXRlZCkgZXZl biB3aGVuIHRoZSBQcmVmZXIgaGVhZGVyIGZpZWxkIGlzIHByZXNlbnQuDQoNCk9uIFRodSwgMjAx Ni0wNi0wMiBhdCAxMjoxMyArMTAwMCwgTWFydGluIFRob21zb24gd3JvdGU6DQo+IE9uIDEgSnVu ZSAyMDE2IGF0IDIxOjQ2LCBSVUVMTEFOIEhlcnZlIDxIZXJ2ZS5SdWVsbGFuQGNyZi5jYW5vbi5m cj4gd3JvdGU6DQo+ID4gMi4gV2hhdCBkb2VzIGEgcHVzaCBzZXJ2ZXIgdGhhdCByZWNlaXZlcyBh IHJlcXVlc3QgZm9yIGEgcHVzaCBtZXNzYWdlIHdpdGggIlByZWZlcjogcmVzcG9uZC1hc3luYyIg YnV0IGRvZXNuJ3Qgd2FudCB0byBwcm92aWRlIGEgcmVjZWlwdCBzdWJzY3JpcHRpb24sIG9yIGRv ZXNuJ3Qgc3VwcG9ydCBwcm92aWRpbmcgcmVjZWlwdHM/IElzIHRoaXMgYWxsb3dlZCBpbiB0aGUg Zmlyc3QgcGxhY2U/DQo+IA0KPiBUaGlzIGlzIGhhbmRsZWQgaW4gUkZDNzI0MC4gIEl0IGlnbm9y ZXMgdGhlIFByZWZlciBoZWFkZXIuICBJIGJlbGlldmUNCj4gdGhhdCBleGlzdGluZyBpbXBsZW1l bnRhdGlvbnMgZG8gdGhpcyB2ZXJ5IHdlbGwgOikNCg0KQXMgdHdvIGF1dGhvcnMgb2YgdGhlIHNw ZWMgaGF2ZSBkaXZlcmdlbnQgb3BpbmlvbnMsIEkgdGhpbmsgdGhhdCBhIGNsZWFyDQpzdGF0ZW1l bnQgd291bGQgYmUgaGVscGZ1bCA7LSkuDQpJJ3ZlIGNyZWF0ZWQgYSBwdWxsIHJlcXVlc3Qgc3Rh dGluZyB0aGF0IHN1cHBvcnQgZm9yIHB1c2ggcmVjZWlwdHMgaXMNCm5vdCBtYW5kYXRvcnksIGJ1 dCBJJ3ZlIG5vdCBzdHJvbmcgb3BpbmlvbiBvbiB0aGUgc3ViamVjdC4NCg0KaHR0cHM6Ly9naXRo dWIuY29tL3dlYnB1c2gtd2cvd2VicHVzaC1wcm90b2NvbC9wdWxsLzk1DQoNCkhlcnbDqQ0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCldlYnB1c2ggbWFp bGluZyBsaXN0DQpXZWJwdXNoQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3dlYnB1c2gNCg== From nobody Fri Jun 3 00:02:01 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C0B12D0D8 for ; Fri, 3 Jun 2016 00:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iE-mrpghq5Tt for ; Fri, 3 Jun 2016 00:01:58 -0700 (PDT) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81C6312D141 for ; Fri, 3 Jun 2016 00:01:51 -0700 (PDT) Received: by mail-qg0-x232.google.com with SMTP id p34so7670717qgp.1 for ; Fri, 03 Jun 2016 00:01:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=SN+1W8xgawrYXIMcjJ8RTnr40VsAT6AjEO1vzIsg140=; b=cK/iHUYmZ5kuwTIrDHwCYwTpIEAExFR1U9Qv484f9gCdqSvKqZZLjiKHZLd0mfclqn OPvYd8CnANYV+FEPnAFmB3L6grXrXfYvTm/1kSVMAiB/0GgmAETV8fDhmhuP3wXfg9Db jeGhCP4AhGznjV5X65RB2qwoyJCnZfpS7AjgImTv6n7XdMwIxMBdeDS2byR20BrkOXCm AzjxRoTWXmwP0W6TubCrbCx2sbECsZUaEYIRKgcJ26rpeFyMLxKQ3jig1hfbfgzH4drs UVB8jODVjT2edwwhipycmUeqQ4IqSazEP0UsKKOi+SjLuzyjNpny+N1cx9348eovSslF zvIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=SN+1W8xgawrYXIMcjJ8RTnr40VsAT6AjEO1vzIsg140=; b=RyeCHbkFGSD/oREwmY2A4f/ces9chiBCR78yTF8oHqC7DgvVSEsZ8nY9R06Z03BSzU 3veJQeFtJwrKWvgc4IVmazo78dYmQPu/8igULa7cVz6SEB/nUQaCnflFQ8cOz8h7h/S4 zqVWiO89yV6Gr2mhCna+gRiWKvgWYq94fsfIy/dRacR+xzqmN+u2yABn7GpmWMoHyqp7 0npfQLN+6JIlGmhQr9xSMw9D06GBIoIHbGl7pchkDg6cAzoSHQNsWT/BSSKVNjiDHWqI 903rpkLPhhtDCqWOgX+FNjeFkrX90oxVweIgUP7Lm4YY13LY6w184OsJSwZUpfTeFbn9 BYfA== X-Gm-Message-State: ALyK8tK2Vk6orZSVfrtKmJdTQhSKgKCUc9Do4wZ7B+tfTspE6Nt5LcJdRVngay8pu/O463Gxl25SLoqOetp3xw== X-Received: by 10.140.38.145 with SMTP id t17mr1787680qgt.10.1464937310631; Fri, 03 Jun 2016 00:01:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.38.242 with HTTP; Fri, 3 Jun 2016 00:01:49 -0700 (PDT) From: Martin Thomson Date: Fri, 3 Jun 2016 17:01:49 +1000 Message-ID: To: "webpush@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Webpush] #101 Topic -> token X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 07:02:00 -0000 Kit said: > * Could we restrict the `Topic` grammar to just `token`? ISTM base64url already fits this definition. https://github.com/webpush-wg/webpush-protocol/pull/101 Assuming that there are no objections, I think that this is a good simplification. We currently accept quoted-string, but that's an annoying thing to handle. From nobody Fri Jun 3 00:24:04 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7667B12D55D for ; Fri, 3 Jun 2016 00:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVFdciLltomY for ; Fri, 3 Jun 2016 00:24:01 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::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 3CB1D12D16D for ; Fri, 3 Jun 2016 00:24:01 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id s186so17993795qkc.1 for ; Fri, 03 Jun 2016 00:24:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=DThUumACbc4vetbk8+6KFrO8BhHXNwofBbWpFpZoUkc=; b=dcbdQ3+mRTZKsBE7WLhpNOjFxnNl8bINbqNoQy6FaceRgHot9eyTCaiBgct9VnFd8p Uo9KWTozEBnkXe1XrAtmVSWL2GAHGeGaplClDbEFaCUjq7I8WVWO/kQaJXDzA2b+rnBv +Ozt7n3EUWQMBVkXo2j9rZopwIzvKp1pknob/Wg0FKuhfDMYxbFncOINusx440YC8JfZ aMybGAsTXAFlmuVI4FgNqDFn6fwCtoHdSPZ0LcX6NxJ5N3elhx+3COP7DDoF60GeHENO 0rbMHXkuHgxDCpQuZnAJZ9hd0ntYRHbVsMHpzjp8NlU2zd9eR/DAssJ8MOdpCtFprxJX RPUg== 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-transfer-encoding; bh=DThUumACbc4vetbk8+6KFrO8BhHXNwofBbWpFpZoUkc=; b=bfULwnZRrHfbYjEB25qOranmqKpPZdVkLNEg3goPoUJpuBZ5kVy2ffwTJKEMRLCpf/ lc1e4zB0vXNmpaUaOnWsCIpOMXT5tXJFojb6rXVfhEyQUWQsGDQiqMEKW5fgteh7ls6Q v9PlBH5t9TtCHrC70tN7zmEd/WCiioOPakZxPYtIA1rSpWMzxR/Tb7gb7NjFgWVkMvVX ydaEua0kglc+U4pC3tolsx59o9YBXvYTfUXhH6LYaDIiW8v2MRnzxnqXIRPPNcIqH8fN ByIhHrskn+FZahc0Yel39Jx16NYgSAV5a1VlZPNfadPo3xol+u7dpVIvGKSwxRZ4g5em lf6Q== X-Gm-Message-State: ALyK8tL9Lw66C4vmhgP0Aq7sKnZsEaRiQP7QfrL+u93n4zHHYPmuPpx650fO6iBOpRP3SFtuhszG53fw2EdCqA== X-Received: by 10.55.135.7 with SMTP id j7mr1851641qkd.32.1464938640356; Fri, 03 Jun 2016 00:24:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.104.110 with HTTP; Fri, 3 Jun 2016 00:23:59 -0700 (PDT) In-Reply-To: <989D9268-BE9A-47F7-9181-C0F323D1DA1F@mozilla.com> References: <6af49c2baf1b4e4f884b812d573b947e@Antiope.crf.canon.fr> <989D9268-BE9A-47F7-9181-C0F323D1DA1F@mozilla.com> From: Martin Thomson Date: Fri, 3 Jun 2016 17:23:59 +1000 Message-ID: To: Kit Cambridge Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Brian Raymor , Peter Beverloo , "webpush@ietf.org" , RUELLAN Herve Subject: Re: [Webpush] Non-blocking comments on -05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 07:24:03 -0000 I don't think that Brian addressed these already... On 2 June 2016 at 17:01, Kit Cambridge wrote: > * If the replaced and new message specify TTLs, and the new TTL is shorte= r...does it just replace the old TTL? (This is implied by "the information = that is stored for the push message is updated", as well as the restriction= that the response TTL must be <=3D request TTL, but I wanted to double-che= ck). Yes, let's be explicit though: https://github.com/webpush-wg/webpush-protocol/pull/102 I've also changed from MAY to SHOULD for suppressing delivery receipts on replacement. There is a race condition, otherwise I would say MUST. > In section 6, are non-zero `wait` values allowed? (I'm assuming not, sinc= e the UA can disconnect at any time). The 0 value is special in that it is required. Other values are up to the push service to decide on what to do, though it does give a client some control over liveness without having to initiate PING frames. Do you think we need text about non-zero values? Respecting Prefer is generally discretionary, and I'd like to keep it that way. > * Is there a way for the push server to indicate to the UA how long it's = willing to wait for acks before re-delivering? (For instance, so that the U= A can batch acks for a burst of incoming messages. Or does this not make se= nse with H2?) You mean like Retry-After? There isn't really anything like that. > In section 7.2, could we consider allowing push servers to reject message= s < 4k? If the PS is proxying the message to a third-party server, which Mo= zilla's server does on iOS and Android, it might not be able to control the= size limit. The point of having this value is that it's a low limit and application servers can rely on that many octets being available. I hate to suggest it, because it's disgusting to implement, but if you are sending messages to iOS devices, maybe you need to consider split-and-merge. From nobody Fri Jun 3 00:24:34 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7CD12D164 for ; Fri, 3 Jun 2016 00:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5zlGVzPKjtR for ; Fri, 3 Jun 2016 00:24:31 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D39E12D16D for ; Fri, 3 Jun 2016 00:24:31 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id n63so50512543qkf.0 for ; Fri, 03 Jun 2016 00:24:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=9Y1o4nvm/Ucd4AFbgHKuPoxQFsttC/lblpoS13iPqbk=; b=WulwnDd4mB7zL/E60TfFisCAuHxJZCMPFdZke1Gs3ZbPMajfCZDCxjr8H5PNWZyZlw tiFMHv/kBgpN4Q4yYSQwrVfH6ziYm+Xbc/gW2h1QSDXzWzW6XQay2gbgxflHLBufJKOk 5T1i3/T6xwmOnu2pVs54sqttxUe+pkeQbeeI10Fa42bXS+hL9b3AjqI+s1bbNRR2BF7v Y0N2hDuNSSz9C36LNdToadHR5EVTUWmIl7trtuN0MSQYzk3TUokeyHltooaXn85uWMn2 ea+Aj0D+0wZrGVLsba8sXw/vTeiNulTd1/EY7xwYB+JYPpTUmWKow16NYnVR4FcPnMkZ Pn/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=9Y1o4nvm/Ucd4AFbgHKuPoxQFsttC/lblpoS13iPqbk=; b=B64yByfMUWdE7Tbtmw6ISwS8bVE+8vN8aJtuPSQywbVhmPO/cNf8crDInSbLTSNfSN HqIDguq6OOQ65ljf1aKOlXebOjHE6MqsNG+9wnB/DWe9n1X/qDNC+akwLpx1EpV8107E n+TadSs4wZRkw5xGytqjNNDBSFLVlxeH4VuJEifclGmijrRcYAkcCYvXCPKkoy7vG2gk +rP7it0PoRRgSTR3QxwW88K3LhxR4WP24LxxJZ2v+d5FLFDKF2jV+igwf1y1d4PwPq2T lIIrMAirFmY+SqiBOYoglPlrjGnvIUfIpAxqEs1DKxsLl5dC33avTKIVgtIs2CUMcYh5 9cFg== X-Gm-Message-State: ALyK8tKSHqgGAj7b/u7NT1HzfRgNRrdg1igc/qDBG93gLlY3xZQIpRX1rmqvznTH/OAZ17GTDnqOxF8TOjLCGw== X-Received: by 10.55.20.208 with SMTP id 77mr1832120qku.124.1464938670409; Fri, 03 Jun 2016 00:24:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.104.110 with HTTP; Fri, 3 Jun 2016 00:24:30 -0700 (PDT) From: Martin Thomson Date: Fri, 3 Jun 2016 17:24:30 +1000 Message-ID: To: "webpush@ietf.org" , Kit Cambridge Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Webpush] Deleting a subscription X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 07:24:33 -0000 Kit said: > In section 7.3.1, if the UA deletes a subscription that belongs to a subscription set, does it receive a 410 for the deleted subscription on the subscription set stream? We haven't defined any way to learn about changes to subscriptions. Since the UA is the one doing the deletion, I think that it shouldn't need notification of it. How about this: https://github.com/webpush-wg/webpush-protocol/pull/103 From nobody Fri Jun 3 07:39:35 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2472812D1B1 for ; Fri, 3 Jun 2016 07:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKZhO31rtdMx for ; Fri, 3 Jun 2016 07:39:30 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E55C812D6C1 for ; Fri, 3 Jun 2016 07:39:29 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id 62so44385604pfd.1 for ; Fri, 03 Jun 2016 07:39:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gckSzB1QaXBPzJKXbco9zn8Tt+v8q+b+ihIHpoakyWo=; b=qog2TKjNDzF+hIz3L2QbokQ6ozypWGCzI5heDOmWdSUJu+Kf1k5HyTipB2m05viQpe rV6Nl127XmEUb2RFQjZN4+ZI4LFca98WIELw8GLw9E1PGYH4ub0+YK9P4xF1Ea22IVce k14n9j8RUuEYpPObH47eaA+KPuiCcWScF2Dezz+3bNAYh9vAW0HiUDX2y72LAlzSZQEh WevjjX+E7FEN4UzrLjMcwaxT3WO4ZOFHt+iV+Axz6lkrmosW7bdLlwtFasmKTa2nPS2V i+83Y8+NIhrG24wpWNQw61P7EZztCVbkTyWB1iO0bwwOIvtaEiI0kSaAsVX9A4FNIk0W gjVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gckSzB1QaXBPzJKXbco9zn8Tt+v8q+b+ihIHpoakyWo=; b=gmME+w6VCKa9CHg/xXWmk7sJQsshEfSwETU5EH1ypb0d0XJ1omLvfNNZM27P2BSetY 6c6aYyBV050hchX+DgwuUcfLNQbZYviSJgU45nB5PK5fcmqCyQz8EBy1WAO3/wdhRdbg b24khwivnTm10bCOevjMY2Tb1UORKZDf3126MXpKGGOaz6crf2pjxk91Wr5LAegYwkER RpLMo0RPhOJHjUIbdvTVbs5dcJ2xM1S3C+GABy2ISuwXbouiL/RRR0ru2Tx9rQNlJUgG YcFJkOheHqcTYT18If3doiNIFoU3/v/Vt6BjfAjv5aSz7aCst9Sh37ry9qQWLX6/vnxf sQ3g== X-Gm-Message-State: ALyK8tJsrAfW4U4Wg9QYKARPM81sYgcXBN9HaXZ8b3fm3wN2/im74LGTenn7WFrt4c1rZUeLrj3aGzvZUx7vaA== X-Received: by 10.98.28.74 with SMTP id c71mr6545710pfc.131.1464964769493; Fri, 03 Jun 2016 07:39:29 -0700 (PDT) MIME-Version: 1.0 References: <6af49c2baf1b4e4f884b812d573b947e@Antiope.crf.canon.fr> <989D9268-BE9A-47F7-9181-C0F323D1DA1F@mozilla.com> <1464858574.5342.12.camel@crf.canon.fr> In-Reply-To: <1464858574.5342.12.camel@crf.canon.fr> From: Costin Manolache Date: Fri, 03 Jun 2016 14:39:19 +0000 Message-ID: To: RUELLAN Herve , "kcambridge@mozilla.com" Content-Type: multipart/alternative; boundary=94eb2c11179ab1b7de053460b0ec Archived-At: Cc: "Brian.Raymor@microsoft.com" , "martin.thomson@gmail.com" , "webpush@ietf.org" , "beverloo@google.com" Subject: Re: [Webpush] Non-blocking comments on -05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 14:39:32 -0000 --94eb2c11179ab1b7de053460b0ec Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jun 2, 2016 at 2:09 AM RUELLAN Herve wrote: > Hi Kit, > > On Thu, 2016-06-02 at 00:01 -0700, Kit Cambridge wrote: > > Hi all, > > > > First, I'd like to echo Peter's "thank you". I'm very grateful for all > your work in putting this standard together and marshaling feedback, here > and on GitHub! In addition to the comments from Peter, JR, and Herv=C3=A9= , I > have a few questions and suggestions. None of them block the WGLC. > > > > In section 4.1, I'm not clear what "unable to receive push messages tha= t > are aggregated for the lifetime of the subscription" means. If the UA is > forwarding requests, could it still disaggregate messages sent to a > subscription set before delivering them to the other clients? > > > > The use case here is that the user agent is acting as a proxy for > another client for monitoring a subscription. This can be for example a > camera using a mobile phone to monitor its subscription. The > subscription should be linked to the client and not the user agent to > allow the client to use another user agent as a proxy without changing > the subscription. > > I just created a pull request for trying to make this use case clearer: > https://github.com/webpush-wg/webpush-protocol/pull/96 > > I'm not very comfortable to adding features at this point - proxy mode and migrating subscription sets have quite a few implementation implications. I think it's a useful feature and use case - but it is very tricky. We can discuss it in separate thread. In particular the AS proxy is very unlikely to work with authentication. Costin > Cheers, > > Herv=C3=A9 > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > --94eb2c11179ab1b7de053460b0ec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Ju= n 2, 2016 at 2:09 AM RUELLAN Herve <Herve.Ruellan@crf.canon.fr> wrote:
Hi Kit,

On Thu, 2016-06-02 at 00:01 -0700, Kit Cambridge wrote:
> Hi all,
>
> First, I'd like to echo Peter's "thank you". I'm= very grateful for all your work in putting this standard together and mars= haling feedback, here and on GitHub! In addition to the comments from Peter= , JR, and Herv=C3=A9, I have a few questions and suggestions. None of them = block the WGLC.
>
> In section 4.1, I'm not clear what "unable to receive push me= ssages that are aggregated for the lifetime of the subscription" means= . If the UA is forwarding requests, could it still disaggregate messages se= nt to a subscription set before delivering them to the other clients?
>

The use case here is that the user agent is acting as a proxy for
another client for monitoring a subscription. This can be for example a
camera using a mobile phone to monitor its subscription. The
subscription should be linked to the client and not the user agent to
allow the client to use another user agent as a proxy without changing
the subscription.

I just created a pull request for trying to make this use case clearer:
https://github.com/webpush-wg/webpush-protocol= /pull/96


I'm not very comfortable to adding= features at this point - proxy mode and migrating=C2=A0
subscrip= tion sets have quite a few implementation implications. I think it's a = useful
feature and use case - but it is very tricky. We can discu= ss it in separate thread.

In particular the AS pro= xy is very unlikely to work with authentication.

C= ostin


=C2=A0
Cheers,

Herv=C3=A9
_______________________________________________
Webpush mailing list
Webpush@ietf.org<= br> https://www.ietf.org/mailman/listinfo/webpush
--94eb2c11179ab1b7de053460b0ec-- From nobody Fri Jun 3 07:56:52 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6813912D1E7 for ; Fri, 3 Jun 2016 07:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZrPMIBuzr0W for ; Fri, 3 Jun 2016 07:56:41 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::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 2913112D6A9 for ; Fri, 3 Jun 2016 07:56:35 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id b124so44522723pfb.0 for ; Fri, 03 Jun 2016 07:56:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=q3ejmLFDPMA+nnfHFbvPpqVnD0osHFC0u9LCW+DBT7Y=; b=jwjxF4+1nKrgDB0priklaZcLtGx/1ssWAlUjd8RyWnQduIMWbFeKteP7HaS0gwP6hG qmdWNNaxEwIj+szKmYQsCeH9/TiGUSydUoDvlZAB16VoHBtFpayijeTBt5M1uBHOYXhl 51/v6CxKwfE4LJ5H573rkSvMXorHodlXv2yNvlwHG3g53Lzik0Pco8FZNAZ1nwbPzNL/ XKyYV0rMaBCpu0eg/5p84JOWBw2BASWGTPlB++VzoPc5ck5U+0Nc+5Osvlk7qyCZBiQl n2ospRwdxr/pz68tGEtvcgoEuzKDLfM6OvF5hWCRDQNdmxRATdVxA1a+ZRBRYgvexIxS OpRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=q3ejmLFDPMA+nnfHFbvPpqVnD0osHFC0u9LCW+DBT7Y=; b=V+HLM1ZoHTw4ZFFNsRnnLbpz6dxp430TAAXhWdsiD73Z0rXoRZUmn/mSe/EXiyugoB +dU/I/urtlUo8afBMJA8xadZScT2VU8FJhUXJ9By0v27M7m+AC/zzH3X9Vk21cIQIw5y UKWbHHQNsRUJIvZ0QAyG4BhocrnAuYQsd1QK3zGY+o+JXmtc0Ei9+cgwXDXngZpXCGM7 w4tb7/Fh46Pl3UuDRZyI8Hwkfddw9mMjlRKXw1s3VgiBqn+eCrHPY4a5+//LEeB22bFQ NSgVeGkMng2sM6w5vE5yZZPsDxZt1GtwoFwcv9cwiqwEzojbiIAOQaIT8YZTzCqBgszh yIUw== X-Gm-Message-State: ALyK8tIgTWKWB7cqni+JKnlO0tvMiWOCbLtTIB2jLqZdZ41HQi05ThWgJ0yQ4cihqFYcL6ERT3ZlyPZGjVpArQ== X-Received: by 10.98.85.66 with SMTP id j63mr6566998pfb.90.1464965794677; Fri, 03 Jun 2016 07:56:34 -0700 (PDT) MIME-Version: 1.0 References: <6af49c2baf1b4e4f884b812d573b947e@Antiope.crf.canon.fr> <989D9268-BE9A-47F7-9181-C0F323D1DA1F@mozilla.com> In-Reply-To: <989D9268-BE9A-47F7-9181-C0F323D1DA1F@mozilla.com> From: Costin Manolache Date: Fri, 03 Jun 2016 14:56:25 +0000 Message-ID: To: Kit Cambridge , Martin Thomson Content-Type: multipart/alternative; boundary=94eb2c0cdac8ccccbf053460ed4f Archived-At: Cc: Brian Raymor , RUELLAN Herve , "webpush@ietf.org" , Peter Beverloo Subject: Re: [Webpush] Non-blocking comments on -05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 14:56:51 -0000 --94eb2c0cdac8ccccbf053460ed4f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jun 2, 2016 at 12:01 AM Kit Cambridge wrote: > Hi all, > > First, I'd like to echo Peter's "thank you". I'm very grateful for all > your work in putting this standard together and marshaling feedback, here > and on GitHub! In addition to the comments from Peter, JR, and Herv=C3=A9= , I > have a few questions and suggestions. None of them block the WGLC. > > In section 4.1, I'm not clear what "unable to receive push messages that > are aggregated for the lifetime of the subscription" means. If the UA is > forwarding requests, could it still disaggregate messages sent to a > subscription set before delivering them to the other clients? > > In section 5.1... > > * It might help to include the `Link: ; > rel=3D"urn:ietf:params:push:receipt"` header in the `POST` example. The p= rose > suggests a symmetry with subscription sets, but I was confused how the ap= p > server specifies the receipt subscription URL on the first reading. > * I agree with Peter that clarifying whether receipts are sent for TTL=3D= 0 > messages would be nice. > * Does it make sense for the push server to use a 400-class status code i= n > a receipt to report a nack? For example, if the UA failed to decrypt the > message, or the app threw an exception. IIUC, the spec allows 204 for > successful deliveries and 410 for expired messages, but it's not clear if > the PS can send other statuses in receipts. > Would generate too much traffic and load, and would increase the implementation costs. In some cases the messages can be expired by the storage system, in batch - it wouldn't be a problem if 'nack' would be a rare case, but in mobile a very large number of devices ( tablets, etc ) are offline for long time so nack would be very frequent. > > * I'm also curious to hear implementer feedback about receipts in general= . > > > In section 5.4... > > * Could we restrict the `Topic` grammar to just `token`? ISTM base64url > already fits this definition. > * If the replaced and new message specify TTLs, and the new TTL is > shorter...does it just replace the old TTL? (This is implied by "the > information that is stored for the push message is updated", as well as t= he > restriction that the response TTL must be <=3D request TTL, but I wanted = to > double-check). > One thing to keep in mind is that some PS may use nosql and be distributed and use eventual consistency. Messages have a timestamp, so either they will be collapsed, or both will be sent. If the new one has shorter TTL, it may get lost. > > In section 6, are non-zero `wait` values allowed? (I'm assuming not, sinc= e > the UA can disconnect at any time). > > In section 6.2... > > * Is there a way for the push server to indicate to the UA how long it's > willing to wait for acks before re-delivering? (For instance, so that the > UA can batch acks for a burst of incoming messages. Or does this not make > sense with H2?) > Batch acks would be useful, but with resource URL it's trickier. If ACK would be implemented at lower level it may be possible ( i.e. UA would ack the H2 stream IDs of the messages ), but it's an optimization that can be done later. I expect PS will re-deliver on the next connection or monitor request. > * Can a UA "nack" a message, or would this be implementation-specific? > (Related to my note above about reporting nacks to the AS in the receipt > subscription). > It would add costs to the PS, and I don't think it's a common use case. To 'nack', the UA needs to first get the message to know the ID. > > In section 7.2, could we consider allowing push servers to reject message= s > < 4k? If the PS is proxying the message to a third-party server, which > Mozilla's server does on iOS and Android, it might not be able to control > the size limit. > +1 Costin > > In section 7.3.1, if the UA deletes a subscription that belongs to a > subscription set, does it receive a 410 for the deleted subscription on t= he > subscription set stream? > > > Cheers, > - kit > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > --94eb2c0cdac8ccccbf053460ed4f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu= , Jun 2, 2016 at 12:01 AM Kit Cambridge <kcambridge@mozilla.com> wrote:
Hi all,

First, I'd like to echo Peter's "thank you". I'm very= grateful for all your work in putting this standard together and marshalin= g feedback, here and on GitHub! In addition to the comments from Peter, JR,= and Herv=C3=A9, I have a few questions and suggestions. None of them block= the WGLC.

In section 4.1, I'm not clear what "unable to receive push message= s that are aggregated for the lifetime of the subscription" means. If = the UA is forwarding requests, could it still disaggregate messages sent to= a subscription set before delivering them to the other clients?

In section 5.1...

* It might help to include the `Link: </r/3ZtI4YVNBnUUZhuoChl6omUvG4ZM&g= t;; rel=3D"urn:ietf:params:push:receipt"` header in the `POST` ex= ample. The prose suggests a symmetry with subscription sets, but I was conf= used how the app server specifies the receipt subscription URL on the first= reading.
* I agree with Peter that clarifying whether receipts are sent for TTL=3D0 = messages would be nice.
* Does it make sense for the push server to use a 400-class status code in = a receipt to report a nack? For example, if the UA failed to decrypt the me= ssage, or the app threw an exception. IIUC, the spec allows 204 for success= ful deliveries and 410 for expired messages, but it's not clear if the = PS can send other statuses in receipts.

Would generate too much traffic and load, and would increase the implement= ation costs. In some cases=C2=A0
the messages can be expired by t= he storage system, in batch - it wouldn't be a problem if 'nack'= ;=C2=A0
would be a rare case, but in mobile a very large number o= f devices ( tablets, etc ) are offline for=C2=A0
long time so nac= k would be very frequent.=C2=A0

=C2=A0

* I'm also curious to hear implementer feedback about receipts in gener= al.
=C2=A0
<= /div>

In section 5.4...

* Could we restrict the `Topic` grammar to just `token`? ISTM base64url alr= eady fits this definition.
* If the replaced and new message specify TTLs, and the new TTL is shorter.= ..does it just replace the old TTL? (This is implied by "the informati= on that is stored for the push message is updated", as well as the res= triction that the response TTL must be <=3D request TTL, but I wanted to= double-check).

One thing to keep in mi= nd is that some PS may use nosql and be distributed and use eventual consis= tency.
Messages have a timestamp, so either they will be collapse= d, or both will be sent. If the new one has shorter
TTL, it may g= et lost.=C2=A0
=C2=A0
<= /div>

In section 6, are non-zero `wait` values allowed? (I'm assuming not, si= nce the UA can disconnect at any time).

In section 6.2...

* Is there a way for the push server to indicate to the UA how long it'= s willing to wait for acks before re-delivering? (For instance, so that the= UA can batch acks for a burst of incoming messages. Or does this not make = sense with H2?)

Batch acks would be use= ful, but with resource URL it's trickier. If ACK would be implemented a= t lower level it may be possible
( i.e. UA would ack the H2 strea= m IDs of the messages ), but it's an optimization that can be done late= r.

I expect PS will re-deliver on the next connect= ion or monitor request.=C2=A0
=C2=A0
* Can a UA "nack" a message, or would this be implementation-spec= ific? (Related to my note above about reporting nacks to the AS in the rece= ipt subscription).

It would add costs t= o the PS, and I don't think it's a common use case. To 'nack= 9;, the UA needs to first get the message to know the ID.
=C2=A0<= /div>

In section 7.2, could we consider allowing push servers to reject messages = < 4k? If the PS is proxying the message to a third-party server, which M= ozilla's server does on iOS and Android, it might not be able to contro= l the size limit.

+1

=
Costin
=C2=A0

In section 7.3.1, if the UA deletes a subscription that belongs to a subscr= iption set, does it receive a 410 for the deleted subscription on the subsc= ription set stream?


=C2= =A0

Cheers,
- kit

_______________________________________________
Webpush mailing list
Webpush@ietf.org<= br> https://www.ietf.org/mailman/listinfo/webpush
--94eb2c0cdac8ccccbf053460ed4f-- From nobody Fri Jun 3 10:04:15 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E28512D740 for ; Fri, 3 Jun 2016 10:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLzjnT-goZGq for ; Fri, 3 Jun 2016 10:04:11 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0124.outbound.protection.outlook.com [207.46.100.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C823A12D746 for ; Fri, 3 Jun 2016 10:04:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TX1yOAugNOkjxO1ZkfKg0065KQrf+EGHGeKnrdGB2TY=; b=SrgUXaHX0DTRkobzm7RHhALSrsqOW64UgkuAfdgJTixt5K43uJs4JKMpMCq3FopgyxZzJBdSXHXi42BV/MRencDXVGyN6NimU7YP/8ZgPnDMMpeludAyCWefplmZ8K8WvHhrFlZz0Pyzh7fHQIPBNGbnJTK0YMPH96QqGK5OZfY= Received: from CO2PR03MB2407.namprd03.prod.outlook.com (10.166.93.137) by CO2PR03MB2407.namprd03.prod.outlook.com (10.166.93.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.506.9; Fri, 3 Jun 2016 17:04:07 +0000 Received: from CO2PR03MB2407.namprd03.prod.outlook.com ([10.166.93.137]) by CO2PR03MB2407.namprd03.prod.outlook.com ([10.166.93.137]) with mapi id 15.01.0506.011; Fri, 3 Jun 2016 17:04:07 +0000 From: Brian Raymor To: "webpush@ietf.org" Thread-Topic: Rejecting messages < 4K? (WAS Re: [Webpush] Non-blocking comments on -05) Thread-Index: AdG9uHv/UzV61crjSIiwm/f0msling== Date: Fri, 3 Jun 2016 17:04:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.233.197.250] x-ms-office365-filtering-correlation-id: eb3a9468-0771-4075-d8c5-08d38bd11314 x-microsoft-exchange-diagnostics: 1; CO2PR03MB2407; 5:qISYw2ZsDtoiEdo0tL7J5C0oUXIPCEHaUJJ/n7GcDdGrxMgJFlom4jI22IMWCRX8JvbXgdGFFdUH4Nlk0Sl5v8E9fhf0anyk1XfASssMmZ/lLX5jy+5bXBkEws5HvY7y0zRllcTLSX9zyrIrUwziiw==; 24:jxy09qBL8VliyDXy+gyXdwVmID9ni98OhXzxtTOKHe1X5QXRJ4dXiEofKqU2Z6N83MMvlHB8cJCDmYWI6HZs81iQxdGiTtNfNbK8Gtq1EeY=; 7:E5LJjpMSyf8tJYxekXmEbXdWwPklZqgZOGWh4jiWjsE0YPZzjg0GWBpaA/McUomcJEhuvpbqAP/5iSpXLM3TiwAgUlsblirP0iH43XBoQatQuydFsbYANiBYADuKoJOxvddmJOKUROEoam377MiD9mFdWh2E7tvYEKQbwvhk7h3LyOhzZjRrTi+3tsDkQ61GUpEVVtVd6zItupGDpB3tBtZuVa+hVsOiBAsRGM+k+TvpXr8miIUGwNPMn/2QS6ED x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR03MB2407; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CO2PR03MB2407; BCL:0; PCL:0; RULEID:; SRVR:CO2PR03MB2407; x-forefront-prvs: 0962D394D2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(74316001)(8936002)(6116002)(102836003)(586003)(99286002)(5002640100001)(11100500001)(3846002)(19580395003)(2900100001)(1730700003)(2501003)(76576001)(19580405001)(450100001)(77096005)(5004730100002)(2906002)(81166006)(8676002)(122556002)(107886002)(50986999)(3280700002)(15650500001)(33656002)(110136002)(54356999)(5008740100001)(10290500002)(189998001)(5003600100002)(5005710100001)(10090500001)(86362001)(2351001)(229853001)(9686002)(66066001)(10400500002)(5640700001)(92566002)(87936001)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR03MB2407; H:CO2PR03MB2407.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jun 2016 17:04:07.0805 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR03MB2407 Archived-At: Subject: [Webpush] Rejecting messages < 4K? (WAS Re: Non-blocking comments on -05) X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 17:04:13 -0000 For easier discussion and tracking, I'm calling out this suggestion with a = more specific subject line. On Thursday, June 2, 2016 12:02 AM, Kit Cambridge = suggested: > In section 7.2, could we consider allowing push servers to reject message= s < 4k? > If the PS is proxying the message to a third-party server, which Mozilla'= s server does on iOS and Android, it might not be able to control the size = limit. On Friday, June 3, 2016 7:56 AM, Costin Manolache secon= ded: > +1 This change would simply eliminate this requirement: Push services MUST NOT return a 413 status code in responses to an entity= body that is 4k (4096 bytes) or less in size. Martin - this was in your first draft. Any concerns? ...Brian From nobody Fri Jun 3 16:16:51 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2760A12D8D8 for ; Fri, 3 Jun 2016 16:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boGeYowCUZ-9 for ; Fri, 3 Jun 2016 16:16:46 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::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 6A8FC12D624 for ; Fri, 3 Jun 2016 16:16:36 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id s186so29232691qkc.1 for ; Fri, 03 Jun 2016 16:16:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pMn2vpHQW6vfebYQHWkxKwi+u4/2UVYaW5iHeVlsuf0=; b=Ti+T3l5Q1+a8CxbC26B7r7+U8EPIIhDD2aW6GSVjb4f3Fd5AQz+J5Iuwa/y6hpzalS 9sIfaXrsI6/JCQ2boeCk3T6O3rHnmkH75ICrxfhkJdJN8FdoUgi19v5aGXiN1R7mvPdt 91i6lJ4G3FSrkbXBNEfGSw3kfV4x1mFozrQgYba2Z3NGZVk172VIqL1faCbJ3tUcU5EO t1J2CV5b4h7pbPyYpPpA4qwDNZW+pewM4DW9OjSVcb1FcFyPrLnJZac90A59hjiwZIE2 W4QoWlwCvdfUYzzYIqGU3nLMqUdXObn5ye5Oj9QzJtelr0ozxgkuOxHO+MYzEnWGEQgu 0DSw== 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; bh=pMn2vpHQW6vfebYQHWkxKwi+u4/2UVYaW5iHeVlsuf0=; b=hNq7uBALQCgeKI0s1PLv9HvNESF0wwKdqfmGzFsS78dlpjnuGYuNV/YrX+QOR9RavT UjXyCAfGl1Yg0QlS2bR7NRH7bYFmYsjrPw1FMzCEOP6e0lhEdxwSh0rXMw7veulOFbVO BZk/Rz55Y7HywI3tpco89tal5qcUKBYl9WXU8tapll7JVSHhRtptP3O+vHWQZrU81mT5 5mCflb01RTzyEb8tpOpm7s1sWEjltE8Js80z/xgav0Zlf+OiynY4OV6GAkm1hRwwSO0J KOhtbXvtM2OLh6F+NmJVtChb6gZg1WdpIRTl2Zosz4wSStAsrTaZvx1xNFqnEqOO6P86 CjOA== X-Gm-Message-State: ALyK8tIj2mM48hauYNlhRYuBiZv130kr8YXfGgTfdr+1jL/UdRCCO/93gV+RA27jBYl4S7a1QccuCQURptdO/g== X-Received: by 10.55.135.7 with SMTP id j7mr5713767qkd.32.1464995795568; Fri, 03 Jun 2016 16:16:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.104.110 with HTTP; Fri, 3 Jun 2016 16:16:34 -0700 (PDT) In-Reply-To: References: <6af49c2baf1b4e4f884b812d573b947e@Antiope.crf.canon.fr> <989D9268-BE9A-47F7-9181-C0F323D1DA1F@mozilla.com> From: Martin Thomson Date: Sat, 4 Jun 2016 09:16:34 +1000 Message-ID: To: Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Kit Cambridge , Brian Raymor , RUELLAN Herve , "webpush@ietf.org" , Peter Beverloo Subject: Re: [Webpush] Non-blocking comments on -05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 23:16:49 -0000 On 4 June 2016 at 00:56, Costin Manolache wrote: >> In section 7.2, could we consider allowing push servers to reject messages >> < 4k? If the PS is proxying the message to a third-party server, which >> Mozilla's server does on iOS and Android, it might not be able to control >> the size limit. > > > +1 Do either of you want to recommend an alternative limit? The limit exists so that application servers can send messages of a certain size without having to worry that they will be told to go away. That's a useful property to maintain. However, if there are practical limits that make 4k too hard, please pick a more realistic limit. Is it 2k? Less? From nobody Fri Jun 3 16:19:42 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5618012D511 for ; Fri, 3 Jun 2016 16:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxoneRADR2y0 for ; Fri, 3 Jun 2016 16:19:39 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01ED312D8D0 for ; Fri, 3 Jun 2016 16:19:38 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id p22so1846538qka.2 for ; Fri, 03 Jun 2016 16:19:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=+cCwV9XAsy7+lmbq8rQFvji7lj7tWEer93v5i8ATvkk=; b=is94WVLBkIYSLEKrGb3ZP2PP4GGcR7cilqWti5PPyJSmvg6moq0I6DDyJtjTypvmYy Glh20sbmDMKQMG46Rz4jowv41XYo3kiVHY25cHrs1nX5ALF9j6qXQzARNkV+TfFZj7ea a4G94MDIsnKcW8tOd3aIIrevzdLCeGyA18clDmliC68U1Vn1Xd7nkVl69gC6Htx7H7bT fYX/XKFP2aj72AfWw79nbb/EeQojwx32zdskiPbcI7yWiWxHeYnpJZX21HrVgjplPO6t DTDJifW9z9D4mLd4/XTwhtkl9kCu4PVly9ZoHEpbrogLdwMg+CUk0THb4nQhh5GPriT9 NL9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=+cCwV9XAsy7+lmbq8rQFvji7lj7tWEer93v5i8ATvkk=; b=Jv9SBj+bAxq+36oUObADw4VQFg0ZVSR/rShoG1Ffmz05C2ILu2uB2IpaO4Tlls0LgB YWGzd/ZUcNL4SMDZ2tTCR5RId3FdV5iMGvwa9EKBXhpVprAPplisz6tY25OLtPLFL0N2 Gf6ni9qrL/sfgixh0ba3efzfyVTtY0LjlsyV5gWBvHxbFuyokZVF5hwUEN/PHVKQ4/gh MXqs1MxNWFYfDRe5RuPBsBN/GKUdWt69hKjUvIu1JLvnfDLOUDMUZKKn/JPG1/LHAnHZ yz9bnBgRrMadeTKcWv1dr1i7h944X9OKdJ3DonjY9KDrf+jQlrqJEKXB840ucgZtfNrF Q7gg== X-Gm-Message-State: ALyK8tK6YV5WGFUwMMCLMRpfB8Tptn+TLxDGLk7Jly4NJtuwD5o2hYwbx4wIFFdHN3HamTuOE9sRuoy0MIqruw== X-Received: by 10.55.20.208 with SMTP id 77mr5737364qku.124.1464995977849; Fri, 03 Jun 2016 16:19:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.104.110 with HTTP; Fri, 3 Jun 2016 16:19:37 -0700 (PDT) From: Martin Thomson Date: Sat, 4 Jun 2016 09:19:37 +1000 Message-ID: To: "webpush@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Webpush] Delivery receipts support X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 23:19:41 -0000 Costin (on github) said: > Since we have open issues with receipts - can we not make it mandatory ? It's very unlikely all implementations will be able to support the receipts any time soon, at least not as push promises. We discussed this in the past. At that time, we decided to make support of delivery receipts mandatory. Do people want to reopen that issue? Note that I don't believe that any implementation currently supports receipts. I had expected that to be a temporary situation, but if people expect that this will be a problem, now would be a good time to hear of it. From nobody Fri Jun 3 17:59:24 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A04F12D836 for ; Fri, 3 Jun 2016 17:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Dexj-D1rjjI for ; Fri, 3 Jun 2016 17:59:21 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::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 CF9C712D833 for ; Fri, 3 Jun 2016 17:59:21 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id g64so48629477pfb.2 for ; Fri, 03 Jun 2016 17:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=9E88aBKw9pWXrzWaNSqB8ICB+iK2irJ/30/Srul8LwU=; b=imOJY6SxPtMxEFAygkY+mRk05ugaLW8MCmNS22k5wFXps8kzr7z52uT/RBK2zobGvX qLGTg864f7HteFtJePqcph1HDZ9u7WQqmXTEaoLs311EAAfUioRRa+cBVtAqyc4+lMwF WJO0OT32a/aHwRgqg7vaxX8Wgxotugsb5LZFwYCFTNln1txf0Yma3QRczuvgvlEL/qr/ 8hom6ubOdIIiGPsiVdyqwOeWablHwgkQKb/Jv9umiSM7kF8fY5+mXLuzTOyFfBr5XrPB kbHTPznCSuFPh0KXhNi7DCIUSFl8C/gxaI1ZmHn1VHC0QibFxVq8t0Qg1UsPz0Wp1Gb3 xMHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=9E88aBKw9pWXrzWaNSqB8ICB+iK2irJ/30/Srul8LwU=; b=NOSVWREydur1HmpqQ3a6XHvfyadqkULABOg0YkpigpMkxYOz82HRbHRCbh5CDZl7iQ y3fGiiNieCsyo/QzfRgEpaeoA43fvjWrU3BTDACJavClA4IHdkLDrAHAec43j5tWynvM 4imCjAsR1rvmlEmsTy/xm5eL9gJYBjJEXQSs1SaW9ZkbkbC+iKQ4BWpYEgIClyZ+k3XA Ztpc8Rz/n2pZ5SxVNKZPaEr9+t/MUVgo7KpNv6ucg/gOidwcKAd4c8WW2lKfTDOFAdcI 3/LyJO4o/AYGU6rXigf4D3iu216gB9skqQjbLdzXWcemjjm2GsHi4NKL6PUdRD4PQOF1 mKGQ== X-Gm-Message-State: ALyK8tL504aMXWc1sNdx/kzN1oD5MeFhYXCJo4v5BEIle8CzOtQzsoQV8rKo+ycLjYdFsJmaGMjE2cKeNzgkOA== X-Received: by 10.98.67.138 with SMTP id l10mr9271145pfi.59.1465001961378; Fri, 03 Jun 2016 17:59:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Costin Manolache Date: Sat, 04 Jun 2016 00:59:11 +0000 Message-ID: To: Martin Thomson , "webpush@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0c0fb480d82f05346959ae Archived-At: Subject: Re: [Webpush] Delivery receipts support X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 00:59:23 -0000 --94eb2c0c0fb480d82f05346959ae Content-Type: text/plain; charset=UTF-8 We can accept messages that request receipts - and we do support sending the receipts. Just not the receipts that are in the spec :-) In the past we assumed it's only an issue of getting a raw http2 framer/stack - but with the issues around flow control it may take a bit longer. If it is acceptable to say that accepting messages with receipts is mandatory, but using the specific h2+promises receipt monitoring is optional - I think it's fine. On Fri, Jun 3, 2016 at 4:19 PM Martin Thomson wrote: > Costin (on github) said: > > Since we have open issues with receipts - can we not make it mandatory ? > It's very unlikely all implementations will be able to support the receipts > any time soon, at least not as push promises. > > We discussed this in the past. At that time, we decided to make > support of delivery receipts mandatory. Do people want to reopen that > issue? > > Note that I don't believe that any implementation currently supports > receipts. I had expected that to be a temporary situation, but if > people expect that this will be a problem, now would be a good time to > hear of it. > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > --94eb2c0c0fb480d82f05346959ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We can accept messages that request receipts - and we do s= upport sending the=C2=A0
receipts.=C2=A0Just not the receipts that are in the spec :-)

In the past we assumed it's only an=C2=A0issue of getting a raw http2
=C2=A0framer/stack - but with the issues around flow control= =C2=A0it may take a bit longer.

If it is acceptable to say that accepting messages wi= th receipts is mandatory, but
using the specific h2+promises rece= ipt monitoring is optional - I think it's fine.=C2=A0



On Fri, Jun 3, 2016 at 4:19 PM Martin Thomson <martin.thomson@gmail.com> wrote:
Costin (on github) said:
> Since we have open issues with receipts - can we not make it mandatory= ? It's very unlikely all implementations will be able to support the r= eceipts any time soon, at least not as push promises.

We discussed this in the past.=C2=A0 At that time, we decided to make
support of delivery receipts mandatory.=C2=A0 Do people want to reopen that=
issue?

Note that I don't believe that any implementation currently supports receipts.=C2=A0 I had expected that to be a temporary situation, but if
people expect that this will be a problem, now would be a good time to
hear of it.

_______________________________________________
Webpush mailing list
Webpush@ietf.org<= br> https://www.ietf.org/mailman/listinfo/webpush
--94eb2c0c0fb480d82f05346959ae-- From nobody Fri Jun 3 19:48:25 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1FAE12B005 for ; Fri, 3 Jun 2016 19:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZWSh0uTOmir for ; Fri, 3 Jun 2016 19:48:22 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3163812D158 for ; Fri, 3 Jun 2016 19:48:22 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id b124so49215939pfb.0 for ; Fri, 03 Jun 2016 19:48:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hymc498vo0i8Jj8CEWo2h0cyPNweOpMQT/IHYcvbwDo=; b=IPD1moc0UpRH/+gqwRde8ihvYhmffIaipD1/FYyoOWd/4WPIVIBQTmCJjyOvQttsJg gQl9HU+QFOa5uc+yEz4awjAp/OvfG9g7RNO59MjBxlVChASL4NuMp57Baw3oabsEcDci tj7p39QKq68tRpDf0Ldi3EvPCMVlL4ZdnRs/21zSX4gm6UjBWuTCAaKQd2WDz7RLPHIi BNQqc+D/hauaPUl8fe5EbLRLPjBb3KeG7uyhh6D6/um1MayKiDOwRlTV9X/5s/PXMFu6 MgMHab453bBI8HcF3qaARAFE0xJfwnclGIbOdq8cP9O8JTN2OLG5wbvWVyCp9nVVdj/F uTlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hymc498vo0i8Jj8CEWo2h0cyPNweOpMQT/IHYcvbwDo=; b=CEgeu0dMesUKXmaLqk7xdNgc97d/EM/VNE9gAlyPz3UiQkV7bo0H+KjmAQ9mb4VnPk 7AMi4rOKKixONdkvzK32jaAJ3gOZ/oDSTLNch1f9Q8XGxXkCQRyWz8mSIuYjq6bhRIT3 lBSqGxJvaK8cmq4l0/5w2zlEe0qvmuumGwlDjIuVC4CLwxcgMQgmtTcJ2c2povasc0J8 pC0iV7H4SpGX97ndfvlfxsqTkoqYYGx8YoAYy2meVHF+aqQlG3KfPkU0b93TnggbWFPe HR33geVd3jJkOr7N6xk5IsZR1aZfWCxfHSs0B17Q5rxN0U6qgdCpIf++avtqLA0dRCEs 65/A== X-Gm-Message-State: ALyK8tKz4I18Ir+7A/9H4XLIBWXEoyG6M1OydwsPz61cuMqsPpxATAiqMgHQBHsd5OStGZkSLb21F+t02m4ong== X-Received: by 10.98.57.85 with SMTP id g82mr9898423pfa.130.1465008501288; Fri, 03 Jun 2016 19:48:21 -0700 (PDT) MIME-Version: 1.0 References: <6af49c2baf1b4e4f884b812d573b947e@Antiope.crf.canon.fr> <989D9268-BE9A-47F7-9181-C0F323D1DA1F@mozilla.com> In-Reply-To: From: Costin Manolache Date: Sat, 04 Jun 2016 02:48:11 +0000 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=94eb2c112a6a4ff4d105346adf84 Archived-At: Cc: Kit Cambridge , Brian Raymor , RUELLAN Herve , "webpush@ietf.org" , Peter Beverloo Subject: Re: [Webpush] Non-blocking comments on -05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 02:48:24 -0000 --94eb2c112a6a4ff4d105346adf84 Content-Type: text/plain; charset=UTF-8 We support 4k, and it would be great to keep it as is for regular UA and PS. However if the push service is proxying to other protocols - there are services limiting the size to 2k, and I assume for IoT or other cases the limit may be even lower. In such cases the PS can't deliver - so should indicate the cause. In most cases the AS has more information about the UA - so it shouldn't attempt to send 4k to a lightbulb with 256B of free RAM. Costin On Fri, Jun 3, 2016 at 4:16 PM Martin Thomson wrote: > On 4 June 2016 at 00:56, Costin Manolache wrote: > >> In section 7.2, could we consider allowing push servers to reject > messages > >> < 4k? If the PS is proxying the message to a third-party server, which > >> Mozilla's server does on iOS and Android, it might not be able to > control > >> the size limit. > > > > > > +1 > > > Do either of you want to recommend an alternative limit? The limit > exists so that application servers can send messages of a certain size > without having to worry that they will be told to go away. That's a > useful property to maintain. However, if there are practical limits > that make 4k too hard, please pick a more realistic limit. Is it 2k? > Less? > --94eb2c112a6a4ff4d105346adf84 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We support 4k, and it would be great to keep it=C2=A0as is for regular UA
and PS.
=

However if the push service is proxying to other protoc= ols - there are
services limiting the=C2=A0size to 2k, and I assume for IoT or other cases
= the limit may be even lower.=C2=A0In such cases the PS can't deliver - so= =C2=A0
should indicate the= cause.=C2=A0
In most cases the AS has more information ab= out the UA - so it shouldn't
attempt to send 4k to a lightbul= b with 256B of free RAM.=C2=A0

Costin



On Fri, Jun 3, 2016 at 4:16 PM Martin Thomson = <martin.thomson@gmail.com> wrote:
On 4 June 2016 at 00:5= 6, Costin Manolache <costin@gmail.com> wrote:
>> In section 7.2, could we consider allowing push servers to reject = messages
>> < 4k? If the PS is proxying the message to a third-party server= , which
>> Mozilla's server does on iOS and Android, it might not be able= to control
>> the size limit.
>
>
> +1


Do either of you want to recommend an alternative limit?=C2=A0 The limit exists so that application servers can send messages of a certain size
without having to worry that they will be told to go away.=C2=A0 That's= a
useful property to maintain.=C2=A0 However, if there are practical limits that make 4k too hard, please pick a more realistic limit.=C2=A0 Is it 2k?<= br> Less?
--94eb2c112a6a4ff4d105346adf84-- From nobody Mon Jun 6 10:41:51 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B73412D885 for ; Mon, 6 Jun 2016 10:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.13 X-Spam-Level: X-Spam-Status: No, score=-1.13 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_WEB=0.77] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHo6x4TIWHv2 for ; Mon, 6 Jun 2016 10:41:44 -0700 (PDT) Received: from gateway33.websitewelcome.com (gateway33.websitewelcome.com [192.185.146.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70D0112D875 for ; Mon, 6 Jun 2016 10:41:44 -0700 (PDT) Received: from cm2.websitewelcome.com (cm2.websitewelcome.com [192.185.178.13]) by gateway33.websitewelcome.com (Postfix) with ESMTP id CAE9CCA251494 for ; Mon, 6 Jun 2016 12:41:43 -0500 (CDT) Received: from gator4135.hostgator.com ([192.185.4.147]) by cm2.websitewelcome.com with id 3Vhg1t0043AKFgo01VhhKS; Mon, 06 Jun 2016 12:41:43 -0500 Received: from mb72736d0.tmodns.net ([208.54.39.183]:63384 helo=[172.20.10.2]) by gator4135.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1b9yWx-000U6P-Pd for webpush@ietf.org; Mon, 06 Jun 2016 12:41:39 -0500 From: Shida Schubert Content-Type: multipart/alternative; boundary="Apple-Mail=_AE0C3D74-ACDD-4A20-8F7B-B07201B21513" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Date: Mon, 6 Jun 2016 10:41:57 -0700 References: <7BE6135D-961D-4D6E-B6FC-99BA27B1B0C4@ntt-at.com> <4B69453E-54AD-414A-BDC3-18E175AA25BC@ntt-at.com> <65b3ac726b70495db4bb0c2df33c19dc@Antiope.crf.canon.fr> To: "webpush@ietf.org" In-Reply-To: <65b3ac726b70495db4bb0c2df33c19dc@Antiope.crf.canon.fr> X-Mailer: Apple Mail (2.3124) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator4135.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source-IP: 208.54.39.183 X-Exim-ID: 1b9yWx-000U6P-Pd X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: mb72736d0.tmodns.net ([172.20.10.2]) [208.54.39.183]:63384 X-Source-Auth: shida@agnada.com X-Email-Count: 3 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== Archived-At: Subject: Re: [Webpush] WGLC for draft-ietf-webpush-protocol-05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 17:41:48 -0000 --Apple-Mail=_AE0C3D74-ACDD-4A20-8F7B-B07201B21513 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 All; The WGLC is concluding today but with the number of pull-requests, = despite many of them being a non-blocker with some normative changes, I = am going to run another WGLC (this time 2 weeks) once the 06 is = available and all issues on github are resolved.=20 Thanks to you all for providing the comments. Shida as co-chair > On Jun 1, 2016, at 4:49 AM, RUELLAN Herve = wrote: >=20 > I also shared some comments and sent some pull-requests. I think the = draft is in a pretty good shape and none of my comments or suggestions = are blocking for its advancement. > =20 > Thanks, > =20 > Herv=C3=A9 > =20 > From: Webpush [mailto:webpush-bounces@ietf.org = ] On Behalf Of Peter Beverloo > Sent: mardi 31 mai 2016 21:43 > To: Shida Schubert > > Cc: webpush@ietf.org > Subject: Re: [Webpush] WGLC for draft-ietf-webpush-protocol-05 > =20 > I have just shared some comments, but none of them are significant = enough to defer WGLC. > =20 > As such, I can definitely support the draft as-is. > =20 > Thanks, > Peter > =20 > On Tue, May 31, 2016 at 4:52 AM, Shida Schubert > wrote: > All; > =20 > We have heard very little regarding the actual contents of the draft = and WGLC is over this week. > =20 > As noted when I started the last call, please show your support by = providing acknowledgement(s) if you are happy with the draft as is.=20 > =20 > Thanks!=20 > Shida > =20 > On May 24, 2016, at 11:11 AM, Costin Manolache > wrote: > =20 > +1 - we discussed my concerns on flow control for push promises, and I = think it's reasonable to have them addressed either=20 > as part of http2 or as a separate document.=20 > =20 > Other than that I think it's reasonable and stable base - extensions = and features can be added on top of it. > =20 > Costin > =20 > =20 > On Mon, May 23, 2016 at 5:53 PM Richard Maher > wrote: > Please see embedded comments: - > =20 > On Tue, May 24, 2016 at 8:03 AM, Shida Schubert > wrote: > =20 > Hi Richard; > =20 > Thank you for your feedback. > =20 > Currently developers need to either deal with different spec/api for = each of the push notification providers (GCM, Azure, APN etc.) to = communicate to their subscribers or use third party service (urban = airship etc.), which is fine for native apps but gets a little more = complicated with the browser.=20 > =20 > Inconvenient but feature detection is not the end of the world. > =20 > The IETF has agreed that we need a standardized protocol for this and = that=E2=80=99s what we are chartered to work on.=20 > =20 > A much better idea especially considering the number of Push Services = that don't happen to also manufacture a browser. But let's get it as = fit-for-purpose and as extensive as we can, eh? How many different = specifications have there been so far dealing with Server Push, Simple = Push, etc. Each time with developers having to deprecate and re-tool :-( > =20 > =20 > As for Broadcasting, from my shallow understanding isn=E2=80=99t it = merely the same payload sent to set or all of subscribers? > =20 > I find that level of naivety astounding in anyone who is involved in = formulation of this standard. Why do you seek to deliberately ignore the = client-based subscription feature where any and all client-to-topic = mapping is maintained solely by the Push Service and where the = Application Server is oblivious to consumers and freed the need for a = local mapping database? The Use-Cases are clear: - Sports results, = Weather Updates, Stock Prices, Security Alerts, just to name a few. The = strategy for encrypting an authenticating the payload/body is also = clear(ish): - https://github.com/slightlyoff/ServiceWorker/issues/901 = > =20 > Why do you people continue to say "What elephant?" > =20 > In which case, I believe it can be handled as an implementation matter = likely at the application side. > =20 > For some other use cases, managing subscriptions on the server is = indeed an option. Horses for courses: - > = https://developers.google.com/cloud-messaging/topic-messaging#managing_top= ic_subscriptions_from_the_server = =20 > =20 > The protocol can be extended at later stage if wg agrees it is = something that is necessary but I haven=E2=80=99t heard anybody else at = the meeting or on the mailing list expressing this feature is a = show-stopper. =20 > =20 > I sorry to appear blunt but if the other members of the cloistered = star chamber that is adjudicating on this are equally ignorant of the = business requirements then there is no surprise they haven't come up = with a solution. > =20 > But *please* don't listen to me. Just look at what solutions that are = already in the wild with native apps. Why won't you let HTML5 Web App = developers compete on an even playing field and create Apps that satisfy = these common requirements? > =20 > The MBONE people seem to have made progress over the years and we all = know that your Application Servers with simply be overwhelmed if you = tickle potentially millions of clients so let's get on with the = solution?=20 > =20 > =20 > Anyway, I would very much appreciate it, if you can refrain the = comments to the technical contents of the draft.=20 > =20 > Are you telling me that pointing out omissions and scope deficiencies = is not welcomed? > =20 > Either way 5.4 is completely wrong. You've been told. > =20 > =20 > Thanks > Shida > =20 > On May 16, 2016, at 6:50 PM, Richard Maher > wrote: > =20 > "5.4 Updating Push Messages" is based on the misconception that = "Topics" are "Collapse Keys". The standard as proposed has been = superseded by event on the ground by established, successful, and more = importantly scalable solutions: - > =20 > Google Cloud Messaging: - > https://developers.google.com/cloud-messaging/topic-messaging = > =20 > Azure Notification Hubs: - > = https://blogs.windows.com/buildingapps/2013/09/16/delivering-push-notifica= tions-to-millions-of-devices-with-windows-azure-notification-hubs/ = > =20 > Whether the Topics are identified via HTTP headers or JSON Tokens is = the only moot point. What is clear is that the proposed protocol = attempts to conflate the Topic and Collapse Key features: - > = https://developers.google.com/cloud-messaging/concept-options#collapsible_= and_non-collapsible_messages = > =20 > The fact that quintessential Push Notification feature "Broadcasting" = has been descoped from this protocol must be sufficient to reject the = proposal. > =20 > Please do not make the same mistake that you made with Geofences. IETF = and W3C credibility has already suffered enough. > =20 > On Tue, May 17, 2016 at 2:32 AM, Shida Schubert > wrote: > All; > =20 > As discussed at the IETF 95, as last issue surrounding the = subscription re-use is addressed, we are starting a Working Group Last = Call for the webpush protocol.=20 > =20 > https://tools.ietf.org/html/draft-ietf-webpush-protocol-05 = > =20 > If you have any issues or questions regarding the draft please submit = it to the list, when raising issues please provide constructive = resolution when possible. > =20 > Please acknowledge on the list even when you are content/happy with = the status of the draft.=20 > =20 > The Working Group Last Call will end on June 6th (3 weeks).=20 > =20 > Shida > As co-chair >=20 > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush = > =20 > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush = > =20 >=20 > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush = > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush = > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush = > =20 >=20 > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush = > =20 > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush = --Apple-Mail=_AE0C3D74-ACDD-4A20-8F7B-B07201B21513 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

All;

The WGLC is concluding today but with the number of = pull-requests, despite many of them being a non-blocker with some = normative changes, I am going to run another WGLC (this time 2 weeks) = once the 06 is available and all issues on github are = resolved. 

Thanks to you all for providing the comments.

Shida as = co-chair

On Jun 1, 2016, at 4:49 AM, RUELLAN Herve = <Herve.Ruellan@crf.canon.fr> wrote:

I also shared some comments and sent some = pull-requests. I think the draft is in a pretty good shape and none of = my comments or suggestions are blocking for its advancement.
 
Thanks,
 
Herv=C3=A9
 
From: Webpush = [mailto:webpush-bounces@ietf.org] On Behalf = Of Peter = Beverloo
Sent: mardi 31 mai 2016 21:43
To: Shida Schubert <shida@ntt-at.com>
Cc: webpush@ietf.org
Subject: Re: [Webpush] WGLC for = draft-ietf-webpush-protocol-05
 
I have just shared some comments, but = none of them are significant enough to defer WGLC.
 
As such, I can definitely support the = draft as-is.
 
Thanks,
Peter
 
On Tue, May 31, 2016 = at 4:52 AM, Shida Schubert <shida@ntt-at.com> wrote:
All;
 
We have heard very little regarding the actual = contents of the draft and WGLC is over this week.
 
As noted when I started the last call, = please show your support by providing acknowledgement(s) if you are = happy with the draft as is. 
 
Thanks! 
Shida
 
On = May 24, 2016, at 11:11 AM, Costin Manolache <costin@gmail.com> = wrote:
 
+1 - we discussed my = concerns on flow control for push promises, and I think it's reasonable = to have them addressed either 
as part of http2 or = as a separate document. 
 
Other than that I think it's reasonable and stable = base - extensions and features can be added on top of it.
 
Costin
 
 
On = Mon, May 23, 2016 at 5:53 PM Richard Maher <maherrj@googlemail.com> wrote:
Please see embedded comments: -
 
On = Tue, May 24, 2016 at 8:03 AM, Shida Schubert <shida@ntt-at.com> = wrote:
 
Hi Richard;
 
Thank you for your feedback.
 
Currently developers need to either deal = with different spec/api for each of the push notification providers = (GCM, Azure, APN etc.) to communicate to their subscribers or use third = party service (urban airship etc.), which is fine for native apps but = gets a little more complicated with the browser. 
 
Inconvenient but feature detection is not the end of the = world.
 
The IETF has agreed that we need a = standardized protocol for this and that=E2=80=99s what we are chartered = to work on. 
 
A much better idea especially considering the number of Push = Services that don't happen to also manufacture a browser. But let's get = it as fit-for-purpose and as extensive as we can, eh? How many different = specifications have there been so far dealing with Server Push, Simple = Push, etc. Each time with developers having to deprecate and re-tool = :-(
 
 
As for Broadcasting, from my shallow understanding = isn=E2=80=99t it merely the same payload sent to set or all of = subscribers?
 
I find that level of naivety astounding in anyone who is = involved in formulation of this standard. Why do you seek to = deliberately ignore the client-based subscription feature where any and = all client-to-topic mapping is maintained solely by the Push Service and = where the Application Server is oblivious to consumers and freed the = need for a local mapping database? The Use-Cases are clear: - Sports = results, Weather Updates, Stock Prices, Security Alerts, just to name a = few. The strategy for encrypting an authenticating the payload/body is = also clear(ish): - https://github.com/slightlyoff/ServiceWorker/issues/901
 
Why do you people continue to say "What = elephant?"
 
In which case, I believe it can be = handled as an implementation matter likely at the application side.
 
 For some other use cases, managing subscriptions on the = server is indeed an option. Horses for courses: -
 
The protocol can be = extended at later stage if wg agrees it is something that is necessary = but I haven=E2=80=99t heard anybody else at the meeting or on the = mailing list expressing this feature is a show-stopper.  
 
I sorry to appear blunt but if the other members of the = cloistered star chamber that is adjudicating on this are equally = ignorant of the business requirements then there is no surprise they = haven't come up with a solution.
 
But *please* don't listen to me. Just look at what = solutions that are already in the wild with native apps. Why won't you = let HTML5 Web App developers compete on an even playing field and create = Apps that satisfy these common requirements?
 
The MBONE people seem to have made = progress over the years and we all know that your Application Servers = with simply be overwhelmed if you tickle potentially millions of clients = so let's get on with the solution? 
 
 
Anyway, I would very much appreciate it, if you can = refrain the comments to the technical contents of the draft. 
 
Are you telling me that pointing out omissions and scope = deficiencies is not welcomed?
 
Either way 5.4 is completely wrong. You've been = told.
  
 
Thanks
Shida
 
On = May 16, 2016, at 6:50 PM, Richard Maher <maherrj@googlemail.com> wrote:
 
"5.4 Updating Push Messages" is based on = the misconception that "Topics" are "Collapse Keys". The standard as = proposed has been superseded by event on the ground by established, = successful, and more importantly scalable solutions: -
 
Google Cloud Messaging: -
 
Azure Notification = Hubs: -
 https://blogs.windows.com/buildingapps/2013/09/16/delivering-pu= sh-notifications-to-millions-of-devices-with-windows-azure-notification-hu= bs/
 
Whether the Topics are identified via HTTP headers or = JSON Tokens is the only moot point. What is clear is that the proposed = protocol attempts to conflate the Topic and Collapse Key features: -
 
The fact that quintessential Push = Notification feature "Broadcasting" has been descoped from this protocol = must be sufficient to reject the proposal.
 
Please do not make the same mistake that = you made with Geofences. IETF and W3C credibility has already suffered = enough.
 
On Tue, May 17, 2016 = at 2:32 AM, Shida Schubert <shida@ntt-at.com> wrote:
All;
 
As discussed at the IETF 95, as last issue = surrounding the subscription re-use is addressed, we are starting a = Working Group Last Call for the webpush protocol. 
 
https://tools.ietf.org/html/draft-ietf-webpush-protocol-05<= o:p class=3D"">
 
If you have any = issues or questions regarding the draft please submit it to the list, = when raising issues please provide constructive resolution when = possible.
 
Please acknowledge on the list even when you are = content/happy with the status of the draft. 
 
The Working Group Last Call will end on = June 6th (3 weeks). 
 
Shida
As co-chair


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

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


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

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


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

 
_______________________________________________
Webpush mailing = list
Webpush@ietf.org
https://www.ietf.org/mailman/listinfo/webpush
= --Apple-Mail=_AE0C3D74-ACDD-4A20-8F7B-B07201B21513-- From nobody Mon Jun 6 14:16:05 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0FB012D5BC for ; Mon, 6 Jun 2016 14:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPuXHgSm4yh9 for ; Mon, 6 Jun 2016 14:15:59 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0726.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:726]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7247E12B00D for ; Mon, 6 Jun 2016 14:15:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rsVy2NNJ+nBHe5fcYwzCnotjBx7821VVVogTn69wQRc=; b=NK1iy2h41WFR9NFWl2f3YYVn3PQgUH2QEryP3OJ1iuszburCz77hhr9FV/xLwIcVBK+T5ctWGA2wE2jMkTYb9079+O/4wMsLvi+dYFamGN4ccxxRt3GrKKdht34X+/fiXsEWeW0FsAWqElYMxosRcQi8YShBMEo42Vg7Rqr2iDc= Received: from CO2PR03MB2407.namprd03.prod.outlook.com (10.166.93.137) by CO2PR03MB2408.namprd03.prod.outlook.com (10.166.93.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.506.9; Mon, 6 Jun 2016 21:15:31 +0000 Received: from CO2PR03MB2407.namprd03.prod.outlook.com ([10.166.93.137]) by CO2PR03MB2407.namprd03.prod.outlook.com ([10.166.93.137]) with mapi id 15.01.0506.016; Mon, 6 Jun 2016 21:15:31 +0000 From: Brian Raymor To: "webpush@ietf.org" Thread-Topic: Status for webpush-05 WGLC Thread-Index: AdHAOCd7uxTXYP7bRPSDqvdAJMja2A== Date: Mon, 6 Jun 2016 21:15:30 +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: [24.16.23.27] x-ms-office365-filtering-correlation-id: e9f706b6-8a33-4f11-40e7-08d38e4fb0f7 x-microsoft-exchange-diagnostics: 1; CO2PR03MB2408; 5:YVcu9vT/C7sddxPyZ2yoNAFQ6bSMzNzb2xwkMG0RWSNw0WU1V5nLlkLjZ7b2sRyfDiRCaPMLVapX+pwb9nByjkxwCNbOyj0/cO91ZiZhsSTtHercn8NSqt/TvtVvk6BI74AWucVGjtMEmRyaE7Fnww==; 24:Fqnr+GYxvUigfJyADUj7NmJCDS2uB/rYDzS/92YnW3yorWnieQoShuB7IxiCS0LO6WDJPW5mi0zEXJcfbODvKbfsPu7V9qSCtufo0u1YpuA=; 7:p3zAWp7cjbCIqHe+K9cc3lRaoE6eeRw8y7CUrRNGuWH7nvBOkNcDinUVkek4y19JT2JZEJx4rY/C8kPVM1F/zLuCXyOJk+NMqBTAm9aiDRBA8JOWJEREkOyQ358Byn4ywO2kw1PsDgaNg4lqBnNiBhj7zEVWki7qkYZ/1EJpzAy8R3KsrNW8JGjxjcIQzeElZGERjjGYCB5SqP4ViNQSUSJmwZUWTUa2gP/l84K0u1ev2qkftZdR21EC6VZJT5tb x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR03MB2408; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CO2PR03MB2408; BCL:0; PCL:0; RULEID:; SRVR:CO2PR03MB2408; x-forefront-prvs: 096507C068 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(107886002)(8990500004)(10290500002)(86362001)(10400500002)(5008740100001)(97736004)(76576001)(68736007)(110136002)(19580395003)(5630700001)(5640700001)(3660700001)(189998001)(3280700002)(19300405004)(2501003)(9686002)(5005710100001)(50986999)(74316001)(2906002)(102836003)(790700001)(92566002)(450100001)(15975445007)(77096005)(2900100001)(229853001)(122556002)(81156014)(81166006)(1730700003)(8676002)(106356001)(8936002)(66066001)(105586002)(6116002)(3846002)(101416001)(10090500001)(54356999)(19625215002)(11100500001)(2351001)(5004730100002)(5002640100001)(16236675004)(5003600100002)(86612001)(586003)(99286002)(33656002)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR03MB2408; H:CO2PR03MB2407.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CO2PR03MB2407F25BA3A3548DB9314C8E835C0CO2PR03MB2407namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2016 21:15:30.9270 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR03MB2408 Archived-At: Subject: [Webpush] Status for webpush-05 WGLC X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 21:16:02 -0000 --_000_CO2PR03MB2407F25BA3A3548DB9314C8E835C0CO2PR03MB2407namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I really appreciate all the detailed reading and thought that went into the= feedback. Thanks for helping to improve the draft. Going forward, I would make one small request. Could we use separate mail s= ubjects for separate topics? It's a bit difficult to track conversations when all t= he subject lines are "Non-blocking comments on -05" ;-) That said, if I've missed capturing or a= ddressing your issue, please let me know. My goal is to publish webpush-06 on or before 6/13 if consensus is reached.= We have until 7/8 to publish further drafts for IETF96. These open issues need more working group discussion: * Adds that receipt support is mandatory. https://github.com/webpush-wg/webpush-protocol/pull/104 Receipts have been required since the -00 draft from July 2015 - https://to= ols.ietf.org/html/draft-ietf-webpush-protocol-00#section-6.2 Related threads on the mailing list: http://www.ietf.org/mail-archive/web/webpush/current/msg00565.html http://www.ietf.org/mail-archive/web/webpush/current/msg00573.html * Allow push service to reject messages < 4K https://github.com/webpush-wg/webpush-protocol/issues/109 Related thread on the mailing list: http://www.ietf.org/mail-archive/web/webpush/current/msg00572.html These open issues are more editorial in nature: * Optional message encryption and push message examples Issue: https://github.com/webpush-wg/webpush-protocol/issues/106 PR: https://github.com/webpush-wg/webpush-protocol/pull/107 When we added "The ciphertext of the push message is included in the body o= f the request." during WGLC, the examples no longer matched the description. I'm leaning towards clear text examples = for clarity with a pointer to an example of encrypted content in Martin's optional draft. * Make it a bit more obvious which is the send resource. https://github.com/webpush-wg/webpush-protocol/pull/105 Costin writes - "push resource" is confusing me every time - "push" is used= in all other resources. Please share your suggestions in the PR. * proxy uc https://github.com/webpush-wg/webpush-protocol/pull/96 Herve provided further clarification for the Canon scenarios. Costin has pe= nding feedback that needs to be addressed. --_000_CO2PR03MB2407F25BA3A3548DB9314C8E835C0CO2PR03MB2407namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I really appreciate all the detailed reading and = thought that went into the feedback.

Thanks for helping to improve the draft.

 

Going forward, I would make one small request. Co= uld we use separate mail subjects

for separate topics? It’s a bit difficult t= o track conversations when all the subject lines are

“Non-blocking comments on -05” ;-) Th= at said, if I’ve missed capturing or addressing your

issue, please let me know.

 

My goal is to publish webpush-06 on or before 6/1= 3 if consensus is reached. We have until 7/8

to publish further drafts for IETF96.<= /p>

 

These open issues need more working group discuss= ion:

 

*  Adds that receipt support is mandatory.

https://github.com/webpush-wg/webpush-protocol/pu= ll/104

 

Receipts have been required since the -00 draft f= rom July 2015 - https://tools.ietf.org/html/draft-ietf-webpush-protocol-00#= section-6.2

 

Related threads on the mailing list:

http://www.ietf.org/mail-archive/web/webpush/curr= ent/msg00565.html

http://www.ietf.org/mail-archive/web/webpush/curr= ent/msg00573.html

 

*  Allow push service to reject messages <= ; 4K

https://github.com/webpush-wg/webpush-protocol/is= sues/109

 

Related thread on the mailing list:

http://www.ietf.org/mail-archive/web/webpush/curr= ent/msg00572.html

 

 

These open issues are more editorial in nature:

 

*  Optional message encryption and push mess= age examples

Issue: https://github.com/webpush-wg/webpush-prot= ocol/issues/106

PR: https://github.com/webpush-wg/webpush-protoco= l/pull/107

 

When we added "The ciphertext of the push me= ssage is included in the body of the request." during WGLC, the exampl= es

no longer matched the description. I’m lean= ing towards clear text examples for clarity with a pointer to an example

of encrypted content in Martin’s optional d= raft.

 

*  Make it a bit more obvious which is the s= end resource.

https://github.com/webpush-wg/webpush-protocol/pu= ll/105

 

Costin writes - "push resource" is conf= using me every time - "push" is used in all other resources.=

Please share your suggestions in the PR.

 

*  proxy uc

https://github.com/webpush-wg/webpush-protocol/pu= ll/96

 

Herve provided further clarification for the Cano= n scenarios. Costin has pending

feedback that needs to be addressed.

 

 

 

--_000_CO2PR03MB2407F25BA3A3548DB9314C8E835C0CO2PR03MB2407namp_-- From nobody Mon Jun 6 15:03:43 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D068812D94A for ; Mon, 6 Jun 2016 15:03:38 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwPtw0ICLcvC for ; Mon, 6 Jun 2016 15:03:37 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::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 3034612D62A for ; Mon, 6 Jun 2016 15:03:37 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id z189so55758747itg.0 for ; Mon, 06 Jun 2016 15:03:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=EbcMtJ7+fTLVM/QTnCeR1Hhen06sc/bvsuRrpHRb0gw=; b=xkDEGTz+Asr2OPI9BNPGuW3zFm57SAClYMR9FD7/enGSQ0rfecnlT18f6us4UA2wus Aecmg4sMNEJAEc7KQquaF5YnFooENxc46HAvhSba5MtHjJzcL9OoNsHEnTe0/2fMQ+gG QxeREvN+SF0ZZwt0Xv+nRk1pDF4NGMYYr8EiP9DGJVBnDoEjzFqR2hFYLtJyj+UCyJrw F7PxmOYoLD7LUhdO8eVThxSQCKWGO955f05ZBFPgxu2Pezf9/tMe3HSuS66sarNMhmAd JnC4+7ynY9i7PGk49x5ym7h0khcOQRmlqB+nrikyLmBOJY47xB0LPV4+01igMjIHwfxm IVig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=EbcMtJ7+fTLVM/QTnCeR1Hhen06sc/bvsuRrpHRb0gw=; b=Zfc2qF0MkX6zaI4YhjhIevfidq/yGLqM1QDAnivyzVoYVBWLbU1N23RiDie0mSL9ku nstG58kJfjKQ6q92uf3/TI8VSk2In11mUkMM19znqMXGrS4gAjp6g6Qs4G9jGascLV32 QvvGgMZJs4LvaKe3+Q4OXIoHHrI/om8eql5OI47Y/QI2g0l/cg7JBGkN2zaxe8wBPgPT lmDtKse/G8oGjJJeNKgDVOlySZt/nKqNJ4YNS50km8VgBOyHK7y/jnOrlyyIq+sQgc0d me6nwze2zPhAdc26lJnrXTXkd//TGpcwIpLWgJcRDrFVuqmb1JGDA5i7r8qY8BG06Oxl zXPA== X-Gm-Message-State: ALyK8tJRUakq0HzklkqXLhJdwhVxtd1W8oMBnIZ68H59H92vVIAaGGlPmdEkZiD68XamWXXsNfRsSoErsT4Pow== X-Received: by 10.107.62.4 with SMTP id l4mr515220ioa.185.1465250616516; Mon, 06 Jun 2016 15:03:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.152.131 with HTTP; Mon, 6 Jun 2016 15:02:57 -0700 (PDT) From: Idel Pivnitskiy Date: Tue, 7 Jun 2016 01:02:57 +0300 Message-ID: To: webpush@ietf.org Content-Type: multipart/alternative; boundary=94eb2c06a88c8188480534a33ee9 Archived-At: Subject: [Webpush] Define a list of headers, which must be transmitted to the UA X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 22:03:39 -0000 --94eb2c06a88c8188480534a33ee9 Content-Type: text/plain; charset=UTF-8 Hello, Should we define a list of headers, which must be transmitted to the UA and PS can't drop them? For example: Content-Type, Content-Length etc.? Best regards, Idel Pivnitskiy -- Twitter: @idelpivnitskiy GitHub: @idelpivnitskiy --94eb2c06a88c8188480534a33ee9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

Should we define a li= st of headers, which must be transmitted to the UA and PS can't drop th= em?

For example: Content-Type,=C2=A0Content-Length=
etc.?

=
Best regards,
Idel P= ivnitskiy
--
GitHub:= =C2=A0@idel= pivnitskiy
--94eb2c06a88c8188480534a33ee9-- From nobody Mon Jun 6 15:56:49 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC4BA12D1E0 for ; Mon, 6 Jun 2016 15:56:47 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQtqTbJ5XMr7 for ; Mon, 6 Jun 2016 15:56:46 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33EDA12D140 for ; Mon, 6 Jun 2016 15:56:46 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id i65so49531608ith.1 for ; Mon, 06 Jun 2016 15:56:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=KWSGHEuJEaW8aZUl9DISwLr0YlnpRjGzxpEB2M5RP1Q=; b=LqdjWfT/bZHwEiGSnLVpbzuvjVpwNU/yBU0FquJbfBXy2uHMZe7if2lzo3ly8mPeOM dkimz1y2zpjUrCMxLDUikV9BCd3T4c3wNGqAAdl8tvNVNxfZyqCgBtncZ6Vez7MNGSdK wduEORnqFXeiGbS5a/jdjn54Pjb3805oRqXRNI8rxvgRT3Ydraw9DeZ7EsOwWhssec91 ZSBbKUSDswCXfluRVsVAcO+gnAnAo65RMTTLtzjsn3EhjwzdzqBQmKkek8lLotKh+eS1 FB1DvoqFTXRwSehQk7E8YGruWT3mAVOS7ONcfldgzbQFzNv4MISVbA5P99zDwLHN6Wth u+IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=KWSGHEuJEaW8aZUl9DISwLr0YlnpRjGzxpEB2M5RP1Q=; b=SaWML/LJCJkrBcBnhUh8bDMxW5/A7vo3kw5IbukaF1oh2rL3qGfNQTeI+eqBB7f3H8 XAGf4TYIqaY2BXz2hJfTljt//zrUZ9dT00+5xD7MhLz0bGy6Cvk3YnM238Ji+vYDZE3b kIW4sTdPObmzEODi7fGszlBcEMPPLmUrnCz845Ywyvw7O4kKWU9x0g1Q3Go8UAFLcD+u lO6YNpyWxdVTwyHm6dMW7oAFGA/N15oEEl2csfeRLjzxpyDLrHNR+PUTMQRPNet+JW5C /7avf0Os8TzJa9aih/NbUhCVYyg7DHS1y/xpWG9uHG0D3bs7oDw3ADzmf4ByMZvut71t BmgA== X-Gm-Message-State: ALyK8tJKCUFhxbLXuEBHL/B0k/OoqaNXba56aBpfClh1Nk9r3lkE/qRwhknyoOuItbK/5fJHK1H0opdyZJmdJw== X-Received: by 10.107.31.66 with SMTP id f63mr24696411iof.180.1465253805530; Mon, 06 Jun 2016 15:56:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.152.131 with HTTP; Mon, 6 Jun 2016 15:56:06 -0700 (PDT) From: Idel Pivnitskiy Date: Tue, 7 Jun 2016 01:56:06 +0300 Message-ID: To: webpush@ietf.org Content-Type: multipart/alternative; boundary=001a1140f8d495c4c40534a3fcf2 Archived-At: Subject: [Webpush] Different status codes for negative Push Message Receipts X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 22:56:48 -0000 --001a1140f8d495c4c40534a3fcf2 Content-Type: text/plain; charset=UTF-8 I've created an issue on GitHub, related to this discussion: https://github.com/webpush-wg/webpush-protocol/issues/110 Could be useful for an AS to know what happened with push message / UA. Best regards, Idel Pivnitskiy -- Twitter: @idelpivnitskiy GitHub: @idelpivnitskiy --001a1140f8d495c4c40534a3fcf2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've created an issue on GitHub, related to this = discussion:=C2=A0


Could be useful for a= n AS to know what happened with push message / UA.

<= div>
Best regards,
Idel Pivnitskiy
--
GitHub:=C2=A0@idelpivnitskiy
--001a1140f8d495c4c40534a3fcf2-- From nobody Mon Jun 6 16:03:26 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3224412D661 for ; Mon, 6 Jun 2016 16:03:25 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtHhOd_daHug for ; Mon, 6 Jun 2016 16:03:24 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBEB612D567 for ; Mon, 6 Jun 2016 16:03:23 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id f67so57412384ith.1 for ; Mon, 06 Jun 2016 16:03:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=I82HGYfkNIbDrbFJC61kswIvhtJ4/uvGsqlf8r9mREI=; b=G8iRBV2E9h90H5gpkYaFY3No/uRCZntPMAXGC7AyWogkx38g5REKXBsg1plISvLsDV C6X0colsfs1CgMcl0TOguZ+UA00sjYTzt0+Ym+h9o4/Gk3L4R0VXKicZyjFEawa2yySF e5NUfDs3ahdwvjK0v0hyiQLCEppite2bQnsCHky17ytGf8TTg7WbDIQi/mYU5ckIqjrl yjRcttw5A7LVr3kVqzgWnZ03Y+EreRNrPH4NOgWqouJ4f28E/AKpfaQgeCQRH5/nbW8u YvTpW6YyMlTM4+6z/p8hj2YBlPtmBNC4LdaHW3gVkul0exyv8Ea67RqYn9O9DvI4bqAR WkvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=I82HGYfkNIbDrbFJC61kswIvhtJ4/uvGsqlf8r9mREI=; b=MCLOq1yosFaOeyozr+p3g3boFq7rt64o1F9AGynaH7zPIM6otJG8wDV6EBxpahS4FF JF5+cpam9J84DqX4xq6zqfLzBoawinhiaSe5LiqBA4Rkz8iu3dTYgaHg2TWZ9B1FOUoH fmTQMxayLS/0iEsb7M6KA0EjKlcz8+FLC1bkr4EKZ6AZH8IF9/poq/tHV+4agIjfnb2Y jXmNlB5yaBvZQt8YJROvB2W/qkY0O23wDGs7IjSx40RNE5DOr4TK2bMXtcDHhySbY50V Y0s7UUs7A8MqzkF0bRhfHUa+GtmtztHHQylgkNJDtTeO2K2xfRL2bjgoS1d+h1X5D8zP QIow== X-Gm-Message-State: ALyK8tI9sStlJQHBghnOgQVdQ3wP0r8RHbDlqMPLvVbQyMAJbEHefklU97v+k+OQOTNorcFWsOgtZ0LM63uhkw== X-Received: by 10.107.148.143 with SMTP id w137mr25225728iod.63.1465254200508; Mon, 06 Jun 2016 16:03:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.152.131 with HTTP; Mon, 6 Jun 2016 16:02:40 -0700 (PDT) From: Idel Pivnitskiy Date: Tue, 7 Jun 2016 02:02:40 +0300 Message-ID: To: webpush@ietf.org Content-Type: multipart/alternative; boundary=001a113fd48629ea550534a414a6 Archived-At: Subject: [Webpush] When UA should send an acknowledgement? X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 23:03:25 -0000 --001a113fd48629ea550534a414a6 Content-Type: text/plain; charset=UTF-8 Just a question: When should UA send an acknowledgement? Immediately after receiving a push message or after decryption/decoding/processing a push message? Best regards, Idel Pivnitskiy -- Twitter: @idelpivnitskiy GitHub: @idelpivnitskiy --001a113fd48629ea550534a414a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just a question:=C2=A0When should UA send an acknowle= dgement? Immediately after receiving a push message or after decryption/dec= oding/processing a push message?

Best regards,
Idel Pivnitski= y
--
GitHub:=C2=A0@idelpivnitskiy=
--001a113fd48629ea550534a414a6-- From nobody Mon Jun 6 16:19:22 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A55912D667 for ; Mon, 6 Jun 2016 16:19:20 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pBTginbymZC for ; Mon, 6 Jun 2016 16:19:18 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB19E12D665 for ; Mon, 6 Jun 2016 16:19:18 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id z123so57628755itg.0 for ; Mon, 06 Jun 2016 16:19:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=k9k+/ikQKpUCNcViJdTo06mb7tKVJFeO3KnnHepf+iw=; b=OsASLVKibdz3qu2hlAJWBfLo4cNyZN0sxwhYQL7/GRqJLIwrb7e4Ec3LS16byt+e+d WJwuH1qpzNga/H9/HYA7+CtA3Js6t0Vxy4qnE+kQByWGo34wkm1f8oS/UCV0WEvf2a5S KrUWGvX9zdArKZpB+S+fJ/Oj7BVjf0Nqcq/jgPH/VL2E8m97YmygZBq1/PHXriePBCGr rxLokpEEsTclUuqoAnu0Ss1ysxYQr/4u9So7koz+UQCOrUGAWSwLekUJPwncL0ooHCpW Za8kmEUustPTUfkawncCKSlKAhv0BWijJZRSD6H+OIfy3fpnENwBn7KrYc1FttDBH1IC y2Ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=k9k+/ikQKpUCNcViJdTo06mb7tKVJFeO3KnnHepf+iw=; b=ZvzGkYpZbyOtPsX40CdMb9ucLV3b6rud9Zdra6LjWOVXlHV/P1giNww2yWOP4WEIH1 bUHRL+tojV6FDQL9/nmJqcBnm+kWl4p7qx8VpLgeyJq9Zr8HHG6PIlKnEgzdPoUijrCF O+gl6aKq5Nv9+Orxku3ZVWyLfV4eIucCcHYTEUL+BASQKQi3/gdmA7b7PJXhoQvrJoZ1 nQhDinmdLaeA+0VxIqAalvSlK79ciAwobJtKzhzT0sHw8RMwz+/T0oidsqj5lace8OM3 qXez17RWV6yS8cVVKdoPhlaHY9SmhCj5D+2BurvlhX8FCZu4hNE8InfhjkzxwjXU0LOC FdfA== X-Gm-Message-State: ALyK8tIYgXJy66NZ8ShuBpYTK9Zq0aZ7ShvyaCt3OhTvRO7UNmkuoXHIANbAXXLhCCCV3P+6KrsPgC61d/42hg== X-Received: by 10.36.105.71 with SMTP id e68mr20130968itc.77.1465255158294; Mon, 06 Jun 2016 16:19:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.152.131 with HTTP; Mon, 6 Jun 2016 16:18:38 -0700 (PDT) From: Idel Pivnitskiy Date: Tue, 7 Jun 2016 02:18:38 +0300 Message-ID: To: webpush@ietf.org Content-Type: multipart/alternative; boundary=001a11452a88372f960534a44dfe Archived-At: Subject: [Webpush] 414 Request-URL Too Long X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 23:19:20 -0000 --001a11452a88372f960534a44dfe Content-Type: text/plain; charset=UTF-8 Let's consider usage of 414 status code for the long URIs. Related issue: https://github.com/webpush-wg/webpush-protocol/issues/111 Best regards, Idel Pivnitskiy -- Twitter: @idelpivnitskiy GitHub: @idelpivnitskiy --001a11452a88372f960534a44dfe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Let's consider usage of 414 status code for the l= ong URIs.


Best= regards,
Idel Pivnitskiy
--
--001a11452a88372f960534a44dfe-- From nobody Mon Jun 6 17:17:33 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7224912B053 for ; Mon, 6 Jun 2016 17:17: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wb-4FNIea9iO for ; Mon, 6 Jun 2016 17:17:31 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE9D712D1BE for ; Mon, 6 Jun 2016 17:17:30 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id z189so59926181itg.0 for ; Mon, 06 Jun 2016 17:17:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=SKq5c10tZnqKjY0bKK87ARMuic81Irysr3t9fdYUcx8=; b=fDPuv+w8rFIpntzY4TyqOv6p50QHRRc8XveQaZXCceEjxQfFEiDmJVkrDPbK769E1Q hJmQWixV5Pqtp9sebzdGjDvxegrUsMRworxuTLIdeHjSrKdJHvVBsDY9s3SjwkLDboiD dje2Q6JRO4i8gyziVGppMe4sqe710or+TL43QnNxIuY9abga4fxEJm5Kc40IhBeZIso7 oagYdyiIu/EgwvBDmKnFI4voCmNvMU1PbrnihtdnCIRsZiSDST1SmsBM6XD2tKgH7REx LXdoM5WyBjpPmnZz8/VZoQt1Scj8LdgYg14VqsJSBNkQJqEGM4AQfL+K9uagMUy2HyY0 QHQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=SKq5c10tZnqKjY0bKK87ARMuic81Irysr3t9fdYUcx8=; b=KOEYz1YAGxDhpBzOJJidKAKHmafJ+nTVQdSMjFUKwlRXyDXNPbE/aM1fiR4o4CyG0w uHDbxnx7/GthhAvVjzmziNBL5xZW5jk+RL5jLOCIWLenaoDduf+VSQsJFEX/Kp2+BmSj SDk2pZlxOD9pKUEzfbdbrZH+6ztd/mP+TOBba60b6zzwqAkl3C8CRMY+9p97rOylbDLM OC0/vRew62x26cQds8yxQqWuuT+UCMMRh9imKXm2K++y/OxBHWW82I3YDByASfDiDq4F 81b44su9iMrxjOCFBpFH9umKhWSE/KdVfqgjMTaTVU2QWIDc79Z1Mu/MNiGy6EfuUi7T zHhQ== X-Gm-Message-State: ALyK8tJL/92PSVs26uBui1/9XR0GnultwD/ClZTINccsP9x8r0VeycXS+xpEaArfAtujadry7YA2wz0zjXroPA== X-Received: by 10.36.65.138 with SMTP id b10mr1845383itd.77.1465258650189; Mon, 06 Jun 2016 17:17:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.152.131 with HTTP; Mon, 6 Jun 2016 17:16:50 -0700 (PDT) From: Idel Pivnitskiy Date: Tue, 7 Jun 2016 03:16:50 +0300 Message-ID: To: webpush@ietf.org Content-Type: multipart/alternative; boundary=001a1144805459814b0534a51d00 Archived-At: Subject: [Webpush] Try to deliver receipt at least once, even if TTL expired X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 00:17:32 -0000 --001a1144805459814b0534a51d00 Content-Type: text/plain; charset=UTF-8 After reading all discussions: https://github.com/webpush-wg/webpush-protocol/issues/112 Best regards, Idel Pivnitskiy -- Twitter: @idelpivnitskiy GitHub: @idelpivnitskiy --001a1144805459814b0534a51d00 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Best= regards,
Idel Pivnitskiy
--
--001a1144805459814b0534a51d00-- From nobody Mon Jun 6 17:45:57 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3337112B063 for ; Mon, 6 Jun 2016 17:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMFTNtZgcdE5 for ; Mon, 6 Jun 2016 17:45:53 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0732.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc0c::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D492B12D738 for ; Mon, 6 Jun 2016 17:45:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LTSUW219176SPrcHaqTvd7RgVJD35pbjL7e3CO94lE8=; b=SqMLVWz1ce2n+fu61GbfxlNUi8zrQRSGtMVLcsMstjo/3pP7OeF681ovfHpTldDI5eX4zWkgjeYi+reGUjxGTnIh/VEH7j5ZgNuhnPFkq8LxwiYGi7oM34KULGrq3A+IcTsOzg450Qq9aXfxW6tIcr7hj3M+GFNS6rBVddjxX+8= Received: from BY2PR0301MB0632.namprd03.prod.outlook.com (10.160.63.12) by BY2PR0301MB0632.namprd03.prod.outlook.com (10.160.63.12) with Microsoft SMTP Server (TLS) id 15.1.492.11; Tue, 7 Jun 2016 00:45:52 +0000 Received: from BY2PR0301MB0632.namprd03.prod.outlook.com ([10.160.63.12]) by BY2PR0301MB0632.namprd03.prod.outlook.com ([10.160.63.12]) with mapi id 15.01.0492.020; Tue, 7 Jun 2016 00:45:52 +0000 From: Elio Damaggio To: "webpush@ietf.org" Thread-Topic: [Webpush] Delivery receipts support Thread-Index: AQHRve5vKCZC2BHYGUKWvoiJbF7Otp/dLCvg Date: Tue, 7 Jun 2016 00:45:51 +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=elioda@microsoft.com; x-originating-ip: [2001:4898:80e8:9::61c] x-ms-office365-filtering-correlation-id: 6ac31a8d-9044-48ac-1ca8-08d38e6d139e x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0632; 5:d9A+tsn5DES3LzBR4p7Cdu5y4ohhXRly9UhiN/DFKg8vKOi0eFqAC+tP9dFznmUqlwefQxPLFnF/EOhLJcA/iyyoQIJNm2q7MwrwZ5vasvCXbyC0fodgcWU6fyL5ksuaYXkQlF0oqdl8IZX9jDjd+Q==; 24:EbtKpcwLlXsnN8+G2vx+K7ZBl5I9nQJNFMcUVEO5EOB6QznXYoWX1C17bDvFU4/gZqGw1mmhUdK3uqcuJ0+7rMNCZ6l5+VW1u7HuqW34sXQ=; 7:bXDRxkyr8Wy8o6weMclWKoVw7Ah8d3KYwUbvXQSa6kdcidotvduPnolvnpt/i37iozSPvEiLC/57XqeRM9spcX5/Q0q4uBrpelbeDFxdla01SkoVx/ptn+JJEK+aM2NbS7Z15mevIz/ZHr0k+i0SIo3R6m7uOnWDuSkMWs4JhpFsyVrmJ8H//UHTDa2KYGnFY9L/hRS/hezJKD/x5ZxhtUwI0na00LKzY+5mKcbEWGW2XQwtlHCtNg5GNuOgx+cy x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0301MB0632; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078)(219752817060721)(36081394915603); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BY2PR0301MB0632; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0632; x-forefront-prvs: 09669DB681 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(199003)(12063002)(189002)(3905003)(10290500002)(76176999)(10400500002)(10090500001)(105586002)(101416001)(68736007)(5005710100001)(86612001)(2906002)(99286002)(8990500004)(450100001)(1730700003)(81166006)(2950100001)(15975445007)(19580395003)(50986999)(54356999)(2501003)(76576001)(11100500001)(8676002)(122556002)(2900100001)(19580405001)(8936002)(92566002)(5008740100001)(81156014)(87936001)(3280700002)(74316001)(9686002)(5004730100002)(86362001)(5003600100002)(189998001)(77096005)(3660700001)(6116002)(106356001)(106116001)(97736004)(2351001)(107886002)(110136002)(5002640100001)(33656002)(586003)(5640700001)(102836003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0632; H:BY2PR0301MB0632.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2016 00:45:51.7330 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0632 Archived-At: Subject: Re: [Webpush] Delivery receipts support X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 00:45:56 -0000 I would prefer not to reopen this. For context, at the time it was decided to avoid making this optional in or= der to avoid fragmentation, especially possible for multiplatform apps. In my times at Notification Hubs, this was a critical feature that many cus= tomers have to implement on their own, using their own channel, and negativ= ely affecting battery life with additional connections. For additional context, Azure Mobile Engagement (https://azure.microsoft.co= m/en-us/services/mobile-engagement/) and similar products (https://www.urba= nairship.com/), all would be able to leverage receipts. -----Original Message----- From: Webpush [mailto:webpush-bounces@ietf.org] On Behalf Of Martin Thomson Sent: Friday, June 3, 2016 4:20 PM To: webpush@ietf.org Subject: [Webpush] Delivery receipts support Costin (on github) said: > Since we have open issues with receipts - can we not make it mandatory ? = It's very unlikely all implementations will be able to support the receipts= any time soon, at least not as push promises. We discussed this in the past. At that time, we decided to make support of= delivery receipts mandatory. Do people want to reopen that issue? Note that I don't believe that any implementation currently supports receip= ts. I had expected that to be a temporary situation, but if people expect = that this will be a problem, now would be a good time to hear of it. _______________________________________________ Webpush mailing list Webpush@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf= .org%2fmailman%2flistinfo%2fwebpush&data=3D01%7c01%7celioda%40microsoft.com= %7c8be5a9d4b6a649ef606e08d38c058cf2%7c72f988bf86f141af91ab2d7cd011db47%7c1&= sdata=3DgfZh5%2bqsN4fxcZ1JsgFp4Jk7WZwkr%2bSWwvZ7b245PrM%3d From nobody Tue Jun 7 16:19:45 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6769612D812 for ; Tue, 7 Jun 2016 16:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5D1j0vts9Jp9 for ; Tue, 7 Jun 2016 16:19:08 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0747.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::747]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 839C912D18E for ; Tue, 7 Jun 2016 16:18:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sCZBG8QdkH1tOQg1xfrSsphVnAyfyMqrq0FR8qbZH6o=; b=L6l50XNgVP7u+YJRciQUT6GjbFZ8OBAiEWNLzsQfjDNOlBpEgRCqW9xLPk1dsR23y7wD8nP/buqSufccINMYapdn6S7uN7knKufCobWC5QQXorUn3dVi6+nqaTC+YqfZnZ7+R7ID+eaDj7CzIMOunAC7WM8eXXt+RIp0Qu62SaM= Received: from BN3PR03MB2403.namprd03.prod.outlook.com (10.166.75.14) by BN3PR03MB2402.namprd03.prod.outlook.com (10.166.75.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.511.8; Tue, 7 Jun 2016 23:15:10 +0000 Received: from BN3PR03MB2403.namprd03.prod.outlook.com ([10.166.75.14]) by BN3PR03MB2403.namprd03.prod.outlook.com ([10.166.75.14]) with mapi id 15.01.0511.010; Tue, 7 Jun 2016 23:15:09 +0000 From: Brian Raymor To: Idel Pivnitskiy , "webpush@ietf.org" Thread-Topic: [Webpush] Different status codes for negative Push Message Receipts Thread-Index: AQHRwEa5vUhTLLwUUEWQzOHJmCGu/Z/eo8Fg Date: Tue, 7 Jun 2016 23:15:09 +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: [24.16.23.27] x-ms-office365-filtering-correlation-id: 7a8ef54e-a2d3-4ccd-fcff-08d38f29923e x-microsoft-exchange-diagnostics: 1; BN3PR03MB2402; 5:n1mmkmCG+uEXwaXinqJNItN+h/jTM569CIaGhJ3/qfOZPaPGy5iJbUSyifqnD05iR/slKHuxPdi86fTQE+O/HhOraTxNlR1AMmU7sGxUtSE3C/30vQu2Ql9bEo/gGBapwMssNA3PqBm2QbzGmpJCmQ==; 24:+nmzxjIRosuQGEeCKUlWdMlnOH/9UHTYA/WO5Tjc9fsVXZDFpYg4qu6yGdpTxQrSge33zdXeEXIn96tWb57IegQ4gz1zmeeH1dVCvOwHa+A=; 7:slvsHdR+Q9N4s8ljTWhpmqKiNe4Ey6aFWotSbO4wETu46/Ef9T8B5rHAz+0OkyFTXxMmqjE6hhnVOMEC13Y82uC+WoN9QEeJIjZxpOxy4/WNFaLspd5m/qkUVbOJdyAJKv7eHL9UzaHzy/7k3akz90cp1HhDR0xy5etInlQX3tharbuHjZlKA1ChkP8D5l79A8bxtOjELdI8qtwdz+2BesRf2m5kO+p9k/Ahvpa6gLPFMmAWfvxPfW1JwdrRb+0p x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB2402; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BN3PR03MB2402; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB2402; x-forefront-prvs: 09669DB681 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(12063002)(199003)(189002)(24454002)(377454003)(5008740100001)(68736007)(99286002)(5001770100001)(2501003)(8936002)(2906002)(106116001)(87936001)(97736004)(10400500002)(8990500004)(6116002)(3280700002)(5005710100001)(33656002)(10290500002)(105586002)(3846002)(76576001)(122556002)(5004730100002)(102836003)(106356001)(86612001)(5002640100001)(107886002)(10090500001)(77096005)(86362001)(54356999)(586003)(50986999)(76176999)(2950100001)(15650500001)(5003600100002)(3660700001)(189998001)(101416001)(66066001)(19580395003)(15975445007)(19580405001)(81166006)(81156014)(74316001)(8676002)(92566002)(2900100001)(9686002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB2402; H:BN3PR03MB2403.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:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2016 23:15:09.7842 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB2402 Archived-At: Subject: Re: [Webpush] Different status codes for negative Push Message Receipts X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 23:19:16 -0000 T24gTW9uZGF5LCBKdW5lIDYsIDIwMTYgMzo1NiBQTSwgSWRlbCBQaXZuaXRza2l5IDxpZGVsLnBp dm5pdHNraXlAZ21haWwuY29tPiB3cm90ZToNCg0KPiBJJ3ZlIGNyZWF0ZWQgYW4gaXNzdWUgb24g R2l0SHViLCByZWxhdGVkIHRvIHRoaXMgZGlzY3Vzc2lvbjrCoA0KPiBodHRwczovL2dpdGh1Yi5j b20vd2VicHVzaC13Zy93ZWJwdXNoLXByb3RvY29sL2lzc3Vlcy8xMTANCj4gQ291bGQgYmUgdXNl ZnVsIGZvciBhbiBBUyB0byBrbm93IHdoYXQgaGFwcGVuZWQgd2l0aCBwdXNoIG1lc3NhZ2UgLyBV QS4NCg0KDQpJ4oCZdmUgYWRkZWQgbXkgY29tbWVudHMgdG8gdGhlIGlzc3VlLg0KDQpUaGFua3Ms DQouLi5Ccmlhbg0KDQoNCg0KDQo= From nobody Tue Jun 7 16:19:48 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 061CA12D18E for ; Tue, 7 Jun 2016 16:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQvjLOdhiuuF for ; Tue, 7 Jun 2016 16:19:13 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0747.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::747]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF32C12D641 for ; Tue, 7 Jun 2016 16:18:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=72Y8wbnc2qqmcy2mWOKFRxEr3mUaDCWtdljSh+vlgtI=; b=fIQUqAL9Yc3u8Ssc7MqhTPxX8UfdSG1m6qTrATOQCjuP5qqrH6KsP9fQWYU6O1JkUD2Hh/x41+wX8ZOasWR9ye05ppu/oXrj5ORqkYmow0IbyWNenB6ItDy4G9quVGY42PvFnC5ayzuGNQ7wAw3JoC8ZdWIOQopSX9p3YriLnbM= Received: from BN3PR03MB2403.namprd03.prod.outlook.com (10.166.75.14) by BN3PR03MB2402.namprd03.prod.outlook.com (10.166.75.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.511.8; Tue, 7 Jun 2016 23:17:32 +0000 Received: from BN3PR03MB2403.namprd03.prod.outlook.com ([10.166.75.14]) by BN3PR03MB2403.namprd03.prod.outlook.com ([10.166.75.14]) with mapi id 15.01.0511.010; Tue, 7 Jun 2016 23:17:32 +0000 From: Brian Raymor To: Costin Manolache , Martin Thomson Thread-Topic: [Webpush] Non-blocking comments on -05 Thread-Index: AQHRu3RQwDJq8LaJ6EaFkMQ0Dd4KCZ/Uf30AgADyW4CAAFBvAIACFwOAgACLvQCAADsggIAGDeOg Date: Tue, 7 Jun 2016 23:17:31 +0000 Message-ID: References: <6af49c2baf1b4e4f884b812d573b947e@Antiope.crf.canon.fr> <989D9268-BE9A-47F7-9181-C0F323D1DA1F@mozilla.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brian.Raymor@microsoft.com; x-originating-ip: [24.16.23.27] x-ms-office365-filtering-correlation-id: bce8a5a5-7471-4b6e-44e5-08d38f29e6f3 x-microsoft-exchange-diagnostics: 1; BN3PR03MB2402; 5:2YQufWbh+mUx6YOh+nIIXYU+bibJTAtyc4JLTuaEA8gtCs+ligV8Ea0BIhQHjJj4XYpB6zq1weUrJlOykOoLLgF1yklEXyZDNwzGIo+YZ70LbHUK5WqGWM0W50GrEWlDG771SgnsftqmjRoT6BFlLQ==; 24:dLFWiZU81Hz4FIFNND9/XoL4w7DDiFqY2sb/XCOaF/DSQk13aP/BH0l196Hn7oN2ZZftHeY8CHPssbHDvZA2fmzyayh1H119Lyd1EZs/8wQ=; 7:XjXCG7ygRCuhEHx+BIIXoX8wn7aeFIonxACGav7iFq7/RhbKTA06+SzcciEqutslNZAZUiD2vp8RWL0XxTJk03o6aky0GSZNhrOv9WjgIVpGVAoVmA5/iEIwe0AiMoIBtTzuk7kdthArOpUPMKVY8KKBHHKEuBv4hc4Fp/5TzACHbC+LE35meyT4OelQ3Pier5hThFifdjuRGLWJ54ARs8r3mjltykYzBeduFYzD54f+cFQvzWAGcKpVvyGozwcy x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB2402; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BN3PR03MB2402; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB2402; x-forefront-prvs: 09669DB681 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(199003)(189002)(24454002)(377454003)(5008740100001)(68736007)(16236675004)(99286002)(5001770100001)(8936002)(11100500001)(2906002)(4326007)(106116001)(87936001)(97736004)(10400500002)(8990500004)(6116002)(790700001)(3280700002)(5005710100001)(93886004)(33656002)(10290500002)(105586002)(3846002)(76576001)(122556002)(5004730100002)(102836003)(106356001)(86612001)(5002640100001)(10090500001)(77096005)(19617315012)(86362001)(54356999)(586003)(19625215002)(50986999)(76176999)(2950100001)(5003600100002)(19609705001)(3660700001)(189998001)(101416001)(66066001)(19580395003)(15975445007)(19580405001)(81166006)(81156014)(74316001)(8676002)(19300405004)(92566002)(2900100001)(9686002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB2402; H:BN3PR03MB2403.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:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR03MB240396B9F24E762D04E61CEB835D0BN3PR03MB2403namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2016 23:17:31.9724 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB2402 Archived-At: Cc: Kit Cambridge , RUELLAN Herve , "webpush@ietf.org" , Peter Beverloo Subject: Re: [Webpush] Non-blocking comments on -05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 23:19:35 -0000 --_000_BN3PR03MB240396B9F24E762D04E61CEB835D0BN3PR03MB2403namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgdGhlcmUgYXJlIG5vIGZ1cnRoZXIgY29tbWVudHMgb3IgcHJvcG9zYWxzLCBJIHdpbGwgY2xv c2UgaHR0cHM6Ly9naXRodWIuY29tL3dlYnB1c2gtd2cvd2VicHVzaC1wcm90b2NvbC9pc3N1ZXMv MTA5DQoNClRoYW5rcywNCuKApkJyaWFuDQoNCg0KRnJvbTogQ29zdGluIE1hbm9sYWNoZSBbbWFp bHRvOmNvc3RpbkBnbWFpbC5jb21dDQpTZW50OiBGcmlkYXksIEp1bmUgMywgMjAxNiA3OjQ4IFBN DQpUbzogTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4NCkNjOiBLaXQg Q2FtYnJpZGdlIDxrY2FtYnJpZGdlQG1vemlsbGEuY29tPjsgQnJpYW4gUmF5bW9yIDxCcmlhbi5S YXltb3JAbWljcm9zb2Z0LmNvbT47IFBldGVyIEJldmVybG9vIDxiZXZlcmxvb0Bnb29nbGUuY29t Pjsgd2VicHVzaEBpZXRmLm9yZzsgUlVFTExBTiBIZXJ2ZSA8SGVydmUuUnVlbGxhbkBjcmYuY2Fu b24uZnI+DQpTdWJqZWN0OiBSZTogW1dlYnB1c2hdIE5vbi1ibG9ja2luZyBjb21tZW50cyBvbiAt MDUNCg0KV2Ugc3VwcG9ydCA0aywgYW5kIGl0IHdvdWxkIGJlIGdyZWF0IHRvIGtlZXAgaXQgYXMg aXMgZm9yIHJlZ3VsYXIgVUENCmFuZCBQUy4NCg0KSG93ZXZlciBpZiB0aGUgcHVzaCBzZXJ2aWNl IGlzIHByb3h5aW5nIHRvIG90aGVyIHByb3RvY29scyAtIHRoZXJlIGFyZQ0Kc2VydmljZXMgbGlt aXRpbmcgdGhlIHNpemUgdG8gMmssIGFuZCBJIGFzc3VtZSBmb3IgSW9UIG9yIG90aGVyIGNhc2Vz DQp0aGUgbGltaXQgbWF5IGJlIGV2ZW4gbG93ZXIuIEluIHN1Y2ggY2FzZXMgdGhlIFBTIGNhbid0 IGRlbGl2ZXIgLSBzbw0Kc2hvdWxkIGluZGljYXRlIHRoZSBjYXVzZS4NCkluIG1vc3QgY2FzZXMg dGhlIEFTIGhhcyBtb3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBVQSAtIHNvIGl0IHNob3VsZG4n dA0KYXR0ZW1wdCB0byBzZW5kIDRrIHRvIGEgbGlnaHRidWxiIHdpdGggMjU2QiBvZiBmcmVlIFJB TS4NCg0KQ29zdGluDQoNCg0KDQoNCk9uIEZyaSwgSnVuIDMsIDIwMTYgYXQgNDoxNiBQTSBNYXJ0 aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPG1haWx0bzptYXJ0aW4udGhvbXNv bkBnbWFpbC5jb20+PiB3cm90ZToNCk9uIDQgSnVuZSAyMDE2IGF0IDAwOjU2LCBDb3N0aW4gTWFu b2xhY2hlIDxjb3N0aW5AZ21haWwuY29tPG1haWx0bzpjb3N0aW5AZ21haWwuY29tPj4gd3JvdGU6 DQo+PiBJbiBzZWN0aW9uIDcuMiwgY291bGQgd2UgY29uc2lkZXIgYWxsb3dpbmcgcHVzaCBzZXJ2 ZXJzIHRvIHJlamVjdCBtZXNzYWdlcw0KPj4gPCA0az8gSWYgdGhlIFBTIGlzIHByb3h5aW5nIHRo ZSBtZXNzYWdlIHRvIGEgdGhpcmQtcGFydHkgc2VydmVyLCB3aGljaA0KPj4gTW96aWxsYSdzIHNl cnZlciBkb2VzIG9uIGlPUyBhbmQgQW5kcm9pZCwgaXQgbWlnaHQgbm90IGJlIGFibGUgdG8gY29u dHJvbA0KPj4gdGhlIHNpemUgbGltaXQuDQo+DQo+DQo+ICsxDQoNCg0KRG8gZWl0aGVyIG9mIHlv dSB3YW50IHRvIHJlY29tbWVuZCBhbiBhbHRlcm5hdGl2ZSBsaW1pdD8gIFRoZSBsaW1pdA0KZXhp c3RzIHNvIHRoYXQgYXBwbGljYXRpb24gc2VydmVycyBjYW4gc2VuZCBtZXNzYWdlcyBvZiBhIGNl cnRhaW4gc2l6ZQ0Kd2l0aG91dCBoYXZpbmcgdG8gd29ycnkgdGhhdCB0aGV5IHdpbGwgYmUgdG9s ZCB0byBnbyBhd2F5LiAgVGhhdCdzIGENCnVzZWZ1bCBwcm9wZXJ0eSB0byBtYWludGFpbi4gIEhv d2V2ZXIsIGlmIHRoZXJlIGFyZSBwcmFjdGljYWwgbGltaXRzDQp0aGF0IG1ha2UgNGsgdG9vIGhh cmQsIHBsZWFzZSBwaWNrIGEgbW9yZSByZWFsaXN0aWMgbGltaXQuICBJcyBpdCAyaz8NCkxlc3M/ DQo= --_000_BN3PR03MB240396B9F24E762D04E61CEB835D0BN3PR03MB2403namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPklmIHRoZXJlIGFyZSBubyBmdXJ0aGVyIGNvbW1lbnRzIG9y IHByb3Bvc2FscywgSSB3aWxsIGNsb3NlDQo8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vd2Vi cHVzaC13Zy93ZWJwdXNoLXByb3RvY29sL2lzc3Vlcy8xMDkiPmh0dHBzOi8vZ2l0aHViLmNvbS93 ZWJwdXNoLXdnL3dlYnB1c2gtcHJvdG9jb2wvaXNzdWVzLzEwOTwvYT48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+4oCmQnJpYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHNwYW4gc3R5bGU9Im1zby1i b29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IENvc3Rp biBNYW5vbGFjaGUgW21haWx0bzpjb3N0aW5AZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+ IEZyaWRheSwgSnVuZSAzLCAyMDE2IDc6NDggUE08YnI+DQo8Yj5Ubzo8L2I+IE1hcnRpbiBUaG9t c29uICZsdDttYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBLaXQg Q2FtYnJpZGdlICZsdDtrY2FtYnJpZGdlQG1vemlsbGEuY29tJmd0OzsgQnJpYW4gUmF5bW9yICZs dDtCcmlhbi5SYXltb3JAbWljcm9zb2Z0LmNvbSZndDs7IFBldGVyIEJldmVybG9vICZsdDtiZXZl cmxvb0Bnb29nbGUuY29tJmd0Ozsgd2VicHVzaEBpZXRmLm9yZzsgUlVFTExBTiBIZXJ2ZSAmbHQ7 SGVydmUuUnVlbGxhbkBjcmYuY2Fub24uZnImZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb V2VicHVzaF0gTm9uLWJsb2NraW5nIGNvbW1lbnRzIG9uIC0wNTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPldlIHN1cHBvcnQgNGssIGFuZCBpdCB3b3VsZCBiZSBncmVhdCB0 byBrZWVwIGl0Jm5ic3A7YXMgaXMgZm9yIHJlZ3VsYXIgVUE8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hbmQgUFMuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93ZXZlciBpZiB0aGUgcHVzaCBzZXJ2aWNlIGlz IHByb3h5aW5nIHRvIG90aGVyIHByb3RvY29scyAtIHRoZXJlIGFyZTxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+c2VydmljZXMgbGltaXRpbmcgdGhl Jm5ic3A7c2l6ZSB0byAyaywgYW5kIEkgYXNzdW1lIGZvciBJb1Qgb3Igb3RoZXIgY2FzZXM8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoZSBsaW1p dCBtYXkgYmUgZXZlbiBsb3dlci4mbmJzcDtJbiBzdWNoIGNhc2VzIHRoZSBQUyBjYW4ndCBkZWxp dmVyIC0gc28mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPnNob3VsZCBpbmRpY2F0ZSB0aGUgY2F1c2UuJm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBtb3N0IGNhc2VzIHRoZSBB UyBoYXMgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgVUEgLSBzbyBpdCBzaG91bGRuJ3Q8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmF0dGVtcHQg dG8gc2VuZCA0ayB0byBhIGxpZ2h0YnVsYiB3aXRoIDI1NkIgb2YgZnJlZSBSQU0uJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNvc3Rp bjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBKdW4gMywgMjAxNiBhdCA0OjE2IFBNIE1hcnRp biBUaG9tc29uICZsdDs8YSBocmVmPSJtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tIj5t YXJ0aW4udGhvbXNvbkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDQgSnVuZSAyMDE2IGF0 IDAwOjU2LCBDb3N0aW4gTWFub2xhY2hlICZsdDs8YSBocmVmPSJtYWlsdG86Y29zdGluQGdtYWls LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNvc3RpbkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+ DQomZ3Q7Jmd0OyBJbiBzZWN0aW9uIDcuMiwgY291bGQgd2UgY29uc2lkZXIgYWxsb3dpbmcgcHVz aCBzZXJ2ZXJzIHRvIHJlamVjdCBtZXNzYWdlczxicj4NCiZndDsmZ3Q7ICZsdDsgNGs/IElmIHRo ZSBQUyBpcyBwcm94eWluZyB0aGUgbWVzc2FnZSB0byBhIHRoaXJkLXBhcnR5IHNlcnZlciwgd2hp Y2g8YnI+DQomZ3Q7Jmd0OyBNb3ppbGxhJ3Mgc2VydmVyIGRvZXMgb24gaU9TIGFuZCBBbmRyb2lk LCBpdCBtaWdodCBub3QgYmUgYWJsZSB0byBjb250cm9sPGJyPg0KJmd0OyZndDsgdGhlIHNpemUg bGltaXQuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7ICYjNDM7MTxicj4NCjxicj4NCjxi cj4NCkRvIGVpdGhlciBvZiB5b3Ugd2FudCB0byByZWNvbW1lbmQgYW4gYWx0ZXJuYXRpdmUgbGlt aXQ/Jm5ic3A7IFRoZSBsaW1pdDxicj4NCmV4aXN0cyBzbyB0aGF0IGFwcGxpY2F0aW9uIHNlcnZl cnMgY2FuIHNlbmQgbWVzc2FnZXMgb2YgYSBjZXJ0YWluIHNpemU8YnI+DQp3aXRob3V0IGhhdmlu ZyB0byB3b3JyeSB0aGF0IHRoZXkgd2lsbCBiZSB0b2xkIHRvIGdvIGF3YXkuJm5ic3A7IFRoYXQn cyBhPGJyPg0KdXNlZnVsIHByb3BlcnR5IHRvIG1haW50YWluLiZuYnNwOyBIb3dldmVyLCBpZiB0 aGVyZSBhcmUgcHJhY3RpY2FsIGxpbWl0czxicj4NCnRoYXQgbWFrZSA0ayB0b28gaGFyZCwgcGxl YXNlIHBpY2sgYSBtb3JlIHJlYWxpc3RpYyBsaW1pdC4mbmJzcDsgSXMgaXQgMms/PGJyPg0KTGVz cz88bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_BN3PR03MB240396B9F24E762D04E61CEB835D0BN3PR03MB2403namp_-- From nobody Tue Jun 7 17:08:53 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A48412D8FF for ; Tue, 7 Jun 2016 17:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mozilla-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVASZxm6Yb13 for ; Tue, 7 Jun 2016 17:08:49 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A1D912D8E0 for ; Tue, 7 Jun 2016 17:08:49 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id n127so29097499iof.3 for ; Tue, 07 Jun 2016 17:08:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=t/v3lq0PjO8anRfh8QaNXiG2T0oJexgx2ZkAn2wuLhs=; b=Vq0fgfLPLIitKdFdK+IfEmsVrd8DPQEUCfd8jRhdua7+EnqRne5zqlQOioZAzkfU3T 6GoZDg691C46kXN5H73XiSwaXJGR4FfmDP6s+Dnvr3uc1piVmj75p1pYQ6OTZ6k9DrOz sSHKPY7T8U47gYODtluVpOjla8dVztR1/KvSBCE2tZhh6CG7nzczo2s8eSqBx6xQMA9C cIt0L1eRuwjwYd/dTLXFWMXUc0RngjwHdbTE7pVZZ2RBROIupPDhxZ9Xn1XuKYN76iBo vYyRMzZFH65oEiaul5X8lTt84ntUKe9YtplfVS74KQATvIrVjhqfJBRtexPBD6nPUqMj lQ7g== 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-transfer-encoding; bh=t/v3lq0PjO8anRfh8QaNXiG2T0oJexgx2ZkAn2wuLhs=; b=Gq2iOViMBWr6kHRnqbmUHCvURq1B7GSrKPQmre01AC6XMmhqo4v0JD5GDuZ1ipA7lJ 5K8DHMnqRSEHURABw/82ruY7wY6GtsyL6tGvPInpowZMfA31snBnUpzyYyxWNa2pm065 mn20htxQFkomHafvhEEQvfnSA0AIr5Olh2/yV2jEe8JctKQlHUbapVR6WIKycSPjJjf2 iVqC4Ij64E37CtCch1xzyZahYJs2xGLHXoLQOWOhxMEUGmLGkooMnCIYPGW9pnV6i10P 3rNf+kZHRj1xfguamqr3XLA16ILzaDbsSpXskb8wWzdQboh7BAxpy2CoE70Y/qnojfBc DwoQ== X-Gm-Message-State: ALyK8tLPF+c49VlPJOw42C9vmz9O+a46/0/5xAc5DZVb9ALLqaqfE8J5tT/NbucbpTVMXEAFa1vS3q4TISmhfqvq MIME-Version: 1.0 X-Received: by 10.107.132.40 with SMTP id g40mr4279709iod.34.1465344528407; Tue, 07 Jun 2016 17:08:48 -0700 (PDT) Received: by 10.79.76.194 with HTTP; Tue, 7 Jun 2016 17:08:48 -0700 (PDT) In-Reply-To: References: Date: Tue, 7 Jun 2016 17:08:48 -0700 Message-ID: From: Benjamin Bangert To: Brian Raymor Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "webpush@ietf.org" , Idel Pivnitskiy Subject: Re: [Webpush] Different status codes for negative Push Message Receipts X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 00:08:52 -0000 I have also added comments to the issue, would it be more appropriate to discuss it here? On Tue, Jun 7, 2016 at 4:15 PM, Brian Raymor w= rote: > On Monday, June 6, 2016 3:56 PM, Idel Pivnitskiy wrote: > >> I've created an issue on GitHub, related to this discussion: >> https://github.com/webpush-wg/webpush-protocol/issues/110 >> Could be useful for an AS to know what happened with push message / UA. > > > I=E2=80=99ve added my comments to the issue. > > Thanks, > ...Brian > > > > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush From nobody Tue Jun 7 19:35:01 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDDAE12D7E1 for ; Tue, 7 Jun 2016 19:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZ4NYeJbDiWO for ; Tue, 7 Jun 2016 19:34:57 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F1AD12D625 for ; Tue, 7 Jun 2016 19:34:57 -0700 (PDT) Received: by mail-qg0-x22e.google.com with SMTP id 93so68188806qgx.2 for ; Tue, 07 Jun 2016 19:34: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:from:date:message-id:subject:to :cc; bh=yGPt3YWV522ERqcBKtrfKwFPixATuqihzK0NMxbTh9c=; b=mp2xBRRlm9uPR2mc75KqHqd4uTXN3yi8zwCl51cfQy215He7xQCXEZJPugervc/h/8 MHeNMr/yMcFrPe5GlZUHlHFad6Cgy+jo/OBH1YZc1uH8a/uD5Tva0XkcgAh9tmq8FDYo K2bkjq7/ONkiaz+JQ5k+jSHcK6zMjg6RorMt9PH82yn//7yQaOksz3RBKDF2N29yZtno 52RgAYFlZn6dtJvuy78zfIf97iUlX7F3ij1KzA++hFUzUFva5knrPcgwN5jA7MkFBp0s 1n4xn2jgNEp4s0vehlvuE48J9QI2mwSD6sb9sCuA9z5Dg5Q/A9QlWthT3YhV/zSQelHE jX3w== 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; bh=yGPt3YWV522ERqcBKtrfKwFPixATuqihzK0NMxbTh9c=; b=b6Dy/PXdiUAUFlTqb3Lwd/P+zi4+JxOz8rA+pvYh18jL5tCHjg9h4jq2JxYm/jUCBd 6/qX1iM9/P54YPRjiBcNf5ykoTVx8EJY3jmQ5gWFrk+msS0vZcLtCTT9cBZrCrApHS7r 8FwFs0+Q4qjv2cHl9jHOSaobJGChbbx521J6Bs4+NhFC7Ilbq/Ugc1LgzW4nB4DcFhN8 17MyfFL585+kGtgpnNMVaPqtBa/CcQL1ZaHZuWp++S7wPeI42Xf51ah2x3/sHwWK4NaZ /tq27ZOEcriLhhOcPvODWU6hn7NnalTtnPFwkUIKTkgURrlDSfMIOLz7f1g+XnQgsnia d18w== X-Gm-Message-State: ALyK8tIOfBxI4Dshou3luArWkBNnsjJkGuaW3JydclTJkI86mDfG2n0YQR/y0nq1dRiSPZGHbBomsgupgpJxSQ== X-Received: by 10.140.32.198 with SMTP id h64mr2380678qgh.53.1465353296450; Tue, 07 Jun 2016 19:34:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.104.110 with HTTP; Tue, 7 Jun 2016 19:34:56 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Wed, 8 Jun 2016 12:34:56 +1000 Message-ID: To: Idel Pivnitskiy Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] When UA should send an acknowledgement? X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 02:34:59 -0000 On 7 June 2016 at 09:02, Idel Pivnitskiy wrote: > Just a question: When should UA send an acknowledgement? Immediately after > receiving a push message or after decryption/decoding/processing a push > message? This is defined in http://w3c.github.io/push-api/index.html#the-push-event (Step 6.5.3 is the acknowledgment.) What a user agent does with the message is outside this spec. From nobody Tue Jun 7 19:59:48 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF9812D967 for ; Tue, 7 Jun 2016 19:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mozilla-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yb_vA41NXtOT for ; Tue, 7 Jun 2016 19:59:43 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::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 504641200A0 for ; Tue, 7 Jun 2016 19:59:43 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id 5so32067247ioy.1 for ; Tue, 07 Jun 2016 19:59:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=gdoTF3zCktvnaZYwZZQyRzweT87GvK3Io/PzSiX3/3w=; b=HmVpoVDsTKdbuSuFmwOGjxJxuevF4uB5PTF7fmWKrMDMvQp4HTbOpCjPSZp+iuoH74 kB49T0pzsFL8DuVt7G0mB2ioaesYpI1QSyVV2xUEvBytZpsmQmAMtp3O/FngHB+MRnR7 megDORgtp41X6x5WZAUfMM0WAWMJ5XA0ehKHpzTlsJ04kqY9Kgx65Xek8S3+jqUkJsMx 3JNsNuHmVy0X1kzkrmNOIQqcR7mu0JuPh58frrAcpbw/gW/Cw1+0BsdUUjyHc15BysKo S1+AmYe3uzyJMNi41RMjAN/IefR4wil2FDjosdaFVA1fuQlOPpeaFHDi5R0CfmsffazF fNxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=gdoTF3zCktvnaZYwZZQyRzweT87GvK3Io/PzSiX3/3w=; b=PvHt/Cc+5YJXDlBiOWXtTnCP48Kmj6+XMKAt2X01ADZl1PQYKt1hAgIkzKciv04lyz QhYAEHMiZOnMbsqwHd+nNVysWsDZte2xbQXlK2EuvfKWRYV3Rr6sRO++M6cMtEPehq85 paXBbNtk3uWt8LZSnoaNGVuibXdX0ljOWfvkNkKHWE7WFCZh8gEDDVQ7/czzPFREZGFw aC4x6zGWorTxWhCk/dEI1xiHOYiVqzL/HdLTRfVoUoXCLQl57Llno58XqvjZL+4pGEY0 6y3JOppNuDVgOMAWS6lDCgthu8OrFIdUIbBXlnhUpUcCMYDw1Ae560jh87PBykzudz/s KxCA== X-Gm-Message-State: ALyK8tKKCrmon7ofIPvepiSiQb0YexAmifIRIdjY1eauNyh+CYQQgciH+mC54VwylnyVv2jJScaNMrMpcuUeAWBR MIME-Version: 1.0 X-Received: by 10.107.201.3 with SMTP id z3mr4731861iof.120.1465354782409; Tue, 07 Jun 2016 19:59:42 -0700 (PDT) Received: by 10.79.76.194 with HTTP; Tue, 7 Jun 2016 19:59:42 -0700 (PDT) In-Reply-To: References: Date: Tue, 7 Jun 2016 19:59:42 -0700 Message-ID: From: Benjamin Bangert To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" , Idel Pivnitskiy Subject: Re: [Webpush] When UA should send an acknowledgement? X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 02:59:46 -0000 On Tue, Jun 7, 2016 at 7:34 PM, Martin Thomson wrote: > On 7 June 2016 at 09:02, Idel Pivnitskiy wrote: >> Just a question: When should UA send an acknowledgement? Immediately after >> receiving a push message or after decryption/decoding/processing a push >> message? > > This is defined in > http://w3c.github.io/push-api/index.html#the-push-event (Step 6.5.3 > is the acknowledgment.) > > What a user agent does with the message is outside this spec. > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush From nobody Tue Jun 7 20:17:43 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D043D12D9A1 for ; Tue, 7 Jun 2016 20:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mozilla-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBDwzwJk9vxf for ; Tue, 7 Jun 2016 20:17:38 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::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 6DA5912D9A9 for ; Tue, 7 Jun 2016 20:17:35 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id 5so32324903ioy.1 for ; Tue, 07 Jun 2016 20:17:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=XVRN7WFTf3Exohn7n+V2QVK1Vc0y8KWQtgP+MRFja+Q=; b=yDUfgbJf6VhdFktNzi4Zmvm2WXRR2+W2S88E1gaApX9/NM2qjJQ699IyKrtcsXZFU2 6xTMiBS+Ba7WZXWvw0n+bDdUHeO1fanTSAKNKG8qWP+QCH2g9huiwQ7iHjOnvmkbzY6B n5PdQJmbN77PJykOnkBYbXHKWWQueIb5JMwQfrlllZbbUTplZiEP4VjyJ1dt1p7MIkEK iTxaV8ewk1xnmhwlZhTLlqThvxW/+jpNtol1Ixm57rAXa8MJw4HnCUYDW25uW7D0HxNo W19UEM6xeXSryvAG6OrhSDIjriUQiyiSRDr6+0nOVDtaDyVROsHYAQPWI76qq+SBHmRP nJvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=XVRN7WFTf3Exohn7n+V2QVK1Vc0y8KWQtgP+MRFja+Q=; b=Dn0ozZGcLTb50/EoGm2Ca16ZHerCZzb/sieM6lz4p6bxrj+k6BurYQoj7+gRmOsSyx icrb1Q+JwKnf86YXhKHKbqYTHbCbywj6+8uORu7ODfJwggpUQz/LIuIfNheG7BeZsxPb K0pooK6ss/bcG5cq97d8PtnYDpb4njyMSU7j1Rfwkoi96noq4lHTjxIQoylJx0G3LuvJ CMlceJxU8ijjUXohMzAyMTAlW2wgtzdYb/hSpQVorI1eNBJg2wlkgaRmk1PbtISD4buI 1s0AjYps7v0NIOnDDGhOd3Cg1OpE+Xn/jdbUgh/ZwBZve3fb2UIw48Y/Qm0k5YJsxBR5 aGsg== X-Gm-Message-State: ALyK8tInoReRPdprUCSan02H57avkM/BhKDHs5lzvS8x7mTtD64aaXp8LaTRKlPj5okZ+Lq/7/oxPCXp1HzOmtiJ MIME-Version: 1.0 X-Received: by 10.107.201.3 with SMTP id z3mr4818129iof.120.1465355854622; Tue, 07 Jun 2016 20:17:34 -0700 (PDT) Received: by 10.79.76.194 with HTTP; Tue, 7 Jun 2016 20:17:34 -0700 (PDT) In-Reply-To: References: Date: Tue, 7 Jun 2016 20:17:34 -0700 Message-ID: From: Benjamin Bangert To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" , Idel Pivnitskiy Subject: Re: [Webpush] When UA should send an acknowledgement? X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 03:17:42 -0000 On Tue, Jun 7, 2016 at 7:34 PM, Martin Thomson wrote: > On 7 June 2016 at 09:02, Idel Pivnitskiy wrote: >> Just a question: When should UA send an acknowledgement? Immediately after >> receiving a push message or after decryption/decoding/processing a push >> message? > > This is defined in > http://w3c.github.io/push-api/index.html#the-push-event (Step 6.5.3 > is the acknowledgment.) > > What a user agent does with the message is outside this spec. For our implementation, we will actually never send more notifications until all sent ones are ack'd. This means if a message is malformed or causes a UA error in a UA that actually follows the DOM spec, it will never get a notification again (except the notification it won't ack). As such, our UA necessarily cannot and will not follow the DOM spec as written. Instead we follow the WebPush spec which appears to conflict with the DOM spec. Per the WebPush spec, 6.2: "To ensure that a push message is properly delivered to the user agent at least once, the user agent MUST acknowledge receipt of the message by performing a HTTP DELETE on the push message resource. " The DOM spec in 6.5.3 notes that if the message is improperly encrypted, the process is halted, and the webpush acknowledgement does *not take place*. The relevant portion of the DOM process: "If the push message could not be decrypted for any reason, discard the message and terminate this process. " This makes it sound as if the following steps (including webpush ack) *must not be run*. Some clarification around this would be great. Cheers, Ben From nobody Tue Jun 7 21:37:06 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82BA212D51A for ; Tue, 7 Jun 2016 21:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ne2_y7P5-jk for ; Tue, 7 Jun 2016 21:37:03 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::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 814D012D180 for ; Tue, 7 Jun 2016 21:36:57 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id s186so79575709qkc.1 for ; Tue, 07 Jun 2016 21:36: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:from:date:message-id:subject:to :cc; bh=FILMZGW4BL4U6eOq9wFH+vQy+3CA95ftv/fj5BuwZBQ=; b=z8cpAAo1xsc1BZSXv0VP4JM43BxObDtNfAWCZ3mD/+m21zgHG1smDqbIDN3WhuhsKT 6RAWaF3310w+1auYCxaDDbzxr3fmcGbPl+uwtVb5jqrjnvv7rvN9zi626W40dtH31DBv Jzc9Stcz2RdBhwCTlrJmFdMtLoLopE3oGktCtjVN/YHK+3Yu77jD7ck/MIbSOyZt5+l0 Q/MnSCihuRGmAOo2fAcGP7c0j/768Uj+vELzK6z80Sx6sZEnuE9Vqo56N2OZds2cEhb9 iwASF76iWGu4oTOw3Ii0sNaXgU9G533aQzsw+9i/TesuiY5Nr217fCxr+zwRJPqVe67v W00g== 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; bh=FILMZGW4BL4U6eOq9wFH+vQy+3CA95ftv/fj5BuwZBQ=; b=bcPgiQDpSCXi42N+zEXC1uyzvsNWdgBXGCk/JHIxJy2sKUw29tbH8R+5nru6g/UX0J Of8XMdICwZ7mDlv7Bl2xK0nlLpEUVXBAjAzjmW+hiWzV1fmwN1iBA4tJP2TZ25ky2/UM T3ov97Ox9q0NjcbyYAyAHPbEEHosIUjROxhijoxctMru8sO/7nArVyU7d0p9wrcZ3WQq w2AVpZ4VjVlIZd4I5smUaL4rT4S2A3b8j6A0a/32oSNHyKQvD8Q58xXkCaUnVTXHpJ+X DwDZwivNjWQeJ43p4JOz1kWjuqoekfjif/BsoURodY+k8SfNx6ElYdio4IH7akfSR2TQ Tilw== X-Gm-Message-State: ALyK8tJ7f2YiaUse/eFhZfu95rafkHKPiAEmfs0Q3WwBFH4FmaP+oavWj2FfPMqDUX6Mept4b3T3wzAlihycGQ== X-Received: by 10.55.138.194 with SMTP id m185mr3001354qkd.48.1465360616651; Tue, 07 Jun 2016 21:36:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.104.110 with HTTP; Tue, 7 Jun 2016 21:36:56 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Wed, 8 Jun 2016 14:36:56 +1000 Message-ID: To: Benjamin Bangert Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" , Idel Pivnitskiy Subject: Re: [Webpush] When UA should send an acknowledgement? X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 04:37:04 -0000 On 8 June 2016 at 13:17, Benjamin Bangert wrote: > For our implementation, we will actually never send more notifications > until all sent ones are ack'd. This means if a message is malformed or > causes a UA error in a UA that actually follows the DOM spec, it will > never get a notification again (except the notification it won't ack). This is fine, as long as you regard unacknowledged messages that you thought were delivered as poisonous after a certain amount of time (or retries, if you do that). If you follow that advice, then progress will eventually be made. I expect that Costin will agree with you, but we've discussed this in the past. The problem here is that an acknowledgment from the user agent doesn't constitute a useful signal. You have moved the problem to a second middle-man. When the user agent acknowledges prior to processing the message, how will the application know that it was processed? Can you guarantee that? When the browser crashes, your message is still lost. The only way for this to be a good signal is to have the acknowledgment be end-to-end. (p.s., I don't know if your assertion is true or not. I don't think that it matters. I should know that code, but it's an absolute rats nest, despite Kit's recent efforts at cleanup.) From nobody Tue Jun 7 22:15:18 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4B6512D662 for ; Tue, 7 Jun 2016 22:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mozilla-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UvhPKXQI52q for ; Tue, 7 Jun 2016 22:15:14 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 191E412D648 for ; Tue, 7 Jun 2016 22:15:13 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id o189so145189012ioe.2 for ; Tue, 07 Jun 2016 22:15:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=lTAgwC7vztPxlYGiXpQI0g8anro2+FOBRzu+kf4IwAk=; b=mpY5W26s4nHzgzmB8frJjLSj689BCEfsMR65tb5/KEyIm3NmpyF1PIyAjKzOuSV+UI SoEx7MxA4+DaQmNgw2w+pJ9DCQabXa3UpxpXiJUf6NHJvwjIkIBQXoeSA74uQUsw5f// Es4CireI7+UXarBjqHVXioLIeaUWgs7KlpeFkxooh5UqfTr4mtBHKDiStxuZWqeciTH/ 3IbIyaz+57NmgDRRvw7KYl/WpNwoPZHoTJubs3cNIIA86Ida+KtKJZt3lMtI1P9JBQXs eC3cMOG1ftuoq7wFfuvONwTkC7GIkp9IHTrmNqeuHBeJxSznIuy1EW2ra04+CvaaFwQP 9BrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=lTAgwC7vztPxlYGiXpQI0g8anro2+FOBRzu+kf4IwAk=; b=Vj+nYFRTvR1pNMdPt2wRR/dNMgT5ZYrT4GnUJ9eDjjQw3cionkieBGufju5BmfYJ5b rmS/LLEs7znHOpewVL5IK7yiPMAKXNWC8LFEJdywYBsiBoZKb+MWTDlADbYNZwNeoLB4 oHyCgWNb41KPXDSGb3Noq7AzHBOkDKymDA3825o3rTiV8vAGtNTJkhEvfcIBe2SM4Pen iFBi5XsN23SCfChvKNozoYuYIQt1VpFOq0DYh0ZgeUhS0Njb91ORv6H2w9WT08ZHO2kX bLDSuahhzP3oAbTN3YcELKmw+9kJ3hJQ4OTlc01nU8V5vC7cAPujaeGnSFw2mVeH1hp+ jdvg== X-Gm-Message-State: ALyK8tJaSNxdjKQ4T+tadcg8tPIq0p1VY09zbeicZfCRH3jXBLShVXxx+E42wD3uTozKG8VOINToXdGmwbuNmhEr MIME-Version: 1.0 X-Received: by 10.107.6.149 with SMTP id f21mr2784272ioi.14.1465362913019; Tue, 07 Jun 2016 22:15:13 -0700 (PDT) Received: by 10.79.76.194 with HTTP; Tue, 7 Jun 2016 22:15:12 -0700 (PDT) In-Reply-To: References: Date: Tue, 7 Jun 2016 22:15:12 -0700 Message-ID: From: Benjamin Bangert To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" , Idel Pivnitskiy Subject: Re: [Webpush] When UA should send an acknowledgement? X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 05:15:17 -0000 On Tue, Jun 7, 2016 at 9:36 PM, Martin Thomson wrote: > On 8 June 2016 at 13:17, Benjamin Bangert wrote: >> For our implementation, we will actually never send more notifications >> until all sent ones are ack'd. This means if a message is malformed or >> causes a UA error in a UA that actually follows the DOM spec, it will >> never get a notification again (except the notification it won't ack). > > > This is fine, as long as you regard unacknowledged messages that you > thought were delivered as poisonous after a certain amount of time (or > retries, if you do that). If you follow that advice, then progress > will eventually be made. This recommendation isn't in the WebPush spec. By mandating that the UA MUST ack every message it's clear that failure to ack a message should result in redelivery attempts. If it's intended that a UA does not need to ack every message, the WebPush spec should be updated to reflect that. I could see a PS reasonably considering messages dead if other messages were ack'd or some other command came over the connection such that the server knew that the client is alive and likely processed it. Automatically ack'ing a message in this manner for the PS has as many problems if not more than requiring the UA to ack every message though. It also introduces a lot of complexity into the PS and may result in very long message delivery times should a UA get bogged down with many improperly encrypted messages. > > I expect that Costin will agree with you, but we've discussed this in > the past. The problem here is that an acknowledgment from the user > agent doesn't constitute a useful signal. You have moved the problem > to a second middle-man. When the user agent acknowledges prior to > processing the message, how will the application know that it was > processed? Can you guarantee that? When the browser crashes, your > message is still lost. Why not change the DOM spec to indicate that if a message was processed and failed for some reason it should still be ack'd? If the same message consistently crashes the browser, I would expect the browser to track that fact and avoid the message again in the future. Clearly we have the choice of guaranteeing that a message will be processed at-most-once, or at-least-once, since a crash immediately after processing could stop the ack from making it back. If the desire is at-most-once, then the UA should ack immediately upon receipt of the message (or the PS can consider it ack'd if a PING frame is returned after sending a message, etc.). The Push DOM spec seems to favor the at-least-once model, in which case it would be appropriate for the UA to always ack a message even if it decrypts improperly, or the SW throws an exception, etc. > > The only way for this to be a good signal is to have the > acknowledgment be end-to-end. > > (p.s., I don't know if your assertion is true or not. I don't think > that it matters. I should know that code, but it's an absolute rats > nest, despite Kit's recent efforts at cleanup.) From nobody Wed Jun 8 00:38:37 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB05312D18D for ; Wed, 8 Jun 2016 00:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAU9W1bUkYLc for ; Wed, 8 Jun 2016 00:38:33 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d: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 093DC12D0A1 for ; Wed, 8 Jun 2016 00:38:33 -0700 (PDT) Received: by mail-qg0-x234.google.com with SMTP id p34so15418qgp.1 for ; Wed, 08 Jun 2016 00:38:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZGuNT4WvTneWpiSpfsc90Sep/I1Lc5n+cNmtetVnSVM=; b=TGBsSES036hFji1P4bl4ODrZzYwDNQD7f4e9z3N4cr1C7nqnalUW0RlVns3zfK4oGe 2zxzgWiZJ6PFjluHyIHaB0ey7iI2tTeSbMGLe++XSgc99uvnx8opsixv7If0Ozojuvqb JvzhtHPKDtElvfLLsA9mI9sb/hE2g2Co7ERJUFNbwhg+gXH9uUpfDHbv1Ka5eJnGv4et kTbj8ByXeEsZvNcsK3/S7FeF0goS3okNmbefl+YMSA3v2La1ylmlAz5JkiMgTCQAqE6q S4h9NYNQG/LZv6y5Y1wVpnQG0eueFxWHtFIY2DeP9+guILahTFd6K0M3kP47eMcxDOyo wbHg== 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; bh=ZGuNT4WvTneWpiSpfsc90Sep/I1Lc5n+cNmtetVnSVM=; b=huhrPf9oUE/IjkgsldFpQXAB7SXWIwLL3shAeUdsv3XcBPtMiu7AJ2xlZaCOzhKzvi VoKaTAVy3D27TMyUm1GMPFrjZKSBK8f/gg8RvD4P7XW1prmgy5NUiFMnne3AYjRTV0vG 3B8l/VLGaRMd+qcCkL+tSatc0nacLR8+F9htoIISe8v0CX084Ti/TYLfkS5jXp0hkWG1 O77ULg3yKrU6/b/HrcrVPbyFFvYsqwZEJasBBujeMq/pSyPxFfBIxQixKacLjXD1LdDq mHCjFm6ZH8aDeg3O5qKLAOJBcvBZ15VMdVFGmPzvG+ZmG424tNacWoRemiL3Z0WbO0EH KGCQ== X-Gm-Message-State: ALyK8tIRdw9pda1yBxW0eJxoG63dmxjqOIqVaY2S8IeE7u2n03NZYG8eX0MKwo9J6FYAZ5LdfSPUwbN2RdPJWg== X-Received: by 10.140.163.65 with SMTP id j62mr3303831qhj.40.1465371512076; Wed, 08 Jun 2016 00:38:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.104.110 with HTTP; Wed, 8 Jun 2016 00:38:31 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Wed, 8 Jun 2016 17:38:31 +1000 Message-ID: To: Benjamin Bangert Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" , Idel Pivnitskiy Subject: Re: [Webpush] When UA should send an acknowledgement? X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 07:38:35 -0000 I'm sorry, I'm confused by your message. I can't decide if you want at-least-once, or at-most-once. End-to-end ack, i.e., ack after successful processing, is in support of at-least-once, which I think is consistent with other decisions we've made in the overall design. On 8 June 2016 at 15:15, Benjamin Bangert wrote: > On Tue, Jun 7, 2016 at 9:36 PM, Martin Thomson wrote: >> On 8 June 2016 at 13:17, Benjamin Bangert wrote: >>> For our implementation, we will actually never send more notifications >>> until all sent ones are ack'd. This means if a message is malformed or >>> causes a UA error in a UA that actually follows the DOM spec, it will >>> never get a notification again (except the notification it won't ack). >> >> >> This is fine, as long as you regard unacknowledged messages that you >> thought were delivered as poisonous after a certain amount of time (or >> retries, if you do that). If you follow that advice, then progress >> will eventually be made. > > This recommendation isn't in the WebPush spec. By mandating that the UA > MUST ack every message it's clear that failure to ack a message should > result in redelivery attempts. > > If it's intended that a UA does not need to ack every message, the WebPush > spec should be updated to reflect that. I could see a PS reasonably > considering messages dead if other messages were ack'd or some other > command came over the connection such that the server knew that > the client is alive and likely processed it. > > Automatically ack'ing a message in this manner for the PS has as many > problems if not more than requiring the UA to ack every message though. > It also introduces a lot of complexity into the PS and may result in very > long message delivery times should a UA get bogged down with many > improperly encrypted messages. > >> >> I expect that Costin will agree with you, but we've discussed this in >> the past. The problem here is that an acknowledgment from the user >> agent doesn't constitute a useful signal. You have moved the problem >> to a second middle-man. When the user agent acknowledges prior to >> processing the message, how will the application know that it was >> processed? Can you guarantee that? When the browser crashes, your >> message is still lost. > > Why not change the DOM spec to indicate that if a message was > processed and failed for some reason it should still be ack'd? > > If the same message consistently crashes the browser, I would expect > the browser to track that fact and avoid the message again in the future. > > Clearly we have the choice of guaranteeing that a message will be > processed at-most-once, or at-least-once, since a crash immediately > after processing could stop the ack from making it back. If the desire > is at-most-once, then the UA should ack immediately upon receipt of > the message (or the PS can consider it ack'd if a PING frame is > returned after sending a message, etc.). > > The Push DOM spec seems to favor the at-least-once model, in which > case it would be appropriate for the UA to always ack a message even > if it decrypts improperly, or the SW throws an exception, etc. > >> >> The only way for this to be a good signal is to have the >> acknowledgment be end-to-end. >> >> (p.s., I don't know if your assertion is true or not. I don't think >> that it matters. I should know that code, but it's an absolute rats >> nest, despite Kit's recent efforts at cleanup.) From nobody Wed Jun 8 06:43:13 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1115012D5D8 for ; Wed, 8 Jun 2016 06:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mozilla-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJ-udGLXuMX6 for ; Wed, 8 Jun 2016 06:43:09 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::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 E13D412D16F for ; Wed, 8 Jun 2016 06:43:00 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id n127so9391151iof.3 for ; Wed, 08 Jun 2016 06:43:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=OeeiMgUfX8kZ0RxM7Sx6Cx+CvHhv1s5RkF1kioqkOMY=; b=rDFSMqeObYA7ds252+M24xAdD8vDSXbQllJQviwqjhpztbRtcwsJ042U/lZKJtUQ/a Hc+sFBdpVnnqXh/9R46NlHOweKG61xUZfvV6oPt58iObJfZTTSDYjnlPKwm68b3c/Lcb yJVfrdJ/f/QZt+OxQwzfw1kACXoZZgtUptcsSouruJQDnUkm6438O4n3bDE+ZXOxlGBj LPN4LFq5FdJYbGg4SrUONXEW8kXK9pZuDeV50An1A2u6xEUQGuKfapFnmUlksyMB7ooE N/qd2WAqg1UlHJ20qHlssmXAwFe8KYzZL3S84V7PdOqvc0K9rqg03RQXGL0CdMRAPm5k YrUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=OeeiMgUfX8kZ0RxM7Sx6Cx+CvHhv1s5RkF1kioqkOMY=; b=FXN5r5GszRjc0e73TyPX+2HvGvQiBOiC7S/BfvfwSRhh6MN7E2VNE842SOIoIiO+Bh cFOxX96Rv5Nq8cAGFzuJCcN5GLOIx//1zs1s4figSgmTEycb5aoJfh5sY5TlAr0pl3k/ 7+2nveCLMPdjcuEgRnOnaat2AEgO+RFFQpCaAeff/ZHzGkHY4AWZx5KcnqDr5UhcQNU0 u4tfHyZOiEJnSykNAUFRzma8ADX5E8LwUe/9aoMaiEb5BdjZ0MRK9CkUVd4d3YHb0OIi gksWrXXCOIBQDfN0j5tUuTXNoWHlXhaGT2rZMt8aayrY/kKSFy6K+VD06er76YEIjF+s uJjw== X-Gm-Message-State: ALyK8tKsM4pDoEny+55rFBZotEEbz7QWo+i//9hTU3BJWNcqhCfCB6fmv77uqGpVlo3BzicQJSNvYfLRmdkD3L5j MIME-Version: 1.0 X-Received: by 10.107.6.149 with SMTP id f21mr5962961ioi.14.1465393379881; Wed, 08 Jun 2016 06:42:59 -0700 (PDT) Received: by 10.79.76.194 with HTTP; Wed, 8 Jun 2016 06:42:59 -0700 (PDT) In-Reply-To: References: Date: Wed, 8 Jun 2016 06:42:59 -0700 Message-ID: From: Benjamin Bangert To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" , Idel Pivnitskiy Subject: Re: [Webpush] When UA should send an acknowledgement? X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 13:43:12 -0000 I'm in support of at-least-once processing, so the ack would occur last per the DOM API. The difference would be that the DOM spec should require ack even if decryption fails or the SW fails for some reason. On Wed, Jun 8, 2016 at 12:38 AM, Martin Thomson wrote: > I'm sorry, I'm confused by your message. I can't decide if you want > at-least-once, or at-most-once. End-to-end ack, i.e., ack after > successful processing, is in support of at-least-once, which I think > is consistent with other decisions we've made in the overall design. > > On 8 June 2016 at 15:15, Benjamin Bangert wrote: >> On Tue, Jun 7, 2016 at 9:36 PM, Martin Thomson wrote: >>> On 8 June 2016 at 13:17, Benjamin Bangert wrote: >>>> For our implementation, we will actually never send more notifications >>>> until all sent ones are ack'd. This means if a message is malformed or >>>> causes a UA error in a UA that actually follows the DOM spec, it will >>>> never get a notification again (except the notification it won't ack). >>> >>> >>> This is fine, as long as you regard unacknowledged messages that you >>> thought were delivered as poisonous after a certain amount of time (or >>> retries, if you do that). If you follow that advice, then progress >>> will eventually be made. >> >> This recommendation isn't in the WebPush spec. By mandating that the UA >> MUST ack every message it's clear that failure to ack a message should >> result in redelivery attempts. >> >> If it's intended that a UA does not need to ack every message, the WebPush >> spec should be updated to reflect that. I could see a PS reasonably >> considering messages dead if other messages were ack'd or some other >> command came over the connection such that the server knew that >> the client is alive and likely processed it. >> >> Automatically ack'ing a message in this manner for the PS has as many >> problems if not more than requiring the UA to ack every message though. >> It also introduces a lot of complexity into the PS and may result in very >> long message delivery times should a UA get bogged down with many >> improperly encrypted messages. >> >>> >>> I expect that Costin will agree with you, but we've discussed this in >>> the past. The problem here is that an acknowledgment from the user >>> agent doesn't constitute a useful signal. You have moved the problem >>> to a second middle-man. When the user agent acknowledges prior to >>> processing the message, how will the application know that it was >>> processed? Can you guarantee that? When the browser crashes, your >>> message is still lost. >> >> Why not change the DOM spec to indicate that if a message was >> processed and failed for some reason it should still be ack'd? >> >> If the same message consistently crashes the browser, I would expect >> the browser to track that fact and avoid the message again in the future. >> >> Clearly we have the choice of guaranteeing that a message will be >> processed at-most-once, or at-least-once, since a crash immediately >> after processing could stop the ack from making it back. If the desire >> is at-most-once, then the UA should ack immediately upon receipt of >> the message (or the PS can consider it ack'd if a PING frame is >> returned after sending a message, etc.). >> >> The Push DOM spec seems to favor the at-least-once model, in which >> case it would be appropriate for the UA to always ack a message even >> if it decrypts improperly, or the SW throws an exception, etc. >> >>> >>> The only way for this to be a good signal is to have the >>> acknowledgment be end-to-end. >>> >>> (p.s., I don't know if your assertion is true or not. I don't think >>> that it matters. I should know that code, but it's an absolute rats >>> nest, despite Kit's recent efforts at cleanup.) From nobody Wed Jun 8 13:12:15 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81CA112D790 for ; Wed, 8 Jun 2016 13:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lpb2v-elvm4z for ; Wed, 8 Jun 2016 13:12:11 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0796.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::796]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4502C12D53A for ; Wed, 8 Jun 2016 13:12:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NTjT+YPJu5Yyss9NgM7wTskE1CiwBMd5k/s1gYk0Phs=; b=V/YChlfC1tvLJ6H9Ag6riRqMrBOBuHDaTaISskGGwBkyTvFbDCWHygMF7VmZtddM/nmocCp7cWRsjsvzhdMKNoHgTEQ+cTBKZJcNQQDyvICs68gDuv1wTCjz8KHWBb7E6ZpogfQgKpd4HGSL9UXW/KeBwUPXddwhk2EI6I1sJ0A= Received: from CO2PR03MB2407.namprd03.prod.outlook.com (10.166.93.137) by DM2PR0301MB0639.namprd03.prod.outlook.com (10.160.96.13) with Microsoft SMTP Server (TLS) id 15.1.497.12; Wed, 8 Jun 2016 20:11:54 +0000 Received: from CO2PR03MB2407.namprd03.prod.outlook.com ([10.166.93.137]) by CO2PR03MB2407.namprd03.prod.outlook.com ([10.166.93.137]) with mapi id 15.01.0517.005; Wed, 8 Jun 2016 20:11:53 +0000 From: Brian Raymor To: Elio Damaggio , "webpush@ietf.org" Thread-Topic: [Webpush] Delivery receipts support Thread-Index: AQHRve5wIgM7r2aAvEWxY9OZtq2b25/dMASAgALWDJA= Date: Wed, 8 Jun 2016 20:11:53 +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: [24.16.23.27] x-ms-office365-filtering-correlation-id: 05621121-ad76-4b96-56ae-08d38fd92264 x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0639; 5:C9ddFwDs3kY0NPyDraSwPmdHXV4jE+3K+QoGyW+IPYyD9H+9c6vGkM21NI6mmyCkbjVG3pk8EqO2pc0mapTy/Jyv8LD8yX1x2joeKih9gpTmmvguc2eT0dUHBXGatRrhe0KR1y8PZL5jmdxJLUh3LQ==; 24:YnasSICsjJMkRyRWDQwqdsbA4dHrMStJT+lG/jMYRMP/nb1Y+zkPW+TKFd9a48yRT+hAv0V5zI09ifCtAuT1IU48fsTjHcWjOwUbX/PJBck=; 7:c9QL4yphq5ocBTzcHkGmFfupkewd8L14ZnUksp+QeOHkAgfgba/mRnnfmf+begq4d30qbAhBkU0kQEnnmgZ/m/YpYr1np6dJLcrdtjRGgTTqKuk03t5WDLzhZ6lmGnDYEz8utDi1MXPaRFW8xC9Qm4zFlYAdQTmw2RcRSH9G+MrHnMmFP9iuKqtSI7SRgn4CFMy7H6xnfDUbvNAniiT0liLhiKuIF0mJ2uBKcSUXYFzN4vZmWgKi+IFGaa1GkAKv x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0639; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(189930954265078)(219752817060721)(36081394915603); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:DM2PR0301MB0639; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0639; x-forefront-prvs: 0967749BC1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(12063002)(3905003)(13464003)(377454003)(106116001)(5002640100001)(102836003)(10090500001)(105586002)(586003)(1511001)(99286002)(2501003)(2900100001)(122556002)(3846002)(74316001)(19580395003)(450100001)(77096005)(5003600100002)(5008740100001)(5005710100001)(10290500002)(2950100001)(9686002)(15975445007)(19580405001)(106356001)(66066001)(10400500002)(107886002)(76576001)(50986999)(2561002)(81156014)(76176999)(2421001)(8676002)(86362001)(33656002)(97736004)(2906002)(101416001)(81166006)(54356999)(3280700002)(68736007)(3660700001)(92566002)(189998001)(8936002)(8990500004)(6116002)(87936001)(5001770100001)(86612001)(5004730100002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0639; H:CO2PR03MB2407.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:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2016 20:11:53.6110 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0639 Archived-At: Subject: Re: [Webpush] Delivery receipts support X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 20:12:13 -0000 If there is no further discussion today, I plan make the edit that I propos= ed in https://github.com/webpush-wg/webpush-protocol/pull/10 -----Original Message----- From: Webpush [mailto:webpush-bounces@ietf.org] On Behalf Of Elio Damaggio Sent: Monday, June 6, 2016 5:46 PM To: webpush@ietf.org Subject: Re: [Webpush] Delivery receipts support I would prefer not to reopen this. For context, at the time it was decided to avoid making this optional in or= der to avoid fragmentation, especially possible for multiplatform apps. In my times at Notification Hubs, this was a critical feature that many cus= tomers have to implement on their own, using their own channel, and negativ= ely affecting battery life with additional connections. For additional context, Azure Mobile Engagement (https://azure.microsoft.co= m/en-us/services/mobile-engagement/) and similar products (https://www.urba= nairship.com/), all would be able to leverage receipts. -----Original Message----- From: Webpush [mailto:webpush-bounces@ietf.org] On Behalf Of Martin Thomson Sent: Friday, June 3, 2016 4:20 PM To: webpush@ietf.org Subject: [Webpush] Delivery receipts support Costin (on github) said: > Since we have open issues with receipts - can we not make it mandatory ? = It's very unlikely all implementations will be able to support the receipts= any time soon, at least not as push promises. We discussed this in the past. At that time, we decided to make support of= delivery receipts mandatory. Do people want to reopen that issue? Note that I don't believe that any implementation currently supports receip= ts. I had expected that to be a temporary situation, but if people expect = that this will be a problem, now would be a good time to hear of it. _______________________________________________ Webpush mailing list Webpush@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf= .org%2fmailman%2flistinfo%2fwebpush&data=3D01%7c01%7celioda%40microsoft.com= %7c8be5a9d4b6a649ef606e08d38c058cf2%7c72f988bf86f141af91ab2d7cd011db47%7c1&= sdata=3DgfZh5%2bqsN4fxcZ1JsgFp4Jk7WZwkr%2bSWwvZ7b245PrM%3d _______________________________________________ Webpush mailing list Webpush@ietf.org https://www.ietf.org/mailman/listinfo/webpush From nobody Wed Jun 8 13:45:08 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA3812D5BF for ; Wed, 8 Jun 2016 13:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQ-BOzQWKBg1 for ; Wed, 8 Jun 2016 13:45:02 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0114.outbound.protection.outlook.com [65.55.169.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4936512D681 for ; Wed, 8 Jun 2016 13:45:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hBFxJDZZRNHps+HADx+cTFQKQK7dk4Ik13KFmJ6lrkk=; b=nhdOzclyyhtH7uXbemkh4cAJO5W00KWynIiRE0xReQfTG4S7CeSA/kUUm6SzInj0rVhhK9144cyfRF5VbVvmBBjN7iXKOYbvlFTFm2c1svcqUA82LM5iGWSji53ls6OfUri1R5tWwYgEu8n766qA7C5CeJ7eJejq2I+2eRqXSFw= Received: from CO2PR03MB2407.namprd03.prod.outlook.com (10.166.93.137) by CO2PR03MB2407.namprd03.prod.outlook.com (10.166.93.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.517.8; Wed, 8 Jun 2016 20:44:59 +0000 Received: from CO2PR03MB2407.namprd03.prod.outlook.com ([10.166.93.137]) by CO2PR03MB2407.namprd03.prod.outlook.com ([10.166.93.137]) with mapi id 15.01.0517.005; Wed, 8 Jun 2016 20:44:59 +0000 From: Brian Raymor To: RUELLAN Herve , "kcambridge@mozilla.com" , Costin Manolache Thread-Topic: [Webpush] Non-blocking comments on -05 Thread-Index: AQHRu3RQwDJq8LaJ6EaFkMQ0Dd4KCZ/Uf30AgADyW4CAAFBvAIAAI8eAgAoob+A= Date: Wed, 8 Jun 2016 20:44:59 +0000 Message-ID: References: <6af49c2baf1b4e4f884b812d573b947e@Antiope.crf.canon.fr> <989D9268-BE9A-47F7-9181-C0F323D1DA1F@mozilla.com> <1464858574.5342.12.camel@crf.canon.fr> In-Reply-To: <1464858574.5342.12.camel@crf.canon.fr> 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: [24.16.23.27] x-ms-office365-filtering-correlation-id: ba84e630-736e-42e9-41e6-08d38fddc1ed x-microsoft-exchange-diagnostics: 1; CO2PR03MB2407; 6:K9j7ss+l3/0DtwwTt6MQjBZfHLYabLmswng99A1gOK/kQiWwT+lyS9/VnLzgVy0TuGidpryWNk9uVHOJDhfLfaVInPXpp3g1TAgua/B6hO8OJj22dx1liNwxPHkGbkBdGoLVBfygn9KnxhJ3bBtbkkJk0Q3jCKxWgqovaWGdwrVBU84bXcEWAJuNSY4B9b7DH/TLgp/Xn5wp6we/nWJlw+vGvwZ800Gc54cyFaxmu05hElrrz68t/qDDJwU8Ujv99uj/BlNbNOtirKXTwDdgAqoLePDw+UNXJja4KpUpEjHmyBzgIJvjFjmp+e1qMmoX; 5:+s20irg0j9b9WaVQCBX4q1fcXXzOOLgEOXgCRT76MsARGc3u9aG4T6nZQzwYx2fasVbcfQA2jBplyqCWMET/dwUNhISe82iq8F9lwDTd9F+6E0GICrEIQmrnU30s6WJw8EqY6PwOT+lpqCw66klf7A==; 24:mLl6Cg6xATLcr1IvLBBdID7kW7tqLnbpyQJ4/tGjAuXwqPyJbkbELv8jdxICnY4m8Y1QeSsWRzMFdheyytTDh3fCoo6zJIp9sMiXaA0rqQI=; 7:YpIyGOgqsMk5SkxCbTVH8nIZkjpgsOYiaEDnqgmatRIMGLAKk5PzFr8Xn0wnfRaqx+YcNSNC4Bfq9GBhFidJFSlsrWnA7kRWJXK01uiGQqemm5QwwAVvhG5gsdOGE/MRDxMevCfoHgbxkWtF6E5k58s7WW/qAEfjoF5N20UYt6kSncsA0hz4aNV/bczp3kvwYD4PeZBH1kJexLaDuJQGaf7yTlezbKT1pT1Kps8Htfo= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR03MB2407; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(72170088055959)(166708455590820)(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CO2PR03MB2407; BCL:0; PCL:0; RULEID:; SRVR:CO2PR03MB2407; x-forefront-prvs: 0967749BC1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(53754006)(199003)(377424004)(189002)(24454002)(3660700001)(87936001)(81166006)(81156014)(93886004)(8676002)(3280700002)(189998001)(86612001)(66066001)(86362001)(586003)(8990500004)(5004730100002)(10090500001)(2501003)(2900100001)(2950100001)(3846002)(102836003)(76576001)(19580405001)(19580395003)(101416001)(5002640100001)(2906002)(97736004)(106356001)(5001770100001)(6116002)(77096005)(92566002)(54356999)(76176999)(122556002)(106116001)(74316001)(50986999)(68736007)(5005710100001)(10290500002)(10400500002)(8936002)(5003600100002)(15975445007)(11100500001)(9686002)(105586002)(4326007)(99286002)(33656002)(5008740100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR03MB2407; H:CO2PR03MB2407.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2016 20:44:59.2686 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR03MB2407 Archived-At: Cc: "martin.thomson@gmail.com" , "webpush@ietf.org" , "beverloo@google.com" Subject: Re: [Webpush] Non-blocking comments on -05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 20:45:06 -0000 VGhhbmtzIHRvIEhlcnZlIGZvciB1cGRhdGluZyB0aGlzIC0gaHR0cHM6Ly9naXRodWIuY29tL3dl YnB1c2gtd2cvd2VicHVzaC1wcm90b2NvbC9wdWxsLzExNA0KDQpLaXQgLSBkb2VzIHRoZSBQUiBh ZGRyZXNzIHlvdXIgZmVlZGJhY2sgYmVsb3c/DQoNCkNvc3RpbiByYWlzZWQgYSBjb25jZXJuIGFi b3V0IHRoaXMgc3BlY2lmaWMgc2VudGVuY2U6DQogIEVhY2ggc3Vic2NyaXB0aW9uIHNldCBjYW4g dGhlbiBiZSBtYW5hZ2VkIGluZGVwZW5kZW50bHksIHdoaWNoIG1pZ2h0IGluY2x1ZGUgYmVpbmcg bW92ZWQgYmV0d2VlbiB1c2VyIGFnZW50cy4NCg0Kbm90aW5nOg0KDQo+IEJUVyAtIEkgYW0gYWxz byBpbnRlcmVzdGVkIGluIHRoZSAnbW92ZSBiZXR3ZWVuIFVBJyB1c2UgY2FzZSwgYnV0IEkgZG9u J3QgdGhpbmsgdGhlcmUgaXMgZW5vdWdoIGltcGxlbWVudGF0aW9uIGFuZCBkYXRhIGFyb3VuZCBp dC4NCg0KRG9lcyBhbnlvbmUgZWxzZSBzaGFyZSB0aGlzIGNvbmNlcm4/DQoNClRoYW5rcywNCi4u LkJyaWFuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBSVUVMTEFOIEhlcnZl IFttYWlsdG86SGVydmUuUnVlbGxhbkBjcmYuY2Fub24uZnJdIA0KU2VudDogVGh1cnNkYXksIEp1 bmUgMiwgMjAxNiAyOjEwIEFNDQpUbzoga2NhbWJyaWRnZUBtb3ppbGxhLmNvbQ0KQ2M6IGJldmVy bG9vQGdvb2dsZS5jb207IEJyaWFuIFJheW1vciA8QnJpYW4uUmF5bW9yQG1pY3Jvc29mdC5jb20+ OyBtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb207IHdlYnB1c2hAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbV2VicHVzaF0gTm9uLWJsb2NraW5nIGNvbW1lbnRzIG9uIC0wNQ0KDQpIaSBLaXQsDQoNCk9u IFRodSwgMjAxNi0wNi0wMiBhdCAwMDowMSAtMDcwMCwgS2l0IENhbWJyaWRnZSB3cm90ZToNCj4g SGkgYWxsLA0KPiANCj4gRmlyc3QsIEknZCBsaWtlIHRvIGVjaG8gUGV0ZXIncyAidGhhbmsgeW91 Ii4gSSdtIHZlcnkgZ3JhdGVmdWwgZm9yIGFsbCB5b3VyIHdvcmsgaW4gcHV0dGluZyB0aGlzIHN0 YW5kYXJkIHRvZ2V0aGVyIGFuZCBtYXJzaGFsaW5nIGZlZWRiYWNrLCBoZXJlIGFuZCBvbiBHaXRI dWIhIEluIGFkZGl0aW9uIHRvIHRoZSBjb21tZW50cyBmcm9tIFBldGVyLCBKUiwgYW5kIEhlcnbD qSwgSSBoYXZlIGEgZmV3IHF1ZXN0aW9ucyBhbmQgc3VnZ2VzdGlvbnMuIE5vbmUgb2YgdGhlbSBi bG9jayB0aGUgV0dMQy4NCj4gDQo+IEluIHNlY3Rpb24gNC4xLCBJJ20gbm90IGNsZWFyIHdoYXQg InVuYWJsZSB0byByZWNlaXZlIHB1c2ggbWVzc2FnZXMgdGhhdCBhcmUgYWdncmVnYXRlZCBmb3Ig dGhlIGxpZmV0aW1lIG9mIHRoZSBzdWJzY3JpcHRpb24iIG1lYW5zLiBJZiB0aGUgVUEgaXMgZm9y d2FyZGluZyByZXF1ZXN0cywgY291bGQgaXQgc3RpbGwgZGlzYWdncmVnYXRlIG1lc3NhZ2VzIHNl bnQgdG8gYSBzdWJzY3JpcHRpb24gc2V0IGJlZm9yZSBkZWxpdmVyaW5nIHRoZW0gdG8gdGhlIG90 aGVyIGNsaWVudHM/DQo+IA0KDQpUaGUgdXNlIGNhc2UgaGVyZSBpcyB0aGF0IHRoZSB1c2VyIGFn ZW50IGlzIGFjdGluZyBhcyBhIHByb3h5IGZvcg0KYW5vdGhlciBjbGllbnQgZm9yIG1vbml0b3Jp bmcgYSBzdWJzY3JpcHRpb24uIFRoaXMgY2FuIGJlIGZvciBleGFtcGxlIGENCmNhbWVyYSB1c2lu ZyBhIG1vYmlsZSBwaG9uZSB0byBtb25pdG9yIGl0cyBzdWJzY3JpcHRpb24uIFRoZQ0Kc3Vic2Ny aXB0aW9uIHNob3VsZCBiZSBsaW5rZWQgdG8gdGhlIGNsaWVudCBhbmQgbm90IHRoZSB1c2VyIGFn ZW50IHRvDQphbGxvdyB0aGUgY2xpZW50IHRvIHVzZSBhbm90aGVyIHVzZXIgYWdlbnQgYXMgYSBw cm94eSB3aXRob3V0IGNoYW5naW5nDQp0aGUgc3Vic2NyaXB0aW9uLg0KDQpJIGp1c3QgY3JlYXRl ZCBhIHB1bGwgcmVxdWVzdCBmb3IgdHJ5aW5nIHRvIG1ha2UgdGhpcyB1c2UgY2FzZSBjbGVhcmVy Og0KaHR0cHM6Ly9naXRodWIuY29tL3dlYnB1c2gtd2cvd2VicHVzaC1wcm90b2NvbC9wdWxsLzk2 DQoNCkNoZWVycywNCg0KSGVydsOpDQo= From nobody Wed Jun 8 15:10:54 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD8A12D736 for ; Wed, 8 Jun 2016 15:10:53 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9x7rfPyeOyCi for ; Wed, 8 Jun 2016 15:10:51 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 CBE8912D68A for ; Wed, 8 Jun 2016 15:10:50 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id h190so20628197ith.1 for ; Wed, 08 Jun 2016 15:10:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t8QMbuEBGNxOHOglUkTHHTmvEdr8pjg9EAFQZmoy4wA=; b=Y5/lM1uZ1APpII76mQEciNwIRBTujy/txmELRxVqk7v5HZEDBDOfYLNuseK8dieWz+ fVCrk5qjXHy5zrbYzV/Z1V08RtWAdrsdTouhBuRprWGF+mNEPKuoNtHnoVkDcKk56fXK kjRF3oc1woSCBe3N3XhNl0iGmZL2d2IjQluZDlB4w/3lIpvKuAqmNysbJohyBdnQsvhe X4D6NnT4grsX3IqHp9N8zGwooL3f/G/rku/8XU5Cqy/lkqYioLLoUSyNOn7XGomb/SqG TWBybhQ0/dI9xltUWJH8aHJyUTeKvx1uSo8+pYgo2pBSdc0Hd+fsyBgTvtOImbthN41q RNpg== 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; bh=t8QMbuEBGNxOHOglUkTHHTmvEdr8pjg9EAFQZmoy4wA=; b=Nd94vnlVoFJG6bgnvZ4Kgrwu9BpKdMbQ+u6rBaHWI6kkygWZifSQK7kkEhN91tEFMW kxdJXC6X7pNDzvVcX8ec0oHOnWPubtgINpUBnDw+yRFkVNhg26IjVsw3p+SwzDrkE/Fe ALyRPbgHDKbPdmU34fuGwYmIS9pV4IlD+xWpDXhYHnY9S4RToP+nve8/s1ZROqFBErjp jrzxgh/ja+tRd1+IkHKmynz2PmP2IcsAQdAmD88ZF1lV9vVdxjeiae9u88bVI7w+pfAj FWQ9MzYCfXXEbgeWbxSGiSJBy0rITi5rpr5HMDP87H9Qr9XUfK8VobFnKVTObJ5B/BfJ y8Ow== X-Gm-Message-State: ALyK8tKaOZghm2+3AnPk3UkgvenkrEKtqrOhR7gpZxo6HbSlhk4WN4ou5pLz23PcinbEV9AFOeiz+JMydtJ9cw== X-Received: by 10.36.123.77 with SMTP id q74mr15944769itc.44.1465423850119; Wed, 08 Jun 2016 15:10:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.152.131 with HTTP; Wed, 8 Jun 2016 15:10:10 -0700 (PDT) In-Reply-To: References: From: Idel Pivnitskiy Date: Thu, 9 Jun 2016 01:10:10 +0300 Message-ID: To: Benjamin Bangert Content-Type: multipart/alternative; boundary=001a11475b2208285e0534cb9444 Archived-At: Cc: Martin Thomson , "webpush@ietf.org" Subject: Re: [Webpush] When UA should send an acknowledgement? X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 22:10:53 -0000 --001a11475b2208285e0534cb9444 Content-Type: text/plain; charset=UTF-8 Agree with Benjamin, In current spec if decryption or decoding fails, ack will not be sent. Consequently, PS will try to resend a message after some delay without ack and situation will repeat again. Lucky if it will not lead the crash of an application again and again. Best regards, Idel Pivnitskiy -- Twitter: @idelpivnitskiy GitHub: @idelpivnitskiy On Wed, Jun 8, 2016 at 4:42 PM, Benjamin Bangert wrote: > I'm in support of at-least-once processing, so the ack would occur last per > the DOM API. The difference would be that the DOM spec should require > ack even if decryption fails or the SW fails for some reason. > > On Wed, Jun 8, 2016 at 12:38 AM, Martin Thomson > wrote: > > I'm sorry, I'm confused by your message. I can't decide if you want > > at-least-once, or at-most-once. End-to-end ack, i.e., ack after > > successful processing, is in support of at-least-once, which I think > > is consistent with other decisions we've made in the overall design. > > > > On 8 June 2016 at 15:15, Benjamin Bangert wrote: > >> On Tue, Jun 7, 2016 at 9:36 PM, Martin Thomson < > martin.thomson@gmail.com> wrote: > >>> On 8 June 2016 at 13:17, Benjamin Bangert > wrote: > >>>> For our implementation, we will actually never send more notifications > >>>> until all sent ones are ack'd. This means if a message is malformed or > >>>> causes a UA error in a UA that actually follows the DOM spec, it will > >>>> never get a notification again (except the notification it won't ack). > >>> > >>> > >>> This is fine, as long as you regard unacknowledged messages that you > >>> thought were delivered as poisonous after a certain amount of time (or > >>> retries, if you do that). If you follow that advice, then progress > >>> will eventually be made. > >> > >> This recommendation isn't in the WebPush spec. By mandating that the UA > >> MUST ack every message it's clear that failure to ack a message should > >> result in redelivery attempts. > >> > >> If it's intended that a UA does not need to ack every message, the > WebPush > >> spec should be updated to reflect that. I could see a PS reasonably > >> considering messages dead if other messages were ack'd or some other > >> command came over the connection such that the server knew that > >> the client is alive and likely processed it. > >> > >> Automatically ack'ing a message in this manner for the PS has as many > >> problems if not more than requiring the UA to ack every message though. > >> It also introduces a lot of complexity into the PS and may result in > very > >> long message delivery times should a UA get bogged down with many > >> improperly encrypted messages. > >> > >>> > >>> I expect that Costin will agree with you, but we've discussed this in > >>> the past. The problem here is that an acknowledgment from the user > >>> agent doesn't constitute a useful signal. You have moved the problem > >>> to a second middle-man. When the user agent acknowledges prior to > >>> processing the message, how will the application know that it was > >>> processed? Can you guarantee that? When the browser crashes, your > >>> message is still lost. > >> > >> Why not change the DOM spec to indicate that if a message was > >> processed and failed for some reason it should still be ack'd? > >> > >> If the same message consistently crashes the browser, I would expect > >> the browser to track that fact and avoid the message again in the > future. > >> > >> Clearly we have the choice of guaranteeing that a message will be > >> processed at-most-once, or at-least-once, since a crash immediately > >> after processing could stop the ack from making it back. If the desire > >> is at-most-once, then the UA should ack immediately upon receipt of > >> the message (or the PS can consider it ack'd if a PING frame is > >> returned after sending a message, etc.). > >> > >> The Push DOM spec seems to favor the at-least-once model, in which > >> case it would be appropriate for the UA to always ack a message even > >> if it decrypts improperly, or the SW throws an exception, etc. > >> > >>> > >>> The only way for this to be a good signal is to have the > >>> acknowledgment be end-to-end. > >>> > >>> (p.s., I don't know if your assertion is true or not. I don't think > >>> that it matters. I should know that code, but it's an absolute rats > >>> nest, despite Kit's recent efforts at cleanup.) > --001a11475b2208285e0534cb9444 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agree with=C2=A0Benjamin,

In current sp= ec if decryption or decoding fails, ack will not be sent.=C2=A0Consequently= , PS will try to resend a message after some delay without ack and situatio= n will repeat again. Lucky if it will not lead the crash of an application = again and again.

Best regards,
Idel Pivnitskiy
--
Twitter: @idelpivnits= kiy
GitHub:=C2=A0@idelpivnitskiy
=

On Wed, Jun 8, 2016 at 4:42 PM, Benjamin Ban= gert <bbangert@mozilla.com> wrote:
I'm in support of at-least-once processing, so the ack wo= uld occur last per
the DOM API. The difference would be that the DOM spec should require
ack even if decryption fails or the SW fails for some reason.

On Wed, Jun 8, 2016 at 12:38 AM, Martin Thomson
<martin.thomson@gmail.com> wrote:
> I'm sorry, I'm confused by your message.=C2=A0 I can't dec= ide if you want
> at-least-once, or at-most-once.=C2=A0 End-to-end ack, i.e., ack after<= br> > successful processing, is in support of at-least-once, which I think > is consistent with other decisions we've made in the overall desig= n.
>
> On 8 June 2016 at 15:15, Benjamin Bangert <bbangert@mozilla.com> wrote:
>> On Tue, Jun 7, 2016 at 9:36 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
>>> On 8 June 2016 at 13:17, Benjamin Bangert <bbangert@mozilla.com> wrote:
>>>> For our implementation, we will actually never send more n= otifications
>>>> until all sent ones are ack'd. This means if a message= is malformed or
>>>> causes a UA error in a UA that actually follows the DOM sp= ec, it will
>>>> never get a notification again (except the notification it= won't ack).
>>>
>>>
>>> This is fine, as long as you regard unacknowledged messages th= at you
>>> thought were delivered as poisonous after a certain amount of = time (or
>>> retries, if you do that).=C2=A0 If you follow that advice, the= n progress
>>> will eventually be made.
>>
>> This recommendation isn't in the WebPush spec. By mandating th= at the UA
>> MUST ack every message it's clear that failure to ack a messag= e should
>> result in redelivery attempts.
>>
>> If it's intended that a UA does not need to ack every message,= the WebPush
>> spec should be updated to reflect that. I could see a PS reasonabl= y
>> considering messages dead if other messages were ack'd or some= other
>> command came over the connection such that the server knew that >> the client is alive and likely processed it.
>>
>> Automatically ack'ing a message in this manner for the PS has = as many
>> problems if not more than requiring the UA to ack every message th= ough.
>> It also introduces a lot of complexity into the PS and may result = in very
>> long message delivery times should a UA get bogged down with many<= br> >> improperly encrypted messages.
>>
>>>
>>> I expect that Costin will agree with you, but we've discus= sed this in
>>> the past.=C2=A0 The problem here is that an acknowledgment fro= m the user
>>> agent doesn't constitute a useful signal.=C2=A0 You have m= oved the problem
>>> to a second middle-man.=C2=A0 When the user agent acknowledges= prior to
>>> processing the message, how will the application know that it = was
>>> processed?=C2=A0 Can you guarantee that?=C2=A0 When the browse= r crashes, your
>>> message is still lost.
>>
>> Why not change the DOM spec to indicate that if a message was
>> processed and failed for some reason it should still be ack'd?=
>>
>> If the same message consistently crashes the browser, I would expe= ct
>> the browser to track that fact and avoid the message again in the = future.
>>
>> Clearly we have the choice of guaranteeing that a message will be<= br> >> processed at-most-once, or at-least-once, since a crash immediatel= y
>> after processing could stop the ack from making it back. If the de= sire
>> is at-most-once, then the UA should ack immediately upon receipt o= f
>> the message (or the PS can consider it ack'd if a PING frame i= s
>> returned after sending a message, etc.).
>>
>> The Push DOM spec seems to favor the at-least-once model, in which=
>> case it would be appropriate for the UA to always ack a message ev= en
>> if it decrypts improperly, or the SW throws an exception, etc.
>>
>>>
>>> The only way for this to be a good signal is to have the
>>> acknowledgment be end-to-end.
>>>
>>> (p.s., I don't know if your assertion is true or not.=C2= =A0 I don't think
>>> that it matters.=C2=A0 I should know that code, but it's a= n absolute rats
>>> nest, despite Kit's recent efforts at cleanup.)

--001a11475b2208285e0534cb9444-- From nobody Wed Jun 8 16:07:44 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFA8F12D0FF for ; Wed, 8 Jun 2016 16:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKYDBPHmV4Pe for ; Wed, 8 Jun 2016 16:07:41 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A08912B064 for ; Wed, 8 Jun 2016 16:07:41 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id o189so23202785ioe.2 for ; Wed, 08 Jun 2016 16:07:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=1z+OgUDJppgxkKqbKSPd9ivF9SEb6l8+9JexUFNf1SI=; b=RLIOQI1AGVdiATWovikZTrjZpbCvFA1Igx7asLyHmbaLFvG7NFYy42FMlhpxbpLnlW I27wDVnUIa3JTnfD3ML7jIFqBtp/BCseDO6n5XNdtYyaq7VqEGweyQSlmFFWkW3DbtPS 2fxvOgTe74LLTWn0CO9EWpblCmS6lBINU5SDiUF8UbNkUNyIFM/O6Ps1KmgvUXsDvnUk EazGmp5pUUXlicsaq8+64pRCYdNJxwfrXdYqCGPTRI0rhkjmE9uvlhwLtov/4t+3kexF qQUFvrVUXeNM9cK+V8lsP0O+xxflD/WfkWEXCyKaUQXO7KGYf0VgiLXzgdZfJczx9mRo oLtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=1z+OgUDJppgxkKqbKSPd9ivF9SEb6l8+9JexUFNf1SI=; b=ajXGG6EMqN4GQ0X1CCZVii5Csd149sRCh1MIaGe/tA3M4IFIpKMriILDPdpoqB4HiB 0QDrvt6cu9iROLd+k8+rwv70J/0sxuVVF2TzpeG1R9JE5is3tHSt9kzHmTh238teIDkb 9Ujt1h9ApdTGwy1lzwP05b5ey1SzJO989yCppHmdtYjwnCGcod0SykBC8EN5g984wAKN tSZT2nHiDi5UXm3CYDyseMg1vwBPSz7uacJ0tvlReL8UlhvthNfJNMLfp3y7HVSwH2fT 0PokCkTtoaMuloeqTbnbGiDtorhqlenvXaRfDAfybs0JV74xpMmPKTb3ogKkmpC3TzAa l2gQ== X-Gm-Message-State: ALyK8tIlEg7DTpOF56cZd5d749VkBw+U0i5yoQFeiF+zmucrpwCMPx/+KSjg0HWdWQ/uC/Owi+ul/A5V77l/AQ== X-Received: by 10.107.31.74 with SMTP id f71mr12462144iof.180.1465427260523; Wed, 08 Jun 2016 16:07:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.152.131 with HTTP; Wed, 8 Jun 2016 16:07:01 -0700 (PDT) From: Idel Pivnitskiy Date: Thu, 9 Jun 2016 02:07:01 +0300 Message-ID: To: webpush@ietf.org Content-Type: multipart/alternative; boundary=001a1141c73a4ecb130534cc5ffd Archived-At: Subject: [Webpush] Delivery receipt may be sent before AS request delivery X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 23:07:43 -0000 --001a1141c73a4ecb130534cc5ffd Content-Type: text/plain; charset=UTF-8 Found out a problem with lost of delivery receipts for push messages with little TTL, an issue was created: https://github.com/webpush-wg/webpush-protocol/issues/115 Best regards, Idel Pivnitskiy -- Twitter: @idelpivnitskiy GitHub: @idelpivnitskiy --001a1141c73a4ecb130534cc5ffd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Found out a problem with lost of delivery receipts for pus= h messages with little TTL, an issue was created:

--001a1141c73a4ecb130534cc5ffd-- From nobody Wed Jun 8 17:59:00 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4004F12D883 for ; Wed, 8 Jun 2016 17:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfT3Opk0zFK5 for ; Wed, 8 Jun 2016 17:58:57 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d: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 BB39012D7F4 for ; Wed, 8 Jun 2016 17:58:57 -0700 (PDT) Received: by mail-qg0-x234.google.com with SMTP id 93so13158292qgx.2 for ; Wed, 08 Jun 2016 17:58: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:from:date:message-id:subject:to :cc; bh=LhuttiSm9m3H9kA80132cBjJjr5pdZ2Q7Xq/BzpVVrc=; b=C1LPh56RMIkwncqUPc1xIl5DQjirzVZhXchFCdspeIsSUlS3Jdk8npdnU4NFM0b04d htAvc5VGxJ8VFR3+Ch7/5MCZFfCzUB4soconlcMXKJ2SMtL1KA+I6RZqFi0cJ4pqk0Yv QpxmX+ZvVCpx/PCJq+cMwUqgBGLe2BdDmSDALlmxNns3KGSfrTlRSzXTra8M7Fk+SIoy +v46kuafD8/ePCu+Tf7C+jvKv9lVgzc0htOOqxNoY7zezrzWDJdET1Ybw3B9oNZMlOlv hHTVf+e1dS+zXAVDdFqCb5ni7vg4fBXJo01HVxPClNa7zs+w7TWgl3QLpFbCi1Vesti1 fq7A== 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; bh=LhuttiSm9m3H9kA80132cBjJjr5pdZ2Q7Xq/BzpVVrc=; b=eO3lKoov9S79EqOwMHa72XFp7EmcpE4URsKpRarYVfMnLCB82ZD2JY7o1ef6t52hdJ +RHUUO0rTj87RXp447sYFVl1VJsExayiu06Kow+q2/uGp4hCaXIhh8uzhBWUBHbMqhbF zX87KoLP1Cp1Bj6ut6D7kU6PTeMTZpWY3+GVAa16jPhAe4pu+A71Ye74ulX1plmfaRO0 BkVBsvSxHF97uCawCPFpdIqx3Fvxg2Idm1ddZD3Kmcsxmu0YbgZ1ZsUl+qMIxSaH7zJN jdVf4eHDbs7XBVyzT2obznb+Zj5pRP3dW7lymv2GvvkEKFwGsDCC30AMXsVA7MhJlhwo dBsQ== X-Gm-Message-State: ALyK8tLS+SWqW5Uz3NeBzFYabIOXz0ctMCfwpYnfgsArUteHfy/qBTB5aOJ25T1JunwoqOudMG2qAZtxzEZEYA== X-Received: by 10.140.101.240 with SMTP id u103mr7096615qge.61.1465433936904; Wed, 08 Jun 2016 17:58:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.104.110 with HTTP; Wed, 8 Jun 2016 17:58:56 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 9 Jun 2016 10:58:56 +1000 Message-ID: To: Benjamin Bangert Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" , Idel Pivnitskiy Subject: Re: [Webpush] When UA should send an acknowledgement? X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 00:58:59 -0000 On 8 June 2016 at 23:42, Benjamin Bangert wrote: > I'm in support of at-least-once processing, so the ack would occur last per > the DOM API. The difference would be that the DOM spec should require > ack even if decryption fails or the SW fails for some reason. So I get the point about decryption: if it is bad, then that won't change next time. But a SW failure makes the application vulnerable to random chance. Sure, the SW might be bad, but badness isn't a terminal condition there in the same way that crypto is. From nobody Wed Jun 8 18:06:44 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91AE612D8D4 for ; Wed, 8 Jun 2016 18:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggF9qtu7ICvU for ; Wed, 8 Jun 2016 18:06:40 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7C0C12D8CD for ; Wed, 8 Jun 2016 18:06:40 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id p22so13515717qka.2 for ; Wed, 08 Jun 2016 18:06:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=tKicJd22tz2jy9FDJpP5Ce1X1a+sefhpEv+G+HOuDQM=; b=ArjX4/OGULITb2uiEQ53922yo6V37FS/bCXO7Xhh5+nqxZp1aaw3MamIFlG19BdVvI iGjOsur0tq8AzmnBoqt+DnaHeB582Qk3/AbiCmVNv3kQ/Z5XE0jwpHW5siiABe+WDwRH 67uAXNBOheui9nVms3tpBIxn435DbtolK0GXBjfaYVvza0BEdAbzTim20cduqQ2WjIWB LYCzZStS6Len13H73nSxTqmYewVoqQ86p88I/UCP9D0bQCd7SLY5FiEsXBNWRQ87poOW fMkEDOk0S0GAF1UzFMSYdy3aSoklZRBbs/BQLZqeRISwxyExL/CwvmvcPIUPjyRwY0qn ha3Q== 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-transfer-encoding; bh=tKicJd22tz2jy9FDJpP5Ce1X1a+sefhpEv+G+HOuDQM=; b=X4rxJXLueuAmTITf9XiXMQNMDMq263uGMSfiybMClvhceljHtpMWXoYlSm6bAujiVB swikVh6AtYKmFsZKD0My+vU2Kmq4kKDglGU6pPHA4yYOf5FhE+mWD129/o8aRYbK3wOx 1Ryln4IeI+ldspWWfEEeE/cqD+hrqM9SIQCOB4smaXz21Y/bAR5VZOWhx1y4kBJW+tck w7Zs8BRybkmNYUYK7CETOV7V6QiHTa4KYB9fuBVlqMo4UGLCJUSGFSqZryFGhBWUTnGe Wdrk0kKpZWznmGAVKXiTiFWnmuBA6QErZXzChME0jPR5HoY+UJffUJhW8TJD5iIiTPNk hq8w== X-Gm-Message-State: ALyK8tIKgqaCjheAAXIzm/K7uNVJltPzF1/YtRdDuYRY2X3xpu501dDcvnnT8yh9VmyZhf7PWHSqo7jtPEcYSw== X-Received: by 10.55.138.194 with SMTP id m185mr7902068qkd.48.1465434399294; Wed, 08 Jun 2016 18:06:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.104.110 with HTTP; Wed, 8 Jun 2016 18:06:38 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 9 Jun 2016 11:06:38 +1000 Message-ID: To: Idel Pivnitskiy Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Delivery receipt may be sent before AS request delivery X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 01:06:42 -0000 For context: > Here may be a problem with push messages with a little value of TTL. Mess= age may be sent to a UA and ack may be received from the UA before the AS w= ill send a HTTP GET request to the receipt subscription resource. PS will r= etry delivering of receipt, but TTL may expire before this. > > To eliminate this problem it would be better to introduce separate resour= ce for an AS: something like /subscribe for a UA, where AS may create a rec= eipt subscription. We originally had the design you describe, but @brianraymor proposed a simpler design that accomplishes the same goals, providing that you recognize that a TTL shorter than the time it takes to poll the receipt subscription resource can result in losing the receipt. The only good solution to this general problem is to have a longer TTL. Even if you fix the "bug" you identified, a short TTL can expire between the time that the message is delivered to the user agent and before the acknowledgment can reach the push service. On 9 June 2016 at 09:07, Idel Pivnitskiy wrote: > Found out a problem with lost of delivery receipts for push messages with > little TTL, an issue was created: > > https://github.com/webpush-wg/webpush-protocol/issues/115 > > Best regards, > Idel Pivnitskiy > -- > Twitter: @idelpivnitskiy > GitHub: @idelpivnitskiy > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > From nobody Wed Jun 8 18:39:00 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D5B12D684 for ; Wed, 8 Jun 2016 18:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mozilla-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jiT3IpuPXyQ for ; Wed, 8 Jun 2016 18:38:56 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0A1C12D1DC for ; Wed, 8 Jun 2016 18:38:55 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id m62so25615789iof.0 for ; Wed, 08 Jun 2016 18:38:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=3P7wM+FczzwD4QWl1/GUgkz/206+DzBKWJddSLA0O84=; b=ar7FMACbgfN880lI1QNSjDTZWvGsVMExjNI4DLunbbaPf/Z+oUwrZfGgkcwVzC67sl xJGmDBfIuNAeBx4gdMDjeaP+zr59SFIV/WF2VCjxGN7pLv0wequaQFxeSI3sGNHnZv0a c6EyecyWuJtRMgSldQuQDAVO3SN+C4Wg5kw4UIXQBrqx9Uc2vMlK01WmcKzT481bF07Z AZ+UJ77pbQHJANqkqRobJQ54UHfCBjLM0C8E45+vhUs/ch5Ouh3FRL0k8lalgbS0aK4x BxB+p/4bRNx9ZFRmsrLLgrJfA6I/bqqbMrSoLUtn8tEDH1LD2tHH56yS4q0o0zY+PF4h Rg7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=3P7wM+FczzwD4QWl1/GUgkz/206+DzBKWJddSLA0O84=; b=gJxiyvxLu4mLZ8NC5glrBe6BtY9oa9k3Dkabd6u20QGAyTux7V9CE0NIZ9P9zLrALR PhNOpbRftwcjb/h6VMxahy0MNWobirYVEeLKOZb11XOyg1IoYIt96lV6AqKPzjXoka10 hTj0PQHmm3ojQUPV+GWReykOuIzZ5lBJWGQeQmO2vG0mS/xq44hFh/5FsOn382aZxR6w J/AFpB5YcGIzrmc+jDZxva7wDxMNLDnemf3l5KXqmEr7lpD2XMEYRdGoDL0sdwRFAThN p3G1fjTm35ODcl1ZKH8km8UH5smTH3QjjU9/jb/H4iIj3vkUoxWsT+gmjEiJPDDRbz6K pX9g== X-Gm-Message-State: ALyK8tIkWe/m/VdjpkGY5oDjYnVSfLwHOWEydmrRN4PxCI2zK6nVnpY4NV0VRTNjczGP+mYoeaJ99DNIvxDQLABD MIME-Version: 1.0 X-Received: by 10.107.197.194 with SMTP id v185mr6043443iof.34.1465436335039; Wed, 08 Jun 2016 18:38:55 -0700 (PDT) Received: by 10.79.76.194 with HTTP; Wed, 8 Jun 2016 18:38:54 -0700 (PDT) In-Reply-To: References: Date: Wed, 8 Jun 2016 18:38:54 -0700 Message-ID: From: Benjamin Bangert To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" , Idel Pivnitskiy Subject: Re: [Webpush] When UA should send an acknowledgement? X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 01:38:59 -0000 On Wed, Jun 8, 2016 at 5:58 PM, Martin Thomson wrote: > On 8 June 2016 at 23:42, Benjamin Bangert wrote: >> I'm in support of at-least-once processing, so the ack would occur last per >> the DOM API. The difference would be that the DOM spec should require >> ack even if decryption fails or the SW fails for some reason. > > So I get the point about decryption: if it is bad, then that won't > change next time. But a SW failure makes the application vulnerable > to random chance. Sure, the SW might be bad, but badness isn't a > terminal condition there in the same way that crypto is. Agreed, I think its sensible for a UA to try the message once more. If a crash or something else bad still occurs, the UA can ack instead of trying for a third time. Given the UA's manage to remember tabs open right before a crash, it doesn't seem far-fetched for a UA to count process attempts for a message-id where a crash occurred afterwards. Cheers, Ben From nobody Wed Jun 8 18:46:50 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0DBA12D8FA for ; Wed, 8 Jun 2016 18:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvu3-88tXdy0 for ; Wed, 8 Jun 2016 18:46:47 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18D4B12D7C5 for ; Wed, 8 Jun 2016 18:46:47 -0700 (PDT) Received: by mail-qg0-x22e.google.com with SMTP id p34so13563774qgp.1 for ; Wed, 08 Jun 2016 18:46:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=v+ROqIE+jfvEG+5KB9obePpO+L/ckyuKlflBTzY1CZ4=; b=NLlu8wo4wUKErusWynd+7Qg7vioDy0yP5dUCjYUlra0yV/JQNc+2aHckuLpqVLmTl4 bwm2QCZDv2OPygr6Gltkr6cR6YtB3j0o4YpWdB7Ed5bMNtQ3hCmirM2HZioShhmU1G+7 kcOAWDpHkCfVy6ea1L9MlJ6zrE+nXbp9NgcIhvTyWj8JR3TrlgTQhRNnLu3DH3iSBiIp bGikmSR6pJKl53PC1FnoA7PXBX+h316rx2BQa68u4882h4A+LxTnnFRRdUmLbGndJuGF FZdKVXCCzen+zjzNedyk0lSzw+/Y4aMEcxPPCNQEJvyKdPJYjG4XBR2ugZh2ceKc2dd+ zmSg== 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; bh=v+ROqIE+jfvEG+5KB9obePpO+L/ckyuKlflBTzY1CZ4=; b=WV+4tfMq6hZ1vySRWwts6d/3KhMsLyncmn03XaT/5YVVqORfBf720fRgDCVWBceMVg EqxEQCsov+PH64fakX3lvfJDK6RO+gCab/+/8hbZGnl3tRnQeQKjKAzBdt6srfat4+do 5Xc7HyIY2OyD2POn4pgUqv36b4AkuaW4iJ91zlUUyBxEivddySSGkX1wyKFBjgu3FpPH L1nrdUK5cFY5vzF0hdmcQpkW74G//EfgZfJF93axYhJGIHKzfRevBRB9nqeQGlV9aNWP cOFl/fm+8SvKpwYCp1hUluXIvofAl385qQechMVZXVYSW3leHJwuFw2ZzVwa2ycs15tY w63A== X-Gm-Message-State: ALyK8tKS4vMeLsfyK+HWFpOvpzQgFaP9YKM6ZLcTuWPmD9GXLaXA6+xwSAuVH/t9LsPTt95iB1/YlFQ+hjjlGA== X-Received: by 10.140.101.240 with SMTP id u103mr7217383qge.61.1465436806227; Wed, 08 Jun 2016 18:46:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.104.110 with HTTP; Wed, 8 Jun 2016 18:46:45 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 9 Jun 2016 11:46:45 +1000 Message-ID: To: Benjamin Bangert Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" , Idel Pivnitskiy Subject: Re: [Webpush] When UA should send an acknowledgement? X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 01:46:49 -0000 On 9 June 2016 at 11:38, Benjamin Bangert wrote: > On Wed, Jun 8, 2016 at 5:58 PM, Martin Thomson wrote: >> On 8 June 2016 at 23:42, Benjamin Bangert wrote: >>> I'm in support of at-least-once processing, so the ack would occur last per >>> the DOM API. The difference would be that the DOM spec should require >>> ack even if decryption fails or the SW fails for some reason. >> >> So I get the point about decryption: if it is bad, then that won't >> change next time. But a SW failure makes the application vulnerable >> to random chance. Sure, the SW might be bad, but badness isn't a >> terminal condition there in the same way that crypto is. > > Agreed, I think its sensible for a UA to try the message once more. If > a crash or something else bad still occurs, the UA can ack instead of > trying for a third time. Given the UA's manage to remember tabs open > right before a crash, it doesn't seem far-fetched for a UA to count > process attempts for a message-id where a crash occurred afterwards. That I can get behind. I have opened a PR for the decryption failure. I will open a second one for the case that the SW rejects multiple times. I think that we have a bit of leeway on that one though. (Note: all of these are for the push API spec. Do you think that we need any changes to the protocol spec as a result of all this?) From nobody Wed Jun 8 19:12:52 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D52FE12D10D for ; Wed, 8 Jun 2016 19:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enkSHzdZqttu for ; Wed, 8 Jun 2016 19:12:48 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8365712B065 for ; Wed, 8 Jun 2016 19:12:48 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id m62so26115322iof.0 for ; Wed, 08 Jun 2016 19:12:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=otASm8BabHrHEKwHW1/4wJi34gA5t0x7+GX37p/a9zY=; b=EIT4vrschgSQbcpy5d7NGKzkpeaUeKCvMKzn/aandXywGU2iyNUUoViJSs+qaBZj+3 8L79LkyW/iFryRvcmYRdip9n3hNtei9hjD39dtoCVx63dMvMA6lE2u8tzx+1dBkRSUY7 pACsYi8spB5Kq9frZ0IPjA6sopWe3Hx838++V3jiuT4Hi662klXtcCKRxTXIaQjuTQNj m2Ds3IsZiied8XNQnQg8p1Np8Y9K4FbB/O9cWBvb2lW8eFr4JNTMws4L2sRUTWoI7L53 kC/z06Vz3C2TiIfc9RbwbwOzf+wv79o3e1BGzcGXn/lTWfsPcTSLwdueAhAylo0qTiy8 zV4g== 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; bh=otASm8BabHrHEKwHW1/4wJi34gA5t0x7+GX37p/a9zY=; b=k6UW7Pnox3UlJw6ibjWyK0uwq8xh5cRc2dfqSRpKgAck7vZfoNKj8lLfryNIqC2dTa Q2BzNjvz7JY6rpcaJnlXOqUdXUELNUcEroXhmk8YiVFrcC6zgELmRZOO0cpzkzek64ij vWv2AawJ6K3yMpOmumX3wWFylopPTYMdMukXSgSKEUZPf/VK9J/LSjwi3KP3f/3q9p/4 LzPOQ7WrEwVdROsnjgmOUi5gGaM3ayU9T1mjpaZ7Nao2PLS4LXGiAP32bOADaAhCPBbu 5aGT1qAdabh9gQLzN1BrwfR3cYSaUHEQXu4pVddZgq+0khz0rJT1OzzoSrNpJ+uyZ06i MpjA== X-Gm-Message-State: ALyK8tLapowJpNkb06WbgO88Ugeg9NzCw+OzwpPOUDPm+nZvNI1QxmpvRs/P8mORSGhAjtcq6KTx3L33U9hrmA== X-Received: by 10.107.148.143 with SMTP id w137mr13126889iod.63.1465438367533; Wed, 08 Jun 2016 19:12:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.152.131 with HTTP; Wed, 8 Jun 2016 19:12:08 -0700 (PDT) In-Reply-To: References: From: Idel Pivnitskiy Date: Thu, 9 Jun 2016 05:12:08 +0300 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113fd4865690a90534cef577 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Delivery receipt may be sent before AS request delivery X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 02:12:51 -0000 --001a113fd4865690a90534cef577 Content-Type: text/plain; charset=UTF-8 I implemented the design which describes as "Before" in this presentation [1] last year. And I agree that interaction of UA in this process is inconvenient. It should be something like this [2], but instead of using token-URI like /receipts/xjTG79I3VuptNWS0DsFu4ihT97aE6UQJ, introduce something more simple, like: POST /subscribe-for-receipt HTTP/1.1 Host: push.example.net Benefits: 1. subscription may be created and receiving Push Message Receipts may be requested before sending a new push message => no delivery receipts will be lost; 2. no need to send a push message to get receipt subscription resource; 3. easy receipt subscription management and receiving receipts (AS may have a separate thread or service for this purpose); 4. simplifying registration of a new push message on PS side: just one new object will be created (a push message), no need to think about management of receipt subscriptions (what it needs to do? return the same receipt subscription or a new one). Even if the 1st issue is not a big deal, because we may increase TTL value, the 4th will simplify a PS and the 3rd will be more appropriate for an AS. I'm also a little bit confused, when reading the draft and see the same sentence, but with different status codes: - Section 5: A 201 (Created) response indicates that the push message was accepted. - Section 5.1: A 202 (Accepted) response indicates that the push message was accepted. - Section 5.4: A 201 (Created) response indicates that the push message replacement was accepted. What will be for replacing Push Message with requesting delivery receipt: "A 202 (Accepted) response indicates that the push message replacement was accepted"? Another advantage: just one status code will be returned when AS requests Push Message delivery. [1] https://www.ietf.org/proceedings/95/slides/slides-95-webpush-1.pdf [2] https://tools.ietf.org/html/draft-ietf-webpush-protocol-04#section-5 Best regards, Idel Pivnitskiy -- Twitter: @idelpivnitskiy GitHub: @idelpivnitskiy On Thu, Jun 9, 2016 at 4:06 AM, Martin Thomson wrote: > For context: > > > Here may be a problem with push messages with a little value of TTL. > Message may be sent to a UA and ack may be received from the UA before the > AS will send a HTTP GET request to the receipt subscription resource. PS > will retry delivering of receipt, but TTL may expire before this. > > > > To eliminate this problem it would be better to introduce separate > resource for an AS: something like /subscribe for a UA, where AS may create > a receipt subscription. > > We originally had the design you describe, but @brianraymor proposed a > simpler design that accomplishes the same goals, providing that you > recognize that a TTL shorter than the time it takes to poll the > receipt subscription resource can result in losing the receipt. > > The only good solution to this general problem is to have a longer TTL. > > Even if you fix the "bug" you identified, a short TTL can expire > between the time that the message is delivered to the user agent and > before the acknowledgment can reach the push service. > > > On 9 June 2016 at 09:07, Idel Pivnitskiy > wrote: > > Found out a problem with lost of delivery receipts for push messages with > > little TTL, an issue was created: > > > > https://github.com/webpush-wg/webpush-protocol/issues/115 > > > > Best regards, > > Idel Pivnitskiy > > -- > > Twitter: @idelpivnitskiy > > GitHub: @idelpivnitskiy > > > > _______________________________________________ > > Webpush mailing list > > Webpush@ietf.org > > https://www.ietf.org/mailman/listinfo/webpush > > > --001a113fd4865690a90534cef577 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I implemented the design which describes as "Before&q= uot; in this presentation [1] last year. And I agree that interaction of UA= in this process is=C2=A0inconvenient. It should be something like this [2]= , but instead of using token-URI like=C2=A0/receipts/xjTG79I3VuptNWS0DsFu4i= hT97aE6UQJ, introduce something more simple, like:

= POST /subscribe-for-receipt HTTP/1.1

Benefits:<= /div>
  1. subscription may be created and receiving Push Message Re= ceipts may be requested before sending a new push message =3D> no delive= ry receipts will be lost;
  2. no need to send a push message to get= receipt subscription resource;
  3. easy receipt subscription manag= ement and receiving receipts (AS may have a separate thread or service for = this purpose);
  4. simplifying registration of a new push message o= n PS side: just one new object will be created (a push message), no need to= think about management of receipt subscriptions (what it needs to do? retu= rn the same receipt subscription or a new one).
Even if the 1st issue is not a big deal, because we may increase TTL val= ue, the 4th will simplify a PS and the 3rd will be more appropriate for an = AS.

I'm also a little bit confused, when readi= ng the draft and see the same sentence, but with different status codes:
  • Section 5:=C2=A0A 201 (Created) response indicates that the= push message was accepted.
  • Section 5.1:=C2=A0A 202 (Accepted) = response indicates that the push message was accepted.
  • Section = 5.4:=C2=A0A 201 (Created) response indicates that the push message replacem= ent was accepted.
What will be for replacing Push M= essage with requesting delivery receipt: "A 202 (Accepted) response in= dicates that the push message replacement was accepted"?
Another advantage: just one status code will be returned when A= S requests Push Message delivery.


Best regards,
Idel Pivnitskiy
--
GitHub:=C2=A0@idelpivnitskiy
=

On Thu, Jun 9, 2016 at 4:06 AM, Martin Thoms= on <martin.thomson@gmail.com> wrote:
For context:

> Here may be a problem with push messages with a little value of TTL. M= essage may be sent to a UA and ack may be received from the UA before the A= S will send a HTTP GET request to the receipt subscription resource. PS wil= l retry delivering of receipt, but TTL may expire before this.
>
> To eliminate this problem it would be better to introduce separate res= ource for an AS: something like /subscribe for a UA, where AS may create a = receipt subscription.

We originally had the design you describe, but @brianraymor proposed a
simpler design that accomplishes the same goals, providing that you
recognize that a TTL shorter than the time it takes to poll the
receipt subscription resource can result in losing the receipt.

The only good solution to this general problem is to have a longer TTL.

Even if you fix the "bug" you identified, a short TTL can expire<= br> between the time that the message is delivered to the user agent and
before the acknowledgment can reach the push service.


On 9 June 2016 at 09:07, Idel Pivnitskiy <idel.pivnitskiy@gmail.com> wrote:
> Found out a problem with lost of delivery receipts for push messages w= ith
> little TTL, an issue was created:
>
> https://github.com/webpush-wg/webpush-= protocol/issues/115
>
> Best regards,
> Idel Pivnitskiy
> --
> Twitter: @idelpivnitskiy
> GitHub: @idelpivnitskiy
>
> _______________________________________________
> Webpush mailing list
> Webpush@ietf.org
> https://www.ietf.org/mailman/listinfo/webpush<= br> >

--001a113fd4865690a90534cef577-- From nobody Thu Jun 9 11:39:51 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B950F12D913 for ; Thu, 9 Jun 2016 11:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mozilla-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RaNdDk9YRJ0F for ; Thu, 9 Jun 2016 11:39:47 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE19712D8F1 for ; Thu, 9 Jun 2016 11:39:47 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id c2so15386069pfa.2 for ; Thu, 09 Jun 2016 11:39:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bfu2Utb9Kdf9HxrsIAATSKs9gSPH24onh7l/QRcuFu0=; b=Nq0a59aIV+R3GPdBYFIPIo1mhDqYPgOnanJRQK9++K2d3KrvBUE7Xj4HHBb6Yhu/5p pfOThLc/gDmrX5IlZV+fEEEvda+rVw8fD8ilDfwHgsvb5hre8QN2N58BG0oM8DZJoHQg MIDDI6e2sg/rEflwOgEVkbiEwiIxow3W5cyMrBW7OTNCK7oBRPiHSeyWz2u1lTmI/0vr T8B8CwAyON+Fw19Vk5RYS8Cy3WB3HNSzzemRzEk//WgSPjpf9Tb6FJfUmtXhEFcuaNv2 m4Wgy/3AufwAU7BEnvS1uZW7CTSwFkX5Ua6lzgZT13wi69Pc2tS2+CTxr4i7bPgPWc5c RT4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bfu2Utb9Kdf9HxrsIAATSKs9gSPH24onh7l/QRcuFu0=; b=ZkFxypzffX2z5VOKAlKfUB5lKU3z7xTvaExP87XsGpQpYPJ9E7ucPH9y5ZF5DwSibK EDakEnBTAGnKcnNTgDARtqf4qaMiAUCXxfMnhaK+kY6GdZC0dMrMeKIn5I86eJ7vSlDJ nG1Cmf6xbnFq/6jZ/XrTQDHXejUxxJHMrfhSlYIBi/esVbTLudzjzGuEFDTJ5AylrHct 3KMnfZdsBS74WcFWKFEsL5UqnwtXHdkq4Iw/1bNH0ityFxXBn3lTeeKnd3LTr6WT5jEZ i0H0w1ikMXfLctnKLuuEz95TaHdt8DbIWhdX4HvKe5Rl8VIUh4tkCmm9YT+zOkOpCK8Y d2sg== X-Gm-Message-State: ALyK8tJSkDYafHd0NKXEcBS7YGzQdQzQxQ17RkiOh9VWTajHrTF/3EtFAOKTm3+cP5OWcwDL X-Received: by 10.98.103.7 with SMTP id b7mr5782363pfc.19.1465497587167; Thu, 09 Jun 2016 11:39:47 -0700 (PDT) Received: from ?IPv6:2620:101:80fc:224:2c56:4df9:4f07:7d77? ([2620:101:80fc:224:2c56:4df9:4f07:7d77]) by smtp.gmail.com with ESMTPSA id et3sm11648849pad.48.2016.06.09.11.39.45 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 09 Jun 2016 11:39:46 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Kit Cambridge In-Reply-To: Date: Thu, 9 Jun 2016 11:40:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6af49c2baf1b4e4f884b812d573b947e@Antiope.crf.canon.fr> <989D9268-BE9A-47F7-9181-C0F323D1DA1F@mozilla.com> To: Brian Raymor X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Costin Manolache , RUELLAN Herve , Martin Thomson , "webpush@ietf.org" , Peter Beverloo Subject: Re: [Webpush] Non-blocking comments on -05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 18:39:51 -0000 Following up: I think keeping the 4k minimum makes sense. It really = depends on the service that=92s proxying the message=85or the = characteristics of the receiving device, as Costin points out. The push server can chunk the message before proxying, per Martin=92s = suggestion. It could also refuse to deliver the message with another = 400-class status code, instead of a 413. On Jun 7, 2016, at 4:17 PM, Brian Raymor = wrote: > If there are no further comments or proposals, I will close = https://github.com/webpush-wg/webpush-protocol/issues/109 > =20 > Thanks, > =85Brian From nobody Thu Jun 9 12:00:57 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C4E12D934 for ; Thu, 9 Jun 2016 12:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mozilla-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lbp9buUIflW4 for ; Thu, 9 Jun 2016 12:00:53 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::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 9652512D914 for ; Thu, 9 Jun 2016 12:00:41 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id t190so15494949pfb.3 for ; Thu, 09 Jun 2016 12:00:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LnR+a39qL7CQTXFVUiM7+Nt089EVog1+2i8+MmtaRhw=; b=TT/9xqHF9DOh91GZXwBiKqQRqZXLX2qkr74ovSTtOOeSPWCbs8ZgF2k+2G9HoST1MS 4KmaDdxBmEhkJWGTiJNbKfPPCPZvLOcKCnVXJI6XLyR1f5k82flumtpWrTIvQiGZVqMT TiNfsIkte2PH0h1JrGwn8IeF+dMushAu3dQgDsBCCvG2vjY3/2p+r5LetIqtiLpHeKFS ZNgaCLntmQwIFLKZYBRxsEGdRScWkZJ6EH9U9K4qd0fOv/cnfDu3OP1vrs1DiZaQLYa9 XT8e0xGCxpjrspRwrzpJ/qQwsdmqJxGQEH3XYQ35ubHkfOI6nffHHee+gkXpa3MVgAN2 JyNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LnR+a39qL7CQTXFVUiM7+Nt089EVog1+2i8+MmtaRhw=; b=IzWhHZVGU5A+7/i6IRoPQy/hAiD+uMWoqMUMlUUqAX/R+sAdv916l6H5OaMqNF2zoF MrNiUlEOccUPx89R7MGq/Mx8ZhYbEmKQcoeW/elqzrm3Giv/Bk1afEuLfYPOeBU1CMOo Jqtib7ZsnhOlEIsJPaEBao2oggtzZHXKtPiyuk7qdnXc6BHQMPMTYIfRfUi9EsIxTV2U q6glGT8yKto7xDnZ5rdMIjQRiw5gyM9oeiHXCQ8O2OaBMCTP4CI1E1zSUmiKjZK0rikp Yx6b+A0v1reo+11U5TeYct4AlQhsziln6dCoUPyC3lwKtD6JBCx1fhKXxkQYfvMreErS uDKQ== X-Gm-Message-State: ALyK8tI356dmCF4SeyHv6HeLTw9/HGEbQipizBS28lMj3AS6yLaZ660ARE8+fcEhg+AOXPMU X-Received: by 10.98.29.81 with SMTP id d78mr356905pfd.142.1465498841036; Thu, 09 Jun 2016 12:00:41 -0700 (PDT) Received: from [10.252.28.174] (corp.mtv2.mozilla.com. [63.245.221.32]) by smtp.gmail.com with ESMTPSA id c13sm11842744pfc.40.2016.06.09.12.00.39 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 09 Jun 2016 12:00:40 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Kit Cambridge In-Reply-To: Date: Thu, 9 Jun 2016 12:01:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2953D35A-1FC9-4765-BBE0-83DBCA8CAC10@mozilla.com> References: <6af49c2baf1b4e4f884b812d573b947e@Antiope.crf.canon.fr> <989D9268-BE9A-47F7-9181-C0F323D1DA1F@mozilla.com> <1464858574.5342.12.camel@crf.canon.fr> To: Brian Raymor X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Costin Manolache , "beverloo@google.com" , "martin.thomson@gmail.com" , "webpush@ietf.org" , RUELLAN Herve Subject: Re: [Webpush] Non-blocking comments on -05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 19:00:56 -0000 On Jun 8, 2016, at 1:44 PM, Brian Raymor = wrote: > Kit - does the PR address your feedback below? Yes, =93monitoring subscriptions for other clients=94 is clearer. Thank = you! > Costin raised a concern about this specific sentence: > Each subscription set can then be managed independently, which might = include being moved between user agents. >=20 > noting: >=20 >> BTW - I am also interested in the 'move between UA' use case, but I = don't think there is enough implementation and data around it. >=20 > Does anyone else share this concern? Does moving a subscription set mean another UA would be able to receive = messages sent to subscriptions in that set? (That is, without requiring = the old UA to drop all its subscriptions and the new UA to reregister).= From nobody Thu Jun 9 14:33:52 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A2D12DA14 for ; Thu, 9 Jun 2016 14:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDIgfqgK6JnI for ; Thu, 9 Jun 2016 14:33:50 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::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 5491512DA13 for ; Thu, 9 Jun 2016 14:33:43 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id u63so28204813qkh.0 for ; Thu, 09 Jun 2016 14:33:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yok+XefJCY86fmojwQ3w+l7jAScBjZ3pOs++vTlQ0Xc=; b=kDvu9GnjAVpLFT0SZboM6GCWNDE/7XVpemEds2/wKuo9RCA9pXED6z7ISEcepI1kxS iN4wWq9GoU37zYE7c8jo1AptuuEb5W1mJuQTKZb0mqLnUUUPnQ8xrttiGR9T06B52j0R 0jVYv7DN9tSNLZXa1ZyDw8tlCpjarqV8S3eKC41uSD+ZXnPymwZnN/jnFs7TTzVWm2zP NJKtngr+1r278fbSBgTEaEHJJ5YrhpKZJ4o3TIOlxWT9JJpt7/1qSw7MyxC9eYKCbfI0 Gw9pyNIkx5FO88eedJjUw3QGkyyvi/CfDWXF8dxSOtO3rrGP8i3XEol+UsoH8kaykaok AiOA== 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; bh=yok+XefJCY86fmojwQ3w+l7jAScBjZ3pOs++vTlQ0Xc=; b=ct3+njBHe49LDyFgk73Y8dvXyLbl8p38KsgB2VenhtHbyins+pgw8qN3xDK6i+b4FI dbJQ9H87oADwmOFoUxJefnVPn9Q7gmTWcBHbTBharxmX3DJZHOb0ItJTaCBMoN7adE9X faT4BkxUbvP6GFj0TgRdqdBTFNqZU7VPAsQ+Wb1abXWW3UUG1zTUf1wLWnq3/3H6c2MB q2SUaz0v3IKsPhioLJnEe42NfhAA3D1JfoReVbiPhc3Zr7jPqXLbJEAEZOmIXd0mKQuo /WztbElOMFPb2pDf1+fpnxZ8sikwhx9Z1e4/f0wIcUhmo5M0bErnh9Ah6Mycqy7OdRuR 47Jw== X-Gm-Message-State: ALyK8tKZrpB6XtcVdyx0OpE7diZw6w4ZSOZGua6sDVhizmAKjiLRvZeMxn5j0yLAS04/VKMWO0lpC9ZwTBQLPQ== X-Received: by 10.55.20.208 with SMTP id 77mr12105306qku.124.1465508022383; Thu, 09 Jun 2016 14:33:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.104.37 with HTTP; Thu, 9 Jun 2016 14:33:41 -0700 (PDT) In-Reply-To: <2953D35A-1FC9-4765-BBE0-83DBCA8CAC10@mozilla.com> References: <6af49c2baf1b4e4f884b812d573b947e@Antiope.crf.canon.fr> <989D9268-BE9A-47F7-9181-C0F323D1DA1F@mozilla.com> <1464858574.5342.12.camel@crf.canon.fr> <2953D35A-1FC9-4765-BBE0-83DBCA8CAC10@mozilla.com> From: Martin Thomson Date: Fri, 10 Jun 2016 07:33:41 +1000 Message-ID: To: Kit Cambridge Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Costin Manolache , Brian Raymor , "beverloo@google.com" , "webpush@ietf.org" , RUELLAN Herve Subject: Re: [Webpush] Non-blocking comments on -05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 21:33:51 -0000 On 10 June 2016 at 05:01, Kit Cambridge wrote: > Does moving a subscription set mean another UA would be able to receive messages sent to subscriptions in that set? (That is, without requiring the old UA to drop all its subscriptions and the new UA to reregister). I think that you have it. If you have 2 subscriptions that are in the same set, they have to be monitored together. If they are in separate sets, then they can be monitored separately. The separation enables intermediation. I don't think that this is a use case that is particularly important for the web case; I confess that it isn't that interesting to me. However, I think that it is an entirely valid use case, and it costs little. It does however enable things on the web side that *are* very interesting to me. Say you have a UA that wants to go into a deep sleep to save power. In that mode, it still wants to receive push messages from several high priority sites. But it doesn't want to get the deal-of-the-day and all that junk from other sites. Now, the UA knows that the push service is unable to discriminate between important and unimportant properly and it doesn't want to risk getting things like text message notifications from unimportant sites. Even if these are normally sent with moderately high urgency, legitimately. If it can split the important sites and the unimportant sites into two subscription sets, then it can monitor the important sites only. That's not possible if you don't allow the UA to control which subscriptions get grouped together. If you want a concrete example, think pagerduty.com vs. skype.com. A call might be entirely undesirable at 3am, but if a production site is on fire, it's wake up time. From nobody Thu Jun 9 15:03:36 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5387512D550 for ; Thu, 9 Jun 2016 15:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mozilla-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 331snXtfmyoS for ; Thu, 9 Jun 2016 15:03:31 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD33E12DA1A for ; Thu, 9 Jun 2016 15:03:30 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id t190so16743307pfb.3 for ; Thu, 09 Jun 2016 15:03:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=TYiHmc+a4C+hYwmLOjkeptipnqzh3KR4rFaMwb68s8I=; b=CZwW/yo8bTCT9SALyJgUpA+X8uAx+xpLiQY6x2HV8ysnk0iCvVYJohtTPE1YB4Gqgb Ap3rqyYoFT61TG9VeCmKKBftwxEjmOQLfIsRDhWP84p4Szwzz8A8qLzOnj5+NvmeqU0D ISjatngrPpGx1zjTJjQ98XvgVf4huTvF/CnNB4iVTaqpRghBt5UWFUIAN/57mrye2QeG 9MiPX9rTaccZ2GMxhw3J8RBKSAJsRK5QxjWOySmmOh7b0QBGN9MwkmfkBnEzjMvfllZB ccdBayiUeV6IQp5rkCNU4zft8wqitbBu73fmz3vAc6TTX4CBgzokMZPiKx81fFgK1qnD Imeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=TYiHmc+a4C+hYwmLOjkeptipnqzh3KR4rFaMwb68s8I=; b=mzI4BC/Gfyiki5LTFRqWveK8BkQxiMhLK7S44odn4fv6OukROe84DPBSMLpaJj6v/q UmN5z9U3IHU+Y0VKcy5ymoHkVA0QehuQX52Tn10MKQLEAUwwrcTENFpms4PNAbujOTJ0 fkwjdRuxyg+N/3w6A5IDVpS05t6aqjCz4fDR+PMtUErBDxHaANku87TD8LXYAPJf0mKn FYzmKkfn/ppv1E87c1KvqvlmhR83VN6taAoD77mYLsUlwSx/AGfK29OInU8W4UtxGssx zXhYLvK6pivDnHzEgxPmXQOSx+o44L6We5wMZl25aW024tXNulv71oNYS/ZjkCI7+pqO 75+A== X-Gm-Message-State: ALyK8tLwY+HrurpXYtjqIEI44vmDVFgbakXBd3PkWO4AghlSQflLSU3gS7oV0M5Sgaf023eX X-Received: by 10.98.85.66 with SMTP id j63mr6791116pfb.90.1465509809814; Thu, 09 Jun 2016 15:03:29 -0700 (PDT) Received: from ?IPv6:2620:101:80fc:224:1d89:264d:e0de:18e7? ([2620:101:80fc:224:1d89:264d:e0de:18e7]) by smtp.gmail.com with ESMTPSA id y2sm12365450pfi.39.2016.06.09.15.03.28 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 09 Jun 2016 15:03:28 -0700 (PDT) To: webpush@ietf.org References: <6af49c2baf1b4e4f884b812d573b947e@Antiope.crf.canon.fr> <989D9268-BE9A-47F7-9181-C0F323D1DA1F@mozilla.com> From: jr conlin Message-ID: Date: Thu, 9 Jun 2016 15:03:30 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:49.0) Gecko/20100101 Thunderbird/49.0a2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------94A07E0D143253D8928A0AE0" Archived-At: Subject: Re: [Webpush] Non-blocking comments on -05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 22:03:34 -0000 This is a multi-part message in MIME format. --------------94A07E0D143253D8928A0AE0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit For some of our bridged protocols, we lose a percentage due to the protocol exchange overhead. Our server knows the limit and usually returns that with a 413 error (I'm fine with our server being non-standard, since I suspect that not all implementations would use bridges the way we do.) Our bridge currently limits to just over 3K, however to Costin's point, I can perceive some future bridge or device having much tighter restrictions. On 6/3/2016 7:48 PM, Costin Manolache wrote: > We support 4k, and it would be great to keep it as is for regular UA > and PS. > > However if the push service is proxying to other protocols - there are > services limiting the size to 2k, and I assume for IoT or other cases > the limit may be even lower. In such cases the PS can't deliver - so > should indicate the cause. > In most cases the AS has more information about the UA - so it shouldn't > attempt to send 4k to a lightbulb with 256B of free RAM. > > Costin > > > > > On Fri, Jun 3, 2016 at 4:16 PM Martin Thomson > > wrote: > > On 4 June 2016 at 00:56, Costin Manolache > wrote: > >> In section 7.2, could we consider allowing push servers to > reject messages > >> < 4k? If the PS is proxying the message to a third-party > server, which > >> Mozilla's server does on iOS and Android, it might not be able > to control > >> the size limit. > > > > > > +1 > > > Do either of you want to recommend an alternative limit? The limit > exists so that application servers can send messages of a certain size > without having to worry that they will be told to go away. That's a > useful property to maintain. However, if there are practical limits > that make 4k too hard, please pick a more realistic limit. Is it 2k? > Less? > > > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush --------------94A07E0D143253D8928A0AE0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
For some of our bridged protocols, we lose a percentage due to the protocol exchange overhead. Our server knows the limit and usually returns that with a 413 error (I'm fine with our server being non-standard, since I suspect that not all implementations would use bridges the way we do.)

Our bridge currently limits to just over 3K, however to Costin's point, I can perceive some future bridge or device having much tighter restrictions.

On 6/3/2016 7:48 PM, Costin Manolache wrote:
We support 4k, and it would be great to keep it as is for regular UA
and PS.

However if the push service is proxying to other protocols - there are
services limiting the size to 2k, and I assume for IoT or other cases
the limit may be even lower. In such cases the PS can't deliver - so 
should indicate the cause. 
In most cases the AS has more information about the UA - so it shouldn't
attempt to send 4k to a lightbulb with 256B of free RAM. 

Costin




On Fri, Jun 3, 2016 at 4:16 PM Martin Thomson <martin.thomson@gmail.com> wrote:
On 4 June 2016 at 00:56, Costin Manolache <costin@gmail.com> wrote:
>> In section 7.2, could we consider allowing push servers to reject messages
>> < 4k? If the PS is proxying the message to a third-party server, which
>> Mozilla's server does on iOS and Android, it might not be able to control
>> the size limit.
>
>
> +1


Do either of you want to recommend an alternative limit?  The limit
exists so that application servers can send messages of a certain size
without having to worry that they will be told to go away.  That's a
useful property to maintain.  However, if there are practical limits
that make 4k too hard, please pick a more realistic limit.  Is it 2k?
Less?


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


--------------94A07E0D143253D8928A0AE0-- From nobody Thu Jun 9 15:20:20 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8AB12B05B for ; Thu, 9 Jun 2016 15:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bc88Hkye2_3U for ; Thu, 9 Jun 2016 15:20:17 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0773.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:773]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 246BF12B00B for ; Thu, 9 Jun 2016 15:20:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UN0W96pp2fcMJFsxB3Kfc7ywrSfhHu/cY0/pzUGeS6M=; b=C0iA9X+goNHP6hIiyQuguhNMtISlp+fPL4c7x9SojqsRiDELW4f77t1D4qKavajOxB7BSLw8Yry3mLjU6avh1dUPa16a3tccy7Xbt78sCrk+ENNHoGcspq69caOSE/62oNMFjws0Zg3xv6NwiKBHNgodV6lCXGn2LudHEl7tw4A= Received: from CO2PR03MB2407.namprd03.prod.outlook.com (10.166.93.137) by CO2PR03MB2407.namprd03.prod.outlook.com (10.166.93.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.517.8; Thu, 9 Jun 2016 22:19:55 +0000 Received: from CO2PR03MB2407.namprd03.prod.outlook.com ([10.166.93.137]) by CO2PR03MB2407.namprd03.prod.outlook.com ([10.166.93.137]) with mapi id 15.01.0517.005; Thu, 9 Jun 2016 22:19:55 +0000 From: Brian Raymor To: "webpush@ietf.org" Thread-Topic: Prefer: wait=0 for Receiving Push Message Receipts Thread-Index: AdHCmaXPqP5E+T/6TVO6nqulqOJ2zg== Date: Thu, 9 Jun 2016 22:19:55 +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: [24.16.23.27] x-ms-office365-filtering-correlation-id: b725e24e-6e9e-4c19-24ec-08d390b42f83 x-microsoft-exchange-diagnostics: 1; CO2PR03MB2407; 6:RerP1WeVrfq1xkZdUNHbpcPGdBdBbWoWsC0y/QmcHNg9gvrVK5oiBDXxdZbXmUO0Lmsg4sPohD4g5nZeweUvaNsaA1jOV9HpJuNhAB4QyjHkoG64vDuTdBzxjp/XZkQ5GR9dR4cIohFg7AJWPTFlnveWQKQY0fRUAhKIzzf94027/joXJVR9eZckruH33g0wdVI8d3DQs5RnokeKaV/3XCKozcXYDKPHlZwe6oMwgXkENg0G/ok62c238lXqr0RHVnH1rCrMLhpj/fVt2M10G3uArVSQmLu6VfvTk/Y41+uqivxARCy731g3lDEjYnUF; 5:0Vs3CCRmP//KW8Su/ntQXRGOVN3vTWcIxkZp2SSCc1gZQDvxdtg/psjQATNLd9WbyCeWwUjKSYQUvEpketLWQVQOCGoXGPjEEmSE3PZF8PlWmtGQiJScKzxDdKVq42z51Wbl4p7BXOl+/VdlWQqagw==; 24:/Jd16bZD0lIzmeoCbcebkkSbUz2zTZyTw50EgxdXHNLjpGNoIL0RT7clvMu+0UHBUNAyYX8WzW/8NNJg+OwV7b0ulC3nz4FF/xixFBpnp/E=; 7:wqM9jlY2htTdmX26IaxZ0HIO/GsrhB39fK5kP9WtuKoyuMs5x1KmwX5MyyzCfPuM4xxjAlgGv4YrtQCw2+L/OOGi3brX+kdf2zWG46ZXDqfDlmHnC4sWdDERHzhdxWzQw76ziQCoJYWtDuad799QfFGN1jDa+NYmnbLtkq5rUrf1ZP0cjtzaH4cAMX29QOyxBIh52Im+VJQEKwo1iVPLt8uSSDBzoaEdRs837MMQR7Q= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR03MB2407; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CO2PR03MB2407; BCL:0; PCL:0; RULEID:; SRVR:CO2PR03MB2407; x-forefront-prvs: 0968D37274 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(78114003)(12063002)(199003)(189002)(3660700001)(81166006)(87936001)(81156014)(2351001)(86612001)(189998001)(5640700001)(3280700002)(33656002)(110136002)(5008740100001)(8676002)(66066001)(586003)(10090500001)(86362001)(5004730100002)(102836003)(76576001)(2900100001)(3846002)(1730700003)(2501003)(15650500001)(10400500002)(2906002)(19580395003)(5002640100001)(77096005)(92566002)(8990500004)(101416001)(54356999)(74316001)(122556002)(10290500002)(5005710100001)(68736007)(50986999)(106356001)(5003600100002)(8936002)(6116002)(9686002)(97736004)(11100500001)(450100001)(107886002)(105586002)(229853001)(15975445007)(99286002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR03MB2407; H:CO2PR03MB2407.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2016 22:19:55.3758 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR03MB2407 Archived-At: Subject: [Webpush] Prefer: wait=0 for Receiving Push Message Receipts X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 22:20:19 -0000 https://github.com/webpush-wg/webpush-protocol/issues/113 Idel has suggested the addition of the Prefer: wait=3D0 option to section 6= .3. Receiving Push Message Receipts to allow application servers to have the same option for immediately checking/receiving receipts as user= agents have for immediately checking/receiving messages. I'd appreciate broader review and comments about whether this is a useful f= eature. =20 The addition to 6.3. Receiving Push Message Receipts would be: An application server can also request the contents of the receipt subscrip= tion resource immediately by including a Prefer header field [RFC7240] with a "wait" preference set to "0". In response to this request, the push = service MUST generate a server push for all receipts that have not yet been= delivered. A 204 (No Content) status code with no associated server pushes indicates t= hat no new receipts are presently available. From nobody Thu Jun 9 16:05:50 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0672112D60C for ; Thu, 9 Jun 2016 16:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTNSwJCzPFxf for ; Thu, 9 Jun 2016 16:05:47 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0755.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:755]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C51D212D5A0 for ; Thu, 9 Jun 2016 16:05:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=J69l1vLuS07bVohZtiwTgXTtW3I4jlUqikGVl02mGOs=; b=fe1NYQQzSw6ml3S/tI5KLee/nYYcwixAlbZuKOmmidlxVaR2WiW8NDboVGRbbvhX7Mwlaxx2J026+HE8sxXLY52qMBpaDBiu4sBIs+2/XvOu5qxXfSp9ZMklGgYzgTGuWtI8gpeWfikBYIYfP49BF7YYEOiiYnaRSFzTTplVkT0= Received: from CO2PR03MB2407.namprd03.prod.outlook.com (10.166.93.137) by CO2PR03MB2405.namprd03.prod.outlook.com (10.166.93.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.517.8; Thu, 9 Jun 2016 23:05:26 +0000 Received: from CO2PR03MB2407.namprd03.prod.outlook.com ([10.166.93.137]) by CO2PR03MB2407.namprd03.prod.outlook.com ([10.166.93.137]) with mapi id 15.01.0517.005; Thu, 9 Jun 2016 23:05:26 +0000 From: Brian Raymor To: Benjamin Bangert Thread-Topic: [Webpush] Different status codes for negative Push Message Receipts Thread-Index: AQHRwEa5vUhTLLwUUEWQzOHJmCGu/Z/eo8FggAAPjQCAAwqd8A== Date: Thu, 9 Jun 2016 23:05:26 +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: [24.16.23.27] x-ms-office365-filtering-correlation-id: 52273a98-14f2-41b8-cf11-08d390ba8b87 x-microsoft-exchange-diagnostics: 1; CO2PR03MB2405; 6:jqaLOfIMR2JuHnoyLxdcHJ6u0RVKx7sRNMrmzynnxpN74BZlk740l/chodjYk98WQ0JNO8gwMBF6l2vAImEq23xqpxIjEJbMVro8suSobl5V+205Ipzc8ggkrWumI2qEmmEiBQFiJn4dkD9A+6gbHQKocHER+S4jlYeAZ+i7QZrLn25g8KnE1qFHNKZvi223A+Xx9yU7fzzevt/9WP39vO0o3uQE7mXu/N3YIRzgl9OlKo2JadqbF/rsqzsQ45ahfXqSb4PKgOaVtSdyRpjSUgKEjLCaQax5nRLf3Clo30zSk3kjtoxXDC8zMSYkkMH+3F6VYoKM8G8kLAslegfonA==; 5:loR4zP3cQNtKns8HPWSB28ZG9qy5neNciOFpOtj5GAv0GiMBSWfHk8GAHF6YNeaVKcqHHhwOpWvsrrayA3qLMk3/4C7n9cuMhboWppdcjpCkqsNmV+iJwGVRSeIjjUXU/bTvtXozTxgy9OzR+CjovA==; 24:FctrIGsEVxH0JcL+WHYI2jzrouzo5Au7z8SjMLGES/RUSZwvR1BeWgvIzj7G0OFHJ/cF9jPMAZZm5LzeYuKB3yHF3nAnbKneEhS4E47U21o=; 7:U2XpGgzlMhC2MVs3K26hBjR00W0hltJYN7qeewYxedlrUsuNXHoNYUUyEBOs+8YDbWopQEOrYYLhTwo07xaKeNUJo+8d8r+fISv97/q6S3qfmxjwYLE9kBai5vicE0LqJERFI/f3Xj13PBaDHo1cg2JUuwb80EM+fGcDKzA8RIKCIFz57r3Krpc9rW2PaXBxce40fbCI7V11DJlcD6JdCpyAPPw1WN/a9NAJQPADru6Ztai8xBZ+gnU35lkB8dNH x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR03MB2405; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CO2PR03MB2405; BCL:0; PCL:0; RULEID:; SRVR:CO2PR03MB2405; x-forefront-prvs: 0968D37274 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(199003)(377454003)(12063002)(189002)(33656002)(81156014)(8676002)(81166006)(15975445007)(4326007)(76576001)(5008740100001)(99286002)(2950100001)(2900100001)(6116002)(3846002)(102836003)(586003)(122556002)(86362001)(92566002)(7110500001)(76176999)(50986999)(86612001)(189998001)(54356999)(8990500004)(3660700001)(11100500001)(101416001)(2420400007)(15650500001)(9686002)(110136002)(106356001)(5004730100002)(5003600100002)(66066001)(68736007)(74316001)(3280700002)(10400500002)(10290500002)(105586002)(87936001)(106116001)(5005710100001)(2906002)(77096005)(19580395003)(97736004)(8936002)(19580405001)(5002640100001)(10710500007)(10090500001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR03MB2405; H:CO2PR03MB2407.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2016 23:05:26.8153 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR03MB2405 Archived-At: Cc: "webpush@ietf.org" , Idel Pivnitskiy Subject: Re: [Webpush] Different status codes for negative Push Message Receipts X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 23:05:49 -0000 DQpXZSd2ZSBzdHJ1Z2dsZWQgbWlnaHRpbHkgaW4gdGhlIHBhc3QgdG8gaWRlbnRpZnkgdGhlIGJl c3Qgc3RhdHVzIGNvZGVzIGZvciB0aGVzZSBzY2VuYXJpb3MsIGluY2x1ZGluZzoNCg0KKiBOZXcg c3RhdHVzIGNvZGVzIGZvciB3ZWJwdXNoDQoqIDV4eCBzdGF0dXMgY29kZXMNCiogVXNpbmcgNDE3 IGFuZCBFeHBlY3QNCiogQWNrbm93bGVkZ2VtZW50LURhdGENCg0KQSBzYW1wbGUgb2YgcmVsYXRl ZCBjb252ZXJzYXRpb25zOg0KDQpodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv d2VicHVzaC9jdXJyZW50L21zZzAwMzUxLmh0bWwNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1h cmNoaXZlL3dlYi93ZWJwdXNoL2N1cnJlbnQvbXNnMDAzNjIuaHRtbA0KaHR0cHM6Ly9naXRodWIu Y29tL3dlYnB1c2gtd2cvd2VicHVzaC1wcm90b2NvbC9pc3N1ZXMvMTcNCmh0dHBzOi8vZ2l0aHVi LmNvbS93ZWJwdXNoLXdnL3dlYnB1c2gtcHJvdG9jb2wvaXNzdWVzLzQyDQpodHRwczovL2dpdGh1 Yi5jb20vd2VicHVzaC13Zy93ZWJwdXNoLXByb3RvY29sL2lzc3Vlcy80OQ0KDQpJdCdzIG15IGlt cHJlc3Npb24gdGhhdCB3ZSBjb21wcmVoZW5zaXZlbHkgZXhoYXVzdGVkIHRoZSB0b3BpYyBwcmlv ciB0byBXR0xDIHVubGVzcyB0aGVyZSBhcmUgbmV3IHNjZW5hcmlvcw0KdG8gYWRkcmVzcy4NCg0K VGhvdWdodHM/DQoNCi4uLkJyaWFuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBCZW5qYW1pbiBCYW5nZXJ0IFttYWlsdG86YmJhbmdlcnRAbW96aWxsYS5jb21dIA0KU2VudDog VHVlc2RheSwgSnVuZSA3LCAyMDE2IDU6MDkgUE0NClRvOiBCcmlhbiBSYXltb3IgPEJyaWFuLlJh eW1vckBtaWNyb3NvZnQuY29tPg0KQ2M6IElkZWwgUGl2bml0c2tpeSA8aWRlbC5waXZuaXRza2l5 QGdtYWlsLmNvbT47IHdlYnB1c2hAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbV2VicHVzaF0gRGlm ZmVyZW50IHN0YXR1cyBjb2RlcyBmb3IgbmVnYXRpdmUgUHVzaCBNZXNzYWdlIFJlY2VpcHRzDQoN CkkgaGF2ZSBhbHNvIGFkZGVkIGNvbW1lbnRzIHRvIHRoZSBpc3N1ZSwgd291bGQgaXQgYmUgbW9y ZSBhcHByb3ByaWF0ZQ0KdG8gZGlzY3VzcyBpdCBoZXJlPw0KDQpPbiBUdWUsIEp1biA3LCAyMDE2 IGF0IDQ6MTUgUE0sIEJyaWFuIFJheW1vciA8QnJpYW4uUmF5bW9yQG1pY3Jvc29mdC5jb20+IHdy b3RlOg0KPiBPbiBNb25kYXksIEp1bmUgNiwgMjAxNiAzOjU2IFBNLCBJZGVsIFBpdm5pdHNraXkg PGlkZWwucGl2bml0c2tpeUBnbWFpbC5jb20+IHdyb3RlOg0KPg0KPj4gSSd2ZSBjcmVhdGVkIGFu IGlzc3VlIG9uIEdpdEh1YiwgcmVsYXRlZCB0byB0aGlzIGRpc2N1c3Npb246DQo+PiBodHRwczov L2dpdGh1Yi5jb20vd2VicHVzaC13Zy93ZWJwdXNoLXByb3RvY29sL2lzc3Vlcy8xMTANCj4+IENv dWxkIGJlIHVzZWZ1bCBmb3IgYW4gQVMgdG8ga25vdyB3aGF0IGhhcHBlbmVkIHdpdGggcHVzaCBt ZXNzYWdlIC8gVUEuDQo+DQo+DQo+IEnigJl2ZSBhZGRlZCBteSBjb21tZW50cyB0byB0aGUgaXNz dWUuDQo+DQo+IFRoYW5rcywNCj4gLi4uQnJpYW4NCj4NCj4NCj4NCj4NCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gV2VicHVzaCBtYWlsaW5nIGxp c3QNCj4gV2VicHVzaEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3dlYnB1c2gNCg== From nobody Fri Jun 10 03:17:15 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1435C12D7C2 for ; Fri, 10 Jun 2016 03:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NelCU6uaOVg for ; Fri, 10 Jun 2016 03:17:12 -0700 (PDT) Received: from inari-msr.crf.canon.fr (inari-msr.crf.canon.fr [194.2.158.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 484C912D0E4 for ; Fri, 10 Jun 2016 03:17:11 -0700 (PDT) Received: from mir-bsr.corp.crf.canon.fr (mir-bsr.corp.crf.canon.fr [172.19.77.99]) by inari-msr.crf.canon.fr (8.13.8/8.13.8) with ESMTP id u5AAH522003696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Jun 2016 12:17:05 +0200 Received: from Antiope.crf.canon.fr (antiope.fesl2.crf.canon.fr [172.19.70.56]) by mir-bsr.corp.crf.canon.fr (8.13.8/8.13.8) with ESMTP id u5AAH5Ro027353; Fri, 10 Jun 2016 12:17:05 +0200 Received: from Antiope.crf.canon.fr (172.19.70.56) by Antiope.crf.canon.fr (172.19.70.56) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 10 Jun 2016 12:17:04 +0200 Received: from Antiope.crf.canon.fr ([fe80::5c25:f890:ae73:d15a]) by Antiope.crf.canon.fr ([fe80::5c25:f890:ae73:d15a%12]) with mapi id 15.00.0995.032; Fri, 10 Jun 2016 12:17:04 +0200 From: RUELLAN Herve To: "martin.thomson@gmail.com" Thread-Topic: [Webpush] Non-blocking comments on -05 Thread-Index: AQHRu3RPtv1gb54CNUWyRYz7Gkh/JZ/UfYOQgADSzoCAAFBvAIAAI8UAgAowSYCAAXVWAIAAKpqAgADVRoA= Date: Fri, 10 Jun 2016 10:17:04 +0000 Message-ID: <1465553821.3039.13.camel@crf.canon.fr> References: <6af49c2baf1b4e4f884b812d573b947e@Antiope.crf.canon.fr> <989D9268-BE9A-47F7-9181-C0F323D1DA1F@mozilla.com> <1464858574.5342.12.camel@crf.canon.fr> <2953D35A-1FC9-4765-BBE0-83DBCA8CAC10@mozilla.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Evolution 3.12.11 (3.12.11-1.fc21) x-originating-ip: [172.20.5.129] Content-Type: text/plain; charset="utf-8" Content-ID: <2E7A6669B095414FABCBBBD915E44A7D@crf.canon.fr> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "kcambridge@mozilla.com" , "costin@gmail.com" , "Brian.Raymor@microsoft.com" , "webpush@ietf.org" , "beverloo@google.com" Subject: Re: [Webpush] Non-blocking comments on -05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 10:17:14 -0000 T24gRnJpLCAyMDE2LTA2LTEwIGF0IDA3OjMzICsxMDAwLCBNYXJ0aW4gVGhvbXNvbiB3cm90ZToN Cj4gT24gMTAgSnVuZSAyMDE2IGF0IDA1OjAxLCBLaXQgQ2FtYnJpZGdlIDxrY2FtYnJpZGdlQG1v emlsbGEuY29tPiB3cm90ZToNCj4gPiBEb2VzIG1vdmluZyBhIHN1YnNjcmlwdGlvbiBzZXQgbWVh biBhbm90aGVyIFVBIHdvdWxkIGJlIGFibGUgdG8gcmVjZWl2ZSBtZXNzYWdlcyBzZW50IHRvIHN1 YnNjcmlwdGlvbnMgaW4gdGhhdCBzZXQ/IChUaGF0IGlzLCB3aXRob3V0IHJlcXVpcmluZyB0aGUg b2xkIFVBIHRvIGRyb3AgYWxsIGl0cyBzdWJzY3JpcHRpb25zIGFuZCB0aGUgbmV3IFVBIHRvIHJl cmVnaXN0ZXIpLg0KPiANCj4gSSB0aGluayB0aGF0IHlvdSBoYXZlIGl0LiBJZiB5b3UgaGF2ZSAy IHN1YnNjcmlwdGlvbnMgdGhhdCBhcmUgaW4gdGhlDQo+IHNhbWUgc2V0LCB0aGV5IGhhdmUgdG8g YmUgbW9uaXRvcmVkIHRvZ2V0aGVyLiAgSWYgdGhleSBhcmUgaW4gc2VwYXJhdGUNCj4gc2V0cywg dGhlbiB0aGV5IGNhbiBiZSBtb25pdG9yZWQgc2VwYXJhdGVseS4gIFRoZSBzZXBhcmF0aW9uIGVu YWJsZXMNCj4gaW50ZXJtZWRpYXRpb24uDQo+IA0KPiBJIGRvbid0IHRoaW5rIHRoYXQgdGhpcyBp cyBhIHVzZSBjYXNlIHRoYXQgaXMgcGFydGljdWxhcmx5IGltcG9ydGFudA0KPiBmb3IgdGhlIHdl YiBjYXNlOyBJIGNvbmZlc3MgdGhhdCBpdCBpc24ndCB0aGF0IGludGVyZXN0aW5nIHRvIG1lLg0K PiBIb3dldmVyLCBJIHRoaW5rIHRoYXQgaXQgaXMgYW4gZW50aXJlbHkgdmFsaWQgdXNlIGNhc2Us IGFuZCBpdCBjb3N0cw0KPiBsaXR0bGUuICBJdCBkb2VzIGhvd2V2ZXIgZW5hYmxlIHRoaW5ncyBv biB0aGUgd2ViIHNpZGUgdGhhdCAqYXJlKiB2ZXJ5DQo+IGludGVyZXN0aW5nIHRvIG1lLg0KPiAN Cj4gU2F5IHlvdSBoYXZlIGEgVUEgdGhhdCB3YW50cyB0byBnbyBpbnRvIGEgZGVlcCBzbGVlcCB0 byBzYXZlIHBvd2VyLg0KPiBJbiB0aGF0IG1vZGUsIGl0IHN0aWxsIHdhbnRzIHRvIHJlY2VpdmUg cHVzaCBtZXNzYWdlcyBmcm9tIHNldmVyYWwNCj4gaGlnaCBwcmlvcml0eSBzaXRlcy4gIEJ1dCBp dCBkb2Vzbid0IHdhbnQgdG8gZ2V0IHRoZSBkZWFsLW9mLXRoZS1kYXkNCj4gYW5kIGFsbCB0aGF0 IGp1bmsgZnJvbSBvdGhlciBzaXRlcy4NCj4gDQo+IE5vdywgdGhlIFVBIGtub3dzIHRoYXQgdGhl IHB1c2ggc2VydmljZSBpcyB1bmFibGUgdG8gZGlzY3JpbWluYXRlDQo+IGJldHdlZW4gaW1wb3J0 YW50IGFuZCB1bmltcG9ydGFudCBwcm9wZXJseSBhbmQgaXQgZG9lc24ndCB3YW50IHRvIHJpc2sN Cj4gZ2V0dGluZyB0aGluZ3MgbGlrZSB0ZXh0IG1lc3NhZ2Ugbm90aWZpY2F0aW9ucyBmcm9tIHVu aW1wb3J0YW50IHNpdGVzLg0KPiBFdmVuIGlmIHRoZXNlIGFyZSBub3JtYWxseSBzZW50IHdpdGgg bW9kZXJhdGVseSBoaWdoIHVyZ2VuY3ksDQo+IGxlZ2l0aW1hdGVseS4NCj4gDQo+IElmIGl0IGNh biBzcGxpdCB0aGUgaW1wb3J0YW50IHNpdGVzIGFuZCB0aGUgdW5pbXBvcnRhbnQgc2l0ZXMgaW50 byB0d28NCj4gc3Vic2NyaXB0aW9uIHNldHMsIHRoZW4gaXQgY2FuIG1vbml0b3IgdGhlIGltcG9y dGFudCBzaXRlcyBvbmx5Lg0KPiBUaGF0J3Mgbm90IHBvc3NpYmxlIGlmIHlvdSBkb24ndCBhbGxv dyB0aGUgVUEgdG8gY29udHJvbCB3aGljaA0KPiBzdWJzY3JpcHRpb25zIGdldCBncm91cGVkIHRv Z2V0aGVyLg0KPiANCj4gSWYgeW91IHdhbnQgYSBjb25jcmV0ZSBleGFtcGxlLCB0aGluayBwYWdl cmR1dHkuY29tIHZzLiBza3lwZS5jb20uICBBDQo+IGNhbGwgbWlnaHQgYmUgZW50aXJlbHkgdW5k ZXNpcmFibGUgYXQgM2FtLCBidXQgaWYgYSBwcm9kdWN0aW9uIHNpdGUgaXMNCj4gb24gZmlyZSwg aXQncyB3YWtlIHVwIHRpbWUuDQoNCkFzIHRoZXJlIHNlZW1zIHRvIGJlIHNldmVyYWwgdXNlIGNh c2VzIGhlcmUgKHlvdXIgdXNlIGNhc2UgZm9yIHRoZSB3ZWIsDQpDb3N0aW4ncyBtdWx0aS11c2Vy IGNhc2UgaW4gYW5kcm9pZCwgYW5kIG15IFVBIHByb3h5aW5nIHVzZSBjYXNlKSwgSQ0KdGhpbmsg bW9yZSBvZiB0aGVtIGNvdWxkIGJlIGxpc3RlZCBpbiB0aGUgc3BlYy4NCg0KSG93IGFib3V0Og0K DQpFYWNoIHN1YnNjcmlwdGlvbiBzZXQgY2FuIHRoZW4gYmUgbWFuYWdlZCBpbmRlcGVuZGVudGx5 LCB3aGljaCBtaWdodA0KaW5jbHVkZSBtb25pdG9yaW5nIG9ubHkgYSBzZXQgb2YgdmVyeSBpbXBv cnRhbnQgc3Vic2NyaXB0aW9ucywgaGFuZGxpbmcNCnN1YnNjcmlwdGlvbiBmb3IgZGlmZmVyZW50 IHVzZXJzIHNlcGFyYXRlbHksIG9yIG1vdmluZyBhIHN1YnNjcmlwdGlvbg0Kc2V0IGJldHdlZW4g dXNlciBhZ2VudHMuDQoNCg0KRm9yIG1vdmluZyBzdWJzY3JpcHRpb24gc2V0cyBiZXR3ZWVuIFVB LCBJIGFncmVlIHRoYXQgaXQncyB0b28gZWFybHkgdG8NCnNvbHZlIGl0IGluIHRoaXMgV2VicHVz aCBkcmFmdC4gTXkgY29uY2VybiBoZXJlIGlzIHRvIGxlYXZlIG9wZW4gdGhlDQpwb3NzaWJpbGl0 eSBvZiBidWlsZGluZyBpdCBpbiB0aGUgZnV0dXJlLg0KDQpIZXJ2w6kNCg== From nobody Fri Jun 10 10:17:48 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 612A112D7E3 for ; Fri, 10 Jun 2016 10:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtXnQY45Nm3E for ; Fri, 10 Jun 2016 10:17:44 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::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 E1E0A12D5FB for ; Fri, 10 Jun 2016 10:17:43 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id t190so25345868pfb.3 for ; Fri, 10 Jun 2016 10:17:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZepsuThc1fGVJbBdv8Ty0UnP/KMN9c4a7RRIGHa3y1Q=; b=T/VQuE4M1u3XvEkzZ5WCtsPsspdTn15aWab9kdS08ZiXEOQ/Phb7Z55T2C6DOaoobr 3nNpLJcM8g1SmvnmaXGB7X4+801uR+EDP2o/iF+Rnod8QL7id2bYzowhSN3K6wJayoRR hWOjXWno/H4UqBoAtTvE/B4+A6/WW/OUxsrMvT50xVKbZ5Cad4SwIKr3CSdbJGn0pknY Xr+RE2GtJVyPCtQVyn0o2fsxxZRj4MJkw9qSOZtnN/wrtl+FHm+NOS5aPheaK3XYEKEc rLju9Mj+JCWCSPTd0t77fhSgy6She5OyoPNbfEsWW7prI6jVQauBQEfZbYWv+YSmvCZ9 GW9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZepsuThc1fGVJbBdv8Ty0UnP/KMN9c4a7RRIGHa3y1Q=; b=FQKcySqALEUC5nC1ROct76dEXsPOq1iNIu+4luEx/saeEu1u14ziWbr8H47lI1G+aw ZBAp1sQYVRGaMr4Uc9ELKSYqitMng1uo0k36dclj5II5TUYfd0Y8uEJi+/iIQlBMrpNY kT/licoBj0Tx5Kwnypi3evoxofRKaUwjK1YT/gunGKioATUkR+BQlavLXXvs8NWqj9nA Ui7ZwHLFvIayjvHJBTJ5DijtmJMtgC0FXTAZE6YXTT4cbHFU3443GX4W6T4fXQeA481n UYTixD2xkMVFsp/h7jRY48syiZM7had7o323bC25V/IGKddd4wbIaKpUXcmyRO/HzKxA nsPg== X-Gm-Message-State: ALyK8tLyIon+7B5lYsP2JM6KhZUadZffFTz685hho4aT6NeBh1ooAsLAksvvpgzjAegwQmNmRhevK/SB67XqmA== X-Received: by 10.98.105.138 with SMTP id e132mr3382598pfc.59.1465579063291; Fri, 10 Jun 2016 10:17:43 -0700 (PDT) MIME-Version: 1.0 References: <6af49c2baf1b4e4f884b812d573b947e@Antiope.crf.canon.fr> <989D9268-BE9A-47F7-9181-C0F323D1DA1F@mozilla.com> <1464858574.5342.12.camel@crf.canon.fr> <2953D35A-1FC9-4765-BBE0-83DBCA8CAC10@mozilla.com> <1465553821.3039.13.camel@crf.canon.fr> In-Reply-To: <1465553821.3039.13.camel@crf.canon.fr> From: Costin Manolache Date: Fri, 10 Jun 2016 17:17:33 +0000 Message-ID: To: RUELLAN Herve , "martin.thomson@gmail.com" Content-Type: multipart/alternative; boundary=001a113a1dcc7538310534efb799 Archived-At: Cc: "kcambridge@mozilla.com" , "Brian.Raymor@microsoft.com" , "webpush@ietf.org" , "beverloo@google.com" Subject: Re: [Webpush] Non-blocking comments on -05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 17:17:46 -0000 --001a113a1dcc7538310534efb799 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Most use cases mentioned - with the exception of 'moving subscription' - can be implemented efficiently by storing the messages keyed by some 'primary' ID. For large numbers, it is desirable to optimize the number of DB queries done at connect - i.e. do a single read that hits a single shard. Most of the time the read will return empty, but the locality of the messages for a single device is pretty important. Moving subscriptions pretty much requires a different design - and I don't have any experience with how it can scale. Costin On Fri, Jun 10, 2016 at 3:17 AM RUELLAN Herve wrote: > On Fri, 2016-06-10 at 07:33 +1000, Martin Thomson wrote: > > On 10 June 2016 at 05:01, Kit Cambridge wrote: > > > Does moving a subscription set mean another UA would be able to > receive messages sent to subscriptions in that set? (That is, without > requiring the old UA to drop all its subscriptions and the new UA to > reregister). > > > > I think that you have it. If you have 2 subscriptions that are in the > > same set, they have to be monitored together. If they are in separate > > sets, then they can be monitored separately. The separation enables > > intermediation. > > > > I don't think that this is a use case that is particularly important > > for the web case; I confess that it isn't that interesting to me. > > However, I think that it is an entirely valid use case, and it costs > > little. It does however enable things on the web side that *are* very > > interesting to me. > > > > Say you have a UA that wants to go into a deep sleep to save power. > > In that mode, it still wants to receive push messages from several > > high priority sites. But it doesn't want to get the deal-of-the-day > > and all that junk from other sites. > > > > Now, the UA knows that the push service is unable to discriminate > > between important and unimportant properly and it doesn't want to risk > > getting things like text message notifications from unimportant sites. > > Even if these are normally sent with moderately high urgency, > > legitimately. > > > > If it can split the important sites and the unimportant sites into two > > subscription sets, then it can monitor the important sites only. > > That's not possible if you don't allow the UA to control which > > subscriptions get grouped together. > > > > If you want a concrete example, think pagerduty.com vs. skype.com. A > > call might be entirely undesirable at 3am, but if a production site is > > on fire, it's wake up time. > > As there seems to be several use cases here (your use case for the web, > Costin's multi-user case in android, and my UA proxying use case), I > think more of them could be listed in the spec. > > How about: > > Each subscription set can then be managed independently, which might > include monitoring only a set of very important subscriptions, handling > subscription for different users separately, or moving a subscription > set between user agents. > > > For moving subscription sets between UA, I agree that it's too early to > solve it in this Webpush draft. My concern here is to leave open the > possibility of building it in the future. > > Herv=C3=A9 > --001a113a1dcc7538310534efb799 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Most use cases mentioned - with the exception of 'movi= ng subscription' - can be implemented
efficiently by storing the me= ssages keyed by some 'primary' ID. For large numbers, it=C2=A0
is desirable to optimize the number o= f DB queries done at connect - i.e.= =C2=A0do a single read that=C2=A0
hits a single shard.=C2=A0 Most of the time the read will return em= pty, but the locality of the=C2=A0
messages for a single device is pretty important.=C2=A0

Moving subscriptions pretty much requires a different des= ign - and I don't have any experience
with how it can scale.=C2=A0

= Costin



On Fri, Jun 10, 2016 at 3:17 AM RUELLAN Herve &= lt;Herve.Ruellan@crf.canon.fr= > wrote:
On Fri, 2016-06-10 = at 07:33 +1000, Martin Thomson wrote:
> On 10 June 2016 at 05:01, Kit Cambridge <kcambridge@mozilla.com> wrote:
> > Does moving a subscription set mean another UA would be able to r= eceive messages sent to subscriptions in that set? (That is, without requir= ing the old UA to drop all its subscriptions and the new UA to reregister).=
>
> I think that you have it. If you have 2 subscriptions that are in the<= br> > same set, they have to be monitored together.=C2=A0 If they are in sep= arate
> sets, then they can be monitored separately.=C2=A0 The separation enab= les
> intermediation.
>
> I don't think that this is a use case that is particularly importa= nt
> for the web case; I confess that it isn't that interesting to me.<= br> > However, I think that it is an entirely valid use case, and it costs > little.=C2=A0 It does however enable things on the web side that *are*= very
> interesting to me.
>
> Say you have a UA that wants to go into a deep sleep to save power. > In that mode, it still wants to receive push messages from several
> high priority sites.=C2=A0 But it doesn't want to get the deal-of-= the-day
> and all that junk from other sites.
>
> Now, the UA knows that the push service is unable to discriminate
> between important and unimportant properly and it doesn't want to = risk
> getting things like text message notifications from unimportant sites.=
> Even if these are normally sent with moderately high urgency,
> legitimately.
>
> If it can split the important sites and the unimportant sites into two=
> subscription sets, then it can monitor the important sites only.
> That's not possible if you don't allow the UA to control which=
> subscriptions get grouped together.
>
> If you want a concrete example, think pagerduty.com vs. skype.com.=C2=A0 A > call might be entirely undesirable at 3am, but if a production site is=
> on fire, it's wake up time.

As there seems to be several use cases here (your use case for the web,
Costin's multi-user case in android, and my UA proxying use case), I think more of them could be listed in the spec.

How about:

Each subscription set can then be managed independently, which might
include monitoring only a set of very important subscriptions, handling
subscription for different users separately, or moving a subscription
set between user agents.


For moving subscription sets between UA, I agree that it's too early to=
solve it in this Webpush draft. My concern here is to leave open the
possibility of building it in the future.

Herv=C3=A9
--001a113a1dcc7538310534efb799-- From nobody Fri Jun 10 11:59:19 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C06212D62A for ; Fri, 10 Jun 2016 11:59:17 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntr48BdpGlzs for ; Fri, 10 Jun 2016 11:59:15 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::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 8B6E012D52D for ; Fri, 10 Jun 2016 11:59:15 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id h190so2747645ith.1 for ; Fri, 10 Jun 2016 11:59:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=RHFFHRjxfkrdqm1u2HklAWWBI+1lXB1R0oDfkd0rW3Y=; b=Apbp7bfHl7wDmlK8jHZYXqnPHRE8fwccPnafrzDZNRRUzRnDP/xewmmjH84f7bQVDl fwJNGP9+k1tRdxVIRTA6ze5Uz1FVLkJ77IuBfE4e4uVZ/9vJKGPCN4rw/5gDESgYcsXd IcN8pmxQIdn1muCtiemTNFZzaJ5kXaT2Vs4J6bNEnlSBXT+KBgjvv7E1Kvegvz7/o22r fdruVUDdfh56a5JaWwlzsNbT2Y+lyov0CcmyjPoLu6wi+LVJSKLAPZMo6DWckoBr5+Yy wjzv1DQNc512qV2vog1fwqy+36e91VW9jDxG7qy8p60mu0qWAx8NNueEoMhGFz6mESGb mLJQ== 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; bh=RHFFHRjxfkrdqm1u2HklAWWBI+1lXB1R0oDfkd0rW3Y=; b=KZqjut03CKE+Z2KWVr6pZiab4L2ChzY5ltdm23MWvqfGFshZDSFCAzqL0vzIc/3df0 kTPGavbvc3ezQpo5sM9jZpAnbkW/sNI/rCo6x+e5OCFk6uH/+IjyGy1dtgALGcDqkC/d 3hD7ECxRISZN8jjE0cdl5ATx/ClkhmSAnwyeowoa+v1fRfR2MCyKdnyVNo0QKcq2JkRI r+U9LXSdn2K0Pmk0ngQkhxH+TObJ1eAEt+6juzK7nCgCqIyHfMg8D9S2gCRovLAiEVGR fSAnNvyyBIXNkFYhtXTLxtQilsfWrlxqfkNNLE9B8SkJFA9MM6gtCN2/zsnEspoHh0Lp R1wg== X-Gm-Message-State: ALyK8tIphieFd3zTnkpw6gm2IsVDPvHfm5FQJZ7xZhUrScJyD3wTB6Ia8OxgT3GZzHWL3Q48cpHyDQsyrFE+rA== X-Received: by 10.36.94.68 with SMTP id h65mr968972itb.45.1465585154816; Fri, 10 Jun 2016 11:59:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.152.131 with HTTP; Fri, 10 Jun 2016 11:58:35 -0700 (PDT) In-Reply-To: References: From: Idel Pivnitskiy Date: Fri, 10 Jun 2016 21:58:35 +0300 Message-ID: To: "webpush@ietf.org" Content-Type: multipart/alternative; boundary=001a11448a968aa20b0534f122bb Archived-At: Subject: Re: [Webpush] Prefer: wait=0 for Receiving Push Message Receipts X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 18:59:17 -0000 --001a11448a968aa20b0534f122bb Content-Type: text/plain; charset=UTF-8 Thanks Brian, Yes, as a design of receiving push messages and push message receipt is the similar and they are both use server pushes, will not be a problem to reuse already implemented code base to allow this feature for an AS too. Advantages: - More flexible logic for AS (it could choose how it will request receipts); - Possibility to reduce number of always opened connections to the PS, because if a UA may be unavailable most of the time we can not say the same about an AS. It's online most of the time, but can request push message delivery rarely. Previously Kit also considered to add this feature: https://github.com/webpush-wg/webpush-protocol/issues/18#issuecomment-97478621 Best regards, Idel Pivnitskiy -- Twitter: @idelpivnitskiy GitHub: @idelpivnitskiy On Fri, Jun 10, 2016 at 1:19 AM, Brian Raymor wrote: > > https://github.com/webpush-wg/webpush-protocol/issues/113 > > Idel has suggested the addition of the Prefer: wait=0 option to section > 6.3. Receiving Push Message Receipts to allow application servers > to have the same option for immediately checking/receiving receipts as > user agents have for immediately checking/receiving messages. > > I'd appreciate broader review and comments about whether this is a useful > feature. > > The addition to 6.3. Receiving Push Message Receipts would be: > > > An application server can also request the contents of the receipt > subscription resource immediately by including a Prefer header field > [RFC7240] > with a "wait" preference set to "0". In response to this request, the push > service MUST generate a server push for all receipts that have not yet been > delivered. > > A 204 (No Content) status code with no associated server pushes indicates > that no new receipts are presently available. > > > > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > --001a11448a968aa20b0534f122bb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Brian,

Yes, as a desi= gn of receiving push messages and push message receipt is the similar and t= hey are both use server pushes, will not be a problem to reuse already impl= emented code base to allow this feature for an AS too.

=
Advantages:
  • More flexible logic for AS (it could cho= ose how it will request receipts);
  • Possibility to reduce number of = always opened connections to the PS, because if a UA may be unavailable mos= t of the time we can not say the same about an AS. It's online most of = the time, but can request push message delivery rarely.
Previously Kit also considered to add this feature:

https://github.com/webpush-wg/webpush-pro= tocol/issues/18#issuecomment-97478621

Best regards,
Idel Pivnitskiy
--
GitHub:=C2=A0@idelpivnitskiy
<= /div>

On Fri, Jun 10, 2016 at 1:19 AM, Brian Raymo= r <Brian.Raymor@microsoft.com> wrote:

https://github.com/webpush-wg/webpush-pro= tocol/issues/113

Idel has suggested the addition of the Prefer: wait=3D0 option to section 6= .3. Receiving Push Message Receipts to allow application servers
to have the same option for immediately checking/receiving receipts as user= agents have for immediately checking/receiving messages.

I'd appreciate broader review and comments about whether this is a usef= ul feature.

The addition to 6.3. Receiving Push Message Receipts would be:


An application server can also request the contents of the receipt subscrip= tion resource immediately by including a Prefer header field [RFC7240]
with a "wait" preference set to "0". In response to thi= s request, the push service MUST generate a server push for all receipts th= at have not yet been delivered.

A 204 (No Content) status code with no associated server pushes indicates t= hat no new receipts are presently available.




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

--001a11448a968aa20b0534f122bb-- From nobody Fri Jun 10 14:03:52 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E771912D946 for ; Fri, 10 Jun 2016 14:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvlbOj08D0py for ; Fri, 10 Jun 2016 14:03:48 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0112.outbound.protection.outlook.com [207.46.100.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEE3612D734 for ; Fri, 10 Jun 2016 14:03:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OOCWIDoyl1tK8r2QU1OvrXpyHhtRofEqUF0FA4X6vcI=; b=a4+MgFvmrww47FkJKItF6u86ALGJxMcef0Suq2k0YZAmjfw+YPT5Dn75pO2YdkHSjLsH4lSf0SMOBtR0sCJgvk5VOLI+SJhaNyunN5xifGqcMIHO9YnzZwDdH0F5aO2vaNSWLuWrZ38HRJbAELLdQcjZrmDbLe+9OJGQNP8iWbk= Received: from CO2PR03MB2407.namprd03.prod.outlook.com (10.166.93.137) by CO2PR03MB2407.namprd03.prod.outlook.com (10.166.93.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.517.8; Fri, 10 Jun 2016 21:03:46 +0000 Received: from CO2PR03MB2407.namprd03.prod.outlook.com ([10.166.93.137]) by CO2PR03MB2407.namprd03.prod.outlook.com ([10.166.93.137]) with mapi id 15.01.0517.005; Fri, 10 Jun 2016 21:03:46 +0000 From: Brian Raymor To: Brian Raymor , Benjamin Bangert Thread-Topic: [Webpush] Different status codes for negative Push Message Receipts Thread-Index: AQHRwEa5vUhTLLwUUEWQzOHJmCGu/Z/eo8FggAAPjQCAAwqd8IABd0GQ Date: Fri, 10 Jun 2016 21:03:46 +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: [24.16.23.27] x-ms-office365-filtering-correlation-id: fe20f6a2-c58e-4a0b-c6c5-08d39172b6c4 x-microsoft-exchange-diagnostics: 1; CO2PR03MB2407; 6:SGSEK6ooCP+D4ZIIhkyG5lMok4HGCjkWTn2+95FDEKbRvBKfAEk90jfJfKFZIKC9CuYs3FBM1ivIr+730U25fFDSbR2kOUlAwl3W4mbyvPG1wOOjLgCRl25eMIvmNa5tPw5xGbSGuD+md1dYKHFTS0uLWu/qHaXYVS9ckcLXVxawVrH6z4cIqMeZuel/sNOmUIQ5gp0qG8XxMqacq744J3eksSV9R5nb5j//53ZRBDTa7yvtpvN55OJwr9HGEJlK2hBYyA4UstrJSrpmHQyCBhLBMTGcbXQtaX3vTuyXu1Fv6fNxYOTTMcssYtRy46Vd; 5:jXk5EuKChucDlRzBLxsP6W6vq1o5R0H3G4cs+TCc1xzUW1uH4mgcgQWChDpHq27FnOtetAxyZNF9ZusJy1to1QmIbItJ5JBn+qTdyKLGBNgGsW+w71W4lIR7Els4e+SQl78lg15gxi+QOCujmRxTOA==; 24:adFuAHw7COerHDyu+4F2vbBUHZb6oEm58hXRrufd+V7C+osUa0H5nrWR+6NXIUaw9FiQlx2RgCkHFRrq9UL/5PH+L5e9SZcSumw1Ta12Uj4=; 7:4pc06x66FTCQWSZkMBffktLYs27vyjtaQr+Q9hcWowEITsNoh9Nattrt/gou0vtxHMsElIJSdFMKXXwEJWb1k5mLqhtA1uiq2ZtuwdYmV1tMOLdY2K45HbomdyDtlulxNdtEwpqfn8oAUsTCQ4r1ZzPqWhUnPcYQTg8smVOapGgOKS3V4PuPTL1zQjjt8phejnsHsDDpHeZJmU4qKidjxbTupmcqdzwPbsBJ3Gw2TfQ= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR03MB2407; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CO2PR03MB2407; BCL:0; PCL:0; RULEID:; SRVR:CO2PR03MB2407; x-forefront-prvs: 096943F07A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(189002)(24454002)(377454003)(199003)(12063002)(106116001)(74316001)(54356999)(101416001)(122556002)(8990500004)(19580405001)(10710500007)(68736007)(76176999)(2906002)(5005710100001)(5002640100001)(19580395003)(10290500002)(2561002)(50986999)(2420400007)(10400500002)(10090500001)(4326007)(105586002)(15975445007)(99286002)(1511001)(5003600100002)(9686002)(97736004)(77096005)(92566002)(5001770100001)(106356001)(6116002)(8936002)(11100500001)(93886004)(3280700002)(189998001)(86612001)(33656002)(2421001)(5008740100001)(3660700001)(87936001)(81166006)(7110500001)(81156014)(3846002)(2900100001)(76576001)(8676002)(2950100001)(102836003)(66066001)(86362001)(15650500001)(586003)(5004730100002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR03MB2407; H:CO2PR03MB2407.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2016 21:03:46.6457 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR03MB2407 Archived-At: Cc: Idel Pivnitskiy , "webpush@ietf.org" Subject: Re: [Webpush] Different status codes for negative Push Message Receipts X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 21:03:50 -0000 Q2xvc2VkIGh0dHBzOi8vZ2l0aHViLmNvbS93ZWJwdXNoLXdnL3dlYnB1c2gtcHJvdG9jb2wvaXNz dWVzLzExMA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBXZWJwdXNoIFtt YWlsdG86d2VicHVzaC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQnJpYW4gUmF5bW9y DQpTZW50OiBUaHVyc2RheSwgSnVuZSA5LCAyMDE2IDQ6MDUgUE0NClRvOiBCZW5qYW1pbiBCYW5n ZXJ0IDxiYmFuZ2VydEBtb3ppbGxhLmNvbT4NCkNjOiB3ZWJwdXNoQGlldGYub3JnOyBJZGVsIFBp dm5pdHNraXkgPGlkZWwucGl2bml0c2tpeUBnbWFpbC5jb20+DQpTdWJqZWN0OiBSZTogW1dlYnB1 c2hdIERpZmZlcmVudCBzdGF0dXMgY29kZXMgZm9yIG5lZ2F0aXZlIFB1c2ggTWVzc2FnZSBSZWNl aXB0cw0KDQoNCldlJ3ZlIHN0cnVnZ2xlZCBtaWdodGlseSBpbiB0aGUgcGFzdCB0byBpZGVudGlm eSB0aGUgYmVzdCBzdGF0dXMgY29kZXMgZm9yIHRoZXNlIHNjZW5hcmlvcywgaW5jbHVkaW5nOg0K DQoqIE5ldyBzdGF0dXMgY29kZXMgZm9yIHdlYnB1c2gNCiogNXh4IHN0YXR1cyBjb2Rlcw0KKiBV c2luZyA0MTcgYW5kIEV4cGVjdA0KKiBBY2tub3dsZWRnZW1lbnQtRGF0YQ0KDQpBIHNhbXBsZSBv ZiByZWxhdGVkIGNvbnZlcnNhdGlvbnM6DQoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNo aXZlL3dlYi93ZWJwdXNoL2N1cnJlbnQvbXNnMDAzNTEuaHRtbA0KaHR0cDovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL3dlYnB1c2gvY3VycmVudC9tc2cwMDM2Mi5odG1sDQpodHRwczov L2dpdGh1Yi5jb20vd2VicHVzaC13Zy93ZWJwdXNoLXByb3RvY29sL2lzc3Vlcy8xNw0KaHR0cHM6 Ly9naXRodWIuY29tL3dlYnB1c2gtd2cvd2VicHVzaC1wcm90b2NvbC9pc3N1ZXMvNDINCmh0dHBz Oi8vZ2l0aHViLmNvbS93ZWJwdXNoLXdnL3dlYnB1c2gtcHJvdG9jb2wvaXNzdWVzLzQ5DQoNCkl0 J3MgbXkgaW1wcmVzc2lvbiB0aGF0IHdlIGNvbXByZWhlbnNpdmVseSBleGhhdXN0ZWQgdGhlIHRv cGljIHByaW9yIHRvIFdHTEMgdW5sZXNzIHRoZXJlIGFyZSBuZXcgc2NlbmFyaW9zDQp0byBhZGRy ZXNzLg0KDQpUaG91Z2h0cz8NCg0KLi4uQnJpYW4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IEJlbmphbWluIEJhbmdlcnQgW21haWx0bzpiYmFuZ2VydEBtb3ppbGxhLmNvbV0g DQpTZW50OiBUdWVzZGF5LCBKdW5lIDcsIDIwMTYgNTowOSBQTQ0KVG86IEJyaWFuIFJheW1vciA8 QnJpYW4uUmF5bW9yQG1pY3Jvc29mdC5jb20+DQpDYzogSWRlbCBQaXZuaXRza2l5IDxpZGVsLnBp dm5pdHNraXlAZ21haWwuY29tPjsgd2VicHVzaEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtXZWJw dXNoXSBEaWZmZXJlbnQgc3RhdHVzIGNvZGVzIGZvciBuZWdhdGl2ZSBQdXNoIE1lc3NhZ2UgUmVj ZWlwdHMNCg0KSSBoYXZlIGFsc28gYWRkZWQgY29tbWVudHMgdG8gdGhlIGlzc3VlLCB3b3VsZCBp dCBiZSBtb3JlIGFwcHJvcHJpYXRlDQp0byBkaXNjdXNzIGl0IGhlcmU/DQoNCk9uIFR1ZSwgSnVu IDcsIDIwMTYgYXQgNDoxNSBQTSwgQnJpYW4gUmF5bW9yIDxCcmlhbi5SYXltb3JAbWljcm9zb2Z0 LmNvbT4gd3JvdGU6DQo+IE9uIE1vbmRheSwgSnVuZSA2LCAyMDE2IDM6NTYgUE0sIElkZWwgUGl2 bml0c2tpeSA8aWRlbC5waXZuaXRza2l5QGdtYWlsLmNvbT4gd3JvdGU6DQo+DQo+PiBJJ3ZlIGNy ZWF0ZWQgYW4gaXNzdWUgb24gR2l0SHViLCByZWxhdGVkIHRvIHRoaXMgZGlzY3Vzc2lvbjoNCj4+ IGh0dHBzOi8vZ2l0aHViLmNvbS93ZWJwdXNoLXdnL3dlYnB1c2gtcHJvdG9jb2wvaXNzdWVzLzEx MA0KPj4gQ291bGQgYmUgdXNlZnVsIGZvciBhbiBBUyB0byBrbm93IHdoYXQgaGFwcGVuZWQgd2l0 aCBwdXNoIG1lc3NhZ2UgLyBVQS4NCj4NCj4NCj4gSeKAmXZlIGFkZGVkIG15IGNvbW1lbnRzIHRv IHRoZSBpc3N1ZS4NCj4NCj4gVGhhbmtzLA0KPiAuLi5Ccmlhbg0KPg0KPg0KPg0KPg0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBXZWJwdXNoIG1h aWxpbmcgbGlzdA0KPiBXZWJwdXNoQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vd2VicHVzaA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCldlYnB1c2ggbWFpbGluZyBsaXN0DQpXZWJwdXNoQGlldGYub3JnDQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3dlYnB1c2gNCg== From nobody Fri Jun 10 14:28:12 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E51DA12D8E0 for ; Fri, 10 Jun 2016 14:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0h6CsN_faW5Q for ; Fri, 10 Jun 2016 14:28:08 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0110.outbound.protection.outlook.com [207.46.100.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 0A58712D966 for ; Fri, 10 Jun 2016 14:28:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7W+ec/7zkZG1iP5e7Gk63iWDrh3qGLiAunTZbXIKENk=; b=lsJaCMWberaahTBQh1M0PJd289TOlVbrXEmvO1OKPIWs9xgBrGS/dOmzEyOjhOrScvfjV4GMNk0VGJrF153QXw1IbV2+YBUYAUW/S9LgR2r7ZyBxEPYu3HEHjVKw/3hj4oRjUUqNN9BfFueK1OoOtdS1xPIZ55L3PsbGWVEDUVI= Received: from CO2PR03MB2407.namprd03.prod.outlook.com (10.166.93.137) by CO2PR03MB2408.namprd03.prod.outlook.com (10.166.93.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.517.8; Fri, 10 Jun 2016 21:28:06 +0000 Received: from CO2PR03MB2407.namprd03.prod.outlook.com ([10.166.93.137]) by CO2PR03MB2407.namprd03.prod.outlook.com ([10.166.93.137]) with mapi id 15.01.0517.005; Fri, 10 Jun 2016 21:28:06 +0000 From: Brian Raymor To: "webpush@ietf.org" Thread-Topic: Make it a bit more obvious which is the send resource Thread-Index: AdHDXNhAonl6T8X8QNqz9D+vlR3ieg== Date: Fri, 10 Jun 2016 21:28:06 +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: [24.16.23.27] x-ms-office365-filtering-correlation-id: 5bc22ace-542e-4276-8f23-08d391761d18 x-microsoft-exchange-diagnostics: 1; CO2PR03MB2408; 6:BpZzh0wllWOpaWx6HzjS2kLKKBaLR4p/UE7F+JZ/pkE4Zx4rXYsnsjU1JP9+MMFGsJSmUWNfTvbmYlXJjQkDFL3nBWtBVR4VJzJGyV3raJQDaErFTylQaJwzC+W13n39Et890m/2Y8QaHJ+ZRAyQtszQwNuZMYyPjqImluOxXHiPSIvrawVyeMllo3Xovuf9yaV+jhP/BFH5nH/oef/Ke5pILuU09YoxYrNWa82BR0QCSH3buQ0UChRH/t1dhU36TYUBiESGjZsCoMc4pmAk7dsXwIYm88eUyhGbO/EyjgOivIjEmLP4IiFGOMZ83kx9HWan/cDx9gR2D/jck0xAfQ==; 5:8Fbys3lEm38RDav7Rtph2L059dt18w91CFLCgi3hobhtU1uyaKNiaXqkNoEz8+fbeJkZahih4MTJ4xyk8a9gW6aXHKEPpu8aNcwDN8CJvdDnaYjVkBIGEfIk1/tTGNKWGmuMWAuosmqxi56MxYrgGg==; 24:b3rZ4rpO6iQcTmFpBGVI3TkzjS++jwpU+MHuLzgSM/OyGshZo+W1z9Yn0g2afdhwhrwb7LMp4nUf4Bg6z4IjzLAJrKDkO1tjLo/fXl8qu/I=; 7:hufru43eAUmWLkTLc9xtlFa9E7IP+qMix8yUWvccCpUbfBe5ox+J1CtUIWoSLihBqsDq/Zu4Pse2zlXOZEA8LYGzQu7lcdcxGANdA4o0CRm0qwF/rJlR/HhUvA7FeZqEcns0+T9QF9cQavgctKaETZ8TbvOYvBn/3WWAquvOGnLPJYtZWP1x/tAjxEBzoTtcDgML1zShNZxbo2i+5tNjKLh2dPphwzdZeZjjiEjQPQQ8j4tdh1ZFiRvo9I7brSu0 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR03MB2408; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CO2PR03MB2408; BCL:0; PCL:0; RULEID:; SRVR:CO2PR03MB2408; x-forefront-prvs: 096943F07A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(74316001)(2906002)(50986999)(6116002)(54356999)(33656002)(97736004)(8676002)(19580395003)(102836003)(77096005)(92566002)(81166006)(81156014)(5003600100002)(1730700003)(8936002)(3846002)(110136002)(86612001)(189998001)(86362001)(5002640100001)(2900100001)(101416001)(87936001)(586003)(11100500001)(2351001)(15975445007)(107886002)(2501003)(9686002)(229853001)(99286002)(450100001)(106356001)(10400500002)(10290500002)(5004730100002)(105586002)(122556002)(5005710100001)(10090500001)(5640700001)(3660700001)(3280700002)(5008740100001)(68736007)(66066001)(76576001)(8990500004); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR03MB2408; H:CO2PR03MB2407.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2016 21:28:06.9376 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR03MB2408 Archived-At: Subject: [Webpush] Make it a bit more obvious which is the send resource X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 21:28:10 -0000 https://github.com/webpush-wg/webpush-protocol/pull/105 Costin noted - "push resource" is confusing me every time - "push" is used = in all other resources. The original text: The push service MUST provide a URI for the push resource corresponding to the push message subscription in a link relation of type "urn:ietf:params:push". Bikeshed follows. Would adding "delivery" clarify the use? This would match how we currently = describe the process when the application server sends a message. It requests "delivery": The push service MUST provide a URI for the push *delivery* resource corresponding to the push message subscription in a link relation of type "urn:ietf:params:push:delivery". 5. Requesting Push Message Delivery An application server requests the delivery of a push message by sending a HTTP POST request to a push *delivery* resource From nobody Fri Jun 10 15:05:47 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC82C12D986 for ; Fri, 10 Jun 2016 15:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhGBrvsKBmLX for ; Fri, 10 Jun 2016 15:05:43 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0102.outbound.protection.outlook.com [65.55.169.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B538B12D985 for ; Fri, 10 Jun 2016 15:05:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=twVoJXDt8ZwQdIpoSmDVAqaq2KUwAGQp3iKsbxnTL6U=; b=JtZtgfom/MLKjx533F9kxOHP2fWgwvozCRRTW/fz3n6I0kWC4FGqdn2TuXFOEL1JgTIQvJBlflmalG/cNrjJXs42t7/XCYAO3AMFju7iPTyo2ubNppXuU5RtEa4IYJgLvkGDWcDaOkUG6q30+S2Wj005UxCM36HSAXTVgJmzVDI= Received: from CO2PR03MB2407.namprd03.prod.outlook.com (10.166.93.137) by CO2PR03MB2408.namprd03.prod.outlook.com (10.166.93.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.517.8; Fri, 10 Jun 2016 22:05:40 +0000 Received: from CO2PR03MB2407.namprd03.prod.outlook.com ([10.166.93.137]) by CO2PR03MB2407.namprd03.prod.outlook.com ([10.166.93.137]) with mapi id 15.01.0517.005; Fri, 10 Jun 2016 22:05:40 +0000 From: Brian Raymor To: Idel Pivnitskiy , Martin Thomson Thread-Topic: [Webpush] Delivery receipt may be sent before AS request delivery Thread-Index: AQHRwesybhVRwDH2+E+PGN28CwadZ5/gZM8AgALb7vA= Date: Fri, 10 Jun 2016 22:05:40 +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: [24.16.23.27] x-ms-office365-filtering-correlation-id: 1cc10214-43c0-4bce-c73e-08d3917b5c77 x-microsoft-exchange-diagnostics: 1; CO2PR03MB2408; 6:tJhx2KeZcKRr0t2wdCitghkSww2l93NNqex+LRwe1qXswJ7qFrQ1UE3L6UC3R3I9OWK/bkK9sr9av8JyFsB05h6vW2+iuUde6e7xwoRzu6oJqgvJ+E0fAmmB4dT3er9j+Embx7+C4WIPHKDP2CCzHP8bZDudg0KSOxH2ioax3tHGUwwP3Ja6aQk/Mne7jClJBR4BBwwcMXIQ/1T6iL1yx55oIPgJwa8P3EW16r41vaUgBJxjMiBcHoAh8kGbTjI1Me5CZgtqthTxELR522aRANzhwgaXze5eKqqWhQBRSZ1GoMCpem6vZMtw6AWIcaM+; 5:KbScMsttSBkY7RujPZT5OEhg5lcUUDkiGrV0Dxiy9GHd6as4uTkqcTi8IyGSfRUwgyhfujEaUY7wvYUNMLVG8pWerqx7soRBIVITj2430xki0ovnZD64dPkIuyoYXbe82yDkqhY8vkFZE+/tm6Qdfg==; 24:AB0QYX3R5MFcv/1HcW4cwzfh94+yMsD1KZMNZklbz1t9cdn3o2+xqIiJdRGwIGjmLMz2nEgsvM9Y+N+O7kOGBHZjPi6McFJl7SM3XxBqwxQ=; 7:bAz+R6gi+H1gkHiioZ5wG4O6Iy39QjaNAGElBXm2Y4k8PTp82wFFVRtZcVC81o5NdLCqpQCCFBUeRZ6ngWFwoJa4icYb5kxjWlTQqaMlLU20vwxl+6WETkDTkrCPwo4LLKsmiEx6K/vOSlAyIG2BE6lNpzi5kRcEcOnBnNbEjSDvhaDv5/xMOzR7MamP0zU3V5TyFkhhOesdLSFV5vZWI5/AJVk1mJ89DA7fFGn7agPXV1onqJcptLVw5KImypAG x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR03MB2408; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(148322886591682)(166708455590820)(31418570063057)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CO2PR03MB2408; BCL:0; PCL:0; RULEID:; SRVR:CO2PR03MB2408; x-forefront-prvs: 096943F07A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(24454002)(189002)(377454003)(12063002)(199003)(99286002)(106356001)(9686002)(10090500001)(5005710100001)(10290500002)(10400500002)(19625215002)(105586002)(122556002)(5004730100002)(106116001)(15975445007)(11100500001)(76576001)(19617315012)(8990500004)(19300405004)(5008740100001)(3280700002)(3660700001)(66066001)(68736007)(19580395003)(790700001)(74316001)(102836003)(92566002)(76176999)(77096005)(5001770100001)(6116002)(54356999)(2906002)(50986999)(33656002)(16236675004)(97736004)(19580405001)(575784001)(86362001)(2900100001)(101416001)(87936001)(5002640100001)(16601075003)(1680700002)(19609705001)(586003)(2950100001)(5003600100002)(8936002)(81166006)(81156014)(86612001)(189998001)(4326007)(7906002)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR03MB2408; H:CO2PR03MB2407.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CO2PR03MB2407923CBD0C24766814229483500CO2PR03MB2407namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2016 22:05:40.6949 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR03MB2408 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Delivery receipt may be sent before AS request delivery X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 22:05:45 -0000 --_000_CO2PR03MB2407923CBD0C24766814229483500CO2PR03MB2407namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpXZSByZWNlbnRseSByZWFjaGVkIGNvbnNlbnN1cyBvbiB0aGUgc2ltcGxpZmllZCBkZXNpZ24g Zm9yIHJlY2VpcHRzIGFzIE1hcnRpbiBub3RlcyBiZWxvdyAoYW5kIGFzIEkgbm90ZWQgaW4gdGhl IGlzc3VlKS4gSSBkb27igJl0IHNlZSBzdHJvbmcgaW50ZXJlc3QgaW4gcmV2ZXJ0aW5nIHRoYXQg Y2hhbmdlLg0KDQpQYXJ0IG9mIHRoZSBjb21wbGV4aXR5IHlvdeKAmXJlIHNlZWluZyBpcyByZWxh dGVkIHRvIG91ciBjb25zaXN0ZW50IHVzZSBvZiBoYXJkLXRvLWd1ZXNzIGNhcGFiaWxpdHkgVVJJ KHMpLg0KDQpSZWdhcmRpbmcgMjAxIHZzIDIwMiDigJMgU2VlIGFsc28gLSBodHRwOi8vd3d3Lmll dGYub3JnL21haWwtYXJjaGl2ZS93ZWIvd2VicHVzaC9jdXJyZW50L21zZzAwNDM5Lmh0bWwgLQ0K DQpDbG9zZWQgaHR0cHM6Ly9naXRodWIuY29tL3dlYnB1c2gtd2cvd2VicHVzaC1wcm90b2NvbC9p c3N1ZXMvMTE1DQoNCg0KRnJvbTogV2VicHVzaCBbbWFpbHRvOndlYnB1c2gtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIElkZWwgUGl2bml0c2tpeQ0KU2VudDogV2VkbmVzZGF5LCBKdW5l IDgsIDIwMTYgNzoxMiBQTQ0KVG86IE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFp bC5jb20+DQpDYzogd2VicHVzaEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtXZWJwdXNoXSBEZWxp dmVyeSByZWNlaXB0IG1heSBiZSBzZW50IGJlZm9yZSBBUyByZXF1ZXN0IGRlbGl2ZXJ5DQoNCkkg aW1wbGVtZW50ZWQgdGhlIGRlc2lnbiB3aGljaCBkZXNjcmliZXMgYXMgIkJlZm9yZSIgaW4gdGhp cyBwcmVzZW50YXRpb24gWzFdIGxhc3QgeWVhci4gQW5kIEkgYWdyZWUgdGhhdCBpbnRlcmFjdGlv biBvZiBVQSBpbiB0aGlzIHByb2Nlc3MgaXMgaW5jb252ZW5pZW50LiBJdCBzaG91bGQgYmUgc29t ZXRoaW5nIGxpa2UgdGhpcyBbMl0sIGJ1dCBpbnN0ZWFkIG9mIHVzaW5nIHRva2VuLVVSSSBsaWtl IC9yZWNlaXB0cy94alRHNzlJM1Z1cHROV1MwRHNGdTRpaFQ5N2FFNlVRSiwgaW50cm9kdWNlIHNv bWV0aGluZyBtb3JlIHNpbXBsZSwgbGlrZToNCg0KUE9TVCAvc3Vic2NyaWJlLWZvci1yZWNlaXB0 IEhUVFAvMS4xDQpIb3N0OiBwdXNoLmV4YW1wbGUubmV0PGh0dHA6Ly9wdXNoLmV4YW1wbGUubmV0 Pg0KDQpCZW5lZml0czoNCg0KICAxLiAgc3Vic2NyaXB0aW9uIG1heSBiZSBjcmVhdGVkIGFuZCBy ZWNlaXZpbmcgUHVzaCBNZXNzYWdlIFJlY2VpcHRzIG1heSBiZSByZXF1ZXN0ZWQgYmVmb3JlIHNl bmRpbmcgYSBuZXcgcHVzaCBtZXNzYWdlID0+IG5vIGRlbGl2ZXJ5IHJlY2VpcHRzIHdpbGwgYmUg bG9zdDsNCiAgMi4gIG5vIG5lZWQgdG8gc2VuZCBhIHB1c2ggbWVzc2FnZSB0byBnZXQgcmVjZWlw dCBzdWJzY3JpcHRpb24gcmVzb3VyY2U7DQogIDMuICBlYXN5IHJlY2VpcHQgc3Vic2NyaXB0aW9u IG1hbmFnZW1lbnQgYW5kIHJlY2VpdmluZyByZWNlaXB0cyAoQVMgbWF5IGhhdmUgYSBzZXBhcmF0 ZSB0aHJlYWQgb3Igc2VydmljZSBmb3IgdGhpcyBwdXJwb3NlKTsNCiAgNC4gIHNpbXBsaWZ5aW5n IHJlZ2lzdHJhdGlvbiBvZiBhIG5ldyBwdXNoIG1lc3NhZ2Ugb24gUFMgc2lkZToganVzdCBvbmUg bmV3IG9iamVjdCB3aWxsIGJlIGNyZWF0ZWQgKGEgcHVzaCBtZXNzYWdlKSwgbm8gbmVlZCB0byB0 aGluayBhYm91dCBtYW5hZ2VtZW50IG9mIHJlY2VpcHQgc3Vic2NyaXB0aW9ucyAod2hhdCBpdCBu ZWVkcyB0byBkbz8gcmV0dXJuIHRoZSBzYW1lIHJlY2VpcHQgc3Vic2NyaXB0aW9uIG9yIGEgbmV3 IG9uZSkuDQpFdmVuIGlmIHRoZSAxc3QgaXNzdWUgaXMgbm90IGEgYmlnIGRlYWwsIGJlY2F1c2Ug d2UgbWF5IGluY3JlYXNlIFRUTCB2YWx1ZSwgdGhlIDR0aCB3aWxsIHNpbXBsaWZ5IGEgUFMgYW5k IHRoZSAzcmQgd2lsbCBiZSBtb3JlIGFwcHJvcHJpYXRlIGZvciBhbiBBUy4NCg0KSSdtIGFsc28g YSBsaXR0bGUgYml0IGNvbmZ1c2VkLCB3aGVuIHJlYWRpbmcgdGhlIGRyYWZ0IGFuZCBzZWUgdGhl IHNhbWUgc2VudGVuY2UsIGJ1dCB3aXRoIGRpZmZlcmVudCBzdGF0dXMgY29kZXM6DQoNCiAgKiAg IFNlY3Rpb24gNTogQSAyMDEgKENyZWF0ZWQpIHJlc3BvbnNlIGluZGljYXRlcyB0aGF0IHRoZSBw dXNoIG1lc3NhZ2Ugd2FzIGFjY2VwdGVkLg0KICAqICAgU2VjdGlvbiA1LjE6IEEgMjAyIChBY2Nl cHRlZCkgcmVzcG9uc2UgaW5kaWNhdGVzIHRoYXQgdGhlIHB1c2ggbWVzc2FnZSB3YXMgYWNjZXB0 ZWQuDQogICogICBTZWN0aW9uIDUuNDogQSAyMDEgKENyZWF0ZWQpIHJlc3BvbnNlIGluZGljYXRl cyB0aGF0IHRoZSBwdXNoIG1lc3NhZ2UgcmVwbGFjZW1lbnQgd2FzIGFjY2VwdGVkLg0KV2hhdCB3 aWxsIGJlIGZvciByZXBsYWNpbmcgUHVzaCBNZXNzYWdlIHdpdGggcmVxdWVzdGluZyBkZWxpdmVy eSByZWNlaXB0OiAiQSAyMDIgKEFjY2VwdGVkKSByZXNwb25zZSBpbmRpY2F0ZXMgdGhhdCB0aGUg cHVzaCBtZXNzYWdlIHJlcGxhY2VtZW50IHdhcyBhY2NlcHRlZCI/DQoNCkFub3RoZXIgYWR2YW50 YWdlOiBqdXN0IG9uZSBzdGF0dXMgY29kZSB3aWxsIGJlIHJldHVybmVkIHdoZW4gQVMgcmVxdWVz dHMgUHVzaCBNZXNzYWdlIGRlbGl2ZXJ5Lg0KDQpbMV0gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJv Y2VlZGluZ3MvOTUvc2xpZGVzL3NsaWRlcy05NS13ZWJwdXNoLTEucGRmDQpbMl0gaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtd2VicHVzaC1wcm90b2NvbC0wNCNzZWN0aW9u LTUNCg0KQmVzdCByZWdhcmRzLA0KSWRlbCBQaXZuaXRza2l5DQotLQ0KVHdpdHRlcjogQGlkZWxw aXZuaXRza2l5PGh0dHBzOi8vdHdpdHRlci5jb20vaWRlbHBpdm5pdHNraXk+DQpHaXRIdWI6IEBp ZGVscGl2bml0c2tpeTxodHRwczovL2dpdGh1Yi5jb20vaWRlbHBpdm5pdHNraXk+DQoNCk9uIFRo dSwgSnVuIDksIDIwMTYgYXQgNDowNiBBTSwgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29u QGdtYWlsLmNvbTxtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tPj4gd3JvdGU6DQpGb3Ig Y29udGV4dDoNCg0KPiBIZXJlIG1heSBiZSBhIHByb2JsZW0gd2l0aCBwdXNoIG1lc3NhZ2VzIHdp dGggYSBsaXR0bGUgdmFsdWUgb2YgVFRMLiBNZXNzYWdlIG1heSBiZSBzZW50IHRvIGEgVUEgYW5k IGFjayBtYXkgYmUgcmVjZWl2ZWQgZnJvbSB0aGUgVUEgYmVmb3JlIHRoZSBBUyB3aWxsIHNlbmQg YSBIVFRQIEdFVCByZXF1ZXN0IHRvIHRoZSByZWNlaXB0IHN1YnNjcmlwdGlvbiByZXNvdXJjZS4g UFMgd2lsbCByZXRyeSBkZWxpdmVyaW5nIG9mIHJlY2VpcHQsIGJ1dCBUVEwgbWF5IGV4cGlyZSBi ZWZvcmUgdGhpcy4NCj4NCj4gVG8gZWxpbWluYXRlIHRoaXMgcHJvYmxlbSBpdCB3b3VsZCBiZSBi ZXR0ZXIgdG8gaW50cm9kdWNlIHNlcGFyYXRlIHJlc291cmNlIGZvciBhbiBBUzogc29tZXRoaW5n IGxpa2UgL3N1YnNjcmliZSBmb3IgYSBVQSwgd2hlcmUgQVMgbWF5IGNyZWF0ZSBhIHJlY2VpcHQg c3Vic2NyaXB0aW9uLg0KDQpXZSBvcmlnaW5hbGx5IGhhZCB0aGUgZGVzaWduIHlvdSBkZXNjcmli ZSwgYnV0IEBicmlhbnJheW1vciBwcm9wb3NlZCBhDQpzaW1wbGVyIGRlc2lnbiB0aGF0IGFjY29t cGxpc2hlcyB0aGUgc2FtZSBnb2FscywgcHJvdmlkaW5nIHRoYXQgeW91DQpyZWNvZ25pemUgdGhh dCBhIFRUTCBzaG9ydGVyIHRoYW4gdGhlIHRpbWUgaXQgdGFrZXMgdG8gcG9sbCB0aGUNCnJlY2Vp cHQgc3Vic2NyaXB0aW9uIHJlc291cmNlIGNhbiByZXN1bHQgaW4gbG9zaW5nIHRoZSByZWNlaXB0 Lg0KDQpUaGUgb25seSBnb29kIHNvbHV0aW9uIHRvIHRoaXMgZ2VuZXJhbCBwcm9ibGVtIGlzIHRv IGhhdmUgYSBsb25nZXIgVFRMLg0KDQpFdmVuIGlmIHlvdSBmaXggdGhlICJidWciIHlvdSBpZGVu dGlmaWVkLCBhIHNob3J0IFRUTCBjYW4gZXhwaXJlDQpiZXR3ZWVuIHRoZSB0aW1lIHRoYXQgdGhl IG1lc3NhZ2UgaXMgZGVsaXZlcmVkIHRvIHRoZSB1c2VyIGFnZW50IGFuZA0KYmVmb3JlIHRoZSBh Y2tub3dsZWRnbWVudCBjYW4gcmVhY2ggdGhlIHB1c2ggc2VydmljZS4NCg0KDQpPbiA5IEp1bmUg MjAxNiBhdCAwOTowNywgSWRlbCBQaXZuaXRza2l5IDxpZGVsLnBpdm5pdHNraXlAZ21haWwuY29t PG1haWx0bzppZGVsLnBpdm5pdHNraXlAZ21haWwuY29tPj4gd3JvdGU6DQo+IEZvdW5kIG91dCBh IHByb2JsZW0gd2l0aCBsb3N0IG9mIGRlbGl2ZXJ5IHJlY2VpcHRzIGZvciBwdXNoIG1lc3NhZ2Vz IHdpdGgNCj4gbGl0dGxlIFRUTCwgYW4gaXNzdWUgd2FzIGNyZWF0ZWQ6DQo+DQo+IGh0dHBzOi8v Z2l0aHViLmNvbS93ZWJwdXNoLXdnL3dlYnB1c2gtcHJvdG9jb2wvaXNzdWVzLzExNQ0KPg0KPiBC ZXN0IHJlZ2FyZHMsDQo+IElkZWwgUGl2bml0c2tpeQ0KPiAtLQ0KPiBUd2l0dGVyOiBAaWRlbHBp dm5pdHNraXkNCj4gR2l0SHViOiBAaWRlbHBpdm5pdHNraXkNCj4NCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gV2VicHVzaCBtYWlsaW5nIGxpc3QN Cj4gV2VicHVzaEBpZXRmLm9yZzxtYWlsdG86V2VicHVzaEBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby93ZWJwdXNoDQo+DQoNCg== --_000_CO2PR03MB2407923CBD0C24766814229483500CO2PR03MB2407namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDAN Cgl7bXNvLWxpc3QtaWQ6MTY4NzcwNzU1MDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTQ0MTgy NTc4O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2 ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDkN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoyMDY3ODcw MDI3Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTg4ODQ3NzI4Njt9DQpvbA0KCXttYXJnaW4t Ym90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21w b3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29t cG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5XZSByZWNlbnRseSByZWFjaGVkIGNvbnNlbnN1cyBvbiB0 aGUgc2ltcGxpZmllZCBkZXNpZ24gZm9yIHJlY2VpcHRzIGFzIE1hcnRpbiBub3RlcyBiZWxvdyAo YW5kIGFzIEkgbm90ZWQgaW4gdGhlIGlzc3VlKS4gSSBkb27igJl0DQogc2VlIHN0cm9uZyBpbnRl cmVzdCBpbiByZXZlcnRpbmcgdGhhdCBjaGFuZ2UuPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxF bmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5QYXJ0IG9mIHRoZSBjb21wbGV4aXR5IHlv deKAmXJlIHNlZWluZyBpcyByZWxhdGVkIHRvIG91ciBjb25zaXN0ZW50IHVzZSBvZiBoYXJkLXRv LWd1ZXNzIGNhcGFiaWxpdHkgVVJJKHMpLg0KPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRD b21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls RW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5SZWdhcmRpbmcgMjAxIHZzIDIwMiDigJMgU2Vl IGFsc28gLQ0KPC9zcGFuPjwvc3Bhbj48YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwt YXJjaGl2ZS93ZWIvd2VicHVzaC9jdXJyZW50L21zZzAwNDM5Lmh0bWwiPjxzcGFuIHN0eWxlPSJt c28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPmh0dHA6Ly93d3cu aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi93ZWJwdXNoL2N1cnJlbnQvbXNnMDA0MzkuaHRtbDwv c3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwv c3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+DQogLSA8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3Nl Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkNsb3NlZA0KPC9zcGFuPjwvc3Bhbj48YSBocmVmPSJodHRwczov L2dpdGh1Yi5jb20vd2VicHVzaC13Zy93ZWJwdXNoLXByb3RvY29sL2lzc3Vlcy8xMTUiPjxzcGFu IHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPmh0 dHBzOi8vZ2l0aHViLmNvbS93ZWJwdXNoLXdnL3dlYnB1c2gtcHJvdG9jb2wvaXNzdWVzLzExNTwv c3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwv c3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHNwYW4g c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+IFdlYnB1c2ggW21haWx0bzp3ZWJwdXNoLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBC ZWhhbGYgT2YgPC9iPklkZWwgUGl2bml0c2tpeTxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXks IEp1bmUgOCwgMjAxNiA3OjEyIFBNPGJyPg0KPGI+VG86PC9iPiBNYXJ0aW4gVGhvbXNvbiAmbHQ7 bWFydGluLnRob21zb25AZ21haWwuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gd2VicHVzaEBpZXRm Lm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1dlYnB1c2hdIERlbGl2ZXJ5IHJlY2VpcHQg bWF5IGJlIHNlbnQgYmVmb3JlIEFTIHJlcXVlc3QgZGVsaXZlcnk8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGltcGxlbWVudGVkIHRoZSBkZXNpZ24gd2hpY2ggZGVzY3Jp YmVzIGFzICZxdW90O0JlZm9yZSZxdW90OyBpbiB0aGlzIHByZXNlbnRhdGlvbiBbMV0gbGFzdCB5 ZWFyLiBBbmQgSSBhZ3JlZSB0aGF0IGludGVyYWN0aW9uIG9mIFVBIGluIHRoaXMgcHJvY2VzcyBp cyZuYnNwO2luY29udmVuaWVudC4gSXQgc2hvdWxkIGJlIHNvbWV0aGluZyBsaWtlIHRoaXMgWzJd LCBidXQgaW5zdGVhZCBvZiB1c2luZyB0b2tlbi1VUkkgbGlrZSZuYnNwOy9yZWNlaXB0cy94alRH NzlJM1Z1cHROV1MwRHNGdTRpaFQ5N2FFNlVRSiwNCiBpbnRyb2R1Y2Ugc29tZXRoaW5nIG1vcmUg c2ltcGxlLCBsaWtlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlBPU1QgL3N1YnNjcmliZS1mb3ItcmVjZWlwdCBIVFRQLzEuMTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG9zdDogPGEgaHJlZj0i aHR0cDovL3B1c2guZXhhbXBsZS5uZXQiPnB1c2guZXhhbXBsZS5uZXQ8L2E+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZW5lZml0 czo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxvbCBzdGFydD0iMSIgdHlwZT0iMSI+ DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8xIj4NCnN1YnNj cmlwdGlvbiBtYXkgYmUgY3JlYXRlZCBhbmQgcmVjZWl2aW5nIFB1c2ggTWVzc2FnZSBSZWNlaXB0 cyBtYXkgYmUgcmVxdWVzdGVkIGJlZm9yZSBzZW5kaW5nIGEgbmV3IHB1c2ggbWVzc2FnZSA9Jmd0 OyBubyBkZWxpdmVyeSByZWNlaXB0cyB3aWxsIGJlIGxvc3Q7PG86cD48L286cD48L2xpPjxsaSBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzEiPg0Kbm8gbmVlZCB0byBz ZW5kIGEgcHVzaCBtZXNzYWdlIHRvIGdldCByZWNlaXB0IHN1YnNjcmlwdGlvbiByZXNvdXJjZTs8 bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMSBsZXZlbDEg bGZvMSI+DQplYXN5IHJlY2VpcHQgc3Vic2NyaXB0aW9uIG1hbmFnZW1lbnQgYW5kIHJlY2Vpdmlu ZyByZWNlaXB0cyAoQVMgbWF5IGhhdmUgYSBzZXBhcmF0ZSB0aHJlYWQgb3Igc2VydmljZSBmb3Ig dGhpcyBwdXJwb3NlKTs8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28t bGlzdDpsMSBsZXZlbDEgbGZvMSI+DQpzaW1wbGlmeWluZyByZWdpc3RyYXRpb24gb2YgYSBuZXcg cHVzaCBtZXNzYWdlIG9uIFBTIHNpZGU6IGp1c3Qgb25lIG5ldyBvYmplY3Qgd2lsbCBiZSBjcmVh dGVkIChhIHB1c2ggbWVzc2FnZSksIG5vIG5lZWQgdG8gdGhpbmsgYWJvdXQgbWFuYWdlbWVudCBv ZiByZWNlaXB0IHN1YnNjcmlwdGlvbnMgKHdoYXQgaXQgbmVlZHMgdG8gZG8/IHJldHVybiB0aGUg c2FtZSByZWNlaXB0IHN1YnNjcmlwdGlvbiBvciBhIG5ldyBvbmUpLjxvOnA+PC9vOnA+PC9saT48 L29sPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FdmVuIGlm IHRoZSAxc3QgaXNzdWUgaXMgbm90IGEgYmlnIGRlYWwsIGJlY2F1c2Ugd2UgbWF5IGluY3JlYXNl IFRUTCB2YWx1ZSwgdGhlIDR0aCB3aWxsIHNpbXBsaWZ5IGEgUFMgYW5kIHRoZSAzcmQgd2lsbCBi ZSBtb3JlIGFwcHJvcHJpYXRlIGZvciBhbiBBUy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdtIGFsc28gYSBsaXR0bGUgYml0IGNvbmZ1c2Vk LCB3aGVuIHJlYWRpbmcgdGhlIGRyYWZ0IGFuZCBzZWUgdGhlIHNhbWUgc2VudGVuY2UsIGJ1dCB3 aXRoIGRpZmZlcmVudCBzdGF0dXMgY29kZXM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxl dmVsMSBsZm8yIj4NClNlY3Rpb24gNTombmJzcDtBIDIwMSAoQ3JlYXRlZCkgcmVzcG9uc2UgaW5k aWNhdGVzIHRoYXQgdGhlIHB1c2ggbWVzc2FnZSB3YXMgYWNjZXB0ZWQuPG86cD48L286cD48L2xp PjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0KU2VjdGlv biA1LjE6Jm5ic3A7QSAyMDIgKEFjY2VwdGVkKSByZXNwb25zZSBpbmRpY2F0ZXMgdGhhdCB0aGUg cHVzaCBtZXNzYWdlIHdhcyBhY2NlcHRlZC48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQpTZWN0aW9uIDUuNDombmJzcDtBIDIw MSAoQ3JlYXRlZCkgcmVzcG9uc2UgaW5kaWNhdGVzIHRoYXQgdGhlIHB1c2ggbWVzc2FnZSByZXBs YWNlbWVudCB3YXMgYWNjZXB0ZWQuPG86cD48L286cD48L2xpPjwvdWw+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IHdpbGwgYmUgZm9yIHJlcGxhY2luZyBQdXNoIE1l c3NhZ2Ugd2l0aCByZXF1ZXN0aW5nIGRlbGl2ZXJ5IHJlY2VpcHQ6ICZxdW90O0EgMjAyIChBY2Nl cHRlZCkgcmVzcG9uc2UgaW5kaWNhdGVzIHRoYXQgdGhlIHB1c2ggbWVzc2FnZSByZXBsYWNlbWVu dCB3YXMgYWNjZXB0ZWQmcXVvdDs/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkFub3RoZXIgYWR2YW50YWdlOiBqdXN0IG9uZSBzdGF0dXMgY29k ZSB3aWxsIGJlIHJldHVybmVkIHdoZW4gQVMgcmVxdWVzdHMgUHVzaCBNZXNzYWdlIGRlbGl2ZXJ5 LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5b MV0mbmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85NS9zbGlk ZXMvc2xpZGVzLTk1LXdlYnB1c2gtMS5wZGYiPmh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRp bmdzLzk1L3NsaWRlcy9zbGlkZXMtOTUtd2VicHVzaC0xLnBkZjwvYT48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WzJdJm5ic3A7PGEg aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtd2VicHVzaC1wcm90 b2NvbC0wNCNzZWN0aW9uLTUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LXdlYnB1c2gtcHJvdG9jb2wtMDQjc2VjdGlvbi01PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZGVsIFBpdm5pdHNraXk8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ud2l0dGVyOiA8YSBocmVmPSJo dHRwczovL3R3aXR0ZXIuY29tL2lkZWxwaXZuaXRza2l5IiB0YXJnZXQ9Il9ibGFuayI+DQpAaWRl bHBpdm5pdHNraXk8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5HaXRIdWI6Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2lkZWxw aXZuaXRza2l5IiB0YXJnZXQ9Il9ibGFuayI+QGlkZWxwaXZuaXRza2l5PC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBKdW4gOSwgMjAxNiBh dCA0OjA2IEFNLCBNYXJ0aW4gVGhvbXNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcnRpbi50aG9t c29uQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkZvciBjb250ZXh0Ojxicj4NCjxicj4NCiZndDsgSGVyZSBtYXkgYmUgYSBwcm9ibGVt IHdpdGggcHVzaCBtZXNzYWdlcyB3aXRoIGEgbGl0dGxlIHZhbHVlIG9mIFRUTC4gTWVzc2FnZSBt YXkgYmUgc2VudCB0byBhIFVBIGFuZCBhY2sgbWF5IGJlIHJlY2VpdmVkIGZyb20gdGhlIFVBIGJl Zm9yZSB0aGUgQVMgd2lsbCBzZW5kIGEgSFRUUCBHRVQgcmVxdWVzdCB0byB0aGUgcmVjZWlwdCBz dWJzY3JpcHRpb24gcmVzb3VyY2UuIFBTIHdpbGwgcmV0cnkgZGVsaXZlcmluZyBvZiByZWNlaXB0 LCBidXQNCiBUVEwgbWF5IGV4cGlyZSBiZWZvcmUgdGhpcy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBU byBlbGltaW5hdGUgdGhpcyBwcm9ibGVtIGl0IHdvdWxkIGJlIGJldHRlciB0byBpbnRyb2R1Y2Ug c2VwYXJhdGUgcmVzb3VyY2UgZm9yIGFuIEFTOiBzb21ldGhpbmcgbGlrZSAvc3Vic2NyaWJlIGZv ciBhIFVBLCB3aGVyZSBBUyBtYXkgY3JlYXRlIGEgcmVjZWlwdCBzdWJzY3JpcHRpb24uPGJyPg0K PGJyPg0KV2Ugb3JpZ2luYWxseSBoYWQgdGhlIGRlc2lnbiB5b3UgZGVzY3JpYmUsIGJ1dCBAYnJp YW5yYXltb3IgcHJvcG9zZWQgYTxicj4NCnNpbXBsZXIgZGVzaWduIHRoYXQgYWNjb21wbGlzaGVz IHRoZSBzYW1lIGdvYWxzLCBwcm92aWRpbmcgdGhhdCB5b3U8YnI+DQpyZWNvZ25pemUgdGhhdCBh IFRUTCBzaG9ydGVyIHRoYW4gdGhlIHRpbWUgaXQgdGFrZXMgdG8gcG9sbCB0aGU8YnI+DQpyZWNl aXB0IHN1YnNjcmlwdGlvbiByZXNvdXJjZSBjYW4gcmVzdWx0IGluIGxvc2luZyB0aGUgcmVjZWlw dC48YnI+DQo8YnI+DQpUaGUgb25seSBnb29kIHNvbHV0aW9uIHRvIHRoaXMgZ2VuZXJhbCBwcm9i bGVtIGlzIHRvIGhhdmUgYSBsb25nZXIgVFRMLjxicj4NCjxicj4NCkV2ZW4gaWYgeW91IGZpeCB0 aGUgJnF1b3Q7YnVnJnF1b3Q7IHlvdSBpZGVudGlmaWVkLCBhIHNob3J0IFRUTCBjYW4gZXhwaXJl PGJyPg0KYmV0d2VlbiB0aGUgdGltZSB0aGF0IHRoZSBtZXNzYWdlIGlzIGRlbGl2ZXJlZCB0byB0 aGUgdXNlciBhZ2VudCBhbmQ8YnI+DQpiZWZvcmUgdGhlIGFja25vd2xlZGdtZW50IGNhbiByZWFj aCB0aGUgcHVzaCBzZXJ2aWNlLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQpPbiA5IEp1bmUgMjAxNiBhdCAwOTowNywgSWRlbCBQ aXZuaXRza2l5ICZsdDs8YSBocmVmPSJtYWlsdG86aWRlbC5waXZuaXRza2l5QGdtYWlsLmNvbSI+ aWRlbC5waXZuaXRza2l5QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgRm91bmQg b3V0IGEgcHJvYmxlbSB3aXRoIGxvc3Qgb2YgZGVsaXZlcnkgcmVjZWlwdHMgZm9yIHB1c2ggbWVz c2FnZXMgd2l0aDxicj4NCiZndDsgbGl0dGxlIFRUTCwgYW4gaXNzdWUgd2FzIGNyZWF0ZWQ6PGJy Pg0KJmd0Ozxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL3dlYnB1c2gtd2cv d2VicHVzaC1wcm90b2NvbC9pc3N1ZXMvMTE1IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2dp dGh1Yi5jb20vd2VicHVzaC13Zy93ZWJwdXNoLXByb3RvY29sL2lzc3Vlcy8xMTU8L2E+PGJyPg0K Jmd0Ozxicj4NCiZndDsgQmVzdCByZWdhcmRzLDxicj4NCiZndDsgSWRlbCBQaXZuaXRza2l5PGJy Pg0KJmd0OyAtLTxicj4NCiZndDsgVHdpdHRlcjogQGlkZWxwaXZuaXRza2l5PGJyPg0KJmd0OyBH aXRIdWI6IEBpZGVscGl2bml0c2tpeTxicj4NCiZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBXZWJwdXNoIG1haWxpbmcgbGlzdDxi cj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOldlYnB1c2hAaWV0Zi5vcmciPldlYnB1c2hAaWV0Zi5v cmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3dlYnB1c2giIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3dlYnB1c2g8L2E+PGJyPg0KJmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CO2PR03MB2407923CBD0C24766814229483500CO2PR03MB2407namp_-- From nobody Fri Jun 10 19:14:39 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD5F12D59A for ; Fri, 10 Jun 2016 19:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7cOzXz5hOOY for ; Fri, 10 Jun 2016 19:14:34 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0752.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::752]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C47C12B005 for ; Fri, 10 Jun 2016 19:14:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=R1VlMt/2koueUEpwEWC3ToasJ9cMN+1QC2nbtc8h+Sg=; b=ic+1aZII/dCFto+A6xRDceTYbMA/H/yJkEcGVf2N5FdFjySpDNSX8GL/JCC0vN4ZJ1n2ZShHrPQlkWakFnhrTAcsBqB3CZjL36YBqzkb2Vwstu8kkw17mC6q0d3PD8XV3m49Xi/l+B8G67cLCmGGpkuDZX6a9ieQZ9xoGw/2eV0= Received: from CO2PR03MB2407.namprd03.prod.outlook.com (10.166.93.137) by CO2PR03MB2407.namprd03.prod.outlook.com (10.166.93.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.517.8; Sat, 11 Jun 2016 02:14:16 +0000 Received: from CO2PR03MB2407.namprd03.prod.outlook.com ([10.166.93.137]) by CO2PR03MB2407.namprd03.prod.outlook.com ([10.166.93.137]) with mapi id 15.01.0517.005; Sat, 11 Jun 2016 02:14:16 +0000 From: Brian Raymor To: Idel Pivnitskiy , "webpush@ietf.org" Thread-Topic: [Webpush] Prefer: wait=0 for Receiving Push Message Receipts Thread-Index: AdHCmaXPqP5E+T/6TVO6nqulqOJ2zgAsHEeAAA8jShA= Date: Sat, 11 Jun 2016 02:14:16 +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: [24.16.23.27] x-ms-office365-filtering-correlation-id: 56af3cc7-5c43-4f13-e444-08d3919e170a x-microsoft-exchange-diagnostics: 1; CO2PR03MB2407; 6:hagB8f7MQvOad9QQI64xgBRBCrFXDoH6bfYsiC7ZakJr28OpxCMOadnVatvCKITJ/4RsaP+nZvHoqXrPaVWzk2rikJnG9p5eYFHPEyq1f6Pg9mv3VP9BDSvfFOFnLs79gSH7rB4pP2sQMy1TpCx4vMmZcPJUm5X/h5snB7GU6r4Sn5SCk/vXvd7cSEvhj5hGlSoGFVlIAs0pYfoaALgJtEOinXl1qOcEuFcBxe6D0Qu9D5b6kNWZTXAK04rQOxQl+EmZost0mI3Osh4D5vs3j0KEXvPZrct8FCg03VSMPAA=; 5:BSKNSKP6edD5GsnPVECZE3xNIIHe/W07XCb8lrrwQku9B2rcxH5DiTteGoihDmhdxMfeKMNAAd4ST6Ro8uj0xgf/kEjHJxZ6a3eoW7l+/jNQtPIaqixS0OFkJULyBAarkXDIGUMf0J8YazyVN/WH6w==; 24:RoEhHjVFt2H4TIxYR8foK2068jOPnL7OZ0D8zAFaAcbprvNZvjeeZOeCgahsU6NomrcpUOi8xIy+LX4aTKlgyrIPDeP+2XGJaM8VGPGTgA8=; 7:LNej2ZuTflkERj3hRjkJ6nHTu2rA6ZAfryjPz5EKMpXfXmYmNXlw8n2a3ASKxYcDqrbjOp1SUtKcOacoiI/Y7N1F/DsmWrQCWtQeungW3FB5sweQiuDfQvZpShjJmRXdfZS1NAz7XPYneYTm6YHa5hJRLSPXOyKbXcfuHWqTSrV0Ke66WMKtrEKcnXeLfsxBJhFOBdwSfzI6d4TBwstQR14SqINjIxXs6VgCbGpK0JI= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR03MB2407; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(148322886591682)(166708455590820)(209352067349851)(31418570063057); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CO2PR03MB2407; BCL:0; PCL:0; RULEID:; SRVR:CO2PR03MB2407; x-forefront-prvs: 0970508454 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(78114003)(189002)(24454002)(377454003)(199003)(12063002)(74316001)(54356999)(101416001)(10090500001)(8990500004)(19580405001)(68736007)(76176999)(122556002)(2906002)(5005710100001)(5002640100001)(10290500002)(19580395003)(50986999)(99286002)(10400500002)(105586002)(15975445007)(5003600100002)(9686002)(77096005)(92566002)(5001770100001)(106356001)(97736004)(8936002)(6116002)(11100500001)(3280700002)(189998001)(86612001)(5008740100001)(87936001)(81166006)(107886002)(81156014)(3660700001)(2950100001)(3846002)(76576001)(2900100001)(8676002)(2501003)(102836003)(66066001)(86362001)(33656002)(15650500001)(5004730100002)(586003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR03MB2407; H:CO2PR03MB2407.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2016 02:14:16.5415 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR03MB2407 Archived-At: Subject: Re: [Webpush] Prefer: wait=0 for Receiving Push Message Receipts X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2016 02:14:36 -0000 SeKAmW0gbm90IGhlYXJpbmcgYnJvYWQgc3VwcG9ydCB0byBhZGQgdGhpcyBmZWF0dXJlIGR1cmlu ZyBXR0xDLg0KDQpDbG9zZWQgaHR0cHM6Ly9naXRodWIuY29tL3dlYnB1c2gtd2cvd2VicHVzaC1w cm90b2NvbC9pc3N1ZXMvMTEzDQoNCg0KRnJvbTogV2VicHVzaCBbbWFpbHRvOndlYnB1c2gtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIElkZWwgUGl2bml0c2tpeQ0KU2VudDogRnJpZGF5 LCBKdW5lIDEwLCAyMDE2IDExOjU5IEFNDQpUbzogd2VicHVzaEBpZXRmLm9yZw0KU3ViamVjdDog UmU6IFtXZWJwdXNoXSBQcmVmZXI6IHdhaXQ9MCBmb3IgUmVjZWl2aW5nIFB1c2ggTWVzc2FnZSBS ZWNlaXB0cw0KDQpUaGFua3MgQnJpYW4sDQoNClllcywgYXMgYSBkZXNpZ24gb2YgcmVjZWl2aW5n IHB1c2ggbWVzc2FnZXMgYW5kIHB1c2ggbWVzc2FnZSByZWNlaXB0IGlzIHRoZSBzaW1pbGFyIGFu ZCB0aGV5IGFyZSBib3RoIHVzZSBzZXJ2ZXIgcHVzaGVzLCB3aWxsIG5vdCBiZSBhIHByb2JsZW0g dG8gcmV1c2UgYWxyZWFkeSBpbXBsZW1lbnRlZCBjb2RlIGJhc2UgdG8gYWxsb3cgdGhpcyBmZWF0 dXJlIGZvciBhbiBBUyB0b28uDQoNCkFkdmFudGFnZXM6DQrigKIgTW9yZSBmbGV4aWJsZSBsb2dp YyBmb3IgQVMgKGl0IGNvdWxkIGNob29zZSBob3cgaXQgd2lsbCByZXF1ZXN0IHJlY2VpcHRzKTsN CuKAoiBQb3NzaWJpbGl0eSB0byByZWR1Y2UgbnVtYmVyIG9mIGFsd2F5cyBvcGVuZWQgY29ubmVj dGlvbnMgdG8gdGhlIFBTLCBiZWNhdXNlIGlmIGEgVUEgbWF5IGJlIHVuYXZhaWxhYmxlIG1vc3Qg b2YgdGhlIHRpbWUgd2UgY2FuIG5vdCBzYXkgdGhlIHNhbWUgYWJvdXQgYW4gQVMuIEl0J3Mgb25s aW5lIG1vc3Qgb2YgdGhlIHRpbWUsIGJ1dCBjYW4gcmVxdWVzdCBwdXNoIG1lc3NhZ2UgZGVsaXZl cnkgcmFyZWx5Lg0KUHJldmlvdXNseSBLaXQgYWxzbyBjb25zaWRlcmVkIHRvIGFkZCB0aGlzIGZl YXR1cmU6DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS93ZWJwdXNoLXdnL3dlYnB1c2gtcHJvdG9jb2wv aXNzdWVzLzE4I2lzc3VlY29tbWVudC05NzQ3ODYyMQ0KDQoNCkJlc3QgcmVnYXJkcywNCklkZWwg UGl2bml0c2tpeQ0KLS0NClR3aXR0ZXI6IGh0dHBzOi8vdHdpdHRlci5jb20vaWRlbHBpdm5pdHNr aXkNCkdpdEh1YjrCoGh0dHBzOi8vZ2l0aHViLmNvbS9pZGVscGl2bml0c2tpeQ0KDQpPbiBGcmks IEp1biAxMCwgMjAxNiBhdCAxOjE5IEFNLCBCcmlhbiBSYXltb3IgPG1haWx0bzpCcmlhbi5SYXlt b3JAbWljcm9zb2Z0LmNvbT4gd3JvdGU6DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS93ZWJwdXNoLXdn L3dlYnB1c2gtcHJvdG9jb2wvaXNzdWVzLzExMw0KDQpJZGVsIGhhcyBzdWdnZXN0ZWQgdGhlIGFk ZGl0aW9uIG9mIHRoZSBQcmVmZXI6IHdhaXQ9MCBvcHRpb24gdG8gc2VjdGlvbiA2LjMuIFJlY2Vp dmluZyBQdXNoIE1lc3NhZ2UgUmVjZWlwdHMgdG8gYWxsb3cgYXBwbGljYXRpb24gc2VydmVycw0K dG8gaGF2ZSB0aGUgc2FtZSBvcHRpb24gZm9yIGltbWVkaWF0ZWx5IGNoZWNraW5nL3JlY2Vpdmlu ZyByZWNlaXB0cyBhcyB1c2VyIGFnZW50cyBoYXZlIGZvciBpbW1lZGlhdGVseSBjaGVja2luZy9y ZWNlaXZpbmcgbWVzc2FnZXMuDQoNCkknZCBhcHByZWNpYXRlIGJyb2FkZXIgcmV2aWV3IGFuZCBj b21tZW50cyBhYm91dCB3aGV0aGVyIHRoaXMgaXMgYSB1c2VmdWwgZmVhdHVyZS4NCg0KVGhlIGFk ZGl0aW9uIHRvIDYuMy4gUmVjZWl2aW5nIFB1c2ggTWVzc2FnZSBSZWNlaXB0cyB3b3VsZCBiZToN Cg0KDQpBbiBhcHBsaWNhdGlvbiBzZXJ2ZXIgY2FuIGFsc28gcmVxdWVzdCB0aGUgY29udGVudHMg b2YgdGhlIHJlY2VpcHQgc3Vic2NyaXB0aW9uIHJlc291cmNlIGltbWVkaWF0ZWx5IGJ5IGluY2x1 ZGluZyBhIFByZWZlciBoZWFkZXIgZmllbGQgW1JGQzcyNDBdDQp3aXRoIGEgIndhaXQiIHByZWZl cmVuY2Ugc2V0IHRvICIwIi4gSW4gcmVzcG9uc2UgdG8gdGhpcyByZXF1ZXN0LCB0aGUgcHVzaCBz ZXJ2aWNlIE1VU1QgZ2VuZXJhdGUgYSBzZXJ2ZXIgcHVzaCBmb3IgYWxsIHJlY2VpcHRzIHRoYXQg aGF2ZSBub3QgeWV0IGJlZW4gZGVsaXZlcmVkLg0KDQpBIDIwNCAoTm8gQ29udGVudCkgc3RhdHVz IGNvZGUgd2l0aCBubyBhc3NvY2lhdGVkIHNlcnZlciBwdXNoZXMgaW5kaWNhdGVzIHRoYXQgbm8g bmV3IHJlY2VpcHRzIGFyZSBwcmVzZW50bHkgYXZhaWxhYmxlLg0KDQoNCg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KV2VicHVzaCBtYWlsaW5nIGxp c3QNCm1haWx0bzpXZWJwdXNoQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3dlYnB1c2gNCg0K From nobody Mon Jun 13 10:04:57 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A0D12D89C for ; Mon, 13 Jun 2016 10:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ufvp25q7OJju for ; Mon, 13 Jun 2016 10:04:54 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0141.outbound.protection.outlook.com [207.46.100.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B06E12D8A1 for ; Mon, 13 Jun 2016 10:04:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lj++WSCu3IpV/ek3lOnLupcndr+mr5UEO3QcTFew/Zk=; b=Mt++jBfTPBGWmnpZkb/seg8/XYwvkRNVIu7HLSyK3ZGkQD3Q/EOChQWw4vjIfzhBFj9ti2wANZUIDhgyPb9J73op54ohkAmY1X2I5sa5couB5CAtw8BXo/oGRhu3D2pR47b/aOiEYPp+3jCm9M+1zut/CL720LGiR55yiw1y7cY= Received: from CO2PR03MB2407.namprd03.prod.outlook.com (10.166.93.137) by CO2PR03MB2408.namprd03.prod.outlook.com (10.166.93.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.517.8; Mon, 13 Jun 2016 17:04:53 +0000 Received: from CO2PR03MB2407.namprd03.prod.outlook.com ([10.166.93.137]) by CO2PR03MB2407.namprd03.prod.outlook.com ([10.166.93.137]) with mapi id 15.01.0517.009; Mon, 13 Jun 2016 17:04:53 +0000 From: Brian Raymor To: Brian Raymor , "webpush@ietf.org" Thread-Topic: Make it a bit more obvious which is the send resource Thread-Index: AdHDXNhAonl6T8X8QNqz9D+vlR3iegCN/N2A Date: Mon, 13 Jun 2016 17:04:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brian.Raymor@microsoft.com; x-originating-ip: [2001:4898:80e8:b::177] x-ms-office365-filtering-correlation-id: 8d821883-1699-4071-f247-08d393acd686 x-microsoft-exchange-diagnostics: 1; CO2PR03MB2408; 6:gJHM4Rvhtp5yc9DJKEIyPfCXM8DZvqMUJgfuCOBMmH2wDxWwBY5B8h5CR00WRhaqsiu7uy4B4B3AZAZnHv6p2EFiz4msgHFy3MX6Vf0OYy0Af+xvP7asf2xXWzwBbXP/fLDFuhIP0Puc+Sj7e3mntYmVdQ3cnOqsfN3M0vhjPCf6q41d//IaTo8/ceCpiEC7927ZsbdQIemhV9dkz1+AWhflwfCxgLgNSCBPQzTo32PjRni2+Pi0uxFcu6B5AxsWB33k6Osp3zJv4Z1rs3zCNekimGNlTC6DUlB6HZXFpV+K+S4uCTJqiKxhnenZOkatmkFULAF7P9vpJtaWM4Ne5g==; 5:8U8Av3KIjK96dt0bNANF4FV2YkPMsAW/D2a5BIPdPpxbv5Neig+W82F+7Zl0ePp9AG0ND1c5SwVvL5DQS5GEhev9eXCK/Y6qc8vCBtpPbXzBYN1wzMC5yb+n0y/ODpYv+NSq9G/X9ficXbA0Orb3EQ==; 24:ZQr+rjbqt4twaWHtHkGC8so1SsK1v3Vmn0KOb/1IvISEiApySV7QVAd/Kb0VOUjeh3k1qZfPqgkkHfIM9TkvjVD05EKlW/5672MHhpe1HIM=; 7:RehTf9fjP1YhvvQXm0mUwlfZd0mOHYVaplBJTeaTHUnIMZcMW62ndIkZ0ThjWcTYjGqeJJEZaj7QN3CM3rwGFqVsZf2RfgzGyWuTq2/VCH1p0W4KKpJTHuOAvl8gGyY6iiivcsP31n4ugvr3DJyNZizP47r6Z4NG9Yu7UWjgVW2ANVrhDYtRA/n9q5Vid4AU/PNf24waAXRo00OEu7Q9N1TorT+fw7juygkiZYa6ahrEJKWNhsSBv9BaHzEY7fpE x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR03MB2408; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CO2PR03MB2408; BCL:0; PCL:0; RULEID:; SRVR:CO2PR03MB2408; x-forefront-prvs: 0972DEC1D9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(199003)(189002)(13464003)(189998001)(86612001)(5008740100001)(86362001)(50986999)(450100001)(76576001)(2906002)(92566002)(99286002)(68736007)(74316001)(8990500004)(33656002)(5003600100002)(102836003)(54356999)(6116002)(97736004)(5001770100001)(107886002)(87936001)(2561002)(2421001)(101416001)(1511001)(11100500001)(2501003)(122556002)(586003)(81166006)(81156014)(5004730100002)(15975445007)(9686002)(8676002)(5002640100001)(8936002)(10290500002)(2900100001)(106356001)(5005710100001)(10400500002)(10090500001)(77096005)(76176999)(105586002)(3660700001)(3280700002)(2950100001)(19580405001)(19580395003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR03MB2408; H:CO2PR03MB2407.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2016 17:04:53.0791 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR03MB2408 Archived-At: Subject: Re: [Webpush] Make it a bit more obvious which is the send resource X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 17:04:56 -0000 I'm not hearing a strong desire to rename "push resource" to "push delivery= resource" as a clarification during WGLC. Closed https://github.com/webpush-wg/webpush-protocol/pull/105. -----Original Message----- From: Webpush [mailto:webpush-bounces@ietf.org] On Behalf Of Brian Raymor Sent: Friday, June 10, 2016 2:28 PM To: webpush@ietf.org Subject: [Webpush] Make it a bit more obvious which is the send resource https://github.com/webpush-wg/webpush-protocol/pull/105 Costin noted - "push resource" is confusing me every time - "push" is used = in all other resources. The original text: The push service MUST provide a URI for the push resource corresponding to the push message subscription in a link relation of type "urn:ietf:params:push". Bikeshed follows. Would adding "delivery" clarify the use? This would match how we currently = describe the process when the application server sends a message. It requests "delivery": The push service MUST provide a URI for the push *delivery* resource corresponding to the push message subscription in a link relation of type "urn:ietf:params:push:delivery". 5. Requesting Push Message Delivery An application server requests the delivery of a push message by sending a HTTP POST request to a push *delivery* resource _______________________________________________ Webpush mailing list Webpush@ietf.org https://www.ietf.org/mailman/listinfo/webpush From nobody Mon Jun 13 10:46:39 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C10B12D8D8 for ; Mon, 13 Jun 2016 10:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfPM9-LaBcnV for ; Mon, 13 Jun 2016 10:46:31 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0127.outbound.protection.outlook.com [65.55.169.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9A9712D8D6 for ; Mon, 13 Jun 2016 10:46:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TaBb+xMW7qK/801kfDAghFYBsxLvQxkap7lc/mius/8=; b=Fw7c/3Zog++ANUDEiaTbhlKmXe5eCICoizleVNtpw5Bn287klkj01dDzjG7Qq68Xf6GhlP5kTSoFxBKFJLtzJkgN+dTRAdzwp7rtJ8ICFb7VXloEdHIwflNjiq6osFAVKJ6fnwaXKmv6F+SPe3KgV9q6IEtGrF3d7yL0SJXe5zA= Received: from CO2PR03MB2407.namprd03.prod.outlook.com (10.166.93.137) by CO2PR03MB2405.namprd03.prod.outlook.com (10.166.93.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.517.8; Mon, 13 Jun 2016 17:46:29 +0000 Received: from CO2PR03MB2407.namprd03.prod.outlook.com ([10.166.93.137]) by CO2PR03MB2407.namprd03.prod.outlook.com ([10.166.93.137]) with mapi id 15.01.0517.009; Mon, 13 Jun 2016 17:46:29 +0000 From: Brian Raymor To: Costin Manolache , RUELLAN Herve , "martin.thomson@gmail.com" Thread-Topic: [Webpush] Non-blocking comments on -05 Thread-Index: AQHRu3RQwDJq8LaJ6EaFkMQ0Dd4KCZ/Uf30AgADyW4CAAFBvAIAAI8eAgAoob+CAAX0uAIAAKpuAgADVSQCAAHV7gIAEtKMg Date: Mon, 13 Jun 2016 17:46:29 +0000 Message-ID: References: <6af49c2baf1b4e4f884b812d573b947e@Antiope.crf.canon.fr> <989D9268-BE9A-47F7-9181-C0F323D1DA1F@mozilla.com> <1464858574.5342.12.camel@crf.canon.fr> <2953D35A-1FC9-4765-BBE0-83DBCA8CAC10@mozilla.com> <1465553821.3039.13.camel@crf.canon.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brian.Raymor@microsoft.com; x-originating-ip: [2001:4898:80e8:b::177] x-ms-office365-filtering-correlation-id: 7d3b66ae-ab6c-475d-ba5d-08d393b2a64c x-microsoft-exchange-diagnostics: 1; CO2PR03MB2405; 6:gA1w+Hj0+iC3KpctXW1lK+IpQvQktI+k85VHY2YeNR6Lun0Cy+B1WIBQnfRUY8A3/Do+YP5P2QuLq7Qo9CtF6gLjwMTx9wgWnqvlHgXJDVGgPMC25aNgxFuGJt3LB+nmkhirYlBqwa+XV50T+xOy4K705z4UehLR+s2GtniLC2onct6YmTzpMFkCDDdpdcjq4eSZU+SuhNirBZSr8QxrNBrhSgxAmtiuiTxa8Kz763VS6mkntr8w+jZI+Z/waZ0Kcm44nXFS8ct8PsZuwd7WAr3qOSZ4MKx77r/Voi5bnjRj0gVYR8iKyWi4RoFe3Me1TZz3Kc4Re97r6qbM5b5/XQ==; 5:VbNGHw1pY0Xj4KyRtYwngYXjIeRbUahS5OueqrGJDYOtDsmCDCYME+EbrtpLPaz5wyIrPr1kRV5Pw8u3DbqWlm7E+gLjy8QPqMF6nrp0nVMbL+ekfHTPVE9TAxo2oxD879cQN/xLKMPpYdL+DYZ72A==; 24:fPJcrltIOcPzENF8CuDZ3kbv7Y5ituPKm+ox9WRFK7RzbAr5gp0quRqj7a4ebbyLa+msCOvY316sZpgC2cC11kLWaZQ5quxvBc8ytSb4pN8=; 7:AwnZ+DanfnhN1e6At9W16XgP1ekM66KmVh4A+sYtrslxMANc23ZnpPwz/e3qXlIfFsLokiFmwa0ayUJs3m9hNPBQu7fLzz06F5cJvNjgVT98FX93xNe/GBjQNrEuV/w6qy7s4uLEPaiIvKHylgyL533FSL0iZCURoeZDuDE5onm/aooWgRjkMWa612Oce58ZMRw+NA6k+gBL1QRpctqecPFWHkG9eJMM4BWJs2xhWMdrybNenfGAw4Me5KkRp9Ae x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR03MB2405; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(72170088055959)(211936372134217)(196631223173759)(21748063052155)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CO2PR03MB2405; BCL:0; PCL:0; RULEID:; SRVR:CO2PR03MB2405; x-forefront-prvs: 0972DEC1D9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(377424004)(199003)(189002)(51444003)(24454002)(377454003)(5008740100001)(33656002)(93886004)(19609705001)(586003)(97736004)(106116001)(86362001)(92566002)(9686002)(8990500004)(5003600100002)(74316001)(10290500002)(5001770100001)(790700001)(6116002)(102836003)(122556002)(8936002)(68736007)(16236675004)(7906002)(19617315012)(50986999)(54356999)(2501003)(19580405001)(19580395003)(16601075003)(105586002)(81166006)(81156014)(3660700001)(2900100001)(19300405004)(3280700002)(99286002)(5004730100002)(106356001)(8676002)(2950100001)(11100500001)(19625215002)(76576001)(15975445007)(77096005)(101416001)(5005710100001)(5002640100001)(10400500002)(87936001)(4326007)(76176999)(2906002)(86612001)(10090500001)(189998001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR03MB2405; H:CO2PR03MB2407.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CO2PR03MB2407E6A11B6375991195229083530CO2PR03MB2407namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2016 17:46:29.1317 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR03MB2405 Archived-At: Cc: "kcambridge@mozilla.com" , "webpush@ietf.org" , "beverloo@google.com" Subject: Re: [Webpush] Non-blocking comments on -05 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 17:46:34 -0000 --_000_CO2PR03MB2407E6A11B6375991195229083530CO2PR03MB2407namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TXkgb3BpbmlvbiBpcyB0aGF0IHdlIGRvIG5vdCBuZWVkIHRvIGJsb2NrIG9uIHBvdGVudGlhbC9l eHBlcmltZW50YWwgKOKAnG1pZ2h0IGluY2x1ZGXigJ0pIHVzZSBjYXNlcy4NCg0KSWYgdGhlcmUg YXJlIG5vIHN0cm9uZyBvYmplY3Rpb25zIGFuZC9vciBmdXJ0aGVyIGVkaXRzIGZvciBIZXJ2ZSwg SeKAmWxsIG1lcmdlL2VkaXQgdGhpcyBQUiBsYXRlciB0b2RheS4NCg0KDQpGcm9tOiBDb3N0aW4g TWFub2xhY2hlIFttYWlsdG86Y29zdGluQGdtYWlsLmNvbV0NClNlbnQ6IEZyaWRheSwgSnVuZSAx MCwgMjAxNiAxMDoxOCBBTQ0KVG86IFJVRUxMQU4gSGVydmUgPEhlcnZlLlJ1ZWxsYW5AY3JmLmNh bm9uLmZyPjsgbWFydGluLnRob21zb25AZ21haWwuY29tDQpDYzogQnJpYW4gUmF5bW9yIDxCcmlh bi5SYXltb3JAbWljcm9zb2Z0LmNvbT47IGJldmVybG9vQGdvb2dsZS5jb207IGtjYW1icmlkZ2VA bW96aWxsYS5jb207IHdlYnB1c2hAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbV2VicHVzaF0gTm9u LWJsb2NraW5nIGNvbW1lbnRzIG9uIC0wNQ0KDQpNb3N0IHVzZSBjYXNlcyBtZW50aW9uZWQgLSB3 aXRoIHRoZSBleGNlcHRpb24gb2YgJ21vdmluZyBzdWJzY3JpcHRpb24nIC0gY2FuIGJlIGltcGxl bWVudGVkDQplZmZpY2llbnRseSBieSBzdG9yaW5nIHRoZSBtZXNzYWdlcyBrZXllZCBieSBzb21l ICdwcmltYXJ5JyBJRC4gRm9yIGxhcmdlIG51bWJlcnMsIGl0DQppcyBkZXNpcmFibGUgdG8gb3B0 aW1pemUgdGhlIG51bWJlciBvZiBEQiBxdWVyaWVzIGRvbmUgYXQgY29ubmVjdCAtIGkuZS4gZG8g YSBzaW5nbGUgcmVhZCB0aGF0DQpoaXRzIGEgc2luZ2xlIHNoYXJkLiAgTW9zdCBvZiB0aGUgdGlt ZSB0aGUgcmVhZCB3aWxsIHJldHVybiBlbXB0eSwgYnV0IHRoZSBsb2NhbGl0eSBvZiB0aGUNCm1l c3NhZ2VzIGZvciBhIHNpbmdsZSBkZXZpY2UgaXMgcHJldHR5IGltcG9ydGFudC4NCg0KTW92aW5n IHN1YnNjcmlwdGlvbnMgcHJldHR5IG11Y2ggcmVxdWlyZXMgYSBkaWZmZXJlbnQgZGVzaWduIC0g YW5kIEkgZG9uJ3QgaGF2ZSBhbnkgZXhwZXJpZW5jZQ0Kd2l0aCBob3cgaXQgY2FuIHNjYWxlLg0K DQpDb3N0aW4NCg0KDQoNCk9uIEZyaSwgSnVuIDEwLCAyMDE2IGF0IDM6MTcgQU0gUlVFTExBTiBI ZXJ2ZSA8SGVydmUuUnVlbGxhbkBjcmYuY2Fub24uZnI8bWFpbHRvOkhlcnZlLlJ1ZWxsYW5AY3Jm LmNhbm9uLmZyPj4gd3JvdGU6DQpPbiBGcmksIDIwMTYtMDYtMTAgYXQgMDc6MzMgKzEwMDAsIE1h cnRpbiBUaG9tc29uIHdyb3RlOg0KPiBPbiAxMCBKdW5lIDIwMTYgYXQgMDU6MDEsIEtpdCBDYW1i cmlkZ2UgPGtjYW1icmlkZ2VAbW96aWxsYS5jb208bWFpbHRvOmtjYW1icmlkZ2VAbW96aWxsYS5j b20+PiB3cm90ZToNCj4gPiBEb2VzIG1vdmluZyBhIHN1YnNjcmlwdGlvbiBzZXQgbWVhbiBhbm90 aGVyIFVBIHdvdWxkIGJlIGFibGUgdG8gcmVjZWl2ZSBtZXNzYWdlcyBzZW50IHRvIHN1YnNjcmlw dGlvbnMgaW4gdGhhdCBzZXQ/IChUaGF0IGlzLCB3aXRob3V0IHJlcXVpcmluZyB0aGUgb2xkIFVB IHRvIGRyb3AgYWxsIGl0cyBzdWJzY3JpcHRpb25zIGFuZCB0aGUgbmV3IFVBIHRvIHJlcmVnaXN0 ZXIpLg0KPg0KPiBJIHRoaW5rIHRoYXQgeW91IGhhdmUgaXQuIElmIHlvdSBoYXZlIDIgc3Vic2Ny aXB0aW9ucyB0aGF0IGFyZSBpbiB0aGUNCj4gc2FtZSBzZXQsIHRoZXkgaGF2ZSB0byBiZSBtb25p dG9yZWQgdG9nZXRoZXIuICBJZiB0aGV5IGFyZSBpbiBzZXBhcmF0ZQ0KPiBzZXRzLCB0aGVuIHRo ZXkgY2FuIGJlIG1vbml0b3JlZCBzZXBhcmF0ZWx5LiAgVGhlIHNlcGFyYXRpb24gZW5hYmxlcw0K PiBpbnRlcm1lZGlhdGlvbi4NCj4NCj4gSSBkb24ndCB0aGluayB0aGF0IHRoaXMgaXMgYSB1c2Ug Y2FzZSB0aGF0IGlzIHBhcnRpY3VsYXJseSBpbXBvcnRhbnQNCj4gZm9yIHRoZSB3ZWIgY2FzZTsg SSBjb25mZXNzIHRoYXQgaXQgaXNuJ3QgdGhhdCBpbnRlcmVzdGluZyB0byBtZS4NCj4gSG93ZXZl ciwgSSB0aGluayB0aGF0IGl0IGlzIGFuIGVudGlyZWx5IHZhbGlkIHVzZSBjYXNlLCBhbmQgaXQg Y29zdHMNCj4gbGl0dGxlLiAgSXQgZG9lcyBob3dldmVyIGVuYWJsZSB0aGluZ3Mgb24gdGhlIHdl YiBzaWRlIHRoYXQgKmFyZSogdmVyeQ0KPiBpbnRlcmVzdGluZyB0byBtZS4NCj4NCj4gU2F5IHlv dSBoYXZlIGEgVUEgdGhhdCB3YW50cyB0byBnbyBpbnRvIGEgZGVlcCBzbGVlcCB0byBzYXZlIHBv d2VyLg0KPiBJbiB0aGF0IG1vZGUsIGl0IHN0aWxsIHdhbnRzIHRvIHJlY2VpdmUgcHVzaCBtZXNz YWdlcyBmcm9tIHNldmVyYWwNCj4gaGlnaCBwcmlvcml0eSBzaXRlcy4gIEJ1dCBpdCBkb2Vzbid0 IHdhbnQgdG8gZ2V0IHRoZSBkZWFsLW9mLXRoZS1kYXkNCj4gYW5kIGFsbCB0aGF0IGp1bmsgZnJv bSBvdGhlciBzaXRlcy4NCj4NCj4gTm93LCB0aGUgVUEga25vd3MgdGhhdCB0aGUgcHVzaCBzZXJ2 aWNlIGlzIHVuYWJsZSB0byBkaXNjcmltaW5hdGUNCj4gYmV0d2VlbiBpbXBvcnRhbnQgYW5kIHVu aW1wb3J0YW50IHByb3Blcmx5IGFuZCBpdCBkb2Vzbid0IHdhbnQgdG8gcmlzaw0KPiBnZXR0aW5n IHRoaW5ncyBsaWtlIHRleHQgbWVzc2FnZSBub3RpZmljYXRpb25zIGZyb20gdW5pbXBvcnRhbnQg c2l0ZXMuDQo+IEV2ZW4gaWYgdGhlc2UgYXJlIG5vcm1hbGx5IHNlbnQgd2l0aCBtb2RlcmF0ZWx5 IGhpZ2ggdXJnZW5jeSwNCj4gbGVnaXRpbWF0ZWx5Lg0KPg0KPiBJZiBpdCBjYW4gc3BsaXQgdGhl IGltcG9ydGFudCBzaXRlcyBhbmQgdGhlIHVuaW1wb3J0YW50IHNpdGVzIGludG8gdHdvDQo+IHN1 YnNjcmlwdGlvbiBzZXRzLCB0aGVuIGl0IGNhbiBtb25pdG9yIHRoZSBpbXBvcnRhbnQgc2l0ZXMg b25seS4NCj4gVGhhdCdzIG5vdCBwb3NzaWJsZSBpZiB5b3UgZG9uJ3QgYWxsb3cgdGhlIFVBIHRv IGNvbnRyb2wgd2hpY2gNCj4gc3Vic2NyaXB0aW9ucyBnZXQgZ3JvdXBlZCB0b2dldGhlci4NCj4N Cj4gSWYgeW91IHdhbnQgYSBjb25jcmV0ZSBleGFtcGxlLCB0aGluayBwYWdlcmR1dHkuY29tPGh0 dHA6Ly9wYWdlcmR1dHkuY29tPiB2cy4gc2t5cGUuY29tPGh0dHA6Ly9za3lwZS5jb20+LiAgQQ0K PiBjYWxsIG1pZ2h0IGJlIGVudGlyZWx5IHVuZGVzaXJhYmxlIGF0IDNhbSwgYnV0IGlmIGEgcHJv ZHVjdGlvbiBzaXRlIGlzDQo+IG9uIGZpcmUsIGl0J3Mgd2FrZSB1cCB0aW1lLg0KDQpBcyB0aGVy ZSBzZWVtcyB0byBiZSBzZXZlcmFsIHVzZSBjYXNlcyBoZXJlICh5b3VyIHVzZSBjYXNlIGZvciB0 aGUgd2ViLA0KQ29zdGluJ3MgbXVsdGktdXNlciBjYXNlIGluIGFuZHJvaWQsIGFuZCBteSBVQSBw cm94eWluZyB1c2UgY2FzZSksIEkNCnRoaW5rIG1vcmUgb2YgdGhlbSBjb3VsZCBiZSBsaXN0ZWQg aW4gdGhlIHNwZWMuDQoNCkhvdyBhYm91dDoNCg0KRWFjaCBzdWJzY3JpcHRpb24gc2V0IGNhbiB0 aGVuIGJlIG1hbmFnZWQgaW5kZXBlbmRlbnRseSwgd2hpY2ggbWlnaHQNCmluY2x1ZGUgbW9uaXRv cmluZyBvbmx5IGEgc2V0IG9mIHZlcnkgaW1wb3J0YW50IHN1YnNjcmlwdGlvbnMsIGhhbmRsaW5n DQpzdWJzY3JpcHRpb24gZm9yIGRpZmZlcmVudCB1c2VycyBzZXBhcmF0ZWx5LCBvciBtb3Zpbmcg YSBzdWJzY3JpcHRpb24NCnNldCBiZXR3ZWVuIHVzZXIgYWdlbnRzLg0KDQoNCkZvciBtb3Zpbmcg c3Vic2NyaXB0aW9uIHNldHMgYmV0d2VlbiBVQSwgSSBhZ3JlZSB0aGF0IGl0J3MgdG9vIGVhcmx5 IHRvDQpzb2x2ZSBpdCBpbiB0aGlzIFdlYnB1c2ggZHJhZnQuIE15IGNvbmNlcm4gaGVyZSBpcyB0 byBsZWF2ZSBvcGVuIHRoZQ0KcG9zc2liaWxpdHkgb2YgYnVpbGRpbmcgaXQgaW4gdGhlIGZ1dHVy ZS4NCg0KSGVydsOpDQo= --_000_CO2PR03MB2407E6A11B6375991195229083530CO2PR03MB2407namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk15IG9waW5pb24gaXMgdGhhdCB3ZSBkbyBub3QgbmVlZCB0 byBibG9jayBvbiBwb3RlbnRpYWwvZXhwZXJpbWVudGFsICjigJxtaWdodCBpbmNsdWRl4oCdKSB1 c2UgY2FzZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPklmIHRoZXJlIGFyZSBubyBzdHJvbmcgb2JqZWN0aW9u cyBhbmQvb3IgZnVydGhlciBlZGl0cyBmb3IgSGVydmUsIEnigJlsbCBtZXJnZS9lZGl0IHRoaXMg UFIgbGF0ZXIgdG9kYXkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBDb3N0aW4gTWFu b2xhY2hlIFttYWlsdG86Y29zdGluQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlk YXksIEp1bmUgMTAsIDIwMTYgMTA6MTggQU08YnI+DQo8Yj5Ubzo8L2I+IFJVRUxMQU4gSGVydmUg Jmx0O0hlcnZlLlJ1ZWxsYW5AY3JmLmNhbm9uLmZyJmd0OzsgbWFydGluLnRob21zb25AZ21haWwu Y29tPGJyPg0KPGI+Q2M6PC9iPiBCcmlhbiBSYXltb3IgJmx0O0JyaWFuLlJheW1vckBtaWNyb3Nv ZnQuY29tJmd0OzsgYmV2ZXJsb29AZ29vZ2xlLmNvbTsga2NhbWJyaWRnZUBtb3ppbGxhLmNvbTsg d2VicHVzaEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1dlYnB1c2hdIE5vbi1i bG9ja2luZyBjb21tZW50cyBvbiAtMDU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Nb3N0IHVzZSBjYXNlcyBtZW50aW9uZWQgLSB3aXRoIHRoZSBleGNlcHRpb24gb2YgJ21v dmluZyBzdWJzY3JpcHRpb24nIC0gY2FuIGJlIGltcGxlbWVudGVkPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZWZmaWNpZW50bHkgYnkgc3RvcmluZyB0aGUgbWVz c2FnZXMga2V5ZWQgYnkgc29tZSAncHJpbWFyeScgSUQuIEZvciBsYXJnZSBudW1iZXJzLCBpdCZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ aXMgZGVzaXJhYmxlIHRvIG9wdGltaXplIHRoZSBudW1iZXIgb2YgREIgcXVlcmllcyBkb25lIGF0 IGNvbm5lY3QgLSBpLmUuJm5ic3A7ZG8gYSBzaW5nbGUgcmVhZCB0aGF0Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5oaXRzIGEgc2luZ2xl IHNoYXJkLiZuYnNwOyBNb3N0IG9mIHRoZSB0aW1lIHRoZSByZWFkIHdpbGwgcmV0dXJuIGVtcHR5 LCBidXQgdGhlIGxvY2FsaXR5IG9mIHRoZSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bWVzc2FnZXMgZm9yIGEgc2luZ2xlIGRldmljZSBp cyBwcmV0dHkgaW1wb3J0YW50LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Nb3Zpbmcgc3Vic2NyaXB0aW9ucyBwcmV0dHkgbXVjaCBy ZXF1aXJlcyBhIGRpZmZlcmVudCBkZXNpZ24gLSBhbmQgSSBkb24ndCBoYXZlIGFueSBleHBlcmll bmNlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj53 aXRoIGhvdyBpdCBjYW4gc2NhbGUuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNvc3RpbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBKdW4gMTAsIDIwMTYgYXQg MzoxNyBBTSBSVUVMTEFOIEhlcnZlICZsdDs8YSBocmVmPSJtYWlsdG86SGVydmUuUnVlbGxhbkBj cmYuY2Fub24uZnIiPkhlcnZlLlJ1ZWxsYW5AY3JmLmNhbm9uLmZyPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBGcmksIDIwMTYtMDYtMTAgYXQgMDc6MzMgJiM0MzsxMDAwLCBNYXJ0aW4gVGhvbXNvbiB3cm90 ZTo8YnI+DQomZ3Q7IE9uIDEwIEp1bmUgMjAxNiBhdCAwNTowMSwgS2l0IENhbWJyaWRnZSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmtjYW1icmlkZ2VAbW96aWxsYS5jb20iIHRhcmdldD0iX2JsYW5rIj5r Y2FtYnJpZGdlQG1vemlsbGEuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7IERvZXMg bW92aW5nIGEgc3Vic2NyaXB0aW9uIHNldCBtZWFuIGFub3RoZXIgVUEgd291bGQgYmUgYWJsZSB0 byByZWNlaXZlIG1lc3NhZ2VzIHNlbnQgdG8gc3Vic2NyaXB0aW9ucyBpbiB0aGF0IHNldD8gKFRo YXQgaXMsIHdpdGhvdXQgcmVxdWlyaW5nIHRoZSBvbGQgVUEgdG8gZHJvcCBhbGwgaXRzIHN1YnNj cmlwdGlvbnMgYW5kIHRoZSBuZXcgVUEgdG8gcmVyZWdpc3RlcikuPGJyPg0KJmd0Ozxicj4NCiZn dDsgSSB0aGluayB0aGF0IHlvdSBoYXZlIGl0LiBJZiB5b3UgaGF2ZSAyIHN1YnNjcmlwdGlvbnMg dGhhdCBhcmUgaW4gdGhlPGJyPg0KJmd0OyBzYW1lIHNldCwgdGhleSBoYXZlIHRvIGJlIG1vbml0 b3JlZCB0b2dldGhlci4mbmJzcDsgSWYgdGhleSBhcmUgaW4gc2VwYXJhdGU8YnI+DQomZ3Q7IHNl dHMsIHRoZW4gdGhleSBjYW4gYmUgbW9uaXRvcmVkIHNlcGFyYXRlbHkuJm5ic3A7IFRoZSBzZXBh cmF0aW9uIGVuYWJsZXM8YnI+DQomZ3Q7IGludGVybWVkaWF0aW9uLjxicj4NCiZndDs8YnI+DQom Z3Q7IEkgZG9uJ3QgdGhpbmsgdGhhdCB0aGlzIGlzIGEgdXNlIGNhc2UgdGhhdCBpcyBwYXJ0aWN1 bGFybHkgaW1wb3J0YW50PGJyPg0KJmd0OyBmb3IgdGhlIHdlYiBjYXNlOyBJIGNvbmZlc3MgdGhh dCBpdCBpc24ndCB0aGF0IGludGVyZXN0aW5nIHRvIG1lLjxicj4NCiZndDsgSG93ZXZlciwgSSB0 aGluayB0aGF0IGl0IGlzIGFuIGVudGlyZWx5IHZhbGlkIHVzZSBjYXNlLCBhbmQgaXQgY29zdHM8 YnI+DQomZ3Q7IGxpdHRsZS4mbmJzcDsgSXQgZG9lcyBob3dldmVyIGVuYWJsZSB0aGluZ3Mgb24g dGhlIHdlYiBzaWRlIHRoYXQgKmFyZSogdmVyeTxicj4NCiZndDsgaW50ZXJlc3RpbmcgdG8gbWUu PGJyPg0KJmd0Ozxicj4NCiZndDsgU2F5IHlvdSBoYXZlIGEgVUEgdGhhdCB3YW50cyB0byBnbyBp bnRvIGEgZGVlcCBzbGVlcCB0byBzYXZlIHBvd2VyLjxicj4NCiZndDsgSW4gdGhhdCBtb2RlLCBp dCBzdGlsbCB3YW50cyB0byByZWNlaXZlIHB1c2ggbWVzc2FnZXMgZnJvbSBzZXZlcmFsPGJyPg0K Jmd0OyBoaWdoIHByaW9yaXR5IHNpdGVzLiZuYnNwOyBCdXQgaXQgZG9lc24ndCB3YW50IHRvIGdl dCB0aGUgZGVhbC1vZi10aGUtZGF5PGJyPg0KJmd0OyBhbmQgYWxsIHRoYXQganVuayBmcm9tIG90 aGVyIHNpdGVzLjxicj4NCiZndDs8YnI+DQomZ3Q7IE5vdywgdGhlIFVBIGtub3dzIHRoYXQgdGhl IHB1c2ggc2VydmljZSBpcyB1bmFibGUgdG8gZGlzY3JpbWluYXRlPGJyPg0KJmd0OyBiZXR3ZWVu IGltcG9ydGFudCBhbmQgdW5pbXBvcnRhbnQgcHJvcGVybHkgYW5kIGl0IGRvZXNuJ3Qgd2FudCB0 byByaXNrPGJyPg0KJmd0OyBnZXR0aW5nIHRoaW5ncyBsaWtlIHRleHQgbWVzc2FnZSBub3RpZmlj YXRpb25zIGZyb20gdW5pbXBvcnRhbnQgc2l0ZXMuPGJyPg0KJmd0OyBFdmVuIGlmIHRoZXNlIGFy ZSBub3JtYWxseSBzZW50IHdpdGggbW9kZXJhdGVseSBoaWdoIHVyZ2VuY3ksPGJyPg0KJmd0OyBs ZWdpdGltYXRlbHkuPGJyPg0KJmd0Ozxicj4NCiZndDsgSWYgaXQgY2FuIHNwbGl0IHRoZSBpbXBv cnRhbnQgc2l0ZXMgYW5kIHRoZSB1bmltcG9ydGFudCBzaXRlcyBpbnRvIHR3bzxicj4NCiZndDsg c3Vic2NyaXB0aW9uIHNldHMsIHRoZW4gaXQgY2FuIG1vbml0b3IgdGhlIGltcG9ydGFudCBzaXRl cyBvbmx5Ljxicj4NCiZndDsgVGhhdCdzIG5vdCBwb3NzaWJsZSBpZiB5b3UgZG9uJ3QgYWxsb3cg dGhlIFVBIHRvIGNvbnRyb2wgd2hpY2g8YnI+DQomZ3Q7IHN1YnNjcmlwdGlvbnMgZ2V0IGdyb3Vw ZWQgdG9nZXRoZXIuPGJyPg0KJmd0Ozxicj4NCiZndDsgSWYgeW91IHdhbnQgYSBjb25jcmV0ZSBl eGFtcGxlLCB0aGluayA8YSBocmVmPSJodHRwOi8vcGFnZXJkdXR5LmNvbSIgdGFyZ2V0PSJfYmxh bmsiPg0KcGFnZXJkdXR5LmNvbTwvYT4gdnMuIDxhIGhyZWY9Imh0dHA6Ly9za3lwZS5jb20iIHRh cmdldD0iX2JsYW5rIj5za3lwZS5jb208L2E+LiZuYnNwOyBBPGJyPg0KJmd0OyBjYWxsIG1pZ2h0 IGJlIGVudGlyZWx5IHVuZGVzaXJhYmxlIGF0IDNhbSwgYnV0IGlmIGEgcHJvZHVjdGlvbiBzaXRl IGlzPGJyPg0KJmd0OyBvbiBmaXJlLCBpdCdzIHdha2UgdXAgdGltZS48YnI+DQo8YnI+DQpBcyB0 aGVyZSBzZWVtcyB0byBiZSBzZXZlcmFsIHVzZSBjYXNlcyBoZXJlICh5b3VyIHVzZSBjYXNlIGZv ciB0aGUgd2ViLDxicj4NCkNvc3RpbidzIG11bHRpLXVzZXIgY2FzZSBpbiBhbmRyb2lkLCBhbmQg bXkgVUEgcHJveHlpbmcgdXNlIGNhc2UpLCBJPGJyPg0KdGhpbmsgbW9yZSBvZiB0aGVtIGNvdWxk IGJlIGxpc3RlZCBpbiB0aGUgc3BlYy48YnI+DQo8YnI+DQpIb3cgYWJvdXQ6PGJyPg0KPGJyPg0K RWFjaCBzdWJzY3JpcHRpb24gc2V0IGNhbiB0aGVuIGJlIG1hbmFnZWQgaW5kZXBlbmRlbnRseSwg d2hpY2ggbWlnaHQ8YnI+DQppbmNsdWRlIG1vbml0b3Jpbmcgb25seSBhIHNldCBvZiB2ZXJ5IGlt cG9ydGFudCBzdWJzY3JpcHRpb25zLCBoYW5kbGluZzxicj4NCnN1YnNjcmlwdGlvbiBmb3IgZGlm ZmVyZW50IHVzZXJzIHNlcGFyYXRlbHksIG9yIG1vdmluZyBhIHN1YnNjcmlwdGlvbjxicj4NCnNl dCBiZXR3ZWVuIHVzZXIgYWdlbnRzLjxicj4NCjxicj4NCjxicj4NCkZvciBtb3Zpbmcgc3Vic2Ny aXB0aW9uIHNldHMgYmV0d2VlbiBVQSwgSSBhZ3JlZSB0aGF0IGl0J3MgdG9vIGVhcmx5IHRvPGJy Pg0Kc29sdmUgaXQgaW4gdGhpcyBXZWJwdXNoIGRyYWZ0LiBNeSBjb25jZXJuIGhlcmUgaXMgdG8g bGVhdmUgb3BlbiB0aGU8YnI+DQpwb3NzaWJpbGl0eSBvZiBidWlsZGluZyBpdCBpbiB0aGUgZnV0 dXJlLjxicj4NCjxicj4NCkhlcnbDqTxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CO2PR03MB2407E6A11B6375991195229083530CO2PR03MB2407namp_-- From nobody Tue Jun 14 06:26:28 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E932D12D662 for ; Tue, 14 Jun 2016 06:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vroNocMn6cpo for ; Tue, 14 Jun 2016 06:26:25 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::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 1536712D647 for ; Tue, 14 Jun 2016 06:26:25 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id e5so66524942ith.0 for ; Tue, 14 Jun 2016 06:26:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=NXa/YYZFgkyEM6Ml2YSN1eFBuqtpb7dTMG2HdFL72wo=; b=lfvpZjUFxe7u18PkSOx3DeIIZUeIiQZk6BGcXNnTC7ULUqtw1IjJocrpp5fCPgAfGQ a4b8bVmOFNtKAbLtfir+8DWivuERYSNkWID37zGgsxmIoGqADVb4tApQkm0USm9NUfEt akaaMEFfMjMHKMyCP3cGic7/jLntH8jULfrvOYzLEQPVq029lOxEVdXWwwCvEgLouV/O tmpFKQdus6GgePU0eLi2sEUgG2O4iXBJ9hZHWGtPBXNIX2LxaqQ/ZzJN1uDpgxv6gOcL NLqxCSAHlgnmFIzcyJCv8woaWT4k12aA5RHKFjFOkUpq/FXxRTcbKK/SJ+ygwYJyOBM+ MlhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=NXa/YYZFgkyEM6Ml2YSN1eFBuqtpb7dTMG2HdFL72wo=; b=TjQpJdBJAhhrIkzYF1roxGpbObxQwMN5w7+R1zEyWtnJNs6or6/3dIcCjYNjI//QWo alF2apEMCOxH4Ve9UzZP1mP8Sb50IL1x5Mf5uXQLZ/i+3ARsWS4Rxdb2y33XaA8Rq44d gjt1fhfzEEy+Id+fJGBDkcJ0Hvl4OecYgJXb/rhYk+S0Zk/G8OC32VBbq4hhK5OudhXO a0AEAhFmi5YcvhA+bO+fs8Sx+7HsLyYLDMZNW4GCLrI49YANnfGi1Vpg2SaTivP/duig stTMMszfXrMmE1YHpNB+6uuUMPo/PbF1hpkAj5Au+Ar219E8W5vxTMs9I0VZy9TBEytT Zicw== X-Gm-Message-State: ALyK8tJxgEczgyGSWatR4bxo6h9XaAQ+i6hSW4R6EFNd5fE0NeOx04yHvYED0dmU1d7Q//bncZPBYrT4I5kSuw== X-Received: by 10.36.76.71 with SMTP id a68mr20142190itb.77.1465910784327; Tue, 14 Jun 2016 06:26:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.152.131 with HTTP; Tue, 14 Jun 2016 06:25:45 -0700 (PDT) From: Idel Pivnitskiy Date: Tue, 14 Jun 2016 16:25:45 +0300 Message-ID: To: webpush@ietf.org Content-Type: multipart/alternative; boundary=001a1144906a928bb505353cf30d Archived-At: Subject: [Webpush] Replacing Push Messages just with Topic. Why? X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 13:26:27 -0000 --001a1144906a928bb505353cf30d Content-Type: text/plain; charset=UTF-8 Can not find discussion about this. Only push messages that have been assigned a topic can be replaced. A push > message with a topic replaces any outstanding push message with an > identical topic. Why a user can replace push messages just with topics? Why we don't allow him to replace any message providing push message resource? Looks like it may simplify implementation. And no need to worry if user didn't assigned a topic to the message which he wants to replace. Best regards, Idel Pivnitskiy -- Twitter: @idelpivnitskiy GitHub: @idelpivnitskiy --001a1144906a928bb505353cf30d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Can not find discussion about this.

Only pu= sh messages that have been assigned a topic can be replaced. A push message= with a topic replaces any outstanding push message with an identical topic= .

Why a user can replace push messag= es just with topics? Why we don't allow him to replace any message prov= iding push message resource? Looks like it may simplify implementation. And= no need to worry if user didn't assigned a topic to the message which = he wants to replace.

Best regards,
Idel Pivnit= skiy
--
Twitter:=C2=A0@idelpivnitskiy
GitHub:= =C2=A0@idel= pivnitskiy
--001a1144906a928bb505353cf30d-- From nobody Tue Jun 14 06:54:44 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7E8612D607 for ; Tue, 14 Jun 2016 06:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q24CAIr2jWT3 for ; Tue, 14 Jun 2016 06:54:42 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::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 2C14712B074 for ; Tue, 14 Jun 2016 06:54:42 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id c73so62486974qkg.2 for ; Tue, 14 Jun 2016 06:54:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WqvGl3Ks58VID0qa/WkbtmdkhcC0lQtzAn+bpdLGt88=; b=UN+fNOmk1KAiVSKxfCvsrmNBfhyGLmeug/aSKbqu3EIXxc6RFK66YRwmOoZkTBjN9Z AJ2VwG9xqranJPni1vHM0Q6oFsEKL/B7G2xPwPbcfOfs+mrXyanS8GKPGi47oj5YeWt5 wpdEJoIgPJOl+ubZSSnM3tV+38pgDMXnwnXIC/6pvt6SDjJbMnbwr2Zaej7vZHeapSsp jTFYWyzM/o5x8vpvd7kFfg+WvMeJE1Ge3V7WEREYITh7MIhIwbgkA4TPuuOK+a+8vzly JTw6paDEjEK5ECiZfbaRO8WCIkaETo/gC2oX75AW/kuZug7yzkmDieNOo5K0i1fQDSVY 5OJg== 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; bh=WqvGl3Ks58VID0qa/WkbtmdkhcC0lQtzAn+bpdLGt88=; b=AofCvS3iikGCrIXBmuZPiUxsgTplPqKLsJEPJ9Yrj0jId19j0EjfFuMZIUrr2rcr4+ WaKRxuhPburTZdUk4XhD9VmTEyOz4nMAXCFCVFPknHpljVnsh/83s6rRVKGQpsTN4mwJ uTcgCghaePqeNtiKKCdmjPbNMyShm95EH86Tg6LYigG671UdoGjQvl2pzE5nwOyQvh5y cdcFF/38VfLyq5oTrMQN1lfGDc1IIzY4bDxOSUCx3Z2vS8K/9+sBzsvj+thrhwEduPs0 GVUOgLqrC8nLElCrQUh9nXO76Q1DrjB4VOjktAcKUNpBoNtYxODuvMeX9lrmqh0V7BLt I58Q== X-Gm-Message-State: ALyK8tJtnDI85dUyVRcAuT2pIfYHN/5dwtf23kMJOrm8RdsY97MiX7WcFLaMqWGPxCnR4vQhi88Elca/SOGKoQ== X-Received: by 10.55.78.16 with SMTP id c16mr8840486qkb.48.1465912481219; Tue, 14 Jun 2016 06:54:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.104.37 with HTTP; Tue, 14 Jun 2016 06:54:40 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Tue, 14 Jun 2016 14:54:40 +0100 Message-ID: To: Idel Pivnitskiy Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Replacing Push Messages just with Topic. Why? X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 13:54:43 -0000 On 14 June 2016 at 14:25, Idel Pivnitskiy wrote: > Why a user can replace push messages just with topics? Why we don't allow > him to replace any message providing push message resource? Looks like it > may simplify implementation. And no need to worry if user didn't assigned a > topic to the message which he wants to replace. We had a discussion about this at our Yokohama meeting, where I presented exactly this idea. It was observed that many applications don't want to keep state about the messages that they want to replace. In order to replace based on the resource URL, they have to wait for the response from the server as well, which was also considered inconvenient. Topics are simpler to manage. From nobody Tue Jun 14 10:01:07 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9CDB12D7A2 for ; Tue, 14 Jun 2016 10:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7Kds64eN7Gs for ; Tue, 14 Jun 2016 10:01:01 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0125.outbound.protection.outlook.com [207.46.100.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21C7012D853 for ; Tue, 14 Jun 2016 10:01:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0T8aWrlUnPhW/4Amj2HXRBr/A1Q4D82F2Qpo8UVYvYE=; b=n+mWj6XHr0c51TrdBE5V4PuRZNjw2zaqdlYsV+JuQp+bz/MSPJpowqxnh/hqQwS+iBT6+1EVT7mFUb1QoQBHf9ZSPH7y+wbkeYaqCUQUlnX3la5R//I7T6jjefvOLKiug7bzeeORKN1ugV5DBVKbfL0IJPdjQ20/IASx+gOsK2Q= Received: from CO2PR03MB2407.namprd03.prod.outlook.com (10.166.93.137) by CO2PR03MB2407.namprd03.prod.outlook.com (10.166.93.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.517.8; Tue, 14 Jun 2016 17:00:59 +0000 Received: from CO2PR03MB2407.namprd03.prod.outlook.com ([10.166.93.137]) by CO2PR03MB2407.namprd03.prod.outlook.com ([10.166.93.137]) with mapi id 15.01.0517.011; Tue, 14 Jun 2016 17:00:59 +0000 From: Brian Raymor To: "webpush@ietf.org" Thread-Topic: Status for webpush-05 WGLC Thread-Index: AdHAOCd7uxTXYP7bRPSDqvdAJMja2AGHcj+Q Date: Tue, 14 Jun 2016 17:00:59 +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: [24.16.23.27] x-ms-office365-filtering-correlation-id: 4e47bfd4-c712-41c3-3ab3-08d3947575a9 x-microsoft-exchange-diagnostics: 1; CO2PR03MB2407; 6:rKeLtxq7fmdbHz1q+k4aSEmXUeGxpfwYLlYlzWXPxwXOp/QVJqzO/JXvOfgqkv2txgD1UWPjygSRnpc3hZ7XnXkY6PzuoQoi5mbKwXssHlVPGTRGJ9OT2wBzktcuwA77xRPPtUA8S/pXvXoTT10XiF3WyT1DUM7lnf3niNPUJM3pX3K+DZMFTSnjD0rFv76hEpQDfpZFpi9U94WG1Qh3hpz6CBYHaLPz8jjGbMu/NE2xQdF+14VV4qw6bzUAtg3Kiz5GSIaNc0JTcpie/DbRlwLkqPNawjJgjSKqZw5dxzxHGdGo4PQpUV1dcV68gFmh; 5:4hxyFhlzFQE+vkTPKpSBK4/k12PqkoPRAxu+YEj0iMw4L4bFWojNxjYa1h47wHqllMzp5NwUwABjf6d56zaaM5+S401qsWE3Bp+MFSsROBE1WtpWs1WTa62gzJh58WUDxew77eIrA5bdPOeBkqnsHg==; 24:b6X3uxuuCo99A2u7W3M2xxiwx8Q+trELuOOMNfeMswGuCx59iD6OLN8rsVg722P6LskzGTDsjXHiNJr5l4uyX15B1YxMUpWtS1Q+Z70L1OQ=; 7:GjTtwR7P222qmSVkGdxaM6n0tFd8CC005ovfJ1ScRgM3y/VFHRUw0sMSrTHzx4eWsjpTcbf+iIWI3O2ymt8TIYEHp0/NIB7HvuFztcPvLKBaaBcI/0XKkSxfrexLLBbdxeFye/MVcwbwZ25pEFZjzn4C2ClNli/asUygWm6c1sY1slgCW8YrhSlZrptP+pcdU0PvOXllzDYToLc5sBm+cBY01I9Q9X3KFHDtXI8NdQw= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR03MB2407; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CO2PR03MB2407; BCL:0; PCL:0; RULEID:; SRVR:CO2PR03MB2407; x-forefront-prvs: 09730BD177 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(199003)(189002)(122556002)(86362001)(66066001)(99286002)(2351001)(2906002)(106356001)(105586002)(586003)(3846002)(11100500001)(102836003)(6116002)(10090500001)(10290500002)(5005710100001)(10400500002)(2501003)(8936002)(8990500004)(9686002)(19580405001)(5004730100002)(77096005)(5002640100001)(19580395003)(76176999)(54356999)(74316001)(2950100001)(189998001)(2900100001)(87936001)(76576001)(15975445007)(33656002)(5640700001)(3280700002)(101416001)(5008740100001)(92566002)(81166006)(1730700003)(81156014)(8676002)(86612001)(50986999)(97736004)(3660700001)(110136002)(107886002)(5003600100002)(450100001)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR03MB2407; H:CO2PR03MB2407.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jun 2016 17:00:59.4490 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR03MB2407 Archived-At: Subject: Re: [Webpush] Status for webpush-05 WGLC X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 17:01:07 -0000 Update - All issues are closed. The last open PR is in review and ready to = merge today. I plan to publish webpush-06 later today after reviewing the current draft.= =20 From: Webpush [mailto:webpush-bounces@ietf.org] On Behalf Of Brian Raymor Sent: Monday, June 6, 2016 2:16 PM To: webpush@ietf.org Subject: [Webpush] Status for webpush-05 WGLC I really appreciate all the detailed reading and thought that went into the= feedback.=20 Thanks for helping to improve the draft. Going forward, I would make one small request. Could we use separate mail s= ubjects for separate topics? It's a bit difficult to track conversations when all t= he subject lines are "Non-blocking comments on -05" ;-) That said, if I've missed capturing or a= ddressing your issue, please let me know.=20 My goal is to publish webpush-06 on or before 6/13 if consensus is reached.= We have until 7/8 to publish further drafts for IETF96. These open issues need more working group discussion: * =A0Adds that receipt support is mandatory. https://github.com/webpush-wg/webpush-protocol/pull/104 Receipts have been required since the -00 draft from July 2015 - https://to= ols.ietf.org/html/draft-ietf-webpush-protocol-00#section-6.2 Related threads on the mailing list: http://www.ietf.org/mail-archive/web/webpush/current/msg00565.html http://www.ietf.org/mail-archive/web/webpush/current/msg00573.html * =A0Allow push service to reject messages < 4K https://github.com/webpush-wg/webpush-protocol/issues/109 Related thread on the mailing list: http://www.ietf.org/mail-archive/web/webpush/current/msg00572.html These open issues are more editorial in nature: * =A0Optional message encryption and push message examples Issue: https://github.com/webpush-wg/webpush-protocol/issues/106=20 PR: https://github.com/webpush-wg/webpush-protocol/pull/107 When we added "The ciphertext of the push message is included in the body o= f the request." during WGLC, the examples no longer matched the description. I'm leaning towards clear text examples = for clarity with a pointer to an example of encrypted content in Martin's optional draft. * =A0Make it a bit more obvious which is the send resource. https://github.com/webpush-wg/webpush-protocol/pull/105 Costin writes - "push resource" is confusing me every time - "push" is used= in all other resources. Please share your suggestions in the PR. * =A0proxy uc https://github.com/webpush-wg/webpush-protocol/pull/96 Herve provided further clarification for the Canon scenarios. Costin has pe= nding feedback that needs to be addressed. From nobody Tue Jun 14 20:27:50 2016 Return-Path: X-Original-To: webpush@ietf.org Delivered-To: webpush@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6C912B014; Tue, 14 Jun 2016 20:27:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.22.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160615032748.31758.86378.idtracker@ietfa.amsl.com> Date: Tue, 14 Jun 2016 20:27:48 -0700 Archived-At: Cc: webpush@ietf.org Subject: [Webpush] I-D Action: draft-ietf-webpush-protocol-06.txt X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 03:27:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web-Based Push Notifications of the IETF. Title : Generic Event Delivery Using HTTP Push Authors : Martin Thomson Elio Damaggio Brian Raymor Filename : draft-ietf-webpush-protocol-06.txt Pages : 31 Date : 2016-06-14 Abstract: A simple protocol for the delivery of realtime events to user agents is described. This scheme uses HTTP/2 server push. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-webpush-protocol/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-webpush-protocol-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-webpush-protocol-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 23 00:59:01 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D97412D12B for ; Thu, 23 Jun 2016 00:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dp6-AFToyxzV for ; Thu, 23 Jun 2016 00:58:57 -0700 (PDT) Received: from gateway23.websitewelcome.com (gateway23.websitewelcome.com [192.185.49.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B654212D0DD for ; Thu, 23 Jun 2016 00:58:56 -0700 (PDT) Received: from cm7.websitewelcome.com (cm7.websitewelcome.com [108.167.139.20]) by gateway23.websitewelcome.com (Postfix) with ESMTP id 2E95AEAC26E65 for ; Thu, 23 Jun 2016 02:58:56 -0500 (CDT) Received: from gator4135.hostgator.com ([192.185.4.147]) by cm7.websitewelcome.com with id A7yv1t0023AKFgo017yw4U; Thu, 23 Jun 2016 02:58:56 -0500 Received: from ai126251102160.23.access-internet.ne.jp ([126.251.102.160]:53941 helo=[192.168.128.134]) by gator4135.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bFzXK-000BmO-KZ for webpush@ietf.org; Thu, 23 Jun 2016 02:58:54 -0500 From: Shida Schubert Content-Type: multipart/alternative; boundary="Apple-Mail=_D97790C3-B4A3-4715-AFDC-44C161D6A6D6" Message-Id: Date: Thu, 23 Jun 2016 16:58:51 +0900 To: webpush@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator4135.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source-IP: 126.251.102.160 X-Exim-ID: 1bFzXK-000BmO-KZ X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ai126251102160.23.access-internet.ne.jp ([192.168.128.134]) [126.251.102.160]:53941 X-Source-Auth: shida@agnada.com X-Email-Count: 3 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== Archived-At: Subject: [Webpush] WGLC for draft-ietf-webpush-protocol (again) X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 07:59:00 -0000 --Apple-Mail=_D97790C3-B4A3-4715-AFDC-44C161D6A6D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All; As I noted on the e-mail I sent out on June 7th after the initial WGLC = for webpush protocol draft, we are commencing another WGLC as there are = no remaining issues on github AND the authors have produced the 06 = version of the draft reflecting all resolutions. https://tools.ietf.org/html/draft-ietf-webpush-protocol-06 = If you have any issues or questions regarding the draft please submit it = to the list, when raising issues please provide constructive resolution = whenever possible. PLEASE acknowledge on the list when you are content/happy with the = status of the draft and you see no issue passing it forward to IESG for = publication.=20 The WGLC will conclude at the end of the day on July 8th PST. Shida As co-chair= --Apple-Mail=_D97790C3-B4A3-4715-AFDC-44C161D6A6D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
All;

As I noted on the e-mail I sent out on = June 7th after the initial WGLC for webpush protocol draft, we are = commencing another WGLC as there are no remaining issues on github AND = the authors have produced the 06 version of the draft reflecting all = resolutions.

https://tools.ietf.org/html/draft-ietf-webpush-protocol-06<= /div>

If you have = any issues or questions regarding the draft please submit it to the = list, when raising issues please provide constructive resolution = whenever possible.

PLEASE acknowledge on the list when you are content/happy = with the status of the draft and you see no issue passing it forward to = IESG for publication. 

The WGLC will conclude at the end of the day = on July 8th PST.

Shida
As co-chair
= --Apple-Mail=_D97790C3-B4A3-4715-AFDC-44C161D6A6D6-- From nobody Thu Jun 23 08:27:49 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8647B128E18 for ; Thu, 23 Jun 2016 08:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDDo9e8kLrBm for ; Thu, 23 Jun 2016 08:27:46 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6288D12D1AC for ; Thu, 23 Jun 2016 08:27:28 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id q132so98144295lfe.3 for ; Thu, 23 Jun 2016 08:27:28 -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; bh=plrPdMVIsD1z8hjU4fk7DJgP/3h1YJYYS/cTLt05Ctc=; b=BpGgKA74EkBgbuvrB61PREG/XWvp1xc7FReo8i+AroBXoiP+bf0AVwGkvGd9FjtsfV ck3pM/6Ywkr0M2+mKJJtPtwtswMH31O/PcqvB53NaReeJW/yxj5jFJtwb/x4hTfBdKuz klvJ6iQPgp6IvBhL9RASlNeto8eeQ4fBLAq9kvQaxFcY8VrqDSygtKcyRAeEYqdox3Ug BrkCelcRZymJcEZt3mFghDytbScWmuNuDv2YHhCZt0m+VisK8EOF+AjdNdkg44r5pA3B l1GoYlcOqxEOD9b0Mp1lgI+epd6JzHmAL0wjObLBOEZurNudrwz3aWJZi1KZ3caSyBq1 6uPQ== 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; bh=plrPdMVIsD1z8hjU4fk7DJgP/3h1YJYYS/cTLt05Ctc=; b=Vfr5lcZ6KRAnzIvrXZekvFvcsHFfSP0WiLkOXTlqmcy+Wc/5EmAT0zg1gAy6gASznL p9nf6l2zO7yppWra4ek8THI+Ca7xNlN984DiU588p+WMSPyurt0cJp69rlS6ANxSovv6 Uy/xsapRiQ4QiCJPYMImO7xnvTdMCTTFJk7KQZfW2oZ4GUsiNePxTx9tUQ3UumjH9jm/ oeTCtTJESuhrj1qtlZRaegXVa/kd21pja34oPmBy4TIWPbFIzlyIF7SAwCgJbET+4VSb aNQq30ghYDcErXTJYNUFf2PVbT8SfujEcy5nMjvxRa86GPEXmeFwaKfT05UsoDg7IzSB xFBQ== X-Gm-Message-State: ALyK8tLcXvruhjUL/k8Rz36vndrpfgSHRjOL3xHguQvfJ/vBRwB3kLcwXb4mt2WCcKMoX8YudE4rAEL2FS9hOUGV X-Received: by 10.25.166.2 with SMTP id p2mr12476356lfe.48.1466695646117; Thu, 23 Jun 2016 08:27:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.147.199 with HTTP; Thu, 23 Jun 2016 08:27:25 -0700 (PDT) In-Reply-To: References: From: Peter Beverloo Date: Thu, 23 Jun 2016 16:27:25 +0100 Message-ID: To: Shida Schubert Content-Type: multipart/alternative; boundary=001a11411d66fb55860535f3b079 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] WGLC for draft-ietf-webpush-protocol (again) X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 15:27:48 -0000 --001a11411d66fb55860535f3b079 Content-Type: text/plain; charset=UTF-8 I support the draft as-is. Once again, many thanks to the editors for their fantastic work! Thanks, Peter On Thu, Jun 23, 2016 at 8:58 AM, Shida Schubert wrote: > All; > > As I noted on the e-mail I sent out on June 7th after the initial WGLC for > webpush protocol draft, we are commencing another WGLC as there are no > remaining issues on github AND the authors have produced the 06 version of > the draft reflecting all resolutions. > > https://tools.ietf.org/html/draft-ietf-webpush-protocol-06 > > If you have any issues or questions regarding the draft please submit it > to the list, when raising issues please provide constructive resolution > whenever possible. > > PLEASE acknowledge on the list when you are content/happy with the status > of the draft and you see no issue passing it forward to IESG for > publication. > > The WGLC will conclude at the end of the day on July 8th PST. > > Shida > As co-chair > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > > --001a11411d66fb55860535f3b079 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support the draft as-is. Once again, many thanks to the = editors for their fantastic work!

Thanks,
Pete= r

On T= hu, Jun 23, 2016 at 8:58 AM, Shida Schubert <shida@ntt-at.com> wrote:
All;

As I noted on the e-mail I sent ou= t on June 7th after the initial WGLC for webpush protocol draft, we are com= mencing another WGLC as there are no remaining issues on github AND the aut= hors have produced the 06 version of the draft reflecting all resolutions.<= /div>


If you have any issues = or questions regarding the draft please submit it to the list, when raising= issues please provide constructive resolution whenever possible.

PLEASE acknowledge on the list when you are content/happy w= ith the status of the draft and you see no issue passing it forward to IESG= for publication.=C2=A0

The WGLC will conclud= e at the end of the day on July 8th PST.

Shi= da
As co-chair

___________________________________= ____________
Webpush mailing list
Webpush@ietf.org
https://www.ietf.org/mailman/listinfo/webpush


--001a11411d66fb55860535f3b079-- From nobody Thu Jun 23 09:23:15 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE9DE12B037 for ; Thu, 23 Jun 2016 09:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mozilla-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3AyFJIVJPdt for ; Thu, 23 Jun 2016 09:23:11 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B02C312B00F for ; Thu, 23 Jun 2016 09:23:10 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id u201so77803411oie.0 for ; Thu, 23 Jun 2016 09:23:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=UQi2/7qLqaqklBIiJuScGOVNvpCue8NouK56AVPhchg=; b=fg0cNb6L74wF2nf4HaZOINlU0aTz4TGCf1M5K3DAU0uSzWmjDZ7jmeG6E0AW/xc/z8 SQzlDRvj1qVsmL0SW87ECSuv6LScdZS5Ofj5XY8S0BMZOCZ+ML+/Qsfbr3+dCcdxRKP0 QaoHPvvJNBcdW51SUcUfPwPpsyccuN9LdUy3g9iLkGmhtNL79qCKGWg2mVsPgcbEfK/S KV8H1URfgc8ZRfZFsNqtwtecezGFNgKHorwzq+xY3Z8PMlbdYaiHDQc1YDc9MtUKmHuh GL0DO6MdFaHWEl+RjidyYW9UE2Y0ecBt7nKydKSVugROMyI42a31vDo4xmQVteTP/2ze E5ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=UQi2/7qLqaqklBIiJuScGOVNvpCue8NouK56AVPhchg=; b=l18oCji69YG3YlFg4b1jyHDXk+wjH+xmMDO15A6HlQCLCk4EBNGNFOxXoUKraglBz2 gTeH33vWjLSyv04ajhXLQc1XrgsadbRdEaGig72GLYhoULzv3dmbb3xZMIpBm6galkK2 R3LY8ZD7L4t1CUV5moTsoZ8t06sawUcFK7HKouCGzBDgZXbVOZ8RIt0kIfGkHgM7jRKt 9La6AFKUs7YAblJE1itUwj88AdyDwIZPTJPbmp3hayQ131Jdl5Z9tVm85fmV7DUI2FVE VQK7x1ZDSS29Lyg81deenRsIAPQj0tzMw27LdJmksQTxill04dN0rmoD5lFC51DnhGyH 1DvQ== X-Gm-Message-State: ALyK8tL/vg1CTkTf+H7T1tEMVj7ETd6eedw+UAF9HHrFRcDcb03wOD6IOc+3I5+ffPp0jrLj X-Received: by 10.157.8.65 with SMTP id 59mr7467060oty.114.1466698989943; Thu, 23 Jun 2016 09:23:09 -0700 (PDT) Received: from ?IPv6:2602:306:b826:64df:76:b75b:9151:7780? ([2602:306:b826:64df:76:b75b:9151:7780]) by smtp.gmail.com with ESMTPSA id y3sm443572ota.18.2016.06.23.09.23.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jun 2016 09:23:09 -0700 (PDT) To: webpush@ietf.org References: From: jr conlin Message-ID: Date: Thu, 23 Jun 2016 09:23:10 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:49.0) Gecko/20100101 Thunderbird/49.0a2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1D4C923F87D860F7B10A1C27" Archived-At: Subject: Re: [Webpush] WGLC for draft-ietf-webpush-protocol (again) X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 16:23:14 -0000 This is a multi-part message in MIME format. --------------1D4C923F87D860F7B10A1C27 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit I have no additional concerns or requests for this protocol, and support this draft. Huge thanks to the editors and contributors for their patience and understanding. On 6/23/2016 12:58 AM, Shida Schubert wrote: > All; > > As I noted on the e-mail I sent out on June 7th after the initial WGLC > for webpush protocol draft, we are commencing another WGLC as there > are no remaining issues on github AND the authors have produced the 06 > version of the draft reflecting all resolutions. > > https://tools.ietf.org/html/draft-ietf-webpush-protocol-06 > > If you have any issues or questions regarding the draft please submit > it to the list, when raising issues please provide constructive > resolution whenever possible. > > PLEASE acknowledge on the list when you are content/happy with the > status of the draft and you see no issue passing it forward to IESG > for publication. > > The WGLC will conclude at the end of the day on July 8th PST. > > Shida > As co-chair > > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush --------------1D4C923F87D860F7B10A1C27 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
I have no additional concerns or requests for this protocol, and support this draft.

Huge thanks to the editors and contributors for their patience and understanding.

On 6/23/2016 12:58 AM, Shida Schubert wrote:
All;

As I noted on the e-mail I sent out on June 7th after the initial WGLC for webpush protocol draft, we are commencing another WGLC as there are no remaining issues on github AND the authors have produced the 06 version of the draft reflecting all resolutions.


If you have any issues or questions regarding the draft please submit it to the list, when raising issues please provide constructive resolution whenever possible.

PLEASE acknowledge on the list when you are content/happy with the status of the draft and you see no issue passing it forward to IESG for publication. 

The WGLC will conclude at the end of the day on July 8th PST.

Shida
As co-chair


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


--------------1D4C923F87D860F7B10A1C27-- From nobody Fri Jun 24 09:07:59 2016 Return-Path: X-Original-To: webpush@ietf.org Delivered-To: webpush@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5D212DD2E; Fri, 24 Jun 2016 09:00:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160624160058.10933.33452.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2016 09:00:58 -0700 Archived-At: Cc: alissa@cooperw.in, webpush@ietf.org Subject: [Webpush] webpush - Requested session has been scheduled for IETF 96 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 16:01:01 -0000 Dear Shida Schubert, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. webpush Session 1 (2:00:00) Tuesday, Afternoon Session II 1620-1820 Room Name: Schoeneberg size: 100 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Web-Based Push Notifications Area Name: Applications and Real-Time Area Session Requester: Shida Schubert Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: tls mmusic dispatch rtcweb httpbis core Second Priority: capport modern sipcore ice stir Special Requests: --------------------------------------------------------- From nobody Mon Jun 27 03:04:33 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD5312D0BC for ; Mon, 27 Jun 2016 03:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mozilla-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id popfqeLs7INt for ; Mon, 27 Jun 2016 03:04:28 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B98512D0B5 for ; Mon, 27 Jun 2016 03:04:27 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id h14so60644381pfe.1 for ; Mon, 27 Jun 2016 03:04:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=NprwGcQXLLkvjklJS/2cQYbM5QJMzNM8Q4aKliElSH4=; b=xPeCD0ElGDMTJYff/ZG0qX+Zjha9qqF6bx6tJBxbzo+uw6Z9sHczaQgsnqolpYXcuf KsYvSy6WvjJVjNEeiJDAxSwtLQPvXC/J5OjFFLH29U/iiiy7AGI51n4IdCOL7lp58wRy DYDC3QydJCk/qiSs9je9/eQpneN++QHGw8yq8OgOs17bX2PeGszpkgcWgrHOIRKEvrL3 DcixFKzb9d+JIVatlIFtTnVgDC+rfuRm+9dQK4+xtRjyJvl5kivnHunXp7ZrnjkArJDm WuSaOefW0kRSAq2CvvfTb93hXNeDFb5QHW7KOAkkTzzw1CcIJuyIdcFOySbDtAwEQcRZ yPuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=NprwGcQXLLkvjklJS/2cQYbM5QJMzNM8Q4aKliElSH4=; b=A2m+RNl+lWSwfTY86G92+r+MevblicrerNBlH1ObONakhmxTQYqy+xCB53ar5jNhHj IlZqQ8usyyNeqSsR8w4BKeAHn06olhWAKjHXwtNyZf9wWl7vNdyYTN3HmBDpgYKgROuP eWSD7nmmRoPevSS1sHm8M1iuCYyjsQJ2WmircRRvlPt9njUgFSdYFA/wcxzSb2Q3KFY5 UQtuQXaIxe7SsKwyPwT7lo5sD1JcYQNbkKPg8+Ro6vXgJrdaMoYKQV/6+ZJhD56RyTFU YEAA/lx/9YoCd/D+7Ev99DHInX2+fiVcOnbXNe60/vJHc7hzoo2Qrfxkj78GkmDJibwN ftdw== X-Gm-Message-State: ALyK8tLR6XiNk0+Rvt593DTBcjkHmbO7i1XFfVG0AYHIWwX9x4/9lpnSRShU+5wQ2n6+dDZ9 X-Received: by 10.98.208.197 with SMTP id p188mr31944534pfg.152.1467021866730; Mon, 27 Jun 2016 03:04:26 -0700 (PDT) Received: from [10.0.1.5] (c-69-181-119-84.hsd1.ca.comcast.net. [69.181.119.84]) by smtp.gmail.com with ESMTPSA id y70sm5520322pff.25.2016.06.27.03.04.25 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 27 Jun 2016 03:04:25 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_9233EC4E-D516-4CD4-BC36-8E7166ABB8CE" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Kit Cambridge In-Reply-To: Date: Sun, 26 Jun 2016 16:06:16 +0100 Message-Id: <786718A2-C28D-436C-B91D-B3217F459F2E@mozilla.com> References: To: jr conlin X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: webpush@ietf.org Subject: Re: [Webpush] WGLC for draft-ietf-webpush-protocol (again) X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 10:04:31 -0000 --Apple-Mail=_9233EC4E-D516-4CD4-BC36-8E7166ABB8CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I support the draft, with gratitude to the editors and chairs for their = hard work. Cheers, - kit On Jun 23, 2016, at 5:23 PM, jr conlin wrote: > I have no additional concerns or requests for this protocol, and = support this draft. >=20 > Huge thanks to the editors and contributors for their patience and = understanding. >=20 > On 6/23/2016 12:58 AM, Shida Schubert wrote: >> All; >>=20 >> As I noted on the e-mail I sent out on June 7th after the initial = WGLC for webpush protocol draft, we are commencing another WGLC as there = are no remaining issues on github AND the authors have produced the 06 = version of the draft reflecting all resolutions. >>=20 >> https://tools.ietf.org/html/draft-ietf-webpush-protocol-06 >>=20 >> If you have any issues or questions regarding the draft please submit = it to the list, when raising issues please provide constructive = resolution whenever possible. >>=20 >> PLEASE acknowledge on the list when you are content/happy with the = status of the draft and you see no issue passing it forward to IESG for = publication.=20 >>=20 >> The WGLC will conclude at the end of the day on July 8th PST. >>=20 >> Shida >> As co-chair >>=20 >>=20 >> _______________________________________________ >> Webpush mailing list >> Webpush@ietf.org >> https://www.ietf.org/mailman/listinfo/webpush >=20 > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush --Apple-Mail=_9233EC4E-D516-4CD4-BC36-8E7166ABB8CE Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=windows-1252 I support the draft, with gratitude to the editors and chairs for their hard work.

Cheers,
- kit

On Jun 23, 2016, at 5:23 PM, jr conlin <jconlin@mozilla.com> wrote:

I have no additional concerns or requests for this protocol, and support this draft.

Huge thanks to the editors and contributors for their patience and understanding.

On 6/23/2016 12:58 AM, Shida Schubert wrote:
All;

As I noted on the e-mail I sent out on June 7th after the initial WGLC for webpush protocol draft, we are commencing another WGLC as there are no remaining issues on github AND the authors have produced the 06 version of the draft reflecting all resolutions.


If you have any issues or questions regarding the draft please submit it to the list, when raising issues please provide constructive resolution whenever possible.

PLEASE acknowledge on the list when you are content/happy with the status of the draft and you see no issue passing it forward to IESG for publication. 

The WGLC will conclude at the end of the day on July 8th PST.

Shida
As co-chair


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


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

--Apple-Mail=_9233EC4E-D516-4CD4-BC36-8E7166ABB8CE-- From nobody Tue Jun 28 09:24:20 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB8D12D54F for ; Tue, 28 Jun 2016 09:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mozilla-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJmOGXpnMy6R for ; Tue, 28 Jun 2016 09:24:16 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA99512D54C for ; Tue, 28 Jun 2016 09:24:16 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id u201so30180501oie.0 for ; Tue, 28 Jun 2016 09:24:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=mime-version:reply-to:from:date:message-id:subject:to; bh=SWL8B1P9gPquYNnExgiIQyNUXcBvL2sw+xv3udEEyYY=; b=FLs9+3ChxAwzeUHJVNn7rTQTM01xyoBIUf1taGy/Y0GrF3izMY3oP+afYIZFu9WYKd rbsYTYuEtrZLuWdKDboDmTbvRrwTNOxV0wNO1875txLt753BEpNUNusZupPL/wTuWDPK P8lMnXLkpMkK5b2WobZLxb6rTW/nOTWZfDGtRBOKweW4YqYvycpt7Itb7b9DgFYQlV91 PyA+jrhN6MdpDlRP5UujdspOYUeNqROo3iDFURG9qPQo+ZHX+wTD07LK4M1/9uz1pZxv hUtiaF7SrjjWGjN1F64gXB3hYDkl2FokwYwOniseAcFbMU3TBR7R2DaOJi/k8KxhPfIM pTMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:from:date:message-id :subject:to; bh=SWL8B1P9gPquYNnExgiIQyNUXcBvL2sw+xv3udEEyYY=; b=L25elRNGaqXciRqQlpG/uLYpsBOftYqAv0j9X825lUwNYATX5z3sNZEMSfUijoC+Tp VuTEhYvzCTnhl2tFonCjw5c3OXu5dihc+s6CUtGs0eusaKpO4nSBAi1dIyaV2Kt1G99g tiBtWYUTNEBmIg52Vb2ZPk5IJWE/uUc9OYl6KOHNa/f2urBAkKfVZkx+pk6WNOuXchz1 oERExrb411fOsJ9NnAd7tV1d3ogHdFi/O8HCyzbq7GttelYWcL7EXlmmq20h0J2Kz8ZZ TXIasVUePg0tPYRbRv8Fkz/oYWb0QF9j7xSJly9FVIZ3R56Ti2FKrw7ngkd8Ybx6/Rj5 fUJw== X-Gm-Message-State: ALyK8tKfLbnNLcpSBs2FBUeVTkT8SJ3B4gYZiNysPJ7pWLTfomWDU0fy82hDRu/DPeoJ+JPordjZFzR6BptAnOQj X-Received: by 10.202.196.139 with SMTP id u133mr2654928oif.147.1467131056141; Tue, 28 Jun 2016 09:24:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.45.201 with HTTP; Tue, 28 Jun 2016 09:24:15 -0700 (PDT) From: JR Conlin Date: Tue, 28 Jun 2016 09:24:15 -0700 Message-ID: To: "webpush@ietf.org" Content-Type: multipart/alternative; boundary=001a113e25fe70ee2b053659112b Archived-At: Subject: [Webpush] Composite Crypto-Key composition issue X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jrconlin@mozilla.com 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, 28 Jun 2016 16:24:19 -0000 --001a113e25fe70ee2b053659112b Content-Type: text/plain; charset=UTF-8 I believe there may be some confusion about how to create a composite Crypto-Key header. The Crypto-Key Header is used by several supporting protocols of WebPush (ECE, VAPID). The respective specifications state that the field uses RFCs 7230 & 7231 where each parameter list set is divided by commas, and each individual parameter is divided by a semicolon. The confusion arises in whether or not each list set should contain items specific for a given sub-protocol. For instance, our autopush server treats ECE and VAPID as separate entities and divides the set containing the dh= parameter from the set containing p256ecdsa=. It's my understanding that FCM does not follow this practice and will generate an error if a "," appears in the Crypto-Key parameter lists. Since this is a point of confusion and conflict, I believe it would be in the best interests of all if this was addressed in some manner so that future conflict and confusion can be avoided. (For what it's worth, I really don't care what the answer is; keep protocol parameter sets distinct to avoid potential future conflicts or combine all parameters into one big ol' hash. Just want to prevent future folk from swearing at us.) --001a113e25fe70ee2b053659112b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I believe there may be some confusion about how to create a composite Cr= ypto-Key header.

The Crypto-Key Header is used by several supporting protoc= ols of WebPush (ECE, VAPID). The respective specifications state that the f= ield uses RFCs 7230 & 7231 where each parameter list set is divided by = commas, and each individual parameter is divided by a semicolon.

The confusi= on arises in whether or not each list set should contain items specific for= a given sub-protocol.

For instance, our autopush server treats ECE and VAPI= D as separate entities and divides the set containing the dh=3D parameter f= rom the set containing p256ecdsa=3D. It's my understanding that FCM doe= s not follow this practice and will generate an error if a "," ap= pears in the Crypto-Key parameter lists.

Since this is a point of confusion= and conflict, I believe it would be in the best interests of all if this w= as addressed in some manner so that future conflict and confusion can be av= oided.

(For what it's worth, I really don't care what the answer is;= keep protocol parameter sets distinct to avoid potential future conflicts = or combine all parameters into one big ol' hash. Just want to prevent f= uture folk from swearing at us.)
--001a113e25fe70ee2b053659112b-- From nobody Tue Jun 28 09:24:32 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE6112D5AE for ; Tue, 28 Jun 2016 09:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEwaEf0b99Xr for ; Tue, 28 Jun 2016 09:24:24 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE2B312D5AB for ; Tue, 28 Jun 2016 09:24:23 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id h129so15171446lfh.1 for ; Tue, 28 Jun 2016 09:24:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=8YH0+dy/2x2zxZOULRz6Ws4WG3wssVvWVcPZGTjmvvo=; b=KQdp2k/9GIYZPNiZKTYHDLvLajkihJZLg86YaPofvLKdL0Rp/mt16qI0dOHaAY/o25 qbYbKamQYaQXcCJyWc9ri2ZFlVgRt6ZrUM2m71+KEpYBWuRgLeuHOwHbsWuIzIKGrH3s BcMXVu4Dlb1kZuYMzZRdKRBPrUNjs5ti/EHCFYROjPkNHhHq4tFxY3PvETUfFTuyFx2t 9KZJJUmCnJyFoUXYixdoHMEhtUx1w6tqJFF4KBixPeAuNU86HIWbnqYpKIw1H3OSKSlz cuKYQfkKtUP3by1i01Uk8l0aifCsH020izD7SqaEijNPOhCbOh0nPo0CSRTtcxAxZzf8 +sXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=8YH0+dy/2x2zxZOULRz6Ws4WG3wssVvWVcPZGTjmvvo=; b=f50D7a+3lk3NwFZ9GiNOt+viVTP+h1Dly+S7GguLG+3Agm2PpK+HChg7bbyipiVSYe 0CWJ1CbYIgy5iRkGpukdI54kjh1LEhCEehnpbn9vwBstaXEaJRssrSHuNAYMoGacPZTm a5KvbXi8ehweozA+4gWkOSEuI8B/pbaTv+U5a0RJsFmGwtvQ2hxp3ygEJBpK1vpDOmLM yufMCH0RMGgl9hRUJPjSSQBpqjEwxgejEuRrZGK7fQYRh0ArXrnuSKdw6eBRXWXnsXZj jfOpLltY78fDVsdGNUizN35He1LaWGeM4SIUzmeXG8LH06VSYYZc79UsMkoQsfh8UcMs JWJQ== X-Gm-Message-State: ALyK8tLKJXxsr/BbTmCQ6JIlosWLnE4tlB02Maw9eRMwtrIk3ynNAXaRYsMEcEsftheSIe6c7G09F81EAkaarOJ/ X-Received: by 10.46.33.12 with SMTP id h12mr866513ljh.43.1467131061703; Tue, 28 Jun 2016 09:24:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.147.199 with HTTP; Tue, 28 Jun 2016 09:24:20 -0700 (PDT) From: Peter Beverloo Date: Tue, 28 Jun 2016 17:24:20 +0100 Message-ID: To: "webpush@ietf.org" Content-Type: multipart/alternative; boundary=001a1142c5c8c5ef0a05365911ac Archived-At: Subject: [Webpush] Too strict Crypto-Key restriction imposed by webpush-encryption X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 16:24:28 -0000 --001a1142c5c8c5ef0a05365911ac Content-Type: text/plain; charset=UTF-8 For those not following GitHub: There is a discrepancy between webpush-encryption[1] and webpush-vapid[2], where the latter says to use two values in the Crypto-Key header which is explicitly forbidden by the former. I've detailed the issue in the following GitHub issue, with an accompanying pull request relaxing the restriction to a maximum of one Crypto-Key field having the `dh` parameter: https://github.com/webpush-wg/webpush-encryption/issues/6 Thanks, Peter [1] https://tools.ietf.org/html/draft-ietf-webpush-encryption-02#section-3.2 [2] https://tools.ietf.org/html/draft-ietf-webpush-vapid-00#section-4 --001a1142c5c8c5ef0a05365911ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
For those not following GitHub:

T= here is a=C2=A0discrepancy between webpush-encryption[1] and webpush-vapid[= 2], where the latter says to use two values in the Crypto-Key header which = is explicitly forbidden by the former.

I've detailed= the issue in the following GitHub issue, with an accompanying pull request= relaxing the restriction to a maximum of one Crypto-Key field having the `= dh` parameter:


Thanks,
--001a1142c5c8c5ef0a05365911ac-- From nobody Tue Jun 28 09:31:00 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB54812D589 for ; Tue, 28 Jun 2016 09:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtsjX8LRpoVm for ; Tue, 28 Jun 2016 09:30:56 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F44112D51F for ; Tue, 28 Jun 2016 09:30:56 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id h129so15296372lfh.1 for ; Tue, 28 Jun 2016 09:30:55 -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; bh=iFArwYY1jMsi+iv1IGVodcWu53DTPktQwj0oX6I2Mc8=; b=KbN2L3/kt8RyDGAc9UCztgC3/hYv+Cehy5Mik6auCMcrchAnQq2n4BsRGdrM/o+1LS e0Zs1IERswvNdBw9LoGirWraEDg/mPz5N8PlVY+v6dgtgCzm5o+joI11BTStULG29i7S CqEGBFG0sqoCUgcKwJqXFvv7SxlkBXYpzYCf6kQ3CKdnhcHzNw03Pb5ml/zbRdREG8hV 0NrlSHKw/+ooR3bkLA9hNi1vJkXpV/LXhbEWe0K+kEvtWrQBmFqfn14sU/ZAkRvDZuhX gFsjFEtF5zqY8vxYEhz6CLlNKhglxdwsOIXzgFpf+/2PUHwX3usQ8TUi/qoM41ueIQa7 snFg== 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; bh=iFArwYY1jMsi+iv1IGVodcWu53DTPktQwj0oX6I2Mc8=; b=cYnS+dfzA/A0NUfPSAvkUsD7TwICnqOzhtKGYtlLodWY6eDN0HIRPxb2GVBECoZ8ps png0WO/ezW/+p7Nt1VQy3AOYE+NUk3VBBvF/LlZ7eOrX0rnCtMNND2ehayTPKPb1C0Ye 4KpQ0iTldagPvX9ctb4sU1pOBq3mUEK1zDnFa9868z/Gf1W95L/rQtrGPDAhW8qwP4Ww uYiRlgnnqbqzPQuZ/O3APWJG1XgTo/Mi7fKRDMUjtUDrrqRujVyCc5U0nMpiLmQ27TT4 hjV0MTE8ySbg7vIMbONcpwT8pt9WctC9mSFW++PaZRABCyTXNXgYKQTIqPbqRGIVH03k 4FNQ== X-Gm-Message-State: ALyK8tKDKDf12mKS0RyGVZpIa1waSUvuYa0L7+PW4WaD93mRzMR4YXkKGj/oLQ+xbHeOt+1OwW3xVoQPV1CyBgLN X-Received: by 10.25.19.204 with SMTP id 73mr1293285lft.24.1467131454073; Tue, 28 Jun 2016 09:30:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.147.199 with HTTP; Tue, 28 Jun 2016 09:30:53 -0700 (PDT) In-Reply-To: References: From: Peter Beverloo Date: Tue, 28 Jun 2016 17:30:53 +0100 Message-ID: To: jrconlin@mozilla.com Content-Type: multipart/alternative; boundary=001a114064f02915bd0536592960 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Composite Crypto-Key composition issue X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 16:30:59 -0000 --001a114064f02915bd0536592960 Content-Type: text/plain; charset=UTF-8 Looks like we sent an e-mail at exactly the same time[1] about the same issue, proposing the same solution :-). I've created the following GitHub issue with a proposed PR to address the issue: https://github.com/webpush-wg/webpush-encryption/issues/6 Thanks, Peter [1] https://mailarchive.ietf.org/arch/msg/webpush/UAbPwhb-_iu5Q4Ak9vE8sJKy4Ss On Tue, Jun 28, 2016 at 5:24 PM, JR Conlin wrote: > I believe there may be some confusion about how to create a composite > Crypto-Key header. > > The Crypto-Key Header is used by several supporting protocols of WebPush > (ECE, VAPID). The respective specifications state that the field uses RFCs > 7230 & 7231 where each parameter list set is divided by commas, and each > individual parameter is divided by a semicolon. > > The confusion arises in whether or not each list set should contain items > specific for a given sub-protocol. > > For instance, our autopush server treats ECE and VAPID as separate > entities and divides the set containing the dh= parameter from the set > containing p256ecdsa=. It's my understanding that FCM does not follow this > practice and will generate an error if a "," appears in the Crypto-Key > parameter lists. > > Since this is a point of confusion and conflict, I believe it would be in > the best interests of all if this was addressed in some manner so that > future conflict and confusion can be avoided. > > (For what it's worth, I really don't care what the answer is; keep > protocol parameter sets distinct to avoid potential future conflicts or > combine all parameters into one big ol' hash. Just want to prevent future > folk from swearing at us.) > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > > --001a114064f02915bd0536592960 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Looks like we sent an e-mail at exactly the same time[1] a= bout the same issue, proposing the same solution :-).

I&= #39;ve created the following GitHub issue with a proposed PR to address the= issue:

Thanks,
Peter


On Tue, Jun 28, 2016 at 5:24 PM, JR Conli= n <jconlin@mozilla.com> wrote:
I believe there may be some confusion about how to create a compo= site Crypto-Key header.

The Crypto-Key Header is used by several supporting= protocols of WebPush (ECE, VAPID). The respective specifications state tha= t the field uses RFCs 7230 & 7231 where each parameter list set is divi= ded by commas, and each individual parameter is divided by a semicolon.
=
The = confusion arises in whether or not each list set should contain items speci= fic for a given sub-protocol.

For instance, our autopush server treats ECE a= nd VAPID as separate entities and divides the set containing the dh=3D para= meter from the set containing p256ecdsa=3D. It's my understanding that = FCM does not follow this practice and will generate an error if a ",&q= uot; appears in the Crypto-Key parameter lists.

Since this is a point of co= nfusion and conflict, I believe it would be in the best interests of all if= this was addressed in some manner so that future conflict and confusion ca= n be avoided.

(For what it's worth, I really don't care what the ans= wer is; keep protocol parameter sets distinct to avoid potential future con= flicts or combine all parameters into one big ol' hash. Just want to pr= event future folk from swearing at us.)

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


--001a114064f02915bd0536592960-- From nobody Tue Jun 28 16:47:02 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECDA312D8B1 for ; Tue, 28 Jun 2016 16:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqUcszP0Olug for ; Tue, 28 Jun 2016 16:46:59 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::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 2EFCF12D8A3 for ; Tue, 28 Jun 2016 16:46:59 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id w59so16432693qtd.3 for ; Tue, 28 Jun 2016 16:46:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8ZtyaMkTSn6zhe9Rjk7bADcHtsWcNp+Y07YaaN5DCho=; b=rq+HY43kb52JPvVWk4rKTVPcr7POzK/NXcEoFBmVcBlABqsWLlEBvNMjOu9HtQsGdL f6HFeV8WdWUvvS/KvGeooLCMgDX35K+wR/K8XsaI9vneHpnjJpwqym1sal9OcKUZerW5 XHBq6rri+tP60zOHfxHggWExSzs3+YXv2KlXX7sU8yFaH0lJs+Frss5VlpDn/SmMUs6/ /zEW5xPZ9E9JgT45azFowRGK5uROdlYcQanmgo9sZNHZ2GNEfavWGfXjCIAes52dYK2T IaxaUG99F5w0daHRsWUNQFl1bWTc2AhGoGG+gOmnse/peWDt8784olOIBFwcS+4oXodL nx3A== 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; bh=8ZtyaMkTSn6zhe9Rjk7bADcHtsWcNp+Y07YaaN5DCho=; b=gGlBJT1qgA9bMfKjI/W1KF9SODCaOFy20P19aoCQNPHqTqv9srmT64kVhejKsl0Ofa ika9zCBsYed6uzUsjcmK1vPOzNLaYe5s+n5WkUta8NZXWtXtVaC0EK5Kxj8WL1D80p+S YNo7Bu+oZZqxDHUWcGaoHQdmHQxdFQUekLZsbFh5YoDkeybqOPl1S8DAR91/bEBhpMiZ 7MeASS8ZYksDR2pTenHwp25jIrQnuVs/I+h6fGPpBPi9eq3sujE7ykmCdKrsveiSnMVn y3rIValWwHYIpQEUuviePu0MmR4JL/DqBOKrlNslOHhM2CO2meLpmJv5pKtgTCDLga83 kWVw== X-Gm-Message-State: ALyK8tL+AHrdWRM9wSjHAyv+17uMCu0Z3vAauzDtYB131VBIw+MO+f8u7zSLDBLvIAz3ljMbgVOWK1aiB8OdNQ== X-Received: by 10.200.44.136 with SMTP id 8mr7543335qtw.18.1467157618290; Tue, 28 Jun 2016 16:46:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.38 with HTTP; Tue, 28 Jun 2016 16:46:57 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Wed, 29 Jun 2016 09:46:57 +1000 Message-ID: To: Peter Beverloo Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Too strict Crypto-Key restriction imposed by webpush-encryption X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 23:47:01 -0000 On 29 June 2016 at 02:24, Peter Beverloo wrote: > I've detailed the issue in the following GitHub issue, with an accompanying > pull request relaxing the restriction to a maximum of one Crypto-Key field > having the `dh` parameter: > > https://github.com/webpush-wg/webpush-encryption/issues/6 Which I have merged, since the intent was to limit the number of 'dh' parameters to 1, not to prevent vapid from being used properly.. From nobody Wed Jun 29 18:37:41 2016 Return-Path: X-Original-To: webpush@ietf.org Delivered-To: webpush@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6695E12D8AA; Wed, 29 Jun 2016 18:37:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160630013736.30404.82854.idtracker@ietfa.amsl.com> Date: Wed, 29 Jun 2016 18:37:36 -0700 Archived-At: Cc: webpush@ietf.org Subject: [Webpush] I-D Action: draft-ietf-webpush-vapid-01.txt X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 01:37:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web-Based Push Notifications of the IETF. Title : Voluntary Application Server Identification for Web Push Authors : Martin Thomson Peter Beverloo Filename : draft-ietf-webpush-vapid-01.txt Pages : 11 Date : 2016-06-29 Abstract: An application server can voluntarily identify itself to a push service using the described technique. This identification information can be used by the push service to attribute requests that are made by the same application server to a single entity. This can used to reduce the secrecy for push subscription URLs by being able to restrict subscriptions to a specific application server. An application server is further able to include additional information that the operator of a push service can use to contact the operator of the application server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-webpush-vapid/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-webpush-vapid-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-webpush-vapid-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 29 18:44:36 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD8212D1EA for ; Wed, 29 Jun 2016 18:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AenbrkelrALk for ; Wed, 29 Jun 2016 18:44:32 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 262DB12B04D for ; Wed, 29 Jun 2016 18:44:32 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id o76so6583813qke.0 for ; Wed, 29 Jun 2016 18:44:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=QuTQei25ShtAQmFBXQiKnLsnTkous14Hiy9KWWNwmpQ=; b=j7EGEaAHi87HkS0vlEAIC849N/uBDLCNHpbHrlacvnp0NmtE1Jgae8Ly72Af/QcPei weNbZbE/s6ZmevFZEBQosC3BrNZ78+Xvc8zJCjcU2/AYlmFKiZ4bUUDttOI0Mw/OAvBk xjPZptUIGxkb5AfDdaTxoklsK5v+ZypjLeU5IJjTZgJJ/iiC3rKUAQQaiMXtKEDJj2uw jRpsJkyniU92MybYqZqp0yl4jPqVFEZ+juiPJOwoxITKTHGOUJrT14OAHp8EeiADa5J6 3+dZzyCB3aqIJcbirehaOrmZ/oJ0SxHJVgDBvT75Zi1ii6w89PPoqc7gpE1QAF3N7sGa G9/Q== 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; bh=QuTQei25ShtAQmFBXQiKnLsnTkous14Hiy9KWWNwmpQ=; b=IHJySX8mZquckRSTPWeXx1AbgdLvwF+2gJ0gygSjcPPA8cENc9pbwv42dDopoq/cNz ApomW6u7KITsZ+RquaUuiAJ99/pAbcjk455hCoomh+EKJkZR9PGeiUIY0mjzobgS0vYf HkPfO/ORQ2EThri3KJQ6hJfvN9cUysJusT0Oeahi6enl9hanCaV/xLF7CqydeK8FwLeC LJfnXs1jhkrc9s98cSTNkpW3GDAN29Bntxn1XSCqNMlVW5k1NKxyXXZaW9toQYyCTPzY kPuOC9KqddNBlmCUXF/73OV+tHwJNpRxbmxKf3JwM/UQom5LJ9fPsSnXfGXINBFwSrTA hf7Q== X-Gm-Message-State: ALyK8tKoX6rt5dsr0Xq24h44ZoPoiiIufkIDjGXM25gWhvzCeWak3t9oGXs1UyHNiMn97teAOZ/jOLZQOytMEA== X-Received: by 10.55.78.16 with SMTP id c16mr15672704qkb.48.1467251070977; Wed, 29 Jun 2016 18:44:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.38 with HTTP; Wed, 29 Jun 2016 18:44:30 -0700 (PDT) In-Reply-To: <20160630013736.30404.82854.idtracker@ietfa.amsl.com> References: <20160630013736.30404.82854.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Thu, 30 Jun 2016 11:44:30 +1000 Message-ID: To: "webpush@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Webpush] I-D Action: draft-ietf-webpush-vapid-01.txt X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 01:44:34 -0000 This is just to ensure that the I-D archive has the latest and best version of the draft. Since the -00 version we've cleaned up a bunch of minor nits, but the draft is still pretty much the same. Note that I haven't addressed the newly opened issue 23 [1]. I hope that it's just a matter of some confusion on the part of someone (me probably). [1] https://github.com/webpush-wg/webpush-vapid/issues/23 On 30 June 2016 at 11:37, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Web-Based Push Notifications of the IETF. > > Title : Voluntary Application Server Identification for Web Push > Authors : Martin Thomson > Peter Beverloo > Filename : draft-ietf-webpush-vapid-01.txt > Pages : 11 > Date : 2016-06-29 > > Abstract: > An application server can voluntarily identify itself to a push > service using the described technique. This identification > information can be used by the push service to attribute requests > that are made by the same application server to a single entity. > This can used to reduce the secrecy for push subscription URLs by > being able to restrict subscriptions to a specific application > server. An application server is further able to include additional > information that the operator of a push service can use to contact > the operator of the application server. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-webpush-vapid/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-webpush-vapid-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-webpush-vapid-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush From nobody Wed Jun 29 23:00:17 2016 Return-Path: X-Original-To: webpush@ietf.org Delivered-To: webpush@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD8F12D190; Wed, 29 Jun 2016 23:00:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160630060016.30479.84646.idtracker@ietfa.amsl.com> Date: Wed, 29 Jun 2016 23:00:16 -0700 Archived-At: Cc: webpush@ietf.org Subject: [Webpush] I-D Action: draft-ietf-webpush-encryption-03.txt X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 06:00:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web-Based Push Notifications of the IETF. Title : Message Encryption for Web Push Author : Martin Thomson Filename : draft-ietf-webpush-encryption-03.txt Pages : 8 Date : 2016-06-29 Abstract: A message encryption scheme is described for the Web Push protocol. This scheme provides confidentiality and integrity for messages sent from an Application Server to a User Agent. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-webpush-encryption/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-webpush-encryption-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-webpush-encryption-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 29 23:01:08 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3276312D9CF for ; Wed, 29 Jun 2016 23:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4bmFi9MpWGo for ; Wed, 29 Jun 2016 23:01:04 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EA0512DA07 for ; Wed, 29 Jun 2016 23:01:04 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id o76so13735797qke.0 for ; Wed, 29 Jun 2016 23:01:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=zC5mldobIwkwGacJIBpBHznAo9N7FrMeJWFPqbOOB2E=; b=HNqQ0q5MqAsXM35Y9Uz95/Ygb437Z4ur/gKXMv5ZuVtVPYE9NGsjurs6ePolJHFa2o qrDfsXox8XsuK3e6q9G65SwrJbhnv0MueD2II0VdNY1dpkxZfsQWe07jvWPEpvbcifPs 0pfS9DJwfeRvZOwh26kGwyWQdeRngahgW1XB3b4xK8B+aFeTTOnTMWUiYUJrh89G0Zh0 lFBCVDYIO77I6QOR93+4D57p1TQ5O3z6OV4c8IeWtlbPzRvpIlwS6st7LKV7YWaZCo6f 55lnZpgXZefCi5QH5JEtkK2ZvHfeZA/AZhNKtsNvjYdn+GXAFWsc7Dzn64Vb30z8eJ9I oELQ== 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; bh=zC5mldobIwkwGacJIBpBHznAo9N7FrMeJWFPqbOOB2E=; b=g8pUviQ7clZqTCOfbGMKxI8nUzz5uJUDlcXu3MhLcJB6W3gkGCqM9bO6emTW+GwsMK 0H3QqsLXnYDc7ZlU/W4yK/RhmhEM1hnsKByGgHHlDwUBS/xirJeeeofVIo33bORLiy/5 TqYcWEUdXlkB32jQjCCpKmZwcm4e8sjG/VXNcGdIR4yMnh3RUadZULBXlxxAd9s0keG0 TkyZ09B4S9oquACu6/5qJLayoc+O0vt497gh8AnVJw7G8sIx/5hKIH2bw5UlrIjOwqBo /S4viv98i9i7lUEu0FP7Qu392JuQ/wCod+ygauu3Y79KpZOGWSC7hgbgg6OsdtaC3EUs zO+A== X-Gm-Message-State: ALyK8tIziet1bDTvOPmg0LXNohfK97R8aW2qI8/C6w1MsTYESm7OiC6vkFlMxYiCTSLER9TPXzG6JUw2V5nIIg== X-Received: by 10.55.203.73 with SMTP id d70mr16863585qkj.116.1467266462872; Wed, 29 Jun 2016 23:01:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.38 with HTTP; Wed, 29 Jun 2016 23:01:02 -0700 (PDT) In-Reply-To: <20160630060016.30479.84646.idtracker@ietfa.amsl.com> References: <20160630060016.30479.84646.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Thu, 30 Jun 2016 16:01:02 +1000 Message-ID: To: "webpush@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Webpush] I-D Action: draft-ietf-webpush-encryption-03.txt X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 06:01:06 -0000 Only very minor changes in this one. On 30 June 2016 at 16:00, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Web-Based Push Notifications of the IETF. > > Title : Message Encryption for Web Push > Author : Martin Thomson > Filename : draft-ietf-webpush-encryption-03.txt > Pages : 8 > Date : 2016-06-29 > > Abstract: > A message encryption scheme is described for the Web Push protocol. > This scheme provides confidentiality and integrity for messages sent > from an Application Server to a User Agent. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-webpush-encryption/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-webpush-encryption-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-webpush-encryption-03 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush From nobody Thu Jun 30 19:03:03 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1397E12D0B4 for ; Thu, 30 Jun 2016 19:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3s8kfoXD-ZIE for ; Thu, 30 Jun 2016 19:02:59 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::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 9FE2B12D098 for ; Thu, 30 Jun 2016 19:02:59 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id o76so65659074qke.0 for ; Thu, 30 Jun 2016 19:02:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=2HIcFJUP5IJYam/DoJTM6BXBS+ksNCEeD96+csHGKtQ=; b=STGrOOp91HX47Q/BWjB19IgVdi2tdYKPd7bKd1FY6RvtXBPRFRtgB1PzBLLJ8/4ZYx 4I7uTACFCY+NaAQQSIq4Fv9eHbDf3b4i9rcUf3Cz17HzddU1Vv8ETJ8q09GpIVXV4HHt Xr7cZVjUsyAt9n9aLZ1wexAoZEJZ3W721kUtOxXV9zs4jAZjyNhyIrX09gbWJNawq5eM xt1jwi0AQweCKe/Ak1UscnJq6aRj1yGJ7Bq5efUDS5MCUBHH+9DAENUj+xNFTauDk1yv okoAvU1DpIGSUGEICdS4qgcBvU+PEFZ7KrW6opj5Tv/cNuGDMcS36JzpEdQFAfgjdN3N 3b3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=2HIcFJUP5IJYam/DoJTM6BXBS+ksNCEeD96+csHGKtQ=; b=iZtCKyZAqmdloj2RC7Z0Rz3iw0067jZBBSHg4cY9I6yxOoRML+uBFNv5FImU395bLs XZ4ZlApeY3jR88Qb3Qs0qFPReIHDnkW/OQSq0XmHugXeySZqo20wLbsuxAszwRQCcGgw aQ0uQLuzl6+LaMJ8CO3TRQFmRwAbyXOXp3raOPHt+V5q1m7oqMBrQB4o8PrHK2FHKIeS 2BPGBMTidPA4oYv9xD77klHPC0ZRIQVGjR7VEGcp6hcIJR4EAVJbpY0eDyNDUwul1PL0 TIoSIh0IT5spheVRgE4K8KKIKgoXwvM3sztHwoWLi8rK3JFUycIjKHNQQ7bXzXLGkgfP r+Kg== X-Gm-Message-State: ALyK8tIkaHewpqh3W5nNsE0hgc5yvtQXnLV654TB6kBDOMWbWMkyF//otAsIuwr2tXkG4eIpC+be4YKD1pwnqw== X-Received: by 10.55.201.70 with SMTP id q67mr22486301qki.124.1467338578454; Thu, 30 Jun 2016 19:02:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.38 with HTTP; Thu, 30 Jun 2016 19:02:57 -0700 (PDT) From: Martin Thomson Date: Fri, 1 Jul 2016 12:02:57 +1000 Message-ID: To: "webpush@ietf.org" , JR Conlin Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Webpush] vapid issue 24: supplementary data in tokens X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 02:03:02 -0000 JR requests that we allow the inclusion of extra stuff in a vapid token: https://github.com/webpush-wg/webpush-vapid/issues/24 >>> As noted in the arguments of #23, there is a need for an "extra data" field which would be used by the parties using the VAPID claims. This data would contain information useful to the publisher of the claim (e.g. the originating server ID, transaction ID, or other possibly VAPID consumer opaque data). This extra data ("vapid-ext" ?) field would allow consistent, predictable definition rather than a set of 'one-offs' that may be difficult to find or ignored by operators. <<< I think that the general idea is fine. Better this than trying to pack the "sub" field with extra stuff. JR, would it suffice to point out that the [private](https://tools.ietf.org/html/rfc7519#section-4.3) (or even [public](https://tools.ietf.org/html/rfc7519#section-4.2)) claims can be added to the token? Allowing multiple fields gives the application server a fair bit more flexibility. If that's OK, we should point out that this is possible so that push services don't lose the extra data because they aren't aware that it might exist.