From nobody Wed Feb 11 19:46:18 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 0813D1A1E10 for ; Wed, 11 Feb 2015 19:46:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.248 X-Spam-Level: ** X-Spam-Status: No, score=2.248 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 3yk8ZOGSnVzl for ; Wed, 11 Feb 2015 19:46:14 -0800 (PST) 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 22DCD1A1B5A for ; Wed, 11 Feb 2015 19:46:14 -0800 (PST) Received: from [199.116.72.155] (port=62175 helo=[10.1.0.182]) by gator4135.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1YLkjF-0006A7-6v; Wed, 11 Feb 2015 21:46:13 -0600 From: Shida Schubert Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Feb 2015 19:46:11 -0800 Message-Id: <539F7058-12CE-47BA-82CD-BB5413947F20@ntt-at.com> To: webpush@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) 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: 199.116.72.155 X-Exim-ID: 1YLkjF-0006A7-6v X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([10.1.0.182]) [199.116.72.155]:62175 X-Source-Auth: mateo@agnada.com X-Email-Count: 2 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== Archived-At: Cc: Alissa Cooper Subject: [Webpush] Webpush at 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: Thu, 12 Feb 2015 03:46:17 -0000 All; I have tentatively booked 1.5 hour in Dallas to meet and discuss face to = face but seeing that there has been little to no traffic since the last = IETF, despite number of hands indicating that they will contribute, I am = doubting the need to hold the meeting.=20 Actually the only email that was sent out to the list was Martin = informing the WG that he has submitted the updated version of the core = draft addressing all the comments.=20 Furthermore, with so little traffic we see on the list, should we = consider closing the WG?=20 I would like to hear from the WG whether the work indicated on the = charter is worthwhile pursuing and if there are enough energy backing = it.=20 Many Thanks! Shida as a co-chair= From nobody Thu Feb 12 12:47:47 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 02B341A7032 for ; Thu, 12 Feb 2015 12:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 FIHI76bzUUpX for ; Thu, 12 Feb 2015 12:47:43 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A56D1A024E for ; Thu, 12 Feb 2015 12:47:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1516; q=dns/txt; s=iport; t=1423774064; x=1424983664; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=MCVF1Li2JivTGtdNb80/5MwrnIlarLKKlkqOxXjSWJ0=; b=kLD7aI2sxEriScLbTIGWu7kRad7iRj0hSny0czWQ2dZXCX+JJhOGMNhP SmkVbcKqOIJ/v4D4WNDwpEEU7oFwlY8ZMLSxXeqTNt/1xLECt7KlyoLuZ s9Myq5gD2LSkW4yqCjFKf4X6ZRPKUtOXmqTO9K7zfWb9+E8eY3a4p6tVZ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An4FANcQ3VStJV2S/2dsb2JhbABbgwZSWgSCfr4BghwKhSdKAhyBEEMBAQEBAQF8hA0BAQQBAQEgEToLEAIBCBoCJgICAiULFRACBAENBYgtDb4hlywBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIEhiWuECxEBUAeCaC6BFAWPKYkzgRiDBo5iIoNub4ELOX8BAQE X-IronPort-AV: E=Sophos;i="5.09,567,1418083200"; d="scan'208";a="395756808" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-4.cisco.com with ESMTP; 12 Feb 2015 20:47:43 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t1CKlguh028802 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Feb 2015 20:47:42 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.156]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Thu, 12 Feb 2015 14:47:42 -0600 From: "Joe Hildebrand (jhildebr)" To: Shida Schubert , "webpush@ietf.org" Thread-Topic: [Webpush] Webpush at IETF92? Thread-Index: AQHQRnZ61a3zSpB4VE+TL4ycNSRAsJztbJiA Date: Thu, 12 Feb 2015 20:47:42 +0000 Message-ID: References: <539F7058-12CE-47BA-82CD-BB5413947F20@ntt-at.com> In-Reply-To: <539F7058-12CE-47BA-82CD-BB5413947F20@ntt-at.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.7.0.150202 x-originating-ip: [10.24.22.153] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Alissa Cooper Subject: Re: [Webpush] Webpush at 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: Thu, 12 Feb 2015 20:47:46 -0000 KGNvLWNoYWlyIGhhdCBvbikNCg0KU2Vjb25kaW5nIFNoaWRhIGhlcmUuICBOb2JvZHkgaGFzIHJl c3BvbmRlZCB5ZXQuICBTcGVhayB1cCBpZiB5b3UgY2FyZSwgDQpwbGVhc2UuDQoNCg0KT24gMi8x MS8xNSwgODo0NiBQTSwgIlNoaWRhIFNjaHViZXJ0IiA8c2hpZGFAbnR0LWF0LmNvbT4gd3JvdGU6 DQoNCj4NCj5BbGw7DQo+DQo+SSBoYXZlIHRlbnRhdGl2ZWx5IGJvb2tlZCAxLjUgaG91ciBpbiBE YWxsYXMgdG8gbWVldCBhbmQgZGlzY3VzcyBmYWNlIHRvIA0KPmZhY2UgYnV0IHNlZWluZyB0aGF0 IHRoZXJlIGhhcyBiZWVuIGxpdHRsZSB0byBubyB0cmFmZmljIHNpbmNlIHRoZSBsYXN0IA0KPklF VEYsIGRlc3BpdGUgbnVtYmVyIG9mIGhhbmRzIGluZGljYXRpbmcgdGhhdCB0aGV5IHdpbGwgY29u dHJpYnV0ZSwgSSBhbSANCj5kb3VidGluZyB0aGUgbmVlZCB0byBob2xkIHRoZSBtZWV0aW5nLiAN Cj4NCj5BY3R1YWxseSB0aGUgb25seSBlbWFpbCB0aGF0IHdhcyBzZW50IG91dCB0byB0aGUgbGlz dCB3YXMgTWFydGluIA0KPmluZm9ybWluZyB0aGUgV0cgdGhhdCBoZSBoYXMgc3VibWl0dGVkIHRo ZSB1cGRhdGVkIHZlcnNpb24gb2YgdGhlIGNvcmUgDQo+ZHJhZnQgYWRkcmVzc2luZyBhbGwgdGhl IGNvbW1lbnRzLiANCj4NCj5GdXJ0aGVybW9yZSwgd2l0aCBzbyBsaXR0bGUgdHJhZmZpYyB3ZSBz ZWUgb24gdGhlIGxpc3QsIHNob3VsZCB3ZSANCj5jb25zaWRlciBjbG9zaW5nIHRoZSBXRz8gDQo+ DQo+SSB3b3VsZCBsaWtlIHRvIGhlYXIgZnJvbSB0aGUgV0cgd2hldGhlciB0aGUgd29yayBpbmRp Y2F0ZWQgb24gdGhlIA0KPmNoYXJ0ZXIgaXMgd29ydGh3aGlsZSBwdXJzdWluZyBhbmQgaWYgdGhl cmUgYXJlIGVub3VnaCBlbmVyZ3kgYmFja2luZyBpdC4gDQo+DQo+TWFueSBUaGFua3MhDQo+DQo+ U2hpZGEgYXMgYSBjby1jaGFpcg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+V2VicHVzaCBtYWlsaW5nIGxpc3QNCj5XZWJwdXNoQGlldGYub3JnDQo+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby93ZWJwdXNoDQo+DQoNCg0KLS0g DQpKb2UgSGlsZGVicmFuZA0KDQoNCg0K From nobody Thu Feb 12 13:01:04 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 BF4ED1A026E for ; Thu, 12 Feb 2015 13:00:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 tjDdYWOFcUS5 for ; Thu, 12 Feb 2015 13:00:51 -0800 (PST) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::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 E5CED1A1F1D for ; Thu, 12 Feb 2015 13:00:50 -0800 (PST) Received: by mail-we0-f175.google.com with SMTP id x3so12760627wes.6 for ; Thu, 12 Feb 2015 13:00:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BnMdeQOGJK35BK1icV80QNP93yEIR6vkLBlbFN4nyXU=; b=kSX9EdM0BaMj9U7a+FYOovlCuHFslrrPQgwPZD4meB2DqRGnUO2ayDqcG8ups3eQCH uWhhFq/r/9vc3HF3S+921RERFJKf8kqK1fAMoF0TudZ2+JQPyLeaUhyFU81W4ecvtcS1 PpZQ3kVIyfWaPiyBen7OwrkwQWw93MW2YHSwPOEOdMENJdffp/KbVGZlY2ylMYS6Jq8Z 2Ui5ULgd55h239PNOSa9VU2IBASd/2zaO6FPw3xlT3Ju3V3PpaWmI58sR6USOn8gfgOn XlURrqO7f1y43oj5ZR7HtuTmV7/mgwkHkVgykG8rxzI4Q29RE/K5p2/nMkj6NFat59pI QRCw== 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=BnMdeQOGJK35BK1icV80QNP93yEIR6vkLBlbFN4nyXU=; b=i76Uj40737eWAN62ASgdKddL7On3utL0jye1NCqyZyJWTGRb2F3E2SLDtB07JbU8yY fNiF5qXt843HX6cvexv9b2UaLFb1Kh+hXb8/VWPoUGVSJcGxHQHSZr/efJbOFbUDg5xn ypyMb9IUmsF5MwtnqWaJY+Fj2jFtMkJgIXzEni5edMa6IcfyyvzHQXPRER87u3CY+5sw gbJqeBSaHvvip50Ot1U9rCltwxQwT++zkjbRzmQYA3AesMWTR26Byv+xPSJM1vSkxymD +jS9S23xyJGk/KSf3mhKx100yhiGerVWL6KYmgwQcwwXDNrLs/w5gaqUD7wtlO9NmEpr dG+g== X-Gm-Message-State: ALoCoQmROgHsHtaWmpAIMcOjTAaJ/RjNEpaHHx/pqAE8LmMGTTwbCClxcx3Jn8vatGxyxGf+U1Jf MIME-Version: 1.0 X-Received: by 10.194.191.228 with SMTP id hb4mr6425239wjc.116.1423774849496; Thu, 12 Feb 2015 13:00:49 -0800 (PST) Received: by 10.194.221.169 with HTTP; Thu, 12 Feb 2015 13:00:49 -0800 (PST) In-Reply-To: References: <539F7058-12CE-47BA-82CD-BB5413947F20@ntt-at.com> Date: Thu, 12 Feb 2015 21:00:49 +0000 Message-ID: From: Peter Beverloo To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=047d7b8750be25a27e050eea6a6e Archived-At: Cc: Shida Schubert , Alissa Cooper , "webpush@ietf.org" Subject: Re: [Webpush] Webpush at 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: Thu, 12 Feb 2015 21:00:54 -0000 --047d7b8750be25a27e050eea6a6e Content-Type: text/plain; charset=UTF-8 We (Google) are definitely interested in continuing with the working group. Furthermore, we'll also attend the sessions at IETF 92. Thank you for scheduling time. I regret the low level of activity on the mailing lists, and agree that we should at least start a series of discussions prior to the meeting in Dallas. The large open topic for us is encryption, and how this ties in to one-to-many distribution of messages by the push service. Also related to this is the subject of authentication, notably of the sender (application server). We're working on an early draft proposal, and I'm hopeful to have something ready prior to IETF 92. At least we need to have the use cases and associated constraints defined. Thanks, Peter On Thu, Feb 12, 2015 at 8:47 PM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > (co-chair hat on) > > Seconding Shida here. Nobody has responded yet. Speak up if you care, > please. > > > On 2/11/15, 8:46 PM, "Shida Schubert" wrote: > > > > >All; > > > >I have tentatively booked 1.5 hour in Dallas to meet and discuss face to > >face but seeing that there has been little to no traffic since the last > >IETF, despite number of hands indicating that they will contribute, I am > >doubting the need to hold the meeting. > > > >Actually the only email that was sent out to the list was Martin > >informing the WG that he has submitted the updated version of the core > >draft addressing all the comments. > > > >Furthermore, with so little traffic we see on the list, should we > >consider closing the WG? > > > >I would like to hear from the WG whether the work indicated on the > >charter is worthwhile pursuing and if there are enough energy backing it. > > > >Many Thanks! > > > >Shida as a co-chair > >_______________________________________________ > >Webpush mailing list > >Webpush@ietf.org > >https://www.ietf.org/mailman/listinfo/webpush > > > > > -- > Joe Hildebrand > > > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > --047d7b8750be25a27e050eea6a6e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We (Google) are definitely interested in continuing with t= he working group.

