From nobody Tue Sep 13 10:12:26 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 3BC6412B400; Tue, 13 Sep 2016 10:12:25 -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.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147378674523.23612.14162905560596940196.idtracker@ietfa.amsl.com> Date: Tue, 13 Sep 2016 10:12:25 -0700 Archived-At: Cc: webpush@ietf.org Subject: [Webpush] I-D Action: draft-ietf-webpush-protocol-09.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: Tue, 13 Sep 2016 17:12:25 -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-09.txt Pages : 31 Date : 2016-09-13 Abstract: A simple protocol for the delivery of real-time 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-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-webpush-protocol-09 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 Tue Sep 13 10:16: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 AD97612B425 for ; Tue, 13 Sep 2016 10:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 4MQBNLYwEwG0 for ; Tue, 13 Sep 2016 10:16:29 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0107.outbound.protection.outlook.com [104.47.34.107]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F37B912B41D for ; Tue, 13 Sep 2016 10:16:28 -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=3wWQ0V5iA4JXRbdv8Vq4zEJBg91GTNwXZ2vgSw2KoUY=; b=XAQwCLOy2dMPu+0auArg6tEgOTMKE2lrjHQo8GYXBdqtagn49z+w1vfpQOGQT7DA0iFktIOtM238tn3pb4sF684VEUPZF2NzDYPmmyEC7Uc+niMGKwiYTe6Aq6lMY63S1+r7fDfFebLXyjy05qvU6SVPgMTzfLltbuzClsxNfrk= Received: from CY1PR03MB2380.namprd03.prod.outlook.com (10.167.8.6) by CY1PR03MB2377.namprd03.prod.outlook.com (10.166.207.152) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.619.10; Tue, 13 Sep 2016 17:16:26 +0000 Received: from CY1PR03MB2380.namprd03.prod.outlook.com ([10.167.8.6]) by CY1PR03MB2380.namprd03.prod.outlook.com ([10.167.8.6]) with mapi id 15.01.0619.011; Tue, 13 Sep 2016 17:16:26 +0000 From: Brian Raymor To: "webpush@ietf.org" Thread-Topic: [Webpush] I-D Action: draft-ietf-webpush-protocol-09.txt Thread-Index: AQHSDeICj1HZVtBEnkedbXUj7oJcu6B3qNaw Date: Tue, 13 Sep 2016 17:16:26 +0000 Message-ID: References: <147378674523.23612.14162905560596940196.idtracker@ietfa.amsl.com> In-Reply-To: <147378674523.23612.14162905560596940196.idtracker@ietfa.amsl.com> 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: [174.61.159.182] x-ms-office365-filtering-correlation-id: da2fa20e-62f9-4e7e-ade0-08d3dbf9b1f9 x-microsoft-exchange-diagnostics: 1; CY1PR03MB2377; 6:+XhVSZkisVFdQmA34BPU8IKxxZxcDTHD7wT/41uU8TFBQAAmNPjhSFKTD/LiGQGsDTa1/v4JICTz5X8vsXvToeu8dwQhR6VNhT3aQBLR/ElpqKccCjpTDLxtT4/dlSdZZ5xhrLpjS+PW3Chd+Fm2iC23bIMizqk8YxTmGoQpfkosDusWeA8KA8yDWaBp8Z+kUDB9vGFmhqsYNNT6pxeri1yv4ZDPFHBMRk39aXeqSwfx5bG2QdymhXEcdviBs6y8k4dyoAfU1Frtgj++xeM12K5sPGTWFnEersGqiAQIfBeEE1zJqmtquROR7PS6TS3Uil3YJHIKDYFv24gC4KhsTw==; 5:t+mVAfdxMV8GMz9b5sBHcXYUjrIGzZwf/Am5lMDW4eEj8yHfZwezeyMDrC08F3YTh8vbUutQ+UMRZKsk4u/Ar71cEcjnQamziHBmxzJ2q1AplbWVCB8njuzbLLBHW5Jq4woSFtm6uwShXEVaMGriMA==; 24:UJjbvHrAKf/0oWmlFRYuFYtkH+qt8x6ZY77Un10yEffUxQCS1v9epOWkDvYtm1CmN2iy6R3xiTHvXrqetfb3nBJcRL8RwF0+XZvimGhhIb8=; 7:5qVQW7w1GeFoebx3PB11ctBwSMOHwkkzVOT6V6H1k2t6Op5ARBF6IEznU7cS/AQ7IxVKb7keY2gvrBelXzdafPTfyAU8a19DUQyQRCkKnCWhe+lb2gL3wyUBhA3jXH0KAigIWnwp29Xo5OlQE0sPnr667vVnVAWoQYvEBdRe591+P0vP6pdTCnQ6BahycggBcCjOgLvptfkJ5MjCnlrav5D/iYFqfCBmgXFaeJX6r0L5rPTKDmEUKQPO0tqkoPXK x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2377; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2377; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2377; x-forefront-prvs: 0064B3273C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(377454003)(54534003)(13464003)(199003)(377424004)(6116002)(7736002)(19580405001)(450100001)(7846002)(68736007)(5640700001)(189998001)(586003)(3846002)(102836003)(8676002)(19580395003)(11100500001)(230783001)(5002640100001)(122556002)(110136003)(81166006)(87936001)(5660300001)(9686002)(76576001)(81156014)(1730700003)(8936002)(7696004)(305945005)(10400500002)(99286002)(86612001)(33656002)(107886002)(3280700002)(92566002)(3660700001)(97736004)(66066001)(2351001)(2950100001)(74316002)(106356001)(106116001)(86362001)(105586002)(77096005)(54356999)(5005710100001)(8990500004)(10090500001)(76176999)(2501003)(2900100001)(10290500002)(50986999)(101416001)(2906002)(15975445007); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2377; H:CY1PR03MB2380.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: 13 Sep 2016 17:16:26.7230 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2377 Archived-At: Subject: Re: [Webpush] I-D Action: draft-ietf-webpush-protocol-09.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: Tue, 13 Sep 2016 17:16:32 -0000 As noted in the change log, -09 consists of minor edits to Acknowledgements= and Informative References. -----Original Message----- From: Webpush [mailto:webpush-bounces@ietf.org] On Behalf Of internet-draft= s@ietf.org Sent: Tuesday, September 13, 2016 10:12 AM To: i-d-announce@ietf.org Cc: webpush@ietf.org Subject: [Webpush] I-D Action: draft-ietf-webpush-protocol-09.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. 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-09.txt Pages : 31 Date : 2016-09-13 Abstract: A simple protocol for the delivery of real-time 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-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-webpush-protocol-09 Please note that it may take a couple of minutes from the time of submissio= n 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 Sep 21 20:25: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 9BA5312B618 for ; Wed, 21 Sep 2016 20:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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_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=gwPdp8B+; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=JnYXmO/H 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 OMjt3pBJ4osk for ; Wed, 21 Sep 2016 20:25:38 -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 7765C12B280 for ; Wed, 21 Sep 2016 20:25:38 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 710802063D for ; Wed, 21 Sep 2016 23:25:35 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Wed, 21 Sep 2016 23:25:35 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=6kb gmaXPPhvaFReFBs31vSbVRmQ=; b=gwPdp8B+3LhGqcFB89iAK2nsOnqACvBssAF ySQ+PXihSxbyzBo7u3AV0L79yMH31Q61D5uQOrkcQgUjvMhPFVDw5EUCPTxRk3rV 0tEcedRRfpTzVZ1ZEZvN26+SIzjdzkMg7yYHzybi8YJb1AQwSLGx7PitM5JI9xzu aUiGvN8E= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=6kbgmaXPPhvaFReFBs31vSbVRmQ=; b=JnYXm O/HN7M1sniKUcu5l6+xbrPNMurAOqQBjxwbg7XszTP5G8pDsg0XzsJBAENb1+PBu J9Zbncv+MWb1j060xMGS/dQOB4/RNj1QhsqdBOMplFdzkW32U2rlVTk0Bse4xntv NTCAQoMnsM/uvg7ONMLHfW0F4XTZmVHdzLp8f4= X-Sasl-enc: N/xDUATM999sin97W0CSSMfze7KbC567Kd7Yc5Ws3nID 1474514735 Received: from sjc-alcoop-8812.cisco.com (unknown [128.107.241.182]) by mail.messagingengine.com (Postfix) with ESMTPA id DDDCBF2985 for ; Wed, 21 Sep 2016 23:25:34 -0400 (EDT) From: Alissa Cooper Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <1E66EFF9-A0B5-4BB5-8F1D-0ABABBB3C353@cooperw.in> Date: Wed, 21 Sep 2016 23:25:33 -0400 To: webpush@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [Webpush] AD evaluation: draft-ietf-webpush-protocol-09 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, 22 Sep 2016 03:25:40 -0000 I have reviewed this document in preparation for IETF last call. It is = almost ready to go. I have a few comments below. Once these are resolved = and a rev published, I will request publication. =3D Shepherd write-up =3D RFC 2818 is in the downref registry already. That is the only = explanation necessary for the downref. =3D Section 5.3 =3D I'm assuming the application scenarios listed in the table are = illustrative since they do not cover every possible application. It = would be good to note that. =3D Section 5.4 =3D "Delivery receipts for the deleted message SHOULD be suppressed." Why is this a SHOULD rather than a MUST? It seems incorrect in all cases = to send a delivery receipt for a message that never gets delivered. =3D Section 8 =3D I think the first paragraph should include a normative recommendation to = follow the guidance in RFC 7525 for use of TLS. =3D Section 8.2 =3D I think it would be useful to acknowledge in this section that while = correlation using push URIs can be limited in the various ways = described, correlation based on other information exposed by user agents = may still be possible. =3D Section 9.3 =3D The Contact should be IETF Chair (per RFC 6335).= From nobody Thu Sep 22 21:54: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 37B0012B781 for ; Thu, 22 Sep 2016 21:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 B0bspzhbTeMU for ; Thu, 22 Sep 2016 21:54:10 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::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 B777B12B8E0 for ; Thu, 22 Sep 2016 21:54:10 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id 93so47785054qtg.2 for ; Thu, 22 Sep 2016 21:54:10 -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=qZ/Xm/vA7k3oLumfDY27zNuYIOx0NYULB3u87CnUREQ=; b=i+e0Z9/SINjOhAQdMXC94NLh5AfQnGUrymOZl9h/+j3vjGyIFTZYoEU8jUo9MJncGh wkbbFWUZEMdzkoWHAt6T0oA6oGNkmGbMk62FqmZZqMGjfxODfEmZp85jN4f2iCsycgPe ob1lPBgpj6LWS0sbxH4vegAHwDEw/jOChKxJgIRoElDYCLCdU4ymnkZRC0/ZRxg2R3pJ 5DXgrbk/aonyZYT8FZUdv1Q9ftBSq5icvPH7M052na/PmOXLqI36W3L1GODhG3YK0Pyo 2AY+wQ32XerBiRaxAzkhIbzdZQ5gowI/eTQgWPSHs5zvL8gdItyLU0+ncNuuFt3a9HpL 9qYw== 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=qZ/Xm/vA7k3oLumfDY27zNuYIOx0NYULB3u87CnUREQ=; b=ZrDGSCULFHrR7yF3BkwPMe0MDPplZIWoPOht4pT6aOQPQPZ1+dMy2HoE/Af1NLjV17 SU3JMEm8nWyjOXpsFedXiHSis874MMG7GJxpACUM0Dx/9876y0nX78ErrPjFrqbjW2L8 Q8RPrjAEzLhV4FPNwA2EeEd5iicRiHTkxQvtnB6BbbmtW2EPvN5bjM4nKbX3w2nXK2/5 grbtLfix4Qw5fKy0yzfMN/aXwcH6sYFSSwGH4KSF+tFiq1LWIODxBh+uCN0lbUywcT2M ObuXL987poCwBFy0eTiMQXkQoKVJJbYxzztLxdopNzX+At69Ovaclg97lqSYN57Y5fXT YySA== X-Gm-Message-State: AA6/9RkyPKd20Mp2OYKagVk84I0v6RZIzo3ohO6fEwjwNXuhDlf5oFuZ4RWrlB9KLHDtC9kP9NZFXvu0e6uUvA== X-Received: by 10.237.45.39 with SMTP id h36mr5890269qtd.155.1474606449877; Thu, 22 Sep 2016 21:54:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Thu, 22 Sep 2016 21:54:09 -0700 (PDT) In-Reply-To: <1E66EFF9-A0B5-4BB5-8F1D-0ABABBB3C353@cooperw.in> References: <1E66EFF9-A0B5-4BB5-8F1D-0ABABBB3C353@cooperw.in> From: Martin Thomson Date: Fri, 23 Sep 2016 14:54:09 +1000 Message-ID: To: Alissa Cooper Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] AD evaluation: draft-ietf-webpush-protocol-09 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, 23 Sep 2016 04:54:12 -0000 Thanks for reviewing Alissa, The other comments look like they have mechanical fixes. We will get to that. On 22 September 2016 at 13:25, Alissa Cooper wrote: > = Section 5.4 = > > "Delivery receipts for the deleted message > SHOULD be suppressed." > > Why is this a SHOULD rather than a MUST? It seems incorrect in all cases to send a delivery receipt for a message that never gets delivered. I realize that this is actually too short to be comprehensible. What I think that this was trying to capture was that sometimes replaced messages might be delivered successfully, but the acknowledgment might be still in transit toward the server. That acknowledgement could trigger a delivery receipt. This recommends that receipts be suppressed in this case. They might not be given the distributed nature of the push service. (Acknowledgments might be handled in a stateless fashion, and checking that a replacement has occurred can be expensive; preventing the race adds cost and latency also.) >>> A push message replacement request creates a new push message resource and simultaneously deletes any existing message resource that has a matching topic. If an attempt was made to deliver the deleted push message, an acknowledgment could arrive at the push service after the push message has been replaced. Delivery receipts for such deleted messages SHOULD be suppressed. <<< From nobody Sun Sep 25 21:48: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 67BE012B077 for ; Sun, 25 Sep 2016 21:48:40 -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 M5kc2Iz4pSJv for ; Sun, 25 Sep 2016 21:48:38 -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 8EB9312B069 for ; Sun, 25 Sep 2016 21:48:38 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id n185so153728243qke.1 for ; Sun, 25 Sep 2016 21:48:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rc6LdD2NCc+pRNjOUHpmcLpKiy2tdhJKCzYws2uz/PE=; b=HiQjr2SHcRwTCsLIjMkMqPaGV7KJBLMk61doaRcmOtht8sVf6rci+Qa/uWeSB0TCxg SxuwQwYsPQITorz3MOncEi9iF3SCbgKxdrEHFAIerQ5TCsLLTiU6DR0w6ftCehCEfOqM 5Q4gyTTiYg863a9epgK/PKdtis7SzodQfLylneDRrbogghQ0t1Q+s/ZQwLaGJft8nv0j zHYzWltlvgmuyAxpCoqkJrvLCbAEhtKRQNbbRVsOWldvIRzOfI3kQvBixeHH5tVyOoY4 mv736C82ePDj44oYg10w9gG3CDKhSdBhzazlRAV+LRmz8+Gri+KLJXLbeJxIVvHFn8V/ AIXw== 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=rc6LdD2NCc+pRNjOUHpmcLpKiy2tdhJKCzYws2uz/PE=; b=DADBEiM01dqGtVBbOZwJJWpVaKLicII7P3RdyFg9pm0dZJ5SbbVNrlCe38DWnLTfb4 xaseEF70FXxhMvOULjlrxSrVAqSyYbygR+jhSJSsAJtZAvjPkqxqrR2PFWe4UwG2aKI2 RYpyuF4iV7QcS8SufH2ZVXosE4sZZdzwhlnHEbRPzI9CBSzGkzlUjct+5tIET3Kue81c bbfLPQwETCwFa5FvvT8dYFSw7wodJCVtQkaOdQAldCwJSykOrEfJtkcNBAA9rMsC26Ip xKrOZPWBZV4hYyf5+xP04UeRokWW9VNAiBUnQrO3udqjZQUs69n4i/HDWFLo3eSc/SQx 42ag== X-Gm-Message-State: AA6/9Rm3oBrKmF/WMi+p4pgQb5EHHKPpFfCyJYpNHxCpB2SmT3x568gygwuEiHEh+kxDPmq2jiy6JDeSDRu07w== X-Received: by 10.55.113.197 with SMTP id m188mr19324715qkc.55.1474865317613; Sun, 25 Sep 2016 21:48:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Sun, 25 Sep 2016 21:48:37 -0700 (PDT) In-Reply-To: References: <1E66EFF9-A0B5-4BB5-8F1D-0ABABBB3C353@cooperw.in> From: Martin Thomson Date: Mon, 26 Sep 2016 14:48:37 +1000 Message-ID: To: Alissa Cooper Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] AD evaluation: draft-ietf-webpush-protocol-09 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, 26 Sep 2016 04:48:40 -0000 I've create a pull request that includes the text below, plus fixes to the other identified issues: https://github.com/webpush-wg/webpush-protocol/pull/128 Preview at: https://webpush-wg.github.io/webpush-protocol/alissa_review/ On 23 September 2016 at 14:54, Martin Thomson wrote: > Thanks for reviewing Alissa, > > The other comments look like they have mechanical fixes. We will get to that. > > On 22 September 2016 at 13:25, Alissa Cooper wrote: >> = Section 5.4 = >> >> "Delivery receipts for the deleted message >> SHOULD be suppressed." >> >> Why is this a SHOULD rather than a MUST? It seems incorrect in all cases to send a delivery receipt for a message that never gets delivered. > > I realize that this is actually too short to be comprehensible. What > I think that this was trying to capture was that sometimes replaced > messages might be delivered successfully, but the acknowledgment might > be still in transit toward the server. That acknowledgement could > trigger a delivery receipt. > > This recommends that receipts be suppressed in this case. They might > not be given the distributed nature of the push service. > (Acknowledgments might be handled in a stateless fashion, and checking > that a replacement has occurred can be expensive; preventing the race > adds cost and latency also.) > >>>> > A push message replacement request creates a new push message resource > and simultaneously deletes any existing message resource that has a > matching topic. If an attempt was made to deliver the deleted push > message, an acknowledgment could arrive at the push service after the > push message has been replaced. Delivery receipts for such deleted > messages SHOULD be suppressed. > <<< From nobody Mon Sep 26 10:50: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 9437E12B26A for ; Mon, 26 Sep 2016 10:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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_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=f5TEBEmf; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=ocxUBkZ2 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 gM20s-KvSIKO for ; Mon, 26 Sep 2016 10:50:03 -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 D460912B31C for ; Mon, 26 Sep 2016 10:50:01 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 6D99D2054B; Mon, 26 Sep 2016 13:50:00 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 26 Sep 2016 13:50:00 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=yROalsnLCLkhZoFh9y4Uc+NhLHU=; b=f5TEBE mfu82F3na0RXsWrwwqdbgnOqLLUmlvAbuZt+1AekrBD+qFbB1h6pLrmvSuw4ZJjV iIqQ4beFafuDhuY9KAlk+heycE7rHnBb+ko3G9Jkzr5GeuDvY0l1AxVQd5GKdYbQ tKZ861h4osmq21llOXVK7sWoMwXv612t2k8aM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=yROalsnLCLkhZoF h9y4Uc+NhLHU=; b=ocxUBkZ2n/axfyczxuRY5RY8snbb2CXdagKDWP7/hEhGr64 YhUc0RgU6QOJtqd23R8OGE7Lvh3S0gdipqt3H9QMLjEqIRe4kz5Ai/XyNMtI2okS wycxwRY0pErOV/UjLpiKHeIShj18vQBAhB+Qg8bIrh6fF/N0nrKDEpIQB088= X-Sasl-enc: aJyKOMzyxRF8J/iuYa1Vs4mACIgTWuSG5wG2E1YRPPWq 1474912200 Received: from dhcp-10-150-9-154.cisco.com (unknown [173.38.117.90]) by mail.messagingengine.com (Postfix) with ESMTPA id 1E977CCEAB; Mon, 26 Sep 2016 13:50:00 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: Date: Mon, 26 Sep 2016 13:49:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1E66EFF9-A0B5-4BB5-8F1D-0ABABBB3C353@cooperw.in> To: Martin Thomson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] AD evaluation: draft-ietf-webpush-protocol-09 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, 26 Sep 2016 17:50:04 -0000 LGTM > On Sep 26, 2016, at 12:48 AM, Martin Thomson = wrote: >=20 > I've create a pull request that includes the text below, plus fixes to > the other identified issues: >=20 > https://github.com/webpush-wg/webpush-protocol/pull/128 >=20 > Preview at: = https://webpush-wg.github.io/webpush-protocol/alissa_review/ >=20 > On 23 September 2016 at 14:54, Martin Thomson = wrote: >> Thanks for reviewing Alissa, >>=20 >> The other comments look like they have mechanical fixes. We will get = to that. >>=20 >> On 22 September 2016 at 13:25, Alissa Cooper = wrote: >>> =3D Section 5.4 =3D >>>=20 >>> "Delivery receipts for the deleted message >>> SHOULD be suppressed." >>>=20 >>> Why is this a SHOULD rather than a MUST? It seems incorrect in all = cases to send a delivery receipt for a message that never gets = delivered. >>=20 >> I realize that this is actually too short to be comprehensible. What >> I think that this was trying to capture was that sometimes replaced >> messages might be delivered successfully, but the acknowledgment = might >> be still in transit toward the server. That acknowledgement could >> trigger a delivery receipt. >>=20 >> This recommends that receipts be suppressed in this case. They might >> not be given the distributed nature of the push service. >> (Acknowledgments might be handled in a stateless fashion, and = checking >> that a replacement has occurred can be expensive; preventing the race >> adds cost and latency also.) >>=20 >>>>>=20 >> A push message replacement request creates a new push message = resource >> and simultaneously deletes any existing message resource that has a >> matching topic. If an attempt was made to deliver the deleted push >> message, an acknowledgment could arrive at the push service after the >> push message has been replaced. Delivery receipts for such deleted >> messages SHOULD be suppressed. >> <<< From nobody Mon Sep 26 14:52:58 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 5961412B2FF; Mon, 26 Sep 2016 14:52:52 -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.34.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147492677236.5096.12731347179818596664.idtracker@ietfa.amsl.com> Date: Mon, 26 Sep 2016 14:52:52 -0700 Archived-At: Cc: webpush@ietf.org Subject: [Webpush] I-D Action: draft-ietf-webpush-protocol-10.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: Mon, 26 Sep 2016 21:52:52 -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-10.txt Pages : 33 Date : 2016-09-26 Abstract: A simple protocol for the delivery of real-time 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-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-webpush-protocol-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 26 14:54: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 7980612B350 for ; Mon, 26 Sep 2016 14:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 q9NBE2OyqntV for ; Mon, 26 Sep 2016 14:54:32 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0099.outbound.protection.outlook.com [104.47.42.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BA1712B2AC for ; Mon, 26 Sep 2016 14:54:31 -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=W97+R7bD7OYngzlfVYgmH/86ZOzMtyMW9yiW5XG/haU=; b=Dsp1pKGth3z689eXdq94gbdHYvT4gDbSvg6ndThrPEZfcUfTN+exiiLkU35NyvxWKnRbORqmOI97Oww8Cw73eV3zolssH9XwbgUAGomqpW0TTZ5WIk/4zgiqj33DfeRG89lG1XigzjjR3I7fPF1DahITUMWpm8g/PAkOQeqCt1Y= Received: from CY1PR03MB2380.namprd03.prod.outlook.com (10.167.8.6) by CY1PR03MB2379.namprd03.prod.outlook.com (10.166.207.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.639.5; Mon, 26 Sep 2016 21:54:30 +0000 Received: from CY1PR03MB2380.namprd03.prod.outlook.com ([10.167.8.6]) by CY1PR03MB2380.namprd03.prod.outlook.com ([10.167.8.6]) with mapi id 15.01.0629.018; Mon, 26 Sep 2016 21:54:30 +0000 From: Brian Raymor To: Alissa Cooper , Martin Thomson Thread-Topic: [Webpush] AD evaluation: draft-ietf-webpush-protocol-09 Thread-Index: AQHSFIEBkzsAu1vtm0+tmHqetkXrFKCGhAiAgAS1coCAANpQgIAARBLA Date: Mon, 26 Sep 2016 21:54:30 +0000 Message-ID: References: <1E66EFF9-A0B5-4BB5-8F1D-0ABABBB3C353@cooperw.in> 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: [92.54.160.246] x-ms-office365-filtering-correlation-id: 039c3764-304c-4923-91ae-08d3e657b17d x-microsoft-exchange-diagnostics: 1; CY1PR03MB2379; 6:iJA0Q97xMmycX4uAGs9T7BJ7znX2dECjGX1W0uVVYmmbGSYMhXZzX6egWuFOBBwBIawkC9GrQEy7VAO0eusUoPOtJQV4R/OxeTnglMOwv4PKgIb1WJkZVp1rRhSWlkQ9PTOacdz+ytMAL2Y1J4eWJxCj7vyj7NHI2CrToCDBmMUCN9LGRoUiNJaXWg7NirTKv9HDoxXrrhx4oeIBe5QJTV+lPkLQBfTsvkxzVUwXqyYsDgFq4JT0/uyDs9Uhtq+u0JsVaZ6tAwhAG0h+MaJNpQX9H1M5lTrz93kY+yvq1MjbUc+Uu/wGNPr8upjbnZf8m37mv77nYtQO7qUTg8L0gA==; 5:CxtrnJXg4IsXJbvylxUeG0CPy5y6sCRMKHmPqm/tSqHLw4iGTn5fMsdtgx60aWzL61NypegDHF6B546qrYrhTZ1ezC5NKjsLixdjCEC5a77/0yMqWoVI8g2Q08Av5VsiGqJAVTRzWdgeCXATnfXbhA==; 24:SS8mx90IBRI98Hrl5bZcndUtmmJsgjRqCKZjFApK7bqDT3iTHrGdGZvzS6ygsPLxnuOLl449xHQg3tdWaJi0qWCsqRJdTC+G4RyjjBHysvk=; 7:6uX/khf6mKkt7lQAFSBq4VjS/1Zux3VA6U90I7BiEGSsL9QuId4MgFa5uHOs5bnHyX3KuVM9nU0UtRtdCbMw5gslcDgZpIbMk7R2QUq92X7nvFFovhYYj2a0xEaHke2k5piqtvxi2OTsCBDOPuSteqfqP/7AvGioo7ocyN6RsWHWUSGa5seXJpANInYRNcoxsPj0sJnrd55kPjHThMzGxpDpn0+k2qpc9v794faPBZ3UFnXHXnI2FsJo7+EpO/7ubQeDw5/tyyZFDuyiLT1dlSWdxyi6zqYhPYVBFkXiBD+5cGHN7SLtCxBOwU5Qz2jg x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2379; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2379; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2379; x-forefront-prvs: 00770C4423 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(13464003)(54534003)(24454002)(189002)(51444003)(377454003)(189998001)(9686002)(19580395003)(19580405001)(2900100001)(105586002)(93886004)(99286002)(106356001)(305945005)(106116001)(7736002)(7846002)(97736004)(101416001)(66066001)(11100500001)(8936002)(122556002)(5001770100001)(7696004)(5002640100001)(586003)(50986999)(54356999)(3660700001)(76176999)(10090500001)(74316002)(3280700002)(3846002)(86612001)(102836003)(6116002)(5660300001)(2906002)(15975445007)(76576001)(8990500004)(68736007)(87936001)(77096005)(2950100002)(33656002)(81166006)(86362001)(81156014)(4326007)(5005710100001)(92566002)(8676002)(230783001)(10400500002)(10290500002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2379; H:CY1PR03MB2380.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2016 21:54:30.2720 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2379 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] AD evaluation: draft-ietf-webpush-protocol-09 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, 26 Sep 2016 21:54:34 -0000 I've merged Martin's PR, updated the change log, and published webpush-10. -----Original Message----- From: Webpush [mailto:webpush-bounces@ietf.org] On Behalf Of Alissa Cooper Sent: Monday, September 26, 2016 6:50 PM To: Martin Thomson Cc: webpush@ietf.org Subject: Re: [Webpush] AD evaluation: draft-ietf-webpush-protocol-09 LGTM > On Sep 26, 2016, at 12:48 AM, Martin Thomson w= rote: >=20 > I've create a pull request that includes the text below, plus fixes to > the other identified issues: >=20 > https://github.com/webpush-wg/webpush-protocol/pull/128 >=20 > Preview at: https://webpush-wg.github.io/webpush-protocol/alissa_review/ >=20 > On 23 September 2016 at 14:54, Martin Thomson = wrote: >> Thanks for reviewing Alissa, >>=20 >> The other comments look like they have mechanical fixes. We will get to= that. >>=20 >> On 22 September 2016 at 13:25, Alissa Cooper wrote: >>> =3D Section 5.4 =3D >>>=20 >>> "Delivery receipts for the deleted message >>> SHOULD be suppressed." >>>=20 >>> Why is this a SHOULD rather than a MUST? It seems incorrect in all case= s to send a delivery receipt for a message that never gets delivered. >>=20 >> I realize that this is actually too short to be comprehensible. What >> I think that this was trying to capture was that sometimes replaced >> messages might be delivered successfully, but the acknowledgment might >> be still in transit toward the server. That acknowledgement could >> trigger a delivery receipt. >>=20 >> This recommends that receipts be suppressed in this case. They might >> not be given the distributed nature of the push service. >> (Acknowledgments might be handled in a stateless fashion, and checking >> that a replacement has occurred can be expensive; preventing the race >> adds cost and latency also.) >>=20 >>>>>=20 >> A push message replacement request creates a new push message resource >> and simultaneously deletes any existing message resource that has a >> matching topic. If an attempt was made to deliver the deleted push >> message, an acknowledgment could arrive at the push service after the >> push message has been replaced. Delivery receipts for such deleted >> messages SHOULD be suppressed. >> <<< _______________________________________________ Webpush mailing list Webpush@ietf.org https://www.ietf.org/mailman/listinfo/webpush From nobody Tue Sep 27 03:28: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 328B312B026; Tue, 27 Sep 2016 03:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 2Hr3G0qnVEvx; Tue, 27 Sep 2016 03:28:16 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 884CE12B060; Tue, 27 Sep 2016 03:28:12 -0700 (PDT) X-AuditID: c1b4fb25-15fff7000000793b-dc-57ea49b90daa Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by (Symantec Mail Security) with SMTP id A7.22.31035.9B94AE75; Tue, 27 Sep 2016 12:28:10 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.32) with Microsoft SMTP Server id 14.3.301.0; Tue, 27 Sep 2016 12:28:09 +0200 To: , , , From: Magnus Westerlund Message-ID: <1f645188-2344-ebf3-1228-3735bcf81338@ericsson.com> Date: Tue, 27 Sep 2016 12:28:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprELMWRmVeSWpSXmKPExsUyM2K7nO4uz1fhBk+Xylgs/t7AZjFrzyIW i/ZLZ9gtrpz+y+7A4rFkyU+mAMYoLpuU1JzMstQifbsEroyGtz3MBc/UKi6cu8LYwDhRvouR k0NCwERi0cY9LF2MXBxCAusZJSacnM0K4SxnlFh97QxTFyMHh4hAjsTlfmeQBjYBC4mbPxrZ QGxhAXuJny82MIHYvED2k6dX2UDKWQRUJTa2lICERQViJPbPmskMUSIocXLmExaQEmag8gdb y0DCzALyEs1bZ4OVCAloSzQ0dbBOYOSdhaRjFkLHLCQdCxiZVzGKFqcWJ+WmGxnrpRZlJhcX 5+fp5aWWbGIEhtTBLb9VdzBefuN4iFGAg1GJhzdh1stwIdbEsuLK3EOMEhzMSiK8Mu6vwoV4 UxIrq1KL8uOLSnNSiw8xSnOwKInzmq28Hy4kkJ5YkpqdmlqQWgSTZeLglGpgZJWRuKWUK77v zNJNTxYbRknZLlJ73vxF8Frzkhntc9+xX5NgcbD26Fk9RUpU+f/zfVN8PZ+rH74l2S6+5m3m 7DUbhJoM5R/e+RKxPtfaQIDpjP+D1bdz25Q3hua/3O7irrwrzUtY5vmes7UawirhG2dwX37A a2LMISmX12T1JS9il9CU2wFWSizFGYmGWsxFxYkAxXkZPyUCAAA= Archived-At: Subject: [Webpush] Early TSV-ART review of draft-ietf-webpush-protocol-09 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, 27 Sep 2016 10:28:18 -0000 Hi, This review is an early, i.e. pre IETF Last Call TSV-ART review. The TSV-ART reviews document that has potential transport implications or transport related subjects. Please treat it as an IETF Last call comment if you don't want to handled it during the AD review. Document: draft-ietf-webpush-protocol-09 Title: Generic Event Delivery Using HTTP Push Reviewer: M. Westerlund Review Date: Sept 27, 2016 Below are a number of comments based on my review. The one with transport related subject is the overload handling in comment 4. 1. Section 3: So the Security Considerations do require use of HTTP over TLS. However, I do wonder if there would be a point to move that requirement up into the relevant connection sections, like 3. Especially as when one reads the confidentiality requirement in Section 4 for the message one wonders a bit why it is not explicitly required in section 3. 2. Section 5.2: TTL = 1*DIGIT Shouldn't the upper range for allowed values be specified here. At least to ensure that one doesn't get interoperability issues. 3. Section 7.2: To limit the number of stored push messages, the push service MAY either expire messages prior to their advertised Time-To-Live or reduce their advertised Time-To-Live. Do I understand this correctly, that theses options are push service side actions that is not notified at that point to the application server? Instead it will have to note that the message was early expired if it subscribes to delivery receipts? 4. Dealing with overload situations Reviewing Section 7.1 and other parts I find the discussion of how overload situations of various kinds are dealt with missing some cases. So the general handling of subscriptions are covered in Section 7.1 and with a mitigation of redirecting to another server to handle the new subscription. What I lack discussion of are how any form of push back are handled when first the deliver of push service to UA link is overloaded. Is the assumption here that as the push service can store messages the delivery will catch up eventually, or the message expires? How does one handle a 0-RTT messages when one has a queue of messages to deliver, despite having a UA to Push service connection? The second case is how the push service server can push back on accepting new message when it is overloaded. To me it appears that the load on a push service can be very dynamic. Thus overload can really be periods. Thus, what push back to application servers is intended here? Just, do a 503 response on the request from the application server? I do note that RFC 7231 does not appear to have any guidance one how one sets the Retry-After header to spread the load of the retries. This is a known issue. And in this context with automated or external event triggered message creations the push back mechanism needs to be robust and reduce the issues, not make them worse. I would recommend that some recommendations are actually included here for handling overload from application server message submissions. 5. Life of subscription in relation to transports I find myself a bit perplexed of if there are any relation between the subscription and the relation to an existing transport connection and outstanding request, i.e. the availability to receive messages over push. I would guess, that there are no strict need for terminating the subscription even if there are no receiver for an extended time. However, from an application perspective there could exists reason for why a subscription would not be terminated as long as the UA is connected, while any longer duration of no connections could motivate the subscription termination. I personally would like a bit more clarification on this, but seeing how these issues are usually handled around HTTP, I would guess the answer, it will be implementation specific? Still there appear to be assumptions around this, why it wouldn't matter that much, but that is only given that one follows these assumptions. 6. Unclarities which requests that require HTTP/2. The specification is explicit that some request can be performed over HTTP/1.x. However, it is not particular clear which requests that require HTTP/2. I assume all the GET requests that will hang to enable PUSH promises needs to be HTTP/2? Maybe this should be clarified? Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Sep 27 08:40:16 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 5CD8712B228; Tue, 27 Sep 2016 08:40:15 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <147499081533.4580.1262821584500672771.idtracker@ietfa.amsl.com> Date: Tue, 27 Sep 2016 08:40:15 -0700 Archived-At: Cc: Shida Schubert , draft-ietf-webpush-protocol@ietf.org, alissa@cooperw.in, webpush-chairs@ietf.org, webpush@ietf.org Subject: [Webpush] Last Call: (Generic Event Delivery Using HTTP Push) to Proposed Standard X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org 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, 27 Sep 2016 15:40:15 -0000 The IESG has received a request from the Web-Based Push Notifications WG (webpush) to consider the following document: - 'Generic Event Delivery Using HTTP Push' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-10-11. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract A simple protocol for the delivery of real-time events to user agents is described. This scheme uses HTTP/2 server push. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-webpush-protocol/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-webpush-protocol/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc2818: HTTP Over TLS (Informational - IETF stream) This reference is already listed in the acceptable Downref Registry.