From nobody Wed Apr 1 16:18:33 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2FB01ACCE2 for ; Wed, 1 Apr 2015 16:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cw_sUxw4wld4 for ; Wed, 1 Apr 2015 16:18:29 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::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 54B6E1A066B for ; Wed, 1 Apr 2015 16:18:27 -0700 (PDT) Received: by obbgh1 with SMTP id gh1so97970338obb.1 for ; Wed, 01 Apr 2015 16:18:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=C79ifWzDsdZZhNobFmonQnxmAZHbEyqz2no8p0MJQIU=; b=HBqOy42dB43QHsxihzSA1j2QnQI5VlrUi185YM7tNkLDHMS5XaZeXmHF9Q+i4pBKWh LueDFKKWub5aFshTj3t6cU9KKdLx96/aiUMj9dy/VtOdNxtnioVytdtj2FgQ/+EceYR6 IaR3m8uMjP1WHlHSXafOOWOwe6N3Cotxcm0NkbFwsFU+JlI3NRaAT7dZc246jJpfZKx9 QSfUKOg6N9Dp0VuvJxGd/iQa2oLr8WD0eVLIY/wJuE2fKCJbyZrH8OZ6VDR4LKFkWMMl Roqo24H6vGGqVlHO/VZmf4YxGmRfXS1ZH87DYEaiinJ+Me79nKBmtD061C9GCM/3eslw 9P9w== MIME-Version: 1.0 X-Received: by 10.60.158.202 with SMTP id ww10mr44061988oeb.18.1427930306835; Wed, 01 Apr 2015 16:18:26 -0700 (PDT) Received: by 10.202.48.151 with HTTP; Wed, 1 Apr 2015 16:18:26 -0700 (PDT) Date: Wed, 1 Apr 2015 16:18:26 -0700 Message-ID: From: Martin Thomson To: "webpush@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Webpush] Analysis of performance impact of disaggregation X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 23:18:32 -0000 One of the concerns raised about Microsoft's disaggregation proposal was the performance impact it implies. Since connections and the state tied to them is volatile state, being able to efficiently repair that state could be important. Maybe some numbers might help here, even if they are rough and based on some speculation. For a server that chooses to operate as proposed and provide independent subscriptions, this means that clients need to tell the server about every subscription they are interested in after a connection is restored. If I'm right about this much, the choice over whether disaggregation or aggregation is largely driven by costs at this point. That means understanding the costs. ## Costs for aggregation An aggregating server needs a way to identify all undelivered messages across all subscriptions for the registration. I originally envisaged an architecture where this is done by aggregating messages into a single persistent store that was common across the registration. This reduces the cost of session restoration to connection establishment, plus one request, and then a database lookup. An aggregate on push design like this doesn't necessarily require a server to explicitly maintain a list of subscriptions for a registration, servers only need a way to identify the registration based on the subscription URL. I can go into more detail on how that might work if people don't think this is possible. Elio pointed out that their delivery architecture kept subscriptions independent of each other and that aggregation would force them to store additional information identifying active subscriptions. That is, aggregate on pull. Session restoration for an aggregate-on-pull architecture would entail querying the registration store, then querying each of the listed subscriptions independently. Obviously, that imposes additional state management overhead on the server, as well as having the cost and delay of querying each subscription once the connection is online. The only cost to the user agent is a potential delay in message delivery after a connection break. ## Costs for disaggregation A server without any aggregation doesn't need to maintain any information about the correlation of subscriptions. So the concerns raised about aggregation are ameliorated. The cost here is in the time that it takes to tell the server about all of the different subscriptions you are interested in. In HTTP/2, that is largely driven by the size of the path component of the URL, the rest can be aggressively compressed down to a handful of bytes (let's say 16, including the frame header). I'm assuming the absence of bearer tokens for authentication, which might be used here at a significantly increased cost in bytes. The big latency cost comes in when the size of requests exceeds the TCP CWND, which is probably still small at this point. Assuming TLS false start, that CWND is shared with the TLS CCS and Finished and the HTTP/2 preface, which might amount to 100 bytes total. The dominant factors here are therefore how many subscriptions and how long is the URL for each. Here's where the assumptions start to build up. I don't have good stats on this, but I'm going to suggest that you might want to have 100 subscriptions active without performance degradation (I expect the real number to be much lower than this in practice, but outliers are where complaints originate). URLs can be quite long, depending on what is packed into them. Microsoft documentation (https://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh868252.aspx) shows an example with a 159 octet path. If that length is representative, 100 subscriptions will consume 17.5k plus overheads. Transmitting that data takes an insignificant amount of time, but that amount exceeds the CWND for the second round trip of TCP on common MSS values short of INIT_CWND 7. If the CWND is exceeded, then it takes an additional round trip to complete the setup. The example also includes a 62 byte bearer token sent by the application server; I don't know if that is needed here or not for the user agent. I don't know what the current status is, but last time I checked INIT_CWND 4 was the value that was in widespread use. That means less than 64 subscriptions. If you wanted to be quite aggressive about reducing the size of the path and are able to make some architectural changes, it should be quite feasible to construct a subscription path that is only 45 characters in base64. At that point, I think that we can discount the CWND issue. ## Allowing choice I think that I'd be disappointed if we allowed the push service to pick here. That makes it harder to build a single client. But it might be OK given the need for some sort of prior relationship with the push service for authentication purposes. I don't think that this is accepting the judgment of solomon, but I think we need to consider the complexity costs of that option. From nobody Thu Apr 2 17:02:00 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF0991A88C4 for ; Thu, 2 Apr 2015 17:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0juNqdyApJ3f for ; Thu, 2 Apr 2015 17:01:57 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 193BC1A88BD for ; Thu, 2 Apr 2015 17:01:57 -0700 (PDT) Received: by obbgh1 with SMTP id gh1so145150021obb.1 for ; Thu, 02 Apr 2015 17:01:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=icn0jO1a2FbYEvQTCNvkSnhEWRoIF+oXCbG+t0Bw+tc=; b=bQ1cCeje3Ma8WMfkqKZJQ8Ko4PeahoX1EMk8RQJA69Em8t6EL3uyO52OY6DVzQOtxR IEHwPSCGrjAoA5438vwp9KIIhqijq4Q8l5aSWsxv6u0hfU/pPGvQnnEJXH7OJIeb9b6Z 09pCc9vwBHs+oQwPLZcEtbr4hapYf/2hELr4gnuqzkBEf/FdgAINlSWB36CoKCcHoUD8 kV7GAw6PVPEFBtP/1iIUzV1mXNc9g9nLORf6gdbh8MSxtOyKQ0J/XDZx6aSQfufhXGsE kuJ/yobziFWpVTpeh+MChmNQlla4vlLnmhTveLu9paJ4z/fZ+wMnms3KYDi5c3383zes +eWg== MIME-Version: 1.0 X-Received: by 10.182.39.195 with SMTP id r3mr50114617obk.44.1428019316557; Thu, 02 Apr 2015 17:01:56 -0700 (PDT) Received: by 10.202.48.151 with HTTP; Thu, 2 Apr 2015 17:01:56 -0700 (PDT) Date: Thu, 2 Apr 2015 17:01:56 -0700 Message-ID: From: Martin Thomson To: "webpush@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Webpush] My conclusion regarding disaggregation X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 00:01:59 -0000 I have concluded that disaggregation is the right approach. Though not for any of the reasons raised at the meeting. The analysis I posted yesterday concluded that perhaps the efficiency downsides of disaggregation can be mitigated sufficiently if a push service is careful enough with identifier allocation and compression. That mostly removed the downsides for me, but didn't really provide any actual justification for disaggregation. Since writing that, I've been thinking about the protocol consequences of splitting the subscription into two resources. After thinking that through, I concluded that splitting the subscription in two naturally leads to disaggregation. And combined, those two changes have some nice properties and they even enables some features that we might want to include. --- With a split subscription, the application server (AS) pushes against one resource, which triggers a notification at the user agent (UA). * In the aggregated case, the push service (PS) has to use a single identifier for all messages pushed to that subscription (either the public or the private URL associated with that subscription), otherwise the UA has no way of properly identifying the subscription. * On the other hand, if we don't have registration, then monitoring each subscription directly ensures that the client can easily identify the subscription context. That allows us to uniquely identify each message with a URL. Being able to uniquely identify messages has several benefits: * Message collapsing is easy: rather than using POST to create a new message, the contents of a previous message can be replaced with new content using PUT. * Message acknowledgment is easier: the UA can acknowledge a message using a DELETE request on it. If we do collapsing, then the DELETE will ideally be conditional (using If-None-Match or If-Not-Modified-Since), but that's the only real source of complication. * Application servers can cancel message delivery by acknowledging messages that they sent. * I can also imagine being able to navigate a set of messages using "next" and "prev" relations, but that's not actually addressing any use case, so I don't think that we'd specify it. It's merely nice from a consistency standpoint. The only potential pitfall I can see is that if a collapsed message is updated just prior to an "acknowledgment", the ack will be lost since the DELETE is conditional. I think that's OK: that only happens when the UA is online, so the UA will get the updated message quickly and can acknowledge the updated message straight away. Of course, messages will need to be given unguessable URLs for some of these to work without extra authentication machinery, but that's easy. --- I've spoken with Brian and Elio about this. Brian is doing a write-up of the basic design. We'll have a merged proposal ready shortly for discussion (and hopefully adoption). I've already suggest that this merged design not include a registration option. From nobody Wed Apr 15 17:42:42 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98CC31ACEFA for ; Wed, 15 Apr 2015 17:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_ILLEGAL_IP=1.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVdd5B1ZM3Ke for ; Wed, 15 Apr 2015 17:42:39 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0111.outbound.protection.outlook.com [65.55.169.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 080BA1ACEFE for ; Wed, 15 Apr 2015 17:42:35 -0700 (PDT) Received: from BY2PR0301MB0647.namprd03.prod.outlook.com (0.160.63.14) by BY2PR0301MB0645.namprd03.prod.outlook.com (0.160.63.13) with Microsoft SMTP Server (TLS) id 15.1.136.25; Thu, 16 Apr 2015 00:42:34 +0000 Received: from BY2PR0301MB0647.namprd03.prod.outlook.com ([0.160.63.14]) by BY2PR0301MB0647.namprd03.prod.outlook.com ([0.160.63.14]) with mapi id 15.01.0136.026; Thu, 16 Apr 2015 00:42:34 +0000 From: "Brian Raymor (MS OPEN TECH)" To: "webpush@ietf.org" Thread-Topic: New Version Notification for draft-thomson-webpush-protocol-00.txt Thread-Index: AQHQd9mJ1rxhKjKDVk6dxYEt9cKnm51OxvXg Date: Thu, 16 Apr 2015 00:42:34 +0000 Message-ID: References: <20150416000844.29595.68704.idtracker@ietfa.amsl.com> In-Reply-To: <20150416000844.29595.68704.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [73.42.172.77] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0301MB0645; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377424004)(2900100001)(2420400003)(106116001)(62966003)(77156002)(102836002)(15975445007)(92566002)(54356999)(76176999)(2950100001)(230783001)(2351001)(107886001)(50986999)(76576001)(1720100001)(450100001)(74316001)(86362001)(122556002)(40100003)(86612001)(2656002)(110136001)(87936001)(46102003)(2501003)(19580395003)(66066001)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0645; H:BY2PR0301MB0647.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:BY2PR0301MB0645; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0645; x-forefront-prvs: 0548586081 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2015 00:42:34.5845 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0645 Archived-At: Subject: [Webpush] FW: New Version Notification for draft-thomson-webpush-protocol-00.txt X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 00:42:40 -0000 QXMgcmVxdWVzdGVkIGF0IHRoZSBsYXN0IFdlYlB1c2ggbWVldGluZyBpbiBEYWxsYXMsIE1hcnRp biwgRWxpbywgYW5kIEkgaGF2ZSBtZXJnZWQgb3VyIHByb3Bvc2FscyBpbnRvIGEgc3RyYXctbWFu IGZvciByZXZpZXcuDQoNCkR1cmluZyB0aGF0IHByb2Nlc3MsIHdlJ3ZlIGNhcHR1cmVkIGlzc3Vl cyBhdDoNCg0KCWh0dHBzOi8vZ2l0aHViLmNvbS91bmljb3JuLXdnL3dlYnB1c2gtcHJvdG9jb2wv aXNzdWVzDQoNCmJ1dCB3aWxsIG5vdyBtaWdyYXRlIHRob3NlIGRpc2N1c3Npb25zIHRvIHRoZSBX ZWJQdXNoIG1haWxpbmcgbGlzdCBpbiB0aGUgbmV4dCBmZXcgZGF5cy4NCg0KLi4uQnJpYW4NCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0 LXRob21zb24td2VicHVzaC1wcm90b2NvbC0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBz dWJtaXR0ZWQgYnkgQnJpYW4gUmF5bW9yIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9y eS4NCg0KTmFtZToJCWRyYWZ0LXRob21zb24td2VicHVzaC1wcm90b2NvbA0KUmV2aXNpb246CTAw DQpUaXRsZToJCUdlbmVyaWMgRXZlbnQgRGVsaXZlcnkgVXNpbmcgSFRUUCBQdXNoDQpEb2N1bWVu dCBkYXRlOgkyMDE1LTA0LTE1DQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6 CQkyMQ0KVVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LXRob21zb24td2VicHVzaC1wcm90b2NvbC0wMC50eHQNClN0YXR1czogICAgICAgICBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10aG9tc29uLXdlYnB1c2gtcHJv dG9jb2wvDQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt dGhvbXNvbi13ZWJwdXNoLXByb3RvY29sLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBBIHNpbXBsZSBw cm90b2NvbCBmb3IgdGhlIGRlbGl2ZXJ5IG9mIHJlYWx0aW1lIGV2ZW50cyB0byB1c2VyIGFnZW50 cw0KICAgaXMgZGVzY3JpYmVkLiAgVGhpcyBzY2hlbWUgdXNlcyBIVFRQLzIgc2VydmVyIHB1c2gu DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1h eSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVu dGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMu aWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Wed Apr 29 10:13:14 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC7A1ACD7F for ; Wed, 29 Apr 2015 10:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VpVlyYVwQo4 for ; Wed, 29 Apr 2015 10:13:11 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE12C1ACDA7 for ; Wed, 29 Apr 2015 10:12:48 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 01111455.0.5747621.00-2266.15998288.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 29 Apr 2015 17:12:48 +0000 (UTC) X-MXL-Hash: 554111104cd77c60-c2b21df6e3250ff1a4c5ab9c1c499013a8166a68 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id t3THClsD016811; Wed, 29 Apr 2015 10:12:47 -0700 Received: from flpi487.ffdc.sbc.com (flpi487.ffdc.sbc.com [130.4.162.181]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id t3THCicM016797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 29 Apr 2015 10:12:44 -0700 Received: from CAFRFD1MSGHUBAA.ITServices.sbc.com (CAFRFD1MSGHUBAA.itservices.sbc.com [130.4.169.178]) by flpi487.ffdc.sbc.com (RSA Interceptor); Wed, 29 Apr 2015 17:12:33 GMT Received: from CAFRFD1MSGUSRIA.ITServices.sbc.com ([169.254.1.65]) by CAFRFD1MSGHUBAA.ITServices.sbc.com ([130.4.169.178]) with mapi id 14.03.0224.002; Wed, 29 Apr 2015 10:12:33 -0700 From: "DRUTA, DAN" To: "Brian Raymor (MS OPEN TECH)" , "webpush@ietf.org" Thread-Topic: [Webpush] FW: New Version Notification for draft-thomson-webpush-protocol-00.txt Thread-Index: AQHQd9mJ1rxhKjKDVk6dxYEt9cKnm51OxvXggBV5MWA= Date: Wed, 29 Apr 2015 17:12:32 +0000 Message-ID: <4AA3A95D6033ED488F8AE4E45F474487455B1E2A@CAFRFD1MSGUSRIA.ITServices.sbc.com> References: <20150416000844.29595.68704.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.161.219.255] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=Kvf6LxqN c=1 sm=1 a=xwOvzTHDVLE4u4nGvK72ag==:17 a] X-AnalysisOut: [=cDMoV1pVlfoA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=e9J7MTPGsLIA:10 a=48vgC7mUA] X-AnalysisOut: [AAA:8 a=NEAV23lmAAAA:8 a=IvZGDAVS7Wv7DXNWhpEA:9 a=CjuIK1q_] X-AnalysisOut: [8ugA:10 a=j-LSHiSXCvblJ8-5:21 a=wQ7bgGtSqM1Etp_a:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] Archived-At: Subject: Re: [Webpush] FW: New Version Notification for draft-thomson-webpush-protocol-00.txt X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 17:13:13 -0000 Brian, Martin and Elio,=20 Thanks for the offline coordination and for putting this version together. = I finally managed to get to review the draft and it looks good for the most= part. I made a few comments on the issues in github so I won't repeat them here. A couple topics came to mind and I would like to throw them here for furthe= r clarification from the authors: 1. Prioritization As I went through the draft I wasn't able to understand how the push servic= e will handle message prioritization (for the same subscription). Is the expectation that the app server will send them in the right sequence= and the push server will use a FIFO (first in first out) queue? The scenario I have in mind is a social network application that can push n= ews alerts and incoming chat notifications. I would expect the chat notific= ation to have a higher priority than other notifications. If the app server sends notifications as they happen, it is only the push s= ervice that will be able to act based on some form of prioritization indica= tor. Priority is a fairly basic requirement and I hope it can get handled in a h= eader so it can be consistently enforced by the push service. 2. Message deduplication and retries. Section 6.1 talks about acknowledging push messages and that the user agent= must acknowledge with an HTTP DELETE if the message was delivered at least= once. Should we have a mechanism in place to account for message deduplication? I= might be wrong but I can see situations where the three parties (AS, PS, U= A) end up in some race conditions and the AS ends up retrying. It would be = good to clarify that the push messages for the same application event insta= nce (e.g. call from Bob) MUST have the same identifier so they can be dupli= cated at the PS so they don't get sent multiple times to the UE. Regards, Dan -----Original Message----- From: Webpush [mailto:webpush-bounces@ietf.org] On Behalf Of Brian Raymor (= MS OPEN TECH) Sent: Wednesday, April 15, 2015 5:43 PM To: webpush@ietf.org Subject: [Webpush] FW: New Version Notification for draft-thomson-webpush-p= rotocol-00.txt As requested at the last WebPush meeting in Dallas, Martin, Elio, and I hav= e merged our proposals into a straw-man for review. During that process, we've captured issues at: https://github.com/unicorn-wg/webpush-protocol/issues but will now migrate those discussions to the WebPush mailing list in the n= ext few days. ...Brian -----Original Message----- A new version of I-D, draft-thomson-webpush-protocol-00.txt has been successfully submitted by Brian Raymor and posted to the IETF repo= sitory. Name: draft-thomson-webpush-protocol Revision: 00 Title: Generic Event Delivery Using HTTP Push Document date: 2015-04-15 Group: Individual Submission Pages: 21 URL: http://www.ietf.org/internet-drafts/draft-thomson-webpush-p= rotocol-00.txt Status: https://datatracker.ietf.org/doc/draft-thomson-webpush-prot= ocol/ Htmlized: http://tools.ietf.org/html/draft-thomson-webpush-protocol-0= 0 Abstract: A simple protocol for the delivery of realtime events to user agents is described. This scheme uses HTTP/2 server push. = =20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ Webpush mailing list Webpush@ietf.org https://www.ietf.org/mailman/listinfo/webpush From nobody Wed Apr 29 11:57:21 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7B371A8A92 for ; Wed, 29 Apr 2015 11:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P05G8LvnfdFZ for ; Wed, 29 Apr 2015 11:57:18 -0700 (PDT) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::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 E9E2B1A8939 for ; Wed, 29 Apr 2015 11:57:07 -0700 (PDT) Received: by yhrr66 with SMTP id r66so7770886yhr.3 for ; Wed, 29 Apr 2015 11:57:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hwiF6G2XTkBczHJY2UULMbNRICDH85iCVXddJZnSaOE=; b=acCz5SWLSrzZK1slhSuDUwE7OZSbP11cU1VbiMNqTB9tuBGKY5U6e+fR2Od0Mzfdfy BLcFfWBXa39q1AG9et+0/fCH3/J2U1hzKb8ITMFKOo8nzQJ05nu5QZlGJFid+y3hh1rA E3gqUct4sX8hmIY+undu+6GcJ7hyhDxgg0rMkrGECU7rjn11+MhlcCFN7LOCv1i05+I/ 5QngI57VHdaOLrievCZDT864lsfvTEqRSZwu71etbtZowyfSZXbDrSk5rgGxmtyQCVd+ ABJS+cHQHjiy07W2vElcDmb6Lmzsi3vKlggRwuTAScrkYv/HJr/kfcEJSV6wDyAoilSn DqBA== MIME-Version: 1.0 X-Received: by 10.170.158.10 with SMTP id z10mr525046ykc.1.1430333827256; Wed, 29 Apr 2015 11:57:07 -0700 (PDT) Received: by 10.13.247.71 with HTTP; Wed, 29 Apr 2015 11:57:07 -0700 (PDT) In-Reply-To: <4AA3A95D6033ED488F8AE4E45F474487455B1E2A@CAFRFD1MSGUSRIA.ITServices.sbc.com> References: <20150416000844.29595.68704.idtracker@ietfa.amsl.com> <4AA3A95D6033ED488F8AE4E45F474487455B1E2A@CAFRFD1MSGUSRIA.ITServices.sbc.com> Date: Wed, 29 Apr 2015 11:57:07 -0700 Message-ID: From: Martin Thomson To: "DRUTA, DAN" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "Brian Raymor \(MS OPEN TECH\)" , "webpush@ietf.org" Subject: Re: [Webpush] FW: New Version Notification for draft-thomson-webpush-protocol-00.txt X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 18:57:19 -0000 On 29 April 2015 at 10:12, DRUTA, DAN wrote: > 1. Prioritization [...] > Is the expectation that the app server will send them in the right sequence and the push server will use a FIFO (first in first out) queue? The draft really doesn't say, partly because we didn't discuss it much, partly because I think that we'd want some flexibility. I've opened an issue on this in our issue tracker so that we don't forget this. > Priority is a fairly basic requirement and I hope it can get handled in a header so it can be consistently enforced by the push service. Prioritization is a concern if there are multiple messages to deliver at the same time. This happens most often when a device comes back from a short nap (as mobile devices do all the time). With a small number of messages, this might not be a big deal, but if there is a backlog to clear, it could be. I have a draft on signaling priorities that could be used in this context: https://tools.ietf.org/html/draft-thomson-http-nice-02 Do you think that we need to address this in a basic protocol specification, or can it rely on other specifications. > 2. Message deduplication and retries. Yes, reliability is hard. The intent is to have the application mark messages and perform deduplication if it does resending, especially within the TTL period that the push service promises. In terms of the protocol, there is a proposal for message replacement that might reduce the need for some of this, but Brian, Elio and I decided that we'd let this draft stabilize before talking about that feature: https://github.com/unicorn-wg/webpush-protocol/pull/12 From nobody Wed Apr 29 12:25:25 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729281A909D for ; Wed, 29 Apr 2015 12:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xUaLp9NUpSk for ; Wed, 29 Apr 2015 12:25:17 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 132681ACE7C for ; Wed, 29 Apr 2015 12:25:17 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-5) with ESMTP id d1031455.2afdc1c15940.5698711.00-2479.15850744.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 29 Apr 2015 19:25:17 +0000 (UTC) X-MXL-Hash: 5541301d35e84498-04fc024d1632bc576f249a22181976d2bc1805fb Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 51031455.0.5698620.00-2299.15850484.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 29 Apr 2015 19:25:11 +0000 (UTC) X-MXL-Hash: 554130175b6dba19-62703caf6285e708fe4dc9bdab2555f7b48e5914 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id t3TJP8Qm010359; Wed, 29 Apr 2015 12:25:08 -0700 Received: from flpi489.ffdc.sbc.com (flpi489.ffdc.sbc.com [130.4.162.183]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id t3TJP5Gw010331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 29 Apr 2015 12:25:05 -0700 Received: from CAFRFD1MSGHUBAD.ITServices.sbc.com (CAFRFD1MSGHUBAD.itservices.sbc.com [130.4.169.143]) by flpi489.ffdc.sbc.com (RSA Interceptor); Wed, 29 Apr 2015 19:24:52 GMT Received: from CAFRFD1MSGUSRIA.ITServices.sbc.com ([169.254.1.65]) by CAFRFD1MSGHUBAD.ITServices.sbc.com ([130.4.169.143]) with mapi id 14.03.0224.002; Wed, 29 Apr 2015 12:24:52 -0700 From: "DRUTA, DAN" To: Martin Thomson Thread-Topic: [Webpush] FW: New Version Notification for draft-thomson-webpush-protocol-00.txt Thread-Index: AQHQgq5MeMbau1+lGEeNVEQr7zZpxZ1kWdBQ Date: Wed, 29 Apr 2015 19:24:51 +0000 Message-ID: <4AA3A95D6033ED488F8AE4E45F474487455B32A8@CAFRFD1MSGUSRIA.ITServices.sbc.com> References: <20150416000844.29595.68704.idtracker@ietfa.amsl.com> <4AA3A95D6033ED488F8AE4E45F474487455B1E2A@CAFRFD1MSGUSRIA.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.161.219.255] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=Xbw+OvF5 c=1 sm=1 a=xwOvzTHDVLE4u4nGvK72ag==:17 a] X-AnalysisOut: [=cDMoV1pVlfoA:10 a=BLceEmwcHowA:10 a=IkcTkHD0fZMA:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=e9J7MTPGsLIA:10 a=pGLkceISA] X-AnalysisOut: [AAA:8 a=48vgC7mUAAAA:8 a=NEAV23lmAAAA:8 a=cRO23dQ8JaucZOtF] X-AnalysisOut: [vpcA:9 a=QEXdDO2ut3YA:10 a=jCaSjmxH7wZDqm39:21 a=SVsQ1fK-g] X-AnalysisOut: [5EE1f6K:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] Archived-At: Cc: "Brian Raymor \(MS OPEN TECH\)" , "webpush@ietf.org" Subject: Re: [Webpush] FW: New Version Notification for draft-thomson-webpush-protocol-00.txt X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 19:25:24 -0000 SGkgTWFydGluLA0KDQpJIHRoaW5rIHdlIGNhbiBhZGRyZXNzIHRoZSByZWxhdGl2ZSBwcmlvcml0 eSBpbiB0aGUgd2ViIHB1c2ggZHJhZnQgYXQgbWluaW11bSB3aXRoIHNvbWUgY2xhcmlmaWNhdGlv bnMgb24gdXNlIGNhc2VzIGFuZCBzb21lIG9mIHRoZSByZXF1aXJlbWVudHMuIE11Y2ggbGlrZSBJ IHRyaWVkIHRvIGV4cGxhaW4gaW4gbXkgZXhhbXBsZSBhbmQgeW91IGV4cGFuZGVkIHdpdGggdGhl IGRldmljZSBuYXAgc2NlbmFyaW8uDQpJZiBOSUNFIHByb3Bvc2FsIGdldHMgc3VwcG9ydCBpbiBo dHRwIFdHIEkgZG9uJ3Qgc2VlIGFueSByZWFzb24gdG8gcmVpbnZlbnQgdGhlIHdoZWVsIGJ1dCBh cyBvZiBub3cgSSBiZWxpZXZlIHlvdXIgZHJhZnQgaXMgZXhwaXJlZC4NCkF0IGxlYXN0IHdlIHNo b3VsZCBkZXRlcm1pbmUgaG93IGltcG9ydGFudCBvZiBhIGZlYXR1cmUgdGhpcyBpcy4NCg0KRGFu DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNYXJ0aW4gVGhvbXNvbiBbbWFp bHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbV0gDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDI5 LCAyMDE1IDExOjU3IEFNDQpUbzogRFJVVEEsIERBTg0KQ2M6IEJyaWFuIFJheW1vciAoTVMgT1BF TiBURUNIKTsgd2VicHVzaEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtXZWJwdXNoXSBGVzogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC10aG9tc29uLXdlYnB1c2gtcHJvdG9jb2wt MDAudHh0DQoNCk9uIDI5IEFwcmlsIDIwMTUgYXQgMTA6MTIsIERSVVRBLCBEQU4gPGRkNTgyNkBh dHQuY29tPiB3cm90ZToNCj4gMS4gUHJpb3JpdGl6YXRpb24NClsuLi5dDQo+IElzIHRoZSBleHBl Y3RhdGlvbiB0aGF0IHRoZSBhcHAgc2VydmVyIHdpbGwgc2VuZCB0aGVtIGluIHRoZSByaWdodCBz ZXF1ZW5jZSBhbmQgdGhlIHB1c2ggc2VydmVyIHdpbGwgdXNlIGEgRklGTyAoZmlyc3QgaW4gZmly c3Qgb3V0KSBxdWV1ZT8NCg0KVGhlIGRyYWZ0IHJlYWxseSBkb2Vzbid0IHNheSwgcGFydGx5IGJl Y2F1c2Ugd2UgZGlkbid0IGRpc2N1c3MgaXQNCm11Y2gsIHBhcnRseSBiZWNhdXNlIEkgdGhpbmsg dGhhdCB3ZSdkIHdhbnQgc29tZSBmbGV4aWJpbGl0eS4gIEkndmUNCm9wZW5lZCBhbiBpc3N1ZSBv biB0aGlzIGluIG91ciBpc3N1ZSB0cmFja2VyIHNvIHRoYXQgd2UgZG9uJ3QgZm9yZ2V0DQp0aGlz Lg0KDQo+IFByaW9yaXR5IGlzIGEgZmFpcmx5IGJhc2ljIHJlcXVpcmVtZW50IGFuZCBJIGhvcGUg aXQgY2FuIGdldCBoYW5kbGVkIGluIGEgaGVhZGVyIHNvIGl0IGNhbiBiZSBjb25zaXN0ZW50bHkg ZW5mb3JjZWQgYnkgdGhlIHB1c2ggc2VydmljZS4NCg0KUHJpb3JpdGl6YXRpb24gaXMgYSBjb25j ZXJuIGlmIHRoZXJlIGFyZSBtdWx0aXBsZSBtZXNzYWdlcyB0byBkZWxpdmVyDQphdCB0aGUgc2Ft ZSB0aW1lLiAgVGhpcyBoYXBwZW5zIG1vc3Qgb2Z0ZW4gd2hlbiBhIGRldmljZSBjb21lcyBiYWNr DQpmcm9tIGEgc2hvcnQgbmFwIChhcyBtb2JpbGUgZGV2aWNlcyBkbyBhbGwgdGhlIHRpbWUpLiAg V2l0aCBhIHNtYWxsDQpudW1iZXIgb2YgbWVzc2FnZXMsIHRoaXMgbWlnaHQgbm90IGJlIGEgYmln IGRlYWwsIGJ1dCBpZiB0aGVyZSBpcyBhDQpiYWNrbG9nIHRvIGNsZWFyLCBpdCBjb3VsZCBiZS4g IEkgaGF2ZSBhIGRyYWZ0IG9uIHNpZ25hbGluZyBwcmlvcml0aWVzDQp0aGF0IGNvdWxkIGJlIHVz ZWQgaW4gdGhpcyBjb250ZXh0Og0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRo b21zb24taHR0cC1uaWNlLTAyDQoNCkRvIHlvdSB0aGluayB0aGF0IHdlIG5lZWQgdG8gYWRkcmVz cyB0aGlzIGluIGEgYmFzaWMgcHJvdG9jb2wNCnNwZWNpZmljYXRpb24sIG9yIGNhbiBpdCByZWx5 IG9uIG90aGVyIHNwZWNpZmljYXRpb25zLg0KDQo+IDIuIE1lc3NhZ2UgZGVkdXBsaWNhdGlvbiBh bmQgcmV0cmllcy4NCg0KWWVzLCByZWxpYWJpbGl0eSBpcyBoYXJkLiAgVGhlIGludGVudCBpcyB0 byBoYXZlIHRoZSBhcHBsaWNhdGlvbiBtYXJrDQptZXNzYWdlcyBhbmQgcGVyZm9ybSBkZWR1cGxp Y2F0aW9uIGlmIGl0IGRvZXMgcmVzZW5kaW5nLCBlc3BlY2lhbGx5DQp3aXRoaW4gdGhlIFRUTCBw ZXJpb2QgdGhhdCB0aGUgcHVzaCBzZXJ2aWNlIHByb21pc2VzLg0KDQpJbiB0ZXJtcyBvZiB0aGUg cHJvdG9jb2wsIHRoZXJlIGlzIGEgcHJvcG9zYWwgZm9yIG1lc3NhZ2UgcmVwbGFjZW1lbnQNCnRo YXQgbWlnaHQgcmVkdWNlIHRoZSBuZWVkIGZvciBzb21lIG9mIHRoaXMsIGJ1dCBCcmlhbiwgRWxp byBhbmQgSQ0KZGVjaWRlZCB0aGF0IHdlJ2QgbGV0IHRoaXMgZHJhZnQgc3RhYmlsaXplIGJlZm9y ZSB0YWxraW5nIGFib3V0IHRoYXQNCmZlYXR1cmU6IGh0dHBzOi8vZ2l0aHViLmNvbS91bmljb3Ju LXdnL3dlYnB1c2gtcHJvdG9jb2wvcHVsbC8xMg0K