Furthermore, we'll also attend the= sessions at IETF 92. Thank you for scheduling time.

I regret the low level of activity on the mailing lists, and agree that we= should at least start a series of discussions prior to the meeting in Dall= as.

The large open topic for us is encryption= , and how this ties in to one-to-many distribution of messages by the push = service. Also related to this is the subject of authentication, notably of = the sender (application server).

We're working= on an early draft proposal, and I'm hopeful to have something ready pr= ior to IETF 92. At least we need to have the use cases and associated const= raints defined.

Thanks,
Peter

On Thu, Feb 12, 2015 at = 8:47 PM, Joe Hildebrand (jhildebr) <jhildebr@cisco.com> wro= te:
(co-chair hat on)

Seconding Shida here.=C2=A0 Nobody has responded yet.=C2=A0 Speak up if you= care,
please.


On 2/11/15, 8:46 PM, "Shida Schubert" <shida@ntt-at.com> wrote:

>
>All;
>
>I have tentatively booked 1.5 hour in Dallas to meet and discuss face t= o
>face but seeing that there has been little to no traffic since the last=
>IETF, despite number of hands indicating that they will contribute, I a= m
>doubting the need to hold the meeting.
>
>Actually the only email that was sent out to the list was Martin
>informing the WG that he has submitted the updated version of the core<= br> >draft addressing all the comments.
>
>Furthermore, with so little traffic we see on the list, should we
>consider closing the WG?
>
>I would like to hear from the WG whether the work indicated on the
>charter is worthwhile pursuing and if there are enough energy backing i= t.
>
>Many Thanks!
>
>Shida as a co-chair
>_______________________________________________
>Webpush mailing list
>Webpush@ietf.org
>https://www.ietf.org/mailman/listinfo/webpush
>


--
Joe Hildebrand



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

--047d7b8750be25a27e050eea6a6e-- From nobody Thu Feb 12 17:23:46 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 167A21A1A4A for ; Thu, 12 Feb 2015 17:23:26 -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 WvsXERuYG3vF for ; Thu, 12 Feb 2015 17:23:20 -0800 (PST) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) (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 88B471A026C for ; Thu, 12 Feb 2015 17:23:09 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id x12so80898wgg.6 for ; Thu, 12 Feb 2015 17:23:08 -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:content-type; bh=m8nI0hMWw/o9j9QHReKH/0C1cYnaHkgB1c5a34UPwns=; b=EW7P/v4+p6FpFVSDP9mJwmGOilrVBJI1qaI9vSDXld1XUfZukVa4p/xNs/cGlzrJst IggcALfofi76B/LabChtfj1OJcQVpvuCdHn/GxYcW4eSliowLVu3kso9BMe4NW/xHaCf R3HOnXc4JIVYm2jj8KoVR5jzodGn2w5997QClqFa1Wt5H+sZlnBhwb1jYMVbDehhOkbW lr75DDcxQgtdxwN4ZGOfRLb9rlN+NEKpnHHHkjtUqltKNysSoaCia2OAss8qKZCUZ50P 2v/qgaQC1GDPrzPxQepbP/86X3WBWmry17ebBd4fbACHwkhpYOdInXncFQR4wJYITWfi RSlQ== X-Gm-Message-State: ALoCoQlkzB9c+B5KdelPvJOBSoBcML/a9nf5kONcvy4iOOHDAFXBFEpnCwrt5Hj/6BA7CyTx41J2 MIME-Version: 1.0 X-Received: by 10.180.198.101 with SMTP id jb5mr11045150wic.92.1423790588043; Thu, 12 Feb 2015 17:23:08 -0800 (PST) Received: by 10.27.131.41 with HTTP; Thu, 12 Feb 2015 17:23:08 -0800 (PST) In-Reply-To: References: Date: Thu, 12 Feb 2015 17:23:08 -0800 Message-ID: From: Benjamin Bangert To: "webpush@ietf.org" Content-Type: multipart/alternative; boundary=047d7b624d143c3ad7050eee142b Archived-At: Subject: Re: [Webpush] 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: Fri, 13 Feb 2015 01:23:26 -0000 --047d7b624d143c3ad7050eee142b Content-Type: text/plain; charset=UTF-8 A few comments: 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) Section 5: - The examples show plain-text notification content while 8.1 indicates subscriptions include a crypto key, so they should be an opaque encrypted blob - The Push Server should return an appropriate Bad Auth HTTP status code when authorization is required of the Application Server. Section 6: - Should also show an encrypted blob Section 7.2: - It would be useful to have some minimum storage period Section 7.3: - It says the push service can expire it anytime, what happens if a client is disconnected during this time? Or are push services only allowed to expire subscriptions while the client is connected? Section 8.3/8.4: - It seems reasonable that Push Service providers will want to require an App-Server developer to register their app and get an Oauth token or some other scheme to indicate that they are allowed to push notifications (and for Push Service providers to restrict maximum messages/throughput on a per-app basis). Should this be mentioned here? Cheers, Ben On Fri, Dec 12, 2014 at 4:01 PM, Martin Thomson wrote: > I've revised the protocol proposal for web push. > > https://datatracker.ietf.org/doc/draft-thomson-webpush-http2/ > > A more readable HTML version is here, though this will be updated as I > make changes: > > https://martinthomson.github.io/drafts/draft-thomson-webpush-http2.html > > This includes some fairly significant changes to incorporate the > feedback I've received from various corners. I haven't prepared a > change log, but I believe that this covers at least the high points of > what was discussed at the meeting: > > - names of everything have changed > - I've added examples and expanded the explanatory text throughout > - removed use of 202 due to a privacy concern (thanks to Robert > Sparks for sharing his experience with this) > - significantly expanded the operational considerations regarding > load distribution and message retention > - minimum message size of 4k added > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > --047d7b624d143c3ad7050eee142b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A few comments:

Section 2:
=
-=20 The diagram is good, but I think adding one variant for broadcast=20 messages would be good. I could see a crypto secured broadcast working=20 like so:
=C2=A0 - Broadcast Subscribe (In contrast to normal = subscribe)
=C2=A0 - Browser Agent makes Provide Subscription = request to Application, including request (flag) to be issued the broadcast= key
=C2=A0 - Browser stores the broadcast key with the new s= ubscription (rather than generating its own key)

Section 5:
- The examples show plain-text notification content while 8.1 indicates=20 subscriptions include a crypto key, so they should be an opaque=20 encrypted blob
- The Push Server should return an appropriate Bad=20 Auth HTTP status code when authorization is required of the Application=20 Server.

Section 6:
- Should also show an en= crypted blob

Section 7.2:
- It would be use= ful to have some minimum storage period

Section 7.3:
<= /div>
- It says the push service can expire it anytime, what happens if a=20 client is disconnected during this time? Or are push services only=20 allowed to expire subscriptions while the client is connected?

Section 8.3/8.4:
- It seems reasonable that Push Service providers will want to require an App-Server developer to register their app and get an Oauth token or=20 some other scheme to indicate that they are allowed to push=20 notifications (and for Push Service providers to restrict maximum=20 messages/throughput on a per-app basis). Should this be mentioned here?
=

Cheers,
Ben

On Fri, Dec 12, 2014 at 4:01 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
I've revised the protocol proposal for web push.

https://datatracker.ietf.org/doc/draft-thomson-webpush-htt= p2/

A more readable HTML version is here, though this will be updated as I
make changes:

https://martinthomson.github.io/drafts/draft-tho= mson-webpush-http2.html

This includes some fairly significant changes to incorporate the
feedback I've received from various corners.=C2=A0 I haven't prepar= ed a
change log, but I believe that this covers at least the high points of
what was discussed at the meeting:

