From nobody Mon Oct 3 19:33: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 3E1A6129579; Mon, 3 Oct 2016 19:33:18 -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 Gx0Ntkw-TB6l; Mon, 3 Oct 2016 19:33:15 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0139.outbound.protection.outlook.com [104.47.40.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 8302B1295AC; Mon, 3 Oct 2016 19:33:15 -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=xsUkgcal8vN+OgtHwQDzNZSoOkHKTVp0BjZfLkbUcNg=; b=GkjiE/4MRBusk57RkqqII7aF0P1W2fpi9wTsrKH5Q/Ozvktuc2jFKpf1ts6I/oCwgvFQ8Mu6IW9T5xjkdhtppRUi/y8ZNPxgxo0BzmQaqxnnJNOIjQz0W0E6Jp9sWdxh9NmZFCraDI8Uemu0is1xb0GIOPjROSxvOVIlCCoF6UI= Received: from CY1PR03MB2380.namprd03.prod.outlook.com (10.167.8.6) by CY1PR03MB2380.namprd03.prod.outlook.com (10.167.8.6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.639.5; Tue, 4 Oct 2016 02:33:14 +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.0639.015; Tue, 4 Oct 2016 02:33:13 +0000 From: Brian Raymor To: Magnus Westerlund , "tsv-art@ietf.org" , "draft-ietf-webpush-protocol@ietf.org" , "webpush@ietf.org" , "webpush-ads@ietf.org" Thread-Topic: Early TSV-ART review of draft-ietf-webpush-protocol-09 Thread-Index: AQHSGKne4rZHBz7KIU6jZUnx6IKSHaCXcP9w Date: Tue, 4 Oct 2016 02:33:13 +0000 Message-ID: References: <1f645188-2344-ebf3-1228-3735bcf81338@ericsson.com> In-Reply-To: <1f645188-2344-ebf3-1228-3735bcf81338@ericsson.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: 99a905da-651f-4cc2-2c96-08d3ebfeca71 x-microsoft-exchange-diagnostics: 1; CY1PR03MB2380; 6:EnBoUNJnNf15yjQpxxhaTk0+QHPdchO18F1znAMaLOOELMdllM/AVVKbc6qnJZmDo0FNexbmKyeJP7izsARMpX+yhqaD0xAjPxmvL9gXA2XDMeXkCxZDgUz1EToujUGCfeRZ0sorYSPQfO5RDFWhx6wZ4zFxgwek/7bAMZJpDDrojBCDnDgXjWusknrBqDJRfZ8PlpUu8Ek91u0GAgaAaFAPxXB+bwTC/yuiKSnvZFLECwfrZMaCg6U5psNXh0uNS03OP65Rpnymy2+jkM1vKV00xqdcAmMT/poRvmB2s2ImEr/eW7VSZ6LK19tkWD8dyj4JU5PTzLsD1M99e7mIQQ==; 5:xjnzXBcaBZwLmsCLQwlBgqOUbYaFhWDuAIYfWXvu5Pi5UT9z+lJ34RYHv0a68LBcwASteE1fTRkjbpF4KfRe/URKYmx++0IANFPhzA+Cf5LHBTBy/mGLJNnFd3ozBFOBenjHXjsUfGV7vUvydCttew==; 24:icuw+543/6BGl4VFgkCWXMf9GQZzMWv/PVPps0MA0cA9c0SWlAekTH+ITwMHTBBF08HCv7CMYcyhMl1XopOcEtXb6vcT/jh8xOK5P/GZeDw=; 7:XdJkwp0Y1J5uIBRk5Lx7TLwoz17ehrKrkTvz3cne2hZe3cHvjGplI2gQU1wRNcL/rjojR9l+L/3R4wJtK0nXkvqfp6a6+JG4jNOVP54u59OcabgAAlYnYerwJOHC0372jle5gstT7wtCmM7FYr15pacuigXnLqq7HmEcwnYX+ROuTZAChDx1bBKOH2nnvMHowiCe15rDujsBz5oIVUrJ/GrdlIiT04muzXdFhtnm0oO7+f25QDZctnL/wQWDMnFw5MFHITQY6If3db7Yhp1okiU6oIAljk6PD3OteVinVg/Ywf7714dbOEFX5R1mLJyq x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2380; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(158342451672863)(72170088055959); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2380; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2380; x-forefront-prvs: 00851CA28B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(51914003)(24454002)(51444003)(199003)(377454003)(68736007)(6116002)(50986999)(54356999)(8936002)(77096005)(5005710100001)(106116001)(7846002)(10090500001)(92566002)(76176999)(107886002)(2950100002)(10400500002)(2900100001)(8990500004)(9686002)(66066001)(10290500002)(189998001)(5002640100001)(76576001)(2501003)(97736004)(15975445007)(102836003)(2906002)(5001770100001)(3846002)(74316002)(122556002)(87936001)(8676002)(7696004)(86362001)(19580395003)(33656002)(3660700001)(106356001)(105586002)(99286002)(5660300001)(3280700002)(86612001)(7736002)(81166006)(101416001)(305945005)(586003)(2201001)(81156014)(230783001)(19580405001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2380; 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: 04 Oct 2016 02:33:13.6764 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2380 Archived-At: Subject: Re: [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, 04 Oct 2016 02:33:18 -0000 Magnus - Thanks for the review. I'll have a pull request available tomorrow= to address most of your feedback. In the interim, I've shared a few commen= ts and clarifications below. On September 27, 2016 3:28 AM, Magnus Westerlund wrote: > 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=20 > side actions that is not notified at that point to the application=20 > server? Instead it will have to note that the message was early expired=20 > if it subscribes to delivery receipts? This text should be clarified. There are two cases. First, the push service= can only reduce the requested TTL in its response to a request from an app= lication server to deliver a push message: https://tools.ietf.org/html/draft-ietf-webpush-protocol-10#section-5.2 A push service MAY retain a push message for a shorter duration than requested. It indicates this by returning a TTL header field in its response with the actual TTL. This TTL value MUST be less than or equal to the value provided by the application server. Second, if an application server subscribes to delivery receipts it will re= ceive a 410 if the push service does not then honor that TTL: https://tools.ietf.org/html/draft-ietf-webpush-protocol-10#section-6.2 The push service MAY cease to retry delivery of the message prior to its advertised expiration due to scenarios such as an unresponsive user agent or operational constraints. If the application has requested a delivery receipt, then the push service MUST return a 410 (Gone) response to the application server monitoring the receipt subscription. If the application server does not subscribe to delivery receipts, then it'= s a fire-and-forget scenario. > 4. Dealing with overload situations Could webpush implementers review Magnus's questions below and consider whe= ther there is further general guidance that can be offered based on their e= arly experiences with the protocol? > Reviewing Section 7.1 and other parts I find the discussion of how=20 > overload situations of various kinds are dealt with missing some cases.=20 > So the general handling of subscriptions are covered in Section 7.1 and=20 > with a mitigation of redirecting to another server to handle the new=20 > subscription. > What I lack discussion of are how any form of push back are handled when= =20 > first the deliver of push service to UA link is overloaded. Is the=20 > assumption here that as the push service can store messages the delivery= =20 > will catch up eventually, or the message expires?=20 Your assumption in this case is basically correct. The push service could a= lso use the acknowledgements from the user agent as an indicator of overloa= d and reduce the rate. > How does one handle a=20 > 0-RTT messages when one has a queue of messages to deliver, despite=20 > having a UA to Push service connection? > The second case is how the push service server can push back on=20 > accepting new message when it is overloaded. To me it appears that the=20 > load on a push service can be very dynamic. Thus overload can really be=20 > periods. Thus, what push back to application servers is intended here?=20 > Just, do a 503 response on the request from the application server? We decided on a 429. See https://www.ietf.org/mail-archive/web/webpush/curr= ent/msg00341.html - although it's also possible for the push service to ter= minate a subscription.=20 https://tools.ietf.org/html/draft-ietf-webpush-protocol-10#section-8.4 A push service MAY return a 429 (Too Many Requests) status code [RFC6585] when an application server has exceeded its rate limit for push message delivery to a push resource. The push service SHOULD also include a Retry-After header [RFC7231] to indicate how long the application server is requested to wait before it makes another request to the push resource. A push service or user agent MAY also terminate subscriptions (Section 7.3) that receive too many push messages. > I do note that RFC 7231 does not appear to have any guidance one how one= =20 > sets the Retry-After header to spread the load of the retries. This is a= =20 > known issue. And in this context with automated or external event=20 > triggered message creations the push back mechanism needs to be robust=20 > and reduce the issues, not make them worse. > I would recommend that some recommendations are actually included here=20 > 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=20 > subscription and the relation to an existing transport connection and=20 > outstanding request, i.e. the availability to receive messages over=20 > push. I would guess, that there are no strict need for terminating the=20 > subscription even if there are no receiver for an extended time.=20 Especially for mobile and/or battery powered clients, the expectation is th= at the user agents will be dormant for extended periods of time. > However, from an application perspective there could exists reason for=20 > why a subscription would not be terminated as long as the UA is=20 > connected, while any longer duration of no connections could motivate=20 > the subscription termination. > I personally would like a bit more clarification on this, but seeing how= =20 > these issues are usually handled around HTTP, I would guess the answer,=20 > it will be implementation specific? Still there appear to be assumptions= =20 > around this, why it wouldn't matter that much, but that is only given=20 > that one follows these assumptions. I think that your assumption is correct. The behavior is specific to the pu= sh service. Implementers have requested the ability for a push service to terminate a s= ubscription at will based on its internal policies. Again, I'd ask that the webpush implementers share any general guidance or = observations for this case. From nobody Tue Oct 4 18:58: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 BE056129447; Tue, 4 Oct 2016 18:58:27 -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 o2itJ1WvOZwI; Tue, 4 Oct 2016 18:58:25 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::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 142A7128E18; Tue, 4 Oct 2016 18:58:25 -0700 (PDT) Received: by mail-pa0-x235.google.com with SMTP id ik13so25602854pac.2; Tue, 04 Oct 2016 18:58:25 -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=B1GHlHdxzShChmWNkWK5wK/wrQS7K71KyxWSNoNbyCw=; b=SPk5Hj6aHBHxmrkJFtnj4PGGDtiCaBk22hGAPHbj33IxCL141L7z9vuOAfRzZz2DE2 Bj7wv+DOWd7Yf3R6EsfT9/NIrSoBvKuDRuXJA2pppEaAWNWTmHojxr9Xlczerw+HGcir QTdRgz3AM7YBkbAddsc6I95/g1k06OHQkkL+zH4YKaC9+Wx1ahz9/IjrIMm8OHNyhfD7 I/bnD1k5LVo5yFIgRGaljxXofMC4kawzl5Rjc8Y6qcJOC6/HsV5MnCht5TWdRnM6CwoE J9yRIsiZC59n40SNpIvcIPUjnaD/cDJPmVB7PkNxweEQNJbftR2MdlM0J8QeuxwB6rno pWKQ== 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=B1GHlHdxzShChmWNkWK5wK/wrQS7K71KyxWSNoNbyCw=; b=Hvo7pNMdpj/dKzarKeD4aAtyQG1I6VfrZAKlMW3uXABjyAw+cdMhjh9KcqnkkJZmQ8 TAQz0rC4fPojwxzF1Shmn96lHaKQNzxKFA89iGecW1I0nk2WVV77faD60yiru8wv1Z35 BUwz0kMngsgNseNhA46M9KmP9pLUlkKw1wm3sALB7Nr5pv6i6QyICX1UpQtB2illBKtS cTUS9T7bgoxRxMeFgVjSWuGRpcwQmtt9jbaF027ROuESz8sJprOhpIuZ/26J3oLoymhX StUiCFRJl6x9Zoy/AhOFNKI+//MN3FhvUatHk3hbTOGFouWri6byx3j71DVbudBnCA8S Dttw== X-Gm-Message-State: AA6/9Rn5Og57KXupyY0T4UFMMHDSTV3HdxoPF37jeVrlu0AglBeUcM3R7Ag56L7M/Z4fQvINNkU7Kjhr0hXU3A== X-Received: by 10.66.237.133 with SMTP id vc5mr9560902pac.24.1475632704626; Tue, 04 Oct 2016 18:58:24 -0700 (PDT) MIME-Version: 1.0 References: <1f645188-2344-ebf3-1228-3735bcf81338@ericsson.com> In-Reply-To: <1f645188-2344-ebf3-1228-3735bcf81338@ericsson.com> From: Costin Manolache Date: Wed, 05 Oct 2016 01:58:13 +0000 Message-ID: To: Magnus Westerlund , tsv-art@ietf.org, draft-ietf-webpush-protocol@ietf.org, webpush@ietf.org, webpush-ads@ietf.org Content-Type: multipart/alternative; boundary=047d7b15fd972da7ad053e148393 Archived-At: Subject: Re: [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: Wed, 05 Oct 2016 01:58:28 -0000 --047d7b15fd972da7ad053e148393 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Sep 27, 2016 at 3:28 AM Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > 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 =3D 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? > I agree it needs more clarifications - expiring prior to TTL is the same with reducing the TTL, so at least that part seems redundant. In GCM, this would happen only if the sender has too many messages for a device. I assume some implementation of push may not want to load the list of saved messages or counters before saving - there are replicatio= n delays and cost savings - so it might make sense to let the pushservice dro= p messages without telling the app server. In GCM there is a special message that is sent to the UA if the pushservice dropped (collapsed) messages, so UA can do a full sync. > > 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? > In most cases the UA to push service link is lightly used - payload size is limited, as is number of messages per device ( in particular for mobile ). Yes, I think the assumption is the push service will store - and keep attempting to deliver. There was a separate thread on how to control the flow - since push promise doesn't have a response - the focus was on delivery receipts, where overload is far more likely. For UA, the message ack can control the flow. > > 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? > Yes, so far that's what GCM is doing. Expectation is that app server will retry with backoff. > > 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. > Yes, another problem is that a push service can be global, and overload can happen only on a shard ( i.e. affect groups of users - but not the entire service ) - in particular in case of DOS, bugs or an app server running load tests on too few devices= . > > 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. > In general, subscriptions are expected to last for a longer interval to reduce load ( devices calling subscribe, then sending the subscriptions to app servers, who need to store it ). On the other side, it's common for devices or browsers to be reset (clear data,etc) or stop being used. The fact a device connects is an important signal - it is reasonable to kee= p a subscription active while device keeps connection, but expire it after a certain time ( and also clear up any stored messages ). Adding some numbers would be good - but I don't know what would be reasonable, it's a trade-off between storage on server and traffic/battery on device. > > 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? > +1 Costin > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > <+46%2010%20714%2082%2087> > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > <+46%2073%20094%2090%2079> > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > --047d7b15fd972da7ad053e148393 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue= , Sep 27, 2016 at 3:28 AM Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
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 =3D 1*DIGIT

Shouldn't the upper range for allowed values be specified here. At leas= t
to ensure that one doesn't get interoperability issues.

3. Section 7.2:

=C2=A0 =C2=A0 To limit the number of stored push messages, the push service= MAY
=C2=A0 =C2=A0 either expire messages prior to their advertised Time-To-Live= or
=C2=A0 =C2=A0 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?
=

I agree it needs more clarifications - expiring prior t= o TTL is the same with=C2=A0
reducing the TTL, so at least that p= art seems redundant.=C2=A0

In GCM, this would happ= en only if the sender has too many messages for
a device. I assum= e some implementation of push may not want to load
the list of sa= ved messages or counters before saving - there are replication
de= lays and cost savings - so it might make sense to let the pushservice drop<= /div>
messages without telling the app server. In GCM there is a specia= l message
that is sent to the UA if the pushservice dropped (coll= apsed) messages, so
UA can do a full sync.

=C2=A0

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?

In most cases the UA to push service link is lightly u= sed - payload size is=C2=A0
limited, as is number of messages per= device ( in particular for mobile ).
Yes, I think the assumption= is the push service will store - and keep attempting
to deliver.=

There was a separate thread on how to control the= flow - since push
promise doesn't have a response - the focu= s was on delivery receipts, where
overload is far more likely. Fo= r UA, the message ack can control the flow. =C2=A0
=C2=A0

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?

Yes, so far that's wha= t GCM is doing. Expectation is that app server will retry with=C2=A0
<= div>backoff.
=C2=A0

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.

Yes, another problem is that a push service can be= global, and overload can happen
only on a shard ( i.e. affect gr= oups of users - but not the entire service ) - in particular
in c= ase of DOS, bugs or an app server running load tests on too few devices.
=C2=A0

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.

In general, subscriptions are expected to last for a longe= r interval to reduce
load ( devices calling subscribe, then sendi= ng the subscriptions to app servers,
who need to store it ). On t= he other side, it's common for devices or browsers to
be rese= t (clear data,etc) or stop being used.=C2=A0

The f= act a device connects is an important signal - it is reasonable to keep
a subscription active while device keeps connection, but expire it a= fter a certain
time ( and also clear up any stored messages ). Ad= ding some=C2=A0
numbers would be good - but I don't know what= would be reasonable, it's=C2=A0
a trade-off between storage = on server and traffic/battery on device.
=C2=A0

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?

+1

Costin
=C2=A0

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
F=C3=A4r=C3=B6gatan 6=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericss= on.com
----------------------------------------------------------------------

_______________________________________________
Webpush mailing list
W= ebpush@ietf.org
https://www.ietf.org/mailman/listin= fo/webpush
--047d7b15fd972da7ad053e148393-- From nobody Tue Oct 4 20:10:31 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 B17221293E0; Tue, 4 Oct 2016 20:10:27 -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 Dfs4UloAxRNM; Tue, 4 Oct 2016 20:10:24 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0099.outbound.protection.outlook.com [104.47.41.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 A32F4128874; Tue, 4 Oct 2016 20:10:24 -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=/6WKfhXpS1DupmZymnmc2Fw2A1i4LGcN2LSRe9TTo2s=; b=Nz1w/gjqqw381ppxaj4yV8xPz5EHOx4gsMsZpR6Yg4SwkMn5d3H++W7sEW4Fn5c0v/Ho3CTZ54vZjcYToecOya8P+TqtaBUEbBru/hDwyiiZKxHpKxSnhmCTAEnAarq9wp5qV93AXmuDu3CsB0qlVkkCxyACvKU/rE9orLcVa0s= 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.649.16; Wed, 5 Oct 2016 03:10:23 +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.0639.017; Wed, 5 Oct 2016 03:10:23 +0000 From: Brian Raymor To: Magnus Westerlund , "tsv-art@ietf.org" , "draft-ietf-webpush-protocol@ietf.org" , "webpush@ietf.org" , "webpush-ads@ietf.org" Thread-Topic: Early TSV-ART review of draft-ietf-webpush-protocol-09 Thread-Index: AQHSGKne4rZHBz7KIU6jZUnx6IKSHaCXcP9wgAHHqeA= Date: Wed, 5 Oct 2016 03:10:23 +0000 Message-ID: References: <1f645188-2344-ebf3-1228-3735bcf81338@ericsson.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: [174.61.159.182] x-ms-office365-filtering-correlation-id: fef188a6-6d03-45b8-56d8-08d3eccd259a x-microsoft-exchange-diagnostics: 1; CY1PR03MB2379; 7:6MWkfBGbP9Lst38Sk3qkmVFqQxiQf+VaaksJVloiDLwfxv40YyXyFZOj0yXvYpirHlDtw35MHuVW6R8//MAmCZXYiF8ANhiqo5tckncz6tx3I6LKIeFSxjksNpLeiuMYs+h2cB/KxHGnlCjTT4nZpQ1/0G82zo5YrGH0DcRjZNW6seV/vA2BixfRcOLZu/N/Xbg6YGuCqgPwFU1Ff9RVY++y96dbj/5ym+VZ6HYtRQ6rqGJjj4J/fOgzF/Q2tWJJKnQQW/IQkFVYAR781J1wQ3DLIO5Xu3s83a8FcitpLJYPEJIC/2+iHhqAjCSgqzyeJg/Q9uqlkM9AUaucaS6dyQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2379; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(158342451672863)(72170088055959)(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2379; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2379; x-forefront-prvs: 008663486A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(24454002)(189002)(51444003)(13464003)(199003)(51914003)(5002640100001)(105586002)(54356999)(2900100001)(3660700001)(76176999)(3280700002)(106116001)(107886002)(189998001)(15975445007)(86362001)(230783001)(81166006)(8676002)(76576001)(8936002)(106356001)(8990500004)(99286002)(87936001)(77096005)(7696004)(10290500002)(5005710100001)(2201001)(81156014)(10400500002)(2501003)(66066001)(7846002)(586003)(7736002)(122556002)(92566002)(2906002)(101416001)(86612001)(68736007)(6116002)(3846002)(11100500001)(102836003)(305945005)(97736004)(74316002)(33656002)(5001770100001)(5660300001)(50986999)(19580405001)(10090500001)(9686002)(2950100002)(19580395003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2379; 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: 05 Oct 2016 03:10:23.1343 (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: Subject: Re: [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: Wed, 05 Oct 2016 03:10:28 -0000 I've created an initial pull request for review - https://github.com/webpus= h-wg/webpush-protocol/pull/131 - while we discuss whether there's additiona= l guidance that can be shared for "4. Dealing with overload situations". -----Original Message----- From: Brian Raymor [mailto:Brian.Raymor@microsoft.com]=20 Sent: Monday, October 3, 2016 7:33 PM To: Magnus Westerlund ; tsv-art@ietf.org; d= raft-ietf-webpush-protocol@ietf.org; webpush@ietf.org; webpush-ads@ietf.org Subject: RE: Early TSV-ART review of draft-ietf-webpush-protocol-09 Magnus - Thanks for the review. I'll have a pull request available tomorrow= to address most of your feedback. In the interim, I've shared a few commen= ts and clarifications below. On September 27, 2016 3:28 AM, Magnus Westerlund wrote: > 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=20 > side actions that is not notified at that point to the application=20 > server? Instead it will have to note that the message was early expired=20 > if it subscribes to delivery receipts? This text should be clarified. There are two cases. First, the push service= can only reduce the requested TTL in its response to a request from an app= lication server to deliver a push message: https://tools.ietf.org/html/draft-ietf-webpush-protocol-10#section-5.2 A push service MAY retain a push message for a shorter duration than requested. It indicates this by returning a TTL header field in its response with the actual TTL. This TTL value MUST be less than or equal to the value provided by the application server. Second, if an application server subscribes to delivery receipts it will re= ceive a 410 if the push service does not then honor that TTL: https://tools.ietf.org/html/draft-ietf-webpush-protocol-10#section-6.2 The push service MAY cease to retry delivery of the message prior to its advertised expiration due to scenarios such as an unresponsive user agent or operational constraints. If the application has requested a delivery receipt, then the push service MUST return a 410 (Gone) response to the application server monitoring the receipt subscription. If the application server does not subscribe to delivery receipts, then it'= s a fire-and-forget scenario. > 4. Dealing with overload situations Could webpush implementers review Magnus's questions below and consider whe= ther there is further general guidance that can be offered based on their e= arly experiences with the protocol? > Reviewing Section 7.1 and other parts I find the discussion of how=20 > overload situations of various kinds are dealt with missing some cases.=20 > So the general handling of subscriptions are covered in Section 7.1 and=20 > with a mitigation of redirecting to another server to handle the new=20 > subscription. > What I lack discussion of are how any form of push back are handled when= =20 > first the deliver of push service to UA link is overloaded. Is the=20 > assumption here that as the push service can store messages the delivery= =20 > will catch up eventually, or the message expires?=20 Your assumption in this case is basically correct. The push service could a= lso use the acknowledgements from the user agent as an indicator of overloa= d and reduce the rate. > How does one handle a=20 > 0-RTT messages when one has a queue of messages to deliver, despite=20 > having a UA to Push service connection? > The second case is how the push service server can push back on=20 > accepting new message when it is overloaded. To me it appears that the=20 > load on a push service can be very dynamic. Thus overload can really be=20 > periods. Thus, what push back to application servers is intended here?=20 > Just, do a 503 response on the request from the application server? We decided on a 429. See https://www.ietf.org/mail-archive/web/webpush/curr= ent/msg00341.html - although it's also possible for the push service to ter= minate a subscription.=20 https://tools.ietf.org/html/draft-ietf-webpush-protocol-10#section-8.4 A push service MAY return a 429 (Too Many Requests) status code [RFC6585] when an application server has exceeded its rate limit for push message delivery to a push resource. The push service SHOULD also include a Retry-After header [RFC7231] to indicate how long the application server is requested to wait before it makes another request to the push resource. A push service or user agent MAY also terminate subscriptions (Section 7.3) that receive too many push messages. > I do note that RFC 7231 does not appear to have any guidance one how one= =20 > sets the Retry-After header to spread the load of the retries. This is a= =20 > known issue. And in this context with automated or external event=20 > triggered message creations the push back mechanism needs to be robust=20 > and reduce the issues, not make them worse. > I would recommend that some recommendations are actually included here=20 > 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=20 > subscription and the relation to an existing transport connection and=20 > outstanding request, i.e. the availability to receive messages over=20 > push. I would guess, that there are no strict need for terminating the=20 > subscription even if there are no receiver for an extended time.=20 Especially for mobile and/or battery powered clients, the expectation is th= at the user agents will be dormant for extended periods of time. > However, from an application perspective there could exists reason for=20 > why a subscription would not be terminated as long as the UA is=20 > connected, while any longer duration of no connections could motivate=20 > the subscription termination. > I personally would like a bit more clarification on this, but seeing how= =20 > these issues are usually handled around HTTP, I would guess the answer,=20 > it will be implementation specific? Still there appear to be assumptions= =20 > around this, why it wouldn't matter that much, but that is only given=20 > that one follows these assumptions. I think that your assumption is correct. The behavior is specific to the pu= sh service. Implementers have requested the ability for a push service to terminate a s= ubscription at will based on its internal policies. Again, I'd ask that the webpush implementers share any general guidance or = observations for this case. From nobody Wed Oct 5 06:08: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 84FC21296F3; Wed, 5 Oct 2016 06:08:32 -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 IySXUeH31mb7; Wed, 5 Oct 2016 06:08:27 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 0A73B1296EA; Wed, 5 Oct 2016 06:08:26 -0700 (PDT) X-AuditID: c1b4fb2d-5b107980000009f7-aa-57f4fb491bb8 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by (Symantec Mail Security) with SMTP id 45.E1.02551.94BF4F75; Wed, 5 Oct 2016 15:08:25 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.86) with Microsoft SMTP Server id 14.3.301.0; Wed, 5 Oct 2016 15:08:23 +0200 To: Brian Raymor , "tsv-art@ietf.org" , "draft-ietf-webpush-protocol@ietf.org" , "webpush@ietf.org" , "webpush-ads@ietf.org" References: <1f645188-2344-ebf3-1228-3735bcf81338@ericsson.com> From: Magnus Westerlund Message-ID: <4baa72c6-cd52-19d5-c070-4a19336c23ed@ericsson.com> Date: Wed, 5 Oct 2016 15:08:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM2J7iK7n7y/hBq/fSFncn/eIyWLx9wY2 i1l7FrFYtF86w25x5fRfdgdWjyVLfjJ5tO74yx7AFMVlk5Kak1mWWqRvl8CVsfrWEraCaTYV c+b+ZmpgfG7QxcjJISFgInHgzAX2LkYuDiGB9YwS3S2bGEESQgLLGCXenrQCsYUFnCVWXjnL DFIkIvCfUeL8/80sEEVPGSWunuYCsdkELCRu/mhkA7F5BewlOjq2soPYLAIqElO23WYCsUUF YiSuP3sEVSMocXLmE6A5HBycArESjZsiQUxmoNYHW8tAKpgF5CWat85mhtikLdHQ1ME6gZF/ FpLmWQgds5B0LGBkXsUoWpxaXJybbmSsl1qUmVxcnJ+nl5dasokRGJgHt/zW3cG4+rXjIUYB DkYlHt4HWz+HC7EmlhVX5h5ilOBgVhLh1fz1JVyINyWxsiq1KD++qDQntfgQozQHi5I4r9nK ++FCAumJJanZqakFqUUwWSYOTqkGRgV/lRfJrRHXtj6+81lfpyZyQsjNmiebljSetrL+4xxz 9/56G+MNpvF1Ocfd7vmvm1KvZ6G+6YXU3MwPXELm5w/YvvuoJXH/jsekAqPC8HClXVnWRurf avwTF/A4dE/Nqvm37c73LS1W7Ud0trHou2oLJE1akvRzpUZ+jLGMG//v0gSR9a1BSizFGYmG WsxFxYkAAh7BnUgCAAA= Archived-At: Subject: Re: [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: Wed, 05 Oct 2016 13:08:32 -0000 Hi, I have looked at the pull request which looks good, with one very minor comment that you should check out on github. Cheers Magnus Den 2016-10-05 kl. 05:10, skrev Brian Raymor: > I've created an initial pull request for review - > https://github.com/webpush-wg/webpush-protocol/pull/131 - while we > discuss whether there's additional guidance that can be shared for > "4. Dealing with overload situations". > > > -----Original Message----- From: Brian Raymor > [mailto:Brian.Raymor@microsoft.com] Sent: Monday, October 3, 2016 > 7:33 PM To: Magnus Westerlund ; > tsv-art@ietf.org; draft-ietf-webpush-protocol@ietf.org; > webpush@ietf.org; webpush-ads@ietf.org Subject: RE: Early TSV-ART > review of draft-ietf-webpush-protocol-09 > > Magnus - Thanks for the review. I'll have a pull request available > tomorrow to address most of your feedback. In the interim, I've > shared a few comments and clarifications below. > > On September 27, 2016 3:28 AM, Magnus Westerlund > wrote: > > > >> 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? > > This text should be clarified. There are two cases. First, the push > service can only reduce the requested TTL in its response to a > request from an application server to deliver a push message: > > https://tools.ietf.org/html/draft-ietf-webpush-protocol-10#section-5.2 > > A push service MAY retain a push message for a shorter duration > than requested. It indicates this by returning a TTL header field in > its response with the actual TTL. This TTL value MUST be less than > or equal to the value provided by the application server. > > Second, if an application server subscribes to delivery receipts it > will receive a 410 if the push service does not then honor that TTL: > > https://tools.ietf.org/html/draft-ietf-webpush-protocol-10#section-6.2 > > The push service MAY cease to retry delivery of the message prior > to its advertised expiration due to scenarios such as an > unresponsive user agent or operational constraints. If the > application has requested a delivery receipt, then the push service > MUST return a 410 (Gone) response to the application server > monitoring the receipt subscription. > > If the application server does not subscribe to delivery receipts, > then it's a fire-and-forget scenario. > >> 4. Dealing with overload situations > > Could webpush implementers review Magnus's questions below and > consider whether there is further general guidance that can be > offered based on their early experiences with the protocol? > >> 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? > > Your assumption in this case is basically correct. The push service > could also use the acknowledgements from the user agent as an > indicator of overload and reduce the rate. > >> 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? > > We decided on a 429. See > https://www.ietf.org/mail-archive/web/webpush/current/msg00341.html - > although it's also possible for the push service to terminate a > subscription. > > https://tools.ietf.org/html/draft-ietf-webpush-protocol-10#section-8.4 > > A push service MAY return a 429 (Too Many Requests) status code > [RFC6585] when an application server has exceeded its rate limit for > push message delivery to a push resource. The push service SHOULD > also include a Retry-After header [RFC7231] to indicate how long the > application server is requested to wait before it makes another > request to the push resource. > > A push service or user agent MAY also terminate subscriptions > (Section 7.3) that receive too many push messages. > >> 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. > > Especially for mobile and/or battery powered clients, the expectation > is that the user agents will be dormant for extended periods of > 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. > > I think that your assumption is correct. The behavior is specific to > the push service. Implementers have requested the ability for a push > service to terminate a subscription at will based on its internal > policies. > > Again, I'd ask that the webpush implementers share any general > guidance or observations for this case. > > > > > -- 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 Sat Oct 8 12:55:09 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 C945B126FDC for ; Sat, 8 Oct 2016 12:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5] 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 GC1Ch0iyj6UZ for ; Sat, 8 Oct 2016 12:55:06 -0700 (PDT) Received: from gateway34.websitewelcome.com (gateway34.websitewelcome.com [192.185.148.119]) (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 7E4E1120726 for ; Sat, 8 Oct 2016 12:55:06 -0700 (PDT) Received: from cm7.websitewelcome.com (cm7.websitewelcome.com [108.167.139.20]) by gateway34.websitewelcome.com (Postfix) with ESMTP id DA5D6BE87A27B for ; Sat, 8 Oct 2016 14:55:05 -0500 (CDT) Received: from gator4135.hostgator.com ([192.185.4.147]) by cm7.websitewelcome.com with id t7v41t00S3AKFgo017v5pK; Sat, 08 Oct 2016 14:55:05 -0500 Received: from [172.56.7.229] (port=23899 helo=[172.20.10.11]) by gator4135.hostgator.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bsxi4-000QOI-Ay for webpush@ietf.org; Sat, 08 Oct 2016 14:55:04 -0500 From: Shida Schubert Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <0F8DEB44-41DC-40CA-84CC-4C023E3CBB00@ntt-at.com> Date: Sat, 8 Oct 2016 12:55:02 -0700 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: 172.56.7.229 X-Exim-ID: 1bsxi4-000QOI-Ay X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([172.20.10.11]) [172.56.7.229]:23899 X-Source-Auth: dashi@agnada.com X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== Archived-At: Subject: [Webpush] Agenda requests for IETF 97 (Seoul) 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, 08 Oct 2016 19:55:08 -0000 All,=20 The Seoul meeting is approaching in a month and we as chairs would need = to decide if we are keeping our 90 minutes slot in Seoul.=20 Please send in your agenda requests with what you would like to discuss = and how long you would need.=20 Please send your requests and/or ideas for the agenda to the chairs or = to the list. Many Thanks, Shida as co-chair= From nobody Sun Oct 9 22:05:53 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 B8776129404; Sun, 9 Oct 2016 22:05: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.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147607595271.30469.10749017366005045467.idtracker@ietfa.amsl.com> Date: Sun, 09 Oct 2016 22:05:52 -0700 Archived-At: Cc: webpush@ietf.org Subject: [Webpush] I-D Action: draft-ietf-webpush-encryption-04.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, 10 Oct 2016 05:05: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 : Message Encryption for Web Push Author : Martin Thomson Filename : draft-ietf-webpush-encryption-04.txt Pages : 12 Date : 2016-10-09 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-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-webpush-encryption-04 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 Sun Oct 9 22:07: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 A3692129474 for ; Sun, 9 Oct 2016 22:07:36 -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 zf9Pyt9iWUSB for ; Sun, 9 Oct 2016 22:07:35 -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 13070126FDC for ; Sun, 9 Oct 2016 22:07:35 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id o68so90295276qkf.3 for ; Sun, 09 Oct 2016 22:07:35 -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=it3dBbosZVsUaF7uKXnjV6n0v3w9IwZqhIRsGxDEXMc=; b=Cb1Tc9VH46Lgpq8o+ccSpz2DR+DzijbkCgEil5mKclzzkIgW4Zg/1RN3qzFd9qgw4p nPijJnvBdET5o9JY+VbVvQSQzUxEudujGQYgOg5tPs0ux9fTlezZLIDMs9q7hUbboSFi RGRjDEbfHUXxAneamTx3uYv5md85gC8WavVt5KfYkdByn3kZUpg7ieLCBvcbVBEZhoKZ 5c8MJuiNVvf7MJwl2CvmsFMZ4W2HsMfkU4jfK8utKBrB+X63Yk4IfWH99zaYB5f5Q7Sh 8tR7k+5e8HJ9FeuQcSyqBzU54iuG6Hal4kqFEqT4E+pw9GfOh8wXifaw3+RkepFOpH5t 3fow== 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=it3dBbosZVsUaF7uKXnjV6n0v3w9IwZqhIRsGxDEXMc=; b=a+P2EL54h8n1ID09RaI5AAL1gPmAcy1FVxXrnfD9TRUtMLKEMyfLsE2zHhMTYYFspr Jy6a5DdL6GnxjVpk6ORFWne6yjZf8nGXdrcTeOhqxyXsn+lwSWfZ7lPMr8LwOm0ST99J FJC1gzs3VjMHSWxxCtmRlYMXjO0U9bH/RIri3SI07+y9QVabRbS3OPO0gpbrR9uMbhve qWoGdk1vMpLHCY0JDGJyq6YsDFt/Dll0vO/qXYr2aqsuB5WUOJw02RkCguPTpKFCmHrj wcvayVGCTQXXEe7o+tSZql45SP+LFK4n7sPziTrqRD0TytyXQ0n7isaC6rRM9ZZtrkjO lLiA== X-Gm-Message-State: AA6/9Rnxe64GnZ27fURYXuFe+9SG0tMfQDlV6bKnqmJMqN498iEZ9wCKE1yFqZ9orPBNQnGu17kJ9TXcAJ9IfQ== X-Received: by 10.55.155.15 with SMTP id d15mr28896229qke.115.1476076054124; Sun, 09 Oct 2016 22:07:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Sun, 9 Oct 2016 22:07:33 -0700 (PDT) In-Reply-To: <147607595271.30469.10749017366005045467.idtracker@ietfa.amsl.com> References: <147607595271.30469.10749017366005045467.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Mon, 10 Oct 2016 16:07:33 +1100 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-04.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: Mon, 10 Oct 2016 05:07:36 -0000 On 10 October 2016 at 16:05, wrote: > https://tools.ietf.org/html/draft-ietf-webpush-encryption-04 This version is the simplified version of the draft that I described earlier. The actual format should not have changed, but the description has been simplified greatly. From nobody Mon Oct 10 06:21:55 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 A5D161296A4; Mon, 10 Oct 2016 06:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, 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=dbVZjdGb; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=AA8RlrN3 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 hkESesb213xG; Mon, 10 Oct 2016 06:21:51 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43C001296A8; Mon, 10 Oct 2016 06:21:51 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id ACEF1206A4; Mon, 10 Oct 2016 09:21:50 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 10 Oct 2016 09:21:50 -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=ophTu272kjJcH//+0+s5YlKuWQE=; b=dbVZjd GbcqkO1uiHKZk39/e5hqjuJ8UE0kkWfHS0LA0uWtsrJntc6+bUO6zxAREWfmA9/q STLTvjY3tQhUL7PlyJb/CNkW8se+8ek+N/PfwNXjxi8UkAiyGKFqhi8BzFQ9jSln 8BbD/3cFNERp8LUc0VRz2gNJAKTjOydrD6Hz4= 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=ophTu272kjJcH// +0+s5YlKuWQE=; b=AA8RlrN3f7Z/pf2uSAdgm7lWUF9zS8OSKOcAYcATLN1tiDo HfgG2lvCvDqr/T+Bj6wl45J3n5f8TIrC5QLEnQjti1YbMUGrqkA1uqk4YH4g/llV axgOYWT5wSgK/tEVmDKpXDOqlkoKHo4fSscwGSQkxtKWhqMUCGYkm36MPm24= X-Sasl-enc: T/WYH4J6Ob7rZ3t13ePzzcgOwzDhIjZ9R3VZpG/qNik7 1476105710 Received: from dhcp-10-150-9-141.cisco.com (unknown [173.38.117.65]) by mail.messagingengine.com (Postfix) with ESMTPA id 57EC4CC07D; Mon, 10 Oct 2016 09:21:50 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <4baa72c6-cd52-19d5-c070-4a19336c23ed@ericsson.com> Date: Mon, 10 Oct 2016 09:21:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <08A740FC-B283-404D-AF3C-E97D574E9642@cooperw.in> References: <1f645188-2344-ebf3-1228-3735bcf81338@ericsson.com> <4baa72c6-cd52-19d5-c070-4a19336c23ed@ericsson.com> To: "draft-ietf-webpush-protocol@ietf.org" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "webpush@ietf.org" Subject: Re: [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: Mon, 10 Oct 2016 13:21:54 -0000 The IESG will be reviewing this draft this week as it is scheduled for = the telechat on Thursday, so please post the -11 version as soon as = possible (including any text needed to address #4 below). Thanks, Alissa > On Oct 5, 2016, at 9:08 AM, Magnus Westerlund = wrote: >=20 > Hi, >=20 > I have looked at the pull request which looks good, with one very = minor comment that you should check out on github. >=20 > Cheers >=20 > Magnus >=20 >=20 > Den 2016-10-05 kl. 05:10, skrev Brian Raymor: >> I've created an initial pull request for review - >> https://github.com/webpush-wg/webpush-protocol/pull/131 - while we >> discuss whether there's additional guidance that can be shared for >> "4. Dealing with overload situations". >=20 >=20 >=20 >>=20 >>=20 >> -----Original Message----- From: Brian Raymor >> [mailto:Brian.Raymor@microsoft.com] Sent: Monday, October 3, 2016 >> 7:33 PM To: Magnus Westerlund ; >> tsv-art@ietf.org; draft-ietf-webpush-protocol@ietf.org; >> webpush@ietf.org; webpush-ads@ietf.org Subject: RE: Early TSV-ART >> review of draft-ietf-webpush-protocol-09 >>=20 >> Magnus - Thanks for the review. I'll have a pull request available >> tomorrow to address most of your feedback. In the interim, I've >> shared a few comments and clarifications below. >>=20 >> On September 27, 2016 3:28 AM, Magnus Westerlund >> wrote: >>=20 >> >>=20 >>> 3. Section 7.2: >>=20 >>> 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. >>=20 >>> 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? >>=20 >> This text should be clarified. There are two cases. First, the push >> service can only reduce the requested TTL in its response to a >> request from an application server to deliver a push message: >>=20 >> = https://tools.ietf.org/html/draft-ietf-webpush-protocol-10#section-5.2 >>=20 >> A push service MAY retain a push message for a shorter duration >> than requested. It indicates this by returning a TTL header field in >> its response with the actual TTL. This TTL value MUST be less than >> or equal to the value provided by the application server. >>=20 >> Second, if an application server subscribes to delivery receipts it >> will receive a 410 if the push service does not then honor that TTL: >>=20 >> = https://tools.ietf.org/html/draft-ietf-webpush-protocol-10#section-6.2 >>=20 >> The push service MAY cease to retry delivery of the message prior >> to its advertised expiration due to scenarios such as an >> unresponsive user agent or operational constraints. If the >> application has requested a delivery receipt, then the push service >> MUST return a 410 (Gone) response to the application server >> monitoring the receipt subscription. >>=20 >> If the application server does not subscribe to delivery receipts, >> then it's a fire-and-forget scenario. >>=20 >>> 4. Dealing with overload situations >>=20 >> Could webpush implementers review Magnus's questions below and >> consider whether there is further general guidance that can be >> offered based on their early experiences with the protocol? >>=20 >>> 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. >>=20 >>> 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? >>=20 >> Your assumption in this case is basically correct. The push service >> could also use the acknowledgements from the user agent as an >> indicator of overload and reduce the rate. >>=20 >>> 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? >>=20 >>> 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? >>=20 >> We decided on a 429. See >> https://www.ietf.org/mail-archive/web/webpush/current/msg00341.html - >> although it's also possible for the push service to terminate a >> subscription. >>=20 >> = https://tools.ietf.org/html/draft-ietf-webpush-protocol-10#section-8.4 >>=20 >> A push service MAY return a 429 (Too Many Requests) status code >> [RFC6585] when an application server has exceeded its rate limit for >> push message delivery to a push resource. The push service SHOULD >> also include a Retry-After header [RFC7231] to indicate how long the >> application server is requested to wait before it makes another >> request to the push resource. >>=20 >> A push service or user agent MAY also terminate subscriptions >> (Section 7.3) that receive too many push messages. >>=20 >>> 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. >>=20 >>> I would recommend that some recommendations are actually included >>> here for handling overload from application server message >>> submissions. >>=20 >>> 5. Life of subscription in relation to transports >>=20 >>> 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. >>=20 >> Especially for mobile and/or battery powered clients, the expectation >> is that the user agents will be dormant for extended periods of >> time. >>=20 >>> 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. >>=20 >>> 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. >>=20 >> I think that your assumption is correct. The behavior is specific to >> the push service. Implementers have requested the ability for a push >> service to terminate a subscription at will based on its internal >> policies. >>=20 >> Again, I'd ask that the webpush implementers share any general >> guidance or observations for this case. >>=20 >> >>=20 >>=20 >>=20 >=20 >=20 > --=20 >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 From nobody Mon Oct 10 09:42:13 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 DD3D61294B7; Mon, 10 Oct 2016 09:42:12 -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.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147611773290.31445.6966629762651541030.idtracker@ietfa.amsl.com> Date: Mon, 10 Oct 2016 09:42:12 -0700 Archived-At: Cc: webpush@ietf.org Subject: [Webpush] I-D Action: draft-ietf-webpush-protocol-11.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, 10 Oct 2016 16:42:13 -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-11.txt Pages : 33 Date : 2016-10-10 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-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-webpush-protocol-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 10 09:50: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 9ADA112973C; Mon, 10 Oct 2016 09:50:00 -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_H4=-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 rv3_M6S3aZxw; Mon, 10 Oct 2016 09:49:57 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0129.outbound.protection.outlook.com [104.47.42.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 C081712973A; Mon, 10 Oct 2016 09:49:57 -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=Yi9XF6PVD9L3VFLMBy9sN/+Z5pXSiYjGrYFljg69gSc=; b=iqGsc/Ub39tJ5DzUZOy48kjJnNDCm152P95olhQa73Fk5r3t3SWGaoU1I7l4AlWbWe0oOcWnrTFsyKaN/NWNhcBp5dwD1pLfllAQu55egkn25VkUTxebycJDWb/9AJ4u8CfMUx5XAvP3kW4UUvxEeWbD3QhH9yaHGqm3OYBSW0U= Received: from CY1PR03MB2380.namprd03.prod.outlook.com (10.167.8.6) by CY1PR03MB2380.namprd03.prod.outlook.com (10.167.8.6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Mon, 10 Oct 2016 16:49:56 +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.0659.020; Mon, 10 Oct 2016 16:49:56 +0000 From: Brian Raymor To: Alissa Cooper , "draft-ietf-webpush-protocol@ietf.org" Thread-Topic: Early TSV-ART review of draft-ietf-webpush-protocol-09 Thread-Index: AQHSGKne4rZHBz7KIU6jZUnx6IKSHaCXcP9wgAHHqeCAAKkcgIAH322AgAA4noA= Date: Mon, 10 Oct 2016 16:49:55 +0000 Message-ID: References: <1f645188-2344-ebf3-1228-3735bcf81338@ericsson.com> <4baa72c6-cd52-19d5-c070-4a19336c23ed@ericsson.com> <08A740FC-B283-404D-AF3C-E97D574E9642@cooperw.in> In-Reply-To: <08A740FC-B283-404D-AF3C-E97D574E9642@cooperw.in> 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: cd91b96a-9a5d-46ae-8120-08d3f12d7700 x-microsoft-exchange-diagnostics: 1; CY1PR03MB2380; 7:yeWNvUlw6L7oN1we8geMDUZZCTG8UI5qmbvlXM6Hwhc02Y6Vq9ELivXMfivSGASxIYuFZH2nGYqc51ZDutrG3l+T88pHhO+ZJlluLVFHPrgJharU3oPeOFvQocEdnpRfgqc0xf39rJdKdeRf+t1OLuUjLrxkGvpnh4YPls2idRuEf2EjTx6M+D7q8tagDimKdXF4ccN/Jp5jNp/lPek33Tl7KBCb6trUGQqQtO3yPLA0zaHXmQzsthq1vEr3HY7HNkB0l4Jbv6LNX0EeD0tx3UFQEH5xUpyhlX5Z76RB1DHGsFzO8xx8bE9khTkquMZ3BLOOh250kMYex+XfZJRJ9IVBZlIvOBYxRR5//W+bVvsFyxMb3l2u4hL/MaWbpEcA x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2380; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(158342451672863)(72170088055959)(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2380; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2380; x-forefront-prvs: 0091C8F1EB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(377424004)(199003)(13464003)(51444003)(24454002)(189002)(51914003)(102836003)(586003)(86612001)(15975445007)(76576001)(3846002)(5005710100001)(5002640100001)(66066001)(10090500001)(5660300001)(9686002)(19580395003)(68736007)(87936001)(2950100002)(3660700001)(3280700002)(81156014)(81166006)(10400500002)(19580405001)(2906002)(7696004)(8676002)(4326007)(77096005)(122556002)(86362001)(8936002)(2501003)(106116001)(106356001)(305945005)(33656002)(7846002)(5001770100001)(54356999)(50986999)(76176999)(74316002)(101416001)(11100500001)(93886004)(7736002)(8990500004)(230783001)(6116002)(10290500002)(189998001)(97736004)(92566002)(2900100001)(105586002)(99286002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2380; 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2016 16:49:55.9323 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2380 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [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: Mon, 10 Oct 2016 16:50:00 -0000 webpush-11 was published.=20 At this time, no further clarifications were added for #4. -----Original Message----- From: Alissa Cooper [mailto:alissa@cooperw.in]=20 Sent: Monday, October 10, 2016 6:22 AM To: draft-ietf-webpush-protocol@ietf.org Cc: webpush@ietf.org Subject: Re: Early TSV-ART review of draft-ietf-webpush-protocol-09 The IESG will be reviewing this draft this week as it is scheduled for the = telechat on Thursday, so please post the -11 version as soon as possible (i= ncluding any text needed to address #4 below). Thanks, Alissa > On Oct 5, 2016, at 9:08 AM, Magnus Westerlund wrote: >=20 > Hi, >=20 > I have looked at the pull request which looks good, with one very minor c= omment that you should check out on github. >=20 > Cheers >=20 > Magnus >=20 >=20 > Den 2016-10-05 kl. 05:10, skrev Brian Raymor: >> I've created an initial pull request for review - >> https://github.com/webpush-wg/webpush-protocol/pull/131 - while we >> discuss whether there's additional guidance that can be shared for >> "4. Dealing with overload situations". >=20 >=20 >=20 >>=20 >>=20 >> -----Original Message----- From: Brian Raymor >> [mailto:Brian.Raymor@microsoft.com] Sent: Monday, October 3, 2016 >> 7:33 PM To: Magnus Westerlund ; >> tsv-art@ietf.org; draft-ietf-webpush-protocol@ietf.org; >> webpush@ietf.org; webpush-ads@ietf.org Subject: RE: Early TSV-ART >> review of draft-ietf-webpush-protocol-09 >>=20 >> Magnus - Thanks for the review. I'll have a pull request available >> tomorrow to address most of your feedback. In the interim, I've >> shared a few comments and clarifications below. >>=20 >> On September 27, 2016 3:28 AM, Magnus Westerlund >> wrote: >>=20 >> >>=20 >>> 3. Section 7.2: >>=20 >>> 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. >>=20 >>> 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? >>=20 >> This text should be clarified. There are two cases. First, the push >> service can only reduce the requested TTL in its response to a >> request from an application server to deliver a push message: >>=20 >> https://tools.ietf.org/html/draft-ietf-webpush-protocol-10#section-5.2 >>=20 >> A push service MAY retain a push message for a shorter duration >> than requested. It indicates this by returning a TTL header field in >> its response with the actual TTL. This TTL value MUST be less than >> or equal to the value provided by the application server. >>=20 >> Second, if an application server subscribes to delivery receipts it >> will receive a 410 if the push service does not then honor that TTL: >>=20 >> https://tools.ietf.org/html/draft-ietf-webpush-protocol-10#section-6.2 >>=20 >> The push service MAY cease to retry delivery of the message prior >> to its advertised expiration due to scenarios such as an >> unresponsive user agent or operational constraints. If the >> application has requested a delivery receipt, then the push service >> MUST return a 410 (Gone) response to the application server >> monitoring the receipt subscription. >>=20 >> If the application server does not subscribe to delivery receipts, >> then it's a fire-and-forget scenario. >>=20 >>> 4. Dealing with overload situations >>=20 >> Could webpush implementers review Magnus's questions below and >> consider whether there is further general guidance that can be >> offered based on their early experiences with the protocol? >>=20 >>> 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. >>=20 >>> 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? >>=20 >> Your assumption in this case is basically correct. The push service >> could also use the acknowledgements from the user agent as an >> indicator of overload and reduce the rate. >>=20 >>> 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? >>=20 >>> 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? >>=20 >> We decided on a 429. See >> https://www.ietf.org/mail-archive/web/webpush/current/msg00341.html - >> although it's also possible for the push service to terminate a >> subscription. >>=20 >> https://tools.ietf.org/html/draft-ietf-webpush-protocol-10#section-8.4 >>=20 >> A push service MAY return a 429 (Too Many Requests) status code >> [RFC6585] when an application server has exceeded its rate limit for >> push message delivery to a push resource. The push service SHOULD >> also include a Retry-After header [RFC7231] to indicate how long the >> application server is requested to wait before it makes another >> request to the push resource. >>=20 >> A push service or user agent MAY also terminate subscriptions >> (Section 7.3) that receive too many push messages. >>=20 >>> 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. >>=20 >>> I would recommend that some recommendations are actually included >>> here for handling overload from application server message >>> submissions. >>=20 >>> 5. Life of subscription in relation to transports >>=20 >>> 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. >>=20 >> Especially for mobile and/or battery powered clients, the expectation >> is that the user agents will be dormant for extended periods of >> time. >>=20 >>> 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. >>=20 >>> 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. >>=20 >> I think that your assumption is correct. The behavior is specific to >> the push service. Implementers have requested the ability for a push >> service to terminate a subscription at will based on its internal >> policies. >>=20 >> Again, I'd ask that the webpush implementers share any general >> guidance or observations for this case. >>=20 >> >>=20 >>=20 >>=20 >=20 >=20 > --=20 >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 From nobody Tue Oct 11 06:17: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 C9D7B1294DF for ; Tue, 11 Oct 2016 06:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_H2=-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=cooperw.in header.b=ZIocmvai; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=ag+205zX 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 Vv2cXbrNqLwL for ; Tue, 11 Oct 2016 06:17:30 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 098C212946E for ; Tue, 11 Oct 2016 06:17:30 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 4CF0B2089F for ; Tue, 11 Oct 2016 09:17:29 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Tue, 11 Oct 2016 09:17:29 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= 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=u6N8uL27M86uFKxn9qzGDKXr4CU=; b=ZIocmv aisxe59MSxZNYwwgV725rW3P+heXbsTPFkqQbjicBJAlAzijWsCiM7eEpun4NYvx xAWQZtzLITno9Nzt/5YBeLwpTpneHN4phSpWs52CZSQRsn85ChWASgGem1j8tLCa bNtJmZKh1YWb/V/PNqHgLECC1hSidKME7hmew= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=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=u6N8uL27M86uFKx n9qzGDKXr4CU=; b=ag+205zXfwSVX5LrquQz4C/r9vxbisjJH+aHiVlie6jTqin ecNzv28WCxaiZQ8Vn3FCgcYlASpDSFCwzfMrHTiDEIX/UHDxQhE2Jh0goKL5wbIp Zny3Ae6TTEDSFLZy8WaAFzx4A4IF9g+G8aYxsrmq1gnmHYVoBE5mdhTTfYTw= X-Sasl-enc: siCf4TWcTOmVN9H8N5kCNknbXfrVU/6HaTDCxd4S2XmZ 1476191849 Received: from dhcp-10-150-9-172.cisco.com (unknown [173.38.117.90]) by mail.messagingengine.com (Postfix) with ESMTPA id 03DCBF2985 for ; Tue, 11 Oct 2016 09:17:28 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: Date: Tue, 11 Oct 2016 09:17:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9D4B66B4-C906-4D39-B124-3CB761DA394C@cooperw.in> References: <147499081575.4580.11302740752421976418.idtracker@ietfa.amsl.com> To: webpush@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Webpush] [IANA #929427] Last Call: (Generic Event Delivery Using HTTP Push) to Proposed Standard 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, 11 Oct 2016 13:17:33 -0000 I had assumed that port 1001 was specified in this document because = it=E2=80=99s already in use. Assuming the authors definitely want 1001 = assigned for this purpose, the WG chairs will need to do a quick = consensus call about requesting early allocation for port 1001. Assuming = the WG has consensus to do that, the chairs can then send a request for = early allocation to IANA. Thanks, Alissa > On Oct 10, 2016, at 5:34 PM, Sabrina Tanamal via RT = wrote: > ... > Fourth, this document requests that the IANA Services Operator = register system port number 1001. However, we cannot reserve specific = numbers. >=20 > We can make a temporary one-year early allocation, to be marked = "TEMPORARY" in the registry, which could be renewed for another year if = this I-D has not yet been approved for publication by the allocation's = expiration date. This procedure is described in RFC 7120. In short, = after obtaining approval from the group and the AD, the webpush chairs = should send a request for early allocation of system port number 1001 to = iana@iana.org. >=20 > We understand that these are the only actions required to be completed = upon approval of this document. >=20 > Note: The actions requested in this document will not be completed = until the document has been approved for publication as an RFC. This = message is only to confirm what actions will be performed.=20 >=20 > Please note that specific values cannot be reserved. However, early = allocation is available for some types of registrations. For more = information, please see RFC 7120. >=20 > Thank you, >=20 > Sabrina Tanamal > IANA Services Specialist >=20 > (END IANA COMMENTS) >=20 From nobody Tue Oct 11 09:17: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 B5C08129444 for ; Tue, 11 Oct 2016 09:17:30 -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 8R8z3PPRoWp1 for ; Tue, 11 Oct 2016 09:17:28 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0126.outbound.protection.outlook.com [104.47.41.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1768E1293E0 for ; Tue, 11 Oct 2016 09:17: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=W0Hpf9LRDKe5uvGn2CNpweVmd91zr3wtzXer7EW8Xvc=; b=NitTyPifcwBDAoRiUa1PTYW2JgnSUo4FfW9dcXvTJIngwFVHTPPB5CqzQOfxyMiPV9hT7xh4HMb2M/T4lYpcq1XbfHWobknnseXTHFvLGG5PGP1N1o4Wgctva2qxWlz+BuQqOI6e6ZxYNK7p3i2jM+Yy0xVx/hzMKd6sx+K/uw8= 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_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.649.16; Tue, 11 Oct 2016 16:17:25 +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.0659.020; Tue, 11 Oct 2016 16:17:25 +0000 From: Brian Raymor To: Alissa Cooper , "webpush@ietf.org" Thread-Topic: [Webpush] [IANA #929427] Last Call: (Generic Event Delivery Using HTTP Push) to Proposed Standard Thread-Index: AQHSIz4V1kPJKXnEJkmlSleo4LGfmaCjPSWAgAAvBIA= Date: Tue, 11 Oct 2016 16:17:25 +0000 Message-ID: References: <147499081575.4580.11302740752421976418.idtracker@ietfa.amsl.com> <9D4B66B4-C906-4D39-B124-3CB761DA394C@cooperw.in> In-Reply-To: <9D4B66B4-C906-4D39-B124-3CB761DA394C@cooperw.in> 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: bf0f83c3-ae68-4b1f-60fd-08d3f1f216f3 x-microsoft-exchange-diagnostics: 1; CY1PR03MB2377; 7:Riu/ZxVJfIyE5F+d4yjY1k0Crl6jMze0W7mT2ylSha8SDXY4HMUUHJaayoFLYiEsMMG/S8hFppt+FFDbV7qDjAzwNslgCTLFdqPpuES+KFZ1LrRCjAIp8R9HGeqwFmzh+Sr+Lxp/yySkvfP2dXGVasQCMlVfaGdzHuYJ/VeccqIR9P8yx+eAtHjdKeIrETvXT+klcqUe+q0xSGpxpOckEHp30hFR+pcoySRe5mXwa48TkAi5V5WMzy+UOupZ3pkbvxOZaCK3AMOCqFNkVX+jC++WjKbYdw59joOmMF0QDMNX3p9FZd4vDbBIdsq67QzY21LGdNoxJ28BmaQqFgA+6Lnhcs1MvO0mBxlUNOGLwhqkaDMqk7W7JSqQxo53s0WD x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2377; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2377; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2377; x-forefront-prvs: 00922518D8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(199003)(24454002)(189002)(76576001)(102836003)(107886002)(81166006)(81156014)(7736002)(87936001)(2906002)(6116002)(66066001)(8676002)(2950100002)(97736004)(101416001)(8936002)(92566002)(2501003)(8990500004)(19580395003)(305945005)(5005710100001)(10290500002)(19580405001)(7846002)(11100500001)(3846002)(7696004)(10400500002)(10090500001)(586003)(5660300001)(189998001)(3660700001)(99286002)(5001770100001)(230783001)(3280700002)(105586002)(15975445007)(50986999)(74316002)(9686002)(54356999)(106116001)(77096005)(122556002)(106356001)(76176999)(33656002)(68736007)(5002640100001)(86362001)(93886004)(2900100001)(86612001)(41533002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2377; 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2016 16:17:25.5887 (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] [IANA #929427] Last Call: (Generic Event Delivery Using HTTP Push) to Proposed Standard 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, 11 Oct 2016 16:17:31 -0000 DQpPbiBPY3RvYmVyIDExLCAyMDE2LCBhdCA2OjE3IEFNLCBBbGlzc2EgQ29vcGVyIDxhbGlzc2FA Y29vcGVydy5pbj4gd3JvdGU6DQoNCj4gSSBoYWQgYXNzdW1lZCB0aGF0IHBvcnQgMTAwMSB3YXMg c3BlY2lmaWVkIGluIHRoaXMgZG9jdW1lbnQgYmVjYXVzZSBpdOKAmXMgYWxyZWFkeSBpbiB1c2Uu DQo+IEFzc3VtaW5nIHRoZSBhdXRob3JzIGRlZmluaXRlbHkgd2FudCAxMDAxIGFzc2lnbmVkIGZv ciB0aGlzIHB1cnBvc2UsIHRoZSBXRyBjaGFpcnMgd2lsbA0KPiBuZWVkIHRvIGRvIGEgcXVpY2sg Y29uc2Vuc3VzIGNhbGwgYWJvdXQgcmVxdWVzdGluZyBlYXJseSBhbGxvY2F0aW9uIGZvciBwb3J0 IDEwMDEuIEFzc3VtaW5nDQo+IHRoZSBXRyBoYXMgY29uc2Vuc3VzIHRvIGRvIHRoYXQsIHRoZSBj aGFpcnMgY2FuIHRoZW4gc2VuZCBhIHJlcXVlc3QgZm9yIGVhcmx5IGFsbG9jYXRpb24gdG8gSUFO QS4NCg0KSWYgaXQgd291bGQgYmUgc2ltcGxlciwgdGhlbiBpdCB3b3VsZCBiZSBhY2NlcHRhYmxl IHRvIGNoYW5nZSAxMDAxIHRvIFRCRCBhbmQgcmVxdWVzdCBJQU5BIHRvDQptYWtlIHRoZSBhc3Np Z25tZW50Lg0KDQpUaGlzIGlzIHJlbGF0ZWQgdG8gaHR0cHM6Ly9naXRodWIuY29tL3dlYnB1c2gt d2cvd2VicHVzaC1wcm90b2NvbC9pc3N1ZXMvMzcuIFdlIGNvdWxkIG5vdCBzcGVjaWZ5IHRoZSBw b3J0DQpudW1iZXJzIHRoYXQgYXJlIGN1cnJlbnRseSBpbiB1c2UgZm9yIHB1c2ggc2VydmljZXMg YmVjYXVzZSA1MjIzIGFuZCA1MjI4IGFyZSBhbHJlYWR5IHJlZ2lzdGVyZWQgd2l0aCBJQU5BIGZv ciANCm90aGVyIHByb3RvY29scy4gKFRoZSBwb3J0cyBhcmUgcmVnaXN0ZXJlZCB0byBocHZpcnRn cnAgYW5kIGhwdnJvb20sIGFsdGhvdWdoIHVub2ZmaWNpYWxseSB1c2VkIGJ5IEFQTlMgYW5kIEdD TS4pDQpJbiByZXZpZXdpbmcgUkZDNjMzNSBTZWN0aW9uIDguMS4xLCBwZXJoYXBzIEkgbWlzaW50 ZXJwcmV0ZWQgdGhlIGd1aWRhbmNlIHRvIHByb3ZpZGUgYSBzdWdnZXN0aW9uIHRvIElBTkEsIHdo aWNoDQppcyB3aHkgMTAwMSB3YXMgcmVxdWVzdGVkOg0KDQpodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjNjMzNQ0KDQogICBvICBQb3J0IE51bWJlcjogSWYgYXNzaWdubWVudCBvZiBhIHBv cnQgbnVtYmVyIGlzIGRlc2lyZWQsIGVpdGhlciB0aGUNCiAgICAgIHBvcnQgbnVtYmVyIHRoZSBy ZXF1ZXN0ZXIgc3VnZ2VzdHMgZm9yIGFzc2lnbm1lbnQgb3IgaW5kaWNhdGlvbiBvZg0KICAgICAg cG9ydCByYW5nZSAodXNlciBvciBzeXN0ZW0pIE1VU1QgYmUgcHJvdmlkZWQuICBJZiBvbmx5IGEg c2VydmljZQ0KICAgICAgbmFtZSBpcyB0byBiZSBhc3NpZ25lZCwgdGhpcyBmaWVsZCBpcyBsZWZ0 IGVtcHR5LiAgSWYgYSBzcGVjaWZpYw0KICAgICAgcG9ydCBudW1iZXIgaXMgcmVxdWVzdGVkLCBJ QU5BIGlzIGVuY291cmFnZWQgdG8gYXNzaWduIHRoZQ0KICAgICAgcmVxdWVzdGVkIG51bWJlci4g IElmIGEgcmFuZ2UgaXMgc3BlY2lmaWVkLCBJQU5BIHdpbGwgY2hvb3NlIGENCiAgICAgIHN1aXRh YmxlIG51bWJlciBmcm9tIHRoZSBVc2VyIG9yIFN5c3RlbSBQb3J0cyByYW5nZXMuICBOb3RlIHRo YXQNCiAgICAgIHRoZSBhcHBsaWNhbnQgTVVTVCBOT1QgdXNlIHRoZSByZXF1ZXN0ZWQgcG9ydCBp biBpbXBsZW1lbnRhdGlvbnMNCiAgICAgIGRlcGxveWVkIGZvciB1c2Ugb24gdGhlIHB1YmxpYyBJ bnRlcm5ldCBwcmlvciB0byB0aGUgY29tcGxldGlvbiBvZg0KICAgICAgdGhlIGFzc2lnbm1lbnQs IGJlY2F1c2UgdGhlcmUgaXMgbm8gZ3VhcmFudGVlIHRoYXQgSUFOQSB3aWxsDQogICAgICBhc3Np Z24gdGhlIHJlcXVlc3RlZCBwb3J0Lg0KDQouLi5Ccmlhbg0K From nobody Tue Oct 11 12:40: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 4101B129633 for ; Tue, 11 Oct 2016 12:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_H2=-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=cooperw.in header.b=BdDj1bM3; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=X0dL/SZE 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 RRJLPInFiD1d for ; Tue, 11 Oct 2016 12:40:01 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30B271294B7 for ; Tue, 11 Oct 2016 12:40:01 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 7F702205CE; Tue, 11 Oct 2016 15:40:00 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Tue, 11 Oct 2016 15:40: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=C1+ZG0OUqlo3Jz1YhgOmcFbxULU=; b=BdDj1b M3a9FmgqaDcyygp+5DMK0FkQKcJygqbEUfde8xBv+DKuKVuAtWMu0z6fWRJuUUz7 axBNuviGpnq92NLovPMWv/p+89EAzERpC84G6btdOL2AmtGoenXTi4tBmSl2yEqj c+e+iovd9FUbwX+Qq8b8tn+jOxKr999gmHsUE= 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=C1+ZG0OUqlo3Jz1 YhgOmcFbxULU=; b=X0dL/SZEmYJMfQi7Dd23VS1FSPl85UYgsdCehw8QPg1g0h1 lJNMDfGbHupHdjsjz0iTQPPSIs8ch5tout8nr0ZosCUPuuF/NyMa2CdyYK901N4U Ad6ALlKh6xLfT7WjsMbPif3UqSOTXlEYwbi7d4evX5Aheuqk/YOdOAXC5a2Y= X-Sasl-enc: rXqX3IWzUwMvsfMs5F97YIR+1IJcKAYp2Krteq+vusC9 1476214800 Received: from dhcp-10-150-9-172.cisco.com (unknown [173.38.117.90]) by mail.messagingengine.com (Postfix) with ESMTPA id 26920F2988; Tue, 11 Oct 2016 15:40:00 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: Date: Tue, 11 Oct 2016 15:39:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8E0B3D9D-3194-4321-B928-1BC9D4D0508B@cooperw.in> References: <147499081575.4580.11302740752421976418.idtracker@ietfa.amsl.com> <9D4B66B4-C906-4D39-B124-3CB761DA394C@cooperw.in> To: Brian Raymor X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] [IANA #929427] Last Call: (Generic Event Delivery Using HTTP Push) to Proposed Standard 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, 11 Oct 2016 19:40:03 -0000 > On Oct 11, 2016, at 12:17 PM, Brian Raymor = wrote: >=20 >=20 > On October 11, 2016, at 6:17 AM, Alissa Cooper = wrote: >=20 >> I had assumed that port 1001 was specified in this document because = it=E2=80=99s already in use. >> Assuming the authors definitely want 1001 assigned for this purpose, = the WG chairs will >> need to do a quick consensus call about requesting early allocation = for port 1001. Assuming >> the WG has consensus to do that, the chairs can then send a request = for early allocation to IANA. >=20 > If it would be simpler, then it would be acceptable to change 1001 to = TBD and request IANA to > make the assignment. >=20 > This is related to = https://github.com/webpush-wg/webpush-protocol/issues/37. We could not = specify the port > numbers that are currently in use for push services because 5223 and = 5228 are already registered with IANA for=20 > other protocols. (The ports are registered to hpvirtgrp and hpvroom, = although unofficially used by APNS and GCM.) > In reviewing RFC6335 Section 8.1.1, perhaps I misinterpreted the = guidance to provide a suggestion to IANA, which > is why 1001 was requested: >=20 > https://tools.ietf.org/html/rfc6335 >=20 > o Port Number: If assignment of a port number is desired, either = the > port number the requester suggests for assignment or indication = of > port range (user or system) MUST be provided. If only a service > name is to be assigned, this field is left empty. If a specific > port number is requested, IANA is encouraged to assign the > requested number. If a range is specified, IANA will choose a > suitable number from the User or System Ports ranges. Note that > the applicant MUST NOT use the requested port in implementations > deployed for use on the public Internet prior to the completion = of > the assignment, because there is no guarantee that IANA will > assign the requested port. Ah, I see. Since it=E2=80=99s not already in use I think the right thing = to do is to request 1001 if it=E2=80=99s available, or another port = number in the range if it=E2=80=99s not. I believe the problem for IANA = is that it=E2=80=99s possible that 1001 will be assigned before this = document gets published (by another document in the RFC Editor=E2=80=99s = queue ahead of this one, for example). Let me run that by IANA and = confirm. Alissa=20 >=20 > ...Brian From nobody Wed Oct 12 05:47: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 30C641294EE; Wed, 12 Oct 2016 05:47:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147627647715.24195.7361128430619980058.idtracker@ietfa.amsl.com> Date: Wed, 12 Oct 2016 05:47:57 -0700 Archived-At: Cc: draft-ietf-webpush-protocol@ietf.org, shida@ntt-at.com, webpush-chairs@ietf.org, webpush@ietf.org Subject: [Webpush] Alissa Cooper's Yes on draft-ietf-webpush-protocol-11: (with COMMENT) 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, 12 Oct 2016 12:47:57 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-webpush-protocol-11: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-webpush-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Resolution of IANA's issue regarding port 1001 has been merged on git, awaiting potential further updates resulting from IESG review. https://github.com/webpush-wg/webpush-protocol/pull/133/files From nobody Wed Oct 12 07:39:46 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 74A171294CF; Wed, 12 Oct 2016 07:39:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147628318443.27316.12918309346360247871.idtracker@ietfa.amsl.com> Date: Wed, 12 Oct 2016 07:39:44 -0700 Archived-At: Cc: draft-ietf-webpush-protocol@ietf.org, shida@ntt-at.com, webpush-chairs@ietf.org, webpush@ietf.org Subject: [Webpush] Alexey Melnikov's Discuss on draft-ietf-webpush-protocol-11: (with DISCUSS and COMMENT) 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, 12 Oct 2016 14:39:44 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-webpush-protocol-11: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-webpush-protocol/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is generally a well written document, but I have a small list of issues (which should be easy to address) I would like to discuss before recommending its approval for publication: 1) In 5.2: is there upper limit on the TTL? The ABNF doesn't restrict the value, but it is important for interoperability 2) In 5.3: urgency is defined as a list of one or more values. The description says that it defines the lowest value allowed. There is also a sentence prohibiting multiple values. Why is this a set and how would multiple values be interpreted? 3) In 6: I don't know where the ":link" Pseudo-Header field came from. Can you clarify where it is defined? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1) I see you defined a new HTTP Header Field "Urgency". Can you reuse email header field "Priority" instead (possibly extending it) Can be 'normal', 'urgent', or 'non-urgent' and can influence transmission speed and delivery. ? 2) In 4.1: Can 429 be used when no subscription set is specified? (If yes, this should be mentioned in section 4). 3) In 6.1: ":link" is included in the PUSH_PROMISE and not the HEADERS block (when compared to section 6). Is this intentional or should one of the examples be fixed? 4) In general case it is not possible to achieve message reliability because a push server is allowed to expire messages after they were accepted for delivery due to overload. (Similarly for forced subscription expiration.) I don't think the document makes this clear in Section 7.4. 5) In 9.3: Contact: IETF Chair - I think you should point to the WG mailing list or IESG as a whole. IETF Chair has other things to do than answer questions about IANA port registration :-). From nobody Wed Oct 12 07:49: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 A62C2129553; Wed, 12 Oct 2016 07:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_H2=-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=cooperw.in header.b=UAzUHHoA; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=R4pKJH4T 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 rRt4CGvsbLWw; Wed, 12 Oct 2016 07:48:56 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9FD812954B; Wed, 12 Oct 2016 07:48:52 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 4633A2070C; Wed, 12 Oct 2016 10:48:52 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Wed, 12 Oct 2016 10:48:52 -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=HEvgf 2WCUu3brT8010M17k88pio=; b=UAzUHHoAZcVEgK5u/czgy+LV45k5SuahBTUbH +0vekF/+WotBfflBRhiRqhDk/YTKm8WJgSXdZ4fYVo59m+iSht40C91qq+SzhWOB /INjBcieb8rhbP+5CCuM4YnkEEQBOtOZb43bQJ98QEr2Cn/njJ315qv0oAcuqiiy 33csy4= 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=HEvgf2WCUu3brT8010M17k88pio=; b=R4pKJ H4TBIoEStk3Kvou9Uphm2RySqQk8wQOz2i7gTKHV7kusHZy6tKepkzOCfJ/4U7bt hYCWv64y2iASldmyhq/U/3y37KmRxnAU/eArwzwGR+NX6TKcvLctBW/Z8G1DvS7h bmv1pBNfiMxORm8sbUVUpsV4WjbYbQAHBQ9lRg= X-Sasl-enc: o11CnM9RxShIb46jRpBFGfKZNSOHqMc1p/Fz4lMpj62s 1476283731 Received: from sjc-alcoop-8812.cisco.com (unknown [128.107.241.179]) by mail.messagingengine.com (Postfix) with ESMTPA id F1830F29CD; Wed, 12 Oct 2016 10:48:50 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_4EA097D1-72D6-46AE-9A0F-6447C1332471" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <147628318443.27316.12918309346360247871.idtracker@ietfa.amsl.com> Date: Wed, 12 Oct 2016 10:48:49 -0400 Message-Id: <04E15ABA-F8A8-47BB-B9C9-B6B7DE513480@cooperw.in> References: <147628318443.27316.12918309346360247871.idtracker@ietfa.amsl.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3124) Archived-At: Cc: draft-ietf-webpush-protocol@ietf.org, Shida Schubert , webpush-chairs@ietf.org, IESG , webpush@ietf.org Subject: Re: [Webpush] Alexey Melnikov's Discuss on draft-ietf-webpush-protocol-11: (with DISCUSS and COMMENT) 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, 12 Oct 2016 14:48:57 -0000 --Apple-Mail=_4EA097D1-72D6-46AE-9A0F-6447C1332471 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Oct 12, 2016, at 10:39 AM, Alexey Melnikov = wrote: >=20 > 5) In 9.3: >=20 > Contact: IETF Chair >=20 > - I think you should point to the WG mailing list or IESG as a whole. > IETF Chair has other things to do than answer questions about IANA = port > registration :-). >=20 >=20 Actually IETF chair is the contact mandated by RFC 6335: = https://tools.ietf.org/html/rfc6335#section-8.1 = . Agree with your point = but I had asked the authors to change this to conform to 6335. Alissa= --Apple-Mail=_4EA097D1-72D6-46AE-9A0F-6447C1332471 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Oct 12, 2016, at 10:39 AM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:

5) In 9.3:

Contact: IETF Chair

- I think = you should point to the WG mailing list or IESG as a whole.
IETF Chair has other things to do than answer questions about = IANA port
registration :-).


Actually IETF chair is the contact mandated by RFC = 6335: https://tools.ietf.org/html/rfc6335#section-8.1. Agree = with your point but I had asked the authors to change this to conform to = 6335.

Alissa
= --Apple-Mail=_4EA097D1-72D6-46AE-9A0F-6447C1332471-- From nobody Wed Oct 12 07: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 A696A129478; Wed, 12 Oct 2016 07:54:30 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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=fastmail.fm header.b=VL+QCmiX; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=Ue4Zvcx3 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 do2sXufsSgwP; Wed, 12 Oct 2016 07:54:29 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2503D126B6D; Wed, 12 Oct 2016 07:54:16 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 6744E207F2; Wed, 12 Oct 2016 10:54:15 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute4.internal (MEProxy); Wed, 12 Oct 2016 10:54:15 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; 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=+39GDquWxYLjh6eicCkE2aTjdVU=; b=VL+QCm iXe+JUMR3V4UbhDfEm+w/hJnT1KOEG1hu2DB6kpi+84CtDCNF+6dB1MLPVfqTRTS 07qYXEac7LstRfP5FgFI3Ns+G1piXN105k0xP94U8ODriilHfs/3k5XmXEDO+czG SklVwhz9gEqSo3L+ilUhUPF7+D3Sq4pqSELcY= 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=+39GDquWxYLjh6e icCkE2aTjdVU=; b=Ue4Zvcx3JPw+cBs5PEm917yg3O4+ffcvpsveLfx99Me0mHk 2VL6FJzhgJhmw/SXdd+qHgFk/vHWx5XlJUidMIhEdT2pEmduDeHZNOqlyt1hZqtx G/4sga0Tgn58TzacOmw1er9WkqIkQcmfdnRezvkoXM+JTfvdbbdAoeF6GV2w= Received: by mailuser.nyi.internal (Postfix, from userid 99) id 3C24A96883; Wed, 12 Oct 2016 10:54:15 -0400 (EDT) Message-Id: <1476284055.1321637.753695665.10AF37AF@webmail.messagingengine.com> X-Sasl-Enc: FgzJuki9Xl3wagnVoHrNf8n6ojfEir56RORkgpcx2zYy 1476284055 From: Alexey Melnikov To: Alissa Cooper MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_147628405513216371"; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-cdbff290 In-Reply-To: <04E15ABA-F8A8-47BB-B9C9-B6B7DE513480@cooperw.in> References: <147628318443.27316.12918309346360247871.idtracker@ietfa.amsl.com> <04E15ABA-F8A8-47BB-B9C9-B6B7DE513480@cooperw.in> Date: Wed, 12 Oct 2016 15:54:15 +0100 Archived-At: Cc: draft-ietf-webpush-protocol@ietf.org, Shida Schubert , webpush-chairs@ietf.org, IESG , webpush@ietf.org Subject: Re: [Webpush] Alexey Melnikov's Discuss on draft-ietf-webpush-protocol-11: (with DISCUSS and COMMENT) 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, 12 Oct 2016 14:54:30 -0000 This is a multi-part message in MIME format. --_----------=_147628405513216371 Content-Transfer-Encoding: 7bit Content-Type: text/plain On Wed, Oct 12, 2016, at 03:48 PM, Alissa Cooper wrote: > >> On Oct 12, 2016, at 10:39 AM, Alexey Melnikov >> wrote: >> >> 5) In 9.3: >> >> Contact: IETF Chair >> >> - I think you should point to the WG mailing list or IESG as a whole. >> IETF Chair has other things to do than answer questions about >> IANA port >> registration :-). >> > > Actually IETF chair is the contact mandated by RFC 6335: > https://tools.ietf.org/html/rfc6335#section-8.1. Agree with your point > but I had asked the authors to change this to conform to 6335. Ah, Ok. So arguably my fault, as I was the responsible AD for RFC 6335 :-). --_----------=_147628405513216371 Content-Transfer-Encoding: 7bit Content-Type: text/html
On Wed, Oct 12, 2016, at 03:48 PM, Alissa Cooper wrote:

On Oct 12, 2016, at 10:39 AM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:

5) In 9.3:

Contact: IETF Chair

- I think you should point to the WG mailing list or IESG as a whole.
IETF Chair has other things to do than answer questions about IANA port
registration :-).


Actually IETF chair is the contact mandated by RFC 6335: https://tools.ietf.org/html/rfc6335#section-8.1. Agree with your point but I had asked the authors to change this to conform to 6335.

Ah, Ok. So arguably my fault, as I was the responsible AD for RFC 6335 :-).
--_----------=_147628405513216371-- From nobody Wed Oct 12 08:36: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 6F0C71200DF; Wed, 12 Oct 2016 08:35: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 gFmIZOktzjF6; Wed, 12 Oct 2016 08:35:56 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::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 51642129411; Wed, 12 Oct 2016 08:35:56 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id f128so36247079qkb.1; Wed, 12 Oct 2016 08:35:56 -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=HyKinFGeI5/iBNZkavKm35fJvb9QEFG38l5tIqBhm+w=; b=aTojmqulcsaFoxYRiwBCN1IAX6KjljolTni4CLqlzlIC1tfBop6Aqg21SnS8540YmS yyICt9R+2oa2txBn3c3iBOLxhenbb37WgAVpjb1/DmA5uFfKFR6tDgHspUbvWxoZMWio l02Az6fDnWhaqvQ+6JBxjNd3dpbdOZe1yFR45Y8UDcXHCdQ3j7UYSHekS3/ipp2qAqgZ I4sspNItSwjqSDlQrPvd5jIR27NO1EiYdqbR/p9PgbXV4Z3SZYtRd+bPs7rZlAuqkQ7I IRmKFy7u8tRShHc7yBLqiJ4cFhLyGmEk3FLpDsC/Bf/Vw0k113yXHx+QfP9/yvkBOuX8 lyYQ== 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=HyKinFGeI5/iBNZkavKm35fJvb9QEFG38l5tIqBhm+w=; b=HHb/ZWH4Aa7MrCqNJbjo+W8mpYnrjbmPw6xKtnxhcw2bTQz09mV45wKq0Ug7vKBSDm WKPewPUHgybI3eu++imszjfeH7/oY04re4RdzZ1JCFz6ur5xSSkF3BljGRJHz7JqNLI+ hc9nTOoYILokntMeyUYOV/MlcFC4zQBNGq6JHQKnj+5gWixfa0lt6i4unK3XkiarnhA8 v3igNT5s5knO3EidYWwsLGTaU4xddnvKwFyFdV7mjxzXcUSs7gN4+Ar/efr2AbRL+gvU r5XBYeItGpQD75WwVnxELLOEBWhOAkNKJ3Y/bOCGWrdi9jluVJOWSJ1iHhEI8mmP/FHZ KOaA== X-Gm-Message-State: AA6/9Rki5TS15pe279TDFtpcE0c6H3n1PVd9c8IeZPESad0F5/QkCsVUwu4/cv02v18U9RUwrXLwtPdo35Aksw== X-Received: by 10.55.99.17 with SMTP id x17mr1657540qkb.147.1476286554787; Wed, 12 Oct 2016 08:35:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Wed, 12 Oct 2016 08:35:54 -0700 (PDT) In-Reply-To: <147628318443.27316.12918309346360247871.idtracker@ietfa.amsl.com> References: <147628318443.27316.12918309346360247871.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Thu, 13 Oct 2016 02:35:54 +1100 Message-ID: To: Alexey Melnikov Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-webpush-protocol@ietf.org, Shida Schubert , webpush-chairs@ietf.org, The IESG , "webpush@ietf.org" Subject: Re: [Webpush] Alexey Melnikov's Discuss on draft-ietf-webpush-protocol-11: (with DISCUSS and COMMENT) 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, 12 Oct 2016 15:35:58 -0000 Hi Alexey, Thanks for going through this so thoroughly. Most of these are - as you say - trivial, and I have PRs for the issues that you identified, see below. On 13 October 2016 at 01:39, Alexey Melnikov wrote: > 1) In 5.2: is there upper limit on the TTL? The ABNF doesn't restrict the > value, but it is important for interoperability Magnus Westerlund noted the same problem, so we've cribbed some text from other HTTP documents. You can see the updated text here: https://github.com/webpush-wg/webpush-protocol/pull/131 > 2) In 5.3: urgency is defined as a list of one or more values. The > description says that it defines the lowest value allowed. There is also > a sentence prohibiting multiple values. Why is this a set and how would > multiple values be interpreted? This was in keeping with providing a definition for the header field that is consistent with other HTTP header fields, but I believe that you are correct in that the list construction in the ABNF is a hazard rather than a feature: https://github.com/webpush-wg/webpush-protocol/pull/135 > 3) In 6: > > I don't know where the ":link" Pseudo-Header field came from. Can you > clarify where it is defined? Pure editorial error, it's a real header field, as in RFC 5988: https://github.com/webpush-wg/webpush-protocol/pull/134 > 1) > I see you defined a new HTTP Header Field "Urgency". Can you reuse email > header field "Priority" instead (possibly extending it) > Can be 'normal', 'urgent', or 'non-urgent' and can influence > transmission speed and delivery. > ? The working group discussed this specifically and at some length. Priority was actually one of my original proposals. The concern is that this is NOT a priority, but an urgency. That the values are the same is merely convenient. > 2) In 4.1: > > Can 429 be used when no subscription set is specified? (If yes, this > should be mentioned in section 4) I think that I'd rather leave this to Section 4.1. It follows the text immediately. subsection of 4 anyway. > 3) In 6.1: ":link" is included in the PUSH_PROMISE and not the HEADERS > block (when compared to section 6). Is this intentional or should one of > the examples be fixed? Yes, the link relation should be in the response, not the promise. Thanks. > 4) In general case it is not possible to achieve message reliability > because a push server is allowed to expire messages after they were > accepted for delivery due to overload. (Similarly for forced subscription > expiration.) I don't think the document makes this clear in Section 7.4. You are right, we mention this elsewhere, but not here: https://github.com/webpush-wg/webpush-protocol/pull/136 > 5) In 9.3: Alissa covered this already. From nobody Wed Oct 12 08:38:13 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 1D56C127077; Wed, 12 Oct 2016 08:38:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147628669208.6293.5760415846814077051.idtracker@ietfa.amsl.com> Date: Wed, 12 Oct 2016 08:38:12 -0700 Archived-At: Cc: draft-ietf-webpush-protocol@ietf.org, shida@ntt-at.com, webpush-chairs@ietf.org, webpush@ietf.org Subject: [Webpush] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draf?= =?utf-8?q?t-ietf-webpush-protocol-11=3A_=28with_COMMENT=29?= 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, 12 Oct 2016 15:38:12 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-webpush-protocol-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-webpush-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Maybe stupid questions: 1) Would it be possible for a user agent to use the same push service with multiple application servers? Or is this the case where a subscription set should be used? What happens in this case? Also, is there a possibility for different user agents to use the same push service if they would need to receive the same message from the same server...? Just thinking... 2) section 8.4 says: "To address this case, the W3C Push API [API] has adopted Voluntary Application Server Identification [I-D.ietf-webpush-vapid], which allows a user agent to restrict a subscription to a specific application server. " How does the user agent signal to the push service which application servers should be accepted? Did I miss that? Nit?: - In the Figure at the beginning of section 2 (which doesn't have a caption btw.) I guess you should use "application server" instead of "application" otherwise the previous definition is confusing... Also here in section 8 (s/application/application server): "This includes any communications between user agent and push service, plus communications between the application and the push service. " From nobody Wed Oct 12 08:49:10 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 598B3129428; Wed, 12 Oct 2016 08:49: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 q4qgHUz8MgsX; Wed, 12 Oct 2016 08:49:02 -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 5A0261200DF; Wed, 12 Oct 2016 08:49:01 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id o68so84387376qkf.3; Wed, 12 Oct 2016 08:49: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; bh=JM9E4xK1COKJc8xTJur4i7DSCjua4P5BUAbLeHLxTbM=; b=UBQAf0cYK01vLUeYG499fjBrS2Cg0KUJ0lchLvRbUwWUto8WOhWMc6wFUG2w/ZmPao pQVbPmMNO18xP4mdcbbKcXqAb0baOHBRrPQpfO/K8t2gXlWGL585EL1CdbLYoxsdmTAa gJwFFV6yknyM4E9tnbWokUy/JWnq6nORpHXg/SjROpZLURXesRIHa4zhkZks1DnAIraJ LtXxgeZVPr9bGnswclIaDZYhkBjBlbt/yoSmXv6bK25BkpdLiK/hpVi0XZf8MoeCYlsR S3JC6cn9D5Jvg7iOoM0isUtwBk2lpCKqIhl0y9lKZujQI/siUP4jE4gxNH5KAYrG/dmQ KVXA== 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=JM9E4xK1COKJc8xTJur4i7DSCjua4P5BUAbLeHLxTbM=; b=D9ojZ1AmIfeRfGljgGalrBOLnm3VcZtEdYKadUI/cSvrEW72pMsThzXN4DIpcwJ7p6 LldUdJs+opPRZglRzh/tWJi8rh6xSED6kGqwVOQf8i4qmYgr6Ov1UCYdUV40IX6+Ik6s GhwlJEcvo0jaBsoUTm85r3XsdV8YPUTzBVYQI+izCJKGf5WJGeE1C7NB+QCSXAVUSXPm f+1lpGSR+um+ixwiycj7assuqtzM3inGjDnAyq7ek4Gk7p1A/neP8g567Y8wdKTQ7k3m enSc3AwfPFnEZn5MmjKUK24V3mX4U/1BzigDk56veRmMe9QZwEMX69IGFCk7c/iRmxwS zlAg== X-Gm-Message-State: AA6/9RlCEgiRyNbu4LqFY599SoPq2dMN/D+QSsV/P7rpfGgColg2yy7S4r9qgNRKFq37h25VFdDxvqJ1VphmvA== X-Received: by 10.55.71.3 with SMTP id u3mr2034804qka.144.1476287340536; Wed, 12 Oct 2016 08:49:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Wed, 12 Oct 2016 08:48:59 -0700 (PDT) In-Reply-To: <147628669208.6293.5760415846814077051.idtracker@ietfa.amsl.com> References: <147628669208.6293.5760415846814077051.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Thu, 13 Oct 2016 02:48:59 +1100 Message-ID: To: Mirja Kuehlewind Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-webpush-protocol@ietf.org, Shida Schubert , webpush-chairs@ietf.org, The IESG , "webpush@ietf.org" Subject: Re: [Webpush] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draf?= =?utf-8?q?t-ietf-webpush-protocol-11=3A_=28with_COMMENT=29?= 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, 12 Oct 2016 15:49:04 -0000 On 13 October 2016 at 02:38, Mirja Kuehlewind wrote: > 1) Would it be possible for a user agent to use the same push service > with multiple application servers? Or is this the case where a > subscription set should be used? What happens in this case? Also, is > there a possibility for different user agents to use the same push > service if they would need to receive the same message from the same > server...? Just thinking... A UA can use the same push service for multiple subscriptions. Subscription sets help with that by aggregating push messages (you only have to make one request to retrieve messages for multiple subscriptions). Different user agents cannot get the same message from the service unless it is sent to them separately. Every message is encrypted toward a specific recipient and the push service treats different clients as completely independent. This is in contrast to a centralized pub-sub system where a "channel" might be read from by multiple subscribers. This would be a feature some proprietary push services have more or less, but the privacy and security properties of that feature - frankly - stink. > 2) section 8.4 says: > "To address this case, the W3C Push API [API] has adopted Voluntary > Application Server Identification [I-D.ietf-webpush-vapid], which > allows a user agent to restrict a subscription to a specific > application server. " > How does the user agent signal to the push service which application > servers should be accepted? Did I miss that? All the details are in the referenced draft. > Nit?: > - In the Figure at the beginning of section 2 (which doesn't have a > caption btw.) I guess you should use "application server" instead of > "application" otherwise the previous definition is confusing... > > Also here in section 8 (s/application/application server): > "This includes any communications > between user agent and push service, plus communications between the > application and the push service. " Thanks for picking these out, we try to be consistent, but often fail: https://github.com/webpush-wg/webpush-protocol/pull/137 From nobody Wed Oct 12 11:26:31 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 715951295FB; Wed, 12 Oct 2016 11:26:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147629678445.6285.5038003546245862234.idtracker@ietfa.amsl.com> Date: Wed, 12 Oct 2016 11:26:24 -0700 Archived-At: Cc: draft-ietf-webpush-protocol@ietf.org, shida@ntt-at.com, webpush-chairs@ietf.org, webpush@ietf.org Subject: [Webpush] Kathleen Moriarty's No Objection on draft-ietf-webpush-protocol-11: (with COMMENT) 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, 12 Oct 2016 18:26:26 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-webpush-protocol-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-webpush-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for a well written security considerations section. The only thing I might add is a note on the varying levels of security offered by the HTTP authentication methods, which are documented in their RFCs. Adding just that point to the following (phrased however you'd like) would be helpful: A push service MAY choose to authorize requests based on any HTTP-compatible authorization method available, of which there are numerous options. The somewhat recent updates to Basic & Digest do a really great job at saying how awful they are and there are some experimental options that offer some promise now. From nobody Wed Oct 12 13:46:29 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 58EA2129675; Wed, 12 Oct 2016 13:46:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147630518735.6397.5697353632878943065.idtracker@ietfa.amsl.com> Date: Wed, 12 Oct 2016 13:46:27 -0700 Archived-At: Cc: draft-ietf-webpush-protocol@ietf.org, shida@ntt-at.com, webpush-chairs@ietf.org, webpush@ietf.org Subject: [Webpush] Spencer Dawkins' No Objection on draft-ietf-webpush-protocol-11: (with COMMENT) 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, 12 Oct 2016 20:46:28 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-webpush-protocol-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-webpush-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Alexey on the "well-written document" part, but do have some minor questions. I noticed that push message subscription: This resource provides read and delete access for a message subscription. A user agent receives push messages (Section 6) using a push message subscription. Every push message subscription has exactly one push resource associated with it. and 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. don't say "A link relation of type ..." about the resource being defined, but push message subscription set: This resource provides read and delete access for a collection of push message subscriptions. A user agent receives push messages (Section 6.1) for all the push message subscriptions in the set. A link relation of type "urn:ietf:params:push:set" identifies a push message subscription set. push: An application server requests the delivery (Section 5) of a push message using a push resource. A link relation of type "urn:ietf:params:push" identifies a push resource. and receipt subscription: An application server receives delivery confirmations (Section 5.1) for push messages using a receipt subscription. A link relation of type "urn:ietf:params:push:receipt" identifies a receipt subscription. do. Is that intentional? Or would link relation indentification not be useful for these resources (if you told me that, I'd believe you). I see that Topic: has no semantics, but I wonder if the example use of Topic in Section 5.4 might be clearer if a different Topic was used - "Topic: upd" looks like "upd" would have semantic meaning, on first reading. I wondered why the use of subscription sets in There are minor differences between receiving push messages for a subscription and a subscription set. If a subscription set is available, the user agent SHOULD use the subscription set to monitor for push messages rather than individual push message subscriptions. was a SHOULD, and not a MUST. Is this just an efficiency thing, or is it something else? It would be helpful to explain this. Is there any guidance you could give about the retry mechanism described in this text? How many times, how often, etc. If the push service does not receive the acknowledgement within a reasonable amount of time, then the message is considered to be not yet delivered. The push service SHOULD continue to retry delivery of the message until its advertised expiration. I'm guessing that A push service that does not support reliable delivery over intermittent network connections or failing applications on devices, forces the device to acknowledge receipt directly to the application server, incurring additional power drain in order to establish (usually secure) connections to the individual application servers. isn't just about "establish", but "establish and maintain"? From nobody Wed Oct 12 14:25:48 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 C1D0012954F; Wed, 12 Oct 2016 14:25:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147630754676.6419.3793529940535426058.idtracker@ietfa.amsl.com> Date: Wed, 12 Oct 2016 14:25:46 -0700 Archived-At: Cc: draft-ietf-webpush-protocol@ietf.org, shida@ntt-at.com, webpush-chairs@ietf.org, webpush@ietf.org Subject: [Webpush] Ben Campbell's Yes on draft-ietf-webpush-protocol-11: (with COMMENT) 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, 12 Oct 2016 21:25:47 -0000 Ben Campbell has entered the following ballot position for draft-ietf-webpush-protocol-11: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-webpush-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for a well written document. I have a few questions on one topic, for which the answers may be obvious to people other than me: In section 8, 2nd paragraph: "Applications using this protocol MUST use mechanisms that provide confidentiality, integrity and data origin authentication." What must it use those mechanisms for? Are we talking about communication between the UA and app servers? Are we just talking about data in motion? As much as I like to see such requirements in general, is it reasonable for webpush to state requirements on the internal operation of the application? From nobody Wed Oct 12 14:30: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 F1AB212978B; Wed, 12 Oct 2016 14:29:59 -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 84MjT5goSOzD; Wed, 12 Oct 2016 14:29:58 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF9841297BC; Wed, 12 Oct 2016 14:29:43 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id t193so41201078ywc.2; Wed, 12 Oct 2016 14:29: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=Td4CrnXUg2yvkNDcqM3RbKDVDEK1vOI0Fd1QJqjuTNQ=; b=GCbdW+bsRPpNojgYinse5quoTE5ICHcb18LYf8FerdGT66G1VlGNfqIaVGkNXK4pBi szX7UHl7pyO3x90iQIGqvhrZv9VreXylFLiiB7OKTwTNy4+DMiZuPrHJcpzqMkzLuODE bnxhUeF92cJV5HknCGtW5PwgRkoihkyAYNEwMue3I7C6o5ArRUzJuSqbnWmKclmikDT9 OSNdzqsLPIr0DpdK1pJFi/6RA7ixVUNzjha9LHSwJCZbi3ALGqhnfceBp152sNQDWLQs JOlNrbglznojfkLZiFRAaJ9ADf8WFDeuJeFWgJ2QYrBpFapHhHZFR5X6jS+9FqtFAIvh gLIg== 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=Td4CrnXUg2yvkNDcqM3RbKDVDEK1vOI0Fd1QJqjuTNQ=; b=QCLEVIblNL/XG7Kp/LhxHkbQBn0YT/xPJNIzRFLf8K6Ky+GrSB+yBbKSY4sOSQHf0L NQ5Hm1NYVZoEPANAaY9n5BsMo8UBbNQzvt/LwJvnt1JGhEVoMgpogj6Fki7UkuvAvJ4H tO8+6LhPkPxI282bUl1bXU+DAJyIMzQZknM9BVolD3K558kLJRQ4FQO1xu+7uDYGZz16 gtIZC2fb84qgsDsSbrLOfURA8yYcJM7W0Km1GLRA+th//gdOSPOqW52LrppFo91S24Os HpjFzF2RbSmoA9im5iH4AhLJXCCTpUvfd14zQmVU9Vg8xy0k16MxIhoCJt4/wdllQpEl gasQ== X-Gm-Message-State: AA6/9RkB8zlD/wPC4PJdvclSNUK6HAt7bL1Sse9VTQCdVbnMfoQ5Iu4Gkx15pphi0y9ECLpaU/eqDNHwBzT9ng== X-Received: by 10.129.125.198 with SMTP id y189mr2749426ywc.234.1476307783065; Wed, 12 Oct 2016 14:29:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.92.67 with HTTP; Wed, 12 Oct 2016 14:29:42 -0700 (PDT) In-Reply-To: <147630754676.6419.3793529940535426058.idtracker@ietfa.amsl.com> References: <147630754676.6419.3793529940535426058.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Wed, 12 Oct 2016 16:29:42 -0500 Message-ID: To: Ben Campbell Content-Type: multipart/alternative; boundary=001a114926a0fd291f053eb1b0e4 Archived-At: Cc: draft-ietf-webpush-protocol@ietf.org, Shida Schubert , webpush-chairs@ietf.org, The IESG , webpush@ietf.org Subject: Re: [Webpush] Ben Campbell's Yes on draft-ietf-webpush-protocol-11: (with COMMENT) 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, 12 Oct 2016 21:30:00 -0000 --001a114926a0fd291f053eb1b0e4 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 12, 2016 at 4:25 PM, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-webpush-protocol-11: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-webpush-protocol/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for a well written document. I have a few questions on one topic, > for which the answers may be obvious to people other than me: > > In section 8, 2nd paragraph: "Applications using this protocol MUST use > mechanisms that provide > confidentiality, integrity and data origin authentication." > > What must it use those mechanisms for? Are we talking about communication > between the UA and app servers? Are we just talking about data in motion? > As much as I like to see such requirements in general, is it reasonable > for webpush to state requirements on the internal operation of the > application? > For what it's worth, I didn't understand whether the mandatory HTTP over TLS (right?) satisfies this MUST, or whether it meant something completely different. So I'm also curious about Ben's comment. --001a114926a0fd291f053eb1b0e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Oct 12, 2016 at 4:25 PM, Ben Campbell <ben@nostrum.com> wrote:
Ben Campbell has entered the fol= lowing ballot position for
draft-ietf-webpush-protocol-11: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/d= raft-ietf-webpush-protocol/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

Thanks for a well written document. I have a few questions on one topic, for which the answers may be obvious to people other than me:

In section 8, 2nd paragraph: "Applications using this protocol MUST us= e
mechanisms that provide
=C2=A0 =C2=A0confidentiality, integrity and data origin authentication.&quo= t;

What must it use those mechanisms for? Are we talking about communication between the UA and app servers? Are we just talking about data in motion? =C2=A0As much as I like to see such requirements in general, is it reasonab= le
for webpush to state requirements on the internal operation of the
application?

For what it's worth, I= didn't understand whether the mandatory HTTP over TLS (right?) satisfi= es this MUST, or whether it meant something completely different. =C2=A0

So I'm also curious about Ben's comment.
--001a114926a0fd291f053eb1b0e4-- From nobody Wed Oct 12 15:12: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 1880E12954F; Wed, 12 Oct 2016 15:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996] 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 5XR1I7PUGZ0l; Wed, 12 Oct 2016 15:12:27 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 8BE9C1294C9; Wed, 12 Oct 2016 15:12:27 -0700 (PDT) Received: from [10.0.1.21] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u9CMCMPh062533 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 12 Oct 2016 17:12:23 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.21] From: "Ben Campbell" To: "Spencer Dawkins at IETF" Date: Wed, 12 Oct 2016 17:12:22 -0500 Message-ID: <831BB8CC-4343-463A-8703-107364C7371B@nostrum.com> In-Reply-To: References: <147630754676.6419.3793529940535426058.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.5r5263) Archived-At: Cc: draft-ietf-webpush-protocol@ietf.org, Shida Schubert , webpush-chairs@ietf.org, The IESG , webpush@ietf.org Subject: Re: [Webpush] Ben Campbell's Yes on draft-ietf-webpush-protocol-11: (with COMMENT) 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, 12 Oct 2016 22:12:29 -0000 On 12 Oct 2016, at 16:29, Spencer Dawkins at IETF wrote: > On Wed, Oct 12, 2016 at 4:25 PM, Ben Campbell wrote: > >> Ben Campbell has entered the following ballot position for >> draft-ietf-webpush-protocol-11: Yes >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut >> this >> introductory paragraph, however.) >> >> >> Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-webpush-protocol/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Thanks for a well written document. I have a few questions on one >> topic, >> for which the answers may be obvious to people other than me: >> >> In section 8, 2nd paragraph: "Applications using this protocol MUST >> use >> mechanisms that provide >> confidentiality, integrity and data origin authentication." >> >> What must it use those mechanisms for? Are we talking about >> communication >> between the UA and app servers? Are we just talking about data in >> motion? >> As much as I like to see such requirements in general, is it >> reasonable >> for webpush to state requirements on the internal operation of the >> application? >> > > For what it's worth, I didn't understand whether the mandatory HTTP > over > TLS (right?) satisfies this MUST, or whether it meant something > completely > different. > Ah, right, I guess it could mean that. I assumed that it was talking about something not already covered by the other TLS requirements. > So I'm also curious about Ben's comment. From nobody Wed Oct 12 16:48: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 83E1D12958D; Wed, 12 Oct 2016 16:48:27 -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 3WXTHt-hOrNo; Wed, 12 Oct 2016 16:48:24 -0700 (PDT) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1C1E129628; Wed, 12 Oct 2016 16:48:24 -0700 (PDT) Received: by mail-yb0-x232.google.com with SMTP id 184so25084984yby.2; Wed, 12 Oct 2016 16:48:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NKeDCSF6a27xwUUgIPnNNEnlTqWCmQfCAQBAKAj7Fzk=; b=sPo5kVVVsh7JaEzZmV1cRumAN90pubM8E6JkH5rT6w6OWtmFA/gHdmayYN+EnyKaPK VSgulSQZfnjgD9fBI2sIz/p1EPV8m1j5Q5yJ6T95aD8Fkd/bRRZj6gYWnFcGL0NVH1LF 3Ul7MwWE+dSh8kcXP2OSJUp85D9t39T09GaGKN/KXjc0yPVK7zahGpzNdddzkK+eAAwk EQ/x3Tx7BuMVYqcqRZCaDk/2T7rEFnBh13CzSoqXvupwWsrhgvsAuoIvFuslz8L8buyB HDVEUjK4JlhcqHqZ6u1y/FovarPWYKrhGn9KEfJUzl02lvvzSohEcCC74e1aVe1l635H +kcA== 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=NKeDCSF6a27xwUUgIPnNNEnlTqWCmQfCAQBAKAj7Fzk=; b=Doh2lo36lmtM/Czo4ngsjhXj7Ml3EVtn9WuC59mowpgSUxv7+I9bLHJfWxX+fYDc/p ZDtLjEKJ/PPOA8OWhYgG/iyWWrogSjrT6SlOnKO/HYGvCfqENt0c/AMghil09sTj28Bu 5EHwN3QgQr5prCHGUsoP/+9Ei+N0frv4YGclPTmGyuuMliFt17HOB2BGYHbfXDzdlKMG OuAoofQeknu1WKJE9f8PgZ5KGJiII8/SEdnklAwEwpPBdcau2SndjZvogpAtn3mdrI9P J6CND6oVLsMLXo6ss/rjs/Mjc5Nbw7qASRcB5MZWpVO2t0AZai20ToMlKp7bIxQjqUG3 yHTg== X-Gm-Message-State: AA6/9Rl0zhP1Q1pI/LcLP3C8Y62sRelTn+/nn4lnPMwNT9v0opDadKCs1+MPd7J1+Tx+Gi2nw4ZxtYqQXBrbIw== X-Received: by 10.37.29.133 with SMTP id d127mr3207306ybd.58.1476316103651; Wed, 12 Oct 2016 16:48:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.92.67 with HTTP; Wed, 12 Oct 2016 16:48:22 -0700 (PDT) Received: by 10.37.92.67 with HTTP; Wed, 12 Oct 2016 16:48:22 -0700 (PDT) In-Reply-To: <831BB8CC-4343-463A-8703-107364C7371B@nostrum.com> References: <147630754676.6419.3793529940535426058.idtracker@ietfa.amsl.com> <831BB8CC-4343-463A-8703-107364C7371B@nostrum.com> From: Spencer Dawkins at IETF Date: Wed, 12 Oct 2016 18:48:22 -0500 Message-ID: To: Ben Campbell Content-Type: multipart/alternative; boundary=001a11427750ef38dc053eb3a0d5 Archived-At: Cc: draft-ietf-webpush-protocol@ietf.org, Shida Schubert , webpush-chairs@ietf.org, The IESG , webpush@ietf.org Subject: Re: [Webpush] Ben Campbell's Yes on draft-ietf-webpush-protocol-11: (with COMMENT) 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, 12 Oct 2016 23:48:27 -0000 --001a11427750ef38dc053eb3a0d5 Content-Type: text/plain; charset=UTF-8 Hi, Ben, On Oct 12, 2016 17:12, "Ben Campbell" wrote: > > On 12 Oct 2016, at 16:29, Spencer Dawkins at IETF wrote: > >> On Wed, Oct 12, 2016 at 4:25 PM, Ben Campbell wrote: >> >>> Ben Campbell has entered the following ballot position for >>> draft-ietf-webpush-protocol-11: Yes >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-webpush-protocol/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> Thanks for a well written document. I have a few questions on one topic, >>> for which the answers may be obvious to people other than me: >>> >>> In section 8, 2nd paragraph: "Applications using this protocol MUST use >>> mechanisms that provide >>> confidentiality, integrity and data origin authentication." >>> >>> What must it use those mechanisms for? Are we talking about communication >>> between the UA and app servers? Are we just talking about data in motion? >>> As much as I like to see such requirements in general, is it reasonable >>> for webpush to state requirements on the internal operation of the >>> application? >>> >> >> For what it's worth, I didn't understand whether the mandatory HTTP over >> TLS (right?) satisfies this MUST, or whether it meant something completely >> different. >> > > Ah, right, I guess it could mean that. I assumed that it was talking about something not already covered by the other TLS requirements. Yeah, I was kinda guessing, too :-) >> So I'm also curious about Ben's comment. > > > --001a11427750ef38dc053eb3a0d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi, Ben,

On Oct 12, 2016 17:12, "Ben Campbell" <ben@nostrum.com> wrote:
>
> On 12 Oct 2016, at 16:29, Spencer Dawkins at IETF wrote:
>
>> On Wed, Oct 12, 2016 at 4:25 PM, Ben Campbell <ben@nostrum.com> wrote:
>>
>>> Ben Campbell has entered the following ballot position for
>>> draft-ietf-webpush-protocol-11: Yes
>>>
>>> When responding, please keep the subject line intact and reply= to all
>>> email addresses included in the To and CC lines. (Feel free to= cut this
>>> introductory paragraph, however.)
>>>
>>>
>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteri= a.html
>>> for more information about IESG DISCUSS and COMMENT positions.=
>>>
>>>
>>> The document, along with other ballot positions, can be found = here:
>>> https://datatracker.ietf.org/doc/draft-ietf-webpush-protocol/
>>>
>>>
>>>
>>> --------------------------------------------------------------= --------
>>> COMMENT:
>>> --------------------------------------------------------------= --------
>>>
>>> Thanks for a well written document. I have a few questions on = one topic,
>>> for which the answers may be obvious to people other than me:<= br> >>>
>>> In section 8, 2nd paragraph: "Applications using this pro= tocol MUST use
>>> mechanisms that provide
>>> =C2=A0 =C2=A0confidentiality, integrity and data origin authen= tication."
>>>
>>> What must it use those mechanisms for? Are we talking about co= mmunication
>>> between the UA and app servers? Are we just talking about data= in motion?
>>> =C2=A0As much as I like to see such requirements in general, i= s it reasonable
>>> for webpush to state requirements on the internal operation of= the
>>> application?
>>>
>>
>> For what it's worth, I didn't understand whether the manda= tory HTTP over
>> TLS (right?) satisfies this MUST, or whether it meant something co= mpletely
>> different.
>>
>
> Ah, right, I guess it could mean that. I assumed that it was talking a= bout something not already covered by the other TLS requirements.

Yeah, I was kinda guessing, too :-)

>> So I'm also curious about Ben's comment. >
>
>

--001a11427750ef38dc053eb3a0d5-- From nobody Wed Oct 12 17:10: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 DC8D9129401; Wed, 12 Oct 2016 17:10:09 -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=unavailable 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 OoldHaUGYuly; Wed, 12 Oct 2016 17:10:08 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C23E9127735; Wed, 12 Oct 2016 17:01:14 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id z190so60509825qkc.2; Wed, 12 Oct 2016 17:01:14 -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=2AsmPHt28ukwJ2a99CVYDq+2Fp0uq01psMhyabuoSCY=; b=QaPHQiGx7/62DYYy5XpUA51T3iGMt9yy+dDzD+T1QvdhGQ8aaAQel/HOZd5HIS5PYT AXwTKWIgceugVjrT8m8oX7JVivq1/O+bQbioEfOg8GRetcJYIxaoW4/mPepxmoBn3Jv6 D50v3G8zjTugBuPR0TNCe7tA35EAPYw+z4NeSiB122HgZ2YCDb31ZqhmU9XmM/YfZhJq DoYwntKn4O1juOWtHrLSxW2vfsYUgoyMB37414OzW7YETnLz7v6eMJ9TCKfd4GNb1WfO TYPrmKrHQZFLPqfTTkOMOkSHo9vvou0rrhcruw3qhdi7xqnWSF2fNVdVDxJX51ucf7eS 2eig== 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=2AsmPHt28ukwJ2a99CVYDq+2Fp0uq01psMhyabuoSCY=; b=cb+B8pRlQPHIqGWDZHFjyljIk2RlElJmsWQuJC1mFfoLwwu5XcS2TyHSkJ/lgBDQI0 DHBqpSJK7AjuW87jiy8mpjnj/QBlCKiSCCrRp6dkJdiGzeTG/pTtMDvRMdjwPKd9WNwy 2i4lR1okI67itgl8lvBltLcr/SAq2hv8K/88nOcYtv+TlO1sKZCUx4EGVWMHhjst2+Vf 6Kk4avz0MvM6EWqJx5sGQeynLZ9DhKnZ9F1n3i4AbNpssf7bYm8HmeS5gpVKIVJxoTQZ pt0jtIo+t+GMPx3COHq0ux1tL4qVujnUasPxBjNTTOr1RRCwu5rAwz/souLaM1n5Q0Zh NhZA== X-Gm-Message-State: AA6/9Rlr9RA6pxkHfgyLuJ7z0oy0I73wrv6iovKEHEhFocuInQxF81yNEba2Vl681EXwOnWmoERQl+VpgMpOeg== X-Received: by 10.55.99.17 with SMTP id x17mr3585897qkb.147.1476316873904; Wed, 12 Oct 2016 17:01:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Wed, 12 Oct 2016 17:01:13 -0700 (PDT) In-Reply-To: <147630754676.6419.3793529940535426058.idtracker@ietfa.amsl.com> References: <147630754676.6419.3793529940535426058.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Thu, 13 Oct 2016 11:01:13 +1100 Message-ID: To: Ben Campbell , "Brian Raymor (MS OPEN TECH)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-webpush-protocol@ietf.org, Shida Schubert , webpush-chairs@ietf.org, The IESG , "webpush@ietf.org" Subject: Re: [Webpush] Ben Campbell's Yes on draft-ietf-webpush-protocol-11: (with COMMENT) 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, 13 Oct 2016 00:10:10 -0000 On 13 October 2016 at 08:25, Ben Campbell wrote: > In section 8, 2nd paragraph: "Applications using this protocol MUST use > mechanisms that provide > confidentiality, integrity and data origin authentication." > > What must it use those mechanisms for? Are we talking about communication > between the UA and app servers? Are we just talking about data in motion? > As much as I like to see such requirements in general, is it reasonable > for webpush to state requirements on the internal operation of the > application? This specifically refers to the work in draft-ietf-webpush-encryption, which covers these things. We should add a f'rexample there. Brian, does that sound right? (Yes, TLS is mandatory, but hop-by-hop mechanisms don't cover all the bases.) From nobody Wed Oct 12 17:13:16 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 4E296127735; Wed, 12 Oct 2016 17:13:10 -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 AZrwvtcbAHyR; Wed, 12 Oct 2016 17:13:07 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::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 BC39E12951D; Wed, 12 Oct 2016 17:13:02 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id w3so43066429ywg.1; Wed, 12 Oct 2016 17:13:02 -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=DKSPAC3l+6zuemtd+M6yYFI8X9DMR/YV4HCLAafXRDo=; b=oZ06tHBzids5vJX+Ucar06GY8NyRRgFil7IE5jDtCIR8y9OAbOiHe2GE+goaj/cPtU YTa0dTk/q+2JDen5IQYJh7Nd3DohKIZuat+bDgvQgk2fn6h59ItcRfsf+U+FPdMM5DFb IOvHKRuN7jc+kpXqNddg/sZoP7UCuIG2mXi1Oq267t+PkvTVlX1qJ6cBgfyXmFoxbaoL GR3EEZuYBh77jtzJyydg/XyAecfVJ3NSNM8zjhZSgERwZ34IA1lAiCZUVlLQQMt0SmK5 tK8NF8b2irDFJlTtuwHXC1zdVPyb2as28Sc3Mv+njJtAO848S7REsHTLrXBKf1jX0q4X pTOQ== 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=DKSPAC3l+6zuemtd+M6yYFI8X9DMR/YV4HCLAafXRDo=; b=VdGgKIzbiCP0L3DSOSZ1Pu4RVcG2wbvuliJoHze4JyM5Pxag8xYEbhHM3Yl9Q47aKK 82xl6hwQ0tSmiEi8NXwJZ2AGRD8qG2MtO3FakPCv6mJTiCDIE4NLGLvY2uKhdIWeXFez kh/KnvgL0EnGRpf9wo1eV+81H62c0qMrOS1PnryVZ9jdXhRwxRZvqtD16GL1i+PZ9vpu qq4iLhwq8+P03EwO0ijCrSPnnQ2xSyCtIpsM6nu/q/3OnKeNIH/qYfwDZzI3nbHVQRhE fT8FCxgNHxNa6IpreGWTcjrlV8SFmIME04NlCBzGdTA2A1u0fqOF5d1b+LFFyfEaKMYF A+TQ== X-Gm-Message-State: AA6/9RlSjN+7lowNJFuUzGOHIj/Hs//zHW0nheudYOx+SEeopvjfaG2WYb7eUYITEBZ04woZAOkTT0AP5AxY5g== X-Received: by 10.129.77.84 with SMTP id a81mr3250839ywb.19.1476317581951; Wed, 12 Oct 2016 17:13:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.92.67 with HTTP; Wed, 12 Oct 2016 17:13:01 -0700 (PDT) Received: by 10.37.92.67 with HTTP; Wed, 12 Oct 2016 17:13:01 -0700 (PDT) In-Reply-To: References: <147630754676.6419.3793529940535426058.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Wed, 12 Oct 2016 19:13:01 -0500 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1140b7ac0c466a053eb3f9c5 Archived-At: Cc: Ben Campbell , "Brian Raymor \(MS OPEN TECH\)" , Shida Schubert , iesg@ietf.org, draft-ietf-webpush-protocol@ietf.org, webpush-chairs@ietf.org, "webpush@ietf.org" Subject: Re: [Webpush] Ben Campbell's Yes on draft-ietf-webpush-protocol-11: (with COMMENT) 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, 13 Oct 2016 00:13:10 -0000 --001a1140b7ac0c466a053eb3f9c5 Content-Type: text/plain; charset=UTF-8 Hi, Martin, On Oct 12, 2016 19:10, "Martin Thomson" wrote: > > On 13 October 2016 at 08:25, Ben Campbell wrote: > > In section 8, 2nd paragraph: "Applications using this protocol MUST use > > mechanisms that provide > > confidentiality, integrity and data origin authentication." > > > > What must it use those mechanisms for? Are we talking about communication > > between the UA and app servers? Are we just talking about data in motion? > > As much as I like to see such requirements in general, is it reasonable > > for webpush to state requirements on the internal operation of the > > application? > > This specifically refers to the work in draft-ietf-webpush-encryption, > which covers these things. We should add a f'rexample there. Brian, > does that sound right? > > (Yes, TLS is mandatory, but hop-by-hop mechanisms don't cover all the bases.) > Make Ben happy, because it's his comment, but that would have significantly helped me understand! Spencer --001a1140b7ac0c466a053eb3f9c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi, Martin,

On Oct 12, 2016 19:10, "Martin Thomson" <martin.thomson@gmail.com> wrot= e:
>
> On 13 October 2016 at 08:25, Ben Campbell <ben@nostrum.com> wrote:
> > In section 8, 2nd paragraph: "Applications using this protoc= ol MUST use
> > mechanisms that provide
> >=C2=A0 =C2=A0 confidentiality, integrity and data origin authentic= ation."
> >
> > What must it use those mechanisms for? Are we talking about commu= nication
> > between the UA and app servers? Are we just talking about data in= motion?
> >=C2=A0 As much as I like to see such requirements in general, is i= t reasonable
> > for webpush to state requirements on the internal operation of th= e
> > application?
>
> This specifically refers to the work in draft-ietf-webpush-encryption,=
> which covers these things.=C2=A0 We should add a f'rexample there.= =C2=A0 Brian,
> does that sound right?
>
> (Yes, TLS is mandatory, but hop-by-hop mechanisms don't cover all = the bases.)
>

Make Ben happy, because it's his comment, but that would= have significantly helped me understand!

Spencer

--001a1140b7ac0c466a053eb3f9c5-- From nobody Wed Oct 12 17:21:14 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 9D9ED1295B7; Wed, 12 Oct 2016 17:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996] 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 UhzjrYdbc1zW; Wed, 12 Oct 2016 17:21:10 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 1DC6A1295AE; Wed, 12 Oct 2016 17:21:10 -0700 (PDT) Received: from [10.0.1.21] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u9D0L4jA072658 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 12 Oct 2016 19:21:05 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.21] From: "Ben Campbell" To: "Spencer Dawkins at IETF" Date: Wed, 12 Oct 2016 19:21:04 -0500 Message-ID: In-Reply-To: References: <147630754676.6419.3793529940535426058.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.5r5263) Archived-At: Cc: Brian Raymor , Martin Thomson , Shida Schubert , iesg@ietf.org, draft-ietf-webpush-protocol@ietf.org, webpush-chairs@ietf.org, "webpush@ietf.org" Subject: Re: [Webpush] Ben Campbell's Yes on draft-ietf-webpush-protocol-11: (with COMMENT) 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, 13 Oct 2016 00:21:11 -0000 On 12 Oct 2016, at 19:13, Spencer Dawkins at IETF wrote: > Hi, Martin, > > On Oct 12, 2016 19:10, "Martin Thomson" > wrote: >> >> On 13 October 2016 at 08:25, Ben Campbell wrote: >>> In section 8, 2nd paragraph: "Applications using this protocol MUST >>> use >>> mechanisms that provide >>> confidentiality, integrity and data origin authentication." >>> >>> What must it use those mechanisms for? Are we talking about > communication >>> between the UA and app servers? Are we just talking about data in > motion? >>> As much as I like to see such requirements in general, is it >>> reasonable >>> for webpush to state requirements on the internal operation of the >>> application? >> >> This specifically refers to the work in >> draft-ietf-webpush-encryption, >> which covers these things. We should add a f'rexample there. Brian, >> does that sound right? >> >> (Yes, TLS is mandatory, but hop-by-hop mechanisms don't cover all the > bases.) >> > > Make Ben happy, because it's his comment, but that would have > significantly > helped me understand! Who said I wasn't happy? :-) But I think I now understand this to mean e2e protection, at least with respect to the push service. Some clarification would help. Also, that seems conceptually bound more to section 8.1 than 8. (Or was 8.1 intended to expand on the mention in 8?) Ben. From nobody Wed Oct 12 17:33: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 1227112960D; Wed, 12 Oct 2016 17:33:38 -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 5QWGK_jIlF95; Wed, 12 Oct 2016 17:33:33 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::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 AB1B71293F9; Wed, 12 Oct 2016 17:33:29 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id f128so58501867qkb.1; Wed, 12 Oct 2016 17:33:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Mis3QDf+vYIzoCPGSCXjsYyQhg9tNpOvL/FxHwZqUBU=; b=CuM69C38pztpcRh3iMYoDyn7GNsm5eoVJb7vSWKBpPfmpFcKY/Ia9zRSfFrpmPG04d 21M3t640f6TnNF2tyulHtNXI463cSpI/ZINmccq2OcA5xrXkuMT7sYPrjwDRMtqcpfpm y2nAbWTGEeQRByY0wseKmAeFlsW+zs3RwTqutsOmiSTENUgUNiHBokOHCvMJN9vYyaqA Nc8AjICGbNhmS4KPrHfwspKWil+jt0M1PmbClCbgbK+FfdoDTsjZbzw3xiNicwF56KXM qUrM3jJfLX44wfs5A8ae4Aqz5P1+10r64lsNwWmJhj28+fqTt1Jh2s+jVCjV7e3GGwFt XiYg== 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=Mis3QDf+vYIzoCPGSCXjsYyQhg9tNpOvL/FxHwZqUBU=; b=KtPkG/pcdk928xGY+1cQ0xFpOgcIY5iuDPjm+1qExoocrsAnT9pPD7Y6VXgJQRG1j8 xj2JFcOBDYo8aboRYfjCI0hOL6P2IbLtbA+e46Ha/zkphHyywLt+eZwUZj5ctUYIqhBL UU6xoxM1uK4//J+xvf9U/ovHULD+dyABRebnKJ+eI4eeTSU3oBdO5pZe+pVNSf8liXAe xgnVNpZeeIz3R3IGVdG6YhSGHhPxxzba0a10TGSCGdbyTXzl5sj/bK4xHFEU9DXijFB7 ykYF/XbCAa+E8Ui7rOuCEEstOEmbJV7NWEUFd0DqjRoG5mtUqx3N5M1XX1Do5QKzkZtJ Imcw== X-Gm-Message-State: AA6/9Rl0X01WWFDTl1Q/4H1bTnhf5tT5nE1SHl1TT0CF5V51KSO5Fp3DhYoSZCBP3fBXifHSurqr5SA71ShPDg== X-Received: by 10.55.163.214 with SMTP id m205mr3749168qke.68.1476318808828; Wed, 12 Oct 2016 17:33:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Wed, 12 Oct 2016 17:33:28 -0700 (PDT) In-Reply-To: References: <147630754676.6419.3793529940535426058.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Thu, 13 Oct 2016 11:33:28 +1100 Message-ID: To: Ben Campbell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Brian Raymor , Shida Schubert , Spencer Dawkins at IETF , draft-ietf-webpush-protocol@ietf.org, webpush-chairs@ietf.org, "webpush@ietf.org" , The IESG Subject: Re: [Webpush] Ben Campbell's Yes on draft-ietf-webpush-protocol-11: (with COMMENT) 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, 13 Oct 2016 00:33:38 -0000 On 13 October 2016 at 11:21, Ben Campbell wrote: > But I think I now understand this to mean e2e protection, at least with > respect to the push service. Some clarification would help. Also, that seems > conceptually bound more to section 8.1 than 8. (Or was 8.1 intended to > expand on the mention in 8?) Yes, we should be clearer. And yes, 8.1 was intended to expand on the intro to Section 8. Now that I look at this again, it's probably better to move that statement to 8.1. I hope this helps: https://github.com/webpush-wg/webpush-protocol/pull/138 From nobody Wed Oct 12 17:51: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 D9CA9129654; Wed, 12 Oct 2016 17:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996] 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 7-KNU4gmzUrm; Wed, 12 Oct 2016 17:51:22 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 2F0121295DA; Wed, 12 Oct 2016 17:51:22 -0700 (PDT) Received: from [10.0.1.21] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u9D0pG4b075004 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 12 Oct 2016 19:51:17 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.21] From: "Ben Campbell" To: "Martin Thomson" Date: Wed, 12 Oct 2016 19:51:16 -0500 Message-ID: <9E2486CD-4A05-42A2-AB57-45C309E64DF6@nostrum.com> In-Reply-To: References: <147630754676.6419.3793529940535426058.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown X-Mailer: MailMate (1.9.5r5263) Archived-At: Cc: Brian Raymor , Shida Schubert , Spencer Dawkins at IETF , draft-ietf-webpush-protocol@ietf.org, webpush-chairs@ietf.org, "webpush@ietf.org" , The IESG Subject: Re: [Webpush] Ben Campbell's Yes on draft-ietf-webpush-protocol-11: (with COMMENT) 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, 13 Oct 2016 00:51:24 -0000 On 12 Oct 2016, at 19:33, Martin Thomson wrote: > On 13 October 2016 at 11:21, Ben Campbell wrote: >> But I think I now understand this to mean e2e protection, at least >> with >> respect to the push service. Some clarification would help. Also, >> that seems >> conceptually bound more to section 8.1 than 8. (Or was 8.1 intended >> to >> expand on the mention in 8?) > > Yes, we should be clearer. And yes, 8.1 was intended to expand on the > intro to Section 8. Now that I look at this again, it's probably > better to move that statement to 8.1. > I hope this helps: > https://github.com/webpush-wg/webpush-protocol/pull/138 That works for me. Thanks! Ben. From nobody Wed Oct 12 18:09:10 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 6346D1295C8; Wed, 12 Oct 2016 18:09:07 -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 QNuzwZ_uff5f; Wed, 12 Oct 2016 18:09:05 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0119.outbound.protection.outlook.com [104.47.38.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 221F5129566; Wed, 12 Oct 2016 18:09:05 -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=9jibV+4hIipS7uBda16ivdzXt/In5QM55gC59Jw6O88=; b=ZgxTcObUgpMkWNN6iCb7oez64cKRvrhccgorBx5EzXpj+5tgw6Z51kgDzp3z46/BNtMDQM1hr5dnmavzhIxmyRnG2rbeU/h7HeqbWye3KQ3Fv1wjB3d6x2cdQtU0ksyOImFe/aAdtIDwaoEFeipNAMZlELxmSfFB4UUIF/KK+nM= Received: from CY1PR03MB2380.namprd03.prod.outlook.com (10.167.8.6) by CY1PR03MB2378.namprd03.prod.outlook.com (10.166.207.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.12; Thu, 13 Oct 2016 01:09:03 +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.0659.020; Thu, 13 Oct 2016 01:09:03 +0000 From: Brian Raymor To: Kathleen Moriarty , The IESG Thread-Topic: Kathleen Moriarty's No Objection on draft-ietf-webpush-protocol-11: (with COMMENT) Thread-Index: AQHSJLYoZNpGErSVEEe1X/Yl9wYANaClkmGw Date: Thu, 13 Oct 2016 01:09:02 +0000 Message-ID: References: <147629678445.6285.5038003546245862234.idtracker@ietfa.amsl.com> In-Reply-To: <147629678445.6285.5038003546245862234.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: a8bc5df3-0f27-44ca-d730-08d3f3058595 x-microsoft-exchange-diagnostics: 1; CY1PR03MB2378; 7:skuFv6llY0bPMW0xIKCN/7VqIh5gBPAED+8bmLwi/KnBz8Y0tvFkiRXE4hq2aWDdvhC9VLwMMCm4K/PUd+01ILVo/j1AzHKo8HkVJuz2T877qe1UNmRICJLuw/jbNnUTtvkETp3jIkyuzyKCb6detpIKLWIr7krcqBa2ai8mB6KQCVdM8eh7uIjD4jqQLji92Nmvv2xQtHCMxFRTkL6qFONIy6Wte+dalKvTciJ8eIzfeR9pQc4QQ44dZwm/kd4W1nAdVHFmj7+CzgflbIDyJjD+lheThPYdCIWtzK2hxUh+BBCiZWU17TpY3Of2eNaKXGNEX3t0499lJAIChTnQbcCoFpLCaiiGVfZ2/76mRLpWFAKJgFEvHV5Es2Gv6pHx x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2378; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2378; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2378; x-forefront-prvs: 0094E3478A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(33656002)(19580395003)(11100500001)(92566002)(66066001)(7696004)(50986999)(54356999)(97736004)(2950100002)(76176999)(5001770100001)(101416001)(87936001)(106356001)(99286002)(105586002)(106116001)(74316002)(68736007)(305945005)(3660700001)(86612001)(10090500001)(3280700002)(86362001)(8990500004)(102836003)(10400500002)(5005710100001)(9686002)(8676002)(3846002)(7846002)(230783001)(189998001)(6116002)(10290500002)(4326007)(122556002)(5660300001)(5002640100001)(8936002)(2906002)(76576001)(2900100001)(15975445007)(586003)(81166006)(81156014)(77096005)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2378; 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2016 01:09:02.8455 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2378 Archived-At: Cc: "draft-ietf-webpush-protocol@ietf.org" , "shida@ntt-at.com" , "webpush-chairs@ietf.org" , "webpush@ietf.org" Subject: Re: [Webpush] Kathleen Moriarty's No Objection on draft-ietf-webpush-protocol-11: (with COMMENT) 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, 13 Oct 2016 01:09:07 -0000 DQo+IFRoZSBvbmx5IHRoaW5nIEkgbWlnaHQgYWRkIGlzIGEgbm90ZSBvbiB0aGUgdmFyeWluZyBs ZXZlbHMgb2Ygc2VjdXJpdHkNCj4gb2ZmZXJlZCBieSB0aGUgSFRUUCBhdXRoZW50aWNhdGlvbiBt ZXRob2RzLCB3aGljaCBhcmUgZG9jdW1lbnRlZCBpbiB0aGVpcg0KPiBSRkNzLiAgQWRkaW5nIGp1 c3QgdGhhdCBwb2ludCB0byB0aGUgZm9sbG93aW5nIChwaHJhc2VkIGhvd2V2ZXIgeW91J2QNCj4g bGlrZSkgd291bGQgYmUgaGVscGZ1bDoNCj4gICAgIEEgcHVzaCBzZXJ2aWNlIE1BWQ0KPiAgICBj aG9vc2UgdG8gYXV0aG9yaXplIHJlcXVlc3RzIGJhc2VkIG9uIGFueSBIVFRQLWNvbXBhdGlibGUN Cj4gICAgYXV0aG9yaXphdGlvbiBtZXRob2QgYXZhaWxhYmxlLCBvZiB3aGljaCB0aGVyZSBhcmUg bnVtZXJvdXMgb3B0aW9ucy4NCg0KPiBUaGUgc29tZXdoYXQgcmVjZW50IHVwZGF0ZXMgdG8gQmFz aWMgJiBEaWdlc3QgZG8gYSByZWFsbHkgZ3JlYXQgam9iIGF0DQo+IHNheWluZyBob3cgYXdmdWwg dGhleSBhcmUgYW5kIHRoZXJlIGFyZSBzb21lIGV4cGVyaW1lbnRhbCBvcHRpb25zIHRoYXQNCj4g b2ZmZXIgc29tZSBwcm9taXNlIG5vdy4NCg0KUHJvcG9zZWQgdGV4dCAtIGh0dHBzOi8vZ2l0aHVi LmNvbS93ZWJwdXNoLXdnL3dlYnB1c2gtcHJvdG9jb2wvcHVsbC8xMzkvZmlsZXMNCg0KDQoNCg== From nobody Wed Oct 12 18:51: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 B2C1712940D; Wed, 12 Oct 2016 18:51:38 -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 IH_yzi307qle; Wed, 12 Oct 2016 18:51:36 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::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 99E00129405; Wed, 12 Oct 2016 18:51:36 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id f6so31573315qtd.2; Wed, 12 Oct 2016 18:51:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/CdFwSnXbG+svn+6m2arCAI/ptmFp7PyxR/oNsHf3xE=; b=Or6wNW/m+u9Ol37Cwcp6hqQyxFa2uFaWmtZpYfklFR0eisP+xFnpt2cMOJwxK/SFLe us9zYZgc9x/ti489p5XVY2VrFwvNZDgrueRVf7lGskkkM/Zza2koPlzvtdpsHX40uh43 UGKibtIlDECUCNhi38cTwscpenckgYMd/34VJ73Wp1I70HUS52dzyJvgHRFZkBqgNuXi Y1NVzuu96Y6Q76woZAYqsYFDhj9mDsl6dXqtZZ4zzEBRucjaMWJ2VNNTDccBl37MQ5xw UhV1BxWgDRFEBeMDs43yy9Ny8kegch8ycIqY61numBrkQWMgl7U3lUuvowLll85SN/TE j0UA== 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=/CdFwSnXbG+svn+6m2arCAI/ptmFp7PyxR/oNsHf3xE=; b=OZhmxGgTxgkxc2XRt6KSynZfjx8h2FD01Hyd9OPDxOH0egM1v7dqmHVc6Nfc3gIyUD 9zATDLcaKk0OREKtFnpqae+yX/Do2tU+87d4PQz4xVsm6AhQPxTJ/zM812wwdMvioR6E 67m+H6ml056AnjvSsSsTYVy6s84CXPziQYlyT0oTidIETaxYp90Jh4W8cCNLc7C3Oe3v j3Nq5jsZu6GJqp9b8n1EbARX83/8USrZFMsSoVdu+2P2B5boM5e1/4BXj3B+GWgmeUGb nwmZaDQ0G9tMN+xmIHxLr+5fvXw+WII6WtuAu+fRRJpZD/Zq/+Bzb1P3k7yADQk4ljjf kukA== X-Gm-Message-State: AA6/9RkYFKF0GetbJ2u4LuLxDb4cs/adNE8jtCalpN36obRIQxiWbAZG4KCiJo+oHn3bjw== X-Received: by 10.200.45.124 with SMTP id o57mr4306548qta.90.1476323495812; Wed, 12 Oct 2016 18:51:35 -0700 (PDT) Received: from [192.168.1.4] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id u4sm3799093qka.9.2016.10.12.18.51.34 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 12 Oct 2016 18:51:34 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: kathleen.moriarty.ietf@gmail.com X-Mailer: iPhone Mail (13G36) In-Reply-To: Date: Wed, 12 Oct 2016 21:51:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147629678445.6285.5038003546245862234.idtracker@ietfa.amsl.com> To: Brian Raymor Archived-At: Cc: "draft-ietf-webpush-protocol@ietf.org" , Shida Schubert , "webpush-chairs@ietf.org" , The IESG , "webpush@ietf.org" Subject: Re: [Webpush] Kathleen Moriarty's No Objection on draft-ietf-webpush-protocol-11: (with COMMENT) 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, 13 Oct 2016 01:51:39 -0000 Please excuse typos, sent from handheld device=20 > On Oct 12, 2016, at 9:09 PM, Brian Raymor wro= te: >=20 >=20 >> The only thing I might add is a note on the varying levels of security >> offered by the HTTP authentication methods, which are documented in their= >> RFCs. Adding just that point to the following (phrased however you'd >> like) would be helpful: >> A push service MAY >> choose to authorize requests based on any HTTP-compatible >> authorization method available, of which there are numerous options. >=20 >> The somewhat recent updates to Basic & Digest do a really great job at >> saying how awful they are and there are some experimental options that >> offer some promise now. >=20 > Proposed text - https://github.com/webpush-wg/webpush-protocol/pull/139/fi= les Thanks for the quick update. I would just say 'with varying levels of secur= ity.' The security considerations sections for each of the methods availabl= e for HTTP are included in the RFCs for each. Thank you, Kathleen=20 >=20 >=20 >=20 From nobody Wed Oct 12 20:12: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 05B151296A0; Wed, 12 Oct 2016 20:12:49 -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 5N-6Bzfam3OL; Wed, 12 Oct 2016 20:12:46 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C71F712969F; Wed, 12 Oct 2016 20:12:46 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id t192so45441149ywf.0; Wed, 12 Oct 2016 20:12:46 -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=G/lCf5rOwrzfVPRCVwjl0JClHWfkA6m4d3QBKBLIkuQ=; b=IgWZTs7Zs0lvMbpwmI2Ck7MnDeKH3xNZ8+DjZy06dz/mc5UWdA10BBeieG40lEm14N 5+KQ06m/Ue+RAVwYAbn3IhOh2Liy8Gk2h6xkNy3jcdpK77Jo+kC2sWmd53Ivqx/OyX04 Vq/dJ3JW0bB0GxFCHdSIRtdDZufWM+5JTzWiN7rWly6B9OZYXTeJkWEZVJ5nwhBoTY2L hcMwhfAEN5wMLm0IRIF0Nh7+fGQQaQ1m77hHniyAo9SxS2J8b4ww5EjW2ONd3zZB7SV4 CRpe6sgpDlIXcJTVCbKV9EYCnqoJ5QupQ2syOvllgm1ucE+YoLtjC6sTgY9xHeOswvPY QXvQ== 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=G/lCf5rOwrzfVPRCVwjl0JClHWfkA6m4d3QBKBLIkuQ=; b=CtgLK6T11hznnPcUOoa0/71BRMXIcdXgGqfNk0V2k9xLOb4nRt8N45elZ83wKpaiGn qKaPU+PuYbOt/lOLvwKRZ7izY8o1sTXq4JOgLxP8O49/jptJs3vt0DwxYv7+aTh5X04L r+9LQPODKhzAzUpml9aR+BiqTzCg5V8su4DktcbaHe9Me4WCkQudA/Bk2Z5Z5KtDClzk 0LKqD7e0yrJeQTVOB3Avz8j9ku51z9cxhvZ26Noo6m8acRVu+pR9BoAdJWgBsOC8c4B/ n4nojBkNqMIk/x17F66fLnjTzzuJ50fj/qN0XtEkBzEhJl5jrE7MsmSA8Y6EfitR+gQw JVDQ== X-Gm-Message-State: AA6/9Rnhc64k0bA0Y/qRVY5kLEQnrZjl/nSYSgdAacxNYLtAHlf0boc0srzW90L4Unnh5USdKbzRZ/nc+TFUBg== X-Received: by 10.13.214.12 with SMTP id y12mr3795919ywd.152.1476328366041; Wed, 12 Oct 2016 20:12:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.92.67 with HTTP; Wed, 12 Oct 2016 20:12:45 -0700 (PDT) Received: by 10.37.92.67 with HTTP; Wed, 12 Oct 2016 20:12:45 -0700 (PDT) In-Reply-To: <9E2486CD-4A05-42A2-AB57-45C309E64DF6@nostrum.com> References: <147630754676.6419.3793529940535426058.idtracker@ietfa.amsl.com> <9E2486CD-4A05-42A2-AB57-45C309E64DF6@nostrum.com> From: Spencer Dawkins at IETF Date: Wed, 12 Oct 2016 22:12:45 -0500 Message-ID: To: Ben Campbell Content-Type: multipart/alternative; boundary=94eb2c073bbcd46fb1053eb67b2d Archived-At: Cc: Brian Raymor , webpush-chairs@ietf.org, Shida Schubert , The IESG , draft-ietf-webpush-protocol@ietf.org, Martin Thomson , "webpush@ietf.org" Subject: Re: [Webpush] Ben Campbell's Yes on draft-ietf-webpush-protocol-11: (with COMMENT) 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, 13 Oct 2016 03:12:49 -0000 --94eb2c073bbcd46fb1053eb67b2d Content-Type: text/plain; charset=UTF-8 Hi, Martin, On Oct 12, 2016 19:51, "Ben Campbell" wrote: > > On 12 Oct 2016, at 19:33, Martin Thomson wrote: > >> On 13 October 2016 at 11:21, Ben Campbell wrote: >>> >>> But I think I now understand this to mean e2e protection, at least with >>> respect to the push service. Some clarification would help. Also, that seems >>> conceptually bound more to section 8.1 than 8. (Or was 8.1 intended to >>> expand on the mention in 8?) >> >> >> Yes, we should be clearer. And yes, 8.1 was intended to expand on the >> intro to Section 8. Now that I look at this again, it's probably >> better to move that statement to 8.1. >> I hope this helps: https://github.com/webpush-wg/webpush-protocol/pull/138 > > > That works for me. That's superb. And of course I meant that I didn't know whether Ben was happy YET :-) Spencer > Thanks! > > Ben. --94eb2c073bbcd46fb1053eb67b2d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi, Martin,

On Oct 12, 2016 19:51, "Ben Campbell" <ben@nostrum.com> wrote:
>
> On 12 Oct 2016, at 19:33, Martin Thomson wrote:
>
>> On 13 October 2016 at 11:21, Ben Campbell <ben@nostrum.com> wrote:
>>>
>>> But I think I now understand this to mean e2e protection, at l= east with
>>> respect to the push service. Some clarification would help. Al= so, that seems
>>> conceptually bound more to section 8.1 than 8. (Or was 8.1 int= ended to
>>> expand on the mention in 8?)
>>
>>
>> Yes, we should be clearer.=C2=A0 And yes, 8.1 was intended to expa= nd on the
>> intro to Section 8.=C2=A0 Now that I look at this again, it's = probably
>> better to move that statement to 8.1.
>> I hope this helps: https://github.com/webpush-wg/webpush-protocol/pull/13= 8
>
>
> That works for me.

That's superb.

And of course I meant that I didn't know whether Ben was= happy YET :-)

Spencer

> Thanks!
>
> Ben.

--94eb2c073bbcd46fb1053eb67b2d-- From nobody Wed Oct 12 21:02: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 0F0A6129815; Wed, 12 Oct 2016 21:02:38 -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 KUq-q3AXG-Kq; Wed, 12 Oct 2016 21:02:35 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0133.outbound.protection.outlook.com [104.47.41.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 521BD129811; Wed, 12 Oct 2016 21:02:35 -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=yO91xfGY6z7EINGr/5KIlG3fPysIZqdM7IQYVqN8wiM=; b=KqBZKlk+tFSTnlPlGzRKjjC10gWZtIWlwYqhs9Osq9hNx+zItAJKItrPYrSz4xmbCFVk1XINn5kC0ICrfINSK/a2ndejuklWnMj7Ydfpd+qdpIb3Q2Zn3VDa7aMhfWQpSIyznCoHwYBNHbZeH6WbrUa561vdV4ePjVziAKOq5/M= Received: from CY1PR03MB2380.namprd03.prod.outlook.com (10.167.8.6) by CY1PR03MB2380.namprd03.prod.outlook.com (10.167.8.6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Thu, 13 Oct 2016 04:02:33 +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.0659.020; Thu, 13 Oct 2016 04:02:33 +0000 From: Brian Raymor To: Spencer Dawkins , The IESG Thread-Topic: Spencer Dawkins' No Objection on draft-ietf-webpush-protocol-11: (with COMMENT) Thread-Index: AQHSJMm4b3FeCiphYkefyY+63mvTsaClpngQ Date: Thu, 13 Oct 2016 04:02:33 +0000 Message-ID: References: <147630518735.6397.5697353632878943065.idtracker@ietfa.amsl.com> In-Reply-To: <147630518735.6397.5697353632878943065.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: 04affb6d-011d-4ac8-ac9e-08d3f31dc2d7 x-microsoft-exchange-diagnostics: 1; CY1PR03MB2380; 7:xtP/CVuF8yr2iVx+hQxt63mT4Mz/RpYPnH/v6Fdd1z6LwpNZsdvMd8Yp8pyN5UAB1kQOudf8NHt7rrjSnfNX3lrOaTHxCCCLx+qF8HCVZpQa90xalT34CuTRTem0lfw5MOhzSBekpGi8BaPkAIKXterfHLbl0NOv8c6FpTaJBSTVmqKeTy+HRULGIYmjSAaqLCcltCFPHQwDJbKukD4HrCogfqBYUSJMDtHmZZN6WIvMZrrciea2k8kec3hK1e82TD9Ij4vOGao3nf8M+7Xyz1PMUZi9eYPKGlZPezhzfnSYCf4FjO5S9DDTMMQvCqT1KWQw4TOba20NRptxsEyMYa53giOIxIj9XThotXZvuNX9BztPt4PVozOb93epJkgm x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2380; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(72170088055959); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2380; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2380; x-forefront-prvs: 0094E3478A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(60444003)(189002)(54094003)(199003)(76176999)(11100500001)(122556002)(105586002)(86362001)(86612001)(305945005)(2950100002)(7846002)(7736002)(97736004)(2900100001)(106356001)(99286002)(106116001)(33656002)(19580395003)(3660700001)(5001770100001)(15975445007)(87936001)(74316002)(230783001)(7696004)(8936002)(5660300001)(92566002)(3280700002)(8676002)(9686002)(10090500001)(2906002)(54356999)(68736007)(66066001)(586003)(4326007)(102836003)(5005710100001)(101416001)(3846002)(76576001)(6116002)(10400500002)(189998001)(5002640100001)(10290500002)(81166006)(81156014)(77096005)(8990500004)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2380; 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2016 04:02:33.4724 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2380 Archived-At: Cc: "draft-ietf-webpush-protocol@ietf.org" , "shida@ntt-at.com" , "webpush-chairs@ietf.org" , "webpush@ietf.org" Subject: Re: [Webpush] Spencer Dawkins' No Objection on draft-ietf-webpush-protocol-11: (with COMMENT) 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, 13 Oct 2016 04:02:38 -0000 DQpIaSBTcGVuY2VyLA0KDQo+IEkgbm90aWNlZCB0aGF0IA0KPg0KPiAgcHVzaCBtZXNzYWdlIHN1 YnNjcmlwdGlvbjogIFRoaXMgcmVzb3VyY2UgcHJvdmlkZXMgcmVhZCBhbmQgZGVsZXRlDQo+ICAg ICBhY2Nlc3MgZm9yIGEgbWVzc2FnZSBzdWJzY3JpcHRpb24uICBBIHVzZXIgYWdlbnQgcmVjZWl2 ZXMgcHVzaA0KPiAgICAgIG1lc3NhZ2VzIChTZWN0aW9uIDYpIHVzaW5nIGEgcHVzaCBtZXNzYWdl IHN1YnNjcmlwdGlvbi4gIEV2ZXJ5DQo+ICAgICBwdXNoIG1lc3NhZ2Ugc3Vic2NyaXB0aW9uIGhh cyBleGFjdGx5IG9uZSBwdXNoIHJlc291cmNlIGFzc29jaWF0ZWQNCj4gICAgIHdpdGggaXQuDQog ICAgICANCj4gYW5kDQoNCj4gICBwdXNoIG1lc3NhZ2U6ICBUaGUgcHVzaCBzZXJ2aWNlIGNyZWF0 ZXMgYSBwdXNoIG1lc3NhZ2UgcmVzb3VyY2UgdG8NCj4gICAgICBpZGVudGlmeSBwdXNoIG1lc3Nh Z2VzIHRoYXQgaGF2ZSBiZWVuIGFjY2VwdGVkIGZvciBkZWxpdmVyeQ0KPiAgICAgIChTZWN0aW9u IDUpLiAgVGhlIHB1c2ggbWVzc2FnZSByZXNvdXJjZSBpcyBhbHNvIGRlbGV0ZWQgYnkgdGhlDQo+ ICAgICAgdXNlciBhZ2VudCB0byBhY2tub3dsZWRnZSByZWNlaXB0IChTZWN0aW9uIDYuMikgb2Yg YSBwdXNoIG1lc3NhZ2UuDQogICAgICANCj4gZG9uJ3Qgc2F5ICJBIGxpbmsgcmVsYXRpb24gb2Yg dHlwZSAuLi4iIGFib3V0IHRoZSByZXNvdXJjZSBiZWluZyBkZWZpbmVkLA0KPiBidXQgDQoNCj4g ICBwdXNoIG1lc3NhZ2Ugc3Vic2NyaXB0aW9uIHNldDogIFRoaXMgcmVzb3VyY2UgcHJvdmlkZXMg cmVhZCBhbmQNCj4gICAgICBkZWxldGUgYWNjZXNzIGZvciBhIGNvbGxlY3Rpb24gb2YgcHVzaCBt ZXNzYWdlIHN1YnNjcmlwdGlvbnMuICBBDQo+ICAgICB1c2VyIGFnZW50IHJlY2VpdmVzIHB1c2gg bWVzc2FnZXMgKFNlY3Rpb24gNi4xKSBmb3IgYWxsIHRoZSBwdXNoDQo+ICAgICAgbWVzc2FnZSBz dWJzY3JpcHRpb25zIGluIHRoZSBzZXQuICBBIGxpbmsgcmVsYXRpb24gb2YgdHlwZQ0KPiAgICAg ICJ1cm46aWV0ZjpwYXJhbXM6cHVzaDpzZXQiIGlkZW50aWZpZXMgYSBwdXNoIG1lc3NhZ2Ugc3Vi c2NyaXB0aW9uDQo+ICAgICAgc2V0Lg0KDQo+ICAgcHVzaDogIEFuIGFwcGxpY2F0aW9uIHNlcnZl ciByZXF1ZXN0cyB0aGUgZGVsaXZlcnkgKFNlY3Rpb24gNSkgb2YgYQ0KPiAgICAgIHB1c2ggbWVz c2FnZSB1c2luZyBhIHB1c2ggcmVzb3VyY2UuICBBIGxpbmsgcmVsYXRpb24gb2YgdHlwZQ0KPiAg ICAgICJ1cm46aWV0ZjpwYXJhbXM6cHVzaCIgaWRlbnRpZmllcyBhIHB1c2ggcmVzb3VyY2UuDQog ICAgICANCj4gYW5kIA0KDQo+ICAgcmVjZWlwdCBzdWJzY3JpcHRpb246ICBBbiBhcHBsaWNhdGlv biBzZXJ2ZXIgcmVjZWl2ZXMgZGVsaXZlcnkNCj4gICAgICBjb25maXJtYXRpb25zIChTZWN0aW9u IDUuMSkgZm9yIHB1c2ggbWVzc2FnZXMgdXNpbmcgYSByZWNlaXB0DQo+ICAgICBzdWJzY3JpcHRp b24uICBBIGxpbmsgcmVsYXRpb24gb2YgdHlwZQ0KPiAgICAgICJ1cm46aWV0ZjpwYXJhbXM6cHVz aDpyZWNlaXB0IiBpZGVudGlmaWVzIGEgcmVjZWlwdCBzdWJzY3JpcHRpb24uDQogICAgICANCj4g ZG8uIElzIHRoYXQgaW50ZW50aW9uYWw/IE9yIHdvdWxkIGxpbmsgcmVsYXRpb24gaW5kZW50aWZp Y2F0aW9uIG5vdCBiZQ0KPiB1c2VmdWwgZm9yIHRoZXNlIHJlc291cmNlcyAoaWYgeW91IHRvbGQg bWUgdGhhdCwgSSdkIGJlbGlldmUgeW91KS4NCg0KSXQgaXMgaW50ZW50aW9uYWwuIEJvdGggdGhl IHB1c2ggbWVzc2FnZSBzdWJzY3JpcHRpb24gYW5kIHRoZSBwdXNoIG1lc3NhZ2UNCnJlc291cmNl cyBhcmUgcmV0dXJuZWQgaW4gdGhlIExvY2F0aW9uOiBoZWFkZXIgaW4gdGhlIDIwMSAoQ3JlYXRl ZCkgcmVzcG9uc2UNCmFuZCBkb24ndCByZXF1aXJlIGEgcmVkdW5kYW50IGxpbmsgcmVsYXRpb24u DQoNCkZvciBleGFtcGxlOg0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi13ZWJwdXNoLXByb3RvY29sLTExI3NlY3Rpb24tNA0KDQogICBBIDIwMSAoQ3JlYXRlZCkgcmVz cG9uc2UgaW5kaWNhdGVzIHRoYXQgdGhlIHB1c2ggc3Vic2NyaXB0aW9uIHdhcw0KICAgY3JlYXRl ZC4gIEEgVVJJIGZvciB0aGUgcHVzaCBtZXNzYWdlIHN1YnNjcmlwdGlvbiByZXNvdXJjZSB0aGF0 IHdhcw0KICAgY3JlYXRlZCBpbiByZXNwb25zZSB0byB0aGUgcmVxdWVzdCBNVVNUIGJlIHJldHVy bmVkIGluIHRoZSBMb2NhdGlvbg0KICAgaGVhZGVyIGZpZWxkLg0KDQo+IEkgc2VlIHRoYXQgVG9w aWM6IGhhcyBubyBzZW1hbnRpY3MsIGJ1dCBJIHdvbmRlciBpZiB0aGUgZXhhbXBsZSB1c2Ugb2YN Cj4gVG9waWMgaW4gU2VjdGlvbiA1LjQgbWlnaHQgYmUgY2xlYXJlciBpZiBhIGRpZmZlcmVudCBU b3BpYyB3YXMgdXNlZCAtDQo+ICJUb3BpYzogdXBkIiBsb29rcyBsaWtlICJ1cGQiIHdvdWxkIGhh dmUgc2VtYW50aWMgbWVhbmluZywgb24gZmlyc3QNCj4gcmVhZGluZy4NCg0KSSdtIG9wZW4gdG8g c3VnZ2VzdGlvbnMsIGJ1dCBJIGRvbid0IGtub3cgdGhhdCBhIGNoYW5nZSB3b3VsZCBlbmhhbmNl DQpjbGFyaXR5LiANCg0KPiBJIHdvbmRlcmVkIHdoeSB0aGUgdXNlIG9mIHN1YnNjcmlwdGlvbiBz ZXRzIGluDQoNCj4gICBUaGVyZSBhcmUgbWlub3IgZGlmZmVyZW5jZXMgYmV0d2VlbiByZWNlaXZp bmcgcHVzaCBtZXNzYWdlcyBmb3IgYQ0KPiAgIHN1YnNjcmlwdGlvbiBhbmQgYSBzdWJzY3JpcHRp b24gc2V0LiAgSWYgYSBzdWJzY3JpcHRpb24gc2V0IGlzDQo+ICAgYXZhaWxhYmxlLCB0aGUgdXNl ciBhZ2VudCBTSE9VTEQgdXNlIHRoZSBzdWJzY3JpcHRpb24gc2V0IHRvIG1vbml0b3INCj4gICBm b3IgcHVzaCBtZXNzYWdlcyByYXRoZXIgdGhhbiBpbmRpdmlkdWFsIHB1c2ggbWVzc2FnZSBzdWJz Y3JpcHRpb25zLg0KICAgDQo+IHdhcyBhIFNIT1VMRCwgYW5kIG5vdCBhIE1VU1QuIElzIHRoaXMg anVzdCBhbiBlZmZpY2llbmN5IHRoaW5nLCBvciBpcyBpdA0KPiBzb21ldGhpbmcgZWxzZT8gSXQg d291bGQgYmUgaGVscGZ1bCB0byBleHBsYWluIHRoaXMuDQoNClN1YnNjcmlwdGlvbiBzZXRzIGV2 b2x2ZWQgb3ZlciB0aW1lIGFzIHdlIGV4cGxvcmVkIGFwcHJvcHJpYXRlIG1vZGVscw0Kc3VjaCBh cyAicHVzaCBzZXJ2aWNlIGRlY2lkZXMiIG9yICJ1c2VyIGFnZW50IGRlY2lkZXMiLiBJbiB0aGUg ZW5kLCB3ZSBuZWVkZWQgdG8NCmVuc3VyZSB0aGF0IHRoZSBzdWJzY3JpcHRpb24gc2V0IGRlc2ln biB3YXMgZmxleGlibGUgZW5vdWdoIHRvIGFkZHJlc3MgYQ0KYnJvYWQgcmFuZ2Ugb2Ygc2NlbmFy aW9zLCBpbmNsdWRpbmcgYSBsYXRlLWJyZWFraW5nIG9uZSBmcm9tIENhbm9uOg0KDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3dlYnB1c2gvY3VycmVudC9tc2cwMDM1Ny5o dG1sDQoNCndoaWNoIHJlc3VsdGVkIGluICJ1c2VyIGFnZW50IGRlY2lkZXMiICsgInB1c2ggc2Vy dmljZSBlbmNvdXJhZ2VzIi4NCg0KU3Vic2NyaXB0aW9uIHNldHMgYXJlIGluY2x1ZGVkIGZvciBl ZmZpY2llbmN5IGFzIGRlc2NyaWJlZDoNCg0KICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLXdlYnB1c2gtcHJvdG9jb2wtMTEjc2VjdGlvbi00LjENCg0KICAgQ29sbGVj dGluZyBtdWx0aXBsZSBwdXNoIG1lc3NhZ2Ugc3Vic2NyaXB0aW9ucyBpbnRvIGEgc3Vic2NyaXB0 aW9uDQogICBzZXQgY2FuIHJlcHJlc2VudCBhIHNpZ25pZmljYW50IGVmZmljaWVuY3kgaW1wcm92 ZW1lbnQgZm9yIHB1c2gNCiAgIHNlcnZpY2VzIGFuZCB1c2VyIGFnZW50cy4gIFRoZSBwdXNoIHNl cnZpY2UgTUFZIHByb3ZpZGUgYSBVUkkgZm9yIGENCiAgIHN1YnNjcmlwdGlvbiBzZXQgcmVzb3Vy Y2UgaW4gYSBsaW5rIHJlbGF0aW9uIG9mIHR5cGUNCiAgICJ1cm46aWV0ZjpwYXJhbXM6cHVzaDpz ZXQiLg0KDQogICBXaGVuIGEgc3Vic2NyaXB0aW9uIHNldCBpcyByZXR1cm5lZCBpbiBhIHB1c2gg bWVzc2FnZSBzdWJzY3JpcHRpb24NCiAgIHJlc3BvbnNlLCB0aGUgdXNlciBhZ2VudCBTSE9VTEQg aW5jbHVkZSB0aGlzIHN1YnNjcmlwdGlvbiBzZXQgaW4gYQ0KICAgbGluayByZWxhdGlvbiBvZiB0 eXBlICJ1cm46aWV0ZjpwYXJhbXM6cHVzaDpzZXQiIGluIHN1YnNlcXVlbnQNCiAgIHJlcXVlc3Rz IHRvIGNyZWF0ZSBuZXcgcHVzaCBtZXNzYWdlIHN1YnNjcmlwdGlvbnMuDQoNClRoaXMgd2FzIGFk ZGVkIGZvciBIZXJ2ZSdzIHNjZW5hcmlvOg0KDQogICBBIHVzZXIgYWdlbnQgTUFZIG9taXQgdGhl IHN1YnNjcmlwdGlvbiBzZXQgaWYgaXQgaXMgdW5hYmxlIHRvIHJlY2VpdmUNCiAgIHB1c2ggbWVz c2FnZXMgaW4gYW4gYWdncmVnYXRlZCB3YXkgZm9yIHRoZSBsaWZldGltZSBvZiB0aGUNCiAgIHN1 YnNjcmlwdGlvbi4gIFRoaXMgbWlnaHQgYmUgbmVjZXNzYXJ5IGlmIHRoZSB1c2VyIGFnZW50IGlz DQogICBtb25pdG9yaW5nIHN1YnNjcmlwdGlvbnMgb24gYmVoYWxmIG9mIG90aGVyIHB1c2ggbWVz c2FnZSByZWNlaXZlcnMuDQoNCj4gSXMgdGhlcmUgYW55IGd1aWRhbmNlIHlvdSBjb3VsZCBnaXZl IGFib3V0IHRoZSByZXRyeSBtZWNoYW5pc20gZGVzY3JpYmVkDQo+IGluIHRoaXMgdGV4dD8gSG93 IG1hbnkgdGltZXMsIGhvdyBvZnRlbiwgZXRjLiANCg0KPiAgIElmIHRoZSBwdXNoIHNlcnZpY2Ug ZG9lcyBub3QgcmVjZWl2ZSB0aGUgYWNrbm93bGVkZ2VtZW50IHdpdGhpbiBhDQo+ICAgcmVhc29u YWJsZSBhbW91bnQgb2YgdGltZSwgdGhlbiB0aGUgbWVzc2FnZSBpcyBjb25zaWRlcmVkIHRvIGJl IG5vdA0KPiAgIHlldCBkZWxpdmVyZWQuICBUaGUgcHVzaCBzZXJ2aWNlIFNIT1VMRCBjb250aW51 ZSB0byByZXRyeSBkZWxpdmVyeSBvZg0KPiAgIHRoZSBtZXNzYWdlIHVudGlsIGl0cyBhZHZlcnRp c2VkIGV4cGlyYXRpb24uDQoNClRoZXJlJ3Mgbm8gZ2VuZXJhbCBndWlkYW5jZS4gVGhlIHBvbGlj eSB3b3VsZCBiZSBzcGVjaWZpYyB0byBhIHB1c2ggc2VydmljZS4NCg0KPiBJJ20gZ3Vlc3Npbmcg dGhhdA0KDQo+ICAgQSBwdXNoIHNlcnZpY2UgdGhhdCBkb2VzIG5vdCBzdXBwb3J0IHJlbGlhYmxl IGRlbGl2ZXJ5IG92ZXINCj4gICBpbnRlcm1pdHRlbnQgbmV0d29yayBjb25uZWN0aW9ucyBvciBm YWlsaW5nIGFwcGxpY2F0aW9ucyBvbiBkZXZpY2VzLA0KPiAgIGZvcmNlcyB0aGUgZGV2aWNlIHRv IGFja25vd2xlZGdlIHJlY2VpcHQgZGlyZWN0bHkgdG8gdGhlIGFwcGxpY2F0aW9uDQo+ICAgc2Vy dmVyLCBpbmN1cnJpbmcgYWRkaXRpb25hbCBwb3dlciBkcmFpbiBpbiBvcmRlciB0byBlc3RhYmxp c2gNCj4gICAodXN1YWxseSBzZWN1cmUpIGNvbm5lY3Rpb25zIHRvIHRoZSBpbmRpdmlkdWFsIGFw cGxpY2F0aW9uIHNlcnZlcnMuDQogICANCj4gaXNuJ3QganVzdCBhYm91dCAiZXN0YWJsaXNoIiwg YnV0ICJlc3RhYmxpc2ggYW5kIG1haW50YWluIj8NCg0KVGhhdCB3b3VsZCBiZSBtb3JlIHByZWNp c2UuIFVwZGF0aW5nLiANCg0KDQo= From nobody Wed Oct 12 21:10:16 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 0579B12980D; Wed, 12 Oct 2016 21:10:11 -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=unavailable 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 ZEvXpr79z_9y; Wed, 12 Oct 2016 21:10:09 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0137.outbound.protection.outlook.com [104.47.40.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C021129818; Wed, 12 Oct 2016 21:04:32 -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=nCG1L8C/Tzx8zI6nM82lxLiasgSW+X5Kqv5XBTMdeR8=; b=YREtWubL/qGBBXh3yEeAhQsWQbT3fVH6UUpNOt7Tcvc2AH83ML0RwIj5dNafdrYnBqwuHf6xD7tNBApMbgbIKLao+NSdAahdlUDaHSPKbsAN9DJ2BkU9ng98UgOlohrY0SvslZyYzWPlyEjM21uli6ElZ1buKYHoyNW0WB3dpwo= Received: from CY1PR03MB2380.namprd03.prod.outlook.com (10.167.8.6) by CY1PR03MB2380.namprd03.prod.outlook.com (10.167.8.6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Thu, 13 Oct 2016 04:04:31 +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.0659.020; Thu, 13 Oct 2016 04:04:31 +0000 From: Brian Raymor To: "kathleen.moriarty.ietf@gmail.com" Thread-Topic: Kathleen Moriarty's No Objection on draft-ietf-webpush-protocol-11: (with COMMENT) Thread-Index: AQHSJLYoZNpGErSVEEe1X/Yl9wYANaClkmGwgAAM2QCAACUIsA== Date: Thu, 13 Oct 2016 04:04:30 +0000 Message-ID: References: <147629678445.6285.5038003546245862234.idtracker@ietfa.amsl.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: [174.61.159.182] x-ms-office365-filtering-correlation-id: 13936f0f-991b-45e4-24fd-08d3f31e08d5 x-microsoft-exchange-diagnostics: 1; CY1PR03MB2380; 7:NqClFw2snmuf4Jt5ZKkZ/UJLgxYOiuuE9/FVfftI2zJ/f35UAikVG/0TQikJyWx9d+TEjx2pAWtDDeyIKOiJdxf0z4yJK+A5yf/zEy9ZasseQ6KIj3TWgnHnFY6v9A+PACZ9QQDkhV3dJ1Q3sxF34+KF9MSF1eV8+UDWyZZDtVaCESAcJHxIS9JzsAy/eBXIwt2YU6Yu0r72JuIRcyOgTgsqh8GN6myUgbYItkupVilgXMuG8ll8cntIaa+qcwbudo+rT7Kt1W7U57xlhbwFTq1MwkzSEBvJ7vzSd+vqQjAwB2uzL/4Xpt83ZdRQeKjapKTiDgAQv1aeTBmTcgBn9EUhgiFyFnEHMOSFDpj+ymoR1BuOl+riaOkIre0J2v5U x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2380; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2380; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2380; x-forefront-prvs: 0094E3478A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(377454003)(24454002)(51914003)(189002)(199003)(76176999)(11100500001)(122556002)(105586002)(6916009)(86362001)(86612001)(305945005)(2950100002)(2351001)(7846002)(7736002)(97736004)(2900100001)(106356001)(99286002)(106116001)(33656002)(19580395003)(19580405001)(3660700001)(15975445007)(110136003)(87936001)(74316002)(230783001)(7696004)(8936002)(5640700001)(2501003)(5660300001)(92566002)(3280700002)(8676002)(9686002)(10090500001)(2906002)(54356999)(68736007)(66066001)(586003)(4326007)(102836003)(5005710100001)(101416001)(3846002)(76576001)(6116002)(10400500002)(189998001)(5002640100001)(10290500002)(81166006)(81156014)(77096005)(8990500004)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2380; 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 Oct 2016 04:04:30.8773 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2380 Archived-At: Cc: "draft-ietf-webpush-protocol@ietf.org" , Shida Schubert , "webpush-chairs@ietf.org" , The IESG , "webpush@ietf.org" Subject: Re: [Webpush] Kathleen Moriarty's No Objection on draft-ietf-webpush-protocol-11: (with COMMENT) 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, 13 Oct 2016 04:10:11 -0000 Done. -----Original Message----- From: kathleen.moriarty.ietf@gmail.com [mailto:kathleen.moriarty.ietf@gmail= .com]=20 Sent: Wednesday, October 12, 2016 6:52 PM To: Brian Raymor Cc: The IESG ; draft-ietf-webpush-protocol@ietf.org; Shida S= chubert ; webpush-chairs@ietf.org; webpush@ietf.org Subject: Re: Kathleen Moriarty's No Objection on draft-ietf-webpush-protoco= l-11: (with COMMENT) Please excuse typos, sent from handheld device=20 > On Oct 12, 2016, at 9:09 PM, Brian Raymor wr= ote: >=20 >=20 >> The only thing I might add is a note on the varying levels of security >> offered by the HTTP authentication methods, which are documented in thei= r >> RFCs. Adding just that point to the following (phrased however you'd >> like) would be helpful: >> A push service MAY >> choose to authorize requests based on any HTTP-compatible >> authorization method available, of which there are numerous options. >=20 >> The somewhat recent updates to Basic & Digest do a really great job at >> saying how awful they are and there are some experimental options that >> offer some promise now. >=20 > Proposed text - https://github.com/webpush-wg/webpush-protocol/pull/139/f= iles Thanks for the quick update. I would just say 'with varying levels of secu= rity.' The security considerations sections for each of the methods availa= ble for HTTP are included in the RFCs for each. Thank you, Kathleen=20 >=20 >=20 >=20 From nobody Wed Oct 12 21:13: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 E0CAF129805; Wed, 12 Oct 2016 21:13:11 -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 17J13DjSSGcL; Wed, 12 Oct 2016 21:13:09 -0700 (PDT) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002: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 C850A12983A; Wed, 12 Oct 2016 21:13:08 -0700 (PDT) Received: by mail-yb0-x235.google.com with SMTP id 184so26667498yby.2; Wed, 12 Oct 2016 21:13:08 -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=r3/QBvrHh4+pioMLNUgQrObrcmSU2YSdb/sRcVX6SOs=; b=Q+QveVvkNFeAG78FNl2L4vyjDJjHLx+rJa5PvsR4tzvdyydPqslTE88Uf25claqz4W 7foJCrG/wgsaanIkB6CDim/Y8DFlYK8JtFXHAdRwZB40i/+bpjex4Prbp70LWRValGHG 7xrkFPns/Z13B4qjL9a24Pwa7oTS2PBz4FPZXc/7+53ll+Kee3Dxhee3kf32va8Bx9Uc 2PABZ074WvBejhTk7kkpRlEVxu5aWjndg+91tXqshnrWdVHP8yd55jOFZFpq2MvjxxmZ 0bVlDuPJ+7J2t4BnvHEXE55DEkvXY/RLstBPxs9ooqKXTWiQKc6WIGTUcsuYxG5rVeY2 skQg== 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=r3/QBvrHh4+pioMLNUgQrObrcmSU2YSdb/sRcVX6SOs=; b=Fo58s/I3F4s+laoVXFBuxLhTAq0WGql8kzwzN+nOc5SVMadbI/GUPTivZ6vOU0Q2mG ktROMIkk0rjNPnet7RkKD3y2oNGdIRGhOEsvjj4q+VPdUAAYv1ztNXo9Nh2Rq4wByQtZ 7dKHYYI9MCfuDfPFP+yyzFahk0XFKswfWfjveIInGo2Rg0wD1MsLyWU2LoqdGiXrYQYL D9eplLIoBLopiIV2WcPEFLrdWsnYBcaSXSlEng1U7+b2m2Nix5WQm1bkAH18/T+DrVwz Ps6R56kTideqIycwQwBypEF4zM8hgHXNCBsn631pONBUI/5Iu+forl9IXj51ILeaFKTY RSZw== X-Gm-Message-State: AA6/9RmQYTkcUXHt1inimC4ZiVBqsj9CiTOL2040/xEJfdx9VrstC2Mj8CDkEoEUkU5Q8ndrfSPyPWfR2EgklA== X-Received: by 10.37.171.65 with SMTP id u59mr4040397ybi.12.1476331987975; Wed, 12 Oct 2016 21:13:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.92.67 with HTTP; Wed, 12 Oct 2016 21:13:07 -0700 (PDT) Received: by 10.37.92.67 with HTTP; Wed, 12 Oct 2016 21:13:07 -0700 (PDT) In-Reply-To: References: <147630518735.6397.5697353632878943065.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Wed, 12 Oct 2016 23:13:07 -0500 Message-ID: To: "Brian Raymor (MS OPEN TECH)" Content-Type: multipart/alternative; boundary=94eb2c19ba6cb6c40b053eb753a3 Archived-At: Cc: "draft-ietf-webpush-protocol@ietf.org" , "shida@ntt-at.com" , webpush-chairs@ietf.org, iesg@ietf.org, "webpush@ietf.org" Subject: Re: [Webpush] Spencer Dawkins' No Objection on draft-ietf-webpush-protocol-11: (with COMMENT) 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, 13 Oct 2016 04:13:12 -0000 --94eb2c19ba6cb6c40b053eb753a3 Content-Type: text/plain; charset=UTF-8 Hi, Brian, Thanks for the helpful explanation, and thanks for considering my comments. Spencer On Oct 12, 2016 23:02, "Brian Raymor" wrote: > > > Hi Spencer, > > > I noticed that > > > > push message subscription: This resource provides read and delete > > access for a message subscription. A user agent receives push > > messages (Section 6) using a push message subscription. Every > > push message subscription has exactly one push resource associated > > with it. > > > and > > > 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. > > > don't say "A link relation of type ..." about the resource being defined, > > but > > > push message subscription set: This resource provides read and > > delete access for a collection of push message subscriptions. A > > user agent receives push messages (Section 6.1) for all the push > > message subscriptions in the set. A link relation of type > > "urn:ietf:params:push:set" identifies a push message subscription > > set. > > > push: An application server requests the delivery (Section 5) of a > > push message using a push resource. A link relation of type > > "urn:ietf:params:push" identifies a push resource. > > > and > > > receipt subscription: An application server receives delivery > > confirmations (Section 5.1) for push messages using a receipt > > subscription. A link relation of type > > "urn:ietf:params:push:receipt" identifies a receipt subscription. > > > do. Is that intentional? Or would link relation indentification not be > > useful for these resources (if you told me that, I'd believe you). > > It is intentional. Both the push message subscription and the push message > resources are returned in the Location: header in the 201 (Created) response > and don't require a redundant link relation. > > For example: > > https://tools.ietf.org/html/draft-ietf-webpush-protocol-11#section-4 > > A 201 (Created) response indicates that the push subscription was > created. A URI for the push message subscription resource that was > created in response to the request MUST be returned in the Location > header field. > > > I see that Topic: has no semantics, but I wonder if the example use of > > Topic in Section 5.4 might be clearer if a different Topic was used - > > "Topic: upd" looks like "upd" would have semantic meaning, on first > > reading. > > I'm open to suggestions, but I don't know that a change would enhance > clarity. > > > I wondered why the use of subscription sets in > > > There are minor differences between receiving push messages for a > > subscription and a subscription set. If a subscription set is > > available, the user agent SHOULD use the subscription set to monitor > > for push messages rather than individual push message subscriptions. > > > was a SHOULD, and not a MUST. Is this just an efficiency thing, or is it > > something else? It would be helpful to explain this. > > Subscription sets evolved over time as we explored appropriate models > such as "push service decides" or "user agent decides". In the end, we needed to > ensure that the subscription set design was flexible enough to address a > broad range of scenarios, including a late-breaking one from Canon: > > https://www.ietf.org/mail-archive/web/webpush/current/msg00357.html > > which resulted in "user agent decides" + "push service encourages". > > Subscription sets are included for efficiency as described: > > https://tools.ietf.org/html/draft-ietf-webpush-protocol-11#section-4.1 > > Collecting multiple push message subscriptions into a subscription > set can represent a significant efficiency improvement for push > services and user agents. The push service MAY provide a URI for a > subscription set resource in a link relation of type > "urn:ietf:params:push:set". > > When a subscription set is returned in a push message subscription > response, the user agent SHOULD include this subscription set in a > link relation of type "urn:ietf:params:push:set" in subsequent > requests to create new push message subscriptions. > > This was added for Herve's scenario: > > A user agent MAY omit the subscription set if it is unable to receive > push messages in an aggregated way for the lifetime of the > subscription. This might be necessary if the user agent is > monitoring subscriptions on behalf of other push message receivers. > > > Is there any guidance you could give about the retry mechanism described > > in this text? How many times, how often, etc. > > > If the push service does not receive the acknowledgement within a > > reasonable amount of time, then the message is considered to be not > > yet delivered. The push service SHOULD continue to retry delivery of > > the message until its advertised expiration. > > There's no general guidance. The policy would be specific to a push service. > > > I'm guessing that > > > A push service that does not support reliable delivery over > > intermittent network connections or failing applications on devices, > > forces the device to acknowledge receipt directly to the application > > server, incurring additional power drain in order to establish > > (usually secure) connections to the individual application servers. > > > isn't just about "establish", but "establish and maintain"? > > That would be more precise. Updating. > > --94eb2c19ba6cb6c40b053eb753a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi, Brian,

Thanks for the helpful explanation, and thanks for consideri= ng my comments.

Spencer

On Oct 12, 2016 23:02, "Brian Raymor" <Brian.Raymor@microsoft.com> w= rote:
>
>
> Hi Spencer,
>
> > I noticed that
> >
> >=C2=A0 push message subscription:=C2=A0 This resource provides rea= d and delete
> >=C2=A0 =C2=A0 =C2=A0access for a message subscription.=C2=A0 A use= r agent receives push
> >=C2=A0 =C2=A0 =C2=A0 messages (Section 6) using a push message sub= scription.=C2=A0 Every
> >=C2=A0 =C2=A0 =C2=A0push message subscription has exactly one push= resource associated
> >=C2=A0 =C2=A0 =C2=A0with it.
>
> > and
>
> >=C2=A0 =C2=A0push message:=C2=A0 The push service creates a push m= essage resource to
> >=C2=A0 =C2=A0 =C2=A0 identify push messages that have been accepte= d for delivery
> >=C2=A0 =C2=A0 =C2=A0 (Section 5).=C2=A0 The push message resource = is also deleted by the
> >=C2=A0 =C2=A0 =C2=A0 user agent to acknowledge receipt (Section 6.= 2) of a push message.
>
> > don't say "A link relation of type ..." about the r= esource being defined,
> > but
>
> >=C2=A0 =C2=A0push message subscription set:=C2=A0 This resource pr= ovides read and
> >=C2=A0 =C2=A0 =C2=A0 delete access for a collection of push messag= e subscriptions.=C2=A0 A
> >=C2=A0 =C2=A0 =C2=A0user agent receives push messages (Section 6.1= ) for all the push
> >=C2=A0 =C2=A0 =C2=A0 message subscriptions in the set.=C2=A0 A lin= k relation of type
> >=C2=A0 =C2=A0 =C2=A0 "urn:ietf:params:push:set" identifi= es a push message subscription
> >=C2=A0 =C2=A0 =C2=A0 set.
>
> >=C2=A0 =C2=A0push:=C2=A0 An application server requests the delive= ry (Section 5) of a
> >=C2=A0 =C2=A0 =C2=A0 push message using a push resource.=C2=A0 A l= ink relation of type
> >=C2=A0 =C2=A0 =C2=A0 "urn:ietf:params:push" identifies a= push resource.
>
> > and
>
> >=C2=A0 =C2=A0receipt subscription:=C2=A0 An application server rec= eives delivery
> >=C2=A0 =C2=A0 =C2=A0 confirmations (Section 5.1) for push messages= using a receipt
> >=C2=A0 =C2=A0 =C2=A0subscription.=C2=A0 A link relation of type > >=C2=A0 =C2=A0 =C2=A0 "urn:ietf:params:push:receipt" iden= tifies a receipt subscription.
>
> > do. Is that intentional? Or would link relation indentification n= ot be
> > useful for these resources (if you told me that, I'd believe = you).
>
> It is intentional. Both the push message subscription and the push mes= sage
> resources are returned in the Location: header in the 201 (Created) re= sponse
> and don't require a redundant link relation.
>
> For example:
>
> https://tools.ietf.org/html/draft-ietf-webpush-protocol-11#secti= on-4
>
> =C2=A0 =C2=A0A 201 (Created) response indicates that the push subscrip= tion was
> =C2=A0 =C2=A0created.=C2=A0 A URI for the push message subscription re= source that was
> =C2=A0 =C2=A0created in response to the request MUST be returned in th= e Location
> =C2=A0 =C2=A0header field.
>
> > I see that Topic: has no semantics, but I wonder if the example u= se of
> > Topic in Section 5.4 might be clearer if a different Topic was us= ed -
> > "Topic: upd" looks like "upd" would have sema= ntic meaning, on first
> > reading.
>
> I'm open to suggestions, but I don't know that a change would = enhance
> clarity.
>
> > I wondered why the use of subscription sets in
>
> >=C2=A0 =C2=A0There are minor differences between receiving push me= ssages for a
> >=C2=A0 =C2=A0subscription and a subscription set.=C2=A0 If a subsc= ription set is
> >=C2=A0 =C2=A0available, the user agent SHOULD use the subscription= set to monitor
> >=C2=A0 =C2=A0for push messages rather than individual push message= subscriptions.
>
> > was a SHOULD, and not a MUST. Is this just an efficiency thing, o= r is it
> > something else? It would be helpful to explain this.
>
> Subscription sets evolved over time as we explored appropriate models<= br> > such as "push service decides" or "user agent decides&q= uot;. In the end, we needed to
> ensure that the subscription set design was flexible enough to address= a
> broad range of scenarios, including a late-breaking one from Canon: >
> https://www.ietf.org/mail-archive/web/webpush/current/msg00357.ht= ml
>
> which resulted in "user agent decides" + "push service = encourages".
>
> Subscription sets are included for efficiency as described:
>
> =C2=A0 =C2=A0 https://tools.ietf.org/html/draft-ietf-webpush-p= rotocol-11#section-4.1
>
> =C2=A0 =C2=A0Collecting multiple push message subscriptions into a sub= scription
> =C2=A0 =C2=A0set can represent a significant efficiency improvement fo= r push
> =C2=A0 =C2=A0services and user agents.=C2=A0 The push service MAY prov= ide a URI for a
> =C2=A0 =C2=A0subscription set resource in a link relation of type
> =C2=A0 =C2=A0"urn:ietf:params:push:set".
>
> =C2=A0 =C2=A0When a subscription set is returned in a push message sub= scription
> =C2=A0 =C2=A0response, the user agent SHOULD include this subscription= set in a
> =C2=A0 =C2=A0link relation of type "urn:ietf:params:push:set"= ; in subsequent
> =C2=A0 =C2=A0requests to create new push message subscriptions.
>
> This was added for Herve's scenario:
>
> =C2=A0 =C2=A0A user agent MAY omit the subscription set if it is unabl= e to receive
> =C2=A0 =C2=A0push messages in an aggregated way for the lifetime of th= e
> =C2=A0 =C2=A0subscription.=C2=A0 This might be necessary if the user a= gent is
> =C2=A0 =C2=A0monitoring subscriptions on behalf of other push message = receivers.
>
> > Is there any guidance you could give about the retry mechanism de= scribed
> > in this text? How many times, how often, etc.
>
> >=C2=A0 =C2=A0If the push service does not receive the acknowledgem= ent within a
> >=C2=A0 =C2=A0reasonable amount of time, then the message is consid= ered to be not
> >=C2=A0 =C2=A0yet delivered.=C2=A0 The push service SHOULD continue= to retry delivery of
> >=C2=A0 =C2=A0the message until its advertised expiration.
>
> There's no general guidance. The policy would be specific to a pus= h service.
>
> > I'm guessing that
>
> >=C2=A0 =C2=A0A push service that does not support reliable deliver= y over
> >=C2=A0 =C2=A0intermittent network connections or failing applicati= ons on devices,
> >=C2=A0 =C2=A0forces the device to acknowledge receipt directly to = the application
> >=C2=A0 =C2=A0server, incurring additional power drain in order to = establish
> >=C2=A0 =C2=A0(usually secure) connections to the individual applic= ation servers.
>
> > isn't just about "establish", but "establish a= nd maintain"?
>
> That would be more precise. Updating.
>
>

--94eb2c19ba6cb6c40b053eb753a3-- From nobody Thu Oct 13 02:56: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 ED1E31294A9; Thu, 13 Oct 2016 02:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RCVD_IN_MSPIKE_H2=-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=fastmail.fm header.b=dv1wyRUV; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=E/vhONg/ 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 oTf8muP_QuUk; Thu, 13 Oct 2016 02:56:32 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB9DA129486; Thu, 13 Oct 2016 02:56:32 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 3A44420507; Thu, 13 Oct 2016 05:56:32 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute4.internal (MEProxy); Thu, 13 Oct 2016 05:56:32 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; 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=jYR6DeQNoxeMiE7Gj3vCJHYafvk=; b=dv1wyR UVzGT1pLp5o1TF1QPIkwTY603ATvFjYawzxg8VZoqbEOwK8wP0pq3Rup5ACxz3BC ZSdbX8jDcisDyffoq8LLXmdiw8P3JrHrjaQW8PhOQhGxhe36heKev2h7eBGRVpfZ 4s3j5vtzHl2mgM2o1FDMXRGh36DzVNeVlJLVw= 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=jYR6DeQNoxeMiE7 Gj3vCJHYafvk=; b=E/vhONg/u6JRBTiVvZFSvyl0n1O5avRbxHdGtM5e32Je79p A6plFPNOwOgyLX/Gxf2AdL7tWpxZnPqzypiTnHFQ2Z90e4DM+g4MuEStRufMz3+F Av+jFhmwkuon/AqdgmEAyvVKSU3RnPJEmwP93UWC4hDX00Od8PF6jg7R4KWc= Received: by mailuser.nyi.internal (Postfix, from userid 99) id F1ACA96EAB; Thu, 13 Oct 2016 05:56:31 -0400 (EDT) Message-Id: <1476352591.1585721.754587537.1DA8D41A@webmail.messagingengine.com> X-Sasl-Enc: GComPu0zyDvY8IAW7l6QFjkVse1KUbxIuDAiT/HqOR6+ 1476352591 From: Alexey Melnikov To: Martin Thomson MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-cdbff290 Date: Thu, 13 Oct 2016 10:56:31 +0100 In-Reply-To: References: <147628318443.27316.12918309346360247871.idtracker@ietfa.amsl.com> Archived-At: Cc: draft-ietf-webpush-protocol@ietf.org, Shida Schubert , webpush-chairs@ietf.org, The IESG , webpush@ietf.org Subject: Re: [Webpush] Alexey Melnikov's Discuss on draft-ietf-webpush-protocol-11: (with DISCUSS and COMMENT) 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, 13 Oct 2016 09:56:34 -0000 Your changes look good to me. Thank you! From nobody Thu Oct 13 04:32:43 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 79159129710; Thu, 13 Oct 2016 04:32:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147635835847.2906.17004979879098398253.idtracker@ietfa.amsl.com> Date: Thu, 13 Oct 2016 04:32:38 -0700 Archived-At: Cc: draft-ietf-webpush-protocol@ietf.org, shida@ntt-at.com, webpush-chairs@ietf.org, webpush@ietf.org Subject: [Webpush] Stephen Farrell's Discuss on draft-ietf-webpush-protocol-11: (with DISCUSS and COMMENT) 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, 13 Oct 2016 11:32:38 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-webpush-protocol-11: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-webpush-protocol/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Apologies if some of this is a bit wrong, I had to review this while not at a keyboard so I might make a booboo or two mapping my mental notes to text:-) Apologies also if some of the earlier discussion affects these, I didn't get a chance to check the PRs created as a result of other IESG comments. (1) This might just me being confused (in which case, sorry) but I'm not quite clear on how with works with the SOP. Given you (reasonably) recommend a different port (which is a different origin than 443) are you saying here that the SOP doesn't apply to the client? (Well, actually you don't say, so I'm not sure:-) If the SOP applies, how is the port change handled? If the SOP does not apply, then what does? (Given that I assume some UAs at least will not change their handling of the SOP no matter what we say here.) (2) So-called "capability URLs" (is that a new term here? seems like it could be the topic for a useful informational rfc) are clearly weak, but also clearly as good as we'll get for some things. However, those also become known over time, (in which case they are toast;-) so why don't you need to provide a way for a push service to say "hey, instead of in future you'll need to use "? If that could be done as an extension later, then I'd be ok with that in terms of clearing the discuss, but then I think you'd need to mention it, so that applications and UAs don't build in an assumption that these URLs are fixed for all time (while also needing to be kept "secret" as with other bearer tokens). (3) Why is it not correct to encourage mutual-auth TLS for the application to push-service connections? I'm not arguing to make that mandatory, but it's not that hard in many cases and is very useful, esp since without some client auth just knowing the URL will often enable a sender to send a crap load of updates to possibly many bandwidth/power-challenged UAs. (This is only a discuss because of that potential DoS vector.) (4) Is it really honest to say that the W3C Push API, webpush encryption and vapid are only informative references? The first seems easy to make normative, the second I think really needs to exist before we ought recommend this all get out into the wild and I'm not clear if one could sensibly make a service for this without the 3rd. Yes that might add some delay to the RFC being issued, but that might be the right thing to do. Why is it right to not wait on those two IDs and the w3c rec? This is mainly a discuss in case the answer is "we know nobody's gonna do webpush-encryption ever" in which case I'd like to be convinced that implementing and deploying based on this draft without reading those references defines a good standard. I'm not saying that it does not, I'm saying I'm not yet convinced. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - Thanks for the MUST use TLS. That's totally necessary here. (Even if maybe not sufficient:-) - I just want to check this is correct: I think it'd be potentially useful to be able to pad the traffic here with NOOP pushed messages. The argument is that the existence of a message may sometimes be the same as knowing the message content and the cost of turning on the radio to even check is no different from checking and getting a NOOP pushed message, so there's no major cost to a reasonably sized NOOP message that's only there for traffic padding. (While padding at other layers can also be done, I think we do not know enough today to say at which layers traffic padding is most useful, and we therefore ought define it where we can.) That said, I think one could later define a new "OnlyKidding" Urgency or Topic (see 9.1) that'd do the job. If that's right, consider this me asking if anyone'd like to do that later? If that's wrong, then consider this me asking: "how can I effectively pad traffic at this layer?" - section 6: (A nit) I think this could be clearer if you better explained how the subscriptions and push messages are correlated. While the current text is fine, since it's clear eventually from the examples, it might be better to not assume so much familiarity with h2. From nobody Thu Oct 13 06:37:01 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 BD0871294FC; Thu, 13 Oct 2016 06:36:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147636581973.2847.16077617885564526707.idtracker@ietfa.amsl.com> Date: Thu, 13 Oct 2016 06:36:59 -0700 Archived-At: Cc: draft-ietf-webpush-protocol@ietf.org, shida@ntt-at.com, dromasca@gmail.com, webpush-chairs@ietf.org, webpush@ietf.org Subject: [Webpush] Benoit Claise's No Objection on draft-ietf-webpush-protocol-11: (with COMMENT) 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, 13 Oct 2016 13:37:00 -0000 Benoit Claise has entered the following ballot position for draft-ietf-webpush-protocol-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-webpush-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Here is Dan Romascanu's OPS DIR review: This document describes protocol for the delivery of real-time events to user agents. It uses HTTP/2 server push. It is assumed, but never explicitly stated that at least part of the operational and manageability considerations of HTTP/2 apply. As this document describes a new protocol, the RFC 5707 review applies. Here is my review, using the template described in Annex A of RFC 5706: In what follows my comments are marked DR. Regards, Dan A.1. Operational Considerations 1. Has deployment been discussed? See Section 2.1. * Does the document include a description of how this protocol or technology is going to be deployed and managed? * Is the proposed specification deployable? If not, how could it be improved? * Does the solution scale well from the operational and management perspective? Does the proposed approach have any scaling issues that could affect usability for large-scale operation? * Are there any coexistence issues? DR - Deployment, Scalability, Coexistence are not discussed. 2. Has installation and initial setup been discussed? See Section 2.2. * Is the solution sufficiently configurable? * Are configuration parameters clearly identified? * Are configuration parameters normalized? * Does each configuration parameter have a reasonable default value? * Will configuration be pushed to a device by a configuration manager, or pulled by a device from a configuration server? * How will the devices and managers find and authenticate each other? DR - Installation and initial setup are not discussed. 3. Has the migration path been discussed? See Section 2.3. * Are there any backward compatibility issues? DR - not applicable, as this is a first version 4. Have the Requirements on other protocols and functional components been discussed? See Section 2.4. * What protocol operations are expected to be performed relative to the new protocol or technology, and what protocols and data models are expected to be in place or recommended to ensure for interoperable management? DR - yes, the protocol uses HTTP/2 push mechanisms, this is explained in detail 5. Has the impact on network operation been discussed? See Section 2.5. * Will the new protocol significantly increase traffic load on existing networks? * Will the proposed management for the new protocol significantly increase traffic load on existing networks? * How will the new protocol impact the behavior of other protocols in the network? Will it impact performance (e.g., jitter) of certain types of applications running in the same network? * Does the new protocol need supporting services (e.g., DNS or Authentication, Authorization, and Accounting - AAA) added to an existing network? DR - The introduction mentions optimization of traffic loads as one important goal, but this is not sustained later. Section 6.2 mentions 'operational constraints' with no details or explanation about what it means. Section 7.1 describes management of load, especially in what concerns the high numbers of TCP connections. 6. Have suggestions for verifying correct operation been discussed? See Section 2.6. * How can one test end-to-end connectivity and throughput? * Which metrics are of interest? * Will testing have an impact on the protocol or the network? DR - No. I assume operational procedures for HTTP may apply, but this is not mentioned. 7. Has management interoperability been discussed? See Section 3.1. * Is a standard protocol needed for interoperable management? * Is a standard information or data model needed to make properties comparable across devices from different vendors? DR - No. May be not applicable. 8. Are there fault or threshold conditions that should be reported? See Section 3.3. * Does specific management information have time utility? * Should the information be reported by notifications? Polling? Event-driven polling? * Is notification throttling discussed? * Is there support for saving state that could be used for root cause analysis? DR - No. May be not applicable. 9. Is configuration discussed? See Section 3.4. * Are configuration defaults and default modes of operation considered? * Is there discussion of what information should be preserved across reboots of the device or the management system? Can devices realistically preserve this information through hard reboots where physical configuration might change (e.g., cards might be swapped while a chassis is powered down)? DR - No. A.2. Management Considerations Do you anticipate any manageability issues with the specification? 1. Is management interoperability discussed? See Section 3.1. * Will it use centralized or distributed management? * Will it require remote and/or local management applications? * Are textual or graphical user interfaces required? * Is textual or binary format for management information preferred? 2. Is management information discussed? See Section 3.2. * What is the minimal set of management (configuration, faults, performance monitoring) objects that need to be instrumented in order to manage the new protocol? 3. Is fault management discussed? See Section 3.3. * Is Liveness Detection and Monitoring discussed? * Does the solution have failure modes that are difficult to diagnose or correct? Are faults and alarms reported and logged? 4. Is configuration management discussed? See Section 3.4. * Is protocol state information exposed to the user? How? Are significant state transitions logged? 5. Is accounting management discussed? See Section 3.5. 6. Is performance management discussed? See Section 3.6. * Does the protocol have an impact on network traffic and network devices? Can performance be measured? * Is protocol performance information exposed to the user? 7. Is security management discussed? See Section 3.7. * Does the specification discuss how to manage aspects of security, such as access controls, managing key distribution, etc. DR - No special problems are anticipated, but I would have expected a better documentation on some aspects. I assume that some manageability considerations for HTTP may apply, but this is not mentioned. The protocol uses status codes which can be used for management purposes, but these are not exposed to users. Load implications are discussed in section 7, how to measure load impact is not described, it is probably assumed that HTTP load measurement applies. Securoty and privacy are discussed in a separate section. A.3. Documentation Is an operational considerations and/or manageability section part of the document? DR - Operational considerations are described in Section 7 Does the proposed protocol have a significant operational impact on the Internet? DR - it may have, maybe not on the Internet as a whole, but certainly in networks where this is deployed. Is there proof of implementation and/or operational experience? DR - not in the document, yes in the industry From nobody Thu Oct 13 07:09: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 1638D1298D6; Thu, 13 Oct 2016 07:09:17 -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 kbUUsGDh1tLL; Thu, 13 Oct 2016 07:09:13 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::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 8DDEE1294EB; Thu, 13 Oct 2016 07:09:12 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id 2so79124006vkb.3; Thu, 13 Oct 2016 07:09:12 -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=RkLs+jRM31zok4RKWKviL+8vouW3gMnDbOsrjybfRX0=; b=kBnoWUz/6TSCCBSgpSpo2ebchDPnFoFKiRbP3Abm6VE9PejKMVpRPyhoyABHzcURgY q7PmqnxnyG4lu5PaMjQIzZAkVng901doEE1HXK/Yv7j7LG2dk/lQevORQQFz+PQSUMk6 FjTZeKxoOmg3WNpLWf4x95A4Tw7mii5fxPsf9YcjQSErV2H2lxKO4gdCR7E1rscif3RQ FxtOL6C28PWhjPhHMsJ4J19sn7axFJGEpeAk8Rut83BtqprzkuZsNmdePehYAmH6i23E p6GrDNBp/pGcwHQRNVFKelYChc6dFlvlRn7Erm1O7Ze0A5DWWUfLgXDpiy3CC6dYOZWO Nulg== 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=RkLs+jRM31zok4RKWKviL+8vouW3gMnDbOsrjybfRX0=; b=DCVv+mObqFbPeLoi0bpYLGD5CngP5FVI1R8kUF71Z4qeBWLDwlAgsT/5RsOXQkredO TjG8GyxfRWVJJJT0qgdidgjficUKRaQvOy4P9NsY3hQ7BoJYqGMFURmULgptMFJvZYMn mA/jwS//Ceyaqdrn+4WluWercS50M4eeins+BcjQ996gxCcj3iJN1+ZiJ2TDitCtixTF rFlqM964+5/9ImSFNsQEkWAjPSJakM0zLM4uZ8jAsRNAoGDnbsbCtaJvEW3GWR6rtMYc fT4PmGNqetKSt8Pahs6WQ/1b+1+N6Pn9U6DJQzMKvDvFEcydj7KN2CKEMlmJjY1RGK1l wXHA== X-Gm-Message-State: AA6/9Rm2Ck6hF8/wPnF5itxvc/ykJkXzfWbg0uwvqt6Ykhl4T2bIq1QnAsytkfGbJdnV7nHeyszMSLCXckpsAA== X-Received: by 10.31.215.67 with SMTP id o64mr4552559vkg.92.1476367742126; Thu, 13 Oct 2016 07:09:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.82.68 with HTTP; Thu, 13 Oct 2016 07:09:01 -0700 (PDT) In-Reply-To: References: <147629678445.6285.5038003546245862234.idtracker@ietfa.amsl.com> From: Kathleen Moriarty Date: Thu, 13 Oct 2016 10:09:01 -0400 Message-ID: To: Brian Raymor Content-Type: multipart/alternative; boundary=94eb2c07c972d3d4f4053ebfa619 Archived-At: Cc: "draft-ietf-webpush-protocol@ietf.org" , Shida Schubert , "webpush-chairs@ietf.org" , The IESG , "webpush@ietf.org" Subject: Re: [Webpush] Kathleen Moriarty's No Objection on draft-ietf-webpush-protocol-11: (with COMMENT) 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, 13 Oct 2016 14:09:18 -0000 --94eb2c07c972d3d4f4053ebfa619 Content-Type: text/plain; charset=UTF-8 On Thu, Oct 13, 2016 at 12:04 AM, Brian Raymor wrote: > Done. > > Thank you! > -----Original Message----- > From: kathleen.moriarty.ietf@gmail.com [mailto:kathleen.moriarty. > ietf@gmail.com] > Sent: Wednesday, October 12, 2016 6:52 PM > To: Brian Raymor > Cc: The IESG ; draft-ietf-webpush-protocol@ietf.org; Shida > Schubert ; webpush-chairs@ietf.org; webpush@ietf.org > Subject: Re: Kathleen Moriarty's No Objection on > draft-ietf-webpush-protocol-11: (with COMMENT) > > > > Please excuse typos, sent from handheld device > > > On Oct 12, 2016, at 9:09 PM, Brian Raymor > wrote: > > > > > >> The only thing I might add is a note on the varying levels of security > >> offered by the HTTP authentication methods, which are documented in > their > >> RFCs. Adding just that point to the following (phrased however you'd > >> like) would be helpful: > >> A push service MAY > >> choose to authorize requests based on any HTTP-compatible > >> authorization method available, of which there are numerous options. > > > >> The somewhat recent updates to Basic & Digest do a really great job at > >> saying how awful they are and there are some experimental options that > >> offer some promise now. > > > > Proposed text - https://github.com/webpush-wg/webpush-protocol/pull/139/ > files > > Thanks for the quick update. I would just say 'with varying levels of > security.' The security considerations sections for each of the methods > available for HTTP are included in the RFCs for each. > > Thank you, > Kathleen > > > > > > > -- Best regards, Kathleen --94eb2c07c972d3d4f4053ebfa619 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 13, 2016 at 12:04 AM, Brian Raymor <Brian.Raymor@= microsoft.com> wrote:
Done.=

<= br>
Thank you!
=C2=A0
-----Original Message-----
From: kathleen.moriarty= .ietf@gmail.com [mailto:kathleen.moriarty.ietf@gmail.com]
Sent: Wednesday, October 12, 2016 6:52 PM
To: Brian Raymor <Brian.Ra= ymor@microsoft.com>
Cc: The IESG <iesg@ietf.org>; draft-ietf-webpush-pr= otocol@ietf.org; Shida Schubert <shida@ntt-at.com>; = webpush-chairs@ietf.org; webpush@ie= tf.org
Subject: Re: Kathleen Moriarty's No Objection on draft-ietf-webpush-pro= tocol-11: (with COMMENT)



Please excuse typos, sent from handheld device

> On Oct 12, 2016, at 9:09 PM, Brian Raymor <Brian.Raymor@microsoft.com> wrote:
>
>
>> The only thing I might add is a note on the varying levels of secu= rity
>> offered by the HTTP authentication methods, which are documented i= n their
>> RFCs.=C2=A0 Adding just that point to the following (phrased howev= er you'd
>> like) would be helpful:
>>=C2=A0 =C2=A0 A push service MAY
>>=C2=A0 =C2=A0choose to authorize requests based on any HTTP-compati= ble
>>=C2=A0 =C2=A0authorization method available, of which there are num= erous options.
>
>> The somewhat recent updates to Basic & Digest do a really grea= t job at
>> saying how awful they are and there are some experimental options = that
>> offer some promise now.
>
> Proposed text - https://github.com= /webpush-wg/webpush-protocol/pull/139/files

Thanks for the quick update.=C2=A0 I would just say 'with varying level= s of security.'=C2=A0 The security considerations sections for each of = the methods available for HTTP are included in the RFCs for each.

Thank you,
Kathleen
>
>
>



--
=

Best regards,
Kathleen
--94eb2c07c972d3d4f4053ebfa619-- From nobody Thu Oct 13 18:55: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 2D1F812954F; Thu, 13 Oct 2016 18:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 QyPBEogV9tz8; Thu, 13 Oct 2016 18:54:58 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0138.outbound.protection.outlook.com [104.47.33.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE08D1293E9; Thu, 13 Oct 2016 18:54:57 -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=yqmu2XFWnOQwwMVrBUCP+5UbuVpqaRLickOLb/UJH8s=; b=ms9jhSp+haqmQwHOmKM3yE3t6ijxjIBrHN7ZS8Koi9old0brX/UUxh/jJViLZYuSZTNiG4tUxhnEjT9Z2QptVDvBiBsqlKMOmrwVvHle95dBYgJ7WTPwIPKkS0ZDqv0VX4CVGXfCC8jAvGnVkJddJ9iLd9qenixbrnMs+ZTupAQ= 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.669.12; Fri, 14 Oct 2016 01:54:56 +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.0659.020; Fri, 14 Oct 2016 01:54:55 +0000 From: Brian Raymor To: Stephen Farrell , The IESG Thread-Topic: RE: Stephen Farrell's Discuss on draft-ietf-webpush-protocol-11: (with DISCUSS and COMMENT) Thread-Index: AdIlvWyJLZNmmxx8RgyeO1/5pOE+bg== Date: Fri, 14 Oct 2016 01:54: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: [174.61.159.182] x-ms-office365-filtering-correlation-id: 4d281f4f-1888-4fce-f23c-08d3f3d518d6 x-microsoft-exchange-diagnostics: 1; CY1PR03MB2379; 7:EqShBmDedBt2Nmmmmp/e/XsdCuLQNVODwhwlcg09l3Jdq8YXoY0v5jNBHj+Sqnr5ovUVKlg8CvG44XQTUtpt4huj8yrygJMvyy3H+3Wzavxab32Dad4A6+oyKappioC/LTmjXaX7S06ie3SndhFYfmFgmERxon1kHUhlQ+/u5vHYPryBT9HbEYG9HaZ9TTzqBAa2SuM2WsGzhvUYFfO2moxTSw3mFwLA/bAIsfzrWd/oDsnKztwPfdfhC6mWacxwVqgLu7OUTfcX/unCPweNHU2xW6PWEdPpTGmLxtlNaHscyOrFGsZ4qUcQvOUGSXiaHsZ8+2fGGeEmv5FZiQjJMngsQNkr165pwxY0dQaKieoJUEE/EnBILRKBnDprBr3n x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2379; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(166708455590820)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2379; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2379; x-forefront-prvs: 0095BCF226 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(51914003)(189002)(9686002)(99286002)(8936002)(5002640100001)(54356999)(105586002)(86362001)(106356001)(4326007)(50986999)(81166006)(81156014)(189998001)(5001770100001)(97736004)(86612001)(10400500002)(586003)(5005710100001)(66066001)(7696004)(19625215002)(122556002)(8990500004)(10290500002)(5660300001)(19300405004)(87936001)(3846002)(790700001)(6116002)(102836003)(10090500001)(16236675004)(19580395003)(92566002)(15975445007)(2900100001)(2906002)(33656002)(7846002)(3660700001)(76576001)(3280700002)(7736002)(19617315012)(230783001)(77096005)(101416001)(68736007)(74316002)(8676002)(7906003); 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: multipart/alternative; boundary="_000_CY1PR03MB238089D350CD6A78DB9E80BE83DF0CY1PR03MB2380namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2016 01:54:55.8074 (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: "draft-ietf-webpush-protocol@ietf.org" , "shida@ntt-at.com" , "webpush-chairs@ietf.org" , "webpush@ietf.org" Subject: Re: [Webpush] Stephen Farrell's Discuss on draft-ietf-webpush-protocol-11: (with DISCUSS and COMMENT) 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, 14 Oct 2016 01:55:02 -0000 --_000_CY1PR03MB238089D350CD6A78DB9E80BE83DF0CY1PR03MB2380namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > (1) This might just me being confused (in which case, > sorry) but I'm not quite clear on how with works with the > SOP. Given you (reasonably) recommend a different port > (which is a different origin than 443) are you saying > here that the SOP doesn't apply to the client? (Well, > actually you don't say, so I'm not sure:-) If the SOP > applies, how is the port change handled? If the SOP does > not apply, then what does? (Given that I assume some UAs > at least will not change their handling of the SOP no > matter what we say here.) If SOP =3D=3D "Same Origin Policy", can you explain its relevance in this case? Martin and I reviewed but did not understand the comment. > (2) So-called "capability URLs" (is that a new term here? There's a CAP-URI reference: [CAP-URI] Tennison, J., "Good Practices for Capability URLs", FPWD capability-urls, February 2014, . > seems like it could be the topic for a useful > informational rfc) are clearly weak, but also clearly as > good as we'll get for some things. However, those also > become known over time, (in which case they are toast;-) > so why don't you need to provide a way for a push service > to say "hey, instead of in future you'll need > to use "? If that could be done as an extension > later, then I'd be ok with that in terms of clearing the > discuss, but then I think you'd need to mention it, so > that applications and UAs don't build in an assumption > that these URLs are fixed for all time (while also > needing to be kept "secret" as with other bearer tokens). These URI(s) are not fixed for all time. The expectation is that subscriptions will either be explicitly expired by the push service/user ag= ent as necessary or refreshed. For example: https://tools.ietf.org/html/draft-ietf-webpush-protocol-11#section-7.3 In some cases, it may be necessary to terminate subscriptions so that they can be refreshed. This applies to both push message subscriptions and receipt subscriptions. A push service MAY expire a subscription at any time. If there are outstanding requests to an expired push message subscription resource (Section 6) from a user agent or to an expired receipt subscription resource (Section 6.3) from an application server, this MUST be signaled by returning a 404 (Not Found) status code. To further illustrate, this is how the W3C Push API exposes this feature: https://w3c.github.io/push-api/#the-pushsubscriptionchange-event > (3) Why is it not correct to encourage mutual-auth TLS > for the application to push-service connections? I'm not > arguing to make that mandatory, but it's not that hard in > many cases and is very useful, esp since without some > client auth just knowing the URL will often enable a > sender to send a crap load of updates to possibly many > bandwidth/power-challenged UAs. (This is only a discuss > because of that potential DoS vector.) Martin presented a range of alternatives in an earlier version of vapid: https://tools.ietf.org/html/draft-thomson-webpush-vapid-01#section-2 which resulted in many discussions on the mailing list, such as: https://mailarchive.ietf.org/arch/msg/webpush/oPK2Bk1bsNE8Tb-YLGz4gZAIg7o The current version of vapid is the outcome of working group consensus. > (4) Is it really honest to say that the W3C Push API, > webpush encryption and vapid are only informative > references? The first seems easy to make normative, the > second I think really needs to exist before we ought > recommend this all get out into the wild and I'm not > clear if one could sensibly make a service for this > without the 3rd. Yes that might add some delay to the RFC > being issued, but that might be the right thing to do. > Why is it right to not wait on those two IDs and the w3c > rec? This is mainly a discuss in case the answer is "we > know nobody's gonna do webpush-encryption ever" in which > case I'd like to be convinced that implementing and > deploying based on this draft without reading those > references defines a good standard. I'm not saying that > it does not, I'm saying I'm not yet convinced. WebPush is similar to WebSockets in the sense that there's a related API un= der development at the W3C. I'd note that RFC6455 uses an informative reference to the W3C WSAPI. The expectation is that there will be multiple API surfac= es for WebPush similar to the situation for WebSockets. WebPush includes informative references to vapid and message encryption as examples. In response to comments from Ben Campbell during the review, Mart= in created a pull request which clarifies this: https://github.com/webpush-wg/webpush-protocol/pull/138/files The consensus in the working group was that other implementations/scenarios= outside the browser (such as IoT) would pursue their own approaches to address the = requirements. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- > - Thanks for the MUST use TLS. That's totally necessary > here. (Even if maybe not sufficient:-) >- I just want to check this is correct: I think it'd be > potentially useful to be able to pad the traffic here > with NOOP pushed messages. Applications could absolutely choose to do this if the benefits outweighed the costs. > - section 6: (A nit) I think this could be clearer if you > better explained how the subscriptions and push messages > are correlated. While the current text is fine, since > it's clear eventually from the examples, it might be > better to not assume so much familiarity with h2. The tension is that WebPush is basically an "application" of server push which requires some familiarity with HTTP/2. --_000_CY1PR03MB238089D350CD6A78DB9E80BE83DF0CY1PR03MB2380namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

> (1) This might just me being confused (in wh= ich case,

> sorry) but I'm not quite clear on how with w= orks with the

> SOP.  Given you (reasonably) recommend = a different port

> (which is a different origin than 443) are y= ou saying

> here that the SOP doesn't apply to the clien= t? (Well,

> actually you don't say, so I'm not sure:-) I= f the SOP

> applies, how is the port change handled? If = the SOP does

> not apply, then what does? (Given that I ass= ume some UAs

> at least will not change their handling of t= he SOP no

> matter what we say here.)

 

If SOP =3D=3D “Same Origin Policy”, c= an you explain its relevance

in this case? Martin and I reviewed but did not u= nderstand

the comment.

 

> (2) So-called "capability URLs" (i= s that a new term here?

 

There's a CAP-URI reference:

 

   [CAP-URI]  Tennison, J., "= Good Practices for Capability URLs", FPWD

        &= nbsp;     capability-urls, February 2014,

        &= nbsp;     <http://www.w= 3.org/TR/capability-urls/>.

 

> seems like it could be the topic for a usefu= l

> informational rfc) are clearly weak, but als= o clearly as

> good as we'll get for some things.  How= ever, those also

> become known over time, (in which case they = are toast;-)

> so why don't you need to provide a way for a= push service

> to say "hey, instead of <this-URL>= ; in future you'll need

> to use <that-URL>"? If that could= be done as an extension

> later, then I'd be ok with that in terms of = clearing the

> discuss, but then I think you'd need to ment= ion it, so

> that applications and UAs don't build in an = assumption

> that these URLs are fixed for all time (whil= e also

> needing to be kept "secret" as wit= h other bearer tokens).

 

These URI(s) are not fixed for all time. The expe= ctation is that

subscriptions will either be explicitly expired b= y the push service/user agent

as necessary or refreshed.

 

For example:

 

https://tools.ietf.org/html/draft-ietf-webpush-protocol-11#sec= tion-7.3

 

   In some cases, it may be necessary t= o terminate subscriptions so that

   they can be refreshed.  This ap= plies to both push message

   subscriptions and receipt subscripti= ons.

 

   A push service MAY expire a subscrip= tion at any time.  If there are

   outstanding requests to an expired p= ush message subscription resource

   (Section 6) from a user agent or to = an expired receipt subscription

   resource (Section 6.3) from an appli= cation server, this MUST be

   signaled by returning a 404 (Not Fou= nd) status code.

 

To further illustrate, this is how the W3C Push A= PI exposes this feature:

 

https://w3c.github.io/push-api/#the-push= subscriptionchange-event

 

> (3) Why is it not correct to encourage mutua= l-auth TLS

> for the application to push-service connecti= ons?  I'm not

> arguing to make that mandatory, but it's not= that hard in

> many cases and is very useful, esp since wit= hout some

> client auth just knowing the URL will often = enable a

> sender to send a crap load of updates to pos= sibly many

> bandwidth/power-challenged UAs. (This is onl= y a discuss

> because of that potential DoS vector.)<= /o:p>

 

Martin presented a range of alternatives in an ea= rlier version of vapid:

 

https://tools.ietf.org/html/draft-thomson-w= ebpush-vapid-01#section-2

 

which resulted in many discussions on the mailing= list, such as:

 

https://mailarchive.ietf.org/arch/msg/= webpush/oPK2Bk1bsNE8Tb-YLGz4gZAIg7o

 

The current version of vapid is the outcome of wo= rking group consensus.

 

> (4) Is it really honest to say that the W3C = Push API,

> webpush encryption and vapid are only inform= ative

> references? The first seems easy to make nor= mative, the

> second I think really needs to exist before = we ought

> recommend this all get out into the wild and= I'm not

> clear if one could sensibly make a service f= or this

> without the 3rd. Yes that might add some del= ay to the RFC

> being issued, but that might be the right th= ing to do.

> Why is it right to not wait on those two IDs= and the w3c

> rec? This is mainly a discuss in case the an= swer is "we

> know nobody's gonna do webpush-encryption ev= er" in which

> case I'd like to be convinced that implement= ing and

> deploying based on this draft without readin= g those

> references defines a good standard. I'm not = saying that

> it does not, I'm saying I'm not yet convince= d.

 

WebPush is similar to WebSockets in the sense tha= t there's a related API under

development at the W3C. I'd note that RFC6455 use= s an informative reference

to the W3C WSAPI. The expectation is that there w= ill be multiple API surfaces for

WebPush similar to the situation for WebSockets. =

 

WebPush includes informative references to vapid = and message encryption as

examples. In response to comments from Ben Campbe= ll during the review, Martin

created a pull request which clarifies this:=

 

https://github.com/webpush-wg/webpush-protocol/pul= l/138/files

 

The consensus in the working group was that other= implementations/scenarios outside

the browser (such as IoT) would pursue their own = approaches to address the requirements.

 

-------------------------------------------------= ---------------------

COMMENT:

-------------------------------------------------= ---------------------

 

> - Thanks for the MUST use TLS. That's totall= y necessary

> here. (Even if maybe not sufficient:-)<= /o:p>

 

>- I just want to check this is correct: I thi= nk it'd be

> potentially useful to be able to pad the tra= ffic here

> with NOOP pushed messages.

 

<snip>

 

Applications could absolutely choose to do this i= f the

benefits outweighed the costs.

 

> - section 6: (A nit) I think this could be c= learer if you

> better explained how the subscriptions and p= ush messages

> are correlated. While the current text is fi= ne, since

> it's clear eventually from the examples, it = might be

> better to not assume so much familiarity wit= h h2.

 

The tension is that WebPush is basically an ̶= 0;application” of

server push which requires some familiarity with = HTTP/2.

 

 

--_000_CY1PR03MB238089D350CD6A78DB9E80BE83DF0CY1PR03MB2380namp_-- From nobody Thu Oct 13 20:39: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 A1B66129450; Thu, 13 Oct 2016 20:39:36 -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 R6diAPrH-pyE; Thu, 13 Oct 2016 20:39:35 -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 EFB511293D9; Thu, 13 Oct 2016 20:39:34 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id f128so118873888qkb.1; Thu, 13 Oct 2016 20:39:34 -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=G/OYM5HsAVdN15POs/Fp+s18fsigXB2128sivPV6+50=; b=HUDoUxWTCmDiJZMNGmDgROIJsRC6ph0fSk1CjoSHoCLTW7tHbiPUI3e9on4iQ8Xm9/ WqhnYnU8sbi07uquxJYe0o25FH+me7ybvq/vry5a954oWqvIGXm07sgMf1IpY08prwhs KdqHFHdeBeQpMW0G+O2tF4ofn2lAjyaNoUnaKgM3WvmOTBqSBR1OLxhGTfL1OfLP/JYE Qd/GmZJ6w+pfgYpGdPCdSFWyT+/btp/xlzrlzvxYbrWkM6NrPLY3AAQvGZyZLxFawjkW AhpTxZot4AK+1jEy/3/Hi/3wGpBGIYgWT/CoGTfp600p6FhMrd4fIacOjfq9tDKnzn6i ks3w== 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=G/OYM5HsAVdN15POs/Fp+s18fsigXB2128sivPV6+50=; b=FRV5IoQf4y+x/0wX4oKgzS3XGGFCa1SKuF+8yoorWpKb3w4Qs9gFFcpUFJOmdujosX 4adipX8IV7PJQY8byGJRsA1Azw+5YVnNGrGIUmkEp8nwKHpgSdH4bk5+KidPbjDsHNyu 0T2IVirbv1yplX5AmYaAbSASF1MjFVOFbMGNtvO6Wt5BcQwHV5gzKqR1LK2jLp47hQuf AuHnoJtl0GTpJykuvlT4eX6GkRpgLQcG0EnE0QOkpeEuuUmb4Kq+yLGz7Omz28w0uoRO IaH4pygI4T4egG7SnLFvPH3aYPsP4A9CKGeG+6KbhJcBNzGOnn1jmvovePqmWrdQo5ap JahQ== X-Gm-Message-State: AA6/9Rn/epboeotcTvbhjNRx6dn35nWMR+1+vO+3xMasj3O2e0nv59Up0Z4KbNBUL/LaTf5ySbxF4LaXWGIC5Q== X-Received: by 10.55.74.6 with SMTP id x6mr11102071qka.316.1476416374039; Thu, 13 Oct 2016 20:39:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Thu, 13 Oct 2016 20:39:33 -0700 (PDT) In-Reply-To: <147636581973.2847.16077617885564526707.idtracker@ietfa.amsl.com> References: <147636581973.2847.16077617885564526707.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Fri, 14 Oct 2016 14:39:33 +1100 Message-ID: To: Benoit Claise Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Shida Schubert , The IESG , draft-ietf-webpush-protocol@ietf.org, dromasca@gmail.com, webpush-chairs@ietf.org, "webpush@ietf.org" Subject: Re: [Webpush] Benoit Claise's No Objection on draft-ietf-webpush-protocol-11: (with COMMENT) 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, 14 Oct 2016 03:39:36 -0000 On 14 October 2016 at 00:36, Benoit Claise wrote: > Benoit Claise has entered the following ballot position for > draft-ietf-webpush-protocol-11: No Objection [...] > Here is Dan Romascanu's OPS DIR review: I have confess, I don't see an awful lot of actionable material in this review. I worry that RFC 5706 isn't an entirely appropriate template for a review of this sort of thing. I will concede that the level of consistency across the industry when it comes to managing and operating HTTP servers and services is almost uniformly inconsistent. Dan does observe that the draft doesn't mention that typical HTTP operational practices apply; it was my understanding that this was assumed to be obvious enough to omit. (I'm happy to have a more involved conversation about operational and management concerns with push services, but it's probably something that is better done with a different CC list.) From nobody Fri Oct 14 03:38: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 68803129486; Fri, 14 Oct 2016 03:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.518 X-Spam-Level: X-Spam-Status: No, score=-17.518 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 X7mQRwW5Ht2c; Fri, 14 Oct 2016 03:38:40 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65FE312970E; Fri, 14 Oct 2016 03:38:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1154; q=dns/txt; s=iport; t=1476441519; x=1477651119; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=+dKFPfLdmI5RWKK4Vs96WgmA3Q/X5RVlrpdurOLMWAE=; b=F3xG3Icm+2zxrs9U9HjdtbFvsKII7BycBU9CSRsRQaiWnodUHKICwJ7g turMDKqLOd86ngYu8gkCxRyPOQ+gElmoGsoseaGGorgMibnGS9AR4LWqM DC0QSTXuufznFD0P5rqhIq+gn9u+qaJUmHfL88AufyJTcXXSguTPwMfIY Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CnAQAitQBY/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzwBAQEBAXQqUo00lwWSKYIPggiGIgKCSRQBAgEBAQEBAQFeJ4R?= =?us-ascii?q?iAQEEIxVBEAsYAgImAgJXBg0GAgEBiE62Io0RAQEBAQEBAQEBAQEBAQEBAQEhg?= =?us-ascii?q?QeFNoF9CIJQh0uCWwEEmgaQAIlphgyJKYNQg38eNkQGCIMvgTw8NIg1AQEB?= X-IronPort-AV: E=Sophos;i="5.31,344,1473120000"; d="scan'208";a="649215139" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Oct 2016 10:38:36 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u9EAcZtK031504; Fri, 14 Oct 2016 10:38:36 GMT To: Martin Thomson References: <147636581973.2847.16077617885564526707.idtracker@ietfa.amsl.com> From: Benoit Claise Message-ID: <5cf1e37d-3863-a17b-ccfd-6129fd3ccf05@cisco.com> Date: Fri, 14 Oct 2016 12:38:35 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Shida Schubert , The IESG , draft-ietf-webpush-protocol@ietf.org, dromasca@gmail.com, webpush-chairs@ietf.org, "webpush@ietf.org" Subject: Re: [Webpush] Benoit Claise's No Objection on draft-ietf-webpush-protocol-11: (with COMMENT) 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, 14 Oct 2016 10:38:41 -0000 Martin, Here is the high level message: no show stopper here from my perspective, but from an OPS point of view it could be better documented. Regards, Benoit > On 14 October 2016 at 00:36, Benoit Claise wrote: >> Benoit Claise has entered the following ballot position for >> draft-ietf-webpush-protocol-11: No Objection > [...] >> Here is Dan Romascanu's OPS DIR review: > I have confess, I don't see an awful lot of actionable material in > this review. I worry that RFC 5706 isn't an entirely appropriate > template for a review of this sort of thing. I will concede that the > level of consistency across the industry when it comes to managing and > operating HTTP servers and services is almost uniformly inconsistent. > > Dan does observe that the draft doesn't mention that typical HTTP > operational practices apply; it was my understanding that this was > assumed to be obvious enough to omit. > > (I'm happy to have a more involved conversation about operational and > management concerns with push services, but it's probably something > that is better done with a different CC list.) > . > From nobody Fri Oct 14 08:03:16 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 A542A129840; Fri, 14 Oct 2016 08:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.297 X-Spam-Level: X-Spam-Status: No, score=-7.297 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_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 jCqR3UnDXuvh; Fri, 14 Oct 2016 08:03:08 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7DA2129833; Fri, 14 Oct 2016 08:03:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DD640BE2E; Fri, 14 Oct 2016 16:02:57 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkIXB662FoDn; Fri, 14 Oct 2016 16:02:57 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 52F5EBE2C; Fri, 14 Oct 2016 16:02:57 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1476457377; bh=5j4aIKPtXrZbj6nillXr8Iy0VRCM8lgLZ7bfJXTXQH4=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=y6uIrbFHZBz1El0x1kib5YU9/Leg1gGhNetiw9uFz4am/qG6R862eZ9sGtbjkGF+/ 8iclOgzErLbcgA99aiD0wNVv+5DYHZvrVBUDxazh5DXwR1FA89I5rYevlverGYPvue /NlYlyL/r6Q9s3r0fedqxQ1VB4xKhk/rQ3SVZy84= To: Brian Raymor , The IESG References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5816348f-015a-beca-a5e6-3883fff02aab@cs.tcd.ie> Date: Fri, 14 Oct 2016 16:02:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050001070305000502050306" Archived-At: Cc: "draft-ietf-webpush-protocol@ietf.org" , Shida Schubert , "webpush-chairs@ietf.org" , "webpush@ietf.org" Subject: Re: [Webpush] Stephen Farrell's Discuss on draft-ietf-webpush-protocol-11: (with DISCUSS and COMMENT) 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, 14 Oct 2016 15:03:14 -0000 This is a cryptographically signed message in MIME format. --------------ms050001070305000502050306 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Brian, Thanks for that. I think only the first point really needs further discussion so I'll clear the other points in my ballot. On 14/10/16 02:54, Brian Raymor wrote: >=20 >=20 >> (1) This might just me being confused (in which case, >=20 >> sorry) but I'm not quite clear on how with works with the >=20 >> SOP. Given you (reasonably) recommend a different port >=20 >> (which is a different origin than 443) are you saying >=20 >> here that the SOP doesn't apply to the client? (Well, >=20 >> actually you don't say, so I'm not sure:-) If the SOP >=20 >> applies, how is the port change handled? If the SOP does >=20 >> not apply, then what does? (Given that I assume some UAs >=20 >> at least will not change their handling of the SOP no >=20 >> matter what we say here.) >=20 >=20 >=20 > If SOP =3D=3D "Same Origin Policy",=20 Yep. > can you explain its relevance >=20 > in this case? Martin and I reviewed but did not understand >=20 > the comment. So what's not clear to me is how webpush works with the SOP and whether there's anything more that needs to be said about that in the document. For example, you sensibly recommend running the push service on port 1001 but none of the examples mention that port in the Host or :authority values shown. This may all be clear to someone who's very familiar with alt-svc though, (but it wasn't clear to me:-), which might be fine, but I'm not sure. As an example, is the application that is pushing the messages required to know that the push service is or is not using port 1001? >=20 >=20 >=20 >> (2) So-called "capability URLs" (is that a new term here? >=20 >=20 >=20 > There's a CAP-URI reference: >=20 >=20 >=20 > [CAP-URI] Tennison, J., "Good Practices for Capability URLs", FPWD >=20 > capability-urls, February 2014, >=20 > . >=20 Ah, thanks I missed that. >=20 >=20 >> seems like it could be the topic for a useful >=20 >> informational rfc) are clearly weak, but also clearly as >=20 >> good as we'll get for some things. However, those also >=20 >> become known over time, (in which case they are toast;-) >=20 >> so why don't you need to provide a way for a push service >=20 >> to say "hey, instead of in future you'll need >=20 >> to use "? If that could be done as an extension >=20 >> later, then I'd be ok with that in terms of clearing the >=20 >> discuss, but then I think you'd need to mention it, so >=20 >> that applications and UAs don't build in an assumption >=20 >> that these URLs are fixed for all time (while also >=20 >> needing to be kept "secret" as with other bearer tokens). >=20 >=20 >=20 > These URI(s) are not fixed for all time. The expectation is that >=20 > subscriptions will either be explicitly expired by the push service/use= r agent >=20 > as necessary or refreshed. >=20 >=20 >=20 > For example: >=20 >=20 >=20 > https://tools.ietf.org/html/draft-ietf-webpush-protocol-11#section-7.3 >=20 >=20 >=20 > In some cases, it may be necessary to terminate subscriptions so tha= t >=20 > they can be refreshed. This applies to both push message >=20 > subscriptions and receipt subscriptions. >=20 >=20 >=20 > A push service MAY expire a subscription at any time. If there are >=20 > outstanding requests to an expired push message subscription resourc= e >=20 > (Section 6) from a user agent or to an expired receipt subscription >=20 > resource (Section 6.3) from an application server, this MUST be >=20 > signaled by returning a 404 (Not Found) status code. >=20 >=20 >=20 > To further illustrate, this is how the W3C Push API exposes this featur= e: >=20 >=20 > https://w3c.github.io/push-api/#the-pushsubscriptionchange-event Ah good. Does that also specify a way for the application to change the URL to which it pushes? It's the latter that I think is the bigger potential danger. (In any case, I'll clear this point.) >=20 >=20 >> (3) Why is it not correct to encourage mutual-auth TLS >=20 >> for the application to push-service connections? I'm not >=20 >> arguing to make that mandatory, but it's not that hard in >=20 >> many cases and is very useful, esp since without some >=20 >> client auth just knowing the URL will often enable a >=20 >> sender to send a crap load of updates to possibly many >=20 >> bandwidth/power-challenged UAs. (This is only a discuss >=20 >> because of that potential DoS vector.) >=20 >=20 >=20 > Martin presented a range of alternatives in an earlier version of vapid= : >=20 >=20 >=20 > https://tools.ietf.org/html/draft-thomson-webpush-vapid-01#section-2 >=20 >=20 >=20 > which resulted in many discussions on the mailing list, such as: >=20 >=20 >=20 > https://mailarchive.ietf.org/arch/msg/webpush/oPK2Bk1bsNE8Tb-YLGz4gZAIg= 7o >=20 >=20 >=20 > The current version of vapid is the outcome of working group consensus.= >=20 Ah, ok I didn't know that the vapid thing had a signature based HTTP auth scheme. That's good enough. (I'll be interested in the replay charactistics of vapid auth when that gets to the IESG though, seems a bit ickky to me if I can cut'n'paste such signatures for 24 hours worth of fun. But that's a discussion for another day.) It's also pretty sad that "cloudy" services can't depend on visibility of TLS client auth information. But I guess that's not something that this document can fix. >=20 >> (4) Is it really honest to say that the W3C Push API, >=20 >> webpush encryption and vapid are only informative >=20 >> references? The first seems easy to make normative, the >=20 >> second I think really needs to exist before we ought >=20 >> recommend this all get out into the wild and I'm not >=20 >> clear if one could sensibly make a service for this >=20 >> without the 3rd. Yes that might add some delay to the RFC >=20 >> being issued, but that might be the right thing to do. >=20 >> Why is it right to not wait on those two IDs and the w3c >=20 >> rec? This is mainly a discuss in case the answer is "we >=20 >> know nobody's gonna do webpush-encryption ever" in which >=20 >> case I'd like to be convinced that implementing and >=20 >> deploying based on this draft without reading those >=20 >> references defines a good standard. I'm not saying that >=20 >> it does not, I'm saying I'm not yet convinced. >=20 >=20 >=20 > WebPush is similar to WebSockets in the sense that there's a related AP= I under >=20 > development at the W3C. I'd note that RFC6455 uses an informative refer= ence >=20 > to the W3C WSAPI. The expectation is that there will be multiple API su= rfaces for >=20 > WebPush similar to the situation for WebSockets. >=20 >=20 >=20 > WebPush includes informative references to vapid and message encryption= as >=20 > examples. In response to comments from Ben Campbell during the review, = Martin >=20 > created a pull request which clarifies this: >=20 >=20 >=20 > https://github.com/webpush-wg/webpush-protocol/pull/138/files >=20 >=20 >=20 > The consensus in the working group was that other implementations/scena= rios outside >=20 > the browser (such as IoT) would pursue their own approaches to address = the requirements. >=20 >=20 Ok. Given that I'm assured that the encryption stuff is really happening, I'm fine with this. >=20 > ---------------------------------------------------------------------- >=20 > COMMENT: >=20 > ---------------------------------------------------------------------- >=20 >=20 >=20 >> - Thanks for the MUST use TLS. That's totally necessary >=20 >> here. (Even if maybe not sufficient:-) >=20 >=20 >=20 >> - I just want to check this is correct: I think it'd be >=20 >> potentially useful to be able to pad the traffic here >=20 >> with NOOP pushed messages. >=20 >=20 >=20 > >=20 >=20 >=20 > Applications could absolutely choose to do this if the >=20 > benefits outweighed the costs. >=20 >=20 >=20 >> - section 6: (A nit) I think this could be clearer if you >=20 >> better explained how the subscriptions and push messages >=20 >> are correlated. While the current text is fine, since >=20 >> it's clear eventually from the examples, it might be >=20 >> better to not assume so much familiarity with h2. >=20 >=20 >=20 > The tension is that WebPush is basically an "application" of >=20 > server push which requires some familiarity with HTTP/2. Sure. And this is just a non-blocking comment, but a bit more text on that would have helped this reader. But if you've not also heard the same from others, you should ignore me:-) Cheers, S. >=20 >=20 >=20 >=20 --------------ms050001070305000502050306 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEwMTQx NTAyNTdaMC8GCSqGSIb3DQEJBDEiBCB3E+3qJnw+OMVTFF/gT7vkeOmzU88HnaAjLAA0d7qh xjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCdBu18b8LuT9/YlALG54KgV9vPPREz0koKejoXMh572UoA6seB3vvO 1dBNS53wyBkHoqNSlMMwP59+p5Pvz0irGF3JUeP27AF+Zuj3zUemNNIVinQEwqNKdtAflfUM XPsjAkMiQE4laX0oPnGOxCpzxH3EEZJ4DEhaCxb/jY2PCTDQt4epm+8G9WoOnP5wbftTpQaJ 4UEttTVQbg0lvKpBwREjDMwjDEg2t3ezHuZZbZ9xL2bXQgfo0UkhDquJD7vL57itb9s00Ofp /BbpnPcNPI/lyNHd1JP3Mb/Dyc3YRuZTn/oYJY5dFjx+TrKdvP+gctl33kGA4YaQ0UnT9jCq AAAAAAAA --------------ms050001070305000502050306-- From nobody Fri Oct 14 08:10: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 E067A129842; Fri, 14 Oct 2016 08:10:24 -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 aCovZKtk8w5G; Fri, 14 Oct 2016 08:10:18 -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 61985129523; Fri, 14 Oct 2016 08:10:18 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id o68so199483912qkf.3; Fri, 14 Oct 2016 08:10:18 -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=HbQVWwNJafmuYcMJF/Q/xeiQJPOjib0PZZpq8AdgUlo=; b=cILxl9QEX8z9bl4AsT/tjrWZQL5MGyJ7BWf7QFtIQyvcX4P6MJs3m9B7HceJG/U18G Z+GtiKnZuCjEvqugZBTF0OMgc1YLpontq7Lgp6YY3pclfSjEN4+UuRLmKANRkTbZYcSv OP0uN5nS5wLBymt0lT3rzN/3GnGP998vJVdF33bPLGvhsibl6wmYUZXae4xSfIRAKZmR vekQe+8MIcGLB2Q3tcM3NyXgqBW1lR9t82U7SDmJia9/18aoJlU//tB4eC5F0EYwl+WH YskG4iC4VTYQ/JopXgRmEA3Qsvd3TUE4b5FnGYrHOe3eV48wajKgJhBg8yvGnrhyWD8f OSOA== 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=HbQVWwNJafmuYcMJF/Q/xeiQJPOjib0PZZpq8AdgUlo=; b=aVW8Z+1MzTB8XSPMLbW8oxPsKxVKbh471jJ18crn17I97VaMgTwtMByXIs+LlGpAtq 0aSiYWcAUcf2Nhf7PjKGlXycwyV61h02B7J4fRkazgufSyBakY4q6Yz8MflH0UOAJg+0 jJUBuCCfGoXjEI60Ilg3JZ8P9faOahNnsGCN5WbaNW5yOgGKI8g7nSlkUydRVQBlickt UL4K8Ju/3dzILjdGp1ARf+6YOMV2WYd9XAsYyzPuwIrsi6Fb1apQ1JBQNyczaXmc2Lle jLwiLvdGeXePeaK8hLGVq6q+/Qjsg4oxSicmG1c8hL+wRZE64NBHMnNCYJKmoGEnoTpp ujug== X-Gm-Message-State: AA6/9Rl/C1vpBoDfI0nYxHIJ4mrCSY+ZLdjj9bdKl0xWV/iUrZ2JPJwdbMDZKkBcStBZ3I/pDdppQ21ub+wnXA== X-Received: by 10.55.167.149 with SMTP id q143mr11433076qke.97.1476457817315; Fri, 14 Oct 2016 08:10:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.21.228 with HTTP; Fri, 14 Oct 2016 08:10:16 -0700 (PDT) In-Reply-To: <5cf1e37d-3863-a17b-ccfd-6129fd3ccf05@cisco.com> References: <147636581973.2847.16077617885564526707.idtracker@ietfa.amsl.com> <5cf1e37d-3863-a17b-ccfd-6129fd3ccf05@cisco.com> From: Dan Romascanu Date: Fri, 14 Oct 2016 18:10:16 +0300 Message-ID: To: Benoit Claise Content-Type: multipart/alternative; boundary=001a114fb3d8ba1f74053ed49f4e Archived-At: Cc: webpush-chairs@ietf.org, Shida Schubert , The IESG , draft-ietf-webpush-protocol@ietf.org, Martin Thomson , "webpush@ietf.org" Subject: Re: [Webpush] Benoit Claise's No Objection on draft-ietf-webpush-protocol-11: (with COMMENT) 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, 14 Oct 2016 15:10:25 -0000 --001a114fb3d8ba1f74053ed49f4e Content-Type: text/plain; charset=UTF-8 Hi, I agree with Benoit that the document in its current phase does not seem to include any show stopper. As the OPS-DIR reviews are written to help the OPS ADs, its up to them if the lack of some of the operational and manageability considerations is critical for such documents. I do with however to express my reservations about Martin's statement that the would not be 'an awful lot of actionable material in this review'. The review clearly points to the lack of considerations related to a number of operational and manageability aspects like scalability, coexistence, initial setup, fault management, etc. One can decide and be explicit or not about dealing with these, but how to fix the lack of documentation about these aspects is actionable in my opinion. I also do not see why RFC 5706 would not apply for such a document that describes a standards track IETF protocol extension. OPS-DIR reviewers are referred to RFC 5706 for such documents. Also, I disagree with the statement that '[HTTP operational practions] ... this was assumed to be obvious enough to omit.' The Security Consideration section starts with the sentence: > This protocol MUST use HTTP over TLS [RFC2818] following the recommendations in [RFC7525]. Security considerations are based on previous documents and this is explicitly stated. There is no reason not to state explicitly the same for the manageability considerations Regards, Dan On Fri, Oct 14, 2016 at 1:38 PM, Benoit Claise wrote: > Martin, > > Here is the high level message: no show stopper here from my perspective, > but from an OPS point of view it could be better documented. > > Regards, Benoit > >> On 14 October 2016 at 00:36, Benoit Claise wrote: >> >>> Benoit Claise has entered the following ballot position for >>> draft-ietf-webpush-protocol-11: No Objection >>> >> [...] >> >>> Here is Dan Romascanu's OPS DIR review: >>> >> I have confess, I don't see an awful lot of actionable material in >> this review. I worry that RFC 5706 isn't an entirely appropriate >> template for a review of this sort of thing. I will concede that the >> level of consistency across the industry when it comes to managing and >> operating HTTP servers and services is almost uniformly inconsistent. >> >> Dan does observe that the draft doesn't mention that typical HTTP >> operational practices apply; it was my understanding that this was >> assumed to be obvious enough to omit. >> >> (I'm happy to have a more involved conversation about operational and >> management concerns with push services, but it's probably something >> that is better done with a different CC list.) >> . >> >> > --001a114fb3d8ba1f74053ed49f4e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I agree with Benoit = that the document in its current phase does not seem to include any show st= opper. As the OPS-DIR reviews are written to help the OPS ADs, its up to th= em if the lack of some of the operational and manageability considerations = is critical for such documents.

I do with however to express = my reservations about Martin's statement that the would not be 'an = awful lot of actionable material in
this review'. The review clearly points to the lack of considerations r= elated to a number of operational and manageability aspects like scalabilit= y, coexistence, initial setup, fault management, etc. One can decide and be= explicit or not about dealing with these, but how to fix the lack of docum= entation about these aspects is actionable in my opinion.

I a= lso do not see why RFC 5706 would not apply for such a document that descri= bes a standards track IETF protocol extension. OPS-DIR reviewers are referr= ed to RFC 5706 for such documents.

Also, I disagree with the = statement that '[HTTP operational practions] ... this was
assumed to be obvious enough to omit.' The Security Consideration secti= on starts with the sentence:

> This protocol MUST use HTTP over = TLS [RFC2818] following the 
   recommendations in [RFC7525].

Security considerat=
ions are based on previous documents and this is explicitly stated. There i=
s no reason not to state explicitly the same for the manageability consider=
ations 
Regards,

Dan


On Fri, Oct= 14, 2016 at 1:38 PM, Benoit Claise <bclaise@cisco.com> wrot= e:
Martin,

Here is the high level message: no show stopper here from my perspective, b= ut from an OPS point of view it could be better documented.

Regards, Benoit
On 14 October 2016 at 00:36, Benoit Claise <bclaise@cisco.com> wrote:
Benoit Claise has entered the following ballot position for
draft-ietf-webpush-protocol-11: No Objection
[...]
Here is Dan Romascanu's OPS DIR review:
I have confess, I don't see an awful lot of actionable material in
this review.=C2=A0 I worry that RFC 5706 isn't an entirely appropriate<= br> template for a review of this sort of thing.=C2=A0 I will concede that the<= br> level of consistency across the industry when it comes to managing and
operating HTTP servers and services is almost uniformly inconsistent.

Dan does observe that the draft doesn't mention that typical HTTP
operational practices apply; it was my understanding that this was
assumed to be obvious enough to omit.

(I'm happy to have a more involved conversation about operational and management concerns with push services, but it's probably something
that is better done with a different CC list.)
.



--001a114fb3d8ba1f74053ed49f4e-- From nobody Fri Oct 14 13:00: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 96164129499; Fri, 14 Oct 2016 13:00:43 -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 D_PCe32rdYyV; Fri, 14 Oct 2016 13:00:41 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0123.outbound.protection.outlook.com [104.47.32.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ACE41293DF; Fri, 14 Oct 2016 13:00:41 -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=wbAzB8BK1E6DoYIL8wBHI72mc0HdAPU0q5rMxWUI+cY=; b=oEbiUqVPI5TbzouI11DhXoRPrOyrl/1Qj7GtwWcPTifG1VTx9lUqh8Evdx0UmdLb7QLFKQlH2+YOPt6H/Jm0KhR5MMwTa3Ng10pmYHRVy5pTzaaltiALAC/3qoNGttD+82x1LMUJHUuTlQndRPX6EabJ8CDb1tGSBhRQ2x5Jey0= 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_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.12; Fri, 14 Oct 2016 20:00:40 +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.0659.020; Fri, 14 Oct 2016 20:00:40 +0000 From: Brian Raymor To: Stephen Farrell , The IESG Thread-Topic: Stephen Farrell's Discuss on draft-ietf-webpush-protocol-11: (with DISCUSS and COMMENT) Thread-Index: AQHSJiwPJMwjYoplfkyn6wgWsrTwWqCoSZig Date: Fri, 14 Oct 2016 20:00:39 +0000 Message-ID: References: <5816348f-015a-beca-a5e6-3883fff02aab@cs.tcd.ie> In-Reply-To: <5816348f-015a-beca-a5e6-3883fff02aab@cs.tcd.ie> 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: 24d9cfc1-5b82-4b3a-c85b-08d3f46cc5c6 x-microsoft-exchange-diagnostics: 1; CY1PR03MB2377; 7:dfflr3GMiJdeDQZEoBf3rrweNDuEWtd2fqFsmYUjcped7Pc0cgeusuv8NXbsnZRifeSm0yAZq8FXgJGzwCzla4JZQBPkB5tRvceLcukRjYq1y036NYPgWGSni09C+G7PThncwPnMMrkILBW4yO9QUw2itP1e0k3pjUl/k6H8fbB1yZUP8vTjHAtxt4ZQt+JLDE/UutyMCaekYKActCUslO18hzNfHnvtxwatlIyBoj/xfuFBqGCaWqxrDsDUkfflHin0PWmrgtJmJZ/k7zkOj01AAE3ccvsAXeBFIdmEEHpOTHg/ZBbeHbnDmLZspOwQ9fvZuIanSGAK7FkJVBRl9mW38kg56Wr2Xx1xdPY3I+RILiuDgLKsddynafvEvJhR x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2377; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(35073007944872)(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2377; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2377; x-forefront-prvs: 0095BCF226 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(54356999)(74316002)(3660700001)(86362001)(2900100001)(2950100002)(11100500001)(101416001)(77096005)(97736004)(189998001)(5001770100001)(50986999)(76176999)(106116001)(106356001)(68736007)(76576001)(105586002)(10090500001)(10400500002)(10290500002)(99286002)(5005710100001)(8990500004)(5660300001)(15975445007)(33656002)(7696004)(66066001)(122556002)(9686002)(5002640100001)(86612001)(3280700002)(230783001)(305945005)(102836003)(92566002)(19580395003)(8936002)(2906002)(6116002)(3846002)(81166006)(7736002)(586003)(4326007)(81156014)(7846002)(8676002)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2377; 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2016 20:00:39.8483 (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: Cc: "draft-ietf-webpush-protocol@ietf.org" , Shida Schubert , "webpush-chairs@ietf.org" , "webpush@ietf.org" Subject: Re: [Webpush] Stephen Farrell's Discuss on draft-ietf-webpush-protocol-11: (with DISCUSS and COMMENT) 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, 14 Oct 2016 20:00:43 -0000 DQpIaSBTdGVwaGVuLA0KDQo+IFNvIHdoYXQncyBub3QgY2xlYXIgdG8gbWUgaXMgaG93IHdlYnB1 c2ggd29ya3Mgd2l0aCB0aGUgU09QDQo+IGFuZCB3aGV0aGVyIHRoZXJlJ3MgYW55dGhpbmcgbW9y ZSB0aGF0IG5lZWRzIHRvIGJlIHNhaWQgYWJvdXQNCj4gdGhhdCBpbiB0aGUgZG9jdW1lbnQuIEZv ciBleGFtcGxlLCB5b3Ugc2Vuc2libHkgcmVjb21tZW5kDQo+IHJ1bm5pbmcgdGhlIHB1c2ggc2Vy dmljZSBvbiBwb3J0IDEwMDEgYnV0IG5vbmUgb2YgdGhlIGV4YW1wbGVzDQo+IG1lbnRpb24gdGhh dCBwb3J0IGluIHRoZSBIb3N0IG9yIDphdXRob3JpdHkgdmFsdWVzIHNob3duLg0KPiBUaGlzIG1h eSBhbGwgYmUgY2xlYXIgdG8gc29tZW9uZSB3aG8ncyB2ZXJ5IGZhbWlsaWFyIHdpdGgNCj4gYWx0 LXN2YyB0aG91Z2gsIChidXQgaXQgd2Fzbid0IGNsZWFyIHRvIG1lOi0pLCB3aGljaCBtaWdodA0K PiBiZSBmaW5lLCBidXQgSSdtIG5vdCBzdXJlLiBBcyBhbiBleGFtcGxlLCBpcyB0aGUgYXBwbGlj YXRpb24NCj4gdGhhdCBpcyBwdXNoaW5nIHRoZSBtZXNzYWdlcyByZXF1aXJlZCB0byBrbm93IHRo YXQgdGhlDQo+IHB1c2ggc2VydmljZSBpcyBvciBpcyBub3QgdXNpbmcgcG9ydCAxMDAxPw0KDQpB bHRlcm5hdGl2ZSBzZXJ2aWNlcyBoYXZlIG5vdCBiZWVuIGEgc291cmNlIG9mIGNvbmZ1c2lvbiBp biB0aGUgd29ya2luZyBncm91cC4NClRoZXJlIGhhdmUgYmVlbiBubyByZWxhdGVkIHF1ZXN0aW9u cyBvbiB0aGUgbWFpbGluZyBsaXN0IHRoYXQgSSBjYW4gcmVjYWxsIG9yIGZpbmQuDQoNClRoZSBT T1AgcXVlc3Rpb24gZmVlbHMgbW9yZSByZWxldmFudCB0byBSRkM3ODM4IHRoYW4gV2ViUHVzaCAo aGVuY2Ugb3VyIGNvbmZ1c2lvbg0KeWVzdGVyZGF5KS4NCg0KUGVyaGFwcyBleGNlcnB0aW5nIGEg ZmV3IHJlZmVyZW5jZXMgd2lsbCBoZWxwIGNsYXJpZnkgdGhhdCBwZXJjZXB0aW9uOg0KDQogICBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzgzOA0KDQogICBBbiBhbHRlcm5hdGl2ZSBz ZXJ2aWNlIGNhbiBiZSB1c2VkIHRvIGludGVyYWN0IHdpdGggdGhlIHJlc291cmNlcyBvbg0KICAg YW4gb3JpZ2luIHNlcnZlciBhdCBhIHNlcGFyYXRlIGxvY2F0aW9uIG9uIHRoZSBuZXR3b3JrLCBw b3NzaWJseQ0KICAgdXNpbmcgYSBkaWZmZXJlbnQgcHJvdG9jb2wgY29uZmlndXJhdGlvbi4gIEFs dGVybmF0aXZlIHNlcnZpY2VzIGFyZQ0KICAgY29uc2lkZXJlZCBhdXRob3JpdGF0aXZlIGZvciBh biBvcmlnaW4ncyByZXNvdXJjZXMsIGluIHRoZSBzZW5zZSBvZg0KICAgW1JGQzcyMzBdLCBTZWN0 aW9uIDkuMSAuLi4NCg0KICAgQWx0ZXJuYXRpdmUgc2VydmljZXMgZG8gbm90IHJlcGxhY2Ugb3Ig Y2hhbmdlIHRoZSBvcmlnaW4gZm9yIGFueQ0KICAgZ2l2ZW4gcmVzb3VyY2U7IGluIGdlbmVyYWws IHRoZXkgYXJlIG5vdCB2aXNpYmxlIHRvIHRoZSBzb2Z0d2FyZQ0KICAgImFib3ZlIiB0aGUgYWNj ZXNzIG1lY2hhbmlzbS4gIFRoZSBhbHRlcm5hdGl2ZSBzZXJ2aWNlIGlzIGVzc2VudGlhbGx5DQog ICBhbHRlcm5hdGl2ZSByb3V0aW5nIGluZm9ybWF0aW9uIHRoYXQgY2FuIGFsc28gYmUgdXNlZCB0 byByZWFjaCB0aGUNCiAgIG9yaWdpbiBpbiB0aGUgc2FtZSB3YXkgdGhhdCBETlMgQ05BTUUgb3Ig U1JWIHJlY29yZHMgZGVmaW5lIHJvdXRpbmcNCiAgIGluZm9ybWF0aW9uIGF0IHRoZSBuYW1lIHJl c29sdXRpb24gbGV2ZWwgLi4uDQoNCiAgIFRoaXMgbWVhbnMgdGhhdCBjbGllbnRzIHVzaW5nIGFu IGFsdGVybmF0aXZlIHNlcnZpY2UgY2FuIGNoYW5nZSB0aGUNCiAgIGhvc3QsIHBvcnQsIGFuZCBw cm90b2NvbCB0aGF0IHRoZXkgYXJlIHVzaW5nIHRvIGZldGNoIHJlc291cmNlcywgYnV0DQogICB0 aGVzZSBjaGFuZ2VzIE1VU1QgTk9UIGJlIHByb3BhZ2F0ZWQgdG8gdGhlIGFwcGxpY2F0aW9uIHRo YXQgaXMgdXNpbmcNCiAgIEhUVFA7IGZyb20gdGhhdCBzdGFuZHBvaW50LCB0aGUgVVJJIGJlaW5n IGFjY2Vzc2VkIGFuZCBhbGwNCiAgIGluZm9ybWF0aW9uIGRlcml2ZWQgZnJvbSBpdCAoc2NoZW1l LCBob3N0LCBhbmQgcG9ydCkgYXJlIHRoZSBzYW1lIGFzDQogICBiZWZvcmUuDQoNCiAgIEltcG9y dGFudGx5LCB0aGlzIGluY2x1ZGVzIGl0cyBzZWN1cml0eSBjb250ZXh0OyBpbiBwYXJ0aWN1bGFy LCB3aGVuDQogICBUTFMgW1JGQzUyNDZdIGlzIHVzZWQgdG8gYXV0aGVudGljYXRlLCB0aGUgYWx0 ZXJuYXRpdmUgc2VydmljZSB3aWxsDQogICBuZWVkIHRvIHByZXNlbnQgYSBjZXJ0aWZpY2F0ZSBm b3IgdGhlIG9yaWdpbidzIGhvc3QgbmFtZSwgbm90IHRoYXQgb2YNCiAgIHRoZSBhbHRlcm5hdGl2 ZS4gIExpa2V3aXNlLCB0aGUgSG9zdCBoZWFkZXIgZmllbGQgKFtSRkM3MjMwXSwNCiAgIFNlY3Rp b24gNS40KSBpcyBzdGlsbCBkZXJpdmVkIGZyb20gdGhlIG9yaWdpbiwgbm90IHRoZSBhbHRlcm5h dGl2ZQ0KICAgc2VydmljZSAoanVzdCBhcyBpdCB3b3VsZCBpZiBhIENOQU1FIHdlcmUgYmVpbmcg dXNlZCkuDQoNCkFsc28gc2VlIG1ub3QncyBibG9nIGZvciBhIHF1aWNrIGludHJvZHVjdGlvbjoN Cg0KaHR0cHM6Ly93d3cubW5vdC5uZXQvYmxvZy8yMDE2LzAzLzA5L2FsdC1zdmMNCg0KICAgIFNv LCB0byB1c2UgYW4gYWx0ZXJuYXRpdmUsIGEgY2xpZW50IG5lZWRzIHRvIGhhdmUgd2hhdCB3ZSBj YWxsIOKAnHJlYXNvbmFibGUgYXNzdXJhbmNlc+KAnQ0KICAgIHRoYXQgaXQgaGFzIHRoZSBhdXRo b3JpdHkgdG8gZG8gc28uIEluIHRoaXMgc3BlY2lmaWNhdGlvbiwgd2UgZGVmaW5lIG9uZSB3YXkg dG8gZG8gdGhhdDsNCiAgICB0aGUgYWx0ZXJuYXRpdmUgbmVlZHMgdG8gcHJlc2VudCBhIFRMUyBj ZXJ0aWZpY2F0ZSB0aGF04oCZcyB2YWxpZCBmb3IgdGhlIG9yaWdpbg0KICAgIOKAkyBub3QgdGhl IGFsdGVybmF0aXZlISDigJMgaG9zdG5hbWUuDQoNCkhvcGUgdGhhdCBoZWxwcywNCg0KLi4uQnJp YW4NCg0KDQo= From nobody Sun Oct 16 19:41: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 CA83F1293F9 for ; Sun, 16 Oct 2016 19:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 VLexN_-5IMJU for ; Sun, 16 Oct 2016 19:41:50 -0700 (PDT) Received: from gateway20.websitewelcome.com (gateway20.websitewelcome.com [192.185.45.27]) (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 545A51293F4 for ; Sun, 16 Oct 2016 19:41:50 -0700 (PDT) Received: from cm2.websitewelcome.com (cm2.websitewelcome.com [192.185.178.13]) by gateway20.websitewelcome.com (Postfix) with ESMTP id BD28C99C40A9A for ; Sun, 16 Oct 2016 21:41:49 -0500 (CDT) Received: from gator4135.hostgator.com ([192.185.4.147]) by cm2.websitewelcome.com with id wSho1t00J3AKFgo01Shp4s; Sun, 16 Oct 2016 21:41:49 -0500 Received: from c-98-248-153-86.hsd1.ca.comcast.net ([98.248.153.86]:47809 helo=[10.0.96.3]) by gator4135.hostgator.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.87) (envelope-from ) id 1bvxs3-0004DW-7m; Sun, 16 Oct 2016 21:41:47 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Shida Schubert In-Reply-To: <0F8DEB44-41DC-40CA-84CC-4C023E3CBB00@ntt-at.com> Date: Sun, 16 Oct 2016 19:41:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0F8DEB44-41DC-40CA-84CC-4C023E3CBB00@ntt-at.com> To: Shida Schubert 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: 98.248.153.86 X-Exim-ID: 1bvxs3-0004DW-7m X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: c-98-248-153-86.hsd1.ca.comcast.net ([10.0.96.3]) [98.248.153.86]:47809 X-Source-Auth: dashi@agnada.com X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== Archived-At: Cc: webpush@ietf.org Subject: Re: [Webpush] Agenda requests for IETF 97 (Seoul) 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, 17 Oct 2016 02:41:53 -0000 All; I haven=E2=80=99t received any agenda requests. If we don=E2=80=99t have any topics, I will cancel the session that we = have reserved scheduled for Friday.=20 Please let me know if you have any topics you want to cover in F2F = meeting.=20 Thanks!=20 Shida as co-chiar > On Oct 8, 2016, at 12:55 PM, Shida Schubert wrote: >=20 > All,=20 >=20 > The Seoul meeting is approaching in a month and we as chairs would = need to decide if we are keeping our 90 minutes slot in Seoul.=20 >=20 > Please send in your agenda requests with what you would like to = discuss and how long you would need.=20 >=20 > Please send your requests and/or ideas for the agenda to the chairs or = to the list. >=20 > Many Thanks, > Shida as co-chair > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush From nobody Mon Oct 17 00:03:29 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 15893129569; Mon, 17 Oct 2016 00:03:23 -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 SVwbPoo-4y5k; Mon, 17 Oct 2016 00:03:21 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0137.outbound.protection.outlook.com [104.47.40.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E450C1294FB; Mon, 17 Oct 2016 00:03:20 -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=9ff8HOWoarM5lRJPBVf0rhyltW3XnhC+DSdY0J6wV58=; b=FSoyv+87zlxX3BsNzmhqbePct/Vj6rzxhlS5Qg24I4zPhdNaFSg2oC3OIfhzZgsTyVBsGYRbv/PmTUXYQdajc/UJ4qL1aHH/5NnSpvwlefPwKV/keL3ZMoNiKqSO45R7Asrp+Zpq9jVzvqKKLMFxPjxS6aF14pa4CryLSnZk4po= Received: from CY1PR03MB2380.namprd03.prod.outlook.com (10.167.8.6) by CY1PR03MB2380.namprd03.prod.outlook.com (10.167.8.6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Mon, 17 Oct 2016 07:03:19 +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.0659.025; Mon, 17 Oct 2016 07:03:19 +0000 From: Brian Raymor To: Stephen Farrell , The IESG Thread-Topic: Stephen Farrell's Discuss on draft-ietf-webpush-protocol-11: (with DISCUSS and COMMENT) Thread-Index: AQHSJiwPJMwjYoplfkyn6wgWsrTwWqCoSZiggAPy/pA= Date: Mon, 17 Oct 2016 07:03:19 +0000 Message-ID: References: <5816348f-015a-beca-a5e6-3883fff02aab@cs.tcd.ie> 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: [174.61.159.182] x-ms-office365-filtering-correlation-id: fb83e78d-28c4-474b-88ed-08d3f65bad29 x-microsoft-exchange-diagnostics: 1; CY1PR03MB2380; 7:5ama52CuztzuCmOQUjVQnI2hv3pT65hAMwhYs4WE10VwytKwTh0f2sVaaATcY6MUtmQjkPd7hypY08XEG05HojeRwett5Cy/f8veJsFaBLZdqLdF1HpCIZvkmSeXA2f2Kb1XdWl9l58VQTFBMKhh5KDXG84MN3YbJ4CBjUc6BKPIqejlDhCg5AX5u/VJj5T7SgVqw1HKtHL+PYyjkunp6qEkMBKiikkSGIU7Np2inyBQUqGeIzKZxVCCZ2r/f748jmV2kJqcPJ2PmW+bre6WPfiznkLOCBOqanvHD/uaPcmgjxaf2iTAFYZ2NreczqBdZiDGVvR3+QEDI87EpxredLwpB/iCaDoYNxV6e7UsbqKF16N67wuI/6J5w3VAB2+N x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2380; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2380; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2380; x-forefront-prvs: 0098BA6C6C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(97736004)(2900100001)(106116001)(102836003)(3846002)(6116002)(86612001)(87936001)(10400500002)(7846002)(5005710100001)(10090500001)(8936002)(122556002)(77096005)(19580395003)(5002640100001)(81166006)(5660300001)(305945005)(86362001)(15975445007)(9686002)(81156014)(230783001)(74316002)(3280700002)(7736002)(8676002)(3660700001)(5001770100001)(76576001)(76176999)(54356999)(2906002)(2950100002)(189998001)(11100500001)(7696004)(8990500004)(33656002)(92566002)(66066001)(68736007)(50986999)(10290500002)(586003)(106356001)(105586002)(99286002)(101416001)(4326007); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2380; 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2016 07:03:19.4767 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2380 Archived-At: Cc: "draft-ietf-webpush-protocol@ietf.org" , Shida Schubert , "webpush-chairs@ietf.org" , "webpush@ietf.org" Subject: Re: [Webpush] Stephen Farrell's Discuss on draft-ietf-webpush-protocol-11: (with DISCUSS and COMMENT) 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, 17 Oct 2016 07:03:23 -0000 Q29ycmVjdGluZyBhIG1haWwgYm91bmNlLiBBcG9sb2dpZXMgZm9yIGR1cGxpY2F0ZXMuDQoNClRh a2UgdHdvLg0KDQo+IFNvIHdoYXQncyBub3QgY2xlYXIgdG8gbWUgaXMgaG93IHdlYnB1c2ggd29y a3Mgd2l0aCB0aGUgU09QDQo+IGFuZCB3aGV0aGVyIHRoZXJlJ3MgYW55dGhpbmcgbW9yZSB0aGF0 IG5lZWRzIHRvIGJlIHNhaWQgYWJvdXQNCj4gdGhhdCBpbiB0aGUgZG9jdW1lbnQuIEZvciBleGFt cGxlLCB5b3Ugc2Vuc2libHkgcmVjb21tZW5kDQo+IHJ1bm5pbmcgdGhlIHB1c2ggc2VydmljZSBv biBwb3J0IDEwMDEgYnV0IG5vbmUgb2YgdGhlIGV4YW1wbGVzDQo+IG1lbnRpb24gdGhhdCBwb3J0 IGluIHRoZSBIb3N0IG9yIDphdXRob3JpdHkgdmFsdWVzIHNob3duLg0KPiBUaGlzIG1heSBhbGwg YmUgY2xlYXIgdG8gc29tZW9uZSB3aG8ncyB2ZXJ5IGZhbWlsaWFyIHdpdGgNCj4gYWx0LXN2YyB0 aG91Z2gsIChidXQgaXQgd2Fzbid0IGNsZWFyIHRvIG1lOi0pLCB3aGljaCBtaWdodA0KPiBiZSBm aW5lLCBidXQgSSdtIG5vdCBzdXJlLiBBcyBhbiBleGFtcGxlLCBpcyB0aGUgYXBwbGljYXRpb24N Cj4gdGhhdCBpcyBwdXNoaW5nIHRoZSBtZXNzYWdlcyByZXF1aXJlZCB0byBrbm93IHRoYXQgdGhl DQo+IHB1c2ggc2VydmljZSBpcyBvciBpcyBub3QgdXNpbmcgcG9ydCAxMDAxPw0KDQpJJ3ZlIGFk ZGVkIGEgY2xhcmlmaWNhdGlvbiB0byBTZWN0aW9uIDEuMSByZWdhcmRpbmcgdGhlIGV4YW1wbGVz IGluIHRoZQ0KZG9jdW1lbnQgLSBvdXRsaW5pbmcgdGhlIG1pbm9yIGNoYW5nZXMgcmVxdWlyZWQg aWYgQWx0LVN2YyB3YXMgaW4gcGxheToNCg0KaHR0cHM6Ly9naXRodWIuY29tL3dlYnB1c2gtd2cv d2VicHVzaC1wcm90b2NvbC9wdWxsLzE0MS9maWxlcw0KDQpUaGUgc21hbGwgZGlmZmVyZW5jZSBp cyB0aGUgaW5jbHVzaW9uIG9mIHRoZSBBbHQtVXNlZCBoZWFkZXIgZmllbGQgaW4gdGhlIHVzZXIg YWdlbnQgDQpyZXF1ZXN0cyB0byB0aGUgcHVzaCBzZXJ2aWNlLiBObyBvdGhlciBjaGFuZ2VzIChz dWNoIGFzIFVSTHMpIGFyZSByZXF1aXJlZCB3aGljaCANCm1hdGNoZXMgdGhlIGRlc2NyaXB0aW9u IGluIFJGQzc4Mzg6ICcuLi4gIGluIGdlbmVyYWwsIHRoZXkgYXJlIG5vdCB2aXNpYmxlIHRvDQp0 aGUgc29mdHdhcmUgImFib3ZlIiB0aGUgYWNjZXNzIG1lY2hhbmlzbS4gJyBUaGUgInJvdXRpbmci IGlzIHRyYW5zcGFyZW50bHkNCm1hbmFnZWQgaW4gdGhlIEhUVFAgc3RhY2sgYmFzZWQgb24gbXkg dW5kZXJzdGFuZGluZy4gDQoNClNpbWlsYXJseSwgdGhlIGFwcGxpY2F0aW9uIHNlcnZlciBpcyBO T1QgcmVxdWlyZWQgdG8ga25vdyB0aGF0IHRoZSBwdXNoIHNlcnZpY2UgYW5kDQp1c2VyIGFnZW50 IGFyZSB1c2luZyBwb3J0IDEwMDEuIA0KDQouLi5Ccmlhbg0K From nobody Mon Oct 17 00:13: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 72AD312959F; Mon, 17 Oct 2016 00:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.732 X-Spam-Level: X-Spam-Status: No, score=-4.732 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_MED=-2.3, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 wkHKeKA0ezTP; Mon, 17 Oct 2016 00:13:38 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 569BC1294FB; Mon, 17 Oct 2016 00:13:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 32ADFBE4C; Mon, 17 Oct 2016 08:13:34 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYOUifsbDr27; Mon, 17 Oct 2016 08:13:32 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3026CBE39; Mon, 17 Oct 2016 08:13:32 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1476688412; bh=XtbkD+d5NkMLO9mFjf6rW5QnZr0v+RyTvcu1Wk3ZTjw=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=lgBnlPt7IilApdVhBHqWDiLtdXzUwgAdxDvT+Y69+z9bAOXR8ke9Pgqzm9SRUDD5R JiBCW7sUjQOEvXkkFAjFt6y2NXfTpNV7ZgvNrAB7m9P2TJGAwJVosYLodAgz/5MBQZ teWFBfRHwbv769T5e0/+zeFe+dYL3Gvl+5A5ubZI= To: Brian Raymor , The IESG References: <5816348f-015a-beca-a5e6-3883fff02aab@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <77e09f1f-04de-7819-92ea-9e4609cd853d@cs.tcd.ie> Date: Mon, 17 Oct 2016 08:13:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010804000200030004050805" Archived-At: Cc: "draft-ietf-webpush-protocol@ietf.org" , Shida Schubert , "webpush-chairs@ietf.org" , "webpush@ietf.org" Subject: Re: [Webpush] Stephen Farrell's Discuss on draft-ietf-webpush-protocol-11: (with DISCUSS and COMMENT) 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, 17 Oct 2016 07:13:40 -0000 This is a cryptographically signed message in MIME format. --------------ms010804000200030004050805 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 17/10/16 08:03, Brian Raymor wrote: > Correcting a mail bounce. Apologies for duplicates. >=20 > Take two. >=20 >> So what's not clear to me is how webpush works with the SOP >> and whether there's anything more that needs to be said about >> that in the document. For example, you sensibly recommend >> running the push service on port 1001 but none of the examples >> mention that port in the Host or :authority values shown. >> This may all be clear to someone who's very familiar with >> alt-svc though, (but it wasn't clear to me:-), which might >> be fine, but I'm not sure. As an example, is the application >> that is pushing the messages required to know that the >> push service is or is not using port 1001? >=20 > I've added a clarification to Section 1.1 regarding the examples in the= > document - outlining the minor changes required if Alt-Svc was in play:= >=20 > https://github.com/webpush-wg/webpush-protocol/pull/141/files >=20 > The small difference is the inclusion of the Alt-Used header field in t= he user agent=20 > requests to the push service. No other changes (such as URLs) are requi= red which=20 > matches the description in RFC7838: '... in general, they are not visi= ble to > the software "above" the access mechanism. ' The "routing" is transpare= ntly > managed in the HTTP stack based on my understanding.=20 >=20 > Similarly, the application server is NOT required to know that the push= service and > user agent are using port 1001.=20 Thanks. I think I've tracked down the source of my confusion which isn't quite the above (though that does seem like an improvement). In section 3 it says: "The push service shares the same default port number (443/TCP) with HTTPS, but MAY also advertise the IANA allocated TCP System Port 1001 using HTTP alternative services [RFC7838]." I think the MAY there is what got me into a confused state. Say if a UA knows to use port 1001 on example.net and just goes there, then the UA will treat the content as having the origin example.net:1001. If however the UA goes to example.net on port 443 first and then sees an alt-svc, then when it goes to port 1001 it'll treat the content as having origin just example.net. I guess that'll make a difference in how the UA handles pushed content. And I think what's different here, compared to a generic use of alt-svc, is that port 1001 is being registered so it's more likely a UA goes directly there the very first time and never hits 443. Seems to me that may mean there's a missing bit of text warning of that, and perhaps a missing bit of text that push services would be wise to advertise the port 443 URLs to which a UA can subscribe and then use alt-svc to schlep UAs over to port 1001. (And maybe that means that the text about "advertising the alternate port (1001)" could also do with a change?) Does the above sound right? Or am I still confused? :-) Cheers, S. >=20 > ...Brian >=20 --------------ms010804000200030004050805 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEwMTcw NzEzMzJaMC8GCSqGSIb3DQEJBDEiBCDjxHzTacfoALtSHQXlRRhArwn1ZdwJK5XmV1xfFNUY dzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAerYMtWkBaHwkpEGVCaVew+jGJ3iGhXVFP/fLRubY5d0LFngWxVzC4 idAcbXnzhrtSelsg8J0apNGXLU40x3P+NMwJzT3vZfp5KRozkbdnvzdwX2U8a3wivHxqNwCh NKMETLccg16L4gymga1KYB3eozQ0B7enHCjv13CjRF+aWuN5D0FJqNo3quqkdkoSEXqdZ1a9 Qx4dCm+hTmNC5yqugooGq/TqWApnpIs+s+CdX5vJ/79uJyqfJ0YKYxIny7BybzVO/ZXWkLNj 8bizvdIZ9BhdNIWk/qhf6b0W4L6sIfqDyTWQuX7s+MbbB4lsiTyqDhWwiZTczLq/QmdzUc8O AAAAAAAA --------------ms010804000200030004050805-- From nobody Mon Oct 17 03:04: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 7B90F129435; Mon, 17 Oct 2016 03:04:45 -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 gq0CNJ0A4RiQ; Mon, 17 Oct 2016 03:04:43 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::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 760591294EE; Mon, 17 Oct 2016 03:04:43 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id f128so215898397qkb.1; Mon, 17 Oct 2016 03:04: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=bsYsCiDRG/Em9D5VaA+lcuBGZ12eD1H4WdcBTMUo9Ew=; b=qRFeu+2JRAIB2LjVpSuQw/souhNWBWLbe+QUTvKMcskuSwG5WExplMJp9aUMxSek4Q CNyA1/4qaJpbDJeORb0MRAXDr9wFYGYhTsjcPtfI3cWwIm1l3emyoxA36+GwP+dm5JhE xHZ4sjiem9kmONt0wk5WBwRWF4/QqHTiNoNWUNkG87XwtlrzJNJhx2vqV59yq7kM6jat o+qMZC9sBpIhL1NHbJdyIP6AQh5ixoJZ4FBSlH//Rsqy3/pJIuDcJVW7TVHrO4EBrO01 6Hb8leznJyYXKL2gMU21Tdv/pp2Kj1CzpGNF7w584sBW6rqH91J4dVpNzLaQ8oeQxW24 3wWQ== 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=bsYsCiDRG/Em9D5VaA+lcuBGZ12eD1H4WdcBTMUo9Ew=; b=VaBBZ9gbkTsoI5IUUotGjI14JApXEMA5RdhlMFtR9euFlTahf5xfII+rjwx7Vzwb+N fFOxUREmLetlEVgliIG+02pLcnvxis5DpYrdMv4mVky9B0AmSFKzZcd1288HjYJs3mas v5ECVGeBSkVRuxNYRRMq/0Wd4MACi01LS1E/3v1fjsQhWnL1M12oHW2pxd9Tf5PrN4hi VRU/SSZMaRhUEp+or1gbdl7qj7+cEWh1pno8iUv0Oxsy7ADG4GQzCbBnKjwvcr0x/lQq s0WoogBITqC825KVzgYYF19Ln81lgIwh7JtVGJH4OzgaWmLFs8D+5ZQ030bxzZgmPtzH dncQ== X-Gm-Message-State: AA6/9RmgmRPBsuEHAGx1bUAH83ccPhD9hB+CZO8FoOJGut6atNJy9paPmCLsVfaQH7cBcKPH3uzxlBBHkL5Z0g== X-Received: by 10.55.155.15 with SMTP id d15mr22437378qke.115.1476698681712; Mon, 17 Oct 2016 03:04:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Mon, 17 Oct 2016 03:04:40 -0700 (PDT) In-Reply-To: <77e09f1f-04de-7819-92ea-9e4609cd853d@cs.tcd.ie> References: <5816348f-015a-beca-a5e6-3883fff02aab@cs.tcd.ie> <77e09f1f-04de-7819-92ea-9e4609cd853d@cs.tcd.ie> From: Martin Thomson Date: Mon, 17 Oct 2016 21:04:40 +1100 Message-ID: To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Brian Raymor , Shida Schubert , The IESG , "draft-ietf-webpush-protocol@ietf.org" , "webpush-chairs@ietf.org" , "webpush@ietf.org" Subject: Re: [Webpush] Stephen Farrell's Discuss on draft-ietf-webpush-protocol-11: (with DISCUSS and COMMENT) 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, 17 Oct 2016 10:04:45 -0000 On 17 October 2016 at 18:13, Stephen Farrell wrote: > I think the MAY there is what got me into a confused state. > Say if a UA knows to use port 1001 on example.net and just > goes there, then the UA will treat the content as having the > origin example.net:1001. If however the UA goes to example.net > on port 443 first and then sees an alt-svc, then when it goes > to port 1001 it'll treat the content as having origin just > example.net. Correct. That is a good summary of how Alt-Svc interacts here. > I guess that'll make a difference in how the UA > handles pushed content. Actually it won't because it doesn't treat the content it retrieves as belonging to a particular origin. The information that is received is handled by the UA (not any application that resides in it, in the case of a browser). As a browser, with origins and all that business, we don't actually treat content as subject to SOP until we've received the push message, decrypted it, and actually handed it to the origin. Because the content we receive from a push service rightfully belongs to many origins, we have to treat it specially. The push service is aware of its role in this, so we don't need to ask special permission to share either. It did implement the protocol after all. Thus, the data we source there isn't treated as cross-origin. We do exactly the same for the geolocation API when we get a location from a server. (I could also explain how you can follow the crypto and see that the data isn't cross-origin at all, but that would be just sophistry.) Either way, I believe that what you are asking for rightfully belongs in the API part, since we're trying to make the protocol pieces ignorant of all that disgusting browser gunk. Happy to add something as editor of the API pieces, but not entirely sure what. It's strange because it's entirely too obvious to me to the point that I didn't really know what you were on about, but then you are right that we never actually write this stuff down. Opened https://github.com/w3c/push-api/issues/211 From nobody Mon Oct 17 07:40: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 27106129416; Mon, 17 Oct 2016 07:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.732 X-Spam-Level: X-Spam-Status: No, score=-4.732 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_MED=-2.3, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 zGhylOsBAG_R; Mon, 17 Oct 2016 07:40:25 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9D531295EF; Mon, 17 Oct 2016 07:40:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6F805BE3E; Mon, 17 Oct 2016 15:40:21 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWApJfn-EaHL; Mon, 17 Oct 2016 15:40:21 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CFD15BE2F; Mon, 17 Oct 2016 15:40:20 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1476715221; bh=0NQ19/0dLf6m4n1eQUYj0DHRrbni4KCi8/yfE8xpOyM=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=PQqfkUBTnpYPbFDCbx8qyxJatTvkagSf1ep9FVOChBN7ZTIzGhNX0uHk+xW/0i5aO 5i6mXDAVqbEZ3w5z9Gbl1TR0KY0eUWsb710QqspBr3/SxZRv76RuW77G1TEXCIyJy0 seAsXCFUmYke6tjRVzZM5yoEYlKYfbeUg/MGi+2Y= To: Martin Thomson References: <5816348f-015a-beca-a5e6-3883fff02aab@cs.tcd.ie> <77e09f1f-04de-7819-92ea-9e4609cd853d@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56cca9c2-22a7-10bf-6d3a-cde3b82db9dc@cs.tcd.ie> Date: Mon, 17 Oct 2016 15:40:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060805030707090409070509" Archived-At: Cc: Brian Raymor , Shida Schubert , The IESG , "draft-ietf-webpush-protocol@ietf.org" , "webpush-chairs@ietf.org" , "webpush@ietf.org" Subject: Re: [Webpush] Stephen Farrell's Discuss on draft-ietf-webpush-protocol-11: (with DISCUSS and COMMENT) 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, 17 Oct 2016 14:40:28 -0000 This is a cryptographically signed message in MIME format. --------------ms060805030707090409070509 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 17/10/16 11:04, Martin Thomson wrote: > On 17 October 2016 at 18:13, Stephen Farrell wrote: >> I think the MAY there is what got me into a confused state. >> Say if a UA knows to use port 1001 on example.net and just >> goes there, then the UA will treat the content as having the >> origin example.net:1001. If however the UA goes to example.net >> on port 443 first and then sees an alt-svc, then when it goes >> to port 1001 it'll treat the content as having origin just >> example.net. >=20 > Correct. That is a good summary of how Alt-Svc interacts here. >=20 >> I guess that'll make a difference in how the UA >> handles pushed content. >=20 > Actually it won't because it doesn't treat the content it retrieves as > belonging to a particular origin. The information that is received is > handled by the UA (not any application that resides in it, in the case > of a browser). >=20 > As a browser, with origins and all that business, we don't actually > treat content as subject to SOP until we've received the push message, > decrypted it, and actually handed it to the origin. Because the > content we receive from a push service rightfully belongs to many > origins, we have to treat it specially. Saying that would've definitely helped me understand what's going on. Does something need to be stated in this draft? Or is it safe enough to assume that the reader will also look at the API and encryption drafts, and that people won't come up with other ways to handle pushed messages that don't support good ways to enforce the SOP? Cheers, S. >=20 > The push service is aware of its role in this, so we don't need to ask > special permission to share either. It did implement the protocol > after all. Thus, the data we source there isn't treated as > cross-origin. >=20 > We do exactly the same for the geolocation API when we get a location > from a server. >=20 > (I could also explain how you can follow the crypto and see that the > data isn't cross-origin at all, but that would be just sophistry.) >=20 > Either way, I believe that what you are asking for rightfully belongs > in the API part, since we're trying to make the protocol pieces > ignorant of all that disgusting browser gunk. Happy to add something > as editor of the API pieces, but not entirely sure what. It's strange > because it's entirely too obvious to me to the point that I didn't > really know what you were on about, but then you are right that we > never actually write this stuff down. Opened > https://github.com/w3c/push-api/issues/211 >=20 --------------ms060805030707090409070509 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEwMTcx NDQwMjFaMC8GCSqGSIb3DQEJBDEiBCANtxxpipj20qvXwFFMrDtC6KjoW/PkYvdHdXFEIk88 czBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCbEDMrCh3rVy0lgTaVZWj2mmUy+OsaoEghJyZ1oTXK9EpqJoyFBx22 An3BxppEb7xwiMLOuhPXDEP3ASwbB2aYxI42e/1uqDizPnsYIy7GqRGkEEwm5yvLd8EmG22k Sy2SIWoKlvjnei+Pc3uGScUGupfLFCQA+QPCoxHgk6z5NQJMyz7LnsXhLraSQrX409h83yRZ YG5gsLR3S8r78fpYp5sydbIWwKYe20xqaYb5DzXQ0c+d6P7vW8wSHiH1/4feDx0FAS2cG41v 0DLSWCIM/jrNnYsbP+SfyP4KPS0SFc8YYkCEA5QCa4nRy4ngLc+t1lajpcBCuR/LdztqO1p6 AAAAAAAA --------------ms060805030707090409070509-- From nobody Mon Oct 17 08:27: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 C897E1294DA for ; Mon, 17 Oct 2016 08:27:42 -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=Fgy58xGH; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=EISkTDiq 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 ge0bkPB9IN0V for ; Mon, 17 Oct 2016 08:27:41 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45F99129864 for ; Mon, 17 Oct 2016 08:27:41 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id A7DDA2077B; Mon, 17 Oct 2016 11:27:40 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Mon, 17 Oct 2016 11:27:40 -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=tXONQB1AYwo/NQsKJTZa+sNSY2s=; b=Fgy58x GHA+nRaes1+ERQUgVbveqKIn76TyXclM1HgLAgUjLwal8/6xwmne5qOSRnRmSWOR 30DL+mQWu0YBgEGVc6Re4/gILYq9rl9Cmn4j4R5yn8kLOqBUj0O7iRRtNMa+duI2 0x8MDb5keGPXWAIWWzK/YuWCqx97FkjUYSBc0= 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=tXONQB1AYwo/NQs KJTZa+sNSY2s=; b=EISkTDiqUW9AdmU3ILsYPc74K1DcCfC1dSebofnB5ALiYWi uJDCV3SVIH2Sx0/3nJssZ4V+TdCUL+xhZwFY/aCWwx+oWwBMc/GNPf6HqVJrk5/u BLiCOjLZF0djIvf9d+6D8NeeTPvz1lvUSo742c4V8Ex03y5wRPnTAYwxXv2Y= X-Sasl-enc: yY6374mAODyvYJyBRJqIKE0opgPYUIIbjgvGJy6rZ+pi 1476718060 Received: from [10.24.126.242] (unknown [128.107.241.177]) by mail.messagingengine.com (Postfix) with ESMTPA id D3B11F29D1; Mon, 17 Oct 2016 11:27:39 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: Date: Mon, 17 Oct 2016 11:27:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0F8DEB44-41DC-40CA-84CC-4C023E3CBB00@ntt-at.com> To: Shida Schubert X-Mailer: Apple Mail (2.3124) Archived-At: Cc: webpush@ietf.org Subject: Re: [Webpush] Agenda requests for IETF 97 (Seoul) 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, 17 Oct 2016 15:27:43 -0000 If the WG can decide about canceling by this Thursday, Oct 20, that = would assist with managing conflicts in the final IETF agenda. Thanks, Alissa > On Oct 16, 2016, at 10:41 PM, Shida Schubert wrote: >=20 >=20 > All; >=20 > I haven=E2=80=99t received any agenda requests. >=20 > If we don=E2=80=99t have any topics, I will cancel the session that we = have reserved scheduled for Friday.=20 >=20 > Please let me know if you have any topics you want to cover in F2F = meeting.=20 >=20 > Thanks!=20 > Shida as co-chiar >=20 >> On Oct 8, 2016, at 12:55 PM, Shida Schubert wrote: >>=20 >> All,=20 >>=20 >> The Seoul meeting is approaching in a month and we as chairs would = need to decide if we are keeping our 90 minutes slot in Seoul.=20 >>=20 >> Please send in your agenda requests with what you would like to = discuss and how long you would need.=20 >>=20 >> Please send your requests and/or ideas for the agenda to the chairs = or to the list. >>=20 >> Many Thanks, >> Shida as co-chair >> _______________________________________________ >> 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 From nobody Mon Oct 17 17:59: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 3E3DF129451 for ; Mon, 17 Oct 2016 17:59:56 -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 qsNt0mOsyaBb for ; Mon, 17 Oct 2016 17:59:55 -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 98D491279EB for ; Mon, 17 Oct 2016 17:59:54 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id o68so311507807qkf.3 for ; Mon, 17 Oct 2016 17:59:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QdYwKzEHMcrzjKYxFMlv/lPOl2DsEwMuyDQfWVfJl8w=; b=ZqtFxw1MsGxZVQM3QvbLqgxk0V7cmvYIzsR96xmHb5BruhzbvpURPFrtaS/6jom2E+ EJ684sGVxL1RvFsedtRI9Rw9mMxGL5pNX6FsGa72fzxbT6LgULEcVU14rT/8D4PZ7H5G cYi/uN5mfQFNobAO9ozJ2c1rD/B88GUsDdvvJZScknQSfbrqp2KhQ3ic2bZCYhX/ST5N gkvn5fS3XunqbrJ26SLWb6AWTNRyfn6L8cVzMhinLykHOlodjd4zJ5jT9aLeDbxzUFcK HlbGon8O0iabggjMpSXf0607RcWw4nzm0dx0Mfe7be37GSNbAmv+xWUm2/23O8Ord3v8 7i3g== 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=QdYwKzEHMcrzjKYxFMlv/lPOl2DsEwMuyDQfWVfJl8w=; b=JP6y0aprBlE206AYkzpnQevcxeMgvlgA2ao/8qPQwnXp7hdQJ7tzX4IkjoI6r22mTu q/qH8A5SeUqZEb1B5GjNjLjFwh28WwVodq5Gr8rIF10wwTilbxQ4Xtge+I0iXUUanZH0 MYWAR5Gv/Z7qOFeHdVuZTbW+S+oS2iqubRGeVhHZRmruvtSLSlmcqugEX7tsrsKxi7lG bBxxRRmdZ5dGyS4+vzQorfG5OGjGBmM7SXkD19UrT9u7NMt2AQrTUqTPvHN56E12SBvL qIs13oIxXy0jUj4v3+MDZqVL9dpyV5FlC7UHq+p+aMEhIKrLJ+aets1ouxTXB238eRAB OcRA== X-Gm-Message-State: AA6/9Rk4Q3LdqQCa3M2xuWmWAXQT2fqGrgmyrfYfbJFlrYvCeYzsr5pa8iS8Uj4UFUoupb2Il8l1q8b9SKDpNw== X-Received: by 10.55.74.6 with SMTP id x6mr296966qka.316.1476752393742; Mon, 17 Oct 2016 17:59:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Mon, 17 Oct 2016 17:59:53 -0700 (PDT) In-Reply-To: References: <0F8DEB44-41DC-40CA-84CC-4C023E3CBB00@ntt-at.com> From: Martin Thomson Date: Tue, 18 Oct 2016 11:59:53 +1100 Message-ID: To: Alissa Cooper Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Shida Schubert , "webpush@ietf.org" Subject: Re: [Webpush] Agenda requests for IETF 97 (Seoul) 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, 18 Oct 2016 00:59:56 -0000 On 18 October 2016 at 02:27, Alissa Cooper wrote: > If the WG can decide about canceling by this Thursday, Oct 20, that would assist with managing conflicts in the final IETF agenda. I'm not aware of any need for a meeting. I'd say that we're safe in cancelling already. From nobody Mon Oct 17 21:14: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 0186412943E; Mon, 17 Oct 2016 21:14:25 -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 riCSPf6Z7Rfd; Mon, 17 Oct 2016 21:14:23 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0113.outbound.protection.outlook.com [104.47.38.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D85391294F6; Mon, 17 Oct 2016 21:14:22 -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=uq4431vFzRij8CTyhK+Hme+WxxAGcRvgF/7Ua0lI5Zo=; b=hJltbpTQUWuE/PXHcuy6WATgfjslybyOOdOY+1CL/OCkPEaq9whOYbPuqwJmy3BUvmOJ9DiH7j8vDLR+3uhgYLA8iOgKl6mTAjLrAyGgzvNDe7u/SF/fJnvGqFrWXdin70ucJI0+KiTT+bQkcvdb+4NzHkul7KhzssmZ32Hbro4= Received: from CY1PR03MB2380.namprd03.prod.outlook.com (10.167.8.6) by CY1PR03MB2380.namprd03.prod.outlook.com (10.167.8.6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Tue, 18 Oct 2016 04:14:18 +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.0659.025; Tue, 18 Oct 2016 04:14:18 +0000 From: Brian Raymor To: Stephen Farrell , Martin Thomson Thread-Topic: Stephen Farrell's Discuss on draft-ietf-webpush-protocol-11: (with DISCUSS and COMMENT) Thread-Index: AQHSJiwPJMwjYoplfkyn6wgWsrTwWqCoSZiggAPy/pCAAAMBAIAAL9AAgABNB4CAANs6oA== Date: Tue, 18 Oct 2016 04:14:18 +0000 Message-ID: References: <5816348f-015a-beca-a5e6-3883fff02aab@cs.tcd.ie> <77e09f1f-04de-7819-92ea-9e4609cd853d@cs.tcd.ie> <56cca9c2-22a7-10bf-6d3a-cde3b82db9dc@cs.tcd.ie> In-Reply-To: <56cca9c2-22a7-10bf-6d3a-cde3b82db9dc@cs.tcd.ie> 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: 920c8496-76d8-4c14-5929-08d3f70d3b08 x-microsoft-exchange-diagnostics: 1; CY1PR03MB2380; 7:XgddA5xKMtxGKUztwl/OCoQDznmkRrbXJVpv1xpvHYzivOvK9OIIusxZBZsKkDazi6yXUObrKg+Yt/voJHNDh9zhawsIlWlZULE3PQrsApR9ndqXxKTkWQ93eySiSvx581tnERr3Oz0B+E3AJZUrt0GKBzaj8MGiuKHioxwImABHLXMBtEvKrw6mnujP5ROC6ztMViafXStAT7UjEPV7NaQ7QwrTmQV3tHCpRN4s6GxH/z0IjE08dhwS6WIWBADUmoBkIppOKoXwOPwsL2DNvk/UTHxvbU99NNWMzz07zPcS+rRJJejbe6HGxFE9nwAxd6OKCHeP+e9w3fFQdyFQuhDP8F/TLeadtZ/hyblDkzuCpXrNfRWZJPaAkad093QB x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2380; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6060202)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2380; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2380; x-forefront-prvs: 00997889E7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(189998001)(11100500001)(93886004)(7696004)(76576001)(2906002)(2950100002)(54356999)(76176999)(50986999)(586003)(106356001)(10290500002)(99286002)(101416001)(105586002)(66066001)(68736007)(33656002)(8990500004)(92566002)(5005710100001)(86612001)(87936001)(7846002)(8936002)(10090500001)(4326007)(97736004)(2900100001)(106116001)(10400500002)(3846002)(6116002)(102836003)(7736002)(230783001)(8676002)(74316002)(3660700001)(122556002)(5002640100001)(3280700002)(77096005)(19580395003)(81166006)(305945005)(86362001)(81156014)(15975445007)(9686002)(5001770100001)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2380; 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Oct 2016 04:14:18.5469 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2380 Archived-At: Cc: "draft-ietf-webpush-protocol@ietf.org" , Shida Schubert , "webpush-chairs@ietf.org" , The IESG , "webpush@ietf.org" Subject: Re: [Webpush] Stephen Farrell's Discuss on draft-ietf-webpush-protocol-11: (with DISCUSS and COMMENT) 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, 18 Oct 2016 04:14:25 -0000 SGkgU3RlcGhlbiwNCg0KPiBTYXlpbmcgdGhhdCB3b3VsZCd2ZSBkZWZpbml0ZWx5IGhlbHBlZCBt ZSB1bmRlcnN0YW5kIHdoYXQncyBnb2luZyBvbi4NCg0KU29ycnkgYWJvdXQgdGhhdC4gSXQgcmVx dWlyZWQgYSBmZXcgaXRlcmF0aW9ucyBmb3IgdXMgdG8gdW5kZXJzdGFuZCwgYnV0IHdlIGdvdCB0 aGVyZS4NCg0KPiBEb2VzIHNvbWV0aGluZyBuZWVkIHRvIGJlIHN0YXRlZCBpbiB0aGlzIGRyYWZ0 PyANCg0KTWFydGluIGFuZCBJIGhhdmUgcmV2aWV3ZWQgYW5kIGFyZSBpbiBhZ3JlZW1lbnQgdGhh dA0KZnVydGhlciBjbGFyaWZpY2F0aW9ucyB3b3VsZCBub3QgYmUgaGVscGZ1bCBpbiB0aGUgcHJv dG9jb2wgZHJhZnQuDQoNCj4gT3IgaXMgaXQgc2FmZSBlbm91Z2ggdG8gYXNzdW1lIHRoYXQgdGhl DQo+IHJlYWRlciB3aWxsIGFsc28gbG9vayBhdCB0aGUgQVBJIGFuZCBlbmNyeXB0aW9uIGRyYWZ0 cywNCj4gYW5kIHRoYXQgcGVvcGxlIHdvbid0IGNvbWUgdXAgd2l0aCBvdGhlciB3YXlzIHRvIGhh bmRsZQ0KPiBwdXNoZWQgbWVzc2FnZXMgdGhhdCBkb24ndCBzdXBwb3J0IGdvb2Qgd2F5cyB0bw0K PiBlbmZvcmNlIHRoZSBTT1A/DQoNCkV4YWN0bHkuIFRoaXMgaXMgbW9yZSByZWxldmFudCB0byB0 aGUgUHVzaCBBUEkgLyBXM0Mgd2hpY2ggTWFydGluDQppcyBub3cgdHJhY2tpbmcgaW4gaHR0cHM6 Ly9naXRodWIuY29tL3czYy9wdXNoLWFwaS9pc3N1ZXMvMjExLiANCg0KQW5kIG91ciBleHBlcmll bmNlIGlzIHRoYXQgZGV2ZWxvcGVycyBhcmUgY29uc3VtaW5nIGFsbCB0aGUgcmVsYXRlZA0KZHJh ZnRzLiBXZSBoYWQgc29tZSBuZXcgbWVtYmVycyBkdXJpbmcgV0dMQyB3aG8gZGVtb25zdHJhdGVk DQp0aGlzIHBvaW50IHdpdGggdGhlaXIgY29udHJpYnV0aW9ucy4NCg0KVGhpcyB3YXMgZGVmaW5p dGVseSBhIHN1YnRsZSBkaXNjdXNzaW9uLiBXZSBhcHByZWNpYXRlIHRoYXQgeW91ciByZXZpZXcN CmNhbGxlZCB0aGlzIG91dCBmb3IgY29uc2lkZXJhdGlvbi4gDQoNCi4uLkJyaWFuDQo= From nobody Tue Oct 18 01:43: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 BA9571299CD; Tue, 18 Oct 2016 01:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.732 X-Spam-Level: X-Spam-Status: No, score=-4.732 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_MED=-2.3, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 aO6eNyNhBPrD; Tue, 18 Oct 2016 01:43:48 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9538B1299C3; Tue, 18 Oct 2016 01:43:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E5EF8BE2F; Tue, 18 Oct 2016 09:43:45 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id timD8BSQ4W41; Tue, 18 Oct 2016 09:43:45 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5BE02BE2E; Tue, 18 Oct 2016 09:43:45 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1476780225; bh=jNABrGRn3UzsU2nJoNx+HI1PTIV9Is96jnL4woLdVck=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=twyVMPh0f0P010WZTP4irglriX8QhTWtc6cUT7zjz1pNYNiEAhpHrXWFcKdKK5O7y drnJnktfVJFqeABimscSAsQsLMLlpatk36ClpMMdJdai8BaYXI4BWJcmM+QLNyGlEk /MGjkYrBiZBCZQnGuR4A3jRe8gV3ebGy/BIhxKMo= To: Brian Raymor , Martin Thomson References: <5816348f-015a-beca-a5e6-3883fff02aab@cs.tcd.ie> <77e09f1f-04de-7819-92ea-9e4609cd853d@cs.tcd.ie> <56cca9c2-22a7-10bf-6d3a-cde3b82db9dc@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <6fdc9c7d-e517-b142-45d6-9164d4a63053@cs.tcd.ie> Date: Tue, 18 Oct 2016 09:43:45 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060400070201030402090205" Archived-At: Cc: "draft-ietf-webpush-protocol@ietf.org" , Shida Schubert , "webpush-chairs@ietf.org" , The IESG , "webpush@ietf.org" Subject: Re: [Webpush] Stephen Farrell's Discuss on draft-ietf-webpush-protocol-11: (with DISCUSS and COMMENT) 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, 18 Oct 2016 08:43:51 -0000 This is a cryptographically signed message in MIME format. --------------ms060400070201030402090205 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, We're nearly there... On 18/10/16 05:14, Brian Raymor wrote: > Hi Stephen, >=20 >> Saying that would've definitely helped me understand what's going on. >=20 > Sorry about that. It required a few iterations for us to understand, bu= t we got there. >=20 >> Does something need to be stated in this draft?=20 >=20 > Martin and I have reviewed and are in agreement that > further clarifications would not be helpful in the protocol draft. >=20 >> Or is it safe enough to assume that the >> reader will also look at the API and encryption drafts, >> and that people won't come up with other ways to handle >> pushed messages that don't support good ways to >> enforce the SOP? >=20 > Exactly. This is more relevant to the Push API / W3C which Martin > is now tracking in https://github.com/w3c/push-api/issues/211.=20 >=20 > And our experience is that developers are consuming all the related > drafts. We had some new members during WGLC who demonstrated > this point with their contributions. So doesn't that argue to make the relevant drafts normative references? That's not meant to be a blocking comment btw, I'm ok with the RFC having those as informative (modulo my last question below) but think it'd be better if they were normative. >=20 > This was definitely a subtle discussion. We appreciate that your review= > called this out for consideration.=20 I've just one last thing to ask before we're done: Do we envisage anyone ever using this push service mechanism without the content of the message being as defined in the webpush encryption draft and without following the W3C API? If we do, and if that content ends up in a browser or other application that needs the SOP or similar, then I'm still not sure it's ok to say nothing in this draft. If we do not, then it'd seem sensible to add a statement to the effect that all these things are really a package and it's not necessarily safe to just use this piece alone. Cheers, S. >=20 > ...Brian >=20 --------------ms060400070201030402090205 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEwMTgw ODQzNDVaMC8GCSqGSIb3DQEJBDEiBCB2mp8dxT8KIhTE4fC+4pqyl6EU+TGLFqjXQtLcd3t4 NTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAubX3yT7uxjTPTmG5d5x+QAEWcpxXHxutFGOM6iHjE2pOn/xO04nDH BlAumZzh5Wvrtem2B6bF3w8Irvm7aT+0Wtu/Oe6Lk+Ei913Dc8ro2pV8v18VMeOUl/m00EMv 13Xyr5d46W42fvI5t58HYkLwVlJAAE2kv9dJrYvIKo4qwi7GseD0QHM16NlsfGt0vjWjHa7l kMwD1pD7p3JmmkIP32PIjRs7EatCbeYk5OI2yjWVYgHbynrj69J2cBSf56NhS5XTRe4JfGUH oUzexw2tLVYFknWEyqblvnWQDtTOhFL5VfIKWkty3YlXVNJcCp8tbqqiw8U6M8Eqj3TvUY1F AAAAAAAA --------------ms060400070201030402090205-- From nobody Tue Oct 18 16:21: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 A665C12947D; Tue, 18 Oct 2016 16:21:38 -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 6m0WSOaSi13V; Tue, 18 Oct 2016 16:21:36 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0114.outbound.protection.outlook.com [104.47.34.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 8254812947B; Tue, 18 Oct 2016 16:21:35 -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=mE8DiCTJwqgegqevU3SXqC2U5g99SzThlRjwUQpZJ6s=; b=NXTbd9re2JHiJhcz3mpEnVTPzQQgprRzburHEszNFXxmXHnzTOdpQ1u8fFgJK+1NZvp39RQHq3VI8mWqC7AZu6+eqqDwsdpi58nIwewFF7KFczoOPKqivwyrOUMC1r7s33LcmGOMXgI+a06hisLA5XOGa0mSd+BGDN8OeQY7Un8= Received: from CY1PR03MB2380.namprd03.prod.outlook.com (10.167.8.6) by CY1PR03MB2378.namprd03.prod.outlook.com (10.166.207.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.12; Tue, 18 Oct 2016 23:21:33 +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.0659.025; Tue, 18 Oct 2016 23:21:33 +0000 From: Brian Raymor To: Stephen Farrell , Martin Thomson Thread-Topic: Stephen Farrell's Discuss on draft-ietf-webpush-protocol-11: (with DISCUSS and COMMENT) Thread-Index: AQHSJiwPJMwjYoplfkyn6wgWsrTwWqCoSZiggAPy/pCAAAMBAIAAL9AAgABNB4CAANs6oIAAU3iAgADxCZA= Date: Tue, 18 Oct 2016 23:21:33 +0000 Message-ID: References: <5816348f-015a-beca-a5e6-3883fff02aab@cs.tcd.ie> <77e09f1f-04de-7819-92ea-9e4609cd853d@cs.tcd.ie> <56cca9c2-22a7-10bf-6d3a-cde3b82db9dc@cs.tcd.ie> <6fdc9c7d-e517-b142-45d6-9164d4a63053@cs.tcd.ie> In-Reply-To: <6fdc9c7d-e517-b142-45d6-9164d4a63053@cs.tcd.ie> 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: c8edc1ec-f41d-46af-a5f6-08d3f7ad7fab x-microsoft-exchange-diagnostics: 1; CY1PR03MB2378; 7:dtuCIu2nJfNllk4MaTq1voUJLiDrbtGwwgmSP90vwJh94qaXCd7A0SrzmLPDkQd8+XEx4v0QnGb5QwcRHpOewPFYI4YEGaxrjRXZ+b6XRm+Ge5kCEv/qWyIfnRaXKiB6afyPml2/+14X6HZ+yeT0uAozznz+5DpJcW6LhlYCObPx7ID2+WLLoS2eGQ23PRs6/s8TnfJKsG+Z9lfafeeXMgEcyQccR7Zo0kcmEK4SxfoyeR/DFEP1B9h+5zgQP28l3ZdAjRIPNxrEYbZuG+3mFAypdloSjxnNmxM184SrEXTNLA+zTV4tx9CjJvTllGhhGetVbxqcwZrV+NrRTDAbuHjF1yhOJswJN5d/K0znrZZdY/cYTfUBz+vEOUW2irI2 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2378; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2378; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2378; x-forefront-prvs: 00997889E7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(10400500002)(8936002)(10290500002)(101416001)(76176999)(86612001)(3846002)(50986999)(10090500001)(87936001)(54356999)(230783001)(7696004)(8990500004)(81156014)(102836003)(19580395003)(97736004)(5660300001)(189998001)(5001770100001)(105586002)(9686002)(86362001)(2900100001)(2950100002)(305945005)(7736002)(92566002)(3660700001)(74316002)(4326007)(68736007)(5005710100001)(93886004)(2906002)(15975445007)(5002640100001)(122556002)(8676002)(76576001)(106116001)(81166006)(106356001)(3280700002)(7846002)(33656002)(586003)(6116002)(77096005)(11100500001)(99286002)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2378; 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Oct 2016 23:21:33.1349 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2378 Archived-At: Cc: "draft-ietf-webpush-protocol@ietf.org" , Shida Schubert , "webpush-chairs@ietf.org" , The IESG , "webpush@ietf.org" Subject: Re: [Webpush] Stephen Farrell's Discuss on draft-ietf-webpush-protocol-11: (with DISCUSS and COMMENT) 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, 18 Oct 2016 23:21:39 -0000 SGkgU3RlcGhlbiwNCg0KPj4gQW5kIG91ciBleHBlcmllbmNlIGlzIHRoYXQgZGV2ZWxvcGVycyBh cmUgY29uc3VtaW5nIGFsbCB0aGUgcmVsYXRlZA0KPj4gZHJhZnRzLiBXZSBoYWQgc29tZSBuZXcg bWVtYmVycyBkdXJpbmcgV0dMQyB3aG8gZGVtb25zdHJhdGVkDQo+PiB0aGlzIHBvaW50IHdpdGgg dGhlaXIgY29udHJpYnV0aW9ucy4NCg0KPj4gU28gZG9lc24ndCB0aGF0IGFyZ3VlIHRvIG1ha2Ug dGhlIHJlbGV2YW50IGRyYWZ0cyBub3JtYXRpdmUNCj4+IHJlZmVyZW5jZXM/IFRoYXQncyBub3Qg bWVhbnQgdG8gYmUgYSBibG9ja2luZyBjb21tZW50IGJ0dywNCj4+IEknbSBvayB3aXRoIHRoZSBS RkMgaGF2aW5nIHRob3NlIGFzIGluZm9ybWF0aXZlIChtb2R1bG8gbXkNCj4+IGxhc3QgcXVlc3Rp b24gYmVsb3cpIGJ1dCB0aGluayBpdCdkIGJlIGJldHRlciBpZiB0aGV5IHdlcmUNCj4+IG5vcm1h dGl2ZS4NCg0KTm90IGF0IGFsbCAtIGFuZCBmcmFua2x5IHRoYXQgd291bGQgc3VidmVydCBjb25z ZW5zdXMgaW4gdGhlIHdvcmtpbmcgZ3JvdXAuDQpXZSBjcmVhdGVkIHZhcGlkIGFuZCBtZXNzYWdl IGVuY3J5cHRpb24gYXMgc2VwYXJhdGUgZHJhZnRzIGJlY2F1c2UgdGhleeKAmXJlIG9wdGlvbmFs Lg0KVGhlIG5vcm1hdGl2ZSByZWZlcmVuY2VzIG9jY3VyIGluIHRoZSBXM0MgUHVzaCBBUEkuIEZv ciBXZWJQdXNoLA0KdGhlIG90aGVyIGRyYWZ0cyBkZW1vbnN0cmF0ZSBvbmUgYXBwcm9hY2ggdGhh dCBtaWdodCBub3QgYmUgYXBwcm9wcmlhdGUNCmZvciBvdGhlciBzY2VuYXJpb3MgYnV0IGFyZSBp bmNsdWRlZCBmb3IgYXdhcmVuZXNzLg0KDQpBcyBJIHdyb3RlIGluIGFuIGVhcmxpZXIgcmVzcG9u c2U6DQoNCiAgV2ViUHVzaCBpbmNsdWRlcyBpbmZvcm1hdGl2ZSByZWZlcmVuY2VzIHRvIHZhcGlk IGFuZCBtZXNzYWdlIGVuY3J5cHRpb24gYXMgDQogIGV4YW1wbGVzLiBJbiByZXNwb25zZSB0byBj b21tZW50cyBmcm9tIEJlbiBDYW1wYmVsbCBkdXJpbmcgdGhlIHJldmlldywgTWFydGluDQogIGNy ZWF0ZWQgYSBwdWxsIHJlcXVlc3Qgd2hpY2ggY2xhcmlmaWVzIHRoaXM6DQoNCiAgaHR0cHM6Ly9n aXRodWIuY29tL3dlYnB1c2gtd2cvd2VicHVzaC1wcm90b2NvbC9wdWxsLzEzOC9maWxlcw0KDQog IFRoZSBjb25zZW5zdXMgaW4gdGhlIHdvcmtpbmcgZ3JvdXAgd2FzIHRoYXQgb3RoZXIgaW1wbGVt ZW50YXRpb25zL3NjZW5hcmlvcyBvdXRzaWRlDQogIHRoZSBicm93c2VyIChzdWNoIGFzIElvVCkg d291bGQgcHVyc3VlIHRoZWlyIG93biBhcHByb2FjaGVzIHRvIGFkZHJlc3MgdGhlIHJlcXVpcmVt ZW50cy4NCg0KPiBJJ3ZlIGp1c3Qgb25lIGxhc3QgdGhpbmcgdG8gYXNrIGJlZm9yZSB3ZSdyZSBk b25lOg0KDQo+IERvIHdlIGVudmlzYWdlIGFueW9uZSBldmVyIHVzaW5nIHRoaXMgcHVzaCBzZXJ2 aWNlIG1lY2hhbmlzbQ0KPiB3aXRob3V0IHRoZSBjb250ZW50IG9mIHRoZSBtZXNzYWdlIGJlaW5n IGFzIGRlZmluZWQgaW4gdGhlDQo+IHdlYnB1c2ggZW5jcnlwdGlvbiBkcmFmdCBhbmQgd2l0aG91 dCBmb2xsb3dpbmcgdGhlIFczQyBBUEk/DQoNCkFic29sdXRlbHkuIEFzIEkgd3JvdGUgaW4gYW4g ZWFybGllciByZXNwb25zZToNCg0KICBXZWJQdXNoIGlzIHNpbWlsYXIgdG8gV2ViU29ja2V0cyBp biB0aGUgc2Vuc2UgdGhhdCB0aGVyZSdzIGEgcmVsYXRlZCBBUEkgdW5kZXINCiAgZGV2ZWxvcG1l bnQgYXQgdGhlIFczQy4gSSdkIG5vdGUgdGhhdCBSRkM2NDU1IHVzZXMgYW4gaW5mb3JtYXRpdmUg cmVmZXJlbmNlDQogIHRvIHRoZSBXM0MgV1NBUEkuIFRoZSBleHBlY3RhdGlvbiBpcyB0aGF0IHRo ZXJlIHdpbGwgYmUgbXVsdGlwbGUgQVBJIHN1cmZhY2VzIGZvcg0KICBXZWJQdXNoIHNpbWlsYXIg dG8gdGhlIHNpdHVhdGlvbiBmb3IgV2ViU29ja2V0cy4NCg0KRm9yIGV4YW1wbGUsIG9uZSBjby1h dXRob3IgKEVsaW8pIGhhcyBzY2VuYXJpb3MgaW4gdGhlIElvVCBzcGFjZS4gTm8gYnJvd3NlciBp bnZvbHZlZC4NCg0KPiBJZiB3ZSBkbywgYW5kIGlmIHRoYXQgY29udGVudCBlbmRzIHVwIGluIGEg YnJvd3NlciBvciBvdGhlcg0KPiBhcHBsaWNhdGlvbiB0aGF0IG5lZWRzIHRoZSBTT1Agb3Igc2lt aWxhciwgdGhlbiBJJ20gc3RpbGwgbm90DQo+IHN1cmUgaXQncyBvayB0byBzYXkgbm90aGluZyBp biB0aGlzIGRyYWZ0Lg0KDQpJJ20gbm90IHN1Z2dlc3RpbmcgdGhhdCB0aGVyZSB3aWxsIGJlIG11 bHRpcGxlIEFQSShzKSBpbiB0aGUgYnJvd3Nlci1jYXNlLg0KVGhlIGV4cGVjdGF0aW9uIGlzIHRo ZSB3ZWIgZGV2ZWxvcGVycyB3aWxsIHVzZSB0aGUgVzNDIFB1c2ggQVBJIG9yDQphIGZyYW1ld29y ayBiYXNlZCBvbiB0aGUgUHVzaCBBUEkuIFNPUCBpcyB2ZXJ5IGJyb3dzZXItc3BlY2lmaWMgYW5k DQp0aGVyZeKAmXMgYWxyZWFkeSBhIHNvbHV0aW9uIGluIHRoaXMgY2FzZS4gDQoNCkNoZWVycywN Ci4uLkJyaWFuDQoNCg0KDQoNCg== From nobody Thu Oct 20 04:54:11 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 8D9271298CC; Thu, 20 Oct 2016 04:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.732 X-Spam-Level: X-Spam-Status: No, score=-4.732 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_MED=-2.3, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 4kcKkrR4ZdYi; Thu, 20 Oct 2016 04:54:07 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89527127ABE; Thu, 20 Oct 2016 04:54:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 00227BE56; Thu, 20 Oct 2016 12:54:04 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mj594XiXcV81; Thu, 20 Oct 2016 12:54:03 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 00C48BE51; Thu, 20 Oct 2016 12:54:02 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1476964443; bh=g3sZ6YK4sHQggnEV7rARsJxVksQZIKnavsAMRyp0gNE=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=S9JJJENiHn7BECkjYlx4RNib0wchZZe0MECCsi+Inh1Yc8f/si0z4A3zcJlvNmRsz WgzfVs9WIS2I1lfiKhirCUqFj49Q9Rq1eZI7RwBMZN1NCaqzsNlPfEJN6Di+sffAo5 7M9QDrzXkxS5X6zl2Euo4PtED+PdTx5c04jGLzRQ= To: Brian Raymor , Martin Thomson References: <5816348f-015a-beca-a5e6-3883fff02aab@cs.tcd.ie> <77e09f1f-04de-7819-92ea-9e4609cd853d@cs.tcd.ie> <56cca9c2-22a7-10bf-6d3a-cde3b82db9dc@cs.tcd.ie> <6fdc9c7d-e517-b142-45d6-9164d4a63053@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <821c63dd-e8cf-b6d5-8d4a-dfa2f4428aee@cs.tcd.ie> Date: Thu, 20 Oct 2016 12:54:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010809020603050306000506" Archived-At: Cc: "draft-ietf-webpush-protocol@ietf.org" , Shida Schubert , "webpush-chairs@ietf.org" , The IESG , "webpush@ietf.org" Subject: Re: [Webpush] Stephen Farrell's Discuss on draft-ietf-webpush-protocol-11: (with DISCUSS and COMMENT) 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, 20 Oct 2016 11:54:09 -0000 This is a cryptographically signed message in MIME format. --------------ms010809020603050306000506 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 19/10/16 00:21, Brian Raymor wrote: > SOP is very browser-specific and > there=E2=80=99s already a solution in this case.=20 That's a fair point. While I don't agree that being silent here is right, that's not a good enough reason to continue to block this. (*) So I'll clear now. Thanks for the discussion, Cheers, S. (*) I assume you do not want to add something, but if you did, then my suggestion would be along the lines of "Applications using this push mechanism are likely to need additional security mechanisms to produce an overall useful system, e.g. when the UA is a browser, then the SOP needs to be enforced, which can be achieved via [refs]. Other applications using this mechanism may require similar kinds of higher level security mechanism over and above what is defined here." --------------ms010809020603050306000506 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEwMjAx MTU0MDNaMC8GCSqGSIb3DQEJBDEiBCAuxfHDRGAMLfpy2y93j2bwozt0CPiJgaF7sGkSfmmx jDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBI8k/zVJcohOrRd09sT+PKMized69SaZoTaSpGjySlE5xQUyWikXi0 U/TAcy4L2XRZin2O2gZ9BU6y7C3DVrtWyUb3yqhwt5Nfc7dPcfIj93i+09dZ5uk6pUdV2TUe En7WPOVnCc53p4b/lLRuhk50VS99JQJA7bPBWRL7hoF6mijm3u8CwsxGYdi4eZUa5XGHs/YG E3S5EBWq0gRL0QCoi33kQWghwUDgTQ8krQ0OsHb5++4V4HeFImKDXE7LU18S75u363DWUz1H j2645YccHOKMzRcrTwkzdnZQc9MckRkNnybKkFd5EqHJSaz6X7LAq9hYDJldClUsxpEIx1vd AAAAAAAA --------------ms010809020603050306000506-- From nobody Thu Oct 20 04:55:06 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 86BD51298CC; Thu, 20 Oct 2016 04:55:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.35.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147696450050.18076.16320327022353456888.idtracker@ietfa.amsl.com> Date: Thu, 20 Oct 2016 04:55:00 -0700 Archived-At: Cc: draft-ietf-webpush-protocol@ietf.org, shida@ntt-at.com, webpush-chairs@ietf.org, webpush@ietf.org Subject: [Webpush] Stephen Farrell's No Objection on draft-ietf-webpush-protocol-11: (with COMMENT) 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, 20 Oct 2016 11:55:01 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-webpush-protocol-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-webpush-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the discussion of SOP etc. I found it useful to help me better understand webpush. From nobody Fri Oct 21 16:29:21 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 B49B1129993; Fri, 21 Oct 2016 16:21:22 -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.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147709208273.28214.12668968088431125684.idtracker@ietfa.amsl.com> Date: Fri, 21 Oct 2016 16:21:22 -0700 Archived-At: Cc: alissa@cooperw.in, webpush@ietf.org Subject: [Webpush] webpush - Requested session has been scheduled for IETF 97 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, 21 Oct 2016 23:21:26 -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 (1:30:00) Friday, Afternoon Session I 1150-1320 Room Name: Studio 2 size: 80 --------------------------------------------- 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): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: httpbis mmusic rtcweb tram tls Second Priority: stir modern Special Requests: --------------------------------------------------------- From nobody Fri Oct 21 21:12:49 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 8D0BC1293EB; Fri, 21 Oct 2016 21:12:46 -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.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147710956657.28222.12286711476736328475.idtracker@ietfa.amsl.com> Date: Fri, 21 Oct 2016 21:12:46 -0700 Archived-At: Cc: webpush@ietf.org Subject: [Webpush] I-D Action: draft-ietf-webpush-protocol-12.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: Sat, 22 Oct 2016 04:12:46 -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-12.txt Pages : 33 Date : 2016-10-21 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-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-webpush-protocol-12 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 Sat Oct 22 10:40:09 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 0812A129485; Sat, 22 Oct 2016 10:40:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147715800300.27905.16608260917271960933.idtracker@ietfa.amsl.com> Date: Sat, 22 Oct 2016 10:40:03 -0700 Archived-At: Cc: draft-ietf-webpush-protocol@ietf.org, shida@ntt-at.com, webpush-chairs@ietf.org, webpush@ietf.org Subject: [Webpush] Alexey Melnikov's Yes on draft-ietf-webpush-protocol-12: (with COMMENT) 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: Sat, 22 Oct 2016 17:40:03 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-webpush-protocol-12: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-webpush-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my DISCUSS points. I haven't checked whether you addressed all of my earlier comments: 1) 2) In 4.1: Can 429 be used when no subscription set is specified? (If yes, this should be mentioned in section 4). 3) 4) In general case it is not possible to achieve message reliability because a push server is allowed to expire messages after they were accepted for delivery due to overload. (Similarly for forced subscription expiration.) I don't think the document makes this clear in Section 7.4. 5) From nobody Sat Oct 22 12:43:44 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 A2D691294C6; Sat, 22 Oct 2016 12:43:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147716542262.27942.10233736804025627033.idtracker@ietfa.amsl.com> Date: Sat, 22 Oct 2016 12:43:42 -0700 Archived-At: Cc: shida@ntt-at.com, webpush-chairs@ietf.org, alissa@cooperw.in, webpush@ietf.org Subject: [Webpush] webpush - Cancelling a meeting request for IETF 97 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: Sat, 22 Oct 2016 19:43:43 -0000 A request to cancel a meeting session has just been submitted by . From nobody Sat Oct 22 12:44:38 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 96851129666 for ; Sat, 22 Oct 2016 12:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5] 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 f9WL8mPVjiV5 for ; Sat, 22 Oct 2016 12:44:35 -0700 (PDT) Received: from gateway22.websitewelcome.com (gateway22.websitewelcome.com [192.185.46.233]) (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 8E2CC1294C6 for ; Sat, 22 Oct 2016 12:44:35 -0700 (PDT) Received: from cm1.websitewelcome.com (cm.websitewelcome.com [192.185.0.102]) by gateway22.websitewelcome.com (Postfix) with ESMTP id 0E60BDA262D62 for ; Sat, 22 Oct 2016 14:44:35 -0500 (CDT) Received: from gator4135.hostgator.com ([192.185.4.147]) by cm1.websitewelcome.com with id yjka1t0053AKFgo01jkbTp; Sat, 22 Oct 2016 14:44:35 -0500 Received: from c-98-248-153-86.hsd1.ca.comcast.net ([98.248.153.86]:36214 helo=[10.0.96.3]) by gator4135.hostgator.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.87) (envelope-from ) id 1by2DZ-000XBr-Nx; Sat, 22 Oct 2016 14:44:33 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Shida Schubert In-Reply-To: <147709208273.28214.12668968088431125684.idtracker@ietfa.amsl.com> Date: Sat, 22 Oct 2016 12:44:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <30223ABC-04B1-4B5A-BEF9-C194BC8E92DF@ntt-at.com> References: <147709208273.28214.12668968088431125684.idtracker@ietfa.amsl.com> To: webpush@ietf.org 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: 98.248.153.86 X-Exim-ID: 1by2DZ-000XBr-Nx X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: c-98-248-153-86.hsd1.ca.comcast.net ([10.0.96.3]) [98.248.153.86]:36214 X-Source-Auth: dashi@agnada.com X-Email-Count: 3 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== Archived-At: Cc: Alissa Cooper , webpush-chairs@ietf.org Subject: Re: [Webpush] webpush - Requested session has been scheduled for IETF 97 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, 22 Oct 2016 19:44:36 -0000 I apologize for the confusion.=20 As there was no interests in holding a f2f discussions, I canceled the = following session.=20 Thanks!=20 Shida > On Oct 21, 2016, at 4:21 PM, IETF Secretariat wrote: >=20 > Dear Shida Schubert, >=20 > The session(s) that you have requested have been scheduled. > Below is the scheduled session information followed by > the original request.=20 >=20 > webpush Session 1 (1:30:00) > Friday, Afternoon Session I 1150-1320 > Room Name: Studio 2 size: 80 > --------------------------------------------- >=20 >=20 >=20 > Request Information: >=20 >=20 > --------------------------------------------------------- > Working Group Name: Web-Based Push Notifications > Area Name: Applications and Real-Time Area > Session Requester: Shida Schubert >=20 > Number of Sessions: 1 > Length of Session(s): 1.5 Hours > Number of Attendees: 50 > Conflicts to Avoid:=20 > First Priority: httpbis mmusic rtcweb tram tls > Second Priority: stir modern >=20 >=20 >=20 > Special Requests: >=20 > --------------------------------------------------------- >=20 > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush From nobody Sun Oct 23 16:54:29 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 86CBC129443; Sun, 23 Oct 2016 16:54:27 -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 gldL-R9ur4sK; Sun, 23 Oct 2016 16:54:26 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::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 E934F126CD8; Sun, 23 Oct 2016 16:54:25 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id n189so215552413qke.0; Sun, 23 Oct 2016 16:54:25 -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=W+oUfrkEfgn8548z0DXCooyJuGZmSEDO0t54nsn9Mg4=; b=q2ux+bzjUklNPI1/AjOGhYpb65U4E7tjfpcQfkaWfxbNbK9NvcKEFOgZ/0ND4JPC+4 0E1yCiEZL+UUDphZhsSqwDEUgp+ZDyfF0pTndm2IIUAtxkTdK0hGNQDNpf2M+fJBQIfo NTN2KQLSvyraBmR1p3p9RqHibx6+t8SDS9bl5kONeYm+SwJEoW4NgX4LJ/AdMQdiMgyr MIv0oCkNi69nvvLtGqn2jK8skv02SbbdBwfEiC9Uy9s8rN15L6GQ73HtWfc3oRJPQnVt N+dbBlaAJB6v27jW174N/Ih3R3Vi08N6fDXQ6MK9O7tR18TrumbPXd4xHt4rY9zYZBJg Ve8A== 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=W+oUfrkEfgn8548z0DXCooyJuGZmSEDO0t54nsn9Mg4=; b=LDSGwLHgwRgktBXThEb0vwqIYW0SO24sKBvEfFOxKDCok2k3opq5hZLZhChFdpqNDK 016MHdOHpbk4eHLqK8mK7665p8lmIHR30lUiYF71Bh57W4IEJzoKdv+WFzT3ixg4GRl/ YIlfjQCfAqmPxdeokYpaA1VszEANYsEIgTN9P34ykXbqgEU2HFgtmWA/AiJXfvaig4uX yWpjI6V25y2OJVPGTm4C/flm7q2ydb5yhF72JixDl75WWOgU+3PdTKSTCjpij2BhdLS1 HgCraXP+qK4ZMhcdm8252RpH4Ia4lLYAPuNbZ90cOdAjAWGE0N9cv8YMer5Yiix9uTyg Jqsg== X-Gm-Message-State: ABUngvcMM3VV03b1xB/lmAugWgy1T/iy/C3R5yj/ziTYOYwCgwdBsqFKyWtgCAJYXSzXqLd1XMdYZ+22JTciyw== X-Received: by 10.55.99.141 with SMTP id x135mr6617583qkb.147.1477266864977; Sun, 23 Oct 2016 16:54:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Sun, 23 Oct 2016 16:54:24 -0700 (PDT) In-Reply-To: <147715800300.27905.16608260917271960933.idtracker@ietfa.amsl.com> References: <147715800300.27905.16608260917271960933.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Mon, 24 Oct 2016 10:54:24 +1100 Message-ID: To: Alexey Melnikov Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-webpush-protocol@ietf.org, Shida Schubert , webpush-chairs@ietf.org, The IESG , "webpush@ietf.org" Subject: Re: [Webpush] Alexey Melnikov's Yes on draft-ietf-webpush-protocol-12: (with COMMENT) 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: Sun, 23 Oct 2016 23:54:27 -0000 On 23 October 2016 at 04:40, Alexey Melnikov wrote: > Can 429 be used when no subscription set is specified? (If yes, this > should be mentioned in section 4). The document says: A push service MAY return a 429 (Too Many Requests) status code [RFC6585] to reject requests which omit a subscription set. That's in Section 4.1: https://tools.ietf.org/html/draft-ietf-webpush-protocol-12#section-4.1 I believe that to be sufficient. > 4) In general case it is not possible to achieve message reliability > because a push server is allowed to expire messages after they were > accepted for delivery due to overload. (Similarly for forced subscription > expiration.) I don't think the document makes this clear in Section 7.4. I realize that I dropped this somehow. I made a PR, but then Brian corrected me. The push service is required to provide a negative acknowledgment if it drops a push message before the TTL period ends: The push service MAY cease to retry delivery of the message prior to its advertised expiration due to scenarios such as an unresponsive user agent or operational constraints. If the application has requested a delivery receipt, then the push service MUST return a 410 (Gone) response to the application server monitoring the receipt subscription. Section 6.2: https://tools.ietf.org/html/draft-ietf-webpush-protocol-12#section-6.2 From nobody Mon Oct 24 07:58: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 28B691297FE; Mon, 24 Oct 2016 07:58:48 -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.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147732112812.15475.17004068676440318403.idtracker@ietfa.amsl.com> Date: Mon, 24 Oct 2016 07:58:48 -0700 Archived-At: Cc: alissa@cooperw.in, draft-ietf-webpush-protocol@ietf.org, The IESG , Shida Schubert , webpush-chairs@ietf.org, webpush@ietf.org, rfc-editor@rfc-editor.org Subject: [Webpush] Protocol Action: 'Generic Event Delivery Using HTTP Push' to Proposed Standard (draft-ietf-webpush-protocol-12.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, 24 Oct 2016 14:58:48 -0000 The IESG has approved the following document: - 'Generic Event Delivery Using HTTP Push' (draft-ietf-webpush-protocol-12.txt) as Proposed Standard This document is the product of the Web-Based Push Notifications Working Group. The IESG contact persons are Alexey Melnikov, Ben Campbell and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-webpush-protocol/ Technical Summary This document defines a protocol which enables application server upon having consensus from the user agent (a subscription) to push an event-driven message called a push message (receipt of a call, a notification from a bank to authorize a transaction) through an intermediate service called push service that manages the subscription state and delivery of the push message. Working Group Summary and Document Quality The document has progressed and iterated very rapidly on github and through discussion on the mailing list since its inception in June of 2015 and has gone through two WGLCs and this version has had a rough consensus of the WG. Many of the contributors are those from major browser vendors (Google, Microsoft, Mozilla) but many from service provider and server software manufacturers have been contributing to stabilize the specification as well. This specification has been implemented and deployed in part and some deviation of this specification has been deployed for some time in production environment Personnel Shida Schubert is the shepherd. Alissa Cooper is the AD. From nobody Mon Oct 31 03:38: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 8EF5B129505 for ; Mon, 31 Oct 2016 03:38:22 -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 42Y_Mb2pBuJq for ; Mon, 31 Oct 2016 03:38:21 -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 E5B161294D4 for ; Mon, 31 Oct 2016 03:38:20 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id z190so155785416qkc.2 for ; Mon, 31 Oct 2016 03:38:20 -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=wSMcCo7kVt2zSyr3wPqbiNxyFkII2IYj3uyN8Qa70Sc=; b=RBlB0q+rs21NYWujrl2ibhGQvTr79uQCLkWhzjk3IDwiJLmJKW1wU+b39wjsXx+SaB YB0oLtteSK6cQfGb+K9klMLW6wH/cb1gqmbvaFr0F5L6uM8Q8+AJ+cpKPSKv/mVybuXU 3sKb6f/he0bc4Xp7zviavJEXOxGqeArRaKCr9v3pcCgt/QWQX6dFXYsuAVm8YD2mtVhb aIZshGsFOf/3LZPmvb9yYmoZ6So5zEyCQYwxwubSSy1hlL6/YPdqTGFLjDSx35rOz64e RjIjbtoiV3Qx2F2fAZrXm3WdcCMryFliI3+eg6rqmMCggIp2aAnSJCU0XclzRH6hwFBP 19fQ== 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=wSMcCo7kVt2zSyr3wPqbiNxyFkII2IYj3uyN8Qa70Sc=; b=f5dTTcbvoQnk4bF0EU4RclqsMBQqERw7oGR3ZtehfDYM/G2Ubb5FF52jRAtVQ3OwGi wRHaTJRPmcvU8DbmW3hRyOcZOHHiR0nLeCEfE9nQqnYrhfawSFxhYJPyDEKHWYmawSF3 uQvxeRXGbE4NAqms85gB0H8i9rC674md1fLeUVPD3EN//LUgngXZBe05eR6gBfRqVu9D WCeukMossMBLp9BjRbRWJO6nXOz7lnfHRH/DF1WJufJVXQxBCACK9GrhwNeD2pXHoj8T FzqVk3I3GBoqZRwT2pKZzrYpAcM8hvlsQ9n07EP1C5wz6WI/rfFdbCWxhyeK7k9MZBzN nzPA== X-Gm-Message-State: ABUngvcFYKd9R8TYxXgcms2/VHyvZzAE+bKdcRLA3EgFzqY0QuU7IhqGPITFQZdCw9G5YiS1ADj9BwuHQFLDWw== X-Received: by 10.55.74.1 with SMTP id x1mr17919223qka.316.1477910299705; Mon, 31 Oct 2016 03:38:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Mon, 31 Oct 2016 03:38:19 -0700 (PDT) From: Martin Thomson Date: Mon, 31 Oct 2016 21:38:19 +1100 Message-ID: To: "webpush@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Webpush] Major change to 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: Mon, 31 Oct 2016 10:38:22 -0000 Discussion in the HTTP working group has lead to some fairly substantial changes to the spec that we rely on. These are breaking changes. See the changes here: https://github.com/httpwg/http-extensions/pull/252 In short, several of the parameters that were in header fields are now in the body of the message and the Encryption header field is now gone. This completely messes with the use of that spec in Webpush. It's easy to detect which version is in use because the identifier has changed, and there are small gains to be had. The overall message size is now slightly smaller, and the key derivation is now slightly simpler. The specs also have fewer interdependencies as a result. I've put together a revision of the webpush-encryption draft. I've taken this opportunity to simplify things a little. You can see a preview in the editor's draft: https://webpush-wg.github.io/webpush-encryption/ I realize that this is a fairly big (and late) change. I remain optimistic that it will be the last. Feedback on the changes are positive so far [1]. I plan to submit this doc very soon, ahead of the draft submission deadline. I realize that's short notice, but I'm fully prepared to back out this change if necessary. --Martin [1] Costin suggested that we might also remove Crypto-Key. That is technically possible, though it's probably excessively kludgy, the DH key could be moved to the keyid field. I'm leery of that sort of optimization, but I'm willing to be convinced that this is a special enough case (I don't think that it is that special, but have at it). From nobody Mon Oct 31 14:40: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 47952129B36 for ; Mon, 31 Oct 2016 14:40:52 -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 PTbg58gkqB9G for ; Mon, 31 Oct 2016 14:40:50 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::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 169991299BC for ; Mon, 31 Oct 2016 14:40:50 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id i127so251566288oia.2 for ; Mon, 31 Oct 2016 14:40:50 -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=0JpmNHQ4vaeRy53ktMgos1Qw9wiD/YVzfe71ptroyF8=; b=VdKVUZnhZ++4+2/QIObc3tBRkliZ3w8tZZj4UM/ipRTY+VibGIR312btc8d4msp3zv lHtZjKrlBAUFUHw/dhkIwZzKtFBroUXiQOj4iEoatb5a63G7kJdZS/xn5+FmgoS47GWH W/WhQYc3S1LOEznNPL8T8IDPiEFsUIKEfVArFVbQ3cAJZjhkjhIq4poKdNWwLgR2rCmg caL9a9p/pFMLcqdpaYke5ghlsJGPTyGn2sqAiXqcN2jx3bvfqRdr8QEZeeD1fyRWheBH CzBQpO+eVpLoyFWnZ5zG1N31ToL3+2M9msJFjQ4qTRGhsBXaFxk6exXHbML9eA0WfJJ7 qNmA== 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=0JpmNHQ4vaeRy53ktMgos1Qw9wiD/YVzfe71ptroyF8=; b=NK3fHNmB2CCzh9rhiS7Y5teaMtSh/ImwsoqiJ0Gj3NUQuJTGJWTl7tOxOmM9W0tajr OxOUW6vVl9Q+fBdf5XHSg4i2rfUw9Zty/IpFLHzoSTh2+OvwIuAPQqrfPgDIPy+OHKgp 3GkaVdzeOC+/UGtmMDqrR2OxQycUCWFMQtsB324duOFguCURaZcBuvyYa0KnZgdz4baj Bape7pbRQ55hfdaiRexyhfWO6SPaDx6xtzKUiHpYPamhJsjf3voRNZk3ymdu3dec9aVY bpyuV8LGGTg/kCTadWkbglUoIdWek5FJp4ffjHj0cqmAxJyojnp6sCJHwf+n9sWWHvM8 a1dw== X-Gm-Message-State: ABUngve79jso7e3y6iRQ5zeL4u1hHES+5UByAPiGl1j61pkReNfL4hWGY4u3Q1AiIaB4QMhOIXbw+XRyxSiFOA== X-Received: by 10.107.28.136 with SMTP id c130mr21402053ioc.195.1477950047216; Mon, 31 Oct 2016 14:40:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Costin Manolache Date: Mon, 31 Oct 2016 21:40:36 +0000 Message-ID: To: Martin Thomson , "webpush@ietf.org" Content-Type: multipart/alternative; boundary=001a113fdec68f69c50540300ff5 Archived-At: Subject: Re: [Webpush] Major change to 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: Mon, 31 Oct 2016 21:40:53 -0000 --001a113fdec68f69c50540300ff5 Content-Type: text/plain; charset=UTF-8 I'm not suggesting removing the Crypto-Key as optimization - but for consistency. If we send the salt and the keyid in the binary payload, we should also include the dh key. In particular, it makes it much easier to send webpush binary messages with alternate transports - like Websocket or WiSH (https://tools.ietf.org/html/ draft-yoshino-wish-00 ) if push promises are not available. Technically having headers or binary prefix is equivalent for single message with push promises, or for the send API. But if the message has to be layered on a different transport - it gets tricky, with more complexity and chances of bugs. Costin On Mon, Oct 31, 2016 at 3:38 AM Martin Thomson wrote: Discussion in the HTTP working group has lead to some fairly substantial changes to the spec that we rely on. These are breaking changes. See the changes here: https://github.com/httpwg/http-extensions/pull/252 In short, several of the parameters that were in header fields are now in the body of the message and the Encryption header field is now gone. This completely messes with the use of that spec in Webpush. It's easy to detect which version is in use because the identifier has changed, and there are small gains to be had. The overall message size is now slightly smaller, and the key derivation is now slightly simpler. The specs also have fewer interdependencies as a result. I've put together a revision of the webpush-encryption draft. I've taken this opportunity to simplify things a little. You can see a preview in the editor's draft: https://webpush-wg.github.io/webpush-encryption/ I realize that this is a fairly big (and late) change. I remain optimistic that it will be the last. Feedback on the changes are positive so far [1]. I plan to submit this doc very soon, ahead of the draft submission deadline. I realize that's short notice, but I'm fully prepared to back out this change if necessary. --Martin [1] Costin suggested that we might also remove Crypto-Key. That is technically possible, though it's probably excessively kludgy, the DH key could be moved to the keyid field. I'm leery of that sort of optimization, but I'm willing to be convinced that this is a special enough case (I don't think that it is that special, but have at it). _______________________________________________ Webpush mailing list Webpush@ietf.org https://www.ietf.org/mailman/listinfo/webpush --001a113fdec68f69c50540300ff5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm not suggestin= g removing the Crypto-Key as optimization - but for consistency.=C2=A0
If we send the salt and the keyid in = the binary payload, we should also include the dh key.

In particular, it makes it much easi= er to send webpush binary messages with
a= lternate transports - like Websocket or WiSH (https://tools.ietf.org/html/draft-yoshino-wish-00)
if push promises are not available.
Technically having headers or binary prefix is equivalent= for single message with push=C2=A0
promi= ses, or for the send API. But if the message has to be layered on a differe= nt transport -=C2=A0
it gets tricky, with mor= e complexity and chances of bugs.=C2=A0

<= /div>


=
Costin
=C2=A0


On Mon, Oct 31, 2016 at 3:38 AM Martin Thomson <martin.thom= son@gmail.com> wrote:
Discussion in the HTTP working group has lead to so= me fairly
substantial changes to the spec that we rely on.=C2=A0 These are breaking changes.=C2=A0 See the changes here:
https://github.com/httpwg/http= -extensions/pull/252

In short, several of the parameters that were in header fields are now
in the body of the message and the Encryption header field is now
gone.

This completely messes with the use of that spec in Webpush.=C2=A0 It's=
easy to detect which version is in use because the identifier has
changed, and there are small gains to be had.=C2=A0 The overall message
size is now slightly smaller, and the key derivation is now slightly
simpler.=C2=A0 The specs also have fewer interdependencies as a result.

I've put together a revision of the webpush-encryption draft.=C2=A0 I&#= 39;ve
taken this opportunity to simplify things a little.=C2=A0 You can see a
preview in the editor's draft:

=C2=A0 https://webpush-wg.github= .io/webpush-encryption/

I realize that this is a fairly big (and late) change.=C2=A0 I remain
optimistic that it will be the last. Feedback on the changes are
positive so far [1].

I plan to submit this doc very soon, ahead of the draft submission
deadline.=C2=A0 I realize that's short notice, but I'm fully prepar= ed to
back out this change if necessary.

--Martin

[1] Costin suggested that we might also remove Crypto-Key.=C2=A0 That is technically possible, though it's probably excessively kludgy, the DH key could be moved to the keyid field.=C2=A0 I'm leery of that sort of<= br class=3D"gmail_msg"> optimization, but I'm willing to be convinced that this is a special enough case (I don't think that it is that special, but have at it).
_______________________________________________
Webpush mailing list
W= ebpush@ietf.org
https://www.ietf.org/mailman/listin= fo/webpush
--001a113fdec68f69c50540300ff5-- From nobody Mon Oct 31 15:47: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 29351127735 for ; Mon, 31 Oct 2016 15:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 rQwqQP4whtWW for ; Mon, 31 Oct 2016 15:47:45 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::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 74BD3127078 for ; Mon, 31 Oct 2016 15:47:45 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id 189so30187754pfz.3 for ; Mon, 31 Oct 2016 15:47:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=PGRvBvqbVpfCUd822eu3clOdAkzg8suO/5WIfmoNURA=; b=gGhVuxKF+aekc1JhtcI+eqRICvg7d54l0e+eQmF1ZFf6dpxusUtzvZ7G0e5Kbyqy5Z ofGPxdv2HymmwU182XuILWc7sF9uCzCi1u8qJIQsm/iRERJcqavD0Lek3UmLQ+qDa5n0 jv7+FpcTkaBQ9gUGm26+RqSKNj/pXf9CXGhd4= 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:content-transfer-encoding :content-language; bh=PGRvBvqbVpfCUd822eu3clOdAkzg8suO/5WIfmoNURA=; b=OILuzvmE0QEe7JxHCGqKF64EL7M4evanKTluhF8sKwqX1mZ3e+ySKtJEAv8xxjQ19F Ytx3JMIZjVn6tqgGmZ2xfG9yoMJfMPTBkK8va1VRaws+mhCGbIgXmE0/fvQSUknUNC5Y bgGVLXLs9SFlPNp5QzDHZWTWedS++dtbf3NBtEHUZQXh49YogL+eb0qPvEzr5nhjfZy/ xL5z7dzSm9DEDPXznikd8H6x28wm8kSGxN/aAHph1j0Y0yQJPF1PXqLa0v7sW/tmDAr4 KlNvjfdrt/I/ELSvVtG2UQjKysT4P7fNmelJ2bAqGCvrL0tuD3uGnIErliE1BBjBgoeP j+sQ== X-Gm-Message-State: ABUngvfOGh076UC6KV3Wm+Eml0XHevMJgRz+kom6kYKeRvEd6UziJzX0Oy9G4jr4Uu2uADIx X-Received: by 10.98.88.5 with SMTP id m5mr54178286pfb.9.1477954064549; Mon, 31 Oct 2016 15:47:44 -0700 (PDT) Received: from ?IPv6:2620:101:80fc:224:e061:e86a:d62e:d3a4? ([2620:101:80fc:224:e061:e86a:d62e:d3a4]) by smtp.gmail.com with ESMTPSA id r74sm24011941pfj.11.2016.10.31.15.47.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Oct 2016 15:47:43 -0700 (PDT) To: webpush@ietf.org References: From: jr conlin Message-ID: Date: Mon, 31 Oct 2016 15:47:43 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:51.0) Gecko/20100101 Thunderbird/51.0a2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Webpush] Major change to 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: Mon, 31 Oct 2016 22:47:47 -0000 Perhaps I'm just confused by the various PRs and comments, but if I may, i'd like to make sure I'm very clear on what the change is: The crux of the change is: 1) Encrypted content would be identified as "aes128gcm", which should not be confused with the now, long obsolete "aesgcm128". 2) salt, rs, and key_id are now prefixed to the encrypted content as: `salt(16)|rs(4)|id_len(1)|key_id(id_len)|encrypted_content` 3) The content encoding key (CEK) is set to ``` HMAC-SHA-256( HMAC-SHA-256(salt, key[key_id].secret), "Content-Encoding: aes128gcm\x00\x01") # from 2.2 of http://httpwg.org/http-extensions/encryption-preview.html ``` The majority case will be that `key_id` is not defined (or is ''), in which case, we'd use the locally derived key. 4) There's no longer a need for "context" to be appended to the key info and nonce info, although the Content-Encoding for the new content type will use the now obsolete "aesgcm128" https://github.com/martinthomson/encrypted-content-encoding/pull/28/files#diff-6ee19a23c153fa68b2910aeb69bde1ddR213 5) The DH secret is now derived from running an HMAC-SHA-256 over ```'WebPush: info\x00' + receiverPublicKey + senderPublicKey``` Is that correct? Am I missing something? On 10/31/2016 3:38 AM, Martin Thomson wrote: > Discussion in the HTTP working group has lead to some fairly > substantial changes to the spec that we rely on. These are breaking > changes. See the changes here: > https://github.com/httpwg/http-extensions/pull/252 > > In short, several of the parameters that were in header fields are now > in the body of the message and the Encryption header field is now > gone. > > This completely messes with the use of that spec in Webpush. It's > easy to detect which version is in use because the identifier has > changed, and there are small gains to be had. The overall message > size is now slightly smaller, and the key derivation is now slightly > simpler. The specs also have fewer interdependencies as a result. > > I've put together a revision of the webpush-encryption draft. I've > taken this opportunity to simplify things a little. You can see a > preview in the editor's draft: > > https://webpush-wg.github.io/webpush-encryption/ > > I realize that this is a fairly big (and late) change. I remain > optimistic that it will be the last. Feedback on the changes are > positive so far [1]. > > I plan to submit this doc very soon, ahead of the draft submission > deadline. I realize that's short notice, but I'm fully prepared to > back out this change if necessary. > > --Martin > > [1] Costin suggested that we might also remove Crypto-Key. That is > technically possible, though it's probably excessively kludgy, the DH > key could be moved to the keyid field. I'm leery of that sort of > optimization, but I'm willing to be convinced that this is a special > enough case (I don't think that it is that special, but have at it). > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush From nobody Mon Oct 31 16:05: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 B0E741296C0 for ; Mon, 31 Oct 2016 16:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 GX1QfWmYZ7Rp for ; Mon, 31 Oct 2016 16:04:58 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::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 8AD9212948C for ; Mon, 31 Oct 2016 16:04:58 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id v138so90009509qka.0 for ; Mon, 31 Oct 2016 16:04:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1hVEKeqGfRwKWN1FMxRvPpoKr71Sr6x4buK4UfL1wpA=; b=KsF+CQszYDPVhLAfBUe7Efy4h+uWVjaW49149qe2LunwsuMJR/JRtit1/i+ye3UNCM 7jrksiHeLSCTHAxbwpPBl4L794WcXc1JQqh7y4FqqUZHet3/hcsP3xv2RHVRkH57PhDg H6GjQhdxfnk/f8UwiFBdLCchvfEyCywcXbikW/lXTnvgWG02Z5hm9ZDvLVhaOSZ83xWv z8RzUMgdCJCYUnGGneVgvNXFo6pKYL8oD5hS+fz+xn84vfcLhT6DfbEpX2dbt8XsHNGw T4Kbd0ISdeiA6LqM1pflhO7VyE+2zT7VpeGaNhM99jmIjS0ksq109J6AhvG2OOtHt5rM TAEg== 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=1hVEKeqGfRwKWN1FMxRvPpoKr71Sr6x4buK4UfL1wpA=; b=JdRcs6NU4QoXeIANIutK0UHIaYVuZtLs+gz7uzBDRXGeTdiGMhNSZDDi97yGosWRb9 0QshFjPcSn2IUF6wSE83NTx0dd4046PWW87dIK+zLZqcpGF0jOG4+Xn+pQx2fXGhQgl6 4V2iG+IQ5kxuGHw8GBwpXRnBG4jd/+bOVpwE87RxC19A+Cp8mE3MRdqsHa9Z1T+GjIqm mgeY3rA+37GqplNzY60R3w82015miC9IBOPlTYJmtrL1dWoHsMh+hmLfNM+6tno2yyPP rggpdQnsSK+YP8rJOZuRcxVFG0ywm3yc4q1/FYPc94hfAbj9UJeWvEEfC8BN8YRDD9ro wRRg== X-Gm-Message-State: ABUngvfT2APjRklJhQrP/uClD6v63IzrGvG5s+OE7h1skTN7yX0UE9H/eUUbCT6za906BIAZVhxwKk4slHt9xg== X-Received: by 10.233.235.72 with SMTP id b69mr725612qkg.144.1477955097659; Mon, 31 Oct 2016 16:04:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Mon, 31 Oct 2016 16:04:57 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Tue, 1 Nov 2016 10:04:57 +1100 Message-ID: To: jr conlin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Major change to 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: Mon, 31 Oct 2016 23:05:01 -0000 That is (to the best of my limited ability to check) 100% correct. On 1 November 2016 at 09:47, jr conlin wrote: > Perhaps I'm just confused by the various PRs and comments, but if I may, > i'd like to make sure I'm very clear on what the change is: > > The crux of the change is: > 1) Encrypted content would be identified as "aes128gcm", which should > not be confused with the now, long obsolete "aesgcm128". > > 2) salt, rs, and key_id are now prefixed to the encrypted content as: > `salt(16)|rs(4)|id_len(1)|key_id(id_len)|encrypted_content` > > 3) The content encoding key (CEK) is set to > ``` > HMAC-SHA-256( > HMAC-SHA-256(salt, key[key_id].secret), > "Content-Encoding: aes128gcm\x00\x01") # from 2.2 of > http://httpwg.org/http-extensions/encryption-preview.html > ``` > The majority case will be that `key_id` is not defined (or is ''), in > which case, we'd use the locally derived key. > > 4) There's no longer a need for "context" to be appended to the key info > and nonce info, although the Content-Encoding for the new content type > will use the now obsolete "aesgcm128" > https://github.com/martinthomson/encrypted-content-encoding/pull/28/files#diff-6ee19a23c153fa68b2910aeb69bde1ddR213 > > 5) The DH secret is now derived from running an HMAC-SHA-256 over > ```'WebPush: info\x00' + receiverPublicKey + senderPublicKey``` > > Is that correct? Am I missing something? > > On 10/31/2016 3:38 AM, Martin Thomson wrote: >> Discussion in the HTTP working group has lead to some fairly >> substantial changes to the spec that we rely on. These are breaking >> changes. See the changes here: >> https://github.com/httpwg/http-extensions/pull/252 >> >> In short, several of the parameters that were in header fields are now >> in the body of the message and the Encryption header field is now >> gone. >> >> This completely messes with the use of that spec in Webpush. It's >> easy to detect which version is in use because the identifier has >> changed, and there are small gains to be had. The overall message >> size is now slightly smaller, and the key derivation is now slightly >> simpler. The specs also have fewer interdependencies as a result. >> >> I've put together a revision of the webpush-encryption draft. I've >> taken this opportunity to simplify things a little. You can see a >> preview in the editor's draft: >> >> https://webpush-wg.github.io/webpush-encryption/ >> >> I realize that this is a fairly big (and late) change. I remain >> optimistic that it will be the last. Feedback on the changes are >> positive so far [1]. >> >> I plan to submit this doc very soon, ahead of the draft submission >> deadline. I realize that's short notice, but I'm fully prepared to >> back out this change if necessary. >> >> --Martin >> >> [1] Costin suggested that we might also remove Crypto-Key. That is >> technically possible, though it's probably excessively kludgy, the DH >> key could be moved to the keyid field. I'm leery of that sort of >> optimization, but I'm willing to be convinced that this is a special >> enough case (I don't think that it is that special, but have at it). >> >> _______________________________________________ >> Webpush mailing list >> Webpush@ietf.org >> https://www.ietf.org/mailman/listinfo/webpush > > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush From nobody Mon Oct 31 16:07: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 347D0129BC7 for ; Mon, 31 Oct 2016 16:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 dElVxBkxKjG2 for ; Mon, 31 Oct 2016 16:07:46 -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 4917E129BBC for ; Mon, 31 Oct 2016 16:07:46 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id n85so83774866pfi.1 for ; Mon, 31 Oct 2016 16:07:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=n7aiR43AqkZCT92HhNFXPqoTErXnba9iHCMZ77q9EOc=; b=BW3dLHvntal2T+QTA5sqtol6SwCS1S+D8pK62Qt19M8V9hry3vxo4EKpNKy7g2Jf9c q5Kl9coIKa0WlBWpurMw6IVN6ew4V+Cd5nYc8/hMrAPdFUHuwGTaMheyRIahp08vaGc/ d0t2mp802BpKIBvm6P0dx1eaKNsurF4QxgIlc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=n7aiR43AqkZCT92HhNFXPqoTErXnba9iHCMZ77q9EOc=; b=Yxiz7C3tO+YqUHL/tHlESRNDk+jbuJ54idlYdR3PWpjP796XhiGtLXGv+1JhveYHB2 QBCAGYBAI0uO56vzrBXTHa2uA2RAEF2jgPnoJqRmTQq55yRP5dE1oheAcCIE8hXOHSiJ uxE6voXy9i3UxfappE5mZLQ/6A/suYzn3j8o2GDMBoY4J638H0lygevFL/u4wFw4SOTe GKsnX+PYJXDKhpSh04D2plK2DbcyM1hn2uv4MailvwJTF4nuLwlXgn2gGqrxzkjTaO1X MF1IVy2Kg/ojnad3H6ROStnRe11PAAp0vKP+W7xDSUQ6T1dMwqBsGA0n2l+bw6Uh1s/y IrbQ== X-Gm-Message-State: ABUngvfoY1QOVbOZWjhprD2i5LS7aHhOJ8f8gbzoop29pYcRN78ycwr6hYn+RFEWVEeF68Li X-Received: by 10.98.154.10 with SMTP id o10mr53699582pfe.79.1477955265834; Mon, 31 Oct 2016 16:07:45 -0700 (PDT) Received: from ?IPv6:2620:101:80fc:224:e061:e86a:d62e:d3a4? ([2620:101:80fc:224:e061:e86a:d62e:d3a4]) by smtp.gmail.com with ESMTPSA id r10sm24249paw.2.2016.10.31.16.07.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Oct 2016 16:07:44 -0700 (PDT) To: Martin Thomson References: From: jr conlin Message-ID: Date: Mon, 31 Oct 2016 16:07:44 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:51.0) Gecko/20100101 Thunderbird/51.0a2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Major change to 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: Mon, 31 Oct 2016 23:07:49 -0000 One small comment, then? Can we change the transmitted Content-Encoding type to match the new Content-type of "aes128gcm" instead of the long abandoned "aesgcm128"? (See point #4) I'm betting that's going to be a pain point for a number of folks. On 10/31/2016 4:04 PM, Martin Thomson wrote: > That is (to the best of my limited ability to check) 100% correct. > > On 1 November 2016 at 09:47, jr conlin wrote: >> Perhaps I'm just confused by the various PRs and comments, but if I may, >> i'd like to make sure I'm very clear on what the change is: >> >> The crux of the change is: >> 1) Encrypted content would be identified as "aes128gcm", which should >> not be confused with the now, long obsolete "aesgcm128". >> >> 2) salt, rs, and key_id are now prefixed to the encrypted content as: >> `salt(16)|rs(4)|id_len(1)|key_id(id_len)|encrypted_content` >> >> 3) The content encoding key (CEK) is set to >> ``` >> HMAC-SHA-256( >> HMAC-SHA-256(salt, key[key_id].secret), >> "Content-Encoding: aes128gcm\x00\x01") # from 2.2 of >> http://httpwg.org/http-extensions/encryption-preview.html >> ``` >> The majority case will be that `key_id` is not defined (or is ''), in >> which case, we'd use the locally derived key. >> >> 4) There's no longer a need for "context" to be appended to the key info >> and nonce info, although the Content-Encoding for the new content type >> will use the now obsolete "aesgcm128" >> https://github.com/martinthomson/encrypted-content-encoding/pull/28/files#diff-6ee19a23c153fa68b2910aeb69bde1ddR213 >> >> 5) The DH secret is now derived from running an HMAC-SHA-256 over >> ```'WebPush: info\x00' + receiverPublicKey + senderPublicKey``` >> >> Is that correct? Am I missing something? >> >> On 10/31/2016 3:38 AM, Martin Thomson wrote: >>> Discussion in the HTTP working group has lead to some fairly >>> substantial changes to the spec that we rely on. These are breaking >>> changes. See the changes here: >>> https://github.com/httpwg/http-extensions/pull/252 >>> >>> In short, several of the parameters that were in header fields are now >>> in the body of the message and the Encryption header field is now >>> gone. >>> >>> This completely messes with the use of that spec in Webpush. It's >>> easy to detect which version is in use because the identifier has >>> changed, and there are small gains to be had. The overall message >>> size is now slightly smaller, and the key derivation is now slightly >>> simpler. The specs also have fewer interdependencies as a result. >>> >>> I've put together a revision of the webpush-encryption draft. I've >>> taken this opportunity to simplify things a little. You can see a >>> preview in the editor's draft: >>> >>> https://webpush-wg.github.io/webpush-encryption/ >>> >>> I realize that this is a fairly big (and late) change. I remain >>> optimistic that it will be the last. Feedback on the changes are >>> positive so far [1]. >>> >>> I plan to submit this doc very soon, ahead of the draft submission >>> deadline. I realize that's short notice, but I'm fully prepared to >>> back out this change if necessary. >>> >>> --Martin >>> >>> [1] Costin suggested that we might also remove Crypto-Key. That is >>> technically possible, though it's probably excessively kludgy, the DH >>> key could be moved to the keyid field. I'm leery of that sort of >>> optimization, but I'm willing to be convinced that this is a special >>> enough case (I don't think that it is that special, but have at it). >>> >>> _______________________________________________ >>> Webpush mailing list >>> Webpush@ietf.org >>> https://www.ietf.org/mailman/listinfo/webpush >> >> _______________________________________________ >> Webpush mailing list >> Webpush@ietf.org >> https://www.ietf.org/mailman/listinfo/webpush From nobody Mon Oct 31 16:19: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 13571129438 for ; Mon, 31 Oct 2016 16:19:28 -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 aHDZQoIeVj4D for ; Mon, 31 Oct 2016 16:19:22 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03ECC129410 for ; Mon, 31 Oct 2016 16:19:22 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id v138so90317524qka.0 for ; Mon, 31 Oct 2016 16:19:21 -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=qt3OedJ04mRieqS3oKps04Dt8tHtlG9O5GbyMKS5F0c=; b=VPMI/kza/JhUDCXzpt57I6FxGu2s/oF6Vrq3mhk9+cQsmn6vFpKhaekm1l+B9ab59E ksCsk+TtzPr7fTynikMuIzF9rco2KPn2GLDJHfB8OFZqpf9V3kisk9j5goeZO+C2acWZ 4tl1IGUFFQlC96XrWKKPXigejFdIBMNZu6B406ex0RVwK6wHIXlLKQdt2vspd3Oca6Ti fgH/XfoJKCOvuD7+Qz78QXlFPGSsf2XKkI95oX+NUYTSmRBXHufIMlUBbvv41wYrti+/ CQ21PVh4qpK2HdW6JfeMRs4z1iy86TDTNhoZILcCD53Rfkv44e66ukzYhh6mz+BnvXot 0N7w== 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=qt3OedJ04mRieqS3oKps04Dt8tHtlG9O5GbyMKS5F0c=; b=OoKnRcXJN9PA66kopsNirQhlKOMqLTqg35uXHScJRqNdtSGVSAgKYQejQ1qz5lC1Do 9wdaHHh2dnrnQbHLHoE58ocVQqZ+6Bd/aQrvgvVgk3uYHvkPTvcpU9r3KOWTLy9cV5p+ BjNAEehAZ7x7VmJ9v2RpxVdyzdHISoVTcbJyqkeIQLaqgwClcoVg9Tf+JtKkfo2lTaZD 4qqjrYdrrcrFI1s8/57FsGXFRQ77lx47aPqWqpSFsR0GwcOr6kgZknNOiaVwtHNDYrDg EBvZVpQK57KZmZWADWZT/QDu88jm6wHTFmFbbADyMC8ZBQ9Nvm4n/PFtxCszBr50fNua y+uw== X-Gm-Message-State: ABUngvdL0GUspxR8idv8h0rAHH7jkXEcEcDracyeXTLsFzV06aNx0B2uH3EqOhWfC7xOMV9KvJkgZjxXjRTLOA== X-Received: by 10.55.184.68 with SMTP id i65mr320609qkf.5.1477955961191; Mon, 31 Oct 2016 16:19:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Mon, 31 Oct 2016 16:19:20 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Tue, 1 Nov 2016 10:19:20 +1100 Message-ID: To: jr conlin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Major change to 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: Mon, 31 Oct 2016 23:19:28 -0000 On 1 November 2016 at 10:07, jr conlin wrote: > One small comment, then? Can we change the transmitted Content-Encoding > type to match the new Content-type of "aes128gcm" instead of the long > abandoned "aesgcm128"? (See point #4) Ouch, that's going to hurt. I'll have to redo the examples :*( 40 minutes until the deadline, go! From nobody Mon Oct 31 16:31: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 5226D127078 for ; Mon, 31 Oct 2016 16:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 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.497, 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 0LPmGjOOYSSD for ; Mon, 31 Oct 2016 16:31:30 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 09511129415 for ; Mon, 31 Oct 2016 16:31:30 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id n67so257510223wme.1 for ; Mon, 31 Oct 2016 16:31:29 -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=4OgabyoRCTvvLY24foDt/o+PFSRJ69VYkrBDuQeLISc=; b=U5N71dKwEQDIDITeVU/fNEzoTJMOvZYLaiEUwnRBAjiBiZDGHBs5tqH50ddXvg2OwL RLYBGEhlkBw1Mvs585tvplKrgM5/YrBK1zLHN303IZLKWqZVrLGsYh4cdeMEu+ZYGSaF 7Zr2QfTfWTjiVcn1AymbxlDH1cWoumRdNLKc+hqCosGl8unzqeuwrxFX2pypXdQRTbOW mu//8qUneteIcDm9p6ZFXk640ugN1vFgpZz5Lv+FSvG5gWN0hzTwvmf46PRH51GgfEq+ HDnWrQM4PWIbWcBGsPIWo4L6A/ogEOgwSu7aCJVETKPk/m6LQgQVxn76sMiHB302EwWM /JXQ== 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=4OgabyoRCTvvLY24foDt/o+PFSRJ69VYkrBDuQeLISc=; b=A2iZMK+LJRsPjYhupdp/J+fMiRiYyOR+EpmvhULvvT4CLoG+R5oW5rhlQ4ylaCBYhX Jvl+iSGweYTUghLbK+xLtWN8C7RHNWZ3JEppMNiwt/wpvDDUicto3Y4CW9nbDjb8wVtc AOnnX0gBvFHu9uBJDztKuAQmRzRFAO+do8b9CQubpkSyl5muhZ7wGWCf01IWrJwsnJsI xOo1anD0rydGUvOZpTRhJdJtyNPbsj21kfGwGN+tveB8YhMJzk5MKILJV64MMDlS56fF D+W8EVbqh7cgvkdlYFdjZjXYxbZrbX8caJPoaDXOeFur2a3w/rqJWv9ePZobX+/ffloU 7Fdg== X-Gm-Message-State: ABUngvdDNFFx6MxZ8D6AAwCCCuerLJWOMe7myvtKxIx83fbF7nRSx/BwLr0WpApOHHyqApbNb0zlwIrJus/QoX96 X-Received: by 10.28.158.148 with SMTP id h142mr8578420wme.59.1477956688446; Mon, 31 Oct 2016 16:31:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.176.131 with HTTP; Mon, 31 Oct 2016 16:31:27 -0700 (PDT) In-Reply-To: References: From: Peter Beverloo Date: Mon, 31 Oct 2016 23:31:27 +0000 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a114b360868e90f0540319b14 Archived-At: Cc: jr conlin , "webpush@ietf.org" Subject: Re: [Webpush] Major change to 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: Mon, 31 Oct 2016 23:31:32 -0000 --001a114b360868e90f0540319b14 Content-Type: text/plain; charset=UTF-8 Hi Martin, Thanks for the update and the proposal! I've reviewed these today, and have minor some points of feedback. I'll deliberately avoid the topics of interoperability and upgrade cost here. First of all, this indeed vastly improves layering between the drafts. I very much like how webpush-encryption is now built on top of encryption- encoding as opposed to being some sort of fork. >> A push message MUST include a zero length keyid parameter in the >> content coding header. This allows implementations to ignore the first >> 21 octets of a push message. I don't think this is right. The `salt` and the `rs` must still be known, and those are included in the header. >> A push service is not required to support more than 4096 octets of >> payload body (see Section 7.2 of [I-D.ietf-webpush-protocol]), which >> equates to at most 4059 octets of cleartext. I think this forgot about the padding -- 4096 - 16 (auth) - 2 (padding length) - 21 (header w/o keyid) = 4,057 May also want to s/cleartext/plaintext/ for consistency with encryption- encoding. >> An Application Server MUST include exactly one aes128gcm content >> coding, and at most one entry in the Crypto-Key field. This allows the >> keyid parameter to be omitted. This means the draft is incompatible with VAPID again. It must have at most one Crypto-Key entry that has a `dh` value. I haven't yet been able to validate the examples in the draft, but it sounds like you're changing these anyway per jr's feedback (+1 to that). Thanks, Peter On Mon, Oct 31, 2016 at 11:19 PM, Martin Thomson wrote: > On 1 November 2016 at 10:07, jr conlin wrote: > > One small comment, then? Can we change the transmitted Content-Encoding > > type to match the new Content-type of "aes128gcm" instead of the long > > abandoned "aesgcm128"? (See point #4) > > Ouch, that's going to hurt. I'll have to redo the examples :*( 40 > minutes until the deadline, go! > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > --001a114b360868e90f0540319b14 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Martin,

Thanks for the up= date and the proposal!

I've reviewed these tod= ay, and have minor some points of feedback. I'll
deliberately= avoid the topics of interoperability and upgrade cost here.

=
First of all, this indeed vastly improves layering between the d= rafts. I
very much like how webpush-encryption is now built on to= p of encryption-
encoding as opposed to being some sort of fork.<= /div>

>> A push message MUST include a zero length= keyid parameter in the
>> content coding header. This allo= ws implementations to ignore the first
>> 21 octets of a pu= sh message.

I don't think this is right. The `= salt` and the `rs` must still be known,
and those are included in= the header.

>> A push service is not requir= ed to support more than 4096 octets of
>> payload body (see= Section 7.2 of [I-D.ietf-webpush-protocol]), which
>> equa= tes to at most 4059 octets of cleartext.

I think t= his forgot about the padding --

=C2=A0 4096 - 16 (= auth) - 2 (padding length) - 21 (header w/o keyid) =3D 4,057

=
May also want to s/cleartext/plaintext/ for consistency with enc= ryption-
encoding.

>> An Applicati= on Server MUST include exactly one aes128gcm content
>> cod= ing, and at most one entry in the Crypto-Key field. This allows the
>> keyid parameter to be omitted.

This me= ans the draft is incompatible with VAPID again. It must have at
m= ost one Crypto-Key entry that has a `dh` value.

I = haven't yet been able to validate the examples in the draft, but it
sounds like you're changing these anyway per jr's feedback (= +1 to that).

Thanks,
Peter

On M= on, Oct 31, 2016 at 11:19 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:
On 1 November 2016 at 10:07, jr conlin <jconlin@mozilla.com> wrote:
> One small comment, then? Can we change the transmitted Content-Encodin= g
> type to match the new Content-type of "aes128gcm" instead of= the long
> abandoned "aesgcm128"? (See point #4)

Ouch, that's going to hurt.=C2=A0 I'll have to redo the exam= ples :*(=C2=A0 40
minutes until the deadline, go!

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

--001a114b360868e90f0540319b14-- From nobody Mon Oct 31 16:39: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 ABB7B127078 for ; Mon, 31 Oct 2016 16:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 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.497, 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 7WLYk7tSnETO for ; Mon, 31 Oct 2016 16:39:13 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c: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 04308127077 for ; Mon, 31 Oct 2016 16:39:12 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id t79so78862873wmt.0 for ; Mon, 31 Oct 2016 16:39:12 -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=PeE9WI2moDDL/BN5lPReM4NJGUUuIXZWln6AdJOgYv4=; b=SY/zmfhV3wZCvOBiSulmkSszGPeXYXICq4r6fq0OGcsGkaKY5Sd2fmB0PxBdEh7eo7 RwWXGb4ue03BFfu2PdX8v7qKLBtsq92Dz2dfk2PIMIl1EEepMoSD2glVGzCj/G3GiCtQ 8gnxm291VClgF/w/uxUkbN9laZI7TXXvHCqrv37uYLHpQfx4jDOwy2Cw7WZ2JFUoxENL GqMK80Bncnr2CR1zDj13oGaRaubSrk8Mn/ZBeOUYbMHOHvR+Yc3fa+SVpkTUDFx9B6+V jyKr2o2rvTvsCYkBscZLw4LBFtN0wroWW0te8nAqnjtZVxlhgOOxAr0movz37p20U5gy N1jw== 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=PeE9WI2moDDL/BN5lPReM4NJGUUuIXZWln6AdJOgYv4=; b=Ts0ui/+SM6OoJZQt0n8F0Nl7bcsSO0sQyxudJmidGRa1mImZjZXdlYkD1vFLhkeSqa n4eJmSCADw6HxcY/c9c58BWHoeU4hNPvlAQsoS4YaknoRqsCsqfaXmCMnMnPWr+S12/t b3yVCFaR+Ys3dwNrOgEIw9EJ7ZdGU2zld3uwCiEdG/O9HubKPcJouxxmXRshT8jtf5sl RyHHMtBwQFNbnOQ2HtHhnC5eePuA+GBCU+8oX37ttngjhvTB+HHQ8LyuhWsaADlGkWkL 23wz059A09zlxMw15i7zsgwzoDdsmEF7R+pY/ap5flLsoZN8l9hVt9ye/NgQ/71XtRu5 /YtA== X-Gm-Message-State: ABUngveaDstIxIKJbIVFxPCiMRlafimHPFAPOL1o5Ez8Lb8Laikx+tTbhFNfdli75uTNqqw6BzqhB/uaSJWluJIT X-Received: by 10.28.27.2 with SMTP id b2mr9153984wmb.59.1477957151361; Mon, 31 Oct 2016 16:39:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.176.131 with HTTP; Mon, 31 Oct 2016 16:39:10 -0700 (PDT) In-Reply-To: References: From: Peter Beverloo Date: Mon, 31 Oct 2016 23:39:10 +0000 Message-ID: To: jr conlin Content-Type: multipart/alternative; boundary=001a114b4210007c91054031b7d0 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Major change to 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: Mon, 31 Oct 2016 23:39:16 -0000 --001a114b4210007c91054031b7d0 Content-Type: text/plain; charset=UTF-8 Hi jr, Your understanding matches mine too. On Mon, Oct 31, 2016 at 10:47 PM, jr conlin wrote: > Perhaps I'm just confused by the various PRs and comments, but if I may, > i'd like to make sure I'm very clear on what the change is: > > The crux of the change is: > 1) Encrypted content would be identified as "aes128gcm", which should > not be confused with the now, long obsolete "aesgcm128". > > 2) salt, rs, and key_id are now prefixed to the encrypted content as: > `salt(16)|rs(4)|id_len(1)|key_id(id_len)|encrypted_content` > > 3) The content encoding key (CEK) is set to > ``` > HMAC-SHA-256( > HMAC-SHA-256(salt, key[key_id].secret), > "Content-Encoding: aes128gcm\x00\x01") # from 2.2 of > http://httpwg.org/http-extensions/encryption-preview.html > ``` > Yes, if key[key_id].secret contains the IKM that has already seen the HMAC with the "WebPush: info" info (the context replacement). PRK_key = HMAC-SHA-256(auth_secret, ecdh_secret) key_info = "WebPush: info" || 0x00 || ua_public || as_public IKM = HMAC-SHA-256(PRK_cek, key_info || 0x01) (So it's not just the shared ECDH secret.) The majority case will be that `key_id` is not defined (or is ''), in > which case, we'd use the locally derived key. > To be clear, section 4 of webpush-encryption mandates that the `id` field in the header is the empty string. Thanks, Peter > > 4) There's no longer a need for "context" to be appended to the key info > and nonce info, although the Content-Encoding for the new content type > will use the now obsolete "aesgcm128" > https://github.com/martinthomson/encrypted-content-encoding/pull/28/ > files#diff-6ee19a23c153fa68b2910aeb69bde1ddR213 > > 5) The DH secret is now derived from running an HMAC-SHA-256 over > ```'WebPush: info\x00' + receiverPublicKey + senderPublicKey``` > > Is that correct? Am I missing something? > > On 10/31/2016 3:38 AM, Martin Thomson wrote: > > Discussion in the HTTP working group has lead to some fairly > > substantial changes to the spec that we rely on. These are breaking > > changes. See the changes here: > > https://github.com/httpwg/http-extensions/pull/252 > > > > In short, several of the parameters that were in header fields are now > > in the body of the message and the Encryption header field is now > > gone. > > > > This completely messes with the use of that spec in Webpush. It's > > easy to detect which version is in use because the identifier has > > changed, and there are small gains to be had. The overall message > > size is now slightly smaller, and the key derivation is now slightly > > simpler. The specs also have fewer interdependencies as a result. > > > > I've put together a revision of the webpush-encryption draft. I've > > taken this opportunity to simplify things a little. You can see a > > preview in the editor's draft: > > > > https://webpush-wg.github.io/webpush-encryption/ > > > > I realize that this is a fairly big (and late) change. I remain > > optimistic that it will be the last. Feedback on the changes are > > positive so far [1]. > > > > I plan to submit this doc very soon, ahead of the draft submission > > deadline. I realize that's short notice, but I'm fully prepared to > > back out this change if necessary. > > > > --Martin > > > > [1] Costin suggested that we might also remove Crypto-Key. That is > > technically possible, though it's probably excessively kludgy, the DH > > key could be moved to the keyid field. I'm leery of that sort of > > optimization, but I'm willing to be convinced that this is a special > > enough case (I don't think that it is that special, but have at it). > > > > _______________________________________________ > > 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 > --001a114b4210007c91054031b7d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi j= r,

You= r understanding matches mine too.

On Mon, Oct 31, 2016 at 10:47 PM, jr conlin <jconlin@mozilla.com> wrote:
Perhaps I'm just confused by the various PRs and c= omments, but if I may,
i'd like to make sure I'm very clear on what the change is:

The crux of the change is:
1) Encrypted content would be identified as "aes128gcm", which sh= ould
not be confused with the now, long obsolete "aesgcm128".

2) salt, rs, and key_id are now prefixed to the encrypted content as:
`salt(16)|rs(4)|id_len(1)|key_id(id_len)|encrypted_content`

3) The content encoding key (CEK) is set to
```
HMAC-SHA-256(
=C2=A0 =C2=A0 HMAC-SHA-256(salt, key[key_id].secret),
=C2=A0 =C2=A0 "Content-Encoding: aes128gcm\x00\x01")=C2=A0 # from= 2.2 of
http://httpwg.org/http-extensions/en= cryption-preview.html
```
=C2=A0
Yes, if key[key_id].secret c= ontains the IKM that has already seen the
HMAC with the "Web= Push: info" info (the context replacement).

= =C2=A0 =C2=A0PRK_key =3D HMAC-SHA-256(auth_secret, ecdh_secret)
= =C2=A0 =C2=A0key_info =3D "WebPush: info" || 0x00 || ua_public ||= as_public
=C2=A0 =C2=A0IKM =3D HMAC-SHA-256(PRK_cek, key_info ||= 0x01)
=C2=A0
(So it's not just the shared EC= DH secret.)

The majority case will be that `key_id` is not defined (or is ''), = in
which case, we'd use the locally derived key.

=
To be clear, section 4 of webpush-encryption mandates that = the `id` field
in the header is the empty string.

Thanks,
Peter
=C2=A0

4) There's no longer a need for "context" to be appended to t= he key info
and nonce info, although the Content-Encoding for the new content type
will use the now obsolete "aesgcm128"
https://github.com/martinthomson/encrypted-content= -encoding/pull/28/files#diff-6ee19a23c153fa68b2910aeb69bde1d= dR213

5) The DH secret is now derived from running an HMAC-SHA-256 over
```'WebPush: info\x00' + receiverPublicKey + senderPublicKey```

Is that correct? Am I missing something?

On 10/31/2016 3:38 AM, Martin Thomson wrote:
> Discussion in the HTTP working group has lead to some fairly
> substantial changes to the spec that we rely on.=C2=A0 These are break= ing
> changes.=C2=A0 See the changes here:
> https://github.com/httpwg/http-extension= s/pull/252
>
> In short, several of the parameters that were in header fields are now=
> in the body of the message and the Encryption header field is now
> gone.
>
> This completely messes with the use of that spec in Webpush.=C2=A0 It&= #39;s
> easy to detect which version is in use because the identifier has
> changed, and there are small gains to be had.=C2=A0 The overall messag= e
> size is now slightly smaller, and the key derivation is now slightly > simpler.=C2=A0 The specs also have fewer interdependencies as a result= .
>
> I've put together a revision of the webpush-encryption draft.=C2= =A0 I've
> taken this opportunity to simplify things a little.=C2=A0 You can see = a
> preview in the editor's draft:
>
>=C2=A0 =C2=A0https://webpush-wg.github.io/w= ebpush-encryption/
>
> I realize that this is a fairly big (and late) change.=C2=A0 I remain<= br> > optimistic that it will be the last. Feedback on the changes are
> positive so far [1].
>
> I plan to submit this doc very soon, ahead of the draft submission
> deadline.=C2=A0 I realize that's short notice, but I'm fully p= repared to
> back out this change if necessary.
>
> --Martin
>
> [1] Costin suggested that we might also remove Crypto-Key.=C2=A0 That = is
> technically possible, though it's probably excessively kludgy, the= DH
> key could be moved to the keyid field.=C2=A0 I'm leery of that sor= t of
> optimization, but I'm willing to be convinced that this is a speci= al
> enough case (I don't think that it is that special, but have at it= ).
>
> _______________________________________________
> 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<= br>

--001a114b4210007c91054031b7d0-- From nobody Mon Oct 31 16:47:46 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 73A71129ADD; Mon, 31 Oct 2016 16:47:44 -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.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147795766446.23262.3705349557315755912.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2016 16:47:44 -0700 Archived-At: Cc: webpush@ietf.org Subject: [Webpush] I-D Action: draft-ietf-webpush-encryption-05.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, 31 Oct 2016 23:47:44 -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-05.txt Pages : 11 Date : 2016-10-31 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-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-webpush-encryption-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 31 16:57: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 7C134129C13 for ; Mon, 31 Oct 2016 16:56: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 1cabzytVAJzU for ; Mon, 31 Oct 2016 16:56:54 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::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 64B89129C14 for ; Mon, 31 Oct 2016 16:56:29 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id z190so180986314qkc.2 for ; Mon, 31 Oct 2016 16:56:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/dKi0ZKwKzKF2gQDNJcmII+b2wk4QHLKu3yTcte82/Q=; b=RgmeWLKQJTNgs+wFTH5t8u1SUWN61CH6zTdt6PiMTeKYcW01gKWpA21POB2mynMr3U MJYoohta999mAr9zzeH3sPWGjyHTYLdpFxGwrn+hjX9xgX+v9MTzrfAHNGgxqOPvUh/z xzJflaSIAgpDZy6mQQ8GIgI026ZzQFJtSxUD+Q/hJyPEn16sEa2bme1NJB7Pc9I2ChUD fqz2vUa6ki0IYI6YNZb0tN5/EOJAKtjRWgdRrrCcG1z2+/K2zaZEs+OBOKc+3IlxInmS goJUvPkntMU7JKiPRO37XES006c5/Odq61jZMHXysKqkgcr/k8RimkLmXq/HIbDaSXZd qvEQ== 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=/dKi0ZKwKzKF2gQDNJcmII+b2wk4QHLKu3yTcte82/Q=; b=f9/Zrw1AWZOBcb5xs/mMo5KS3knquSV5YsBsZNfLHh9QOIZPjGdgv3NSRjEsvgzKBi VGthFHlPkKoWsjenI3R7yUfuIY3n5DePoWvKiZ1imNL8HsYeB6KnsSrrYg4sGyIJmQN4 ciZzfLQ6SC7xfftNehb0Pdg8NP7SlScEnR5qmPHW8l1ue0r2adNXYSh2MHEdgAWlNp// ToR5NAW/i/mXS4lpyolpaT3pDtq2UWFa6hHYUjHZjeSPm2PppSavOxEEksP1ZcZNln+u tOLnDXOT3NLDGN72Xo8mtFA1RMDZnBhDMGNrBmgxugO32/V1qFTo8BjBP4J+IvYVi/4d bWsw== X-Gm-Message-State: ABUngvdLsyo4AXnQJ8p7NHNQlGYg9QLb9JyhtIeOHkbjdo0F8g000AX+2i4OEjUqFa2M5BpWnBOQ1cGH/HUQeQ== X-Received: by 10.55.99.141 with SMTP id x135mr26168464qkb.147.1477958188496; Mon, 31 Oct 2016 16:56:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Mon, 31 Oct 2016 16:56:27 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Tue, 1 Nov 2016 10:56:27 +1100 Message-ID: To: Peter Beverloo Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: jr conlin , "webpush@ietf.org" Subject: Re: [Webpush] Major change to 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: Mon, 31 Oct 2016 23:56:59 -0000 Hi Peter and JR, Thanks both for picking up on my stupid errors. Hasty is not always careful enough, but I was working to a time limit. With 5 minutes left, I think that I managed to get all your input integrated. And your reminder about vapid was timely. I think that we can dispense with any attempt to remove Crypto-Key, since we have to have it for vapid anyway. Now I need to think about getting the python implementation updated. --Martin On 1 November 2016 at 10:31, Peter Beverloo wrote: > Hi Martin, > > Thanks for the update and the proposal! > > I've reviewed these today, and have minor some points of feedback. I'll > deliberately avoid the topics of interoperability and upgrade cost here. > > First of all, this indeed vastly improves layering between the drafts. I > very much like how webpush-encryption is now built on top of encryption- > encoding as opposed to being some sort of fork. > >>> A push message MUST include a zero length keyid parameter in the >>> content coding header. This allows implementations to ignore the first >>> 21 octets of a push message. > > I don't think this is right. The `salt` and the `rs` must still be known, > and those are included in the header. > >>> A push service is not required to support more than 4096 octets of >>> payload body (see Section 7.2 of [I-D.ietf-webpush-protocol]), which >>> equates to at most 4059 octets of cleartext. > > I think this forgot about the padding -- > > 4096 - 16 (auth) - 2 (padding length) - 21 (header w/o keyid) = 4,057 > > May also want to s/cleartext/plaintext/ for consistency with encryption- > encoding. > >>> An Application Server MUST include exactly one aes128gcm content >>> coding, and at most one entry in the Crypto-Key field. This allows the >>> keyid parameter to be omitted. > > This means the draft is incompatible with VAPID again. It must have at > most one Crypto-Key entry that has a `dh` value. > > I haven't yet been able to validate the examples in the draft, but it > sounds like you're changing these anyway per jr's feedback (+1 to that). > > Thanks, > Peter > > > On Mon, Oct 31, 2016 at 11:19 PM, Martin Thomson > wrote: >> >> On 1 November 2016 at 10:07, jr conlin wrote: >> > One small comment, then? Can we change the transmitted Content-Encoding >> > type to match the new Content-type of "aes128gcm" instead of the long >> > abandoned "aesgcm128"? (See point #4) >> >> Ouch, that's going to hurt. I'll have to redo the examples :*( 40 >> minutes until the deadline, go! >> >> _______________________________________________ >> Webpush mailing list >> Webpush@ietf.org >> https://www.ietf.org/mailman/listinfo/webpush > > From nobody Mon Oct 31 17:49:40 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 2B7F3120726; Mon, 31 Oct 2016 17:49:38 -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.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147796137813.23209.8561679192884629222.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2016 17:49:38 -0700 Archived-At: Cc: webpush@ietf.org Subject: [Webpush] I-D Action: draft-ietf-webpush-encryption-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: Tue, 01 Nov 2016 00:49:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web-Based Push Notifications of the IETF. Title : Message Encryption for Web Push Author : Martin Thomson Filename : draft-ietf-webpush-encryption-06.txt Pages : 11 Date : 2016-10-31 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-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-webpush-encryption-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 Mon Oct 31 18:08:59 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 11BD81293F4 for ; Mon, 31 Oct 2016 18:08: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 NSD1YZe7lI_r for ; Mon, 31 Oct 2016 18:08:55 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88C501293DA for ; Mon, 31 Oct 2016 18:08:55 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id q130so63490457qke.1 for ; Mon, 31 Oct 2016 18:08:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=ID3K0DqMiQF48qOTdJTPc4sl0k8M55tgPAnlpknneas=; b=Rtx/ge7ME5DeGS4QPOHyb30nMHoPx2zWgI2AuxMz6tKM+ON/JhWvaq+L567IQS/fA/ B7dzvDGxvCPitI+iU18oJKABvAJ+BAQnb40C38z1jHRzRpLGNUkMKc1cNQapeiLrDwjQ 3aOrkoLe6X1FkEtnnB0QRH6QOuZs/BqXEiXdWrqpY5chAYslI6YuHKB0HKnBZF6Kzo5T 35MSaQbxrzEj0U1MqSwgEu5G22ovx4UDBG/taBlo79lkQvd/wJWMy8EmScRCF8eU0HZS tlJSmI2nBt3kZSm+Pg7kDFLoUXlSFIgOenYV6Ot09djGO+n11PEkX3ku/1qTt3+yRn3q oqVA== 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=ID3K0DqMiQF48qOTdJTPc4sl0k8M55tgPAnlpknneas=; b=CsuKLKZN9Ufalw84dbL60zq7m21ZuSqNAUlohSBoDFsR3bqQVVBuLDIcARDulaOz7M g/mFsGKMsY1B2nuPLZ8G0fU8kmko9mXAkrHYezNHSKYjfg4rp7VKfdxVqVROv9D0RBmP OG0Bwug6U5qBhLa+QHl568tSsrdTMstQ2eQ9U6saDZd003AQsyw71OInRp1dFHphwn3Y RdSGWwIhXoXEGS0i6fnfbqp+9GcR08BLooUNlnlKNFDoTkhsx88LaDiWSY6/xDYQwobS KfpTMA0P/6qAQer7i2Hv+nclYmEXKSy9Z9mxbUCIG0IijVqSv1mugh2z+Diqs0Nq94YS s4Eg== X-Gm-Message-State: ABUngvesozvSKhrQpCG/E3KyTFWDpGNVsJ77IcNlEsDfWJ6odBzMehupjjTJeNoJefuRNAY269XTF36EWWWk8w== X-Received: by 10.233.235.72 with SMTP id b69mr1212235qkg.144.1477962534547; Mon, 31 Oct 2016 18:08:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Mon, 31 Oct 2016 18:08:54 -0700 (PDT) In-Reply-To: <147796137813.23209.8561679192884629222.idtracker@ietfa.amsl.com> References: <147796137813.23209.8561679192884629222.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Tue, 1 Nov 2016 12:08:54 +1100 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-06.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, 01 Nov 2016 01:08:58 -0000 I decided to address Peter's comments and get them on the record. On 1 November 2016 at 11:49, 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-06.txt > Pages : 11 > Date : 2016-10-31 > > 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-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-webpush-encryption-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/ > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush