From nobody Wed Mar 4 12:12:43 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 EC9F21AC444 for ; Wed, 4 Mar 2015 12:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.079 X-Spam-Level: X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id og9RR3WHgU9d for ; Wed, 4 Mar 2015 12:12:37 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) (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 6F2761A88E4 for ; Wed, 4 Mar 2015 12:12:37 -0800 (PST) Received: by wggz12 with SMTP id z12so49186975wgg.2 for ; Wed, 04 Mar 2015 12:12:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xNl/S5T0ZN1BBgreA7YFCHnEHmmSoT2jWCmGObtNw28=; b=YIEBPFIcMQExElwUhBAFJSFmSEYPsbtLeWZWkzOPKP1EDV2NnJtIdK5BjsPOv3GPAm VxB95KYdMjMau8urpvd0xC81TDSVjvx+RmMxBB28wuZx/HcWqgQA3GXQrXDTbpvWAmZG SSiWoFP0QM8fCyFt1ka7leLGOLN8gSkczDmbNy3s9Ye28YtyjMM0kXXHKt+rOEHlEjRp fY0mTpbQbxjEbNBaP4sVA33jObcSavFl2GVttW3hz6KcVR2BguSuTXXretyDt58UfpvE Qs2npZJQn36MS/12q9JD+iYh102UgvcOmBnDwwAYNCaGd++8h29Gb/zKZCP/00rBHgMk VMHw== X-Gm-Message-State: ALoCoQm7O4enk6nn2lRUJec7L9qrsOrqqizfha2iUoZISvwYLhjhzD8s933ijS2E40JNP0P8u6Np MIME-Version: 1.0 X-Received: by 10.180.108.178 with SMTP id hl18mr15550140wib.92.1425499956154; Wed, 04 Mar 2015 12:12:36 -0800 (PST) Received: by 10.27.131.38 with HTTP; Wed, 4 Mar 2015 12:12:36 -0800 (PST) In-Reply-To: References: Date: Wed, 4 Mar 2015 12:12:36 -0800 Message-ID: From: Benjamin Bangert To: Martin Thomson Content-Type: multipart/alternative; boundary=e89a8f3ba0fd83aa9b05107c12db Archived-At: Cc: "webpush@ietf.org" , Elio Damaggio Subject: Re: [Webpush] Broadcast (was Re: webpush for http2 -02) 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, 04 Mar 2015 20:12:42 -0000 --e89a8f3ba0fd83aa9b05107c12db Content-Type: text/plain; charset=UTF-8 After reviewing it, and seeing this, I find myself in agreement. I'd greatly prefer to have a basic protocol in place and some systems using it before broadcast is tackle. On Tue, Feb 24, 2015 at 1:30 PM, Martin Thomson wrote: > The question here for me is how much a protocol can enable this and > how much is best left to services like Notification Hubs, etc... > Those services are offered to those who wish to generate push messages > and as such are less encumbered by a need for standardization. In > fact, much of their value-add derives from the flexibility and > expressiveness of their APIs. They benefit from standardization of a > push protocol in that their downstream interactions become > homogeneous, but a standard for aggregation might only act as a > constraint. > > The intent with the aggregation draft I described was to allow a > single push service provider to provide aggregation capabilities > across its endpoints. That leaves open the possibility of an > aggregator that operates across multiple push services (like the > aforementioned), It's hard to see how that could be driven from > anything but the application side, where standards are less urgent. > > At this stage, my proposal seems more like a half-measure, and I'm > reconsidering whether there is anything worth standardizing on the > aggregation front. Do you think that there is something here worth > pursuing? > > Either way, I think that our efforts are best concentrated on > completing the basic protocol first. > > > On 25 February 2015 at 08:00, Elio Damaggio wrote: > > Hi Martin, > > > > Continuing the discussion on broadcast, from our experience of designing > and operating Azure Notification Hubs, we realized that the major hurdles > for users of a push aggregation system are the following: > > > > 1. Push aggregation have to be regularly synched with other data > stores. > > Aggregation sets are application data, e.g. list of people in "platinum" > status, list of users following a certain sport team, enterprise or social > groups. The protocol has to be amenable to synching operations. In our > experience forcing explicit management of the topics (creation and > deletion) hampers these operations compared to more flexible approaches > where tags are associated to device tokens. Azure Notification Hubs is not > the only system that uses this kind of grouping; Urban Airship and Parse > (now Facebook) have a similar systems. Reference: > https://msdn.microsoft.com/en-us/library/dn530749.aspx. > > > > 2. Topic updates happen from both device and topic perspectives. > > This means that it should be possible to say "add/remove topics A,B, and > C to this user", and also "add/remove users 1,2, and 3 to/from this topic". > In a system where both of this kind of updates happen concurrently, having > to explicitly keep track of topic creation and deletion is burdensome. > > > > 3. Sending to dynamic sets. > > Given the effort that goes into synching topics between the push system > and other stores, it is usually preferable for both the users and the > implementer of the push aggregation system to allow Boolean expressions on > topics to be used as targets. Consider a sports application that sends a > reminder to everyone in Boston about a game between the Red Sox and > Cardinals. If the client app registers tags about interest in teams and > location, then the notification should be targeted to everyone in Boston > who is interested in either the Red Sox or the Cardinals. This condition > can be expressed with the following Boolean expression: (follows_RedSox || > follows_Cardinals) && location_Boston > > > > Notification Hubs, Urban Airship and Parse all support this feature. > Even if this feature is not required to be implemented in all aggregation > servers, it follows that a push endpoint, that is independent of a specific > topic and that takes a target topic (or Boolean expression on topics), is > probably better suited than a topic-specific push URL. > > > > Elio > > > > -----Original Message----- > > From: Webpush [mailto:webpush-bounces@ietf.org] On Behalf Of Martin > Thomson > > Sent: Thursday, February 12, 2015 8:41 PM > > To: Benjamin Bangert > > Cc: webpush@ietf.org > > Subject: [Webpush] Broadcast (was Re: webpush for http2 -02) > > > > On 13 February 2015 at 12:23, Benjamin Bangert > wrote: > >> Section 2: > >> - The diagram is good, but I think adding one variant for broadcast > >> messages would be good. I could see a crypto secured broadcast working > like so: > >> - Broadcast Subscribe (In contrast to normal subscribe) > >> - Browser Agent makes Provide Subscription request to Application, > >> including request (flag) to be issued the broadcast key > >> - Browser stores the broadcast key with the new subscription (rather > >> than generating its own key) > > > > I have proposed a separate document with a different model for > broadcast. In that, clients/browsers/UAs don't drive the subscription to a > broadcast, that broadcast is managed by the application sender. > > I got the sense that there wasn't a whole lot of interest in a broadcast > system in the initial stages. > > > > The advantage there is that you don't have to worry about clients having > to be able to connect to push services that they might not have a > pre-existing relationship with (and therefore federate authorization). The > disadvantage is that it drives more of the responsibility for push fanout > onto the application server. > > > > In your proposal here, how do you see the broadcast subscription being > identified and managed? Would an application request the creation of one > and then distribute it to its clients to subscribe to? > > > > _______________________________________________ > > Webpush mailing list > > Webpush@ietf.org > > https://www.ietf.org/mailman/listinfo/webpush > --e89a8f3ba0fd83aa9b05107c12db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
After reviewing it, and seeing this, I find myself in agre= ement. I'd greatly prefer to have a basic protocol in place and some sy= stems using it before broadcast is tackle.

On Tue, Feb 24, 2015 at 1:30 PM, Martin Th= omson <martin.thomson@gmail.com> wrote:
The question here for me is how much a protocol can en= able this and
how much is best left to services like Notification Hubs, etc...
Those services are offered to those who wish to generate push messages
and as such are less encumbered by a need for standardization.=C2=A0 In
fact, much of their value-add derives from the flexibility and
expressiveness of their APIs. They benefit from standardization of a
push protocol in that their downstream interactions become
homogeneous, but a standard for aggregation might only act as a
constraint.

The intent with the aggregation draft I described was to allow a
single push service provider to provide aggregation capabilities
across its endpoints.=C2=A0 That leaves open the possibility of an
aggregator that operates across multiple push services (like the
aforementioned),=C2=A0 It's hard to see how that could be driven from anything but the application side, where standards are less urgent.

At this stage, my proposal seems more like a half-measure, and I'm
reconsidering whether there is anything worth standardizing on the
aggregation front.=C2=A0 Do you think that there is something here worth pursuing?

Either way, I think that our efforts are best concentrated on
completing the basic protocol first.


On 25 February 2015 at 08:00, Elio Damaggio <elioda@microsoft.com> wrote:
> Hi Martin,
>
> Continuing the discussion on broadcast, from our experience of designi= ng and operating Azure Notification Hubs, we realized that the major hurdle= s for users of a push aggregation system are the following:
>
> 1.=C2=A0 =C2=A0 =C2=A0 Push aggregation have to be regularly synched w= ith other data stores.
> Aggregation sets are application data, e.g. list of people in "pl= atinum" status, list of users following a certain sport team, enterpri= se or social groups. The protocol has to be amenable to synching operations= . In our experience forcing explicit management of the topics (creation and= deletion) hampers these operations compared to more flexible approaches wh= ere tags are associated to device tokens. Azure Notification Hubs is not th= e only system that uses this kind of grouping; Urban Airship and Parse (now= Facebook) have a similar systems. Reference: https://msdn.micros= oft.com/en-us/library/dn530749.aspx.
>
> 2.=C2=A0 =C2=A0 =C2=A0 Topic updates happen from both device and topic= perspectives.
> This means that it should be possible to say "add/remove topics A= ,B, and C to this user", and also "add/remove users 1,2, and 3 to= /from this topic". In a system where both of this kind of updates happ= en concurrently, having to explicitly keep track of topic creation and dele= tion is burdensome.
>
> 3.=C2=A0 =C2=A0 =C2=A0 Sending to dynamic sets.
> Given the effort that goes into synching topics between the push syste= m and other stores, it is usually preferable for both the users and the imp= lementer of the push aggregation system to allow Boolean expressions on top= ics to be used as targets. Consider a sports application that sends a remin= der to everyone in Boston about a game between the Red Sox and Cardinals. I= f the client app registers tags about interest in teams and location, then = the notification should be targeted to everyone in Boston who is interested= in either the Red Sox or the Cardinals. This condition can be expressed wi= th the following Boolean expression: (follows_RedSox || follows_Cardinals) = && location_Boston
>
> Notification Hubs, Urban Airship and Parse all support this feature. E= ven if this feature is not required to be implemented in all aggregation se= rvers, it follows that a push endpoint, that is independent of a specific t= opic and that takes a target topic (or Boolean expression on topics), is pr= obably better suited than a topic-specific push URL.
>
> Elio
>
> -----Original Message-----
> From: Webpush [mailto:webp= ush-bounces@ietf.org] On Behalf Of Martin Thomson
> Sent: Thursday, February 12, 2015 8:41 PM
> To: Benjamin Bangert
> Cc: webpush@ietf.org
> Subject: [Webpush] Broadcast (was Re: webpush for http2 -02)
>
> On 13 February 2015 at 12:23, Benjamin Bangert <bbangert@mozilla.com> wrote:
>> Section 2:
>> - The diagram is good, but I think adding one variant for broadcas= t
>> messages would be good. I could see a crypto secured broadcast wor= king like so:
>>=C2=A0 =C2=A0- Broadcast Subscribe (In contrast to normal subscribe= )
>>=C2=A0 =C2=A0- Browser Agent makes Provide Subscription request to = Application,
>> including request (flag) to be issued the broadcast key
>>=C2=A0 =C2=A0- Browser stores the broadcast key with the new subscr= iption (rather
>> than generating its own key)
>
> I have proposed a separate document with a different model for broadca= st.=C2=A0 In that, clients/browsers/UAs don't drive the subscription to= a broadcast, that broadcast is managed by the application sender.
> I got the sense that there wasn't a whole lot of interest in a bro= adcast system in the initial stages.
>
> The advantage there is that you don't have to worry about clients = having to be able to connect to push services that they might not have a pr= e-existing relationship with (and therefore federate authorization).=C2=A0 = The disadvantage is that it drives more of the responsibility for push fano= ut onto the application server.
>
> In your proposal here, how do you see the broadcast subscription being= identified and managed?=C2=A0 Would an application request the creation of= one and then distribute it to its clients to subscribe to?
>
> _______________________________________________
> Webpush mailing list
> Webpush@ietf.org
> https://www.ietf.org/mailman/listinfo/webpush

--e89a8f3ba0fd83aa9b05107c12db-- From nobody Thu Mar 5 11:33:13 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 0694E1A8829 for ; Thu, 5 Mar 2015 11:33:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5w3Q9jU0tOj3 for ; Thu, 5 Mar 2015 11:33:08 -0800 (PST) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (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 D46711A87E4 for ; Thu, 5 Mar 2015 11:33:06 -0800 (PST) Received: by wghl18 with SMTP id l18so8333142wgh.5 for ; Thu, 05 Mar 2015 11:33:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=+hDZLngo01hEsfGS/64gYPth44mxKiZ3KjeLn7/JRFg=; b=bF3A5e55f1wr9kfROnrtFgO9uVFeB5ZG1o/acCzzYBYkUBlh2GE3ToGAokEuybujhZ DHqw+cGQRWv83HzYx5KqtQX4DymLMqcJ9b0zmdM6oUYSJ9aX1dpxW2poudyjZuhof9jD NXxXZk2GeMTcM3GAn/iMszNrdzahzXz40M1o5O79yOpf4PTrzl5LxhWh4Prt2h4maXrW 8jyco5E4VZYpNoWxG3XB5zePaebFWAZQ7+1xl+utWxXYVXtumnGjSUobWNvrbHrU6L7H +IvQRz1Vk0ZcEffUsyQ3A6AJV/rQvLhgnHXK5uRR/QPHYIAhwFReQatMLONhjqA0oe8D R/Pw== X-Gm-Message-State: ALoCoQkai4SLKgw1K60EQ//wWPdAQuOMswitZZsUi+Ra3fVMVeUaIlNP0oEPOvbfKy5iLIMvRz+7 MIME-Version: 1.0 X-Received: by 10.194.81.104 with SMTP id z8mr21202626wjx.45.1425583985365; Thu, 05 Mar 2015 11:33:05 -0800 (PST) Received: by 10.27.131.38 with HTTP; Thu, 5 Mar 2015 11:33:05 -0800 (PST) Date: Thu, 5 Mar 2015 11:33:05 -0800 Message-ID: From: Benjamin Bangert To: "webpush@ietf.org" Content-Type: multipart/alternative; boundary=047d7bf0c58e0bb15205108fa3fb Archived-At: Subject: [Webpush] Authorization to send messages 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, 05 Mar 2015 19:33:11 -0000 --047d7bf0c58e0bb15205108fa3fb Content-Type: text/plain; charset=UTF-8 In webpush http2-02, section 8.3 Authorization doesn't mention how the Push Service should deal with authenticating an Application Server wishing to send messages. From conversations I've heard, it does sound like all major vendors plan on requiring Application Server's to provide some form of authentication/token as GCM/APNS/etc already do. It would make sense that if the PUT to the resource URL should fail with an Authorization Required status, that there could be perhaps some way for an AppServer developer to determine how they might go about getting authorization. Perhaps an HTTP Header that indicates where the developer should go to look at access policies and how to sign-up for the required authorization. - Ben --047d7bf0c58e0bb15205108fa3fb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In webpush http2-02, section 8.3 Authorization d= oesn't mention how the Push Service should deal with authenticating an = Application Server wishing to send messages. From conversations I've he= ard, it does sound like all major vendors plan on requiring Application Ser= ver's to provide some form of authentication/token as GCM/APNS/etc alre= ady do.

It would make sense that if the PUT to the resource UR= L should fail with an Authorization Required status, that there could be pe= rhaps some way for an AppServer developer to determine how they might go ab= out getting authorization. Perhaps an HTTP Header that indicates where the = developer should go to look at access policies and how to sign-up for the r= equired authorization.

- Ben
--047d7bf0c58e0bb15205108fa3fb-- From nobody Thu Mar 5 12:43: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 D5D791A8AD4 for ; Thu, 5 Mar 2015 12:43:40 -0800 (PST) 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 KNZxMVCqOL0d for ; Thu, 5 Mar 2015 12:43:39 -0800 (PST) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::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 9908B1A8AC5 for ; Thu, 5 Mar 2015 12:43:39 -0800 (PST) Received: by oibg201 with SMTP id g201so14027365oib.10 for ; Thu, 05 Mar 2015 12:43:39 -0800 (PST) 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=MYOC47jMkwHnRcZl9PEhWVhUImfDxyajaCzzBDwTh4Y=; b=V++nrN2fEVD1Iq4EWe+Fc+uNXwFNeqlHfXuTPcgWfJDxFvDvancTXDSE6Qm48zvSrw MV/jWFhUbri/OoeutkvQ6JFpVyLQRdCJKwpjzL6MklzFaZIVxBtn9QrKoCIUAzrqjp7Q k8kTkeVUCckaohdTy0XWE6TH9SfI2ww386LtMiZ5VUnk5DG7r9u8jROCIACPU+yZDPzM CwCE4y796mCzOHPdKOwUJXiUm+Dsa+76qk9vxDTlj38xFkj9QqNl+SQ1FNC89CeM1zAS H8mccpOjU41aLP1ot1MioStX3Sv3s8uNAysGUY4fR7pyAewmFW4+oQxMAYk4ZiiLxJX3 5f0w== MIME-Version: 1.0 X-Received: by 10.182.60.197 with SMTP id j5mr8317270obr.85.1425588219131; Thu, 05 Mar 2015 12:43:39 -0800 (PST) Received: by 10.202.225.135 with HTTP; Thu, 5 Mar 2015 12:43:39 -0800 (PST) In-Reply-To: References: Date: Thu, 5 Mar 2015 12:43:39 -0800 Message-ID: From: Martin Thomson To: Benjamin Bangert Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Authorization to send messages 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, 05 Mar 2015 20:43:41 -0000 On 5 March 2015 at 11:33, Benjamin Bangert wrote: > In webpush http2-02, section 8.3 Authorization doesn't mention how the Push > Service should deal with authenticating an Application Server wishing to > send messages. From conversations I've heard, it does sound like all major > vendors plan on requiring Application Server's to provide some form of > authentication/token as GCM/APNS/etc already do. It has always been my view that knowledge of the endpoint is necessary and sufficient here. But I've gained a more nuanced view over time. In particular, Costin has suggested that we build a system whereby a sender can register, thereby establishing a continuous, if pseudonymous, identity. That helps with DoS mitigation strategies, largely because the Push Server can build up a reputation for each identity over time. From nobody Fri Mar 6 16:42:12 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60FF91A878A for ; Fri, 6 Mar 2015 16:42:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNcFhUVGLJcH for ; Fri, 6 Mar 2015 16:42:07 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0106.outbound.protection.outlook.com [207.46.100.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76BA41A8793 for ; Fri, 6 Mar 2015 16:41:54 -0800 (PST) Received: from BN1PR0301MB0626.namprd03.prod.outlook.com (25.160.171.11) by BN1PR0301MB0628.namprd03.prod.outlook.com (25.160.171.13) with Microsoft SMTP Server (TLS) id 15.1.99.9; Sat, 7 Mar 2015 00:41:52 +0000 Received: from BN1PR0301MB0626.namprd03.prod.outlook.com ([25.160.171.11]) by BN1PR0301MB0626.namprd03.prod.outlook.com ([25.160.171.11]) with mapi id 15.01.0099.004; Sat, 7 Mar 2015 00:41:53 +0000 From: Elio Damaggio To: "webpush@ietf.org" Thread-Topic: New Version Notification for draft-damaggio-webpush-http2-00.txt Thread-Index: AQHQWGwL5vf8X76DFkG0wdBJsQZrsJ0QLYtQ Date: Sat, 7 Mar 2015 00:41:53 +0000 Message-ID: References: <20150307001659.6369.72427.idtracker@ietfa.amsl.com> In-Reply-To: <20150307001659.6369.72427.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::3] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR0301MB0628; x-forefront-antispam-report: BMV:0; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(377424004)(13464003)(86362001)(54356999)(76176999)(99286002)(106116001)(86612001)(87936001)(74316001)(122556002)(40100003)(450100001)(110136001)(33656002)(92566002)(15975445007)(2501003)(2420400003)(76576001)(46102003)(1720100001)(77156002)(102836002)(19580395003)(2351001)(19580405001)(230783001)(50986999)(2950100001)(107886001)(2656002)(62966003)(2900100001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR0301MB0628; H:BN1PR0301MB0626.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5001009)(5005006); SRVR:BN1PR0301MB0628; BCL:0; PCL:0; RULEID:; SRVR:BN1PR0301MB0628; x-forefront-prvs: 05087F0C24 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: 07 Mar 2015 00:41:53.1584 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR0301MB0628 Archived-At: Subject: [Webpush] FW: New Version Notification for draft-damaggio-webpush-http2-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: Sat, 07 Mar 2015 00:42:11 -0000 QXMgbm90ZWQgaW4gdGhlIEFja25vd2xlZGdlbWVudHMgc2VjdGlvbiwgdGhpcyBpcyBhbiBpdGVy YXRpb24gb24gTWFydGluIFRob21zb24ncyBkcmFmdC10aG9tc29uLXdlYnB1c2gtaHR0cDItMDIg d2l0aCB0aGUgZm9sbG93aW5nIHByaW1hcnkgY2hhbmdlczoNCg0KMS4gQXMgc3VnZ2VzdGVkIGR1 cmluZyB0aGUgd2VicHVzaCBjaGFydGVyIGRpc2N1c3Npb24gWzFdLCBzcGVjaWZpYyBlbWJlZGRl ZCBzY2VuYXJpb3MgIChkZXZpY2VzIHJlY2VpdmluZyBwdXNoIG1lc3NhZ2VzIGZyb20gY2xvdWQg c2VydmljZXMgdGhyb3VnaCBhbiBpbnRlcm1lZGlhdGUgZ2F0ZXdheSkgYXJlIGFkZGVkIGluIHRo ZSBJbnRyb2R1Y3Rpb24NCg0KMi4gUmVnaXN0cmF0aW9uL1N1YnNjcmliZSByZXNvdXJjZXMgYXJl IHJlbW92ZWQgdG8gcmVkdWNlIHRoZSBvdmVyaGVhZCBvZiBtYWludGFpbmluZyBhIHJlZ2lzdHJh dGlvbi1zdWJzY3JpcHRpb24gcmVsYXRpb25zaGlwIGluIHRoZSBQUy4gU2lkZSBlZmZlY3RzIGFy ZSB0aGF0IGFnZ3JlZ2F0aW9uIChwZXJmb3JtaW5nIGEgR0VUIG9uIHRoZSAvbW9uaXRvciByZXNv dXJjZSB0byByZWNlaXZlIG1lc3NhZ2VzIGZvciBhbGwgc3Vic2NyaXB0aW9ucyBmb3IgYSBVQSkg YW5kIGNvbGxhcHNpbmcgKHBlcmZvcm1pbmcgYSBHRVQgb24gdGhlIHN1YnNjcmlwdGlvbiByZXNv dXJjZSB0byBnZXQgdGhlIGxhc3QgbWVzc2FnZSkgYXJlIG5vIGxvbmdlciBzdXBwb3J0ZWQuIA0K DQozLiBEZWxpdmVyeSBjb25maXJtYXRpb25zIChyZWNlaXB0cykgYXJlIGFkZGVkLiANCiAgICBh LiBBIEpTT04gcmVxdWVzdCBtZXNzYWdlIGZvcm1hdCBpcyBhZGRlZCB0byBlbmFibGUgcmVjZWlw dHMgYW5kIG90aGVyIHBvdGVudGlhbCBmZWF0dXJlcyBzdWNoIGFzIFRUTCBhbmQgbXVsdGljYXN0 LiBPbmx5IFRUTCBpcyAgIA0KICAgICAgICByZWZlcmVuY2VkIGluIHRoaXMgZHJhZnQuIA0KICAg Yi4gVXBkYXRlZCBTZWN0aW9uIDcuNCBJbXBsaWNhdGlvbnMgZm9yIEFwcGxpY2F0aW9uIFJlbGlh YmlsaXR5IHRvIHJlZmxlY3QgdGhlIGF2YWlsYWJpbGl0eSBvZiByZWNlaXB0cw0KDQpXZeKAmWQg ZGVmaW5pdGVseSBhcHByZWNpYXRlIGZlZWRiYWNrL3F1ZXN0aW9ucyDigJMgdGVjaG5pY2FsIG9y IGVkaXRvcmlhbC4gDQoNClsxXSBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv d2VicHVzaC9jdXJyZW50L21zZzAwMDY5Lmh0bWwNCg0KRWxpbw0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IEZyaWRheSwgTWFyY2ggNiwgMjAxNSA0OjE3IFBN DQpUbzogRWxpbyBEYW1hZ2dpbzsgQnJpYW4gUmF5bW9yIChNUyBPUEVOIFRFQ0gpOyBFbGlvIERh bWFnZ2lvOyBCcmlhbiBSYXltb3IgKE1TIE9QRU4gVEVDSCkNClN1YmplY3Q6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZGFtYWdnaW8td2VicHVzaC1odHRwMi0wMC50eHQNCg0K DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZGFtYWdnaW8td2VicHVzaC1odHRwMi0wMC50 eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQnJpYW4gUmF5bW9yIGFuZCBw b3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWRhbWFnZ2lvLXdl YnB1c2gtaHR0cDINClJldmlzaW9uOgkwMA0KVGl0bGU6CQlHZW5lcmljIEV2ZW50IERlbGl2ZXJ5 IFVzaW5nIEhUVFAgUHVzaA0KRG9jdW1lbnQgZGF0ZToJMjAxNS0wMy0wNg0KR3JvdXA6CQlJbmRp dmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMTgNClVSTDogICAgICAgICAgICBodHRwOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1kYW1hZ2dpby13ZWJwdXNoLWh0dHAyLTAw LnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWRhbWFnZ2lvLXdlYnB1c2gtaHR0cDIvDQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtZGFtYWdnaW8td2VicHVzaC1odHRwMi0wMA0KDQoNCkFic3Ry YWN0Og0KICAgQSBzaW1wbGUgcHJvdG9jb2wgZm9yIHRoZSBkZWxpdmVyeSBvZiByZWFsdGltZSBl dmVudHMgdG8gdXNlciBhZ2VudHMNCiAgIGlzIGRlc2NyaWJlZC4gIFRoaXMgc2NoZW1lIHVzZXMg SFRUUC8yIHNlcnZlciBwdXNoLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxl YXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRp bWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUg YXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Wed Mar 11 21:23:27 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 25A211A8A4F for ; Wed, 11 Mar 2015 21:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.447 X-Spam-Level: * X-Spam-Status: No, score=1.447 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_BRBL_LASTEXT=1.449, SPF_HELO_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 sLgYJOYI1qOg for ; Wed, 11 Mar 2015 21:23:22 -0700 (PDT) Received: from gator4135.hostgator.com (gator4135.hostgator.com [192.185.4.147]) (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 A49C71A8A4D for ; Wed, 11 Mar 2015 21:23:22 -0700 (PDT) Received: from [71.204.141.163] (port=32911 helo=[10.0.1.29]) by gator4135.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1YVueX-0007hn-TB for webpush@ietf.org; Wed, 11 Mar 2015 23:23:21 -0500 From: Shida Schubert Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <6DBCBF64-9C57-408C-AD9E-E08906FD0120@ntt-at.com> Date: Wed, 11 Mar 2015 21:23:16 -0700 To: webpush@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) 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: 71.204.141.163 X-Exim-ID: 1YVueX-0007hn-TB X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([10.0.1.29]) [71.204.141.163]:32911 X-Source-Auth: shida@agnada.com X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== Archived-At: Subject: [Webpush] Agenda Requests 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, 12 Mar 2015 04:23:25 -0000 All; I am really happy to see some activities on the list. We have received a request for agenda time on IETF92 on the following draft. draft-damaggio-webpush-http2 If you want to present a draft at the meeting, please let us know. Shida From nobody Thu Mar 12 10:00:50 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 13ED41A1B39 for ; Thu, 12 Mar 2015 10:00:48 -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 G0GOQirr2tcq for ; Thu, 12 Mar 2015 10:00:46 -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 B7F971A1B16 for ; Thu, 12 Mar 2015 10:00:46 -0700 (PDT) Received: by obcwo20 with SMTP id wo20so15321831obc.2 for ; Thu, 12 Mar 2015 10:00:46 -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=dpWRBSA8Fe/UMCkdI206lUsSdU6xDfQUBrZepOA34yY=; b=E77vY7V+Y6VC97v/CDMK4Kqt1pnBVWtkjnLGT9CIOsWZgdBxCn3OnjQLwKBsKqzCma V+acU7ZJC0TXxHPTEJ0S8O7WUuhHn2JuHhDbv1q6l5t+1sjq7Xt0R21v68w8lVIco+VF WCzIJ+SEV/yxSv1fYCIh7y9bIbsUnT+FPrsk0wBndMgtt2kHHL0nEi3TSv1pX6cK6iPR a4TkNVmd3DDrQnbUXJtY3Uv4laxCv5RD5wkdvsi9dbJilbwFIObCfL/59KddzNWPWYZz 3EYJ9HrfrS1F3s/+mjx7n+MXVGBdDAiYJzvuPTh5sN0aKSRjDJiGyTMUFr3RWdvJm5Ht 7zNw== MIME-Version: 1.0 X-Received: by 10.182.249.51 with SMTP id yr19mr24010929obc.30.1426179646105; Thu, 12 Mar 2015 10:00:46 -0700 (PDT) Received: by 10.202.225.135 with HTTP; Thu, 12 Mar 2015 10:00:46 -0700 (PDT) Date: Thu, 12 Mar 2015 10:00:46 -0700 Message-ID: From: Martin Thomson To: "webpush@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Webpush] Subscription split 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, 12 Mar 2015 17:00:48 -0000 Subscriptions are currently identified by a single URI. That URI is used to identify the subscription to the user agent and is also used by the application server to request delivery of messages. I discovered this when Brian Raymor noted that the text on subscription removal was a little weak. In attempting to fix it, I found that the current structure is awkward. You need some unspecified authentication of clients if you want to authorize a request to remove a subscription. I see a few options, and I'd like some input: 1. This is OK. It's relatively straightforward to determine that the DELETE request is being made by the same client that created the subscription. Trivially, you could set a cookie. 2. Split the subscription. Subscriptions would be identified privately with one identifier that the client sees and uses, and a "public" identifier that is distributed to the application server. That makes authorization for removal a simple matter because only the private identifier is needed. 3. Don't specify subscription removal. Both 1 and 2 have roughly equivalent security properties (in the absence of token binding), though stronger authentication is possible either way. Option 3 has the worrying characteristic whereby a user agent is unable to selectively revoke push access if it discovered that a particular application is behaving badly. On the other hand, these events are rare enough that perhaps deleting the registration is acceptable. The cost of option 2 is a modest increase in complexity, a new link relation type and some less visible effects on the HTTP side of things. The two resources would have linked state that would not be visible at the HTTP layer; a single resource potentially allows generic HTTP-layer processing, whereas a split would require more specific logic. On the other hand option 2 makes it marginally easier to do what Microsoft have proposed and remove the concept of a registration. (I don't personally think that is a good idea, but I'm not violently opposed to it either.) From nobody Thu Mar 12 15:07: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 D932A1A009B for ; Thu, 12 Mar 2015 15:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lerp8sYsAMlN for ; Thu, 12 Mar 2015 15:07:18 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0705.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::705]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2145E1A8790 for ; Thu, 12 Mar 2015 15:07:14 -0700 (PDT) Received: from BN1PR0301MB0626.namprd03.prod.outlook.com (25.160.171.11) by BN1PR0301MB0628.namprd03.prod.outlook.com (25.160.171.13) with Microsoft SMTP Server (TLS) id 15.1.106.15; Thu, 12 Mar 2015 22:06:56 +0000 Received: from BN1PR0301MB0626.namprd03.prod.outlook.com ([25.160.171.11]) by BN1PR0301MB0626.namprd03.prod.outlook.com ([25.160.171.11]) with mapi id 15.01.0106.007; Thu, 12 Mar 2015 22:06:55 +0000 From: Elio Damaggio To: Martin Thomson , "webpush@ietf.org" Thread-Topic: [Webpush] Subscription split Thread-Index: AQHQXOYbl+TokCcTGk2oyVBS18juRJ0ZYutg Date: Thu, 12 Mar 2015 22:06:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::3] authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR0301MB0628; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(106116001)(2656002)(76176999)(54356999)(2501003)(76576001)(50986999)(40100003)(46102003)(19580405001)(19580395003)(107886001)(77156002)(74316001)(62966003)(2950100001)(86362001)(2900100001)(92566002)(33656002)(87936001)(102836002)(15975445007)(86612001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR0301MB0628; H:BN1PR0301MB0626.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002009)(5005006); SRVR:BN1PR0301MB0628; BCL:0; PCL:0; RULEID:; SRVR:BN1PR0301MB0628; x-forefront-prvs: 05134F8B4F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2015 22:06:55.9307 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR0301MB0628 Archived-At: Subject: Re: [Webpush] Subscription split 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, 12 Mar 2015 22:07:20 -0000 +1 for #2. Brian Raymor and I were thinking about using two identifiers for subscripti= ons, one with send rights (for the AS, or "public") and one with monitor/de= lete rights (for the UA or "private"). The main idea is that those identifiers can be tokens signed by the Push Se= rver. Each token contains the unique subscription id plus the claims that t= hey enable (send vs monitor+delete). In general, having two identifiers increases security by distributing only = the rights that are required to be distributed (i.e. send rights to the AS)= , and it just seems a good security practice. Elio -----Original Message----- From: Webpush [mailto:webpush-bounces@ietf.org] On Behalf Of Martin Thomson Sent: Thursday, March 12, 2015 10:01 AM To: webpush@ietf.org Subject: [Webpush] Subscription split Subscriptions are currently identified by a single URI. That URI is used t= o identify the subscription to the user agent and is also used by the appli= cation server to request delivery of messages. I discovered this when Brian Raymor noted that the text on subscription rem= oval was a little weak. In attempting to fix it, I found that the current = structure is awkward. You need some unspecified authentication of clients i= f you want to authorize a request to remove a subscription. I see a few options, and I'd like some input: 1. This is OK. It's relatively straightforward to determine that the DELET= E request is being made by the same client that created the subscription. = Trivially, you could set a cookie. 2. Split the subscription. Subscriptions would be identified privately wit= h one identifier that the client sees and uses, and a "public" identifier t= hat is distributed to the application server. That makes authorization for removal a simple matter because only the priva= te identifier is needed. 3. Don't specify subscription removal. Both 1 and 2 have roughly equivalent security properties (in the absence of= token binding), though stronger authentication is possible either way. Option 3 has the worrying characteristic whereby a user agent is unable to = selectively revoke push access if it discovered that a particular applicati= on is behaving badly. On the other hand, these events are rare enough that= perhaps deleting the registration is acceptable. The cost of option 2 is a modest increase in complexity, a new link relatio= n type and some less visible effects on the HTTP side of things. The two r= esources would have linked state that would not be visible at the HTTP laye= r; a single resource potentially allows generic HTTP-layer processing, wher= eas a split would require more specific logic. On the other hand option 2 makes it marginally easier to do what Microsoft = have proposed and remove the concept of a registration. (I don't personall= y think that is a good idea, but I'm not violently opposed to it either.) _______________________________________________ Webpush mailing list Webpush@ietf.org https://www.ietf.org/mailman/listinfo/webpush From nobody Fri Mar 13 11:28:03 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 4C14E1A009E for ; Fri, 13 Mar 2015 11:28:01 -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 bMp1DPSudbnK for ; Fri, 13 Mar 2015 11:28:00 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::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 EED3C1A0282 for ; Fri, 13 Mar 2015 11:27:59 -0700 (PDT) Received: by oiav1 with SMTP id v1so5536300oia.4 for ; Fri, 13 Mar 2015 11:27:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=5AxnITHTtoPeec5rvAmZTxfl6xwPq4SKcTPIXPNGzWM=; b=uwEM/fv29EBJ31patVx07lYAtM1dxE/ISRFzHBp8r5WbyW5Z6T3PBexNusN4epnEBw WmaO6NR00ch+pcchKdO7chbGM1uOr+5UCYQBCMHngOtTw2HTRRT0UEQLN2Pm6e96dvPm xpzP/aAFJ5bozVOXl2vflKXz01EooIb1F5dqeYu3Jt4ZYLvsZpPYdvL6c3PJtOPgKm1/ 4f8MEs0Ncxoi1bnP4z9qO0LrX5z46ifFpvyt4rKgI2kM0nL3ESJOhKRl/4NsKf3NLpjQ z80gvBVPL84rJS57LZuibL2Xi5SMjws58YCFuc7wTbG1kOFMlfQeVT0XH0Eij87kdSS2 c/vg== MIME-Version: 1.0 X-Received: by 10.202.106.14 with SMTP id f14mr37774207oic.39.1426271279450; Fri, 13 Mar 2015 11:27:59 -0700 (PDT) Received: by 10.202.86.20 with HTTP; Fri, 13 Mar 2015 11:27:59 -0700 (PDT) In-Reply-To: <59A39E87EA9F964A836299497B686C351F909E17@CAFRFD1MSGUSRIA.ITServices.sbc.com> References: <59A39E87EA9F964A836299497B686C351F909E17@CAFRFD1MSGUSRIA.ITServices.sbc.com> Date: Fri, 13 Mar 2015 11:27:59 -0700 Message-ID: From: Martin Thomson To: "SULLIVAN, BRYAN L" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "webpush@ietf.org" , Elio Damaggio Subject: Re: [Webpush] Subscription split 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, 13 Mar 2015 18:28:01 -0000 On 12 March 2015 at 15:45, SULLIVAN, BRYAN L wrote: > If the client (web app running on the user's device) has sole rights to s= ubscription management, how do you handle the case in which the client lose= s the subscription identifier/token (e.g. UA is reset, loses cookies, etc) = and the client can't then stop the server from sending messages? The UA has to explicitly request message delivery. So, if it loses a subscription, it can choose to drop the registration and try again. Or, as Elio would have it, you need to ask for messages for each subscription independently, so you can't get messages delivered for contexts you have forgotten about. From nobody Fri Mar 13 23:05:43 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 F05881AC405 for ; Fri, 13 Mar 2015 23:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjSLzrp2jdv2 for ; Fri, 13 Mar 2015 23:05:39 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61ACA1AC402 for ; Fri, 13 Mar 2015 23:05:39 -0700 (PDT) Received: by igbue6 with SMTP id ue6so3010934igb.1 for ; Fri, 13 Mar 2015 23:05:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CC8sC/yIynO2PI2Zbz+iY0kLvvHSIsMKOeuS/9AUD1A=; b=xmBnTJfb0rxt6YnxUUCLCy5Zaa1OlHWJUfXdj6zEBB1d99DoKb9v2CW7xpls51vRzJ mqyUzDLoiwthwYNjcCGb35jR1yJh6khXwkBYJKRjwUPTc4xht4wJBCUHUbsxkbt2ZPcI CrIYh/hgr6zQXqSidoRi5qU8AUoIiEKo3/W5/xr0jgy/Jl5R4Pjs0RCf+XemiALTVPMI +gSCQqWZSJiMVcQ9s8LH0qXGEcVWdKw1A1CeTqB8Uzp4wiGayC9C/2h4JoADRIy3jxlb +W8gvIAF+E3Dpyvbwu7E1bNVAD0DcLFjOunmhtdrAw5OTUbBsFzIYecCe1lOA9ghCs9Y rVIg== MIME-Version: 1.0 X-Received: by 10.107.35.70 with SMTP id j67mr38334392ioj.51.1426313138843; Fri, 13 Mar 2015 23:05:38 -0700 (PDT) Received: by 10.64.117.130 with HTTP; Fri, 13 Mar 2015 23:05:38 -0700 (PDT) In-Reply-To: References: Date: Fri, 13 Mar 2015 23:05:38 -0700 Message-ID: From: Costin Manolache To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1140dcf2fabb300511396710 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Subscription split X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 06:05:42 -0000 --001a1140dcf2fabb300511396710 Content-Type: text/plain; charset=UTF-8 I like option 2 - the subscription will need at least a key pair for encryption, with the private key only on the UA. The private key can be used to sign removal requests, or any other request that would authenticate the client as owning the subscription. Costin On Thu, Mar 12, 2015 at 10:00 AM, Martin Thomson wrote: > Subscriptions are currently identified by a single URI. That URI is > used to identify the subscription to the user agent and is also used > by the application server to request delivery of messages. > > I discovered this when Brian Raymor noted that the text on > subscription removal was a little weak. In attempting to fix it, I > found that the current structure is awkward. You need some unspecified > authentication of clients if you want to authorize a request to remove > a subscription. > > I see a few options, and I'd like some input: > > 1. This is OK. It's relatively straightforward to determine that the > DELETE request is being made by the same client that created the > subscription. Trivially, you could set a cookie. > > 2. Split the subscription. Subscriptions would be identified > privately with one identifier that the client sees and uses, and a > "public" identifier that is distributed to the application server. > That makes authorization for removal a simple matter because only the > private identifier is needed. > > 3. Don't specify subscription removal. > > Both 1 and 2 have roughly equivalent security properties (in the > absence of token binding), though stronger authentication is possible > either way. > > Option 3 has the worrying characteristic whereby a user agent is > unable to selectively revoke push access if it discovered that a > particular application is behaving badly. On the other hand, these > events are rare enough that perhaps deleting the registration is > acceptable. > > The cost of option 2 is a modest increase in complexity, a new link > relation type and some less visible effects on the HTTP side of > things. The two resources would have linked state that would not be > visible at the HTTP layer; a single resource potentially allows > generic HTTP-layer processing, whereas a split would require more > specific logic. > > On the other hand option 2 makes it marginally easier to do what > Microsoft have proposed and remove the concept of a registration. (I > don't personally think that is a good idea, but I'm not violently > opposed to it either.) > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > --001a1140dcf2fabb300511396710 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I like option 2 - the subscription will need at least a ke= y pair for encryption, with the private key only on the UA. The private key= can be used to sign removal requests, or any other request that would auth= enticate the client as owning the subscription.=C2=A0

Costin

On Thu, Mar 12, 2015 at 10:00 AM, Martin Thomson <mar= tin.thomson@gmail.com> wrote:
Subscriptions are currently identified by a single URI.=C2=A0 That URI i= s
used to identify the subscription to the user agent and is also used
by the application server to request delivery of messages.

I discovered this when Brian Raymor noted that the text on
subscription removal was a little weak.=C2=A0 In attempting to fix it, I found that the current structure is awkward. You need some unspecified
authentication of clients if you want to authorize a request to remove
a subscription.

I see a few options, and I'd like some input:

1. This is OK.=C2=A0 It's relatively straightforward to determine that = the
DELETE request is being made by the same client that created the
subscription.=C2=A0 Trivially, you could set a cookie.

2. Split the subscription.=C2=A0 Subscriptions would be identified
privately with one identifier that the client sees and uses, and a
"public" identifier that is distributed to the application server= .
That makes authorization for removal a simple matter because only the
private identifier is needed.

3. Don't specify subscription removal.

Both 1 and 2 have roughly equivalent security properties (in the
absence of token binding), though stronger authentication is possible
either way.

Option 3 has the worrying characteristic whereby a user agent is
unable to selectively revoke push access if it discovered that a
particular application is behaving badly.=C2=A0 On the other hand, these events are rare enough that perhaps deleting the registration is
acceptable.

The cost of option 2 is a modest increase in complexity, a new link
relation type and some less visible effects on the HTTP side of
things.=C2=A0 The two resources would have linked state that would not be visible at the HTTP layer; a single resource potentially allows
generic HTTP-layer processing, whereas a split would require more
specific logic.

On the other hand option 2 makes it marginally easier to do what
Microsoft have proposed and remove the concept of a registration.=C2=A0 (I<= br> don't personally think that is a good idea, but I'm not violently opposed to it either.)

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

--001a1140dcf2fabb300511396710-- From nobody Mon Mar 16 22:26:02 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 011901A0026 for ; Mon, 16 Mar 2015 22:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.447 X-Spam-Level: * X-Spam-Status: No, score=1.447 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_BRBL_LASTEXT=1.449, SPF_HELO_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 1YQmNAvt3AEO for ; Mon, 16 Mar 2015 22:25:56 -0700 (PDT) Received: from gator4135.hostgator.com (gator4135.hostgator.com [192.185.4.147]) (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 B68EF1A0022 for ; Mon, 16 Mar 2015 22:25:56 -0700 (PDT) Received: from [71.204.141.163] (port=48881 helo=[10.0.1.29]) by gator4135.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1YXk0p-0006De-VF for webpush@ietf.org; Tue, 17 Mar 2015 00:25:56 -0500 From: Shida Schubert Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 16 Mar 2015 22:25:54 -0700 To: webpush@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) 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: 71.204.141.163 X-Exim-ID: 1YXk0p-0006De-VF X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([10.0.1.29]) [71.204.141.163]:48881 X-Source-Auth: shida@agnada.com X-Email-Count: 7 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== Archived-At: Subject: [Webpush] Agenda for IETF92 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 05:26:00 -0000 Hi All; I posted the agenda for the upcoming meting below; http://www.ietf.org/proceedings/92/agenda/agenda-92-webpush We may add another item on the list but I am waiting from the author of = the book if he will be attending the upcoming IETF to present the draft.=20= Comments are welcome. Shida= From nobody Sun Mar 22 23:16:00 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC8011A88A5 for ; Sun, 22 Mar 2015 23:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.722 X-Spam-Level: X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hOWdAAb2mrP for ; Sun, 22 Mar 2015 23:15:56 -0700 (PDT) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) (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 0D0FD1A88A6 for ; Sun, 22 Mar 2015 23:15:55 -0700 (PDT) Received: by lbcgn8 with SMTP id gn8so111200446lbc.2 for ; Sun, 22 Mar 2015 23:15:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=RL15u9dbqKcqzm0+ILAJDbma4euDa+GzN+TdrQvX4ys=; b=Q9YlohHFtzZeQsea59s41hNePHCrSe3TsXVNoAWvxEMsqQDLMEe95gsktiaknTaUkr s92oqAxDSlw/nhg1VUtvgkPCkOsSbTkamQX//TzvmImms7dT+UQ1EuNwBUxcoRWvyIhJ TYZ1tBO9dUkgsPgrM7hAM0jJv0E+eg+OyW10y3V7isZCyFpQxzSaX/9SZ0v6tvDj1hVF ztYLzd5YSSzIaVFpm9+CxkXtFIvV+EeRprAqrSsY+ftckjLLQgTuiD+KnsZVNcxdPs43 dhMhxbUwU135oPuiAIr1y40ydz5oLPykanVFMMb4zgJrqi/YBO5Fkd4aN3oJJ5ulWdN4 WscA== X-Gm-Message-State: ALoCoQn+09WpEgrAvgHYr2lCz8LHfnF4ml6ISyzSo/sfAGl8T43Lg68G+Y4BFsPGonP92v9dFHJj MIME-Version: 1.0 X-Received: by 10.112.110.231 with SMTP id id7mr82658672lbb.28.1427091353368; Sun, 22 Mar 2015 23:15:53 -0700 (PDT) Received: by 10.25.212.5 with HTTP; Sun, 22 Mar 2015 23:15:53 -0700 (PDT) Date: Mon, 23 Mar 2015 00:15:53 -0600 Message-ID: From: Eduardo Gueiros To: "webpush@ietf.org" Content-Type: multipart/alternative; boundary=001a1134daf62e12b20511ee99d4 Archived-At: Cc: hiro@awa.sfc.keio.ac.jp Subject: [Webpush] Review draft-nakajima-webpush-problem-statement-00 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: Mon, 23 Mar 2015 06:15:59 -0000 --001a1134daf62e12b20511ee99d4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable General Overview In general, I haven=E2=80=99t necessarily found major issues with he draft = besides grammar errors. I have, however a few inquiries as stated below. No Major issues Minor issues - In the abstract the following statement =E2=80=9C=E2=80=A6delivering even= ts based on the registration=E2=80=A6=E2=80=9D Shouldn=E2=80=99t the subscription be includ= ed as well? If an application registers but does not subscribe for a resource it won=E2=80=99= t get anything. - Suggestion: Change: =E2=80=9CEmergency Alerting notification=E2=80=9D To: =E2=80=9CEmergency Notifications=E2=80=9D - 3.1 paragraph 4 If a device is not connected (3GPP, Wifi=E2=80=A6or otherwise without means= to access remote data) how could emergency notifications be derived (e.g. Desktop without ethernet or wifi)? What do you propose? - There is some general clarification needed in the text and I have suggested modifications in the =E2=80=98Nits & Grammar=E2=80=99 section of = this review. Nits & Grammar Abstract, paragraph 1 > Web Push protocol provides a means of delivering the events to > clients based on the registration made by the application. Proposed text for clarification and grammar: The Web Push Protocol [I-D.thomson-webpush-http2] provides means of delivering events to clients based on registration and subscriptions made the an application. Abstract, paragraph 1 > Also, the emergency alert notification system has been developed and > deployed widely with mobile phones or smartphones, but has not deployed > to Web-only devices. Proposed text for clarification and grammar: Emergency notification systems have been developed and deployed to mobile phones, but not to web-only devices. Abstract, paragraph 2 > This document outlines various existing emergency alert notification > system in other protocols and use cases with their requirements. Proposed text: This document outlines various existing emergency notification systems, their protocols and use cases, and explains how Web Push can help pushing emergency notifications to web-only devices. Introduction, paragraph 2 >Also, emergency alerting is an apparently important feature of > telecommunication network such as cellular networks, allowing the > governments or authorities to send a warnings of natural disaster or > accident. Proposed text for clarification and grammar: Emergency notifications is an important feature of telecommunications networks such as cellular networks, allowing governments and public safety entities to send many types of warnings (eg. natural disasters, abductions, accidents, etc). 1. Introduction, paragraph 3 > emergency notification system Proposed text for clarification and grammar: emergency notification systems 3.1 paragraph 2 > and merged into Public Warning System (PWS) Proposed text for clarification and grammar: and merged into the/a Public Warning System 3.1 paragraph 2 >PWS provides several functions for example: Proposed text for clarification and grammar: PWS provides several functions, for example: 3.1 paragraph 3 > Addition to PWS, some work has been made to distribute the emergency > alerting notification on different network. Proposed text for clarification and grammar: In addition to PWS, some work has been done to send emergency notifications through different networks. 3.1 paragraph 4 > Those previous contributions have been made to develop the method to > distribute an emergency alerting notification. Comment: The phrase is not clear. You already stated previously that work has been done. 3.1 paragraph 5 Comment: Are you suggesting Web Push to handle spacial data in order to deliver location based events? If a client is mobile, it would require the client to update their subscription with their current location on a timely manner in order to receive accurate notifications. This might be slightly out of the scope as Web Push as it=E2=80=99s purpose is simply to push an event ba= sed on the subscription. The means and computations through which the event is generated is apart from the Web Push, in my opinion. 3.2 paragraph 2 > Digital signage has widely deployed among the world. Suggested change: Digital signage has been widely deployed around the world. 3.2 paragraph 2 > Signage located at public area such as train station or street play a > significant role in natural disaster or accident by providing the > evacuation alert or correct informations. Suggested change: Signage located in public areas, such as on train stations or on the street, play a significant role in natural disaster or accidents by providing evacuation alerts or useful information. 3.2 paragraph 2 > Recent few years W3C worked on Web-based signage which > has Web browser is embedded, allowing to display or play Web content. > Disaster use case is proposed in W3C Web-based Signage Scenarios and > Use Cases [SignageUseCase]. Suggested change: In recent years, the W3C has worked on Web-based signage which has a web browser embedded, allowing it to display web content. The disaster notification use case is proposed in the W3C Web-based Signage Scenarios and Use Cases [SignageUseCase]. 3.2 paragraph 3 Comment: So, are you suggesting using Web Push for =E2=80=9Cminor=E2=80=9D notificat= ions instead of using the more =E2=80=9Cover-the-top=E2=80=9D PWS approach? I agree. PWS sh= ould be used for emergency or general notifications from public entities. If a user desires to know precipitation levels in an area, the user should be able to subscribe with a service that provides that data. Regards, Eduardo Gueiros Jive Communications, Inc egueiros at jive.com --001a1134daf62e12b20511ee99d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

General Overview

In general, I haven=E2=80=99t necessarily found major issues = with he draft besides grammar errors. I have, however a few inquiries as st= ated below.=C2=A0

No Major issues

Minor issues

- In the abstract the following statement = =E2=80=9C=E2=80=A6delivering events based on the registration=E2=80=A6=E2= =80=9D Shouldn=E2=80=99t the subscription be included as well? If an applic= ation registers but does not subscribe for a resource it won=E2=80=99t get = anything.=C2=A0

- Suggestion:
Change: =E2=80=9CEmergency Alerting notific= ation=E2=80=9D
To: =E2=80=9CEmergency Notifications=E2=80=9D

- 3.1 paragraph 4

If a device is not connected (3GPP, Wifi=E2= =80=A6or otherwise without means to access remote data) how could emergency= notifications be derived (e.g. Desktop without ethernet or wifi)? What do = you propose?

- There is some general clarification needed= in the text and I have suggested modifications in the =E2=80=98Nits & = Grammar=E2=80=99 section of this review.=C2=A0

Nits & Grammar

Abstract, paragraph 1
> Web Pus= h protocol provides a means of delivering the events to
> clients bas= ed on the registration made by the application. =C2=A0

Proposed text for clarification and grammar:=C2=A0

=C2=A0The Web Push Protocol [I-D.thomson-web= push-http2] provides means of delivering events to clients based on registr= ation and subscriptions made the an application.=C2=A0

Abstract, paragraph 1
> Also, t= he emergency alert notification system has been developed and=C2=A0
>= deployed widely with mobile phones or smartphones, but has not deployed &g= t; to Web-only devices.

Proposed text for clarification and grammar:=C2=A0

=C2=A0Emergency notification systems have be= en developed and deployed to mobile phones, but not to web-only devices.=C2= =A0

Abstract, paragraph 2

> This document outlines various existing= emergency alert notification
> system in other protocols and = use cases with their requirements.

Proposed text:

=C2=A0This document outlines various existin= g emergency notification systems, their protocols and use cases, and explai= ns how Web Push can help pushing emergency notifications to web-only device= s.=C2=A0

Introduction, paragraph 2
>Also= , emergency alerting is an apparently important feature of
>=C2=A0 te= lecommunication network such as cellular networks, allowing the
>=C2= =A0 governments or authorities to send a warnings of natural disaster or>=C2=A0 accident.

Proposed text for clarification and grammar:

=C2=A0Emergency notifications is an importan= t feature of telecommunications networks such as cellular networks, allowin= g governments and public safety entities to send many types of warnings (eg= . natural disasters, abductions, accidents, etc).=C2=A0

1. Introduction, paragraph 3
> emergency notification s= ystem

Proposed text for clarification and grammar:

emergency notification systems

3.1 paragraph 2
> and merged in= to Public Warning System (PWS)

Proposed text for clarifica= tion and grammar:

and merged into the/a Public Warning System<= /span>

3.1 paragraph 2
>PWS provides several functions for exa= mple:

Proposed text for clarification and grammar:

=

PWS provides several functions, for example:=

3.1 paragraph 3
> Addition to PWS, some work has been m= ade to distribute the emergency
> alerting notification on different = network.

Proposed text for clarification and g= rammar:

In addition to PWS, some work has been done = to send emergency notifications through different networks.=C2=A0

3.1 paragraph 4
> Those previous contributions have bee= n made to develop the method to
> distribute an emergency alerting no= tification.

Comment:

The phrase is not clear. You already stated = previously that work has been done.

3.1 paragraph 5
Comment:

Are you suggesting Web Push to handle spacia= l data in order to deliver location based events? If a client is mobile, it= would require the client to update their subscription with their current l= ocation on a timely manner in order to receive accurate notifications. This= might be slightly out of the scope as Web Push as it=E2=80=99s purpose is = simply to push an event based on the subscription. The means and computatio= ns through which the event is generated is apart from the Web Push, in my o= pinion.=C2=A0

3.2 paragraph 2
> Digital signage has widely deployed a= mong the world.

Suggested change:

Digital signage has been widely deployed aro= und the world.=C2=A0


3.2 paragraph 2
> Signage locat= ed at public area such as train station or street play a
> significa= nt role in natural disaster or accident by providing the
> evacuatio= n alert or correct informations.

Suggested change:

Signage located in public areas, such as on = train stations or on the street, play a significant role in natural disaste= r or accidents by providing evacuation alerts or useful information.=

3.2 paragraph 2
> Recent few years W3C worked on Web-ba= sed signage which
> has Web browser is embedded, allowing to display = or play Web content.
>=C2=A0 Disaster use case is proposed in W3C Web= -based Signage Scenarios and
>=C2=A0 Use Cases [SignageUseCase].

Suggested change:

In recent years, the W3C has worked on Web-b= ased signage which has a web browser embedded, allowing it to display web c= ontent. The disaster notification use case is proposed in the W3C Web-based= Signage Scenarios and Use Cases [SignageUseCase].

3.2 paragraph 3
Comment:

So, are you suggesting using Web Push for = =E2=80=9Cminor=E2=80=9D notifications instead of using the more =E2=80=9Cov= er-the-top=E2=80=9D PWS approach? I agree. PWS should be used for emergency= or general notifications from public entities. If a user desires to know p= recipitation levels in an area, the user should be able to subscribe with a= service that provides that data.=C2=A0

Regards,=C2=A0

Eduardo Gueiros
Jive Communication= s, Inc
egueiros at jive.com

--001a1134daf62e12b20511ee99d4-- From nobody Sun Mar 22 23:21:22 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 9B7AD1A88AB for ; Sun, 22 Mar 2015 23:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOpb21hCjy7J for ; Sun, 22 Mar 2015 23:21:19 -0700 (PDT) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) (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 B97131A88C5 for ; Sun, 22 Mar 2015 23:21:16 -0700 (PDT) Received: by labe2 with SMTP id e2so50831164lab.3 for ; Sun, 22 Mar 2015 23:21:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=H6yTvn1tnhWJ3s7JEmVEP5UhBEcmXfljtjbvC16BBms=; b=J6x0VSpz+mlxU6rtNbqU/8jas+DUvJh+pqVC6wSXG7kvlQte1OSbJbH+ktvImMagzP iq5D/Ms/DD6aayYRllIWXJiX8pVL7mH7e/igga3sYBISdoDLj0taxUcdVKALxeZBr+u8 TgllC96P3fIJUyIKAu9IgTCbiYUy/4JFJwGreavo3cF/48M0ox+Ld/asKLnb9/6nBAvl n8Tk8BMsIgNDDxtqMsYZ0KNe2t2gJcFZrc5wJ9j/3lW03lRutBJgPicdGjqLC6cI8bGd 4b4Dw8zQR5Dq4zGKJ4DXpV4Hjzg8j9S0GbpVh891WzFIiTWOIfevbHs4FDHGVmpIIows M+5A== X-Gm-Message-State: ALoCoQmtEk0leJoMUMzovgJo3/jD6X0csgbdJj9lLCrf8ZBCW72hy8k2jVBDiPJkNaBfWJyWz7S8 MIME-Version: 1.0 X-Received: by 10.152.45.9 with SMTP id i9mr4239755lam.2.1427091675153; Sun, 22 Mar 2015 23:21:15 -0700 (PDT) Received: by 10.25.212.5 with HTTP; Sun, 22 Mar 2015 23:21:15 -0700 (PDT) Date: Mon, 23 Mar 2015 00:21:15 -0600 Message-ID: From: Eduardo Gueiros To: "webpush@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2750a5c1f2a0511eeac9b Archived-At: Subject: [Webpush] Review draft-damaggio-webpush-http2-00 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: Mon, 23 Mar 2015 06:21:20 -0000 --001a11c2750a5c1f2a0511eeac9b Content-Type: text/plain; charset=UTF-8 Though late for 92, I just wanted to submit this for the record General Overview No major issues, most of the concerns I had with the [ID-thomson-webpush-http2-02] draft have been addressed by this, the [ID-damaggio-webpush-http2-00] draft. This is looking good and I look forward to what's coming out of this WG. Regards, Eduardo Gueiros Jive Communications, Inc egueiros at jive.com --001a11c2750a5c1f2a0511eeac9b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Though late for 92, I just wanted to submit this for = the record

General Overview
No major issues, most o= f the concerns I had with the [ID-thomson-webpush-http2-02] draft=C2=A0have b= een addressed by this, the [ID-damaggio-webpush-http2-00] draft.=C2=A0

This is looking good and I look forward to what's = coming out of this WG.=C2=A0

Regards,=C2=A0
Eduardo Gueiros
Jive Communications, Inc
eg= ueiros at jive.com
--001a11c2750a5c1f2a0511eeac9b-- From nobody Sun Mar 22 23:32: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 C97C11A88C2 for ; Sun, 22 Mar 2015 23:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.876 X-Spam-Level: X-Spam-Status: No, score=-0.876 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_IMAGE_ONLY_16=1.092, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O78F1tA8HzPV for ; Sun, 22 Mar 2015 23:32:22 -0700 (PDT) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) (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 1FC621A88B9 for ; Sun, 22 Mar 2015 23:32:22 -0700 (PDT) Received: by labto5 with SMTP id to5so18639054lab.0 for ; Sun, 22 Mar 2015 23:32:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=ocY7KUhBdePT38y+BK3oLF0EgvhacXvja+CtEF6Onis=; b=BuZd565PxFkArTWAyL67RPTN4u6Q0pYTlKLHWTW6mEqSUd9OPJOwKSuhTMKPkDxQWH CfuINURPzOUVD0MA9D/JGUKQbYsEoX1J/xCSfxl/lFg/iI4BzG2mSfRvV7WRpkQB4i1l pvK6YicaP49ZEn0G1e4paygxE5a4nUPTIOZoyIAhWwYmcqyFGHM5+2Wq08Y+af4nDILN vIf1W1dutSQfaAoqHR0gkCgixMpRrPeDA7sGmVQ6MgIebMymIBHPSCivlIUcsRLr8ato BgKH74aPddpo6dM+FIT/3AoPUWAMuGky58wM/Ig00cAup04y/keA82DXjOHpb7B10d7s yWIQ== X-Gm-Message-State: ALoCoQlmEAP579ZfkmgGmBD6jYzXwosZvJmb/AIhVGEXJHQbbPJmsjuFt1mmme8ZwX9KrpNVmgeR MIME-Version: 1.0 X-Received: by 10.152.163.67 with SMTP id yg3mr72998866lab.42.1427092340536; Sun, 22 Mar 2015 23:32:20 -0700 (PDT) Received: by 10.25.212.5 with HTTP; Sun, 22 Mar 2015 23:32:20 -0700 (PDT) Date: Mon, 23 Mar 2015 00:32:20 -0600 Message-ID: From: Eduardo Gueiros To: "webpush@ietf.org" Content-Type: multipart/alternative; boundary=001a1134056e050eab0511eed4f2 Archived-At: Cc: brian.raymor@microsoft.com, elioda@microsoft.com Subject: [Webpush] Review draft-damaggio-webpush-http2-00 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: Mon, 23 Mar 2015 06:32:24 -0000 --001a1134056e050eab0511eed4f2 Content-Type: text/plain; charset=UTF-8 Though late for 92, I just wanted to submit this for the record General Overview No major issues, most of the concerns I had with the [ID-thomson-webpush-http2-02] draft have been addressed by this, the [ID-damaggio-webpush-http2-00] draft. This is looking good and I look forward to what's coming out of this WG. Regards, Eduardo Gueiros Jive Communications, Inc egueiros at jive.com --001a1134056e050eab0511eed4f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Though late fo= r 92, I just wanted to submit this for the record

General Overview
No m= ajor issues, most of the concerns I had with the [ID-thomson-webpush-http2-02] draft= =C2=A0have been addressed by this, the [ID-damaggio-webpush-http2-00= ] draft.=C2=A0

<= div style=3D"font-size:12.8000001907349px">This is looking good and I look = forward to what's coming out of this WG.=C2=A0

Regard= s,=C2=A0

Eduardo Gueiros
Jive Communications, Inc
egueir= os at=C2=A0jive.com
<= /div>
--001a1134056e050eab0511eed4f2-- From nobody Mon Mar 23 12:44:38 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 07B0B1A034F for ; Mon, 23 Mar 2015 12:44:38 -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 ypVrB8_HRn5k for ; Mon, 23 Mar 2015 12:44:36 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::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 9855F1A033B for ; Mon, 23 Mar 2015 12:44:36 -0700 (PDT) Received: by oigv203 with SMTP id v203so149928647oig.3 for ; Mon, 23 Mar 2015 12:44:36 -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=m6nkG5D+tBEG06DWnLAsmpaZh2bVUJkaesJRzEr3DMI=; b=E5qBDvLhYsol0qAoyz67Cq78sbGqT2myZPQlf3JBVO5qRumvAUVngc0Jz7Zfh/iW4c mVIXgmnWzzOMEbecXkbmkH1TX/3+2ysFd6F7tyZfebLGbECbOwwM3qs8O0fCf0ZLkgFl isSe910D/TCDiLyrwTD4Yz2BKs8W2gEGIsPqYBqXCzw9HRCL7PPXU2drlDyBzm96Rpuh O7O7WHkqYlcDCBQ7vIdL6U1p8u2cDQ6fCvgFKZHWmIoFSYsmCYp3hgCsQ6vXy6U574MD 85sBwAbELzmvVCx8ynzBqZlUVS0rxzlMizhi12P9M3Y6TGZnptR//BXJIufu/7ZbUHd3 5cFw== MIME-Version: 1.0 X-Received: by 10.182.20.237 with SMTP id q13mr608608obe.82.1427139876098; Mon, 23 Mar 2015 12:44:36 -0700 (PDT) Received: by 10.202.48.151 with HTTP; Mon, 23 Mar 2015 12:44:36 -0700 (PDT) Date: Mon, 23 Mar 2015 12:44:36 -0700 Message-ID: From: Martin Thomson To: "webpush@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Webpush] Slides 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: Mon, 23 Mar 2015 19:44:38 -0000 Apologies for getting this out so late. https://docs.google.com/presentation/d/1K7KIqp-AvLDGNSDA2RBsbXwFVVn3Sf8ajcfMQm1Hbkk/edit#slide=id.g8f55d295f_0133 From nobody Tue Mar 24 01:11:52 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 938151B2D0E for ; Tue, 24 Mar 2015 01:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.498 X-Spam-Level: X-Spam-Status: No, score=0.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQuln3XNQyta for ; Tue, 24 Mar 2015 01:11:47 -0700 (PDT) Received: from volans.mag.keio.ac.jp (volans.mag.keio.ac.jp [IPv6:2001:200:1c0:3507::10]) (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 7BA2E1B2D08 for ; Tue, 24 Mar 2015 01:11:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=awa.sfc.keio.ac.jp; s=volans; h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version:Subject; bh=Zu421lM3mIlPgCTQUYJ0BWCmdMpLZs+h9K8QAWBS1eM=; b=Z6vlxccHI2JqDZfwnR+Dh2BtlutnXiiAXC+GWoKpKPlknTR+POnGbRKt5LzmvMF0aV9w0ut9QeDoG1w4ek6NYF60A11alRHgvt2Ty3MwOfkpa+QVXHJwYV5J7getVJ4WOniOAVfMIjnTjj2tHMWZ3LrfYiBbpxsrRGIiYTQarn2me4fWTaOVcUEwaDOmJ1Et56Qy2UFVrA/ZlSWw/TWc7DJd9J7Hty4nYrys1KJEOU1r81WdNKYSuktCxaR3X8nPzmZIcwrEikZqEoAz2OWhYiA60ASiDQoOriAZRzlZN2RoLKWzOjQmmf1EInETmjSpRTqqKoRxQOA+oGesK4CiCw==; Received: from mail-pd0-f177.google.com ([209.85.192.177]:33128) by volans.mag.keio.ac.jp with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1YaJw8-0002Kh-E6 for webpush@ietf.org; Tue, 24 Mar 2015 17:11:44 +0900 Received: by pdnc3 with SMTP id c3so214194659pdn.0 for ; Tue, 24 Mar 2015 01:11:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=Zu421lM3mIlPgCTQUYJ0BWCmdMpLZs+h9K8QAWBS1eM=; b=QrNuQrJx7Ap2lkS07TF86HTgGdKIL+jhcOvt0sxzEASKtOxX9A0jXjqxG/EPajMeCU tE2vWRkxWvMPYYCDbrsdssF3vzQ7R1rGVqTOeG8bn3t0ODpVGmvW9IctLRUFCvluCf5r avZNCmYrTDjCv8k2GEc2ppc+u0/ntczg+7jG+Nv0qzLeMp4udvKc6ep/MIag63H9wnSI 0WO0H7iz1cxeuBRgjTUtHRX2AF8tL/+A51W1slvGT/zIXziXSImRlcnspphvp6wS7fF8 7vKBO8XjJvDPfDIMhwyYnAE41q4ZLAy8yzH++Le7enKtW62oQbAHry6aRvW9dwbAXy7q aE3w== X-Gm-Message-State: ALoCoQnyQ7PZk/LU854ELCItwgzVoznupaNSXo4CiJI5EhA7RQ9At9eEexppYk3m6j0+f5ffOC1fRlYS98BGs9H37ennX5GKUMYJo3kP+9FhTgGByNCs5r5KKnKYEOsiL4CDFgXInplCOQcM6UPT1jwhp9BkuCL1XQ== X-Received: by 10.68.132.169 with SMTP id ov9mr5254368pbb.109.1427184698109; Tue, 24 Mar 2015 01:11:38 -0700 (PDT) X-Received: by 10.68.132.169 with SMTP id ov9mr5254351pbb.109.1427184697954; Tue, 24 Mar 2015 01:11:37 -0700 (PDT) Received: from ?IPv6:2001:200:1c0:1200:ae87:a3ff:fe18:66bd? ([2001:200:1c0:1200:ae87:a3ff:fe18:66bd]) by mx.google.com with ESMTPSA id dj3sm3267606pbd.48.2015.03.24.01.11.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Mar 2015 01:11:37 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2093\)) Content-Type: multipart/signed; boundary="Apple-Mail=_1BDDB19B-DD1F-4729-9290-03CF5AA8D639"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5b5 (20bfef5) From: Hirotaka Nakajima In-Reply-To: Date: Tue, 24 Mar 2015 17:11:31 +0900 Message-Id: References: To: Eduardo Gueiros X-Mailer: Apple Mail (2.2093) Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Review draft-nakajima-webpush-problem-statement-00 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 08:11:50 -0000 --Apple-Mail=_1BDDB19B-DD1F-4729-9290-03CF5AA8D639 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Eduardo, Thank you for the feedback! > - In the abstract the following statement =E2=80=9C=E2=80=A6delivering = events based on the registration=E2=80=A6=E2=80=9D Shouldn=E2=80=99t the = subscription be included as well? If an application registers but does = not subscribe for a resource it won=E2=80=99t get anything. Subscription should be needed. > - Suggestion: > Change: =E2=80=9CEmergency Alerting notification=E2=80=9D > To: =E2=80=9CEmergency Notifications=E2=80=9D Some documents on IETF or other documents used =E2=80=9CEmergency = Alerting notification=E2=80=9D however I think =E2=80=9CEmergency = Notifications=E2=80=9D is more common so I would change the term. > - 3.1 paragraph 4 >=20 > If a device is not connected (3GPP, Wifi=E2=80=A6or otherwise without = means to access remote data) how could emergency notifications be = derived (e.g. Desktop without ethernet or wifi)? What do you propose? The motivation of this document is to let the IP-only device to receive = the emergency notifications. (The device which has 3G connectivity can get an alert from 3G Cell and = more geo-graphically accurate than Geo IP-based alerting) So I would like to propose that using webpush as a transport of the = emergency notification to non-Cellular devices (e.g. Web-based signage, = TV, automobile, etc..) > Nits & Grammar Thank you so much! I made a changes to the draft on GitHub. https://nunnun.github.io/webpush-problem-statement/ > 3.1 paragraph 5 > Comment: >=20 > Are you suggesting Web Push to handle spacial data in order to deliver = location based events? If a client is mobile, it would require the = client to update their subscription with their current location on a = timely manner in order to receive accurate notifications. This might be = slightly out of the scope as Web Push as it=E2=80=99s purpose is simply = to push an event based on the subscription. The means and computations = through which the event is generated is apart from the Web Push, in my = opinion. The basic idea is delivering the Earthquake Tsunami Notification to Web = devices through IP-network (not using 3GPP). As you pointed that requires the devices to update their location many = times and that cause huge power consumptions and that is exactly out of = scope. > 3.2 paragraph 3 > Comment: >=20 > So, are you suggesting using Web Push for =E2=80=9Cminor=E2=80=9D = notifications instead of using the more =E2=80=9Cover-the-top=E2=80=9D = PWS approach? I agree. PWS should be used for emergency or general = notifications from public entities. If a user desires to know = precipitation levels in an area, the user should be able to subscribe = with a service that provides that data. In Japan, Earthquake Tsunami Warning System has deployed over the = cellular network. However, that mechanism has abused by the mobile operators to send an = advertisement with non-emergency channel and that cause mis-alerting. So I would propose that web push should have some mechanism of priority = to identify the message=E2=80=99s class. (Emergency? Critical? or just = important) Thank you so much for your comment! Best, Hiro > On Mar 23, 2015, at 3:15 PM, Eduardo Gueiros = wrote: >=20 > General Overview >=20 > In general, I haven=E2=80=99t necessarily found major issues with he = draft besides grammar errors. I have, however a few inquiries as stated = below. >=20 > No Major issues >=20 > Minor issues >=20 > - In the abstract the following statement =E2=80=9C=E2=80=A6delivering = events based on the registration=E2=80=A6=E2=80=9D Shouldn=E2=80=99t the = subscription be included as well? If an application registers but does = not subscribe for a resource it won=E2=80=99t get anything. >=20 > - Suggestion: > Change: =E2=80=9CEmergency Alerting notification=E2=80=9D > To: =E2=80=9CEmergency Notifications=E2=80=9D >=20 > - 3.1 paragraph 4 >=20 > If a device is not connected (3GPP, Wifi=E2=80=A6or otherwise without = means to access remote data) how could emergency notifications be = derived (e.g. Desktop without ethernet or wifi)? What do you propose? >=20 > - There is some general clarification needed in the text and I have = suggested modifications in the =E2=80=98Nits & Grammar=E2=80=99 section = of this review. >=20 > Nits & Grammar >=20 > Abstract, paragraph 1 > > Web Push protocol provides a means of delivering the events to > > clients based on the registration made by the application. >=20 > Proposed text for clarification and grammar: >=20 > The Web Push Protocol [I-D.thomson-webpush-http2] provides means of = delivering events to clients based on registration and subscriptions = made the an application. >=20 > Abstract, paragraph 1 > > Also, the emergency alert notification system has been developed and > > deployed widely with mobile phones or smartphones, but has not = deployed > to Web-only devices. >=20 > Proposed text for clarification and grammar: >=20 > Emergency notification systems have been developed and deployed to = mobile phones, but not to web-only devices. >=20 > Abstract, paragraph 2 >=20 > > This document outlines various existing emergency alert notification > > system in other protocols and use cases with their requirements. >=20 > Proposed text: >=20 > This document outlines various existing emergency notification = systems, their protocols and use cases, and explains how Web Push can = help pushing emergency notifications to web-only devices. >=20 > Introduction, paragraph 2 > >Also, emergency alerting is an apparently important feature of > > telecommunication network such as cellular networks, allowing the > > governments or authorities to send a warnings of natural disaster = or > > accident. >=20 > Proposed text for clarification and grammar: >=20 > Emergency notifications is an important feature of telecommunications = networks such as cellular networks, allowing governments and public = safety entities to send many types of warnings (eg. natural disasters, = abductions, accidents, etc). >=20 > 1. Introduction, paragraph 3 > > emergency notification system >=20 > Proposed text for clarification and grammar: >=20 > emergency notification systems >=20 > 3.1 paragraph 2 > > and merged into Public Warning System (PWS) >=20 > Proposed text for clarification and grammar: >=20 > and merged into the/a Public Warning System >=20 > 3.1 paragraph 2 > >PWS provides several functions for example: >=20 > Proposed text for clarification and grammar: >=20 >=20 > PWS provides several functions, for example: >=20 > 3.1 paragraph 3 > > Addition to PWS, some work has been made to distribute the emergency > > alerting notification on different network. >=20 > Proposed text for clarification and grammar: >=20 > In addition to PWS, some work has been done to send emergency = notifications through different networks. >=20 > 3.1 paragraph 4 > > Those previous contributions have been made to develop the method to > > distribute an emergency alerting notification. >=20 > Comment: >=20 > The phrase is not clear. You already stated previously that work has = been done. >=20 > 3.1 paragraph 5 > Comment: >=20 > Are you suggesting Web Push to handle spacial data in order to deliver = location based events? If a client is mobile, it would require the = client to update their subscription with their current location on a = timely manner in order to receive accurate notifications. This might be = slightly out of the scope as Web Push as it=E2=80=99s purpose is simply = to push an event based on the subscription. The means and computations = through which the event is generated is apart from the Web Push, in my = opinion. >=20 > 3.2 paragraph 2 > > Digital signage has widely deployed among the world. >=20 > Suggested change: >=20 > Digital signage has been widely deployed around the world. >=20 >=20 >=20 > 3.2 paragraph 2 > > Signage located at public area such as train station or street play = a > > significant role in natural disaster or accident by providing the > > evacuation alert or correct informations. >=20 > Suggested change: >=20 > Signage located in public areas, such as on train stations or on the = street, play a significant role in natural disaster or accidents by = providing evacuation alerts or useful information. >=20 > 3.2 paragraph 2 > > Recent few years W3C worked on Web-based signage which > > has Web browser is embedded, allowing to display or play Web = content. > > Disaster use case is proposed in W3C Web-based Signage Scenarios = and > > Use Cases [SignageUseCase]. >=20 > Suggested change: >=20 > In recent years, the W3C has worked on Web-based signage which has a = web browser embedded, allowing it to display web content. The disaster = notification use case is proposed in the W3C Web-based Signage Scenarios = and Use Cases [SignageUseCase]. >=20 > 3.2 paragraph 3 > Comment: >=20 > So, are you suggesting using Web Push for =E2=80=9Cminor=E2=80=9D = notifications instead of using the more =E2=80=9Cover-the-top=E2=80=9D = PWS approach? I agree. PWS should be used for emergency or general = notifications from public entities. If a user desires to know = precipitation levels in an area, the user should be able to subscribe = with a service that provides that data. >=20 > Regards, >=20 > Eduardo Gueiros > Jive Communications, Inc > egueiros at jive.com >=20 --Apple-Mail=_1BDDB19B-DD1F-4729-9290-03CF5AA8D639 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVERwzAAoJEGB+XLBFwEd8ThoP/Anjihh8NyvrtEeTpGJOK4xd xRbkekalivE7jOCQUWhyYVqfnTZAW/DyPPahLHrsoGeWJzBN2WFTCSziOqhnscZC BygFZhnFVBcylTEE09A6CiTsgqSq+78oOUY9StA6pT6qGEkH1qgiDkVKJ3wK41rM Hm3D/ITouz229Org3zPbuYl3lSZNmROmwHsBHFTOA8SLZxBMzeDnS4zQ01LEe6H1 kxwlJnwvUIpgqMtjpuYB7/DHszxo5ZNlXF2tlqyvgLLt6Rki6DI4rv4pY6QydsEE iq5NEiwYMPjjvuaDn7RpSYjmMCfsNDyoozetnb/ZyJ/CSPIBnwiTMS4c3U8bO5N5 RC0fBeX3xfs1BYjW2p4AvSg/WdX5rWc4qvZP1Od5lhFzKyGVCdLzY2onZ+w7l6cd HKxmqwcxteylHlLZk9oAhOUeQnZVfpgKEpapbkpC4v2I7zJ6enb8waEVOWsfPKnq mn21fCD6ReglyEyriHTNAmo6OjUNF6+KiIkquM/7N9WPBdsmhtz5Ef3akNtbFSj8 a0KtY2PNlaaJayBZDG6Dcmwg+L22zpvxq7tCf/nN5FV71mvfF5OAGW0gKSw633cj 6N2l/fiMvDsuuVabdWgOvadgXEPDv9pR7GHBrMhW7rth5UbnjOp/LKMQrvTzpxaG XZ5VWYNen8UJpGVU26Zo =vZtU -----END PGP SIGNATURE----- --Apple-Mail=_1BDDB19B-DD1F-4729-9290-03CF5AA8D639-- From nobody Tue Mar 24 21:20:07 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 33ED51ACD8F for ; Tue, 24 Mar 2015 21:20:06 -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 GysiZVALa_Z1 for ; Tue, 24 Mar 2015 21:20:04 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::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 C189D1ACD8C for ; Tue, 24 Mar 2015 21:20:04 -0700 (PDT) Received: by obbgg8 with SMTP id gg8so10611152obb.1 for ; Tue, 24 Mar 2015 21:20:04 -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=nlf5a5nb1Wk0aU4YkCl0zUOPf4yrUqUtneJ+qcOQKHk=; b=YS28G2ZSXOzTytRZZKrbG8ykLdfJAbwIArCuDFw6vF/vwxFUMgK8DGSKqAUkzuYiW0 c6/DM4Sl1FoT2cZuI7FpZEIjnKclTrx1SVN3+EDE+wuD4pqNyOppqjJJiZBuSNLuBG5x DXtwF7C5o11Y1jw/qEV+9MF5g6U2jVELcbbEdPCcRQm0oYyWrvDjjIbyYHo8XwVYJ9lJ jm/39SllxdHaUVmWDP7Bnte+4UCNV/0KFNlRHkUKPDCaQjo1870ElR+QUGV19fAC53LG N4eqVWDiNpxJrCpEF1M2Q+XPubLIa5Z4nDhVJqrSryB2rsiaeY7tD+jzCa6WfDHoUES9 yIZA== MIME-Version: 1.0 X-Received: by 10.202.170.72 with SMTP id t69mr5560261oie.21.1427257204228; Tue, 24 Mar 2015 21:20:04 -0700 (PDT) Received: by 10.202.48.151 with HTTP; Tue, 24 Mar 2015 21:20:04 -0700 (PDT) Date: Tue, 24 Mar 2015 23:20:04 -0500 Message-ID: From: Martin Thomson To: "webpush@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Webpush] Web Push Client 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, 25 Mar 2015 04:20:06 -0000 Out of the discussion on Monday, I've spent an hour on the web push client I mentioned during the meeting. It now interoperates with my other content-encoding implementation. https://github.com/martinthomson/webpush-client I plan to build a test server so that you can request a new "subscription" and send messages to it to test your own code. From nobody Mon Mar 30 14:19:38 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 C99A31A0179 for ; Mon, 30 Mar 2015 14:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hO9hHq-G8om0 for ; Mon, 30 Mar 2015 14:19:36 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0788.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::788]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 123D51A005C for ; Mon, 30 Mar 2015 14:19:35 -0700 (PDT) Received: from BY2PR0301MB0647.namprd03.prod.outlook.com (25.160.63.14) by BY2PR0301MB0726.namprd03.prod.outlook.com (25.160.63.16) with Microsoft SMTP Server (TLS) id 15.1.118.21; Mon, 30 Mar 2015 21:19:16 +0000 Received: from BY2PR0301MB0647.namprd03.prod.outlook.com (25.160.63.14) by BY2PR0301MB0647.namprd03.prod.outlook.com (25.160.63.14) with Microsoft SMTP Server (TLS) id 15.1.118.21; Mon, 30 Mar 2015 21:19:16 +0000 Received: from BY2PR0301MB0647.namprd03.prod.outlook.com ([25.160.63.14]) by BY2PR0301MB0647.namprd03.prod.outlook.com ([25.160.63.14]) with mapi id 15.01.0118.022; Mon, 30 Mar 2015 21:19:15 +0000 From: "Brian Raymor (MS OPEN TECH)" To: Eduardo Gueiros , "webpush@ietf.org" Thread-Topic: [Webpush] Review draft-damaggio-webpush-http2-00 Thread-Index: AQHQZTGe+/H6hN+Sj0+9u1JckH8yWJ01kOTw Date: Mon, 30 Mar 2015 21:19:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ee31::3] authentication-results: jive.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0647; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0726; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(24454002)(164054003)(107886001)(77156002)(33656002)(99286002)(86362001)(102836002)(2501003)(19580395003)(230783001)(76576001)(122556002)(54356999)(46102003)(86612001)(2950100001)(19580405001)(2900100001)(62966003)(74316001)(106116001)(92566002)(50986999)(76176999)(87936001)(2656002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0647; H:BY2PR0301MB0647.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BY2PR0301MB0647; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0647; x-forefront-prvs: 05315CBE52 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2015 21:19:15.7898 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0647 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: Subject: Re: [Webpush] Review draft-damaggio-webpush-http2-00 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: Mon, 30 Mar 2015 21:19:38 -0000 DQpPbiBNYXJjaCAyMiAyMDE1IGF0IDExOjIxIEVkdWFyZG8gR3VlaXJvcyA8ZWd1ZWlyb3NAaml2 ZS5jb20+IHdyb3RlOg0KDQogID4gTm8gbWFqb3IgaXNzdWVzLCBtb3N0IG9mIHRoZSBjb25jZXJu cyBJIGhhZCB3aXRoIHRoZSBbSUQtdGhvbXNvbi13ZWJwdXNoLWh0dHAyLTAyXSBkcmFmdMKgaGF2 ZSBiZWVuIGFkZHJlc3NlZCBieSB0aGlzLCB0aGUgW0lELWRhbWFnZ2lvLXdlYnB1c2gtaHR0cDIt MDBdIGRyYWZ0LsKgDQoNCkVkdWFyZG8sDQoNCkNvdWxkIHlvdSBzaGFyZSBtb3JlIGRldGFpbHMg b24geW91ciBzcGVjaWZpYyBjb25jZXJucz8gTWFydGluLCBFbGlvLCBhbmQgSSBhcmUgcHJlcGFy aW5nIHRvIG1lcmdlIHRoZSB0d28gZHJhZnRzLiBJJ2QgbGlrZSB0byBlbnN1cmUgdGhhdCB3ZSd2 ZSBjYXB0dXJlZCB5b3VyIGZlZWRiYWNrLg0KDQpUaGFua3MsDQoNCi4uLkJyaWFuDQo=