=C2=A0- names of everything have changed
=C2=A0- I've added examples and expanded the explanatory text throughou= t
=C2=A0- removed use of 202 due to a privacy concern (thanks to Robert
Sparks for sharing his experience with this)
=C2=A0- significantly expanded the operational considerations regarding
load distribution and message retention
=C2=A0- minimum message size of 4k added

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

--047d7b624d143c3ad7050eee142b-- From nobody Thu Feb 12 17:30: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 12ED41A005A for ; Thu, 12 Feb 2015 17:30:09 -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 VLFl4q06-MWJ for ; Thu, 12 Feb 2015 17:30:04 -0800 (PST) Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (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 136E91A03B3 for ; Thu, 12 Feb 2015 17:29:58 -0800 (PST) Received: by mail-we0-f171.google.com with SMTP id p10so13756383wes.2 for ; Thu, 12 Feb 2015 17:29:56 -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:content-type; bh=aPd2mGAHtuIbrOhAfnPSjHsV2ziErzcsDFgSI0iW04I=; b=KecQLBzV6Htr5H+LSJNNqKfSEXdknnEOAwxA3f8YzVFe7CKiLzrVsdCrA3b+5IHxV1 zKgGQXeVn5dQmCtbUtI+xX3pOFEg0zaZ/1LMvDRXxr5lni3938JmQFOysVCadegAf2MJ BxGLjyUGAs+Zpc5wmkla+egqmFyz5LFX/v5zq3oC4Eq+GoAuGR6b4TThetDRpmvZoO1L KOsMck94H/VGr0QpleVLolir9e9s5gEnqMZadi7gCkW0S/BSDZxAj0xF7mXQXT3kRJJu Gus1yKR3WwPIHH3powvGbyMOwqsRF8NTir4zm0xwF4EIofMpjn6WzjkCLXq2KTnB3luN xy5g== X-Gm-Message-State: ALoCoQlnBumpj/ksDHyJOvBFbXO7mDfTRaG52WbMmUWVBuwWZgCbMS7iNcI0ePOEQV1AF8wKbQTe MIME-Version: 1.0 X-Received: by 10.180.73.75 with SMTP id j11mr11209221wiv.17.1423790996809; Thu, 12 Feb 2015 17:29:56 -0800 (PST) Received: by 10.27.131.41 with HTTP; Thu, 12 Feb 2015 17:29:56 -0800 (PST) In-Reply-To: References: Date: Thu, 12 Feb 2015 17:29:56 -0800 Message-ID: From: Benjamin Bangert To: "webpush@ietf.org" Content-Type: multipart/alternative; boundary=f46d043c7ee299842b050eee2c1a Archived-At: Subject: Re: [Webpush] 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: Fri, 13 Feb 2015 01:30:09 -0000 --f46d043c7ee299842b050eee2c1a Content-Type: text/plain; charset=UTF-8 One other thought that comes to mind, is that the crypto for the encryption needs to be included in the standard for consistency across browsers. Alternatively, if the crypto is up to the browser (Maybe the standard just specifies several appropriate secure methods), than the Subscription request should indicate the required encryption/HMAC to use for the push notifications to the Application Server knows how to appropriately encrypt the notification with the provided key. This way as crypto requirements change the browser can indicate the new desired scheme to the Application Server without being stuck at a specific now-obsolete method. Perhaps a crypto string similar to the SSL cipher strings. Cheers, Ben On Thu, Feb 12, 2015 at 5:23 PM, Benjamin Bangert wrote: > A few comments: > > 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) > > Section 5: > - The examples show plain-text notification content while 8.1 indicates > subscriptions include a crypto key, so they should be an opaque encrypted > blob > - The Push Server should return an appropriate Bad Auth HTTP status code > when authorization is required of the Application Server. > > Section 6: > - Should also show an encrypted blob > > Section 7.2: > - It would be useful to have some minimum storage period > > Section 7.3: > - It says the push service can expire it anytime, what happens if a client > is disconnected during this time? Or are push services only allowed to > expire subscriptions while the client is connected? > > Section 8.3/8.4: > - It seems reasonable that Push Service providers will want to require an > App-Server developer to register their app and get an Oauth token or some > other scheme to indicate that they are allowed to push notifications (and > for Push Service providers to restrict maximum messages/throughput on a > per-app basis). Should this be mentioned here? > > Cheers, > Ben > > On Fri, Dec 12, 2014 at 4:01 PM, Martin Thomson > wrote: > >> I've revised the protocol proposal for web push. >> >> https://datatracker.ietf.org/doc/draft-thomson-webpush-http2/ >> >> A more readable HTML version is here, though this will be updated as I >> make changes: >> >> https://martinthomson.github.io/drafts/draft-thomson-webpush-http2.html >> >> This includes some fairly significant changes to incorporate the >> feedback I've received from various corners. I haven't prepared a >> change log, but I believe that this covers at least the high points of >> what was discussed at the meeting: >> >> - names of everything have changed >> - I've added examples and expanded the explanatory text throughout >> - removed use of 202 due to a privacy concern (thanks to Robert >> Sparks for sharing his experience with this) >> - significantly expanded the operational considerations regarding >> load distribution and message retention >> - minimum message size of 4k added >> >> _______________________________________________ >> Webpush mailing list >> Webpush@ietf.org >> https://www.ietf.org/mailman/listinfo/webpush >> > > --f46d043c7ee299842b050eee2c1a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One other thought that comes to mind, is th= at the crypto for the encryption needs to be included in the standard for c= onsistency across browsers. Alternatively, if the crypto is up to the brows= er (Maybe the standard just specifies several appropriate secure methods), = than the Subscription request should indicate the required encryption/HMAC = to use for the push notifications to the Application Server knows how to ap= propriately encrypt the notification with the provided key.

Th= is way as crypto requirements change the browser can indicate the new desir= ed scheme to the Application Server without being stuck at a specific now-o= bsolete method. Perhaps a crypto string similar to the SSL cipher strings.<= br>
Cheers,
Ben

<= div class=3D"gmail_quote">On Thu, Feb 12, 2015 at 5:23 PM, Benjamin Bangert= <bbangert@mozilla.com> wrote:
A few comments:

Sectio= n 2:
-=20 The diagram is good, but I think adding one variant for broadcast=20 messages would be good. I could see a crypto secured broadcast working=20 like so:
=C2=A0 - Broadcast Subscribe (In contrast to normal = subscribe)
=C2=A0 - Browser Agent makes Provide Subscription = request to Application, including request (flag) to be issued the broadcast= key
=C2=A0 - Browser stores the broadcast key with the new s= ubscription (rather than generating its own key)

Section 5:
- The examples show plain-text notification content while 8.1 indicates=20 subscriptions include a crypto key, so they should be an opaque=20 encrypted blob
- The Push Server should return an appropriate Bad=20 Auth HTTP status code when authorization is required of the Application=20 Server.

Section 6:
- Should also show an en= crypted blob

Section 7.2:
- It would be use= ful to have some minimum storage period

Section 7.3:
<= /div>
- It says the push service can expire it anytime, what happens if a=20 client is disconnected during this time? Or are push services only=20 allowed to expire subscriptions while the client is connected?

Section 8.3/8.4:
- It seems reasonable that Push Service providers will want to require an App-Server developer to register their app and get an Oauth token or=20 some other scheme to indicate that they are allowed to push=20 notifications (and for Push Service providers to restrict maximum=20 messages/throughput on a per-app basis). Should this be mentioned here?
=

Cheers,
Ben

On Fri, D= ec 12, 2014 at 4:01 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
I've revised the = protocol proposal for web push.

https://datatracker.ietf.org/doc/draft-thomson-webpush-htt= p2/

A more readable HTML version is here, though this will be updated as I
make changes:

https://martinthomson.github.io/drafts/draft-tho= mson-webpush-http2.html

This includes some fairly significant changes to incorporate the
feedback I've received from various corners.=C2=A0 I haven't prepar= ed a
change log, but I believe that this covers at least the high points of
what was discussed at the meeting:

=C2=A0- names of everything have changed
=C2=A0- I've added examples and expanded the explanatory text throughou= t
=C2=A0- removed use of 202 due to a privacy concern (thanks to Robert
Sparks for sharing his experience with this)
=C2=A0- significantly expanded the operational considerations regarding
load distribution and message retention
=C2=A0- minimum message size of 4k added

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


