Re: [Webpush] WGLC for draft-ietf-webpush-protocol-05
Richard Maher <maherrj@googlemail.com> Wed, 25 May 2016 07:04 UTC
Return-Path: <maherrj@googlemail.com>
X-Original-To: webpush@ietfa.amsl.com
Delivered-To: webpush@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6931F12D986 for <webpush@ietfa.amsl.com>; Wed, 25 May 2016 00:04:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9v_jpNrDu41V for <webpush@ietfa.amsl.com>; Wed, 25 May 2016 00:04:07 -0700 (PDT)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C37112D625 for <webpush@ietf.org>; Wed, 25 May 2016 00:04:07 -0700 (PDT)
Received: by mail-qk0-x236.google.com with SMTP id n63so28342533qkf.0 for <webpush@ietf.org>; Wed, 25 May 2016 00:04:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=j69m9tk7MZsY8ZDuA00g790sjidi11XTzAkhBk/LGd8=; b=AbayOY8cclckn7WrRyvurhjNHu71UFe0lKQ71DNd+JuzWZBsBePhBzzklodVB6tGEQ iLfqLZG/oqDfwZMPYUlTU6rqPGjoOpqxGM5HXqX7XO0UPO5akryprkssWRuw7WUgRFyV OVQCODKZY0GBWocIqDvMAoJCt8AiVabhCKO9JbGQ0uFI5Fh1GNeEfDCaFTZvMIzhLw7f fwqp9vyNEqve4wmnTRCqJQH6j95cVWrl6EyuK1vhjBLTwDQeXByDyxfGPErLQEPlqOuP YOLxMaogJiz5TIhnamdtJKE0L//c7o3Onrpu5z6EafDe1GvXrYWNtUdzgCPKYBEsXUqW jNBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=j69m9tk7MZsY8ZDuA00g790sjidi11XTzAkhBk/LGd8=; b=dZRBjrmonRwaWdcaAGo1j1RF7q9DkbKguNpM3lC+ZEXmlVwgRZu6hNafo+IOCsjfhx vexuO+aJpexlxlqMCUIBpXxySsEia4Xih2Os6+J44rVEzCsk3RWXQy+TwLdAxwaZzLKF wy9Mk7NIEk6YDUGVUvaKDy13f/cMd811h15z36mVs2Or2D+ViSTyJBNGpmtx80N+xqmW 2KzX6Qn7sNmNfN32N58g7uMwKVxtOvnyaEJLQjZxbvlQV2hgjI4XOcrUQ5QCjsoiKtlm PfV2bE9gFLMeqiSSFReR1z1A+QpnC6eqgCadgQhPd2FcVrj+E/0OkxyZyUuaCaCp6IQ5 outA==
X-Gm-Message-State: ALyK8tJNv7lTIWs4SDRc9Wm6OYOQ80xJH0DIS0xvFq2CKvLuqXQ5eeOxlGK5ls1GRQ3A5dBxexejK8qVKWbRFw==
MIME-Version: 1.0
X-Received: by 10.55.80.131 with SMTP id e125mr1936469qkb.155.1464159846398; Wed, 25 May 2016 00:04:06 -0700 (PDT)
Received: by 10.55.104.194 with HTTP; Wed, 25 May 2016 00:04:06 -0700 (PDT)
In-Reply-To: <CABvL1xpiMcrtVj=ZCcesxsQJjUBJV23U5zbr5QKPeQDxQadOWg@mail.gmail.com>
References: <DA2216E6-CE23-47A0-AA7A-5E19DAF043AF@ntt-at.com> <CABvL1xrKExY4FXXmNogGKq2=PUd5HtZed09BOW1h33TXE79PNA@mail.gmail.com> <7BE6135D-961D-4D6E-B6FC-99BA27B1B0C4@ntt-at.com> <CABvL1xpiMcrtVj=ZCcesxsQJjUBJV23U5zbr5QKPeQDxQadOWg@mail.gmail.com>
Date: Wed, 25 May 2016 15:04:06 +0800
Message-ID: <CABvL1xoDK4Wisv-Pb+WwsgocOMAWiw32F1XbShDsfF1aHTRT3w@mail.gmail.com>
From: Richard Maher <maherrj@googlemail.com>
To: Shida Schubert <shida@ntt-at.com>
Content-Type: multipart/alternative; boundary="001a114a9ad08a3bab0533a547f1"
Archived-At: <http://mailarchive.ietf.org/arch/msg/webpush/yPaWLSQLcd-diZL6N033Ho1RTSs>
Cc: webpush@ietf.org
Subject: Re: [Webpush] WGLC for draft-ietf-webpush-protocol-05
X-BeenThere: webpush@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussion of potential IETF work on a web push protocol <webpush.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/webpush>, <mailto:webpush-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/webpush/>
List-Post: <mailto:webpush@ietf.org>
List-Help: <mailto:webpush-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/webpush>, <mailto:webpush-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 May 2016 07:04:09 -0000
For those who prefer to pain-by-numbers (see scalability): - https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern And, WRT the payload encryption options, maybe the following is the way to go? Defacto Javascript encryption standard? https://github.com/bitwiseshiftleft/sjcl C# and/or JAVA can encrypt and Javascrypt decrypt. A better solution? On Tue, May 24, 2016 at 8:53 AM, Richard Maher <maherrj@googlemail.com> wrote: > Please see embedded comments: - > > On Tue, May 24, 2016 at 8:03 AM, Shida Schubert <shida@ntt-at.com> wrote: > >> >> Hi Richard; >> >> Thank you for your feedback. >> >> Currently developers need to either deal with different spec/api for each >> of the push notification providers (GCM, Azure, APN etc.) to communicate to >> their subscribers or use third party service (urban airship etc.), which is >> fine for native apps but gets a little more complicated with the browser. >> > > Inconvenient but feature detection is not the end of the world. > > >> The IETF has agreed that we need a standardized protocol for this and >> that’s what we are chartered to work on. >> > > A much better idea especially considering the number of Push Services that > don't happen to also manufacture a browser. But let's get it as > fit-for-purpose and as extensive as we can, eh? How many different > specifications have there been so far dealing with Server Push, Simple > Push, etc. Each time with developers having to deprecate and re-tool :-( > > >> >> As for Broadcasting, from my shallow understanding isn’t it merely the >> same payload sent to set or all of subscribers? >> > > I find that level of naivety astounding in anyone who is involved in > formulation of this standard. Why do you seek to deliberately ignore the > client-based subscription feature where any and all client-to-topic mapping > is maintained solely by the Push Service and where the Application Server > is oblivious to consumers and freed the need for a local mapping database? > The Use-Cases are clear: - Sports results, Weather Updates, Stock Prices, > Security Alerts, just to name a few. The strategy for encrypting an > authenticating the payload/body is also clear(ish): - > https://github.com/slightlyoff/ServiceWorker/issues/901 > > Why do you people continue to say "What elephant?" > > In which case, I believe it can be handled as an implementation matter >> likely at the application side. >> > > For some other use cases, managing subscriptions on the server is indeed > an option. Horses for courses: - > > https://developers.google.com/cloud-messaging/topic-messaging#managing_topic_subscriptions_from_the_server > > > The protocol can be extended at later stage if wg agrees it is something >> that is necessary but I haven’t heard anybody else at the meeting or on the >> mailing list expressing this feature is a show-stopper. >> > > I sorry to appear blunt but if the other members of the cloistered star > chamber that is adjudicating on this are equally ignorant of the business > requirements then there is no surprise they haven't come up with a solution. > > But *please* don't listen to me. Just look at what solutions that are > already in the wild with native apps. Why won't you let HTML5 Web App > developers compete on an even playing field and create Apps that satisfy > these common requirements? > > The MBONE people seem to have made progress over the years and we all know > that your Application Servers with simply be overwhelmed if you tickle > potentially millions of clients so let's get on with the solution? > > >> >> Anyway, I would very much appreciate it, if you can refrain the comments >> to the technical contents of the draft. >> > > Are you telling me that pointing out omissions and scope deficiencies is > not welcomed? > > Either way 5.4 is completely wrong. You've been told. > > >> >> Thanks >> Shida >> >> On May 16, 2016, at 6:50 PM, Richard Maher <maherrj@googlemail.com> >> wrote: >> >> "5.4 Updating Push Messages" is based on the misconception that "Topics" >> are "Collapse Keys". The standard as proposed has been superseded by event >> on the ground by established, successful, and more importantly scalable >> solutions: - >> >> Google Cloud Messaging: - >> https://developers.google.com/cloud-messaging/topic-messaging >> >> Azure Notification Hubs: - >> >> https://blogs.windows.com/buildingapps/2013/09/16/delivering-push-notifications-to-millions-of-devices-with-windows-azure-notification-hubs/ >> >> Whether the Topics are identified via HTTP headers or JSON Tokens is the >> only moot point. What is clear is that the proposed protocol attempts to >> conflate the Topic and Collapse Key features: - >> >> https://developers.google.com/cloud-messaging/concept-options#collapsible_and_non-collapsible_messages >> >> The fact that quintessential Push Notification feature "Broadcasting" has >> been descoped from this protocol must be sufficient to reject the proposal. >> >> Please do not make the same mistake that you made with Geofences. IETF >> and W3C credibility has already suffered enough. >> >> On Tue, May 17, 2016 at 2:32 AM, Shida Schubert <shida@ntt-at.com> wrote: >> >>> All; >>> >>> As discussed at the IETF 95, as last issue surrounding the subscription >>> re-use is addressed, we are starting a Working Group Last Call for the >>> webpush protocol. >>> >>> https://tools.ietf.org/html/draft-ietf-webpush-protocol-05 >>> >>> If you have any issues or questions regarding the draft please submit it >>> to the list, when raising issues please provide constructive resolution >>> when possible. >>> >>> Please acknowledge on the list even when you are content/happy with the >>> status of the draft. >>> >>> The Working Group Last Call will end on June 6th (3 weeks). >>> >>> Shida >>> As co-chair >>> >>> _______________________________________________ >>> Webpush mailing list >>> Webpush@ietf.org >>> https://www.ietf.org/mailman/listinfo/webpush >>> >>> >> _______________________________________________ >> Webpush mailing list >> Webpush@ietf.org >> https://www.ietf.org/mailman/listinfo/webpush >> >> >> >> _______________________________________________ >> Webpush mailing list >> Webpush@ietf.org >> https://www.ietf.org/mailman/listinfo/webpush >> >> >
- [Webpush] WGLC for draft-ietf-webpush-protocol-05 Shida Schubert
- Re: [Webpush] WGLC for draft-ietf-webpush-protoco… Richard Maher
- Re: [Webpush] WGLC for draft-ietf-webpush-protoco… Richard Maher
- Re: [Webpush] WGLC for draft-ietf-webpush-protoco… Shida Schubert
- Re: [Webpush] WGLC for draft-ietf-webpush-protoco… Shida Schubert
- Re: [Webpush] WGLC for draft-ietf-webpush-protoco… Richard Maher
- Re: [Webpush] WGLC for draft-ietf-webpush-protoco… Costin Manolache
- Re: [Webpush] WGLC for draft-ietf-webpush-protoco… Richard Maher
- Re: [Webpush] WGLC for draft-ietf-webpush-protoco… Shida Schubert
- Re: [Webpush] WGLC for draft-ietf-webpush-protoco… Richard Maher
- Re: [Webpush] WGLC for draft-ietf-webpush-protoco… jr conlin
- Re: [Webpush] WGLC for draft-ietf-webpush-protoco… Peter Beverloo
- Re: [Webpush] WGLC for draft-ietf-webpush-protoco… Brian Raymor
- Re: [Webpush] WGLC for draft-ietf-webpush-protoco… JR Conlin
- Re: [Webpush] WGLC for draft-ietf-webpush-protoco… Richard Maher
- Re: [Webpush] WGLC for draft-ietf-webpush-protoco… RUELLAN Herve
- Re: [Webpush] WGLC for draft-ietf-webpush-protoco… Alissa Cooper
- Re: [Webpush] WGLC for draft-ietf-webpush-protoco… Alissa Cooper
- Re: [Webpush] WGLC for draft-ietf-webpush-protoco… Shida Schubert