From nobody Thu Sep 11 12:03:06 2014 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 7EEF41A0020 for ; Thu, 11 Sep 2014 12:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQlxjj9RCkwY for ; Thu, 11 Sep 2014 12:03:00 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B17401A0045 for ; Thu, 11 Sep 2014 12:02:57 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id mc6so8654540lab.31 for ; Thu, 11 Sep 2014 12:02:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=gGyeDFYyuax7m32KBMJn+tfEStw6Y5NrpFIorvjtJ0w=; b=vc3K/yBH9ZFLU3lSou/IGz3y8wMcp1MBKv8UhIi0a2aZn1qUJvPRDy3Cd71U4P/aMx e8irce7eMpqV9cG4hLfaEfIJzXYuYx48EhnCZt6RBIVI5RdKjoQcH+nxBYHSe633fTpA by6rRrfoUND4pdQN4HMTyb0xdJNj7h2U8kU7Q1Ez8/AyY+K1emf+NqEkWMfL3hueyOk1 TxdoDag8eIwYvZz3yC0V0RHU0Lim1OTaWQ1tuIr6eB7x/b1AghnP562z72MHwVqKzXPI fOWnz6MNBjt5N0k7Cs7re3M9rlr3Bs9YWjH8QlaeHxVcybpmE0TSTa3wEnA6AZTm6BfM lp6A== MIME-Version: 1.0 X-Received: by 10.112.201.133 with SMTP id ka5mr3229844lbc.61.1410462175721; Thu, 11 Sep 2014 12:02:55 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Thu, 11 Sep 2014 12:02:55 -0700 (PDT) Date: Thu, 11 Sep 2014 12:02:55 -0700 Message-ID: From: Martin Thomson To: webpush@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/Dg_HMfzRbmwcexbjKIOPajqy-_o Subject: [Webpush] Requesting agenda time in Honolulu 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, 11 Sep 2014 19:03:04 -0000 The next IETF meeting is coming, and after talking with our area director, it seems likely that we'll have a charter approved by then. Do you think we will need agenda time at this meeting? I think that it would be good to go over the issues that were raised, and it certainly helps with momentum. On the other hand, I think that it would be reasonable to say that we need more discussion on this mailing list before scheduling some (expensive) face-to-face time. What are people's preferences? (p.s., I'm not chair, nor am I likely to be one, but someone has to ask.) From nobody Sat Sep 13 17:46:04 2014 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 202A91A0154 for ; Sat, 13 Sep 2014 17:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1Sh2kEkeEv5 for ; Sat, 13 Sep 2014 17:46:00 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62FB01A014D for ; Sat, 13 Sep 2014 17:46:00 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id l4so2710238lbv.8 for ; Sat, 13 Sep 2014 17:45:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZNZq9Tgb/eBA7zCg6CrwnGvykqKBoekVVJdwfaHeJP8=; b=o1KE9QQnpCXG2E1PaRQERaM9x6mYyoqpHAR9jW3Bhy6LUM6aZG5fJGkBTNUtSgLA9H UosJxPHjroPK0qlNWo8kGY+A9tMFeM9KCZk1+C91htkjfRXqR5mYotD83IDQgHkJp1lf JJcnKxYzFZOQarv0J4nOIdo1FD2jBjOj8hHAaL8OIPCnUzaywSO4VDfIeOoCSVayozgU FjExV0O9XXseCPxx6OVF+DF7Q8GyuJJCp0ExERWKyDNRw9huP7I/QGIKtI2nxBQU32Nt fAkPXY6e4ZfMwojZes5cAuix4oywwvbP1QcdfJrCZ9qJTjEb7XDTkkO2w2V/Oy48V+nW JGfg== MIME-Version: 1.0 X-Received: by 10.152.21.168 with SMTP id w8mr13974364lae.59.1410655558574; Sat, 13 Sep 2014 17:45:58 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Sat, 13 Sep 2014 17:45:58 -0700 (PDT) In-Reply-To: References: Date: Sat, 13 Sep 2014 17:45:58 -0700 Message-ID: From: Martin Thomson To: Miguel Garcia Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/_2pvLmeeQyppchc_FoB_wW3dqHA Cc: webpush@ietf.org Subject: Re: [Webpush] Requesting agenda time in Honolulu 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: Sun, 14 Sep 2014 00:46:02 -0000 On 13 September 2014 12:55, Miguel Garcia wrote: > Do you know what's the status on creating the WG? Any ideas on who might be > the chair? Here's the status: http://datatracker.ietf.org/doc/charter-ietf-webpush/history/ The last item currently says: Placed on agenda for telechat - 2014-09-18 I think that means that the IESG will discuss and approve (or disapprove) the creation of the working group then. That may be conditional, I'm not sure. From nobody Mon Sep 15 13:29:34 2014 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 515301A00AB for ; Sat, 13 Sep 2014 12:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.03 X-Spam-Level: X-Spam-Status: No, score=-3.03 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, RP_MATCHES_RCVD=-1.652, 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 sdNu2o47fycq for ; Sat, 13 Sep 2014 12:56:02 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF2481A0097 for ; Sat, 13 Sep 2014 12:56:02 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id tr6so2731950ieb.17 for ; Sat, 13 Sep 2014 12:56:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xUFfOAsWAW0mtYLjsdr6Jyi+UgBl8kT0O35aA4HNPOM=; b=NKo0q1T3EBvdOKnkxk/WmY4Bv2O4AHO56o9ZBXVBaqpoyk74Wji9gJEaPs/U5HtlJS ml6Ws093/9Avj84SKIkRvKzdVpACJtwW7UIdj8NycaeRaMJgTxf6YMsTvcx9Or5yoXAJ O7ba70LE8HnGik0lQBnQOgFi3Pl8jbrxEa2JjQ4sGWAyfX+ylsJXuV3F475d1ZiAddU4 1qVQ+q+mVLJJH9x98xbZBaQG66eITl1a9IgfHt2Q6HDMVLWKMZihuEO5cv7WHPoI8oKm 4UUrrvDjlXuffANxWwxsni0vk7jJ85usbIWtwZtyaAsSH3/qlEmP6w5UaV7pfjH5/yZG kTmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=xUFfOAsWAW0mtYLjsdr6Jyi+UgBl8kT0O35aA4HNPOM=; b=hge5TKq9Mai6J/Tr3YCIayD2HbMpSbJdHmQjFVXsTotmBZ09afUYHd8O225Rbu9NL1 oC/WXrUonom0MjyEp+/ZniOmb8SNiMmeAHl3CRZCrn2vRuF1Gzsg7F+qfbU7nh2fT05s 8+Hjc1GTMQxuVCGvS6zMto5dXrZUlWvqW+wBQbk6R2b62ULtKbtxV/aZpw/5Z0UDwbMj XW0SJ4LSqnBdskMhZUR7K02TqKTWwG7ko17n9bAutYUYUcK//MD7vZprrWKA2nNYnJXm f4zYYPqzwwXk2fULUqmeZyYG/6Lm0VGQMIb2OUZtZpMEuDGlyne8fDcEb+UScb1Jqyfh 3CXA== X-Gm-Message-State: ALoCoQm0EaAtyfZ8c+BtM48Nzh1dYyRhBvB+29u4iHPmeeKvL/aiF+PPy7nX7uqpCB4eLXuIgMCJ X-Received: by 10.50.143.65 with SMTP id sc1mr11468606igb.19.1410638161935; Sat, 13 Sep 2014 12:56:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.30.200 with HTTP; Sat, 13 Sep 2014 12:55:41 -0700 (PDT) In-Reply-To: References: From: Miguel Garcia Date: Sat, 13 Sep 2014 20:55:41 +0100 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1135fdaa8cbc080502f7ca64 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/FapnOUzJa4_b7lMZqGcs8omaRs8 X-Mailman-Approved-At: Mon, 15 Sep 2014 13:29:33 -0700 Cc: webpush@ietf.org Subject: Re: [Webpush] Requesting agenda time in Honolulu 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, 13 Sep 2014 19:56:04 -0000 --001a1135fdaa8cbc080502f7ca64 Content-Type: text/plain; charset=UTF-8 I think we need to start the discussion on the mailing list and see much we agree or disagree before scheduling face time. Do you know what's the status on creating the WG? Any ideas on who might be the chair? Thanks Miguel On Thu, Sep 11, 2014 at 8:02 PM, Martin Thomson wrote: > The next IETF meeting is coming, and after talking with our area > director, it seems likely that we'll have a charter approved by then. > > Do you think we will need agenda time at this meeting? I think that > it would be good to go over the issues that were raised, and it > certainly helps with momentum. On the other hand, I think that it > would be reasonable to say that we need more discussion on this > mailing list before scheduling some (expensive) face-to-face time. > > What are people's preferences? > > (p.s., I'm not chair, nor am I likely to be one, but someone has to ask.) > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > --001a1135fdaa8cbc080502f7ca64 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think we need to start the discussion on the mailing lis= t and see much we agree or disagree before scheduling face time.=C2=A0
=
Do you know what's the status on creating the WG? Any id= eas on who might be the chair?

Thanks
Miguel=C2=A0


On Thu, Sep 11, 2014 at 8:02 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
The next IETF meeting is coming, and after talking with our a= rea
director, it seems likely that we'll have a charter approved by then.
Do you think we will need agenda time at this meeting?=C2=A0 I think that it would be good to go over the issues that were raised, and it
certainly helps with momentum.=C2=A0 On the other hand, I think that it
would be reasonable to say that we need more discussion on this
mailing list before scheduling some (expensive) face-to-face time.

What are people's preferences?

(p.s., I'm not chair, nor am I likely to be one, but someone has to ask= .)

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

--001a1135fdaa8cbc080502f7ca64-- From nobody Wed Sep 17 08:28:16 2014 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 5D7991A0347 for ; Wed, 17 Sep 2014 08:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 wRab4lnZw_Nw for ; Wed, 17 Sep 2014 08:28:13 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC58C1A0205 for ; Wed, 17 Sep 2014 08:28:12 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by gateway2.nyi.internal (Postfix) with ESMTP id EED5820AF0 for ; Wed, 17 Sep 2014 11:28:10 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 17 Sep 2014 11:28:10 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:cc:message-id:references:in-reply-to :mime-version:content-type:content-transfer-encoding; s=mesmtp; bh=oR1WJgD2Bf6aeVht2bL1u41iQi4=; b=LFW61NthNWcQgeTf0A8xC/Mngq6o XurBjR3/imQ8iUrts9ZqERH7gUBPnBdX7Yqac4wQ7yJYF5s5ePJXkMp5G0YtD7qV BJINYt7AriUYvbMkXIBktlnvG/2/1OFgcSDMc2NdevYvprOGz6xI3KM9HYBm9lmj ffqD0/v7gjLUvc8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:cc:message-id :references:in-reply-to:mime-version:content-type :content-transfer-encoding; s=smtpout; bh=oR1WJgD2Bf6aeVht2bL1u4 1iQi4=; b=ECmknJDa1/8YiaXoQyDhMLA0oOXGcViKi2wDr1iLBBbGKbiF9sznxP ppOvqe9KcOOtXpsOs3gwFNigZR5/70gMB044YMvqObOo3EQSv4s4/1FkAwuyY8Ld 2pOG3+/ObW1amWQSudOdiw5EcFo98IkD3iM3hjHluiCTyX5klxTQs= X-Sasl-enc: n0VY+V4XBkmVbZzcbkIa65S+5vOeflHMW+s820h2jNhG 1410967690 Received: from [10.21.151.39] (unknown [128.107.239.234]) by mail.messagingengine.com (Postfix) with ESMTPA id A48B36801B2; Wed, 17 Sep 2014 11:28:07 -0400 (EDT) User-Agent: Microsoft-MacOutlook/14.4.3.140616 Date: Wed, 17 Sep 2014 08:28:01 -0700 From: Alissa Cooper To: Stephen Farrell , The IESG Message-ID: Thread-Topic: Stephen Farrell's No Objection on charter-ietf-webpush-00-00: (with COMMENT) References: <20140917145417.2309.43465.idtracker@ietfa.amsl.com> In-Reply-To: <20140917145417.2309.43465.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/w5PCANR5aL_d0c58slDqNF5hkwQ Cc: webpush@ietf.org Subject: Re: [Webpush] Stephen Farrell's No Objection on charter-ietf-webpush-00-00: (with COMMENT) X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 15:28:15 -0000 Adding webpush@ietf.org since I failed to list it as a recipient in the datatracker until just now. Alissa On 9/17/14, 7:54 AM, "Stephen Farrell" wrote: >Stephen Farrell has entered the following ballot position for >charter-ietf-webpush-00-00: No Objection > >When responding, please keep the subject line intact and reply to all >email addresses included in the To and CC lines. (Feel free to cut this >introductory paragraph, however.) > > > >The document, along with other ballot positions, can be found here: >http://datatracker.ietf.org/doc/charter-ietf-webpush/ > > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > > >I've no objection to this going for external review. > >I am concerned however about the security goals here and >would like to be clear about those before this is chartered. >(If they remain unclear then I figure that'd be worth a BLOCK, >but I'm fine if this is sorted before, during or after external >review so long as it is sorted.) Apologies if some of the >deployed proprietary schemes already address all of this, >I'm not that familiar with 'em. > >I think there are 3 security things I'd like to be clear about: > >First, I think it needs to be possible for pushed data to be >encrypted and authenticated at all times. I'm not sure if all >pushed data MUST or SHOULD be so protected but that >seems like something the WG would need to discuss. And >there are issues related to authorization (by the device >owner) here too. Given that that might not be so easy I >think it'd need to be explicit in the charter or am I missing >something? > >Second, I think that there's a need for some analysis about >any differences in security between pushed and other data >for specific applications. (The security needs to be >commensurate I figure or else we're doing the user a >disservice telling them about application security properties.) >I'm not sure how that'd be reflected in the charter but I'd >like to chat about it. For example, my phone gives me a >push/sync option for email and I don't know if that provides >the same or different security compared to IMAP. I think >the same issues arise here. > >Third, the charter says "This protocol will include the ability >to push the same message to multiple devices (broadcast)." >I have no clue how that can be done with the same security >features as a secured individual push. Can you explain a >bit? Arm-waving is fine, but I'd like to know that the broadcast >requirement is not going to mean that in practice all pushed >data ends as cleartext. Note: I am not asking if a secured >broadcast is needed here, I'm asking if the highly likely >desire for an insecure broadcast will result in insecure >everything. > > From nobody Wed Sep 17 11:12:15 2014 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 655931A06B5 for ; Wed, 17 Sep 2014 11:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 StiZCxz1LhcI for ; Wed, 17 Sep 2014 11:12:05 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11E421A0842 for ; Wed, 17 Sep 2014 11:12:05 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by gateway2.nyi.internal (Postfix) with ESMTP id 404432109D for ; Wed, 17 Sep 2014 14:12:04 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Wed, 17 Sep 2014 14:12:04 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:cc:message-id:references:in-reply-to :mime-version:content-type:content-transfer-encoding; s=mesmtp; bh=LBAb7GwkD9ajNbZeGhzBAKFsHFA=; b=oplfCYxasKCO+0JQUcgwGrHHVKCX UdVNVPPFAvnSZRCedgrmmhbkzLPY+IRJ2zPTmb6itjqHSri7qXVAila9ClNsX6G4 b18fXlLtMVs6IMCwSBJuoMAXUmQfdMZmaA0qiVG61PvcERm2xsBLRGhn+TobiG0f UZmqZU3WjPX3OgA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:cc:message-id :references:in-reply-to:mime-version:content-type :content-transfer-encoding; s=smtpout; bh=LBAb7GwkD9ajNbZeGhzBAK FsHFA=; b=i01ENTQUkJt7kHywmOuAd17yo05dMuKSs1wfurMS/VfxLrv5NwaKoC 7nwBecW5fEjz1JbnOUXCd6qpVbmRfrHEVnCfm52HwAVOw9/Vg8R73oL8RfrQZJcA K+n84+tDCnDeqaTpc9W1erM+5HyZV7uv23cylASZKoDrdkUwtgKLo= X-Sasl-enc: oH4M51qaxddsQBcMVL0tnn0NN/nYjDkzSpudv2vf45zD 1410977523 Received: from [171.68.18.45] (unknown [171.68.18.45]) by mail.messagingengine.com (Postfix) with ESMTPA id D365BC0091B; Wed, 17 Sep 2014 14:12:01 -0400 (EDT) User-Agent: Microsoft-MacOutlook/14.4.3.140616 Date: Wed, 17 Sep 2014 11:11:57 -0700 From: Alissa Cooper To: Martin Thomson , Miguel Garcia Message-ID: Thread-Topic: [Webpush] Requesting agenda time in Honolulu References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/BY5jE1lKY0rJ4IzsnzavC2Bgc3k Cc: webpush@ietf.org Subject: Re: [Webpush] Requesting agenda time in Honolulu X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 18:12:08 -0000 On 9/13/14, 5:45 PM, "Martin Thomson" wrote: >On 13 September 2014 12:55, Miguel Garcia wrote: >> Do you know what's the status on creating the WG? Any ideas on who >>might be >> the chair? > >Here's the status: >http://datatracker.ietf.org/doc/charter-ietf-webpush/history/ > >The last item currently says: Placed on agenda for telechat - 2014-09-18 > >I think that means that the IESG will discuss and approve (or >disapprove) the creation of the working group then. That may be >conditional, I'm not sure. The question before the IESG on tomorrow=E2=80=99s telechat is whether the charte= r is ready for =E2=80=9Cexternal review=E2=80=9D =E2=80=94 by the IETF community and other SDOs= , as appropriate (the pending charter will be sent to a mailing list where, e.g., W3C folks can take a look as well). If it gets approved for external review tomorrow, the external review period will last for two weeks at which point the IESG will have another decision point about whether to approve the WG for chartering. Hopefully you are all seeing the comments being generated by the current internal review. I=E2=80=99m working on finding chairs with an aim to be ready to announce them at the same time as charter approval. Alissa > >_______________________________________________ >Webpush mailing list >Webpush@ietf.org >https://www.ietf.org/mailman/listinfo/webpush From nobody Wed Sep 17 23:36:09 2014 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 7FF7A1A7023 for ; Wed, 17 Sep 2014 23:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PonJH9UxE2MZ for ; Wed, 17 Sep 2014 23:36:07 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87F751A7020 for ; Wed, 17 Sep 2014 23:36:07 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id ar1so543142iec.7 for ; Wed, 17 Sep 2014 23:36:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=/fM85E3aCASkqs2NLrZeEi1/8FQ+hhnTZmCruQDcsOM=; b=YR5vSg+Q8HAHGqc5Js+gPwOZFnEjAA7PicOBSGWLRUxNBBJeyjNn8TeOJGrYOeqH/k /j5HlhHWi5Ya7PKbvdyrTS9l7caYldVlfuh3NfSMeLCKWG4MN2CT7BY7jJRd8g939cS5 hRHDM/L+O4WhhyaMo2welCZt3dlvNV40bJ1ZXYwTQuiLJUEGxhHJ5qt0Cbq6f+1yQPT1 8nAbtMngWmTAt/6KLKfbse4C4Bm2XJOnBEGulmL9xbm7dnAJJnHJNsEvyWDXDiM2eVSZ tMpPySHAwUhqVv0+7UFeuTKmKDzfgWjdI+v8VrReivYoSsWQ0tLsHhqu3mQ3tODyqwtF RTGw== MIME-Version: 1.0 X-Received: by 10.43.111.6 with SMTP id em6mr10644000icc.21.1411022166726; Wed, 17 Sep 2014 23:36:06 -0700 (PDT) Received: by 10.50.39.73 with HTTP; Wed, 17 Sep 2014 23:36:06 -0700 (PDT) Date: Thu, 18 Sep 2014 15:36:06 +0900 Message-ID: From: Daniel Park To: webpush@ietf.org Content-Type: multipart/alternative; boundary=bcaec517186504a25d05035133e1 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/Lh5-0cy4DYRGPCAGYjDpOsIKeCk Subject: [Webpush] any drafts available ? 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, 18 Sep 2014 06:36:08 -0000 --bcaec517186504a25d05035133e1 Content-Type: text/plain; charset=ISO-8859-1 Sorry for aksing too late, but if any drafts are available to make sense this work, that might be very helpful for me to catch up this. Thanks in advance. Daniel, -- Soohong Daniel Park, Ph.D. Samsung Electronics, SW R&D Center --bcaec517186504a25d05035133e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Sorry for aksing too late, but if any drafts are avai= lable to make sense this work, that might be very helpful for me to catch u= p this.

Thanks in advance.

<= div>Daniel,
--

Soohong Daniel Park, Ph.D.
Samsung Electronics= , SW R&D Center


--bcaec517186504a25d05035133e1-- From nobody Thu Sep 18 08:23:27 2014 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 BCEBC1A8788; Thu, 18 Sep 2014 05:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 fUA6XJDgIv10; Thu, 18 Sep 2014 05:48:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A68361A00F5; Thu, 18 Sep 2014 05:47:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Adrian Farrel" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140918124759.20671.83079.idtracker@ietfa.amsl.com> Date: Thu, 18 Sep 2014 05:47:59 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/y_5kltiD5u9GSOONio_gEE_tOLQ X-Mailman-Approved-At: Thu, 18 Sep 2014 08:23:24 -0700 Cc: webpush@ietf.org Subject: [Webpush] Adrian Farrel's No Objection on charter-ietf-webpush-00-00: (with COMMENT) X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 18 Sep 2014 12:48:02 -0000 Adrian Farrel has entered the following ballot position for charter-ietf-webpush-00-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-webpush/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I think this is a fine thing to be working on and have no objection to sending this charter for external review. Building on what Stephen says, I would like the WG to explicitly consider the privacy aspects of consolidating push events since that redirects the 1:1 relationship between pusher and pushee to allow the consolidating service to be aware of the relationships and services that exist. From nobody Thu Sep 18 12:31:09 2014 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 E26B81A8874 for ; Thu, 18 Sep 2014 12:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_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 EZ5EVDzKVNDu for ; Thu, 18 Sep 2014 12:31:06 -0700 (PDT) Received: from gator4135.hostgator.com (gator4135.hostgator.com [192.185.4.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F4A91A04AF for ; Thu, 18 Sep 2014 12:31:05 -0700 (PDT) Received: from [173.180.59.121] (port=64961 helo=[192.168.1.76]) by gator4135.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XUhQ0-0003JV-IV; Thu, 18 Sep 2014 14:31:04 -0500 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Shida Schubert In-Reply-To: Date: Thu, 18 Sep 2014 12:30:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <49A9FFBC-F89F-4277-810B-BE55B16B92E0@ntt-at.com> References: To: Daniel Park X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator4135.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source-IP: 173.180.59.121 X-Exim-ID: 1XUhQ0-0003JV-IV X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.76]) [173.180.59.121]:64961 X-Source-Auth: shida@agnada.com X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/EtlfE4vHJQCMEmT-DaL9VZP7JpQ Cc: webpush@ietf.org Subject: Re: [Webpush] any drafts available ? 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, 18 Sep 2014 19:31:09 -0000 Below is the link to the draft presented at the last IETF which = commenced all the discussions here.=20 http://tools.ietf.org/html/draft-thomson-webpush-http2-00 Regards Shida On Sep 17, 2014, at 11:36 PM, Daniel Park wrote: > Sorry for aksing too late, but if any drafts are available to make = sense this work, that might be very helpful for me to catch up this. >=20 > Thanks in advance. >=20 > Daniel, > --=20 >=20 > Soohong Daniel Park, Ph.D. > Samsung Electronics, SW R&D Center >=20 >=20 > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush From nobody Fri Sep 19 07:57:23 2014 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 E618F1A01C6; Fri, 19 Sep 2014 07:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwzX-f1Md-wH; Fri, 19 Sep 2014 07:57:20 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94BFB1A016B; Fri, 19 Sep 2014 07:57:19 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id gi9so3299371lab.2 for ; Fri, 19 Sep 2014 07:57:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tPTe4WZ0s962ZhXgmSI6KEsucKTb9YhlrGnhPhupSqo=; b=WsDhwBmW+i17Z9XbCnxBtgpFZKvfighKyOFKzT8mV8s8NT73UpuDOdoYeKAVOH86fo wSyCWaI/tq1U0R+bzEmatZNz7aTDE1wqbQUyaH6MbMbDGWsgTU677I9wvBfaVN2dtk+K jlAovhHQ9E1IhV2R4vgZr6Wy0cDDBl0C2KFxmSeuxMWvK44M5hXEe/4OBuH02S0648w7 oCmoAXYyDVckvyHVgrQPZtAl28P6FqYdaM2eRI0y2w57IVW3t9l2j2/ynsgKkrSmwoAm iexmQ16/W71vRu7O5bfSuG1LnBxIxk7WHpVuKTa6meoJYTIgnSPfg9Wrulrtvm7eWJD/ reIA== MIME-Version: 1.0 X-Received: by 10.112.148.170 with SMTP id tt10mr7017743lbb.61.1411138637697; Fri, 19 Sep 2014 07:57:17 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Fri, 19 Sep 2014 07:57:17 -0700 (PDT) In-Reply-To: References: <20140917145417.2309.43465.idtracker@ietfa.amsl.com> Date: Fri, 19 Sep 2014 07:57:17 -0700 Message-ID: From: Martin Thomson To: Alissa Cooper Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/IZqVbN5zETfrhX2ryE6SlEKMMlg Cc: The IESG , webpush@ietf.org, Stephen Farrell Subject: Re: [Webpush] Stephen Farrell's No Objection on charter-ietf-webpush-00-00: (with COMMENT) 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, 19 Sep 2014 14:57:22 -0000 The subject of security in the context of push is something that I've sunk a fair amount of thinking into. That doesn't mean I've given up on it (I need to talk to Senor Barnes about whether using WebCrypto on something here might help...). I believe that the key facts that define the security architecture are: - An application uses web push to talk to itself. - The web push server carries an opaque payload. The key concern being that confidentiality and integrity are assured against the push server itself. The rest we protect with TLS in the usual fashion. I definitely think that we want this to be secured, but as it stands securing pushes is out of our hands. Applications, as they run in both the browser and some random server, both generate and consume the pushed data. The point is - at least from my perspective - to enable an entirely private protocol. In all senses of that word :) At best, I think that we want to do two things: 1. document the properties of the channel (as above) 2. describe a potential method for securing pushed data from the push server; that being one where key agreement occurs at the time that the device registers a push endpoint with the server For broadcast, the same basic model applies, noting of course that the set of discrete entities who hold the same key is likely a larger number than 2. That's obviously a very different situation from that perspective. All instances are the same application, and the information that is carried is necessarily the same. On 17 September 2014 08:28, Alissa Cooper wrote: > Adding webpush@ietf.org since I failed to list it as a recipient in the > datatracker until just now. > Alissa > > On 9/17/14, 7:54 AM, "Stephen Farrell" wrote: > >>Stephen Farrell has entered the following ballot position for >>charter-ietf-webpush-00-00: No Objection >> >>When responding, please keep the subject line intact and reply to all >>email addresses included in the To and CC lines. (Feel free to cut this >>introductory paragraph, however.) >> >> >> >>The document, along with other ballot positions, can be found here: >>http://datatracker.ietf.org/doc/charter-ietf-webpush/ >> >> >> >>---------------------------------------------------------------------- >>COMMENT: >>---------------------------------------------------------------------- >> >> >>I've no objection to this going for external review. >> >>I am concerned however about the security goals here and >>would like to be clear about those before this is chartered. >>(If they remain unclear then I figure that'd be worth a BLOCK, >>but I'm fine if this is sorted before, during or after external >>review so long as it is sorted.) Apologies if some of the >>deployed proprietary schemes already address all of this, >>I'm not that familiar with 'em. >> >>I think there are 3 security things I'd like to be clear about: >> >>First, I think it needs to be possible for pushed data to be >>encrypted and authenticated at all times. I'm not sure if all >>pushed data MUST or SHOULD be so protected but that >>seems like something the WG would need to discuss. And >>there are issues related to authorization (by the device >>owner) here too. Given that that might not be so easy I >>think it'd need to be explicit in the charter or am I missing >>something? >> >>Second, I think that there's a need for some analysis about >>any differences in security between pushed and other data >>for specific applications. (The security needs to be >>commensurate I figure or else we're doing the user a >>disservice telling them about application security properties.) >>I'm not sure how that'd be reflected in the charter but I'd >>like to chat about it. For example, my phone gives me a >>push/sync option for email and I don't know if that provides >>the same or different security compared to IMAP. I think >>the same issues arise here. >> >>Third, the charter says "This protocol will include the ability >>to push the same message to multiple devices (broadcast)." >>I have no clue how that can be done with the same security >>features as a secured individual push. Can you explain a >>bit? Arm-waving is fine, but I'd like to know that the broadcast >>requirement is not going to mean that in practice all pushed >>data ends as cleartext. Note: I am not asking if a secured >>broadcast is needed here, I'm asking if the highly likely >>desire for an insecure broadcast will result in insecure >>everything. >> >> > > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush From nobody Tue Sep 23 07:07:36 2014 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 7FE1A1A86ED for ; Tue, 23 Sep 2014 07:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSf44O2IT6sf for ; Tue, 23 Sep 2014 07:07:32 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 408111A86EF for ; Tue, 23 Sep 2014 07:07:20 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id ty20so8632557lab.7 for ; Tue, 23 Sep 2014 07:07:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=TDNOpBOr+RnxyDR44Nazypu/OxzJFXD5fMM9w1UmAY4=; b=ggXkjfBDqyktFZZBLjUBt4CxkuPmIXeO/R6Y4wX8X6RCZ4UggYgIUoxuXfMueQfMuI VnX9f5o+vec52U3zD8o+dpsoGj4yP9GTEeDPLBTxRLwWbQhFXbCOseWeocE0mLovY1tU UrlWDC8O5c5EiIDEI9AoSPL1fpDzUceg7be1QSdBrEkUIzKujf+i50K1T05EzfWtzylx aZ8G+XFsBpSyluheebbz/V1ZCqq+0WXsgfHoKb2XQhvouKeLQDiirL+myNF5ssDhUGNf gCLfTozh0spmOyPhLXGWc/2qQS8H8hzrNGnwHbCootWacH1pHLykFLNhPSSMuWgaJPRZ k0Ng== MIME-Version: 1.0 X-Received: by 10.152.116.44 with SMTP id jt12mr31556000lab.7.1411481238551; Tue, 23 Sep 2014 07:07:18 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Tue, 23 Sep 2014 07:07:18 -0700 (PDT) Date: Tue, 23 Sep 2014 07:07:18 -0700 Message-ID: From: Martin Thomson To: webpush@ietf.org, Alissa Cooper Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/fFJmdJXqlEl8XK5xs0Y6dymrlY8 Subject: [Webpush] Updated charter proposal 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, 23 Sep 2014 14:07:33 -0000 The IESG comments on the first charter were generally favorable, though there were a few questions and reservations. Here's what I'm going to propose as the updated charter. --- Many applications require continuous access to network communications so that real-time events - such as incoming calls or messages - can be conveyed ("pushed") to the user in a timely fashion. Uncoordinated use of the network by multiple applications can contribute to unnecessary use of the network on devices. For instance, maintaining sessions can dominate costs over the long term, since pushed events are relatively rare. This is particularly onerous for battery-powered devices, on which network communication contributes a significant proportion of power usage. Each independent session independently incurs overheads, causing unnecessary resource usage on devices. Several modern computing platforms provide a push notification service that consolidates application events, distributing those events to applications as they arrive. The single session avoids duplicated overhead costs on devices. This working group will develop a protocol that applications can use to request the delivery of data to a device using a consolidated push notification service. This protocol will include the ability to push the same message to multiple subscribed devices. The work may describe a protocol that allows a device to subscribe to a push service and receive pushed messages. This work will be done in collaboration with the W3C Webapps Working Group, who are developing a Web Push API for use in web applications (see ). --- Pete Resnick suggested we be honest and specifically call out HTTP as the basis of the protocol. I don't think that's appropriate here, since this isn't necessarily HTTP-based. And I say that even when the proposal I have on the table is HTTP-based. There were questions about the "exemplar protocol" statement, which in retrospect is completely understandable. I hope that the last sentence of paragraph 3 is clearer on this point. Stephen Farrell and Adrian Farrel both had concerns around security and privacy. I'm happy to include text if someone can avoid it being too much of a motherhood statement, which I don't think would be valuable. Particularly because a fair treatment of the assumed security architecture, problems arising from that, and the associated privacy implications is entirely achievable within the confines of a security considerations section. I personally don't believe that it's necessary to write security considerations into every charter; I'd prefer to think that we've won hearts and minds over to the need for good considerations such that this need is implicit. Maybe that's just an optimistic projection on my part. BTW, my recent realization is that hard requirements around security will be driven from the W3C webapps WG, not the IETF. From nobody Tue Sep 23 07:57:47 2014 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 E2A1C1A854B; Tue, 23 Sep 2014 07:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 uP-D_M_llkca; Tue, 23 Sep 2014 07:17:33 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id B85EB1A8033; Tue, 23 Sep 2014 07:17:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BE2BFBE75; Tue, 23 Sep 2014 15:17:31 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0iDXn1iAMwv; Tue, 23 Sep 2014 15:17:29 +0100 (IST) Received: from [109.125.29.200] (unknown [109.125.29.200]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BF175BE0F; Tue, 23 Sep 2014 15:17:28 +0100 (IST) Message-ID: <542180F3.2060902@cs.tcd.ie> Date: Tue, 23 Sep 2014 15:17:23 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Martin Thomson , Alissa Cooper References: <20140917145417.2309.43465.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/yitswJhc4ej_2mg7RBTofbsLHc4 X-Mailman-Approved-At: Tue, 23 Sep 2014 07:57:45 -0700 Cc: The IESG , webpush@ietf.org Subject: Re: [Webpush] Stephen Farrell's No Objection on charter-ietf-webpush-00-00: (with COMMENT) 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, 23 Sep 2014 14:17:35 -0000 Hi Martin, On 19/09/14 15:57, Martin Thomson wrote: > The subject of security in the context of push is something that I've > sunk a fair amount of thinking into. That doesn't mean I've given up > on it (I need to talk to Senor Barnes about whether using WebCrypto on > something here might help...). > > I believe that the key facts that define the security architecture are: > > - An application uses web push to talk to itself. You're assuming a we/JS client there right? If so that might be a good way to characterise this. So e.g. an IMAP MUA is out of scope? > - The web push server carries an opaque payload. Opaque to whom would be the question, but skip that and see below. > The key concern being that confidentiality and integrity are assured > against the push server itself. The rest we protect with TLS in the > usual fashion. > > I definitely think that we want this to be secured, but as it stands > securing pushes is out of our hands. Applications, as they run in > both the browser and some random server, both generate and consume the > pushed data. The point is - at least from my perspective - to enable > an entirely private protocol. In all senses of that word :) > > At best, I think that we want to do two things: > > 1. document the properties of the channel (as above) Certainly. I assume you mean the security properties there, so that'd include who has/shares what keys with whom, right? > > 2. describe a potential method for securing pushed data from the push > server; that being one where key agreement occurs at the time that the > device registers a push endpoint with the server Hmmm. I'm not getting how its ok for us to move from pretty well-defined security/privacy properties in the non-pushed case to un-defined dunno-what security properties in the push case. If that is what you're saying how is it ok? If that's not what you're saying then I'm missing something (which is fairly common:-) Can you also speak to Adrian's good point about the privacy and other aspects of consolidating things? > For broadcast, the same basic model applies, noting of course that the > set of discrete entities who hold the same key is likely a larger > number than 2. That's obviously a very different situation from that > perspective. All instances are the same application, and the > information that is carried is necessarily the same. Even more hmmm:-) All instances are the same application is very far from meaning that its ok for them all to share a single symmetric key. (And how you might do that is somewhat mysterious anyway, see also the DICE wg discussion on DTLS/multicast IP.) But, as I said, I'm fine that this go for external review and that this be discussed during that time. Cheers, S. > > > On 17 September 2014 08:28, Alissa Cooper wrote: >> Adding webpush@ietf.org since I failed to list it as a recipient in the >> datatracker until just now. >> Alissa >> >> On 9/17/14, 7:54 AM, "Stephen Farrell" wrote: >> >>> Stephen Farrell has entered the following ballot position for >>> charter-ietf-webpush-00-00: No Objection >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> >>> The document, along with other ballot positions, can be found here: >>> http://datatracker.ietf.org/doc/charter-ietf-webpush/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> >>> I've no objection to this going for external review. >>> >>> I am concerned however about the security goals here and >>> would like to be clear about those before this is chartered. >>> (If they remain unclear then I figure that'd be worth a BLOCK, >>> but I'm fine if this is sorted before, during or after external >>> review so long as it is sorted.) Apologies if some of the >>> deployed proprietary schemes already address all of this, >>> I'm not that familiar with 'em. >>> >>> I think there are 3 security things I'd like to be clear about: >>> >>> First, I think it needs to be possible for pushed data to be >>> encrypted and authenticated at all times. I'm not sure if all >>> pushed data MUST or SHOULD be so protected but that >>> seems like something the WG would need to discuss. And >>> there are issues related to authorization (by the device >>> owner) here too. Given that that might not be so easy I >>> think it'd need to be explicit in the charter or am I missing >>> something? >>> >>> Second, I think that there's a need for some analysis about >>> any differences in security between pushed and other data >>> for specific applications. (The security needs to be >>> commensurate I figure or else we're doing the user a >>> disservice telling them about application security properties.) >>> I'm not sure how that'd be reflected in the charter but I'd >>> like to chat about it. For example, my phone gives me a >>> push/sync option for email and I don't know if that provides >>> the same or different security compared to IMAP. I think >>> the same issues arise here. >>> >>> Third, the charter says "This protocol will include the ability >>> to push the same message to multiple devices (broadcast)." >>> I have no clue how that can be done with the same security >>> features as a secured individual push. Can you explain a >>> bit? Arm-waving is fine, but I'd like to know that the broadcast >>> requirement is not going to mean that in practice all pushed >>> data ends as cleartext. Note: I am not asking if a secured >>> broadcast is needed here, I'm asking if the highly likely >>> desire for an insecure broadcast will result in insecure >>> everything. >>> >>> >> >> >> _______________________________________________ >> Webpush mailing list >> Webpush@ietf.org >> https://www.ietf.org/mailman/listinfo/webpush > From nobody Tue Sep 23 08:18:58 2014 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 4612E1A8033; Tue, 23 Sep 2014 08:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id maw3kZSe0Mrf; Tue, 23 Sep 2014 08:18:36 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2D841A1AD4; Tue, 23 Sep 2014 08:18:35 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id q1so8938300lam.31 for ; Tue, 23 Sep 2014 08:18:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XcweJS2sdxSW0lHc24RPSutd7eLYNDxQgUSNDCZRVEc=; b=pR1FA3RBReNdvS8JMXstChbuVHbZkGmE1sG/SJmWms/J5uMMlOKBBHSz+YVvclzbIU 27ofhFHGXbQjrqFkJQbEs+pdblOscFD+47bRM0cNTpGBEecoQL2PPiqoNtA01jQ2fjSM FGtUSeYO8B3Gk3lZtTf18kxx7X6PqqWNQPtWyO+sJbbnmDqIJgsatUB52tz4+XVydKjv J4w1mec5ANB5F0rvT1wpmXJ5EMbPTGH74fR+G4ExrZd4RKTS/Nranr44eQH6rzB9cNgo zvVDnJtRdPNBgmfxSK6hEwK2jhEFbMS9LyC0QcxGQhJKGbv69NywYmE5kvHrkivPZR5B Qang== MIME-Version: 1.0 X-Received: by 10.112.219.71 with SMTP id pm7mr246884lbc.3.1411485514043; Tue, 23 Sep 2014 08:18:34 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Tue, 23 Sep 2014 08:18:33 -0700 (PDT) In-Reply-To: <542180F3.2060902@cs.tcd.ie> References: <20140917145417.2309.43465.idtracker@ietfa.amsl.com> <542180F3.2060902@cs.tcd.ie> Date: Tue, 23 Sep 2014 08:18:33 -0700 Message-ID: From: Martin Thomson To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/LUX4wv59KzWUpzI2OgiBmhi2JOs Cc: Alissa Cooper , The IESG , webpush@ietf.org Subject: Re: [Webpush] Stephen Farrell's No Objection on charter-ietf-webpush-00-00: (with COMMENT) 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, 23 Sep 2014 15:18:43 -0000 On 23 September 2014 07:17, Stephen Farrell wrote: > You're assuming a we/JS client there right? If so that might be a good > way to characterise this. So e.g. an IMAP MUA is out of scope? Absolutely not. Obviously that is the use case required by the Web API. The protocol however doesn't need to presume any dependency on that, in much the same way that WebRTC has escaped from the confines of the browser. On the rest, I actually agree. I didn't find that answer particularly satisfactory either. It's kinda that status quo that I lived with when I worked with this at Skype. There we used that "talking to yourself" thing to avoid the need for anything better. I think that we can improve on that in the web context. I've some ideas here that I need to check for viability, particularly since they require certain sacrifices. Expect a more satisfactory write up in a day or so. From nobody Tue Sep 23 08:40:01 2014 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 8AD8A1A8720 for ; Tue, 23 Sep 2014 08:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 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, RP_MATCHES_RCVD=-0.786, 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 bee2EEOI2GYo for ; Tue, 23 Sep 2014 08:39:55 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBF201A86FA for ; Tue, 23 Sep 2014 08:39:54 -0700 (PDT) Received: by mail-qg0-f53.google.com with SMTP id e89so4137798qgf.40 for ; Tue, 23 Sep 2014 08:39:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=DLK25xf0SrD1lBOXdMmevIzv5S4mAm1uXzIxU/GO+m8=; b=Da8VZXykV9pQlQXw+pyJ4mOab2bKNVu/k9/VfrD/h6q/QsNmCEuxgJc7YBdzRXND1o jbkl52hfAFi6Iq2x71szeZVx3Kl8QR3o30cHAKDsIbbWhV/9hbsV3KDVWkpiqEIageVH 515BrDH3e+BcQhNBFbqRIRSRLzoLJajoTe68tyuuTbplpjCNQWYPJTI+UGR8JWg+7BL5 nMgcoLze8j0w8YsIuoCLIxR1cSEDRL0l0GVBnFMNQcHKBZhk8QXgKdCBDNmbA6mZg49D WN6xCmya4sGKV2L9iab4IgAg9xXnoDnyffIaCOPjAWIggynuij961m7n68r+fcRonOBF SYJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=DLK25xf0SrD1lBOXdMmevIzv5S4mAm1uXzIxU/GO+m8=; b=NjZEhtnx6oVMmrUsFzcrnSWsMaKxPeUfgd0edwLSPBTbUUf+ryBtYZSvvWOEoEoVMF BO4Wdc5GwS8ol8lkwRetmP+WltZLJmDrztXk1Amfi/CcgUbuvKqkCqi70fJ3BIbAmOnv EVHqsyjWrhBcuZAN4NJ6fHNllk2bYntOPKIaLhLu1h7iE6fsk4//9LdfkDQwmq6y9uJK L6Thrz3/wczfDm/RNxU3531Min1raFjVoKbO4X3UCO6hM7uR39Ce3PHIVG/NGPaLHWb3 3tyrPfDsY0ZqT2mKis/p3MVBZq3F+yHmwdV8/EP1E+ae0gFYWAaRHvHLhFVYYtQx3U8E 84dQ== X-Gm-Message-State: ALoCoQlABMn7vjhQCdMqUHLZfBYjfQkJzDRVVmM4tOPXhah8anI6w9VorUbPAyTOGq54sEx/uifj X-Received: by 10.140.96.165 with SMTP id k34mr651176qge.78.1411486794079; Tue, 23 Sep 2014 08:39:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.94.175 with HTTP; Tue, 23 Sep 2014 08:39:33 -0700 (PDT) In-Reply-To: References: From: nero Date: Tue, 23 Sep 2014 08:39:33 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113a49ecf7c2ba0503bd60de Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/UGLyzcWSYFgi5a6vfa4MojgdQKQ Cc: Alissa Cooper , webpush@ietf.org Subject: Re: [Webpush] Updated charter proposal 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, 23 Sep 2014 15:39:57 -0000 --001a113a49ecf7c2ba0503bd60de Content-Type: text/plain; charset=UTF-8 a few thoughts: 1- I think security and privacy concerns should be addressed (as a matter of fact there is strong security and privacy around the GCM model). 2- "real time calls", it needs to be understood that there are numerous carrier networks across the globe that are badly configured. Messages via webpush are asynchronous by nature and might not reach devices in a specified timeframe even if said devices are able to connect to websites 3- Can you clarify what you mean when you say HTTP should be the basis of the protocol? Is it from the sender to the receiving Push Service? Or also from the receiving Push Service to the connected endpoint (the ultimate receiver of the message)? On Tue, Sep 23, 2014 at 7:07 AM, Martin Thomson wrote: > The IESG comments on the first charter were generally favorable, > though there were a few questions and reservations. Here's what I'm > going to propose as the updated charter. > > --- > > Many applications require continuous access to network communications so > that real-time events - such as incoming calls or messages - can be > conveyed > ("pushed") to the user in a timely fashion. Uncoordinated use of the > network by > multiple applications can contribute to unnecessary use of the network on > devices. For instance, maintaining sessions can dominate costs over the > long > term, since pushed events are relatively rare. This is particularly > onerous for > battery-powered devices, on which network communication contributes a > significant proportion of power usage. Each independent session > independently > incurs overheads, causing unnecessary resource usage on devices. > > Several modern computing platforms provide a push notification service that > consolidates application events, distributing those events to applications > as > they arrive. The single session avoids duplicated overhead costs on > devices. > > This working group will develop a protocol that applications can use to > request > the delivery of data to a device using a consolidated push notification > service. > This protocol will include the ability to push the same message to multiple > subscribed devices. The work may describe a protocol that allows a device > to > subscribe to a push service and receive pushed messages. > > This work will be done in collaboration with the W3C Webapps Working > Group, who > are developing a Web Push API for use in web applications (see > ). > > --- > > Pete Resnick suggested we be honest and specifically call out HTTP as > the basis of the protocol. I don't think that's appropriate here, > since this isn't necessarily HTTP-based. And I say that even when the > proposal I have on the table is HTTP-based. > > There were questions about the "exemplar protocol" statement, which in > retrospect is completely understandable. I hope that the last > sentence of paragraph 3 is clearer on this point. > > Stephen Farrell and Adrian Farrel both had concerns around security > and privacy. I'm happy to include text if someone can avoid it being > too much of a motherhood statement, which I don't think would be > valuable. Particularly because a fair treatment of the assumed > security architecture, problems arising from that, and the associated > privacy implications is entirely achievable within the confines of a > security considerations section. I personally don't believe that it's > necessary to write security considerations into every charter; I'd > prefer to think that we've won hearts and minds over to the need for > good considerations such that this need is implicit. Maybe that's just > an optimistic projection on my part. > > BTW, my recent realization is that hard requirements around security > will be driven from the W3C webapps WG, not the IETF. > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > -- Francesco Nerieri | Eng. Manager - Mobile | nero@google.com | 650.283.8890 --001a113a49ecf7c2ba0503bd60de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
a few thoughts:
1- I think security and privacy = concerns should be addressed (as a matter of fact there is strong security = and privacy around the GCM model).
2- =C2=A0"real time calls"= , it needs to be understood that there are numerous carrier networks across= the globe that are badly configured. Messages via webpush are asynchronous= by nature and might not reach devices in a specified timeframe even if sai= d devices are able to connect to websites
3- Can you clarify what= you mean when you say HTTP should be the basis of the protocol? Is it from= the sender to the receiving Push Service? Or also from the receiving Push = Service to the connected endpoint (the ultimate receiver of the message)?

On Tue,= Sep 23, 2014 at 7:07 AM, Martin Thomson <martin.thomson@gmail.com<= /a>> wrote:
The IESG comments o= n the first charter were generally favorable,
though there were a few questions and reservations.=C2=A0 Here's what I= 'm
going to propose as the updated charter.

---

Many applications require continuous access to network communications so that real-time events - such as incoming calls or messages - can be conveye= d
("pushed") to the user in a timely fashion. Uncoordinated use of = the network by
multiple applications can contribute to unnecessary use of the network on devices.=C2=A0 For instance, maintaining sessions can dominate costs over t= he long
term, since pushed events are relatively rare.=C2=A0 This is particularly o= nerous for
battery-powered devices, on which network communication contributes a
significant proportion of power usage.=C2=A0 Each independent session indep= endently
incurs overheads, causing unnecessary resource usage on devices.

Several modern computing platforms provide a push notification service that=
consolidates application events, distributing those events to applications = as
they arrive.=C2=A0 The single session avoids duplicated overhead costs on d= evices.

This working group will develop a protocol that applications can use to req= uest
the delivery of data to a device using a consolidated push notification ser= vice.
This protocol will include the ability to push the same message to multiple=
subscribed devices.=C2=A0 The work may describe a protocol that allows a de= vice to
subscribe to a push service and receive pushed messages.

This work will be done in collaboration with the W3C Webapps Working Group,= who
are developing a Web Push API for use in web applications (see
<http://www= .w3.org/TR/push-api/>).

---

Pete Resnick suggested we be honest and specifically call out HTTP as
the basis of the protocol.=C2=A0 I don't think that's appropriate h= ere,
since this isn't necessarily HTTP-based.=C2=A0 And I say that even when= the
proposal I have on the table is HTTP-based.

There were questions about the "exemplar protocol" statement, whi= ch in
retrospect is completely understandable.=C2=A0 I hope that the last
sentence of paragraph 3 is clearer on this point.

Stephen Farrell and Adrian Farrel both had concerns around security
and privacy.=C2=A0 I'm happy to include text if someone can avoid it be= ing
too much of a motherhood statement, which I don't think would be
valuable.=C2=A0 Particularly because a fair treatment of the assumed
security architecture, problems arising from that, and the associated
privacy implications is entirely achievable within the confines of a
security considerations section.=C2=A0 I personally don't believe that = it's
necessary to write security considerations into every charter; I'd
prefer to think that we've won hearts and minds over to the need for good considerations such that this need is implicit. Maybe that's just<= br> an optimistic projection on my part.

BTW, my recent realization is that hard requirements around security
will be driven from the W3C webapps WG, not the IETF.

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



--

Francesco Nerieri |=C2=A0Eng. Manager - Mobile |=C2=A0nero@google.com=C2=A0|=C2=A0650.283.8890=C2=A0=
--001a113a49ecf7c2ba0503bd60de-- From nobody Tue Sep 23 14:18:58 2014 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 1746E1A6EDE for ; Tue, 23 Sep 2014 14:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 mNk5esZzeK76 for ; Tue, 23 Sep 2014 14:18:52 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 056811A6EE5 for ; Tue, 23 Sep 2014 14:18:38 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by gateway2.nyi.internal (Postfix) with ESMTP id 6E51E20A9C for ; Tue, 23 Sep 2014 17:18:38 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Tue, 23 Sep 2014 17:18:38 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:cc:message-id:references:in-reply-to :mime-version:content-type:content-transfer-encoding; s=mesmtp; bh=qHiYa1allHBtT8dpFrQ6bGg6YC4=; b=bVNDADUAgB23ktGv1WOSErFUkrKJ txk/Gbe2cpuQYckQBeSS1dDKkuYm/otuIHRfqWb1Y8ixbQnbyXzlEs3VWjTasjXu Bc33ZWVc8/SQsBaZc5Pc/RlyaB1V9BxvhkZN65vpztPmRIj0SkSRAWyLJ6Og/A27 ydBa83Edz/VM/N4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:cc:message-id :references:in-reply-to:mime-version:content-type :content-transfer-encoding; s=smtpout; bh=qHiYa1allHBtT8dpFrQ6bG g6YC4=; b=m51ytA7Y5EPviC0WKiYMc86/JJb1XaOTDpFnSagNnBEekVqT3qEvjh MD7YCLvdFapsswriFl1+x8KZXc8U+eG3l1osMignSX8s23wM7w9nYd81jn/cK9DZ AYOXoiba/b2LK6pRZYQbwnmUfVcgZF8XzY41BonGAfTRmiqrnirMM= X-Sasl-enc: JtwCPqoOiN7Bprn6ndI9MGmqmbYF7mRZqt+ikhYwlPgd 1411507117 Received: from [171.68.18.45] (unknown [171.68.18.45]) by mail.messagingengine.com (Postfix) with ESMTPA id 30EEB680222; Tue, 23 Sep 2014 17:18:35 -0400 (EDT) User-Agent: Microsoft-MacOutlook/14.4.3.140616 Date: Tue, 23 Sep 2014 14:18:28 -0700 From: Alissa Cooper To: Pete Resnick , The IESG Message-ID: Thread-Topic: Pete Resnick's No Objection on charter-ietf-webpush-00-00: (with COMMENT) References: <20140917013538.1659.47034.idtracker@ietfa.amsl.com> In-Reply-To: <20140917013538.1659.47034.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/3RKNLZ79z6rXuvalhy2Qh14W6Dc Cc: webpush@ietf.org Subject: Re: [Webpush] Pete Resnick's No Objection on charter-ietf-webpush-00-00: (with COMMENT) 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, 23 Sep 2014 21:18:54 -0000 Hi Pete, Just one comment below. There is updated charter text in the works that should address the rest. On 9/16/14, 6:35 PM, "Pete Resnick" wrote: >Pete Resnick has entered the following ballot position for >charter-ietf-webpush-00-00: No Objection > >When responding, please keep the subject line intact and reply to all >email addresses included in the To and CC lines. (Feel free to cut this >introductory paragraph, however.) > > > >The document, along with other ballot positions, can be found here: >http://datatracker.ietf.org/doc/charter-ietf-webpush/ > > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >(For the IESG only: I still don't know if we have completely given up on >2418, section 2.2: > > The first > paragraph must give a brief summary of the problem area, basis, > goal(s) and approach(es) planned for the working group. > >Can we perhaps ask the secretariat if it makes a difference to any formal >thing?) > >Seems fine. Strictly editorial/clarification stuff, and one question at >the bottom. > >Paragraph 3: > > This working group will develop a protocol... > >Though the name of the WG should suffice, to save some >heartache/heartburn, you probably want to say instead: > > This working group will develop an HTTP-based protocol=E2=80=A6 > >or something like that. Well, the protocol is for the web, but it need not necessarily be HTTP-based. There is an individual draft that contains an HTTP-based proposal, and we all love HTTP, but I=E2=80=99m not sure we need to constrain it in the charter if someone comes up with a different idea. Alissa > > ...that applications can use to request > the delivery of application data to a device using a consolidated >push > notification service. > >I think you can strike the second "application". What other sort of data >could there be? > > This protocol will include the ability to push the same > message to multiple devices (broadcast). > >Suggest: > >s/message/notification >s/devices (broadcast)/subscribed applications > >I know what you meant, but I think using the word "broadcast" could lead >to silly discussions. > > The work may include an exemplar > protocol for devices registering with push services. > >I can't quite figure out what that sentence means. Help please? > > From nobody Tue Sep 23 14:29:38 2014 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 B3CC51A1BA9 for ; Tue, 23 Sep 2014 14:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 tmAasmDgNOhG for ; Tue, 23 Sep 2014 14:29:21 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 335381A1B2E for ; Tue, 23 Sep 2014 14:29:21 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by gateway2.nyi.internal (Postfix) with ESMTP id A1C3020A7E for ; Tue, 23 Sep 2014 17:29:20 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Tue, 23 Sep 2014 17:29:20 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:cc:message-id:references:in-reply-to :mime-version:content-type:content-transfer-encoding; s=mesmtp; bh=TWOB+CSymMrlk70KMHho0hrKh7M=; b=k01Fo2OYDQDk6mqkPItoMslOuq43 jqv21f/B0/zM3I99s7O3IDW8MphRryC8IMoKRiAC8mvflDdLCfdVebSXuFnjrXq5 OXuKW4PIVrYmOEv+CbjVXLU+nC90DqiM80j8PUwEL1cOYQopJkOMhyAzvdiuqBYE F32F4cMDh0zZH9c= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:cc:message-id :references:in-reply-to:mime-version:content-type :content-transfer-encoding; s=smtpout; bh=TWOB+CSymMrlk70KMHho0h rKh7M=; b=QxUiDCdU3b384f9ZLS5XHlvJRi5BT0mJYKpPNuZkmPZTUoJduK5LwY Qo6oczkaBNjjuqNCfhw5aRQMpdxf9CxjC3RtEtq5nb/rENuuJhoM9V/s742Ip+gh zdx/Nlzw+Qcw7GUyxBBB8FmyUk1+W0s2/rZar2erFrcnubItk7hdg= X-Sasl-enc: j/UfNrV+xk3MoVwURmj4KdIOv2LeCNM/5+Rs0rHhFj93 1411507759 Received: from [171.68.18.45] (unknown [171.68.18.45]) by mail.messagingengine.com (Postfix) with ESMTPA id 9E6206801CD; Tue, 23 Sep 2014 17:29:17 -0400 (EDT) User-Agent: Microsoft-MacOutlook/14.4.3.140616 Date: Tue, 23 Sep 2014 14:29:12 -0700 From: Alissa Cooper To: Adrian Farrel , The IESG Message-ID: Thread-Topic: Adrian Farrel's No Objection on charter-ietf-webpush-00-00: (with COMMENT) References: <20140918124759.20671.83079.idtracker@ietfa.amsl.com> In-Reply-To: <20140918124759.20671.83079.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/FduE7hoZdKl-1-OVM8TDGfVnt3E Cc: webpush@ietf.org Subject: Re: [Webpush] Adrian Farrel's No Objection on charter-ietf-webpush-00-00: (with COMMENT) 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, 23 Sep 2014 21:29:24 -0000 Hi Adrian, On 9/18/14, 5:47 AM, "Adrian Farrel" wrote: >Adrian Farrel has entered the following ballot position for >charter-ietf-webpush-00-00: No Objection > >When responding, please keep the subject line intact and reply to all >email addresses included in the To and CC lines. (Feel free to cut this >introductory paragraph, however.) > > > >The document, along with other ballot positions, can be found here: >http://datatracker.ietf.org/doc/charter-ietf-webpush/ > > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >I think this is a fine thing to be working on and have no objection to >sending this charter for external review. > >Building on what Stephen says, I would like the WG to explicitly consider >the privacy aspects of consolidating push events since that redirects the >1:1 relationship between pusher and pushee to allow the consolidating >service to be aware of the relationships and services that exist. I think the plan is certainly for the WG to document the privacy implications of the protocol that gets defined (and we=E2=80=99ll work in some charter text about that), but I think the notion that there are new risks here as a result of new =E2=80=9Cconsolidation=E2=80=9D is actually a bit backwards. On= e advantage of standardizing a push protocol would be to give users a great choice among push services compared to what they have today. That seems to me to be the proper comparison, and of potential privacy benefit, as opposed to comparing to direct pusher-pushee notifications (which are not common today). Furthermore, if the concern is about what the *network* can learn, again it=E2=80=99s not clear to me that using a standardized push service (assuming encrypted notifications) gives away any more information than use of existing proprietary push services + HTTP does today. Best, Alissa > > From nobody Wed Sep 24 07:09:30 2014 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 994561A00EF for ; Wed, 24 Sep 2014 06:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 eOPSfnqcZD4a for ; Wed, 24 Sep 2014 06:21:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 392821A0127 for ; Wed, 24 Sep 2014 06:21:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: webpush@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140924132140.5930.73013.idtracker@ietfa.amsl.com> Date: Wed, 24 Sep 2014 06:21:40 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/Ngq3enIP2rRjUXqLGuNzHw4BnhA X-Mailman-Approved-At: Wed, 24 Sep 2014 07:09:25 -0700 Subject: [Webpush] State changed: charter-ietf-webpush-00-01 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 13:21:45 -0000 State changed to External review. URL: http://datatracker.ietf.org/doc/charter-ietf-webpush/ From nobody Wed Sep 24 07:09:32 2014 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 010321A00FC; Wed, 24 Sep 2014 06:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 n5qus9HcYagS; Wed, 24 Sep 2014 06:19:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCE81A00D6; Wed, 24 Sep 2014 06:19:19 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140924131919.8882.85143.idtracker@ietfa.amsl.com> Date: Wed, 24 Sep 2014 06:19:19 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/bGrE_7Fa-Bq873oGr0881eG4HVY X-Mailman-Approved-At: Wed, 24 Sep 2014 07:09:25 -0700 Cc: webpush WG Subject: [Webpush] WG Review: Web-Based Push Notifications (webpush) X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 13:19:21 -0000 A new IETF working group has been proposed in the Real-time Applications and Infrastructure Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2014-10-01. Web-Based Push Notifications (webpush) ------------------------------------------------ Current Status: Proposed WG Assigned Area Director: Alissa Cooper Mailing list Address: webpush@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/webpush Archive: http://www.ietf.org/mail-archive/web/webpush/current/maillist.html Charter: Many applications require continuous access to network communications so that real-time events - such as incoming calls or messages - can be conveyed ("pushed") to the user in a timely fashion. Uncoordinated use of the network by multiple applications can contribute to unnecessary use of the network on devices. For instance, maintaining sessions can dominate costs over the long term, since pushed events are relatively rare. This is particularly onerous for battery-powered devices, on which network communication contributes a significant proportion of power usage. Each independent session independently incurs overheads, causing unnecessary resource usage on devices. Several modern computing platforms provide a push notification service that consolidates application events, distributing those events to applications as they arrive. The single session avoids duplicated overhead costs on devices. This working group will develop a protocol that applications can use to request the delivery of data to a device using a consolidated push notification service. This protocol will include the ability to push the same message to multiple subscribed devices. The work may describe a protocol that allows a device to subscribe to a push service and receive pushed messages. This work will be done in collaboration with the W3C Webapps Working Group, who are developing a Web Push API for use in web applications (see ). Milestones: Nov 2015 - Send web push protocol draft to the IESG as Proposed Standard From nobody Wed Sep 24 07:35:59 2014 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 5BD331A0180 for ; Wed, 24 Sep 2014 07:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMR84dJyUlED for ; Wed, 24 Sep 2014 07:20:37 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 179C31A017C for ; Wed, 24 Sep 2014 07:20:35 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id z2so7364440wiv.17 for ; Wed, 24 Sep 2014 07:20:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=6mkiVNlyd2aFQJXbn6vDxwHaKx/ErcePMwAsKRFWD4Y=; b=hGL6MdulEbxQEsK35r5n2RYamh3CxCZG0/q5qUaReY0LiWnt9XcdWlYoXipnPSaA3f Z/LzYpsdAvzIw1z7IxsDtiijePVCkde4IrOTMmBDicIMDeAX6gEbbIIxh2CUlCtf4+ng RnDC/06CxVOY3RC71fuefhFGSgVDSSf0EZdjqpCuY/HCC67msQstm9BQgj0BzZfgR5qX ZyokE3Ozyz0t4xh+ZOCHyo0ybvOzf80bih+SyeaE+0+wEYGz7ZpoeZhPcy+5csuutFf7 ivQcaUvqhGbY14vJBCQtT95T+Uu20zCy/RsVRPcp9nolOnLg9NPunji+hA0S+AaBm0+k flNw== X-Received: by 10.180.91.133 with SMTP id ce5mr31073122wib.62.1411568434696; Wed, 24 Sep 2014 07:20:34 -0700 (PDT) Received: from Barstow-MBP.local ([192.100.104.170]) by mx.google.com with ESMTPSA id fx2sm887385wjb.37.2014.09.24.07.20.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Sep 2014 07:20:34 -0700 (PDT) Message-ID: <5422D32F.8050308@gmail.com> Date: Wed, 24 Sep 2014 10:20:31 -0400 From: Arthur Barstow User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: public-webapps References: <20140924131919.8882.85143.idtracker@ietfa.amsl.com> In-Reply-To: <20140924131919.8882.85143.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140924131919.8882.85143.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/uyjQFwqZVgDsGEl-NO2aGr7UrS0 X-Mailman-Approved-At: Wed, 24 Sep 2014 07:35:56 -0700 Subject: [Webpush] IETF proposes new "Web-Based Push Notifications" Working Group X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: public-webapps List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 14:20:39 -0000 [ Bcc webpush@ietf.org ] Hi All, I recall the IETF's intent to create a web-based push notifications protocol standard was previously announced on this list. Please note the draft charter for this WG explicitly mentions WebApps: [[ ... This work will be done in collaboration with the W3C Webapps Working Group, who are developing a Web Push API for use in web applications (see ). ]] If anyone has any comments or concerns about this, please speak up. -Thanks, AB -------- Original Message -------- Subject: [Webpush] WG Review: Web-Based Push Notifications (webpush) Date: Wed, 24 Sep 2014 06:19:19 -0700 From: The IESG To: IETF-Announce CC: webpush WG A new IETF working group has been proposed in the Real-time Applications and Infrastructure Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2014-10-01. Web-Based Push Notifications (webpush) ------------------------------------------------ Current Status: Proposed WG Assigned Area Director: Alissa Cooper Mailing list Address: webpush@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/webpush Archive: http://www.ietf.org/mail-archive/web/webpush/current/maillist.html Charter: Many applications require continuous access to network communications so that real-time events - such as incoming calls or messages - can be conveyed ("pushed") to the user in a timely fashion. Uncoordinated use of the network by multiple applications can contribute to unnecessary use of the network on devices. For instance, maintaining sessions can dominate costs over the long term, since pushed events are relatively rare. This is particularly onerous for battery-powered devices, on which network communication contributes a significant proportion of power usage. Each independent session independently incurs overheads, causing unnecessary resource usage on devices. Several modern computing platforms provide a push notification service that consolidates application events, distributing those events to applications as they arrive. The single session avoids duplicated overhead costs on devices. This working group will develop a protocol that applications can use to request the delivery of data to a device using a consolidated push notification service. This protocol will include the ability to push the same message to multiple subscribed devices. The work may describe a protocol that allows a device to subscribe to a push service and receive pushed messages. This work will be done in collaboration with the W3C Webapps Working Group, who are developing a Web Push API for use in web applications (see ). Milestones: Nov 2015 - Send web push protocol draft to the IESG as Proposed Standard _______________________________________________ Webpush mailing list Webpush@ietf.org https://www.ietf.org/mailman/listinfo/webpush From nobody Wed Sep 24 11:29:02 2014 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 38CBB1A01AE; Wed, 24 Sep 2014 11:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] 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 7uwAp6BISdC5; Wed, 24 Sep 2014 11:00:22 -0700 (PDT) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (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 1195F1A00DA; Wed, 24 Sep 2014 11:00:22 -0700 (PDT) Received: from [10.20.30.90] (142-254-17-87.dsl.dynamic.fusionbroadband.com [142.254.17.87]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id s8OI0ILO056713 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 24 Sep 2014 11:00:21 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 142-254-17-87.dsl.dynamic.fusionbroadband.com [142.254.17.87] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Paul Hoffman In-Reply-To: <20140924131919.8882.85143.idtracker@ietfa.amsl.com> Date: Wed, 24 Sep 2014 10:59:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2BB9960F-9AD5-4BE4-9BDE-7BEAA443EA23@vpnc.org> References: <20140924131919.8882.85143.idtracker@ietfa.amsl.com> To: ietf@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/jXbChqhf5NJoT0nKjtya1K0Sc3E X-Mailman-Approved-At: Wed, 24 Sep 2014 11:28:47 -0700 Cc: webpush WG Subject: Re: [Webpush] WG Review: Web-Based Push Notifications (webpush) X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 18:00:23 -0000 Is this meant to be over HTTP or not? That WG is called "Web-based", and = the charter says that this will be done in collaboration with with the = W3C WG, but the charter also says that the WG will "develop a protocol". = HTTP is already developed; in fact, we are close to finishing it again. = :-) The charter should say "develop a way to use HTTP", not "develop a = protocol".=20 --Paul Hoffman= From nobody Wed Sep 24 14:24:53 2014 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 7835F1A1A56 for ; Wed, 24 Sep 2014 14:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 V35kHhT6MOvW for ; Wed, 24 Sep 2014 14:24:28 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEB261A016D for ; Wed, 24 Sep 2014 14:24:28 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by gateway2.nyi.internal (Postfix) with ESMTP id 1AC492078F for ; Wed, 24 Sep 2014 17:24:28 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Wed, 24 Sep 2014 17:24:28 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:cc:message-id:references:in-reply-to :mime-version:content-type:content-transfer-encoding; s=mesmtp; bh=xjgUcbRYAC/sID8X9W5VCSEu3sQ=; b=gCtvESdHtFTXP18A5M8oT9aLRhUH hdzhUcPgW//xxzdZjNM8/+h6roJBI/LqMInDL98pGaNqtkCR9sS9NHb6zrANK198 KNcbxjBkRejaybkC8tDOaVw8KWhUZo9Z3kogX77HXVhC8VvggO8hMu1LvdTDeYXA SOd9bybZel3b6iM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:cc:message-id :references:in-reply-to:mime-version:content-type :content-transfer-encoding; s=smtpout; bh=xjgUcbRYAC/sID8X9W5VCS Eu3sQ=; b=osc+/txuQGxckzSPygWgLj41ojszNnFZvnz+1va9dqvS4aNViszCiv MygcKF1bhiHX0oD5ncKgQUNBdddC64HwSSiJ19OMTTa3LslOpZYB426pEKl07ctk ivVugG+zplrlmwBQmD2vA5VsDMsh6718QaMNAv40FYpCw3+h+/iLo= X-Sasl-enc: p7iS8i0PSU2IT2orijNkoVpKrFirYxybdHoCo+x+CSpT 1411593867 Received: from [171.68.18.45] (unknown [171.68.18.45]) by mail.messagingengine.com (Postfix) with ESMTPA id 5ECC56800AE; Wed, 24 Sep 2014 17:24:26 -0400 (EDT) User-Agent: Microsoft-MacOutlook/14.4.3.140616 Date: Wed, 24 Sep 2014 14:24:22 -0700 From: Alissa Cooper To: Paul Hoffman , IESG Message-ID: Thread-Topic: WG Review: Web-Based Push Notifications (webpush) References: <20140924131919.8882.85143.idtracker@ietfa.amsl.com> <2BB9960F-9AD5-4BE4-9BDE-7BEAA443EA23@vpnc.org> In-Reply-To: <2BB9960F-9AD5-4BE4-9BDE-7BEAA443EA23@vpnc.org> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/4CsCRxutedZLIy6ruiVKBP1h0ig Cc: webpush WG Subject: Re: [Webpush] WG Review: Web-Based Push Notifications (webpush) X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 21:24:36 -0000 (Re-directing to iesg@ietf, per the charter review announcement.) Hi Paul, The protocol is for the web, but it need not necessarily be HTTP-based. There is an individual draft that contains an HTTP-based proposal, and we all love HTTP, but I=E2=80=99m not sure we need to constrain it in the charter if someone comes up with a different idea. Alissa On 9/24/14, 10:59 AM, "Paul Hoffman" wrote: >Is this meant to be over HTTP or not? That WG is called "Web-based", and >the charter says that this will be done in collaboration with with the >W3C WG, but the charter also says that the WG will "develop a protocol". >HTTP is already developed; in fact, we are close to finishing it again. >:-) The charter should say "develop a way to use HTTP", not "develop a >protocol".=20 > >--Paul Hoffman From nobody Wed Sep 24 17:49:29 2014 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 A78811A1ADD; Wed, 24 Sep 2014 15:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] 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 1C8vsNiyr8BA; Wed, 24 Sep 2014 15:25:21 -0700 (PDT) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (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 3140F1A1ADC; Wed, 24 Sep 2014 15:25:21 -0700 (PDT) Received: from [10.20.30.90] (142-254-17-87.dsl.dynamic.fusionbroadband.com [142.254.17.87]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id s8OMPGAt067991 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 24 Sep 2014 15:25:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 142-254-17-87.dsl.dynamic.fusionbroadband.com [142.254.17.87] claimed to be [10.20.30.90] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Paul Hoffman In-Reply-To: Date: Wed, 24 Sep 2014 15:24:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9B629095-9585-40A8-9818-5BB9910489CC@vpnc.org> References: <20140924131919.8882.85143.idtracker@ietfa.amsl.com> <2BB9960F-9AD5-4BE4-9BDE-7BEAA443EA23@vpnc.org> To: Alissa Cooper X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/NvH0rZCgJrmN7fI_R9TnFeXOl3E X-Mailman-Approved-At: Wed, 24 Sep 2014 17:49:26 -0700 Cc: IESG , webpush WG Subject: Re: [Webpush] WG Review: Web-Based Push Notifications (webpush) X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 22:25:26 -0000 On Sep 24, 2014, at 2:24 PM, Alissa Cooper wrote: > The protocol is for the web, but it need not necessarily be = HTTP-based. > There is an individual draft that contains an HTTP-based proposal, and = we > all love HTTP, but I=92m not sure we need to constrain it in the = charter if > someone comes up with a different idea. The idea of having a WG called "Web-foo" that is about the Internet, not = the web, seems completely broken in the sense that you will not get the = right people to review the design until much too late in the design = process. Please either rename the WG to "Push Notifications = (pushnotify)" or limit the scope in the charter to using web = technologies, namely HTTP and URIs. --Paul Hoffman= From elioda@microsoft.com Mon Sep 29 10:44:09 2014 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 33E7F1A8F34; Mon, 29 Sep 2014 10:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 ZMr_lbdxai3S; Mon, 29 Sep 2014 10:44:06 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0784.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:784]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F8841A1B83; Mon, 29 Sep 2014 10:44:06 -0700 (PDT) Received: from BL2PR03MB132.namprd03.prod.outlook.com (10.255.230.24) by BL2PR03MB132.namprd03.prod.outlook.com (10.255.230.24) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Mon, 29 Sep 2014 17:43:43 +0000 Received: from BL2PR03MB132.namprd03.prod.outlook.com ([169.254.9.116]) by BL2PR03MB132.namprd03.prod.outlook.com ([169.254.9.116]) with mapi id 15.00.1039.011; Mon, 29 Sep 2014 17:43:43 +0000 From: Elio Damaggio To: "webpush@ietf.org" Thread-Topic: [Webpush] Comment on charter and HTTP Thread-Index: Ac/cCK0ubT2yJjc2Q2a49PXxavRwYQ== Date: Mon, 29 Sep 2014 17:43:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2001:4898:80e0:ee43::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB132; x-forefront-prvs: 034902F5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(199003)(189002)(74662003)(99396003)(46102003)(77982003)(74502003)(97736003)(15202345003)(86612001)(81342003)(54356999)(101416001)(79102003)(108616004)(50986999)(81542003)(86362001)(105586002)(80022003)(558084003)(90102001)(107046002)(16236675004)(19625215002)(229853001)(87936001)(2351001)(31966008)(106356001)(76482002)(2656002)(92566001)(83072002)(85852003)(120916001)(21056001)(83322001)(19580395003)(2501002)(33646002)(20776003)(76576001)(64706001)(110136001)(85306004)(4396001)(10300001)(74316001)(15975445006)(19300405004)(77096002)(95666004)(99286002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB132; H:BL2PR03MB132.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_a72dc3ad78ee4483ab268104a6170e14BL2PR03MB132namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/gwmtI0NWQsmg_fWrzPTJzbj6YzM X-Mailman-Approved-At: Mon, 29 Sep 2014 10:46:34 -0700 Cc: "iesg@ietf.org" Subject: [Webpush] Comment on charter and HTTP 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, 29 Sep 2014 17:45:23 -0000 --_000_a72dc3ad78ee4483ab268104a6170e14BL2PR03MB132namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I read the charter, and, as stated, it includes any "push" protocol for arb= itrary devices. Does the charter include low-powered devices, such as embed= ded systems (think IoT, "Smart things", etc.)? Thanks, Elio --_000_a72dc3ad78ee4483ab268104a6170e14BL2PR03MB132namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I read the charter, and, as stated, it includes any = “push” protocol for arbitrary devices. Does the charter include= low-powered devices, such as embedded systems (think IoT, “Smart thi= ngs”, etc.)?

Thanks,

 

Elio

--_000_a72dc3ad78ee4483ab268104a6170e14BL2PR03MB132namprd03pro_-- From nobody Mon Sep 29 11:29:54 2014 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 180F81A883A; Mon, 29 Sep 2014 11:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b_3FwO9H4iKP; Mon, 29 Sep 2014 11:29:45 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAD591A914A; Mon, 29 Sep 2014 11:29:35 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id n15so6783580lbi.1 for ; Mon, 29 Sep 2014 11:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=OnKW+XDWONIwKrYl2veTATMToGJZYi91GaJcDXiasLI=; b=cuLeK7VMsL8v3RxVxGCm2pmvCQXoK5+6SwWsE4q32grQQyi/6GX3zyaOgYPRyFfHl1 djn2NG21Fd1JQVLE8RgpkphT84vx79ERcBmZ6P8oGzkQKO913ExYgMLBDT90+ylgElpz ODXII6DmUPVVQLYlFPIPNm+21tdFPIjy1DuDiHtMao3woXoCyTdbAQSFtcUiVI1F1oD+ bNj2QO6qhAJT+qaynAk/tLeudqxnnz3hB3ZZ9qTHcCxoIqUALrjqXCP7XHhdlxbRmKKl w3YKU3RjyCUGXvkXV107HFHwVjdFXX+aORiG4sgXZ/M2A51K9NYX8WzemqLI01oOQ2+6 WFpA== MIME-Version: 1.0 X-Received: by 10.112.125.132 with SMTP id mq4mr4659767lbb.103.1412015374052; Mon, 29 Sep 2014 11:29:34 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Mon, 29 Sep 2014 11:29:34 -0700 (PDT) In-Reply-To: References: Date: Mon, 29 Sep 2014 11:29:34 -0700 Message-ID: From: Martin Thomson To: Elio Damaggio Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/84jzLEOn5YrN3FkIlz11agC34m8 Cc: "iesg@ietf.org" , "webpush@ietf.org" Subject: Re: [Webpush] Comment on charter and HTTP 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, 29 Sep 2014 18:29:49 -0000 On 29 September 2014 10:43, Elio Damaggio wrote: > I read the charter, and, as stated, it includes any =E2=80=9Cpush=E2=80= =9D protocol for > arbitrary devices. Does the charter include low-powered devices, such as > embedded systems (think IoT, =E2=80=9CSmart things=E2=80=9D, etc.)? The overall architecture will probably suit, but the protocol might not. The immediate goal is to enable this for things with web browsers, so I'd imagine that some choices will be made that are suboptimal for IoT devices (or at least, not aggressive enough in the power/processing cost savings direction). It's probably not wise to try to solve for too wide a range of devices; I've seen that go very poorly. That doesn't mean that we can't eventually considering widening the net a little. But I personally want to ensure that we have a really good solution for browsers first and foremost. What I was envisaging with my proposal was that this would serve as a baseline, from which customized protocols could be bootstrapped. For instance, if you are talking to a server, you could hint that you can talk some as-yet-unspecified, super-power-saving protocol, at which point the push server switches over to that instead. Of course, the protocol also works over COAP with some small modifications, which might be more practical short term goal. None of that is in the charter though. From nobody Mon Sep 29 17:58:57 2014 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 1BB4C1A0009; Mon, 29 Sep 2014 17:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4uTGvn9Mlxj; Mon, 29 Sep 2014 17:58:51 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0759.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::759]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFB751A0008; Mon, 29 Sep 2014 17:58:50 -0700 (PDT) Received: from BL2PR03MB132.namprd03.prod.outlook.com (10.255.230.24) by BL2PR03MB131.namprd03.prod.outlook.com (10.255.230.23) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Tue, 30 Sep 2014 00:58:27 +0000 Received: from BL2PR03MB132.namprd03.prod.outlook.com ([169.254.9.116]) by BL2PR03MB132.namprd03.prod.outlook.com ([169.254.9.116]) with mapi id 15.00.1039.011; Tue, 30 Sep 2014 00:58:27 +0000 From: Elio Damaggio To: Martin Thomson Thread-Topic: [Webpush] Comment on charter and HTTP Thread-Index: Ac/cCK0ubT2yJjc2Q2a49PXxavRwYQACqPoAAAGOajA= Date: Tue, 30 Sep 2014 00:58:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2001:4898:80e0:ee43::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB131; x-forefront-prvs: 0350D7A55D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(189002)(24454002)(377454003)(199003)(20776003)(77096002)(105586002)(19580405001)(106356001)(4396001)(64706001)(120916001)(21056001)(108616004)(31966008)(85306004)(99396003)(33646002)(19580395003)(97736003)(80022003)(92566001)(107046002)(86612001)(101416001)(50986999)(10300001)(2656002)(76176999)(110136001)(86362001)(46102003)(76482002)(76576001)(54356999)(99286002)(561944003)(95666004)(87936001)(74316001)(85852003)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB131; H:BL2PR03MB132.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/_rb8VtVNbwJ5tJqx4VdpuTVs-Tw Cc: "iesg@ietf.org" , "webpush@ietf.org" Subject: Re: [Webpush] Comment on charter and HTTP 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, 30 Sep 2014 00:58:54 -0000 SSBhZ3JlZSB3aXRoIHlvdSB0aGF0LCBhcyBsb25nIGFzIHRoZSBwcm90b2NvbCBoYXMgdGhlIHJp Z2h0IGV4dGVuc2liaWxpdHkgcG9pbnRzLCBzdXBwb3J0IGZvciBleHRyZW1lbHkgbG93IHBvd2Vy ZWQgZGV2aWNlcyBtaWdodCBiZSBhZGRlZCBsYXRlci4NCg0KR2l2ZW4gdGhlIHdpbGwgb2YgY3Jl YXRpbmcgYSBiYXNlbGluZSwgY29udmVyZ2VuY2Ugb24gdGhlIGZvbGxvd2luZyBhc3BlY3RzIGNv dWxkIGJlIGluY3JlZGlibHkgYmVuZWZpY2lhbDoNCiogYXBwbGljYXRpb24gdG8gcHVzaCBzZXJ2 ZXIgcHJvdG9jb2wgKHcuci50IGRlbGl2ZXJ5L3JlbGlhYmlsaXR5IHNlbWFudGljcywgdW5pY2Fz dC1tdWx0aWNhc3Qgb3B0aW9ucywgc2VjdXJpdHk/KQ0KKiBkZXZpY2UgdG8gcHVzaCBzZXJ2ZXIg cHJvdG9jb2wgZXh0ZW5zaWJpbGl0eSAoYXMgZm9yIHlvdXIgY29tbWVudCkNCiogbGlmZWN5Y2xl IG9mIGNoYW5uZWxzIChleHBpcmF0aW9uLCByZW5ld2FsKQ0KDQpEb2VzIHRoZSBjaGFydGVyIGlu Y2x1ZGUgc29tZSBvciBhbGwgb2YgdGhlIGFib3ZlPw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogTWFydGluIFRob21zb24gW21haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5j b21dIA0KU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMjksIDIwMTQgMTE6MzAgQU0NClRvOiBFbGlv IERhbWFnZ2lvDQpDYzogd2VicHVzaEBpZXRmLm9yZzsgaWVzZ0BpZXRmLm9yZw0KU3ViamVjdDog UmU6IFtXZWJwdXNoXSBDb21tZW50IG9uIGNoYXJ0ZXIgYW5kIEhUVFANCg0KT24gMjkgU2VwdGVt YmVyIDIwMTQgMTA6NDMsIEVsaW8gRGFtYWdnaW8gPGVsaW9kYUBtaWNyb3NvZnQuY29tPiB3cm90 ZToNCj4gSSByZWFkIHRoZSBjaGFydGVyLCBhbmQsIGFzIHN0YXRlZCwgaXQgaW5jbHVkZXMgYW55 IOKAnHB1c2jigJ0gcHJvdG9jb2wgDQo+IGZvciBhcmJpdHJhcnkgZGV2aWNlcy4gRG9lcyB0aGUg Y2hhcnRlciBpbmNsdWRlIGxvdy1wb3dlcmVkIGRldmljZXMsIA0KPiBzdWNoIGFzIGVtYmVkZGVk IHN5c3RlbXMgKHRoaW5rIElvVCwg4oCcU21hcnQgdGhpbmdz4oCdLCBldGMuKT8NCg0KVGhlIG92 ZXJhbGwgYXJjaGl0ZWN0dXJlIHdpbGwgcHJvYmFibHkgc3VpdCwgYnV0IHRoZSBwcm90b2NvbCBt aWdodCBub3QuICBUaGUgaW1tZWRpYXRlIGdvYWwgaXMgdG8gZW5hYmxlIHRoaXMgZm9yIHRoaW5n cyB3aXRoIHdlYiBicm93c2Vycywgc28gSSdkIGltYWdpbmUgdGhhdCBzb21lIGNob2ljZXMgd2ls bCBiZSBtYWRlIHRoYXQgYXJlIHN1Ym9wdGltYWwgZm9yIElvVCBkZXZpY2VzIChvciBhdCBsZWFz dCwgbm90IGFnZ3Jlc3NpdmUgZW5vdWdoIGluIHRoZSBwb3dlci9wcm9jZXNzaW5nIGNvc3Qgc2F2 aW5ncyBkaXJlY3Rpb24pLiAgSXQncyBwcm9iYWJseSBub3Qgd2lzZSB0byB0cnkgdG8gc29sdmUg Zm9yIHRvbyB3aWRlIGEgcmFuZ2Ugb2YgZGV2aWNlczsgSSd2ZSBzZWVuIHRoYXQgZ28gdmVyeSBw b29ybHkuDQoNClRoYXQgZG9lc24ndCBtZWFuIHRoYXQgd2UgY2FuJ3QgZXZlbnR1YWxseSBjb25z aWRlcmluZyB3aWRlbmluZyB0aGUgbmV0IGEgbGl0dGxlLiAgQnV0IEkgcGVyc29uYWxseSB3YW50 IHRvIGVuc3VyZSB0aGF0IHdlIGhhdmUgYSByZWFsbHkgZ29vZCBzb2x1dGlvbiBmb3IgYnJvd3Nl cnMgZmlyc3QgYW5kIGZvcmVtb3N0Lg0KDQpXaGF0IEkgd2FzIGVudmlzYWdpbmcgd2l0aCBteSBw cm9wb3NhbCB3YXMgdGhhdCB0aGlzIHdvdWxkIHNlcnZlIGFzIGEgYmFzZWxpbmUsIGZyb20gd2hp Y2ggY3VzdG9taXplZCBwcm90b2NvbHMgY291bGQgYmUgYm9vdHN0cmFwcGVkLiAgRm9yIGluc3Rh bmNlLCBpZiB5b3UgYXJlIHRhbGtpbmcgdG8gYSBzZXJ2ZXIsIHlvdSBjb3VsZCBoaW50IHRoYXQg eW91IGNhbiB0YWxrIHNvbWUgYXMteWV0LXVuc3BlY2lmaWVkLCBzdXBlci1wb3dlci1zYXZpbmcg cHJvdG9jb2wsIGF0IHdoaWNoIHBvaW50IHRoZSBwdXNoIHNlcnZlciBzd2l0Y2hlcyBvdmVyIHRv IHRoYXQgaW5zdGVhZC4gIE9mIGNvdXJzZSwgdGhlIHByb3RvY29sIGFsc28gd29ya3Mgb3ZlciBD T0FQIHdpdGggc29tZSBzbWFsbCBtb2RpZmljYXRpb25zLCB3aGljaCBtaWdodCBiZSBtb3JlIHBy YWN0aWNhbCBzaG9ydCB0ZXJtIGdvYWwuICBOb25lIG9mIHRoYXQgaXMgaW4gdGhlIGNoYXJ0ZXIg dGhvdWdoLg0K From nobody Mon Sep 29 19:49:52 2014 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 A4F7A1A00C9; Mon, 29 Sep 2014 19:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YozadaOQ2pui; Mon, 29 Sep 2014 19:49:50 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 274621A0072; Mon, 29 Sep 2014 19:49:49 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id ge10so4565397lab.8 for ; Mon, 29 Sep 2014 19:49:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7nviLn+kSwhhLfC0eoUgNalT+NtMm444f/KMvJ1DDZY=; b=g/IjWl09p0oeFFwmJbZYTpdvJOsDyoORLbCoYVaQP21APoRzW/Tq4Nj+Xdon5E+6+x RaV8O4tfDgzOIx3mDz+NJjqPg2xFZLbASRzTV/DbnkU8S4UfpLg4Z56nf9hZPeX6WGss NEWFfIZ905ctyREt5g2VGZzpMjrNmlog3kRa+z7CCjrLhfEdvgfN2tDHC1QCxsei5loK c7elSuo3zPNmnh8GxquZSl2BWL6yIG6xCYs1zTWhJdCyvV5RQAyVVsGev0dmR+gLE+Bh MYsjCKaMS+3Pk2XGSq8hK1YHP1jm6jzmoaoCZD9ZrFJAo7TD0P7TQHKEZvs4ouC4/OFn g7AA== MIME-Version: 1.0 X-Received: by 10.152.20.98 with SMTP id m2mr205557lae.51.1412045388391; Mon, 29 Sep 2014 19:49:48 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Mon, 29 Sep 2014 19:49:48 -0700 (PDT) In-Reply-To: References: Date: Mon, 29 Sep 2014 19:49:48 -0700 Message-ID: From: Martin Thomson To: Elio Damaggio Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/I1sv1YFPLfQWR-7LEUj2ZWSE7oA Cc: "iesg@ietf.org" , "webpush@ietf.org" Subject: Re: [Webpush] Comment on charter and HTTP 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, 30 Sep 2014 02:49:51 -0000 On 29 September 2014 17:58, Elio Damaggio wrote: > I agree with you that, as long as the protocol has the right extensibility points, support for extremely low powered devices might be added later. > > Given the will of creating a baseline, convergence on the following aspects could be incredibly beneficial: > * application to push server protocol (w.r.t delivery/reliability semantics, unicast-multicast options, security?) > * device to push server protocol extensibility (as for your comment) > * lifecycle of channels (expiration, renewal) > > Does the charter include some or all of the above? The charter is intentionally terse. That gives us flexibility in how we approach developing solutions on each of those points. I'm happy to discuss trade-offs on each. From nobody Tue Sep 30 11:34:57 2014 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 A255D1A8760; Tue, 30 Sep 2014 11:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkRJnoffuJNF; Tue, 30 Sep 2014 11:34:44 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7F241A8761; Tue, 30 Sep 2014 11:34:41 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id gq15so783087lab.24 for ; Tue, 30 Sep 2014 11:34:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DABKsO+NDTgK6Lpvuo6m5OUFRMGh7ila7Zjumg0ZtZc=; b=RFkeUYsOI2OCxFnvsm7qAIyGcL7gw6uEwGyGh+dcl9ktkPoPyBkr4uKhqHfEspgvOB rYQ6d+gsDtvRRuqtAw5HSJpTxTjsSWm1j5j0rndHbpl2vki6hl8g4T9RIWFF1xME5Ap6 tOLVkC/2xZr2H26AlceRHiO65R/thRoxWudpUKgbH6unvYt59bRJ1lqEISy7ctSFMMci fqMqMSxvnTpit4U11B/cYB25SnX7t0RGTsFy1RYL+wF1K8VrhSFWOglFwpc0f6IzdDVS +i7CAcJkoeLHPsnLYZJTcL0GCIbOB9mKFB+c2AwobstbGf3QUz163EplRUsZ5+cBkPCr sllg== MIME-Version: 1.0 X-Received: by 10.112.34.78 with SMTP id x14mr31994672lbi.38.1412102079700; Tue, 30 Sep 2014 11:34:39 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Tue, 30 Sep 2014 11:34:39 -0700 (PDT) In-Reply-To: References: <20140917145417.2309.43465.idtracker@ietfa.amsl.com> <542180F3.2060902@cs.tcd.ie> Date: Tue, 30 Sep 2014 11:34:39 -0700 Message-ID: From: Martin Thomson To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/rsz0zFh53LMyZ8d4VzW-Xsr2ADM Cc: Alissa Cooper , The IESG , "webpush@ietf.org" Subject: Re: [Webpush] Stephen Farrell's No Objection on charter-ietf-webpush-00-00: (with COMMENT) 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, 30 Sep 2014 18:34:48 -0000 On 23 September 2014 08:18, Martin Thomson wrote: > On 23 September 2014 07:17, Stephen Farrell wrote: >> You're assuming a we/JS client there right? If so that might be a good >> way to characterise this. So e.g. an IMAP MUA is out of scope? > > Absolutely not. Obviously that is the use case required by the Web > API. The protocol however doesn't need to presume any dependency on > that, in much the same way that WebRTC has escaped from the confines > of the browser. > > On the rest, I actually agree. I didn't find that answer particularly > satisfactory either. It's kinda that status quo that I lived with > when I worked with this at Skype. There we used that "talking to > yourself" thing to avoid the need for anything better. I think that > we can improve on that in the web context. I've some ideas here that > I need to check for viability, particularly since they require certain > sacrifices. Expect a more satisfactory write up in a day or so. I wanted to expand on this, because I realize that there was some confusion. I still believe that we need nothing in the charter, because there is nothing that the *protocol* can do to enforce this and adding something to the charter creates a commitment to do something that is essentially impossible within the defined scope. That said, this isn't a lost cause. I've a way to essential force end-to-end security for the entire solution. That requires changes to the web API. The basic idea here is to have the browser provide an encryption key, with which the application is required to protect pushed messages. If messages aren't encrypted and authenticated, then the browser discards them. Nothing prevents the application from sharing messages with others, but that requires extra work. From nobody Tue Sep 30 13:23:02 2014 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 CCCC01A8949; Tue, 30 Sep 2014 13:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 t1bI5bWyUgK3; Tue, 30 Sep 2014 13:23:00 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 95DE71A8947; Tue, 30 Sep 2014 13:22:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1ACE1BE01; Tue, 30 Sep 2014 21:22:57 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRbqD_9VGMGl; Tue, 30 Sep 2014 21:22:52 +0100 (IST) Received: from [10.87.48.7] (unknown [86.46.31.250]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B8AB8BDFE; Tue, 30 Sep 2014 21:22:52 +0100 (IST) Message-ID: <542B111C.6000008@cs.tcd.ie> Date: Tue, 30 Sep 2014 21:22:52 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Martin Thomson References: <20140917145417.2309.43465.idtracker@ietfa.amsl.com> <542180F3.2060902@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/JlGm6Uwjgbh5mi735ft35IRPM_w Cc: Alissa Cooper , The IESG , "webpush@ietf.org" Subject: Re: [Webpush] Stephen Farrell's No Objection on charter-ietf-webpush-00-00: (with COMMENT) 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, 30 Sep 2014 20:23:01 -0000 Hi Martin, On 30/09/14 19:34, Martin Thomson wrote: > On 23 September 2014 08:18, Martin Thomson wrote: >> On 23 September 2014 07:17, Stephen Farrell wrote: >>> You're assuming a we/JS client there right? If so that might be a good >>> way to characterise this. So e.g. an IMAP MUA is out of scope? >> >> Absolutely not. Obviously that is the use case required by the Web >> API. The protocol however doesn't need to presume any dependency on >> that, in much the same way that WebRTC has escaped from the confines >> of the browser. >> >> On the rest, I actually agree. I didn't find that answer particularly >> satisfactory either. It's kinda that status quo that I lived with >> when I worked with this at Skype. There we used that "talking to >> yourself" thing to avoid the need for anything better. I think that >> we can improve on that in the web context. I've some ideas here that >> I need to check for viability, particularly since they require certain >> sacrifices. Expect a more satisfactory write up in a day or so. > > I wanted to expand on this, because I realize that there was some confusion. There is. In my head at least:-) > > I still believe that we need nothing in the charter, because there is > nothing that the *protocol* can do to enforce this and adding > something to the charter creates a commitment to do something that is > essentially impossible within the defined scope. > > That said, this isn't a lost cause. I've a way to essential force > end-to-end security for the entire solution. That requires changes to > the web API. > > The basic idea here is to have the browser provide an encryption key, > with which the application is required to protect pushed messages. If > messages aren't encrypted and authenticated, then the browser discards > them. Nothing prevents the application from sharing messages with > others, but that requires extra work. So I'm sorry for being slow but I'm not getting it. The above seems to be saying that the charter should be silent on security and also that adding some security would require changing a W3C API. Neither of those sound at all hopeful from my POV. But I'm probably getting some of that wrong. S. > From nobody Tue Sep 30 13:54:01 2014 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 445491A8A62; Tue, 30 Sep 2014 13:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66aXqAAHaUtA; Tue, 30 Sep 2014 13:53:56 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A39861A8A60; Tue, 30 Sep 2014 13:53:55 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id mc6so20696999lab.6 for ; Tue, 30 Sep 2014 13:53:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yHc2yn2eMS1bZVpURn+rJlmMJkrDERHpqpqVWp6I0Fc=; b=gdZbKbjBZAHTo0NSFj0F607bTqVUgCZjf9cSp963rCJ4BmcsMeOKlMlqJHJLElM5CF 76z8/Ciy+L3AvHDdpjr15ZyFP5Whw9beOYMWXdKX4Fgp88+1qIqWr1Umh8bcAmsjDdYf U+KN+EnaWY5GUEpp1FPMBJQk22SbL3O7jvtt/EqjSO2yr1nk0yD+H18W8tgHboJ1l8Ov nxsPcxnOtpvMHSCsXn69+yPMkgHQR7Ijm+kbd7UakLKZuVaHNv8f6c6zV2iBSkEKIQx2 6J0k65wA2fGxyEI39T4B/VS46+oOd49ulqhvuch3W/PA1WprfCEV6SzrC6fPehfu0J4J 1mHg== MIME-Version: 1.0 X-Received: by 10.112.148.170 with SMTP id tt10mr48218643lbb.61.1412110433827; Tue, 30 Sep 2014 13:53:53 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Tue, 30 Sep 2014 13:53:53 -0700 (PDT) In-Reply-To: <542B111C.6000008@cs.tcd.ie> References: <20140917145417.2309.43465.idtracker@ietfa.amsl.com> <542180F3.2060902@cs.tcd.ie> <542B111C.6000008@cs.tcd.ie> Date: Tue, 30 Sep 2014 13:53:53 -0700 Message-ID: From: Martin Thomson To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/Mx3I431fBdDnfseYIpjQZkb6mkc Cc: Alissa Cooper , The IESG , "webpush@ietf.org" Subject: Re: [Webpush] Stephen Farrell's No Objection on charter-ietf-webpush-00-00: (with COMMENT) 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, 30 Sep 2014 20:53:57 -0000 On 30 September 2014 13:22, Stephen Farrell wrote: > So I'm sorry for being slow but I'm not getting it. The above seems > to be saying that the charter should be silent on security and also > that adding some security would require changing a W3C API. Neither > of those sound at all hopeful from my POV. But I'm probably getting > some of that wrong. We can't ensure that there is security in the same way a router cannot. (That is, unless there is some magic thing I'm not aware of.) The most we can do is produce a motherhood statement. I'm hopeful. I've had discussions with the Chrome team on this and they were really excited about the prospects of getting end-to-end security for push. Yes, relying on external parties sucks, but I don't see a good alternative. From nobody Tue Sep 30 14:07:41 2014 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 043C11A9131; Tue, 30 Sep 2014 14:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 DF_TAHf8P0Yu; Tue, 30 Sep 2014 14:07:21 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0251A9129; Tue, 30 Sep 2014 14:07:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 55D84BE02; Tue, 30 Sep 2014 22:07:18 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itKcLb9Fun3K; Tue, 30 Sep 2014 22:07:17 +0100 (IST) Received: from [10.87.48.7] (unknown [86.46.31.250]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0D5CEBE01; Tue, 30 Sep 2014 22:07:17 +0100 (IST) Message-ID: <542B1B84.5020408@cs.tcd.ie> Date: Tue, 30 Sep 2014 22:07:16 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Martin Thomson References: <20140917145417.2309.43465.idtracker@ietfa.amsl.com> <542180F3.2060902@cs.tcd.ie> <542B111C.6000008@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/RWCPqY1ebRcZirtgYRrOsq36qfA Cc: Alissa Cooper , The IESG , "webpush@ietf.org" Subject: Re: [Webpush] Stephen Farrell's No Objection on charter-ietf-webpush-00-00: (with COMMENT) 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, 30 Sep 2014 21:07:24 -0000 Hiya, On 30/09/14 21:53, Martin Thomson wrote: > On 30 September 2014 13:22, Stephen Farrell wrote: >> So I'm sorry for being slow but I'm not getting it. The above seems >> to be saying that the charter should be silent on security and also >> that adding some security would require changing a W3C API. Neither >> of those sound at all hopeful from my POV. But I'm probably getting >> some of that wrong. > > We can't ensure that there is security in the same way a router > cannot. (That is, unless there is some magic thing I'm not aware of.) > The most we can do is produce a motherhood statement. > > I'm hopeful. I've had discussions with the Chrome team on this and > they were really excited about the prospects of getting end-to-end > security for push. Yes, relying on external parties sucks, but I > don't see a good alternative. Good that folks are keen on doing stuff. And there's always going to be a distinction here between what we can define (e.g. a way to use TLS or whatever for pushed stuff) and the extra steps that are needed in deployments. Do we have any worked examples of using security (and caring about privacy) here though? I remain concerned that its too easy to just say "turn on push" for , where the security and privacy consequences of doing so are unknowable for . But maybe I'm worrying over not so much and a worked example will help. S. From nobody Tue Sep 30 15:10:19 2014 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 AC8521AC82C; Tue, 30 Sep 2014 15:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGfn3m5NboZT; Tue, 30 Sep 2014 15:10:17 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A2781ACCE2; Tue, 30 Sep 2014 15:10:12 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id q1so9406469lam.21 for ; Tue, 30 Sep 2014 15:10:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=j7NOub1SuWwoUViRwjIGosTd2r1fk9E8Ddu2jFDaAIQ=; b=P/Ub15Nabp6g7jWu7uC6UQUZY0hHPuzxylCY+5diX/cnBl60H2j2x/QoxUunMOf21v 2CrwMcveCTx3YGU3DtEyroQGgyowZOqu9spO5TFbRT8HvHjZZDH+S5Lsm5pTJeDQi5wi k7Wr9sQjpLeCsjfL+ZgWLVv9lRuye65263O1TwWgnG5jrpkPGlbvr99gnmAhBGLSMqNQ 6+NlPunkbTxbqDsJ0llUPakTBJ0Y8jNGKF7DN0eN6QWhAvPoUb238C2WKZnqLjXL09kc qBLoilXbGZ4+B6fjwm9PRitHbEqZtqkN+T+iruTR23enMSVXFVt/6Vgyy2q/wO/fOzbh jIdQ== MIME-Version: 1.0 X-Received: by 10.112.148.170 with SMTP id tt10mr48568269lbb.61.1412115011328; Tue, 30 Sep 2014 15:10:11 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Tue, 30 Sep 2014 15:10:11 -0700 (PDT) In-Reply-To: <542B1B84.5020408@cs.tcd.ie> References: <20140917145417.2309.43465.idtracker@ietfa.amsl.com> <542180F3.2060902@cs.tcd.ie> <542B111C.6000008@cs.tcd.ie> <542B1B84.5020408@cs.tcd.ie> Date: Tue, 30 Sep 2014 15:10:11 -0700 Message-ID: From: Martin Thomson To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/webpush/IAutdvIuZKyOL4AMmA8K1SG6IrU Cc: Alissa Cooper , The IESG , "webpush@ietf.org" Subject: Re: [Webpush] Stephen Farrell's No Objection on charter-ietf-webpush-00-00: (with COMMENT) 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, 30 Sep 2014 22:10:19 -0000 On 30 September 2014 14:07, Stephen Farrell wrote: > Do we have any worked examples of using security (and caring > about privacy) here though? I remain concerned that its too easy > to just say "turn on push" for , where the security and > privacy consequences of doing so are unknowable for . But > maybe I'm worrying over not so much and a worked example will > help. OK, so the intent of the proposed security mechanism is that the easiest thing to do is to provide end-to-end security. How we'd do that is the API returns two things to the application running in the browser: a location to send messages and a key with which to encrypt them. If you don't encrypt them, then the browser will fail to deliver pushed messages. The keying material isn't used in the message delivery at all. An application running on the server can send anything to the browser over the push channel, but if the message doesn't decrypt and authenticate with the selected key, it doesn't get delivered. It's a little odd to effectively hold functionality hostage like that, but I think that it will work. I won't lie, we can't prevent someone outside of the browser context from only using the hop-by-hop security mechanisms. I can't help but be optimistic that a demonstration of feasibility will help shift those use cases too. It's possible that this sort of mechanism could be enforced at the operating system level in the same way. Ever the eternal optimist, I suppose.