--f46d043c7ee299842b050eee2c1a-- From nobody Thu Feb 12 18:46:53 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 7D41D1A0AF8 for ; Thu, 12 Feb 2015 18:46:43 -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, 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 H2pMTJqxD0aj for ; Thu, 12 Feb 2015 18:46:40 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0708.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:708]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0895E1A1A66 for ; Thu, 12 Feb 2015 18:46:40 -0800 (PST) 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.87.13; Fri, 13 Feb 2015 02:46:23 +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.0087.013; Fri, 13 Feb 2015 02:46:23 +0000 From: "Brian Raymor (MS OPEN TECH)" To: "webpush@ietf.org" Thread-Topic: Feedback on draft-thomson-webpush-http2-02 Thread-Index: AdBHKFp8U9Vp+oxdSPGQKU6/2NUTHA== Date: Fri, 13 Feb 2015 02:46:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2601:8:9500:ee:8d5d:b0f5:119c:64d6] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2PR0301MB0647; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0647; x-forefront-prvs: 0486A0CB86 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(46102003)(92566002)(86612001)(110136001)(33656002)(19580395003)(76576001)(99286002)(77156002)(229853001)(40100003)(62966003)(450100001)(2351001)(107886001)(122556002)(74316001)(2900100001)(87936001)(2656002)(2501002)(230783001)(102836002)(15975445007)(86362001)(50986999)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0647; H:BY2PR0301MB0647.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 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: 13 Feb 2015 02:46:23.7514 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0647 Archived-At: Subject: [Webpush] Feedback on draft-thomson-webpush-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: Fri, 13 Feb 2015 02:46:43 -0000 We plan to attend the IETF 92 meeting and to share proposals prior to the M= arch 9th cut-off date. 1.1. Conventions and Terminology Minor - recommend consistent use of "user agent" throughout the draft. Ther= e are also references to "client" or "device". For example: > "the device creates a registration resource" > "A client sends a POST" Section 2. Overview The diagram illustrates "Provide Subscription" between the UA and its Appli= cation Server, but there are no further details in the draft. While the exp= ectation is that this is left unspecified by the protocol, further details = could be outlined - similar to the text for Push Server discovery and autho= rization? Section 3. Subscription > The push server includes the "registration" link relation in a Locati= on header field. > HTTP/1.1 201 Created > .... > Link: ; > rel=3D"urn:ietf:params:push:reg" > Location: https://push.example.net/reg/1G_GIPMorg_n-IrQvqZr6g In the sample response, should the Location header and the Registration Lin= k paths correspond: Link: ; ... Location: https://push.example.net/monitor/1G_GIPMorg_n-IrQvqZr6g Section 5. Requesting Push Message Delivery This could be removed since it is simply implementation guidance? > A push service that does not store messages can stream the payload of > push messages to the user agent. Flow control SHOULD be used to > limit the state commitment for delivery of large messages. We plan to propose an optional payload to support parameters such as: * time-to-live=20 * multicast * delivery receipt Section 6. Receiving Push Messages No error conditions/behaviors are defined for cases such as an invalid :pat= h in the PUSH_PROMISE? > ... This request also triggers the delivery > of all push messages that the push service has stored but not yet > delivered. Could details of the response be further clarified? > A user agent can request the last push message for a "subscription" > resource by sending GET requests to its URI. What is the scenario for this case? Is it related to collapsible messages? Section 7.2 Push Message expiration It would be useful for the Application Server to be able to send a hint to = the Push Server for time-to-live. This is a common feature in existing impl= ementations. > ... Stored push messages > SHOULD include a Last-Modified header field (see Section 2.2 of > [RFC7232]) indicating when delivery was requested by an application > server. Why is a SHOULD preferred rather than a MUST? Section 7.3 Registration and Subscription Expiration > If a user agent has an outstanding request to the > "registration" resource (see Section 6), this can be signaled by > returning a 400-series response code, such as 410 (Gone). A push > service uses server push to indicate that a subscription has expired; > a pushed 400-series status code for the subscription resource signals > the termination of a subscription. What status code does an Application Server receive for expirations and ter= minations? > A user agent can request that a registration or subscription be > removed by sending a DELETE request to the corresponding URI. If the registration is deleted, then are the related subscriptions also del= eted? Section 7.4 Implications for Application reliability > An application developer might find it tempting to create alternative > mechanisms for message delivery in case the push service fails to > deliver a critical message. > ... > Applications are encouraged to instead provide a means to detect > situations where push messages were not delivered and recover > gracefully. For instance, an application server might include a > sequence number in push messages; a gap in the sequence can then be > used to trigger some form of state resynchronization. It may be difficult to maintain a per-application sequence counter at scale= . This also introduces complexity into the user agent. As noted above, our = preference is for the protocol to support delivery receipts. Section 8.1 Confidentiality from Push Server Access > The Web Push API codifies this practice by requiring that each push > subscription created by the browser be bound to a browser generated > encryption key. This should include the [API] informative reference? Is the W3C consensus s= till pending: =20 * Force confidentiality and integrity protection (encryption) #55 (https://= github.com/w3c/push-api/issues/55) * Add an Encryption Key array to the PushRegistration interface #89 (https://github.com/w3c/push-api/pull/89) and is it useful to reference in the protocol? 8.4. Denial of Service Considerations > End-to-end confidentiality mechanisms, such as those in [API], Similar comment as in Section 8.1. Brian Raymor Senior Program Manager Microsoft Open Technologies, Inc.=20 A subsidiary of Microsoft Corporation From nobody Thu Feb 12 20:41:18 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 643D91A0081 for ; Thu, 12 Feb 2015 20:41:11 -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 yC6cwQTrjoTs for ; Thu, 12 Feb 2015 20:41:08 -0800 (PST) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57AD81A007A for ; Thu, 12 Feb 2015 20:41:08 -0800 (PST) Received: by mail-ob0-f173.google.com with SMTP id uy5so16161902obc.4 for ; Thu, 12 Feb 2015 20:41:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=oV7GQ8Bdg1tsm7XvakBzWhiBXIJmaU/Fuxwf+v1CRwM=; b=Fziy6EfjMRnPFr0+i0ndzCjmY2gXzTKxTQUNpayRCHYEz4gx5T/CSPk22ltOQcXtkS UORqEVUt1jR5hRULIs8HJNhBmkHkhcpZuvuj7wpWxQd+URBqG45qs7cptOFa37G5JwLb vDWifIxHRnKyIUWCliflVBwXKOgvcEdvKJdjtB/3xtYZ50+pDJEv86YH7S/Oz+LuqoPo XMDJjXaY+NW6b9L58WSgEKlpWnuj+2UTnc7WUoNpEsYBg6gUgHFTN+H4yrCIQby1eu8w vrKMckI3pLDlWTcJfR8MHp/grUdKGWO1dW41mt/PiPGDsl/4vnolXx56cJ0VEQczQhxh 5chw== MIME-Version: 1.0 X-Received: by 10.202.75.8 with SMTP id y8mr4927964oia.12.1423802467693; Thu, 12 Feb 2015 20:41:07 -0800 (PST) Received: by 10.202.225.135 with HTTP; Thu, 12 Feb 2015 20:41:07 -0800 (PST) Date: Fri, 13 Feb 2015 15:41:07 +1100 Message-ID: From: Martin Thomson To: Benjamin Bangert Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" Subject: [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: Fri, 13 Feb 2015 04:41:11 -0000 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? From nobody Thu Feb 12 23:04: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 C0B321A0AF1 for ; Thu, 12 Feb 2015 23:04:10 -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 eGAz4stArYGB for ; Thu, 12 Feb 2015 23:04:05 -0800 (PST) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CD6F1A1A79 for ; Thu, 12 Feb 2015 23:04:05 -0800 (PST) Received: by mail-ob0-f180.google.com with SMTP id vb8so16876357obc.11 for ; Thu, 12 Feb 2015 23:04:04 -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:content-transfer-encoding; bh=DBQrUWjd0J/wx7Z/jNBFgnmvwBqW90d7poUYOVpiPI4=; b=XGYbS1vN45TZpPmOr0Xde9zzmdcGsPfh9Adcp11OX8t40bHigxKi95cQ81smtbAPOe Izf1zDnEiLiTW7RsDS9RXLNbirjWBG3gkCpIqPADQsUJ1yloV9ZN/LQu11h1NLmZWB6V SABQGRDHzWxu753gLi2lXWcfKJbiFQltWhnetPu2sRJQCeXjQveKG/JsqMoMKTY+DXL5 TuFLUtaiNQtFMRQa5TswFB2/4W5jywd3bd8Wa5wBVIRYtyo3ZL0M9Or4IUrMkAPJ6qur mdFYN3v8Ino+hf3I0zJsTG4apAi940ykt/8RlWCQl0ui6YIrQl4ZjIDMcIJP/UI3BXSK Wc7w== MIME-Version: 1.0 X-Received: by 10.202.75.8 with SMTP id y8mr5185795oia.12.1423811044821; Thu, 12 Feb 2015 23:04:04 -0800 (PST) Received: by 10.202.225.135 with HTTP; Thu, 12 Feb 2015 23:04:04 -0800 (PST) In-Reply-To: References: Date: Fri, 13 Feb 2015 18:04:04 +1100 Message-ID: From: Martin Thomson To: "Brian Raymor (MS OPEN TECH)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Feedback on draft-thomson-webpush-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: Fri, 13 Feb 2015 07:04:11 -0000 Thanks Brian, I'll see if I can address specific cases here, though I'll break out a new thread for larger issues. On 13 February 2015 at 13:46, Brian Raymor (MS OPEN TECH) wrote: > We plan to attend the IETF 92 meeting and to share proposals prior to the= March 9th cut-off date. > > > 1.1. Conventions and Terminology > > Minor - recommend consistent use of "user agent" throughout the draft. Th= ere are also references to "client" or "device". For example: > > "the device creates a registration resource" > > "A client sends a POST" Yep, that's plain sloppy on my part. Fixed in [e74ef81] > Section 2. Overview > > The diagram illustrates "Provide Subscription" between the UA and its App= lication Server, but there are no further details in the draft. While the e= xpectation is that this is left unspecified by the protocol, further detail= s could be outlined - similar to the text for Push Server discovery and aut= horization? I think that's fair. Do you have text that you would like to see, or should I just throw something together and iterate? [...] > In the sample response, should the Location header and the Registration L= ink paths correspond: > > Link: ; > ... > Location: https://push.example.net/monitor/1G_GIPMorg_n-IrQvqZr6g Good catch. I think that Daniel already pointed it out, because I've already fixed it. > Section 5. Requesting Push Message Delivery > > This could be removed since it is simply implementation guidance? > > > A push service that does not store messages can stream the payload = of > > push messages to the user agent. Flow control SHOULD be used to > > limit the state commitment for delivery of large messages. > > We plan to propose an optional payload to support parameters such as: > > * time-to-live > * multicast > * delivery receipt Those are definitely important features. I always imagined that the Expires header field would suffice for TTL, but after reviewing RFC 7234, I don't think that's quite right. Multicast is interesting, depending of course on what you intend to do with it (see https://tools.ietf.org/html/draft-thomson-webpush-aggregate for a potential take on the problem). I have had some ideas for how to handle delivery receipt notifications, but haven't got anything concrete. I'd be happy to see a proposal. > Section 6. Receiving Push Messages > > No error conditions/behaviors are defined for cases such as an invalid :p= ath in the PUSH_PROMISE? Ignore or reset should work. I've noted that in [adf9374]. > > ... This request also triggers the delivery > > of all push messages that the push service has stored but not yet > > delivered. > > Could details of the response be further clarified? Sounds reasonable. This is just more server pushes. I've added something, though I note that this might change or interact with any delivery receipt feature that you might propose. [79fee57] > > A user agent can request the last push message for a "subscription" > > resource by sending GET requests to its URI. > > What is the scenario for this case? Is it related to collapsible messages= ? The way that this is structured, each subscription effectively has a single "collapse key". Depending on how long a server is willing to retain data, a request to the subscription URI should return the data that was pushed. > Section 7.2 Push Message expiration > > It would be useful for the Application Server to be able to send a hint t= o the Push Server for time-to-live. This is a common feature in existing im= plementations. Indeed. I've opened an issue to track this: https://github.com/martinthomson/drafts/issues/21 I'll follow up with a separate thread too. > > ... Stored push messages > > SHOULD include a Last-Modified header field (see Section 2.2 of > > [RFC7232]) indicating when delivery was requested by an application > > server. > > Why is a SHOULD preferred rather than a MUST? Because it's not clear to me that all the various push services can provide this information. If the working group thinks that a MUST is OK, then I'd certainly prefer a MUST. I'll follow up on this separately. https://github.com/martinthomson/drafts/issues/22 > Section 7.3 Registration and Subscription Expiration > > > If a user agent has an outstanding request to the > > "registration" resource (see Section 6), this can be signaled by > > returning a 400-series response code, such as 410 (Gone). A push > > service uses server push to indicate that a subscription has expire= d; > > a pushed 400-series status code for the subscription resource signa= ls > > the termination of a subscription. > > What status code does an Application Server receive for expirations and t= erminations? That's definitely an oversight. Fixed in [223d0bb]. > If the registration is deleted, then are the related subscriptions also d= eleted? Yep, fixed with the above. > Section 7.4 Implications for Application reliability > > > An application developer might find it tempting to create alternati= ve > > mechanisms for message delivery in case the push service fails to > > deliver a critical message. > > ... > > Applications are encouraged to instead provide a means to detect > > situations where push messages were not delivered and recover > > gracefully. For instance, an application server might include a > > sequence number in push messages; a gap in the sequence can then be > > used to trigger some form of state resynchronization. > > It may be difficult to maintain a per-application sequence counter at sca= le. This also introduces complexity into the user agent. As noted above, ou= r preference is for the protocol to support delivery receipts. This sort of state retention wasn't particularly onerous for the applications that I've worked on, since we needed for other reasons anyway. That said, we would have definitely preferred to receive application-level acknowledgements. That is generally the best reliability mechanism. > Section 8.1 Confidentiality from Push Server Access [...] > This should include the [API] informative reference? Is the W3C consensus= still pending: Yeah, well, I've pre-empted the decision there a little. I think that the main hold-up on that end is the absence of anything in the IETF that can be referenced. Bootstrapping is hard. I hope to have something to announce here soon. From nobody Mon Feb 16 07:00: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 0537E1A1EE8 for ; Mon, 16 Feb 2015 07:00:19 -0800 (PST) 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 EDYOzk5lAlg4 for ; Mon, 16 Feb 2015 07:00:14 -0800 (PST) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) (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 A848E1A1EEB for ; Mon, 16 Feb 2015 06:59:51 -0800 (PST) Received: by labhs14 with SMTP id hs14so28831941lab.1 for ; Mon, 16 Feb 2015 06:59:50 -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=zATgQxjb+V75XDXu6WluJV+kLu+n3OCNn1QumyQqXjw=; b=kWzrMSWCcseTsui6dxxKhAXPmUyxYmjpEXlnvEOKieWAdE1ij87wyUipgl6iRMzINu fLUed3NmRi3dgJpd7bdxD1Lx+8cfzDNY4BHKomMf3bn622etRW3FYSLeI3xwgYF5W4gr JJcK35FPZNBNrSj3P9ZOXcXCN5FmW0jCpE8q7OwRhXuKtchOwHYSdiyapU8ljUXIt6oD zQoTw2/LInK3SP7M9hmCxJs0HSn2WW+Ev+IWuyAufsra0HNxkZBhNY2c0enj/Zw8Y+JW N1Db8LorWzbz/NTkc7W0mFd7tnusJgZel4FYW5k6R/YNGfSdyVo5z7V5OpdR4YOukSwB /Zww== X-Gm-Message-State: ALoCoQm9bEtunXyb9NIaD0SXm1JfMql4hfcJ61MOVLRKIpUJNcomRn8ukHx8xBYfKFxBNEeZhKv6 MIME-Version: 1.0 X-Received: by 10.112.39.69 with SMTP id n5mr20439811lbk.1.1424098790190; Mon, 16 Feb 2015 06:59:50 -0800 (PST) Received: by 10.25.212.203 with HTTP; Mon, 16 Feb 2015 06:59:50 -0800 (PST) In-Reply-To: References: <539F7058-12CE-47BA-82CD-BB5413947F20@ntt-at.com> Date: Mon, 16 Feb 2015 07:59:50 -0700 Message-ID: From: Eduardo Gueiros To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=001a11349d2083c5fa050f35d6fd Archived-At: Cc: Shida Schubert , Alissa Cooper , "webpush@ietf.org" Subject: Re: [Webpush] Webpush at 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: Mon, 16 Feb 2015 15:00:19 -0000 --001a11349d2083c5fa050f35d6fd Content-Type: text/plain; charset=UTF-8 I think there's definitely interest as demonstrated in IETF 91. If you know someone who raised their hands and have not yet expressed themselves, try to engage them. I know a few, and I myself I am guilty of not being more active in this WG as originally committed. I think it's an important subject matter that should not be easily dismissed. On Thu, Feb 12, 2015 at 1:47 PM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > (co-chair hat on) > > Seconding Shida here. Nobody has responded yet. Speak up if you care, > please. > > > On 2/11/15, 8:46 PM, "Shida Schubert" wrote: > > > > >All; > > > >I have tentatively booked 1.5 hour in Dallas to meet and discuss face to > >face but seeing that there has been little to no traffic since the last > >IETF, despite number of hands indicating that they will contribute, I am > >doubting the need to hold the meeting. > > > >Actually the only email that was sent out to the list was Martin > >informing the WG that he has submitted the updated version of the core > >draft addressing all the comments. > > > >Furthermore, with so little traffic we see on the list, should we > >consider closing the WG? > > > >I would like to hear from the WG whether the work indicated on the > >charter is worthwhile pursuing and if there are enough energy backing it. > > > >Many Thanks! > > > >Shida as a co-chair > >_______________________________________________ > >Webpush mailing list > >Webpush@ietf.org > >https://www.ietf.org/mailman/listinfo/webpush > > > > > -- > Joe Hildebrand > > > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > --001a11349d2083c5fa050f35d6fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think there's definitely interest as demonstrated in= IETF 91. If you know someone who raised their hands and have not yet expre= ssed themselves, try to engage them. I know a few, and I myself I am guilty= of not being more active in this WG as originally committed. I think it= 9;s an important subject matter that should not be easily dismissed. =C2=A0=

On Thu, Feb= 12, 2015 at 1:47 PM, Joe Hildebrand (jhildebr) <jhildebr@cisco.com&g= t; wrote:
(co-chair hat on)

Seconding Shida here.=C2=A0 Nobody has responded yet.=C2=A0 Speak up if you= care,
please.


On 2/11/15, 8:46 PM, "Shida Schubert" <shida@ntt-at.com> wrote:

>
>All;
>
>I have tentatively booked 1.5 hour in Dallas to meet and discuss face t= o
>face but seeing that there has been little to no traffic since the last=
>IETF, despite number of hands indicating that they will contribute, I a= m
>doubting the need to hold the meeting.
>
>Actually the only email that was sent out to the list was Martin
>informing the WG that he has submitted the updated version of the core<= br> >draft addressing all the comments.
>
>Furthermore, with so little traffic we see on the list, should we
>consider closing the WG?
>
>I would like to hear from the WG whether the work indicated on the
>charter is worthwhile pursuing and if there are enough energy backing i= t.
>
>Many Thanks!
>
>Shida as a co-chair
>_______________________________________________
>Webpush mailing list
>Webpush@ietf.org
>https://www.ietf.org/mailman/listinfo/webpush
>


--
Joe Hildebrand



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

--001a11349d2083c5fa050f35d6fd-- From nobody Thu Feb 19 23:12: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 01BD61A1A06 for ; Thu, 19 Feb 2015 23:11:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVVxIO95gTu8 for ; Thu, 19 Feb 2015 23:11:57 -0800 (PST) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A44C1A1A95 for ; Thu, 19 Feb 2015 23:11:57 -0800 (PST) Received: by mail-ob0-f170.google.com with SMTP id va2so22590083obc.1 for ; Thu, 19 Feb 2015 23:11:56 -0800 (PST) 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=g8ePm41bXwJ3VDY2vuDHMk+X5yxkB2ztfDpDziw255s=; b=ochJW606eyLd1e/yQrumKtcCDDnGgL4FGs2OmATcL1yLnJuwx2ECdTlfPU0thdO/yc cxq9dDstDNA7TxE3PFt6ZQ1/77U2iVwrz7nHnJcXRlg0P29q73wwzmwhP4bPi3ZYxhp0 qH2jTKQkmfajxvGyQ8bTpXj1cj41ww68hACi0MM05er5eGTjTdzUg72s7mSBlJbDsurD M4tIrO85o9/hMB/RcVoJpApyzHdei8vt+D6tqutoNaEqQdX3niETybEJO0O1i2rm0Q/o XMkiLxsgaAFDMUV4+bz4CHhXxBChkXJweM5HmwYwqO0DcZr7dvRcY3fGFuHCeb0LC9cg rIqg== MIME-Version: 1.0 X-Received: by 10.202.185.198 with SMTP id j189mr5362053oif.72.1424416316391; Thu, 19 Feb 2015 23:11:56 -0800 (PST) Received: by 10.202.225.135 with HTTP; Thu, 19 Feb 2015 23:11:56 -0800 (PST) Date: Fri, 20 Feb 2015 20:11:56 +1300 Message-ID: From: Martin Thomson To: "webpush@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Webpush] Time to live for push 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: Fri, 20 Feb 2015 07:11:59 -0000 A common problem with push message delivery services looks like this: 1. A push is requested by an application server. 2. The user agent is offline temporarily, so the push service stores the message. 3. The user agent returns long after the event is interesting, but the message is delivered anyway. 4. The user agent acts on a message that is now useless, and which could be harmful. This is particularly annoying for something like a call notification, which might be delivered well after the caller gives up on the call. For these, an application can add its own suppression mechanisms. Though manual suppression introduces a trade-off between risk of showing a dead alert and added latency. Also, there isn't anything that can be done about the battery power that was spent in delivering the useless message. So, most systems implement a suppression system at the push service, where an application server can indicate that a message should not be delivered after some point in time. (I've seen one with suppression that occurs only at the client, but that was spectacularly unsuccessful.) The trick here is in working out how to express this. I see a few options: A. RFC 4918 describes a Timeout header field, which has semantics that apply only to the LOCK method. That could be extended to apply to PUT. B. A new header field could be defined to carry the information. This would have the same semantics as the above. C. We could start to explore message payloads. I prefer the header field options, with a slight preference for reusing Timeout (even if that means updating RFC 4918). The precise semantics would need a little work, but here's a straw man outline: The Timeout header field applies to unsafe requests only. The client indicates that changes to the state of a resource as a result of processing the request are to be reset after the described interval elapses. The state that the resource is reset *to* is undefined, for a number of reasons: not all resources will know and support this header field, some changes might be irreversible, servers are always free to set the state of a resource to whatever they like, and it would be nice to avoid the complexity of having multiple interacting layers of timeout. You will note that this is compatible with the definition of Timeout as defined in RFC 4918, including the fact that the server can do nothing with the lock at the timeout expiration time. The final consideration here is whether this is something that needs to enter the core specification, or whether it would be better as a separate specification. I have no opinion on that. From nobody Sat Feb 21 09:53:14 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 115341A1A7F for ; Sat, 21 Feb 2015 09:53:13 -0800 (PST) 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 GgjMs4-Ak2cV for ; Sat, 21 Feb 2015 09:53:07 -0800 (PST) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEE0D1A1B39 for ; Sat, 21 Feb 2015 09:53:06 -0800 (PST) Received: by iecvy18 with SMTP id vy18so14859315iec.6 for ; Sat, 21 Feb 2015 09:53:06 -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=uujMYQGawLdAIo9wxrsHBcRblQuIzuFk8CEsGdyEmoc=; b=HNKmHwt/F2Q//8l0WR/YYIfoQZtmUnK8sJa89pPSUkGLHtFUtZ/kiIQkoQv7LPR7Xv 48Wh5wQ7XGaCw4kMs0HY2RmHRKsullnLSrtPvJPQyJTL9cJt2zjV0bnzWROEXyRpS3e4 lN0Bwn7//wzuezfjAoAEyiAGfbcBwFWmvHtzclBFYVoA5EA+Ik7lTpumUMIXs35g/R1j /ikoDNBa8lhSAwqUuOKKbYwdBOYZrAyJ46dztsbmwajYi2bpCROhwmOnx90iACLEDxLS s1sOdPmsluw9+jLbxg8iGb7l/uhD6SCjqS8rQ2nJaybpF0KSS6yXd8jZWKySxBSCR9L6 0hkQ== MIME-Version: 1.0 X-Received: by 10.50.109.228 with SMTP id hv4mr3711358igb.45.1424541185814; Sat, 21 Feb 2015 09:53:05 -0800 (PST) Received: by 10.64.86.135 with HTTP; Sat, 21 Feb 2015 09:53:05 -0800 (PST) In-Reply-To: References: Date: Sat, 21 Feb 2015 09:53:05 -0800 Message-ID: From: Costin Manolache To: Martin Thomson Content-Type: multipart/alternative; boundary=089e013a214e5938bc050f9cd743 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Time to live for push 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: Sat, 21 Feb 2015 17:53:13 -0000 --089e013a214e5938bc050f9cd743 Content-Type: text/plain; charset=UTF-8 For option A: the format in RFC4918 is "Infinite | Second-1234". Unless 'infinite' is defined to be few weeks - it is going to be hard to support. I think using seconds instead of absolute value is very good. RFC3261 (SIP) uses ';ttl=12' as a URI parameter - without the constant "Second-". I would personally prefer this option. "Expires" header is another option. Going into payload is interesting as well - we need to start discussing the actual format of the payload, but it seems pretty likely that a part will be encrypted, and some part will be clear text but signed. It's a tricky subject - but if Jose/JWE or something similar is used, we will may want to have any parameters that the push server needs to interpret into the signed/authenticated portion of the payload - otherwise we would need to worry about signing some headers or the URI. An important decision is if the ttl (and other timestamps) need to be sent to the device and authenticated or it is going to be dropped or modified during transport. Another complication may be the case the message is forwarded multiple times, there are few cases where this may become necessary. Other things to consider are: - how to deal with servers that don't support a particular ttl value - how to discover max value for a push provider I think the core specification needs to define at least how to encode parameters that are used by the push server (== clear text). Costin On Thu, Feb 19, 2015 at 11:11 PM, Martin Thomson wrote: > A common problem with push message delivery services looks like this: > > 1. A push is requested by an application server. > 2. The user agent is offline temporarily, so the push service stores > the message. > 3. The user agent returns long after the event is interesting, but the > message is delivered anyway. > 4. The user agent acts on a message that is now useless, and which > could be harmful. > > This is particularly annoying for something like a call notification, > which might be delivered well after the caller gives up on the call. > For these, an application can add its own suppression mechanisms. > Though manual suppression introduces a trade-off between risk of > showing a dead alert and added latency. Also, there isn't anything > that can be done about the battery power that was spent in delivering > the useless message. > > So, most systems implement a suppression system at the push service, > where an application server can indicate that a message should not be > delivered after some point in time. (I've seen one with suppression > that occurs only at the client, but that was spectacularly > unsuccessful.) > > The trick here is in working out how to express this. I see a few options: > > A. RFC 4918 describes a Timeout header field, which has semantics that > apply only to the LOCK method. That could be extended to apply to > PUT. > > B. A new header field could be defined to carry the information. This > would have the same semantics as the above. > > C. We could start to explore message payloads. > > I prefer the header field options, with a slight preference for > reusing Timeout (even if that means updating RFC 4918). The precise > semantics would need a little work, but here's a straw man outline: > > The Timeout header field applies to unsafe requests only. The > client indicates that changes to the state of a resource as a result > of processing the request are to be reset after the described interval > elapses. The state that the resource is reset *to* is undefined, for > a number of reasons: not all resources will know and support this > header field, some changes might be irreversible, servers are always > free to set the state of a resource to whatever they like, and it > would be nice to avoid the complexity of having multiple interacting > layers of timeout. > > You will note that this is compatible with the definition of Timeout > as defined in RFC 4918, including the fact that the server can do > nothing with the lock at the timeout expiration time. > > The final consideration here is whether this is something that needs > to enter the core specification, or whether it would be better as a > separate specification. I have no opinion on that. > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > --089e013a214e5938bc050f9cd743 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
For option A: the format in RFC4918 is "Infinite | Se= cond-1234".=C2=A0
Unless 'infinite' is defined to be few w= eeks - it is going to be hard to support.=C2=A0
I think using sec= onds instead of absolute value is very good.

RFC32= 61 (SIP) uses ';ttl=3D12' as a URI parameter - without the constant= "Second-".
I would personally prefer this option.

"Expires" header is another option.

Going into payload is interesting as well - we need to sta= rt discussing the actual
format of the payload, but it seems pret= ty likely that a part will be encrypted, and some part will be
cl= ear text but signed. It's a tricky subject - but if Jose/JWE or somethi= ng similar is=C2=A0
used, we will may want to have any parameters= that the push server needs to interpret
into the signed/authenti= cated portion of the payload - otherwise we would need to worry about=C2=A0=
signing some headers or the URI.=C2=A0 An important decision is = if the ttl (and other timestamps)
need to be sent to the device a= nd authenticated or it is going to be dropped or modified
during = transport.

Another complication may be the case th= e message is forwarded multiple times, there=C2=A0
are few cases = where this may become necessary.=C2=A0

Other thing= s to consider are:
- how to deal with servers that don't supp= ort a particular ttl value
- how to discover max value for a push= provider

I think the core specification needs to = define at least how to encode parameters that are used by
the pus= h server (=3D=3D clear text).=C2=A0

Costin




On Thu, Feb 19, 2015 at 11:11 PM, Martin Th= omson <martin.thomson@gmail.com> wrote:
A common problem with push message delivery services l= ooks like this:

1. A push is requested by an application server.
2. The user agent is offline temporarily, so the push service stores
the message.
3. The user agent returns long after the event is interesting, but the
message is delivered anyway.
4. The user agent acts on a message that is now useless, and which
could be harmful.

This is particularly annoying for something like a call notification,
which might be delivered well after the caller gives up on the call.
For these, an application can add its own suppression mechanisms.
Though manual suppression introduces a trade-off between risk of
showing a dead alert and added latency.=C2=A0 Also, there isn't anythin= g
that can be done about the battery power that was spent in delivering
the useless message.

So, most systems implement a suppression system at the push service,
where an application server can indicate that a message should not be
delivered after some point in time.=C2=A0 (I've seen one with suppressi= on
that occurs only at the client, but that was spectacularly
unsuccessful.)

The trick here is in working out how to express this.=C2=A0 I see a few opt= ions:

A. RFC 4918 describes a Timeout header field, which has semantics that
apply only to the LOCK method.=C2=A0 That could be extended to apply to
PUT.

B. A new header field could be defined to carry the information.=C2=A0 This=
would have the same semantics as the above.

C. We could start to explore message payloads.

I prefer the header field options, with a slight preference for
reusing Timeout (even if that means updating RFC 4918).=C2=A0 =C2=A0The pre= cise
semantics would need a little work, but here's a straw man outline:

=C2=A0 =C2=A0The Timeout header field applies to unsafe requests only.=C2= =A0 The
client indicates that changes to the state of a resource as a result
of processing the request are to be reset after the described interval
elapses.=C2=A0 The state that the resource is reset *to* is undefined, for<= br> a number of reasons: not all resources will know and support this
header field, some changes might be irreversible, servers are always
free to set the state of a resource to whatever they like, and it
would be nice to avoid the complexity of having multiple interacting
layers of timeout.

You will note that this is compatible with the definition of Timeout
as defined in RFC 4918, including the fact that the server can do
nothing with the lock at the timeout expiration time.

The final consideration here is whether this is something that needs
to enter the core specification, or whether it would be better as a
separate specification.=C2=A0 I have no opinion on that.

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

--089e013a214e5938bc050f9cd743-- From nobody Sat Feb 21 14:33:06 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 2423A1A00F6 for ; Sat, 21 Feb 2015 14:33:05 -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 0QWcPeG2Wa-2 for ; Sat, 21 Feb 2015 14:33:03 -0800 (PST) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 396021A004B for ; Sat, 21 Feb 2015 14:33:03 -0800 (PST) Received: by mail-oi0-f54.google.com with SMTP id v63so8153725oia.13 for ; Sat, 21 Feb 2015 14:33:02 -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=IRhe8cYPArsVk87b6fgXvrHmUHrASYcwyuiUpEULjmw=; b=f4jyWVgS6nOqQaJo9P2LcHC2NiltCb9FsVYqMIGpJgUyBRrHO3oyNyDf8cgA0ecS0s 37vlhZWT49kQ220Vi9SrzZ2hMyz0qgiT2V1V0ZEjC0V8XxOKVdLLndFuOIM7afg/z2vq PfIa8jEyykxbr73fD8AIbwbrtl+UpUrDsZBWCg/cgfLaEA8hLu7v2DZXpHxEm3WhyLTi cbeKBAnnGfU7oJXQec2Ww9Zo2GxvjVbbjEXagCaXtc+794mHDqFI3i28b2KwqX8uvDQQ PWHZ3T9EhhBB6yOoSW+FFdzZ//+PCXZ7smPnx3+6ES+BPO+h2S7BPegaPz4CcTC6MA2m 7rXA== MIME-Version: 1.0 X-Received: by 10.60.92.5 with SMTP id ci5mr2808017oeb.26.1424557982497; Sat, 21 Feb 2015 14:33:02 -0800 (PST) Received: by 10.202.225.135 with HTTP; Sat, 21 Feb 2015 14:33:02 -0800 (PST) In-Reply-To: References: Date: Sun, 22 Feb 2015 11:33:02 +1300 Message-ID: From: Martin Thomson To: Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Time to live for push 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: Sat, 21 Feb 2015 22:33:05 -0000 On 22 February 2015 at 06:53, Costin Manolache wrote: > For option A: the format in RFC4918 is "Infinite | Second-1234". > Unless 'infinite' is defined to be few weeks - it is going to be hard to > support. > I think using seconds instead of absolute value is very good. It is customary for the server to have the ultimate authority on what the timeout actually is. A requested timeout of Infinite is always going to be shorter anyway, and if the client asks for a month and the server can only do a minute, then it will be a minute. The only question there is how much value there is in having the server notify the client about the actual timeout. I guess if a server refuses to store for a particular duration, a client could be forced to retry for that duration. > RFC3261 (SIP) uses ';ttl=12' as a URI parameter - without the constant > "Second-". > I would personally prefer this option. The format is unnecessarily clunky, I agree. > "Expires" header is another option. I considered that at some length and rejected it for two reasons: Expires only has defined semantics related to the cacheability of HTTP responses. Using Expires in a request context, even for a PUT (maybe even especially for a PUT) is well outside its original definition. Also, Expires uses an absolute time and clock skew has proven to be a major issue. In theory, an absolute time can be more precise, but most uses for a TTL are on short timescales where clock skew can dominate. At least with a relative time, transit times can be accounted for. > An important decision is if the ttl (and other timestamps) > need to be sent to the device and authenticated or it is going to > be dropped or modified during transport. As I alluded to in my first email, I think that the primary value of a TTL parameter is where the push service uses the value. Once the push hits the user agent, it's value is greatly diminished. Of course, there is nothing wrong with having the push message itself contain time-based information that is consumed by the application. > Another complication may be the case the message is > forwarded multiple times, there are few cases where > this may become necessary. If you are required to forward the message, that's an internal detail of the push service and I'd expect that you would account for any elapsed time there. You could, for instance, convert a relative time into an absolute time for internal consumption, knowing that your servers have good time synchronization. From nobody Sat Feb 21 15:26:36 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 0D62C1A0125 for ; Sat, 21 Feb 2015 15:26:35 -0800 (PST) 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 PvZT09Z87aiY for ; Sat, 21 Feb 2015 15:26:32 -0800 (PST) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62EF51A0121 for ; Sat, 21 Feb 2015 15:26:32 -0800 (PST) Received: by iecrd18 with SMTP id rd18so15816724iec.8 for ; Sat, 21 Feb 2015 15:26:31 -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=5xxUvC0dIHSD+FC8eLlL/bkm9ULNGSg6GYXYQirLwWs=; b=pdX8hsUzOXoW8PCeSZ7TpuihIaQaZrPD8Vv+ZUoIfXlibWJx7sUjmzIaA5p5/fJksv FQt/3K+fAseS2D/k1+fP8cLNVpczS9kIiDUU73HVlSK4Af4EiiUkxGL0tY4HyhNSot4m uXUT4kVQ56MTxMJkiZ9IDHEswEAH2Bj1R2FJHeKAAJ1L739xMeYHIf6m63fXZQyw0OP4 Mgt9TNtia9/65U8qLRfu/GhQPLbYEfEmXo8haDsTRXLkvgIaLSsxEj7U5r2Qv2B6hOfw t7DBFUT409stgNIG+7WBzeGQWjTUyG/rQhpbnEDz1OxkRCVuFeRvzgm23h7HICyRuN1R h+6g== MIME-Version: 1.0 X-Received: by 10.42.150.130 with SMTP id a2mr4665399icw.69.1424561191546; Sat, 21 Feb 2015 15:26:31 -0800 (PST) Received: by 10.64.86.135 with HTTP; Sat, 21 Feb 2015 15:26:31 -0800 (PST) In-Reply-To: References: Date: Sat, 21 Feb 2015 15:26:31 -0800 Message-ID: From: Costin Manolache To: Martin Thomson Content-Type: multipart/alternative; boundary=90e6ba21220bc87570050fa17fde Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Time to live for push 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: Sat, 21 Feb 2015 23:26:35 -0000 --90e6ba21220bc87570050fa17fde Content-Type: text/plain; charset=UTF-8 On Sat, Feb 21, 2015 at 2:33 PM, Martin Thomson wrote: > On 22 February 2015 at 06:53, Costin Manolache wrote: > > For option A: the format in RFC4918 is "Infinite | Second-1234". > > Unless 'infinite' is defined to be few weeks - it is going to be hard to > > support. > > I think using seconds instead of absolute value is very good. > > It is customary for the server to have the ultimate authority on what > the timeout actually is. A requested timeout of Infinite is always > going to be shorter anyway, and if the client asks for a month and the > server can only do a minute, then it will be a minute. > I agree - my comment was more on the slightly strange syntax - "Second-" prefix and "Infinite" constant are a bit odd compared with other ways to represent time. > > The only question there is how much value there is in having the > server notify the client about the actual timeout. I guess if a > server refuses to store for a particular duration, a client could be > forced to retry for that duration. > Server can include 'max ttl' in the response if it rejects too long time, so client can use max ttl. Or accept it with a shorter ttl, but include the shorter ttl in response. > > > RFC3261 (SIP) uses ';ttl=12' as a URI parameter - without the constant > > "Second-". > > I would personally prefer this option. > > The format is unnecessarily clunky, I agree. > Another benefit of having ttl as URL param - or in payload - is for the case message needs to go trough multiple servers. > > > "Expires" header is another option. > > I considered that at some length and rejected it for two reasons: > > Expires only has defined semantics related to the cacheability of HTTP > responses. Using Expires in a request context, even for a PUT (maybe > even especially for a PUT) is well outside its original definition. > > Also, Expires uses an absolute time and clock skew has proven to be a > major issue. In theory, an absolute time can be more precise, but > most uses for a TTL are on short timescales where clock skew can > dominate. At least with a relative time, transit times can be > accounted for. > Agreed - relative time in seconds sounds good, just URL param vs Header vs payload. > > > An important decision is if the ttl (and other timestamps) > > need to be sent to the device and authenticated or it is going to > > be dropped or modified during transport. > > As I alluded to in my first email, I think that the primary value of a > TTL parameter is where the push service uses the value. Once the push > hits the user agent, it's value is greatly diminished. > > Of course, there is nothing wrong with having the push message itself > contain time-based information that is consumed by the application. > One use case is a message that goes trough multiple servers - and may be gated on the client as well. For example message is for a multi-profile UA - and it gets delivered to the client machine but it can't be delivered to the intended profile ( stopped users on android for example ). Or in some cases the UA may display a notification before delivering the message to the app - if TTL expires it may drop the notification and message. The sender would include ttl=60, push server stores the message and delivers it after 20 seconds - than the forwarded message would have the remaining ttl=40 (or ttl=60, 'delay=20'). The message may have to wait on either client or intermediary server. > > > Another complication may be the case the message is > > forwarded multiple times, there are few cases where > > this may become necessary. > > If you are required to forward the message, that's an internal detail > of the push service and I'd expect that you would account for any > elapsed time there. You could, for instance, convert a relative time > into an absolute time for internal consumption, knowing that your > servers have good time synchronization. > That's easy if it's internal forwarding, I was thinking of the case of forwarding to a different push provider. We should consider the case - given the complicated world of mobile. Costin --90e6ba21220bc87570050fa17fde Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Feb 21, 2015 at 2:33 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
On 22 February 2015 at 06:53, Costin Manolache <costin@gmail.com> wrote:
> For option A: the format in RFC4918 is "Infinite | Second-1234&qu= ot;.
> Unless 'infinite' is defined to be few weeks - it is going to = be hard to
> support.
> I think using seconds instead of absolute value is very good.

It is customary for the server to have the ultimate authority on wha= t
the timeout actually is.=C2=A0 A requested timeout of Infinite is always going to be shorter anyway, and if the client asks for a month and the
server can only do a minute, then it will be a minute.

I agree - my comment was more on the slightly strange synta= x - "Second-"=C2=A0
prefix and "Infinite" con= stant are a bit odd compared with other ways
to represent time.= =C2=A0
=C2=A0

The only question there is how much value there is in having the
server notify the client about the actual timeout.=C2=A0 I guess if a
server refuses to store for a particular duration, a client could be
forced to retry for that duration.

Serv= er can include 'max ttl' in the response if it rejects too long tim= e,
so client can use max ttl. Or accept it with a shorter ttl, bu= t include the=C2=A0
shorter ttl in response.
=C2=A0

> RFC3261 (SIP) uses ';ttl=3D12' as a URI parameter - without th= e constant
> "Second-".
> I would personally prefer this option.

The format is unnecessarily clunky, I agree.
Another benefit of having ttl as URL param - or in payload - i= s for the=C2=A0
case message needs to go trough multiple servers.=
=C2=A0

> "Expires" header is another option.

I considered that at some length and rejected it for two reasons:
Expires only has defined semantics related to the cacheability of HTTP
responses.=C2=A0 Using Expires in a request context, even for a PUT (maybe<= br> even especially for a PUT) is well outside its original definition.

Also, Expires uses an absolute time and clock skew has proven to be a
major issue.=C2=A0 In theory, an absolute time can be more precise, but
most uses for a TTL are on short timescales where clock skew can
dominate.=C2=A0 At least with a relative time, transit times can be
accounted for.

Agreed - relative time i= n seconds sounds good, just=C2=A0
URL param vs Header vs payload.= =C2=A0


=C2=A0

> An important decision is if the ttl (and other timestamps)
> need to be sent to the device and authenticated or it is going to
> be dropped or modified during transport.

As I alluded to in my first email, I think that the primary value of= a
TTL parameter is where the push service uses the value.=C2=A0 Once the push=
hits the user agent, it's value is greatly diminished.

Of course, there is nothing wrong with having the push message itself
contain time-based information that is consumed by the application.

One use case is a message that goes trough mul= tiple servers - and may
be gated on the client as well. For examp= le message is for a multi-profile
UA - and it gets delivered to t= he client machine but it can't be delivered to=C2=A0
the inte= nded profile ( stopped users on android for example ). Or in
some= cases the UA may display a notification before delivering the message
to the app - if TTL expires it may drop the notification and message.=

The sender would include ttl=3D60, push server st= ores the=C2=A0
message and delivers it after 20 seconds - than th= e forwarded message would
have the remaining ttl=3D40 (or ttl=3D6= 0, 'delay=3D20'). The message may have=C2=A0
to wait on e= ither client or intermediary =C2=A0server.=C2=A0

> Another complication may be the case the message is
> forwarded multiple times, there are few cases where
> this may become necessary.

If you are required to forward the message, that's an internal d= etail
of the push service and I'd expect that you would account for any
elapsed time there.=C2=A0 You could, for instance, convert a relative time<= br> into an absolute time for internal consumption, knowing that your
servers have good time synchronization.

That's easy if = it's internal forwarding, I was thinking of the case of forwarding to
a different push provider. We should conside= r the case - given the complicated
world of= mobile.=C2=A0

Costin
--90e6ba21220bc87570050fa17fde-- From nobody Tue Feb 24 11:01: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 C326A1A887A for ; Tue, 24 Feb 2015 11:01:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 r8ACJ-CH1E5R for ; Tue, 24 Feb 2015 11:01:17 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0767.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:767]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7672D1A8878 for ; Tue, 24 Feb 2015 11:01:17 -0800 (PST) Received: from BN1PR0301MB0626.namprd03.prod.outlook.com (25.160.171.11) by BN1PR0301MB0611.namprd03.prod.outlook.com (25.160.170.26) with Microsoft SMTP Server (TLS) id 15.1.99.9; Tue, 24 Feb 2015 19:00:59 +0000 Received: from BN1PR0301MB0626.namprd03.prod.outlook.com (25.160.171.11) by BN1PR0301MB0626.namprd03.prod.outlook.com (25.160.171.11) with Microsoft SMTP Server (TLS) id 15.1.99.9; Tue, 24 Feb 2015 19:00:58 +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; Tue, 24 Feb 2015 19:00:58 +0000 From: Elio Damaggio To: Martin Thomson , Benjamin Bangert Thread-Topic: [Webpush] Broadcast (was Re: webpush for http2 -02) Thread-Index: AQHQR0dRdjQKEVJkfkiNVlpzjghP+p0AOG1A Date: Tue, 24 Feb 2015 19:00:58 +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::2] authentication-results: spf=none (sender IP is ) smtp.mailfrom=elioda@microsoft.com; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN1PR0301MB0626; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN1PR0301MB0611; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005004); SRVR:BN1PR0301MB0626; BCL:0; PCL:0; RULEID:; SRVR:BN1PR0301MB0626; x-forefront-prvs: 04976078F0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(189002)(199003)(3905003)(377454003)(13464003)(62966003)(77156002)(106356001)(106116001)(561944003)(105586002)(64706001)(99286002)(101416001)(97736003)(54356999)(76176999)(76576001)(50986999)(33656002)(46102003)(122556002)(87936001)(86612001)(2656002)(74316001)(15975445007)(86362001)(102836002)(68736005)(19580405001)(2950100001)(19580395003)(2900100001)(40100003)(92566002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR0301MB0626; H:BN1PR0301MB0626.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2015 19:00:58.2147 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR0301MB0626 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: Cc: "webpush@ietf.org" 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: Tue, 24 Feb 2015 19:01:20 -0000 Hi Martin, Continuing the discussion on broadcast, from our experience of designing an= d 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" st= atus, list of users following a certain sport team, enterprise or social gr= oups. The protocol has to be amenable to synching operations. In our experi= ence forcing explicit management of the topics (creation and deletion) hamp= ers these operations compared to more flexible approaches where tags are as= sociated to device tokens. Azure Notification Hubs is not the only system t= hat uses this kind of grouping; Urban Airship and Parse (now Facebook) have= a similar systems. Reference: https://msdn.microsoft.com/en-us/library/dn5= 30749.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". I= n a system where both of this kind of updates happen concurrently, having t= o 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 implemen= ter of the push aggregation system to allow Boolean expressions on topics t= o be used as targets. Consider a sports application that sends a reminder t= o 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 n= otification should be targeted to everyone in Boston who is interested in e= ither the Red Sox or the Cardinals. This condition can be expressed with th= e following Boolean expression: (follows_RedSox || follows_Cardinals) && lo= cation_Boston Notification Hubs, Urban Airship and Parse all support this feature. Even i= f 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 probabl= y 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=20 > messages would be good. I could see a crypto secured broadcast working li= ke so: > - Broadcast Subscribe (In contrast to normal subscribe) > - Browser Agent makes Provide Subscription request to Application,=20 > including request (flag) to be issued the broadcast key > - Browser stores the broadcast key with the new subscription (rather=20 > 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 sy= stem 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-existin= g relationship with (and therefore federate authorization). The disadvanta= ge is that it drives more of the responsibility for push fanout onto the ap= plication server. In your proposal here, how do you see the broadcast subscription being iden= tified and managed? Would an application request the creation of one and t= hen distribute it to its clients to subscribe to? _______________________________________________ Webpush mailing list Webpush@ietf.org https://www.ietf.org/mailman/listinfo/webpush From nobody Tue Feb 24 13:30:23 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 865D51A8928 for ; Tue, 24 Feb 2015 13:30:22 -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 7MgDNfrAUtKs for ; Tue, 24 Feb 2015 13:30:19 -0800 (PST) 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 9B1CE1A893E for ; Tue, 24 Feb 2015 13:30:19 -0800 (PST) Received: by mail-oi0-f46.google.com with SMTP id x69so21905704oia.5 for ; Tue, 24 Feb 2015 13:30:18 -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:content-transfer-encoding; bh=ekntwOj2cZwkGsXijSCgmsYNiotZgps4vT9YrooRL6Q=; b=Imw9bekQWlE4buWw8gDaS0d0zbKrsL2ugdRwB7O/BwrhUhXdBvogZWClaBDmYtHl/s pEeCmSDp7giLSYUX5gWIUOkj5W67+PxLdQWMZoEaAuuzQzI22AgjwqfEYIQYbLYqgR/k NWsRD99iAcVfuaP8a7+7AmZjg3NNd33EZdz+eFbZYINTfiC0qWFnnbIATDIBPcBCZ4Pz 0Qv/DeGj6Cp2xLKtyTE5M7klT8kR/foKhmfTE+zRd1BqKpNqUZzAfOqerVjfrmZguayb 1CN0wrQneG3+trq0R3mM9YZ+hHN4rzgJywOcNnlIKgYwxksGzRA/7WqmWYAEgxNe3Kh0 YJBg== MIME-Version: 1.0 X-Received: by 10.202.94.197 with SMTP id s188mr12129059oib.94.1424813418844; Tue, 24 Feb 2015 13:30:18 -0800 (PST) Received: by 10.202.225.135 with HTTP; Tue, 24 Feb 2015 13:30:18 -0800 (PST) In-Reply-To: References: Date: Wed, 25 Feb 2015 10:30:18 +1300 Message-ID: From: Martin Thomson To: Elio Damaggio Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Benjamin Bangert , "webpush@ietf.org" 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: Tue, 24 Feb 2015 21:30:22 -0000 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 f= or users of a push aggregation system are the following: > > 1. Push aggregation have to be regularly synched with other data sto= res. > 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 expe= rience forcing explicit management of the topics (creation and deletion) ha= mpers 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) ha= ve a similar systems. Reference: https://msdn.microsoft.com/en-us/library/d= n530749.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 a= nd other stores, it is usually preferable for both the users and the implem= enter 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 t= he 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 serve= rs, it follows that a push endpoint, that is independent of a specific topi= c and that takes a target topic (or Boolean expression on topics), is proba= bly better suited than a topic-specific push URL. > > Elio > > -----Original Message----- > From: Webpush [mailto:webpush-bounces@ietf.org] On Behalf Of Martin Thoms= on > 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 wro= te: >> 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 l= ike 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-exist= ing relationship with (and therefore federate authorization). The disadvan= tage 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 id= entified 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