From nobody Mon May 11 13:31:28 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7EC51B2A49 for ; Mon, 11 May 2015 13:31:27 -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 xkXPKHVLcVBu for ; Mon, 11 May 2015 13:31:26 -0700 (PDT) Received: from mail-yh0-x22e.google.com (mail-yh0-x22e.google.com [IPv6:2607:f8b0:4002:c01::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 196E81B2A47 for ; Mon, 11 May 2015 13:31:26 -0700 (PDT) Received: by yhw29 with SMTP id 29so39674039yhw.1 for ; Mon, 11 May 2015 13:31:25 -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 :content-type; bh=gptK5QDbjZUnbJlaw69M3d+VQxp1xhHc7SJwrEBAags=; b=tJw8ITs3BbReMeDSmzAeFPwvc6d+BLb93upPLy0sLfan3BXVkVieWEHqhj1GKWM5vr fng/OsVh/SYIUgnzDRvjKPQLzh3Hn5lO/j/aIsGrWgxEdOp6UGqpWTuUIiPPnpfvSh/L hOKWpV7MLR/2jryLeEhoOfaQNKX+HjZDAsY+Bnm1a8J5FVvexJpfM+4jgM57yYiJSHX4 fwMIzcTqTAiHb+oWmGe3+Ul0v1EopolBwSSoki9vLrw+jYt8OlYkQhT93slVIJ18Qn3T 02vXs4sqmRJLPVafLqjUZjlXGBmSnmSXQo/oevIe9kR/6HBNw/4kEjSG7fVjRVUG5anE E4hA== MIME-Version: 1.0 X-Received: by 10.236.208.106 with SMTP id p70mr11687275yho.1.1431376285378; Mon, 11 May 2015 13:31:25 -0700 (PDT) Received: by 10.13.247.71 with HTTP; Mon, 11 May 2015 13:31:25 -0700 (PDT) In-Reply-To: <20150511202617.5897.8737.idtracker@ietfa.amsl.com> References: <20150511202617.5897.8737.idtracker@ietfa.amsl.com> Date: Mon, 11 May 2015 13:31:25 -0700 Message-ID: From: Martin Thomson To: "webpush@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Webpush] Fwd: New Version Notification for draft-thomson-http-encryption-00.txt X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 20:31:27 -0000 I've submitted a new version of the draft that proposes encryption for HTTP. ---------- Forwarded message ---------- From: Date: 11 May 2015 at 13:26 Subject: New Version Notification for draft-thomson-http-encryption-00.txt To: Martin Thomson A new version of I-D, draft-thomson-http-encryption-00.txt has been successfully submitted by Martin Thomson and posted to the IETF repository. Name: draft-thomson-http-encryption Revision: 00 Title: Encrypted Content-Encoding for HTTP Document date: 2015-05-11 Group: Individual Submission Pages: 17 URL: https://www.ietf.org/internet-drafts/draft-thomson-http-encryption-00.txt Status: https://datatracker.ietf.org/doc/draft-thomson-http-encryption/ Htmlized: https://tools.ietf.org/html/draft-thomson-http-encryption-00 Abstract: This memo introduces a content-coding for HTTP that allows message payloads to be encrypted. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Tue May 12 10:58:11 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8821A1ACE2F for ; Tue, 12 May 2015 10:58:09 -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 WFN5TmkZksS5 for ; Tue, 12 May 2015 10:58:07 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CFC01ACDEF for ; Tue, 12 May 2015 10:58:07 -0700 (PDT) Received: by igbhj9 with SMTP id hj9so22115105igb.1 for ; Tue, 12 May 2015 10:58:06 -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=87laCPFY+97qvaNyQi7XC9DxG3bkfaDFjciDfXI1ySE=; b=P9B+aiVEniT7WBRkK7jCs7ob3QojqlxmZNh+OF/mzFe2XqYe4xw6S1nrtnarE2mf5d jjjsmBtHnupE7uceNoxlHogdEYDgPvx16o27VwQ77W57Dlr7L1ZrJYmVoC9IzHoCRCbU H/7Gzgd0vX1G+5U8smB/D8OBRvfXLgH1BjlpnMtyIPmlqv+EWo/VDypgcAZ2iWtboU08 hFaRQNVmu29XNFjRTgY4bU5WTOL0PhDtQnYkV5TJdDioX7NOdu9k8RmgZCAcCC2EtVsD wwK/DPhdBpuuz8FPp5+t0hFypal2GvwV35/TTNiKN8CetMsUyjHt7xm2ctduVvsEsNvF Sfmg== MIME-Version: 1.0 X-Received: by 10.42.187.65 with SMTP id cv1mr4521583icb.87.1431453486763; Tue, 12 May 2015 10:58:06 -0700 (PDT) Received: by 10.36.9.207 with HTTP; Tue, 12 May 2015 10:58:06 -0700 (PDT) In-Reply-To: <4AA3A95D6033ED488F8AE4E45F474487455B32A8@CAFRFD1MSGUSRIA.ITServices.sbc.com> References: <20150416000844.29595.68704.idtracker@ietfa.amsl.com> <4AA3A95D6033ED488F8AE4E45F474487455B1E2A@CAFRFD1MSGUSRIA.ITServices.sbc.com> <4AA3A95D6033ED488F8AE4E45F474487455B32A8@CAFRFD1MSGUSRIA.ITServices.sbc.com> Date: Tue, 12 May 2015 10:58:06 -0700 Message-ID: From: Costin Manolache To: "DRUTA, DAN" Content-Type: multipart/alternative; boundary=20cf303ea1029755970515e63ce6 Archived-At: Cc: "Brian Raymor \(MS OPEN TECH\)" , Martin Thomson , "webpush@ietf.org" Subject: Re: [Webpush] FW: New Version Notification for draft-thomson-webpush-protocol-00.txt X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 17:58:09 -0000 --20cf303ea1029755970515e63ce6 Content-Type: text/plain; charset=UTF-8 It is hard to support ordering at scale - we would prefer that ordering is not guaranteed. But we support de-duplication and retries. Costin On Wed, Apr 29, 2015 at 12:24 PM, DRUTA, DAN wrote: > Hi Martin, > > I think we can address the relative priority in the web push draft at > minimum with some clarifications on use cases and some of the requirements. > Much like I tried to explain in my example and you expanded with the device > nap scenario. > If NICE proposal gets support in http WG I don't see any reason to > reinvent the wheel but as of now I believe your draft is expired. > At least we should determine how important of a feature this is. > > Dan > > -----Original Message----- > From: Martin Thomson [mailto:martin.thomson@gmail.com] > Sent: Wednesday, April 29, 2015 11:57 AM > To: DRUTA, DAN > Cc: Brian Raymor (MS OPEN TECH); webpush@ietf.org > Subject: Re: [Webpush] FW: New Version Notification for > draft-thomson-webpush-protocol-00.txt > > On 29 April 2015 at 10:12, DRUTA, DAN wrote: > > 1. Prioritization > [...] > > Is the expectation that the app server will send them in the right > sequence and the push server will use a FIFO (first in first out) queue? > > The draft really doesn't say, partly because we didn't discuss it > much, partly because I think that we'd want some flexibility. I've > opened an issue on this in our issue tracker so that we don't forget > this. > > > Priority is a fairly basic requirement and I hope it can get handled in > a header so it can be consistently enforced by the push service. > > Prioritization is a concern if there are multiple messages to deliver > at the same time. This happens most often when a device comes back > from a short nap (as mobile devices do all the time). With a small > number of messages, this might not be a big deal, but if there is a > backlog to clear, it could be. I have a draft on signaling priorities > that could be used in this context: > https://tools.ietf.org/html/draft-thomson-http-nice-02 > > Do you think that we need to address this in a basic protocol > specification, or can it rely on other specifications. > > > 2. Message deduplication and retries. > > Yes, reliability is hard. The intent is to have the application mark > messages and perform deduplication if it does resending, especially > within the TTL period that the push service promises. > > In terms of the protocol, there is a proposal for message replacement > that might reduce the need for some of this, but Brian, Elio and I > decided that we'd let this draft stabilize before talking about that > feature: https://github.com/unicorn-wg/webpush-protocol/pull/12 > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > --20cf303ea1029755970515e63ce6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It is hard to support ordering at scale - we would prefer = that ordering is not guaranteed.
But we support de-duplication and retr= ies.

Costin

On Wed, Apr 29, 2015 at 12:24 PM, DRUTA,= DAN <dd5826@att.com> wrote:
= Hi Martin,

I think we can address the relative priority in the web push draft at minim= um with some clarifications on use cases and some of the requirements. Much= like I tried to explain in my example and you expanded with the device nap= scenario.
If NICE proposal gets support in http WG I don't see any reason to rein= vent the wheel but as of now I believe your draft is expired.
At least we should determine how important of a feature this is.

Dan

-----Original Message-----
From: Martin Thomson [mailto:ma= rtin.thomson@gmail.com]
Sent: Wednesday, April 29, 2015 11:57 AM
To: DRUTA, DAN
Cc: Brian Raymor (MS OPEN TECH); webpus= h@ietf.org
Subject: Re: [Webpush] FW: New Version Notification for draft-thomson-webpu= sh-protocol-00.txt

On 29 April 2015 at 10:12, DRUTA, DAN <dd5826@att.com> wrote:
> 1. Prioritization
[...]
> Is the expectation that the app server will send them in the right seq= uence and the push server will use a FIFO (first in first out) queue?

The draft really doesn't say, partly because we didn't discuss it much, partly because I think that we'd want some flexibility.=C2=A0 I&#= 39;ve
opened an issue on this in our issue tracker so that we don't forget this.

> Priority is a fairly basic requirement and I hope it can get handled i= n a header so it can be consistently enforced by the push service.

Prioritization is a concern if there are multiple messages to deliver
at the same time.=C2=A0 This happens most often when a device comes back from a short nap (as mobile devices do all the time).=C2=A0 With a small number of messages, this might not be a big deal, but if there is a
backlog to clear, it could be.=C2=A0 I have a draft on signaling priorities=
that could be used in this context:
https://tools.ietf.org/html/draft-thomson-http-nice-02

Do you think that we need to address this in a basic protocol
specification, or can it rely on other specifications.

> 2. Message deduplication and retries.

Yes, reliability is hard.=C2=A0 The intent is to have the application mark<= br> messages and perform deduplication if it does resending, especially
within the TTL period that the push service promises.

In terms of the protocol, there is a proposal for message replacement
that might reduce the need for some of this, but Brian, Elio and I
decided that we'd let this draft stabilize before talking about that feature: https://github.com/unicorn-wg/webpush-protocol/pull/12
_______________________________________________
Webpush mailing list
Webpush@ietf.org
https://www.ietf.org/mailman/listinfo/webpush

--20cf303ea1029755970515e63ce6-- From nobody Tue May 12 11:17:15 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F59C1ACE16 for ; Tue, 12 May 2015 11:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 dO1wI2I_nqjp for ; Tue, 12 May 2015 11:17:10 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (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 534531ACDEB for ; Tue, 12 May 2015 11:17:10 -0700 (PDT) Received: by igbpi8 with SMTP id pi8so100119993igb.0 for ; Tue, 12 May 2015 11:17:09 -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=rk+cFY4h9jnbS8ltAXfs0/3A+4PrpmjvPgc5sLQEgkM=; b=cnPTeiqUc3GwKOlIBpesQyGR//wf5zO1MOaH81DPbLcfNcXKJjapiqteSCNY2MWd0K e7or8vu0C/z/dFQqJF2pTYZvFuaCyE+SPKhIMaHuRbskWkSB0uWneMqPt2U1HoqomF6S IA4gxYudSPTLnk5hrGczgWZBQr4X0wdbZiqmkD3APdP2abxM6yTlkYF4CX5VnoADbprg WN0gRSLwj/2leqX+Hre8mnufMqEuDbIopkCggbQs2xZ8/PoC13i9/l8q8uxS7uP/0UFv /zhgBg/RbyLLKBST+ZaYyR11NfInKoSy7Jg2Y4dscjfPXen5r/piMP0dEfJdJFqhovM6 MPtw== MIME-Version: 1.0 X-Received: by 10.50.79.228 with SMTP id m4mr2232639igx.42.1431454629806; Tue, 12 May 2015 11:17:09 -0700 (PDT) Received: by 10.36.9.207 with HTTP; Tue, 12 May 2015 11:17:09 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 May 2015 11:17:09 -0700 Message-ID: From: Costin Manolache To: Martin Thomson Content-Type: multipart/alternative; boundary=089e013a1f16b8cc6e0515e680e4 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Analysis of performance impact of disaggregation X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 18:17:13 -0000 --089e013a1f16b8cc6e0515e680e4 Content-Type: text/plain; charset=UTF-8 I missed this email - I want to clarify that the main cost (for us) is the lookups we have to do at connect time. Aggregation means there is one RT to the database, hitting a single "row". Costin On Wed, Apr 1, 2015 at 4:18 PM, Martin Thomson wrote: > One of the concerns raised about Microsoft's disaggregation proposal > was the performance impact it implies. Since connections and the > state tied to them is volatile state, being able to efficiently repair > that state could be important. Maybe some numbers might help here, > even if they are rough and based on some speculation. > > For a server that chooses to operate as proposed and provide > independent subscriptions, this means that clients need to tell the > server about every subscription they are interested in after a > connection is restored. > > If I'm right about this much, the choice over whether disaggregation > or aggregation is largely driven by costs at this point. That means > understanding the costs. > > ## Costs for aggregation > > An aggregating server needs a way to identify all undelivered messages > across all subscriptions for the registration. > > I originally envisaged an architecture where this is done by > aggregating messages into a single persistent store that was common > across the registration. This reduces the cost of session restoration > to connection establishment, plus one request, and then a database > lookup. > > An aggregate on push design like this doesn't necessarily require a > server to explicitly maintain a list of subscriptions for a > registration, servers only need a way to identify the registration > based on the subscription URL. I can go into more detail on how that > might work if people don't think this is possible. > > Elio pointed out that their delivery architecture kept subscriptions > independent of each other and that aggregation would force them to > store additional information identifying active subscriptions. > That is, aggregate on pull. > > Session restoration for an aggregate-on-pull architecture would entail > querying the registration store, then querying each of the listed > subscriptions independently. Obviously, that imposes additional state > management overhead on the server, as well as having the cost and > delay of querying each subscription once the connection is online. > The only cost to the user agent is a potential delay in message > delivery after a connection break. > > ## Costs for disaggregation > > A server without any aggregation doesn't need to maintain any > information about the correlation of subscriptions. So the concerns > raised about aggregation are ameliorated. > > The cost here is in the time that it takes to tell the server about > all of the different subscriptions you are interested in. In HTTP/2, > that is largely driven by the size of the path component of the URL, > the rest can be aggressively compressed down to a handful of bytes > (let's say 16, including the frame header). I'm assuming the absence > of bearer tokens for authentication, which might be used here at a > significantly increased cost in bytes. > > The big latency cost comes in when the size of requests exceeds the > TCP CWND, which is probably still small at this point. Assuming TLS > false start, that CWND is shared with the TLS CCS and Finished and the > HTTP/2 preface, which might amount to 100 bytes total. > > The dominant factors here are therefore how many subscriptions and how > long is the URL for each. Here's where the assumptions start to build > up. > > I don't have good stats on this, but I'm going to suggest that you > might want to have 100 subscriptions active without performance > degradation (I expect the real number to be much lower than this in > practice, but outliers are where complaints originate). > > URLs can be quite long, depending on what is packed into them. > Microsoft documentation > (https://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh868252.aspx) > shows an example with a 159 octet path. > > If that length is representative, 100 subscriptions will consume 17.5k > plus overheads. Transmitting that data takes an insignificant amount > of time, but that amount exceeds the CWND for the second round trip of > TCP on common MSS values short of INIT_CWND 7. If the CWND is > exceeded, then it takes an additional round trip to complete the > setup. The example also includes a 62 byte bearer token sent by the > application server; I don't know if that is needed here or not for the > user agent. > > I don't know what the current status is, but last time I checked > INIT_CWND 4 was the value that was in widespread use. That means less > than 64 subscriptions. > > If you wanted to be quite aggressive about reducing the size of the > path and are able to make some architectural changes, it should be > quite feasible to construct a subscription path that is only 45 > characters in base64. At that point, I think that we can discount the > CWND issue. > > ## Allowing choice > > I think that I'd be disappointed if we allowed the push service to > pick here. That makes it harder to build a single client. But it > might be OK given the need for some sort of prior relationship with > the push service for authentication purposes. I don't think that this > is accepting the judgment of solomon, but I think we need to consider > the complexity costs of that option. > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > --089e013a1f16b8cc6e0515e680e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I missed this email - I want to clarify that the main cost= (for us) is the=C2=A0
lookups we have to do at connect time. Aggregati= on means there is=C2=A0
one RT to the database, hitting a single = "row".=C2=A0


Costin
=



On Wed, Apr 1, 2015 at 4:18 PM, Martin Thomson <= martin.thomson@gmail.com> wrote:
One of the concerns raised about Microsoft's disaggregation propo= sal
was the performance impact it implies.=C2=A0 Since connections and the
state tied to them is volatile state, being able to efficiently repair
that state could be important.=C2=A0 Maybe some numbers might help here, even if they are rough and based on some speculation.

For a server that chooses to operate as proposed and provide
independent subscriptions, this means that clients need to tell the
server about every subscription they are interested in after a
connection is restored.

If I'm right about this much, the choice over whether disaggregation or aggregation is largely driven by costs at this point.=C2=A0 That means understanding the costs.

## Costs for aggregation

An aggregating server needs a way to identify all undelivered messages
across all subscriptions for the registration.

I originally envisaged an architecture where this is done by
aggregating messages into a single persistent store that was common
across the registration.=C2=A0 This reduces the cost of session restoration=
to connection establishment, plus one request, and then a database
lookup.

An aggregate on push design like this doesn't necessarily require a
server to explicitly maintain a list of subscriptions for a
registration, servers only need a way to identify the registration
based on the subscription URL.=C2=A0 I can go into more detail on how that<= br> might work if people don't think this is possible.

Elio pointed out that their delivery architecture kept subscriptions
independent of each other and that aggregation would force them to
store additional information identifying active subscriptions.
That is, aggregate on pull.

Session restoration for an aggregate-on-pull architecture would entail
querying the registration store, then querying each of the listed
subscriptions independently.=C2=A0 Obviously, that imposes additional state=
management overhead on the server, as well as having the cost and
delay of querying each subscription once the connection is online.
The only cost to the user agent is a potential delay in message
delivery after a connection break.

## Costs for disaggregation

A server without any aggregation doesn't need to maintain any
information about the correlation of subscriptions.=C2=A0 So the concerns raised about aggregation are ameliorated.

The cost here is in the time that it takes to tell the server about
all of the different subscriptions you are interested in.=C2=A0 In HTTP/2,<= br> that is largely driven by the size of the path component of the URL,
the rest can be aggressively compressed down to a handful of bytes
(let's say 16, including the frame header).=C2=A0 I'm assuming the = absence
of bearer tokens for authentication, which might be used here at a
significantly increased cost in bytes.

The big latency cost comes in when the size of requests exceeds the
TCP CWND, which is probably still small at this point.=C2=A0 Assuming TLS false start, that CWND is shared with the TLS CCS and Finished and the
HTTP/2 preface, which might amount to 100 bytes total.

The dominant factors here are therefore how many subscriptions and how
long is the URL for each.=C2=A0 Here's where the assumptions start to b= uild
up.

I don't have good stats on this, but I'm going to suggest that you<= br> might want to have 100 subscriptions active without performance
degradation (I expect the real number to be much lower than this in
practice, but outliers are where complaints originate).

URLs can be quite long, depending on what is packed into them.
Microsoft documentation
(https://msdn.microsoft.com/en-us/library/windo= ws/apps/xaml/hh868252.aspx)
shows an example with a 159 octet path.

If that length is representative, 100 subscriptions will consume 17.5k
plus overheads.=C2=A0 Transmitting that data takes an insignificant amount<= br> of time, but that amount exceeds the CWND for the second round trip of
TCP on common MSS values short of INIT_CWND 7.=C2=A0 If the CWND is
exceeded, then it takes an additional round trip to complete the
setup.=C2=A0 The example also includes a 62 byte bearer token sent by the application server; I don't know if that is needed here or not for the<= br> user agent.

I don't know what the current status is, but last time I checked
INIT_CWND 4 was the value that was in widespread use.=C2=A0 That means less=
than 64 subscriptions.

If you wanted to be quite aggressive about reducing the size of the
path and are able to make some architectural changes, it should be
quite feasible to construct a subscription path that is only 45
characters in base64.=C2=A0 At that point, I think that we can discount the=
CWND issue.

## Allowing choice

I think that I'd be disappointed if we allowed the push service to
pick here. That makes it harder to build a single client.=C2=A0 But it
might be OK given the need for some sort of prior relationship with
the push service for authentication purposes.=C2=A0 I don't think that = this
is accepting the judgment of solomon, but I think we need to consider
the complexity costs of that option.

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

--089e013a1f16b8cc6e0515e680e4-- From nobody Tue May 12 12:27:58 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8A51ACEA5 for ; Tue, 12 May 2015 12:27:54 -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 CuKJnEM1Kswa for ; Tue, 12 May 2015 12:27:51 -0700 (PDT) Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE5C61ACEA4 for ; Tue, 12 May 2015 12:27:50 -0700 (PDT) Received: by yhda23 with SMTP id a23so6391332yhd.2 for ; Tue, 12 May 2015 12:27:50 -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=1A5MHizLvurKwxUeDYkRXXJnhnw05wlwVs26WjXga3c=; b=il5Q9DFkFWZKJvvG+e2BCtFZ5xfdaUE89QULTPFqFOBZ0tFcyfWX812FJyq0SX0FSE eHwGyAMCi6LEP85Npm0kFy75KG3z1wQLCpQObLac0kCWWTJH8BpIOhLs0pAOthoJZl2Y 0xD5HEokRyeF3/NCOeElwtzPIo4oM/4JTbQfhS4t5Prft9UzHc9Kn42BtkBhOcV4L2Iu g9Dv7AFPz03rUfxmPSDglR8F1hIVazPnpnOEjOBnsUmQ4QOfOJPK709JiTQGDFcYt3oQ MmlLFFrEE1i/S7jflmrlNqthZ1JLQVUBSpVURTUASPqp4HXTvfLzjw1ZHaLH1Jo8ZXP/ bh4g== MIME-Version: 1.0 X-Received: by 10.236.106.74 with SMTP id l50mr16793730yhg.143.1431458870275; Tue, 12 May 2015 12:27:50 -0700 (PDT) Received: by 10.13.247.71 with HTTP; Tue, 12 May 2015 12:27:50 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 May 2015 12:27:50 -0700 Message-ID: From: Martin Thomson To: Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Analysis of performance impact of disaggregation X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 19:27:54 -0000 On 12 May 2015 at 11:17, Costin Manolache wrote: > I missed this email - I want to clarify that the main cost (for us) is the > lookups we have to do at connect time. Aggregation means there is > one RT to the database, hitting a single "row". I suspect that this is going to be the common mode: some sort of aggregation here saves a lot of effort. Do you have any data to support the idea that connection-related costs are worth keeping down? For instance, the number of reconnects you see per hour as a proportion of the user base, or anything like that. I don't want to ask if it might be proprietary though. From nobody Fri May 15 16:12:43 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF871A8A20 for ; Fri, 15 May 2015 16:12:42 -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 yO42T9GNgn-K for ; Fri, 15 May 2015 16:12:41 -0700 (PDT) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 323301A1B9A for ; Fri, 15 May 2015 16:12:41 -0700 (PDT) Received: by ykec202 with SMTP id c202so38559075yke.2 for ; Fri, 15 May 2015 16:12:40 -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=iPkl2BwzKYpbkAPyxFp0C6oeQipNppe7t+KPFtRBDMc=; b=W6txPUSzX950O0bjTbontALRV19CQ8m9+UsXpye3BMY7GXtp9ZhMVaBa15L2UhkyXL Hgu15bzYh2wWTdYZrkcq9UOV/JQ/BO26EvRaKz4LAMFKgJJg2ZKIciZ3gGyZd7CYNynL ROiO322z4HGVC542pH2m6yaxTFVesjNtPKcDXceKzduIU5rYR+fwgrhP5DqP0+EsgMKn 9NRRnbw/pLHVX/5m+lXhz6NmtcS5G4xgV8KnN6TfSJSahqw3M68lRw0+X9NKsUgP3eAH e67WtEeGViB8K7mLfKJPK/LIuekFIfEO+AM50KGWsQb7rg+mLlxxCgPJJ/mMmHvG4nhN wdWg== MIME-Version: 1.0 X-Received: by 10.236.20.230 with SMTP id p66mr11721162yhp.181.1431731560605; Fri, 15 May 2015 16:12:40 -0700 (PDT) Received: by 10.13.247.71 with HTTP; Fri, 15 May 2015 16:12:40 -0700 (PDT) In-Reply-To: References: <20150416000844.29595.68704.idtracker@ietfa.amsl.com> <4AA3A95D6033ED488F8AE4E45F474487455B1E2A@CAFRFD1MSGUSRIA.ITServices.sbc.com> <4AA3A95D6033ED488F8AE4E45F474487455B32A8@CAFRFD1MSGUSRIA.ITServices.sbc.com> Date: Fri, 15 May 2015 16:12:40 -0700 Message-ID: From: Martin Thomson To: Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "DRUTA, DAN" , "Brian Raymor \(MS OPEN TECH\)" , "webpush@ietf.org" Subject: Re: [Webpush] FW: New Version Notification for draft-thomson-webpush-protocol-00.txt X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 23:12:42 -0000 On 12 May 2015 at 10:58, Costin Manolache wrote: > It is hard to support ordering at scale - we would prefer that ordering is > not guaranteed. > But we support de-duplication and retries. I don't think that any proposal has actually *required* a specific ordering. What the nice proposal suggests is that different policies be adopted with respect to waking idle devices. Ordering might be possible. Either way, the effort would be entirely voluntary: prioritization indicates what an application wants, which might correspond to superior performance if the push service could respect that value, but ultimately nothing should break if priority is ignored. We also have to recognize that applications will sometimes (often?) act in their own self-interest and that their prioritization choices might not be chosen with global optimization in mind. I think that de-dupe and retries are orthogonal to this. From nobody Fri May 15 19:07:59 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 008311ACE6A for ; Fri, 15 May 2015 19:07:58 -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 gwBekRzcI-HA for ; Fri, 15 May 2015 19:07:55 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (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 B491D1ACE96 for ; Fri, 15 May 2015 19:07:50 -0700 (PDT) Received: by iesa3 with SMTP id a3so48177221ies.2 for ; Fri, 15 May 2015 19:07:50 -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=JaBXFAaxc16kDKzHyR4GcqP24tze4FTGlqYUo0DlnrA=; b=I2Yzy+36jdQc5CPrrlgXnk+SGFnOUcG2PIx5ck/OiRCEGRcNANTGk2Ouh+dv6xzJJs 0W1vQkcN9XfJK1WziWAQWOPRM1rtDUmZwsIh28PAhWA5wZRWoQnoKbekK6sn5prEN7NU dC3VkOaq0y0JaKNCW+VeJINmz0Bev4k6DwkJqeS7J5yp1y0aLfyzAtjnDE5hwpg+FJ+c EoTv/I4NLfKqEfe4UiaZeuIOpMrAL2vIRl4l1j1kPPN8PV8KxuWeBa9dRB3gI9RcuVYC 0MQme+0ePUXUzvoRTahXsfzoruHsehCDr8bEv/gox4Y22/rH577P65uZycfnfqJRfk9t oOWg== MIME-Version: 1.0 X-Received: by 10.50.79.202 with SMTP id l10mr259315igx.7.1431742070004; Fri, 15 May 2015 19:07:50 -0700 (PDT) Received: by 10.36.9.207 with HTTP; Fri, 15 May 2015 19:07:49 -0700 (PDT) In-Reply-To: References: <20150416000844.29595.68704.idtracker@ietfa.amsl.com> <4AA3A95D6033ED488F8AE4E45F474487455B1E2A@CAFRFD1MSGUSRIA.ITServices.sbc.com> <4AA3A95D6033ED488F8AE4E45F474487455B32A8@CAFRFD1MSGUSRIA.ITServices.sbc.com> Date: Fri, 15 May 2015 19:07:49 -0700 Message-ID: From: Costin Manolache To: Martin Thomson Content-Type: multipart/alternative; boundary=089e0122aaee7e22b30516296d66 Archived-At: Cc: "DRUTA, DAN" , "Brian Raymor \(MS OPEN TECH\)" , "webpush@ietf.org" Subject: Re: [Webpush] FW: New Version Notification for draft-thomson-webpush-protocol-00.txt X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 02:07:58 -0000 --089e0122aaee7e22b30516296d66 Content-Type: text/plain; charset=UTF-8 Agreed, having priority is good at least to indicate relative importance of different messages from the same app. If the app is on a battery-powered device - we may use the priority to decide if we'll wake up the device or it can be delayed a bit. Costin On Fri, May 15, 2015 at 4:12 PM, Martin Thomson wrote: > On 12 May 2015 at 10:58, Costin Manolache wrote: > > It is hard to support ordering at scale - we would prefer that ordering > is > > not guaranteed. > > But we support de-duplication and retries. > > I don't think that any proposal has actually *required* a specific > ordering. What the nice proposal suggests is that different policies > be adopted with respect to waking idle devices. > > Ordering might be possible. Either way, the effort would be entirely > voluntary: prioritization indicates what an application wants, which > might correspond to superior performance if the push service could > respect that value, but ultimately nothing should break if priority is > ignored. We also have to recognize that applications will sometimes > (often?) act in their own self-interest and that their prioritization > choices might not be chosen with global optimization in mind. > > I think that de-dupe and retries are orthogonal to this. > --089e0122aaee7e22b30516296d66 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agreed, having priority is good at least to indicate relat= ive importance of different messages=C2=A0
from the same app. If the ap= p is on a battery-powered device - we may use the priority to=C2=A0
decide if we'll wake up the device or it can be delayed a bit.=C2=A0=

Costin

=
On Fri, May 15, 2015 at 4:12 PM, Martin Thomson = <martin.thomson@gmail.com> wrote:
On 12 May 2015 at 10:58, Costin Manolache &= lt;costin@gmail.com> wrote:
> It is hard to support ordering at scale - we would prefer that orderin= g is
> not guaranteed.
> But we support de-duplication and retries.

I don't think that any proposal has actually *required* a specif= ic
ordering.=C2=A0 What the nice proposal suggests is that different policies<= br> be adopted with respect to waking idle devices.

Ordering might be possible. Either way, the effort would be entirely
voluntary: prioritization indicates what an application wants, which
might correspond to superior performance if the push service could
respect that value, but ultimately nothing should break if priority is
ignored.=C2=A0 We also have to recognize that applications will sometimes (often?) act in their own self-interest and that their prioritization
choices might not be chosen with global optimization in mind.

I think that de-dupe and retries are orthogonal to this.

--089e0122aaee7e22b30516296d66-- From jconlin@mozilla.com Tue May 26 09:57:24 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB2B11A92FD for ; Tue, 26 May 2015 09:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyihJYn4UGRk for ; Tue, 26 May 2015 09:57:21 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E968D1A1A72 for ; Tue, 26 May 2015 09:57:20 -0700 (PDT) Received: by paza2 with SMTP id a2so87860301paz.3 for ; Tue, 26 May 2015 09:57:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:organization:to:message-id:date :user-agent:mime-version:content-type:content-transfer-encoding; bh=7BK89r6wB65lK13/nx8fcyfL5MVtzZ+a4/ADrPNnUiA=; b=em0zPAvRRW6IYoa/wUV6f6aQraZkDaRxIckYYEvqQk7KTrr0xgtrhiFWii+o7goU+5 184mZ/nsclnKoBUh2XuZmGsrmHcb2S3jJe5NBKt6VsY2RMcowSdyq0fAMgc92ViBd9ye jbYJ/MrwC8RDt6FjTw8f1Uj9YwzaogYT12mS7vgUxYjB+98Lo1SF9Fk6yCKWerWmjskE gTC+N4RKYYk316nnIr0yaXjHnLKHetuR9o7E47UieqUByJdFxvYqBYFOihZ0uQmqHUL6 7AhdkvXrMGDB7OFpdEHkY0Kl50+rK3rgZoL5wnVO7CgIqqm8ErvGhcpF1vr5q4iWbawe wbUg== X-Gm-Message-State: ALoCoQkxrsjV45bO+U3DtaApKbHeTaQMEfNTI0kCh62Bq+plQPUSwIfF+c44FUESdZ0skd/wndt1 X-Received: by 10.68.218.9 with SMTP id pc9mr32362509pbc.2.1432659440435; Tue, 26 May 2015 09:57:20 -0700 (PDT) Received: from ?IPv6:2620:101:80fc:224:2134:ad21:67a:6274? ([2620:101:80fc:224:2134:ad21:67a:6274]) by mx.google.com with ESMTPSA id q5sm8161770pde.56.2015.05.26.09.57.19 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 May 2015 09:57:19 -0700 (PDT) From: JR Conlin X-Google-Original-From: JR Conlin X-Enigmail-Draft-Status: N1110 Organization: mozilla To: webpush@ietf.org Message-ID: <5564A5F0.1040504@mozilla.com> Date: Tue, 26 May 2015 09:57:20 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:40.0) Gecko/20100101 Thunderbird/40.0a2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Tue, 26 May 2015 17:32:37 -0700 Subject: [Webpush] Guidance requested for Cross protocol bridging 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, 26 May 2015 16:58:19 -0000 In order to reduce battery requirements on mobile devices, it's often preferable to use existing messaging architectures for notification delivery. As an example, Google Cloud Messaging (GCM) maintains a proprietary connection between their servers and remote android devices. It would be wasteful for applications to maintain a separate, long lived connection back to a different server, since this connection might mean that the device CPU or network runs more often that the native connection. One approach is that a remote device pass a bridge descriptor object attached to the initial subscription request which contains device specific information. For instance, the object could contain the preferred protocol, the local device ID required by GCM and any other device specific information that might be required to use the proprietary bridge network. This bridge descriptor may be common among subscription requests. The server then stores this information for the device. When the server receives a new push message delivery request, it wraps the request data to fit the proprietary bridge system requirements and sends the event to the device. An app on the device would then process the incoming bridged data and distribute it as if it was carried by HTTP2. The server could return a 202 response to indicate that the message was "handed off" to a bridge system. It's also possible for the push system to "fall back" to HTTP2 if the proprietary bridge fails, but there are still unresolved issues around how the client might detect that a proprietary bridge has failed. There are many benefits to such an approach: * Reduced device battery requirements * Wider device support for Push provider systems * Push availability on legacy systems that may not yet support the Push standard. * "Seamless" cross-notification system support for app developers. * etc. There are also significant drawbacks, the largest being that it is dependent on support by bridge providers. Is this a reasonable approach? From kcambridge@mozilla.com Tue May 26 18:35:00 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC3E1B33A3 for ; Tue, 26 May 2015 18:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCuHFkYRRiNh for ; Tue, 26 May 2015 18:34:56 -0700 (PDT) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) (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 B378D1B33A1 for ; Tue, 26 May 2015 18:34:56 -0700 (PDT) Received: by pabru16 with SMTP id ru16so105872662pab.1 for ; Tue, 26 May 2015 18:34:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=oRARS+lzcDOnZESfJBvinpxcMd1Jbg4Ns1vMGJc33dc=; b=nOQKK4i2MJwNdTATVtRdRLrpS35ujku1Ug/jQ7nyxM7uGL29jDgk0/IttEgMw9pXnN iwSJeKekW12om2zaiBsY9k/bb4z30IE02834a6aM+cfdHNLUCxVW+H8rvAiOIs+wZFfk KuASztQzHhfG0zbnFgtMdkYMurD/xynw2qWsBJ5WXQ9KPvVUJ0KapQQF1D5TmeMT19gn YP6tohSU0/8NHDE7CC+bqKZ5eETsuTAlzLS2sSeSBOaswY71QhecqCMugxs7cDzmPdZk pNpiJGmiEvgsAKgZQs+wBla+fkiP6K356CI6NAs3az2Vn7X27MNxFPdfeKdr5KWrvT3M 5hAA== X-Gm-Message-State: ALoCoQlaEJqqPg9nAKc8VCVfXzy8YDY6/SwL79C1JrJHGOnM2IK1tBQD3Sw9n/6JcZa9k8SHRs49 X-Received: by 10.66.140.36 with SMTP id rd4mr53891661pab.109.1432690496256; Tue, 26 May 2015 18:34:56 -0700 (PDT) Received: from [10.252.27.239] (corp.mtv2.mozilla.com. [63.245.221.32]) by mx.google.com with ESMTPSA id h11sm8491440pdj.27.2015.05.26.18.34.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 May 2015 18:34:55 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Kit Cambridge In-Reply-To: <5564A5F0.1040504@mozilla.com> Date: Tue, 26 May 2015 18:34:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <819B2E60-DED0-4DE8-B1F9-AFDDA6F00A0A@mozilla.com> References: <5564A5F0.1040504@mozilla.com> To: JR Conlin X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: webpush@ietf.org Subject: Re: [Webpush] Guidance requested for Cross protocol bridging 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, 27 May 2015 01:35:58 -0000 On May 26, 2015, at 9:57 AM, JR Conlin wrote: > One approach is that a remote device pass a bridge descriptor object > attached to the initial subscription request which contains device > specific information. For instance, the object could contain the > preferred protocol, the local device ID required by GCM and any other > device specific information that might be required to use the > proprietary bridge network. This bridge descriptor may be common among > subscription requests. I like this approach. More concretely, the client could negotiate the proprietary mechanism by including a header (e.g., `Push-Protocol`) when it creates the subscription=97leaving the request body reserved for the descriptor, outside the scope of the spec. The server then replies with a `Push-Protocol` header containing the accepted mechanism. > The server then stores this information for the device. When the = server > receives a new push message delivery request, it wraps the request = data > to fit the proprietary bridge system requirements and sends the event = to > the device. An app on the device would then process the incoming = bridged > data and distribute it as if it was carried by HTTP2. The server could > return a 202 response to indicate that the message was "handed off" to = a > bridge system. This has implications for other app server interactions, too=97specifically around receipts, message collapsing, and TTLs. Collapsing could be equivalent to sending a new message (which https://github.com/unicorn-wg/webpush-protocol/pull/12 already recommends), but the proprietary bridge might not honor the requested TTL, or may not send feedback when the message is accepted. We could just reinforce that acks aren't reliable to begin with, or implementations can refuse to create receipt subscriptions when the app server POSTs to the receipt subscribe endpoint. But definitely something to think about. > It's also possible for the push system to "fall back" to HTTP2 if the > proprietary bridge fails, but there are still unresolved issues around > how the client might detect that a proprietary bridge has failed. One possibility is that the push server stores the message if delivery via the bridge fails. The client can then include `Prefer: wait=3D0` when it GETs the subscription to pick up any missed messages. But that still requires the client to somehow discover that = the bridge is down. How would you handle this if you were coding against GCM (or another bridged service) directly? Would your app (client) need to periodically poll your app server for messages it might have missed? From nobody Wed May 27 10:42:13 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 308FA1A8905 for ; Wed, 27 May 2015 10:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ir0LMCu-OZmY for ; Wed, 27 May 2015 10:42:08 -0700 (PDT) Received: from mail-pd0-f177.google.com (mail-pd0-f177.google.com [209.85.192.177]) (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 327471A8903 for ; Wed, 27 May 2015 10:42:08 -0700 (PDT) Received: by pdbqa5 with SMTP id qa5so22085577pdb.0 for ; Wed, 27 May 2015 10:42:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=p0PNaQ7WTQKk7waOtRhSUWi3P9XjeNy6O9NkcnhkSk0=; b=OeR0iRouWfbUOvvynQrctHDCYd8pujzT+X3oJnjxrfVX5F6Q/BskPxAtzB8m3XuqCj C5EAdJ/dsctikRZPOGvH3layEKY3pjj26k57QBrJsMU4SZvxpYPiLYkkfIEueIE8hKxk 9ocTEUO4m/EEIbU2T+aiRvT1n7ADVjRxd4XmDrW6p4m+h92MPjfzWHwS0a3tU6LQ1KQ1 ZmfdQAkswCleTy+0FMJ5i7YCkc1bQLsbnK6na4CpYOGU5cIoVe0gCurNraZksTeo2J3S 14gEki3fo7vZCRezw1Ux5sXBSEuIbk1wDxTpyYrbDO6NVkoP+/vlGMbAhDBPttYZxye2 VyCw== X-Gm-Message-State: ALoCoQk7Gl9XNflrWyyKdiRHAGu5Eufwx2OqTQuO1USWM06Nzu23uS1qXkdmBU2lDGJuA9GRDzAS X-Received: by 10.70.94.167 with SMTP id dd7mr43318020pdb.115.1432748527487; Wed, 27 May 2015 10:42:07 -0700 (PDT) Received: from ?IPv6:2620:101:80fc:224:f4ed:75cf:1d5f:93c? ([2620:101:80fc:224:f4ed:75cf:1d5f:93c]) by mx.google.com with ESMTPSA id c16sm16848322pdl.61.2015.05.27.10.42.06 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 May 2015 10:42:06 -0700 (PDT) From: jr conlin To: Kit Cambridge , webpush@ietf.org References: <5564A5F0.1040504@mozilla.com> <819B2E60-DED0-4DE8-B1F9-AFDDA6F00A0A@mozilla.com> X-Enigmail-Draft-Status: N1110 Message-ID: <556601EF.2060007@mozilla.com> Date: Wed, 27 May 2015 10:42:07 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:40.0) Gecko/20100101 Thunderbird/40.0a2 MIME-Version: 1.0 In-Reply-To: <819B2E60-DED0-4DE8-B1F9-AFDDA6F00A0A@mozilla.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Webpush] Guidance requested for Cross protocol bridging 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, 27 May 2015 17:42:12 -0000 On 5/26/2015 6:34 PM, Kit Cambridge wrote: > On May 26, 2015, at 9:57 AM, JR Conlin wrote: > >> One approach is that a remote device pass a bridge descriptor object >> attached to the initial subscription request which contains device >> specific information. For instance, the object could contain the >> preferred protocol, the local device ID required by GCM and any other >> device specific information that might be required to use the >> proprietary bridge network. This bridge descriptor may be common among >> subscription requests. > I like this approach. More concretely, the client could negotiate the > proprietary mechanism by including a header (e.g., `Push-Protocol`) > when it creates the subscription—leaving the request body reserved for > the descriptor, outside the scope of the spec. The server then replies > with a `Push-Protocol` header containing the accepted mechanism. > >> The server then stores this information for the device. When the server >> receives a new push message delivery request, it wraps the request data >> to fit the proprietary bridge system requirements and sends the event to >> the device. An app on the device would then process the incoming bridged >> data and distribute it as if it was carried by HTTP2. The server could >> return a 202 response to indicate that the message was "handed off" to a >> bridge system. > This has implications for other app server interactions, > too—specifically around receipts, message collapsing, and TTLs. > Collapsing could be equivalent to sending a new message (which > https://github.com/unicorn-wg/webpush-protocol/pull/12 already > recommends), but the proprietary bridge might not honor the requested > TTL, or may not send feedback when the message is accepted. > > We could just reinforce that acks aren't reliable to begin with, or > implementations can refuse to create receipt subscriptions when the > app server POSTs to the receipt subscribe endpoint. But definitely > something to think about. My simplest explanation is that Notifications bear passing resemblance to email. Granted, with SMTP, message failures are asynchronously reported back to the user. This is not something that we currently allow. (Likewise, I think that having the concept of an "open relay" would probably be recognized as a horrible idea.) Likewise, not all bridge systems will have a reporting mechanism. Some systems may be more "Fire and Forget", where delivery may not be fully guaranteed either. I think the best we can offer is to report that a message has been successfully submitted to a relay system. If our bridge system is feeling generous, it may report failures for "closed" channels (where a bridge system has since reported a final recipient has permanently closed their endpoint, if that's available). > >> It's also possible for the push system to "fall back" to HTTP2 if the >> proprietary bridge fails, but there are still unresolved issues around >> how the client might detect that a proprietary bridge has failed. > One possibility is that the push server stores the message if > delivery via the bridge fails. The client can then include > `Prefer: wait=0` when it GETs the subscription to pick up any missed > messages. But that still requires the client to somehow discover that the > bridge is down. > > How would you handle this if you were coding against GCM (or another > bridged service) directly? Would your app (client) need to periodically > poll your app server for messages it might have missed? These seem to be bridge dependent, but most systems have a "registration check" event that usually happens during app initialization. This check returns either a token value to the app that needs to be reported back to the remote app server, or an error. A similar approach could be established for WebPush, where the client polls the remote server on re-initialization to get a bridge status. For "longer lived" apps (say, an app that may be running on a desktop or dedicated device that may not experience daily re-initialization), it probably should perform this function on some sort of fuzzed clock. Obviously, there's a stampeding herd problem should these become a significant percentage of the population, but it may be possible to offload this check onto a secondary system that reports status and any pending, undelivered notification events. I am, however, quite open to better ideas. From nobody Wed May 27 14:45:24 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 629EF1ACCF4 for ; Wed, 27 May 2015 14:45:23 -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 E3afSuh8LvyB for ; Wed, 27 May 2015 14:45:21 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (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 BB5BF1ACCED for ; Wed, 27 May 2015 14:45:20 -0700 (PDT) Received: by igbpi8 with SMTP id pi8so98393189igb.0 for ; Wed, 27 May 2015 14:45:20 -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=lXp3/Zb/NHBVkt/JIwyWZdkXvVFPOOBBTg1ScP+bWtw=; b=MoCXsXEidbfShXNIgEeiGtBXS7ShmLa31q+MuyeOfE1MVLvHjqs4jhbOBJPpHararr typXfcPgbLIFstJndQMKCtrqHaMQdPTpXY2z5AualrQtUDrMEJT2I6+JQEiWtHmCCMJx i6540rRNVLIGZ66bQ6nxFBG8W9BybgHciudagITbDsqukfS2txTHYnkf9uUcUfc31eAf NlAFN5foOYIWT3d9+1LNfLPfpl2a4VFf5Ys7nn7NvEqgrIhkDdcQVJPfNdgyEucZ+xtg RW0z+/PRyCKp5JT3LExS6L+JfnyBPvgLoOSq6xzc/eCtTvfIoC/H/njjYBODr8RYX0Y0 8szw== MIME-Version: 1.0 X-Received: by 10.50.27.6 with SMTP id p6mr39738535igg.46.1432763119893; Wed, 27 May 2015 14:45:19 -0700 (PDT) Received: by 10.36.9.207 with HTTP; Wed, 27 May 2015 14:45:19 -0700 (PDT) In-Reply-To: <5564A5F0.1040504@mozilla.com> References: <5564A5F0.1040504@mozilla.com> Date: Wed, 27 May 2015 14:45:19 -0700 Message-ID: From: Costin Manolache To: JR Conlin Content-Type: multipart/alternative; boundary=047d7b10ce47cf05540517172842 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Guidance requested for Cross protocol bridging 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, 27 May 2015 21:45:23 -0000 --047d7b10ce47cf05540517172842 Content-Type: text/plain; charset=UTF-8 On Tue, May 26, 2015 at 9:57 AM, JR Conlin wrote: > In order to reduce battery requirements on mobile devices, it's often > preferable to use existing messaging architectures for notification > delivery. As an example, Google Cloud Messaging (GCM) maintains a > proprietary connection between their servers and remote android devices. > It would be wasteful for applications to maintain a separate, long lived > connection back to a different server, since this connection might mean > that the device CPU or network runs more often that the native connection. > Strongly agreed :-) > > One approach is that a remote device pass a bridge descriptor object > attached to the initial subscription request which contains device > specific information. For instance, the object could contain the > preferred protocol, the local device ID required by GCM and any other > device specific information that might be required to use the > proprietary bridge network. This bridge descriptor may be common among > subscription requests. > I think it would be even cleaner if GCM would return a regular webpush subscription ( i.e. capability URL ), so the app can use the same send protocol. The main issue is that GCM requires a separate authentication/registration. We have several options we're exploring to make it smoother, but I don't think we can drop the requirement to authenticate/authorize all senders, and this will apply to the webpush endpoint as well. > > The server then stores this information for the device. When the server > receives a new push message delivery request, it wraps the request data > to fit the proprietary bridge system requirements and sends the event to > the device. An app on the device would then process the incoming bridged > data and distribute it as if it was carried by HTTP2. The server could > return a 202 response to indicate that the message was "handed off" to a > bridge system. > > It's also possible for the push system to "fall back" to HTTP2 if the > proprietary bridge fails, but there are still unresolved issues around > how the client might detect that a proprietary bridge has failed. > > There are many benefits to such an approach: > * Reduced device battery requirements > * Wider device support for Push provider systems > * Push availability on legacy systems that may not yet support the Push > standard. > * "Seamless" cross-notification system support for app developers. > * etc. > > There are also significant drawbacks, the largest being that it is > dependent on support by bridge providers. > > Is this a reasonable approach? The protocol between user agent and push service should have little impact on the protocol used by a server to send messages. As long as the client gets a subscription from the UA - using the defined W3C API - and the server sends using the defined IETF protocol - everything should work. I would expect other push services to have special protocols for mobile - less chatty, with various optimizations for unreliable connections, etc - but providing same features as HTTP/2. Costin > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > --047d7b10ce47cf05540517172842 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, May 26, 2015 at 9:57 AM, JR Conlin <jconlin@mozilla.com&= gt; wrote:
In order to reduce batt= ery requirements on mobile devices, it's often
preferable to use existing messaging architectures for notification
delivery. As an example, Google Cloud Messaging (GCM) maintains a
proprietary connection between their servers and remote android devices. It would be wasteful for applications to maintain a separate, long lived connection back to a different server, since this connection might mean
that the device CPU or network runs more often that the native connection.<= br>

Strongly agreed :-)
=C2=A0

One approach is that a remote device pass a bridge descriptor object
attached to the initial subscription request which contains device
specific information. For instance, the object could contain the
preferred protocol, the local device ID required by GCM and any other
device specific information that might be required to use the
proprietary bridge network. This bridge descriptor may be common among
subscription requests.

I think it would= be even cleaner if GCM would return a regular webpush=C2=A0
subs= cription ( i.e. capability URL ), so the app can use the same send
protocol.=C2=A0

The main issue is that GCM requi= res a separate authentication/registration.
We have several optio= ns we're exploring to make it smoother, but=C2=A0
I don't= think we can drop the requirement to authenticate/authorize
all = senders, and this will apply to the webpush endpoint as well.=C2=A0

=C2=A0

The server then stores this information for the device. When the server
receives a new push message delivery request, it wraps the request data
to fit the proprietary bridge system requirements and sends the event to the device. An app on the device would then process the incoming bridged data and distribute it as if it was carried by HTTP2. The server could
return a 202 response to indicate that the message was "handed off&quo= t; to a
bridge system.

It's also possible for the push system to "fall back" to HTTP= 2 if the
proprietary bridge fails, but there are still unresolved issues around
how the client might detect that a proprietary bridge has failed.

There are many benefits to such an approach:
* Reduced device battery requirements
* Wider device support for Push provider systems
* Push availability on legacy systems that may not yet support the Push
standard.
* "Seamless" cross-notification system support for app developers= .
* etc.

There are also significant drawbacks, the largest being that it is
dependent on support by bridge providers.

Is this a reasonable approach?

The protocol= between user agent and push service should have little impact on=C2=A0
the protocol used by a server to send messages.

=
As long as the client gets a subscription from the UA - using the defi= ned W3C API -=C2=A0
and the server sends using the defined IETF p= rotocol - everything should work.=C2=A0

I would ex= pect other push services to have special protocols for mobile -=C2=A0
=
less chatty, with various optimizations for unreliable connections, et= c - but=C2=A0
providing same features as HTTP/2. =C2=A0

Costin
=C2=A0

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

--047d7b10ce47cf05540517172842-- From nobody Wed May 27 16:47:06 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA9A81A8A1D for ; Wed, 27 May 2015 16:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQ8uVRo_twOO for ; Wed, 27 May 2015 16:47:01 -0700 (PDT) Received: from mail-pd0-f177.google.com (mail-pd0-f177.google.com [209.85.192.177]) (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 410FE1A8A0B for ; Wed, 27 May 2015 16:47:01 -0700 (PDT) Received: by pdea3 with SMTP id a3so27809955pde.2 for ; Wed, 27 May 2015 16:47:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=iHdC3QVX/j5Z1lXXegj/JktOF6qXU1uM6WRO8Yht96E=; b=UEoN7cvzDVLIUSTge3cGYFjK7qpYm14xMNhfJY+vDVUuJD64y535WUC0oMHWGK1BtY oY4t2xG7A/3BGHxMlHqaadX9mFV3z2mvCpNXbosoxrw5l+IWGNoXiveu5r3EeO1bv6BY Hn3PAa6w7pjWLmxBq2qRUYbkvCJfyKAuMcN3jQYwmJ0TaxyDiPbT3oPO8zu188nFOCto Ckxv7/0WqNwJBw89xiiJz8JwORtR1VMy6YK3HObbc1Fp1JuF9m+uvbz9/X+rtZFTerI4 rgJAc5SXPzWAxNY7Yc2v8A24MK8c8/0vOYB+WFIODYMb1Y12RYl0rFFCx8wXTZLdqaQy pDHA== X-Gm-Message-State: ALoCoQk4FvYLZl2sie+WRTe8ID6rHMBPaLIDJ+0olWdbr4QSl8kENt8w2yxsrXDw6IZyW0QR8hKL X-Received: by 10.70.37.225 with SMTP id b1mr63529457pdk.35.1432770420733; Wed, 27 May 2015 16:47:00 -0700 (PDT) Received: from [192.168.2.102] (107-130-102-77.lightspeed.sntcca.sbcglobal.net. [107.130.102.77]) by mx.google.com with ESMTPSA id p9sm267223pds.92.2015.05.27.16.46.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 May 2015 16:46:59 -0700 (PDT) To: Costin Manolache References: <5564A5F0.1040504@mozilla.com> From: jr conlin X-Enigmail-Draft-Status: N1110 Organization: Mozilla Message-ID: <55665776.6000104@mozilla.com> Date: Wed, 27 May 2015 16:47:02 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Guidance requested for Cross protocol bridging 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, 27 May 2015 23:47:04 -0000 On 5/27/2015 2:45 PM, Costin Manolache wrote: > > > On Tue, May 26, 2015 at 9:57 AM, JR Conlin > wrote: > > In order to reduce battery requirements on mobile devices, it's often > preferable to use existing messaging architectures for notification > delivery. As an example, Google Cloud Messaging (GCM) maintains a > proprietary connection between their servers and remote android > devices. > It would be wasteful for applications to maintain a separate, long > lived > connection back to a different server, since this connection might > mean > that the device CPU or network runs more often that the native > connection. > > > Strongly agreed :-) > > > > One approach is that a remote device pass a bridge descriptor object > attached to the initial subscription request which contains device > specific information. For instance, the object could contain the > preferred protocol, the local device ID required by GCM and any other > device specific information that might be required to use the > proprietary bridge network. This bridge descriptor may be common among > subscription requests. > > > I think it would be even cleaner if GCM would return a regular webpush > subscription ( i.e. capability URL ), so the app can use the same send > protocol. Agreed. However there may be some protocols (say, one for an operator or some legacy system that may not be able or even want to provide a modern system), which we could use as a wrapper. > > The main issue is that GCM requires a separate > authentication/registration. > We have several options we're exploring to make it smoother, but > I don't think we can drop the requirement to authenticate/authorize > all senders, and this will apply to the webpush endpoint as well. Hmm... that might be a bit of an issue. I know that services such as AWS can hold credentials in escrow and effectively be a proxy for a user rather than a proxy for the service. The problem there is that it means the service has to hold user credentials, and all the fun issues that can come with that. > > > > > The server then stores this information for the device. When the > server > receives a new push message delivery request, it wraps the request > data > to fit the proprietary bridge system requirements and sends the > event to > the device. An app on the device would then process the incoming > bridged > data and distribute it as if it was carried by HTTP2. The server could > return a 202 response to indicate that the message was "handed > off" to a > bridge system. > > It's also possible for the push system to "fall back" to HTTP2 if the > proprietary bridge fails, but there are still unresolved issues around > how the client might detect that a proprietary bridge has failed. > > There are many benefits to such an approach: > * Reduced device battery requirements > * Wider device support for Push provider systems > * Push availability on legacy systems that may not yet support the > Push > standard. > * "Seamless" cross-notification system support for app developers. > * etc. > > There are also significant drawbacks, the largest being that it is > dependent on support by bridge providers. > > Is this a reasonable approach? > > > The protocol between user agent and push service should have little > impact on > the protocol used by a server to send messages. > > As long as the client gets a subscription from the UA - using the > defined W3C API - > and the server sends using the defined IETF protocol - everything > should work. > > I would expect other push services to have special protocols for mobile - > less chatty, with various optimizations for unreliable connections, > etc - but > providing same features as HTTP/2. Ideally, yes. I'm also fine with having a "minimal set" of functions for this. If a given app wants to take advantage of the amazing features available using a proprietary notification system, awesome! Use that system. No need to reproduce it. Instead, we should try to provide enough of a system that J. Random Developer can use to write an app and not worry about who is using it on what device or which network. From nobody Wed May 27 21:13:12 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C741A896A for ; Wed, 27 May 2015 21:13:11 -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 hooYJBhkXjAN for ; Wed, 27 May 2015 21:13:08 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33B881A873B for ; Wed, 27 May 2015 21:13:08 -0700 (PDT) Received: by iebgx4 with SMTP id gx4so29499545ieb.0 for ; Wed, 27 May 2015 21:13:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SGtcvfkmpUi6EDdFdWSNQtN/DCYPF4lJrUqfEHb1phA=; b=YH0tfO70vOHeRrG5Xf3fKJKxz7y6K/mmL8pt0kL9EuUG8aFbfnEXNj0O+4ZN9ekxmf oTA7MQL156zd2AbmzlLxWKOvn3ZuIdMBysNdDbsbj/K7iBpIMJe3ntHVLcQlmHOXsglA wnVIOa6y+h9r1CO2JWBLjg5Zhp4x4xHzFvHAtuMjurUYNkff6Rpcum2qX/g5girAQhDo vaTr6bGVU+DNu2iDCLtD+1MEzGX9QvPIHJlGJJZ2BCMw6xvV3S00WAGMbpQWwxsovC6r EyxN/2r0CcibWmQXYQu6rOMFxQvhmpZqFHhEm5pmGw68wxQt2D7QdZa+Nj+axv/ZbzHD 8QNg== MIME-Version: 1.0 X-Received: by 10.50.27.6 with SMTP id p6mr41261600igg.46.1432786387662; Wed, 27 May 2015 21:13:07 -0700 (PDT) Received: by 10.36.9.207 with HTTP; Wed, 27 May 2015 21:13:07 -0700 (PDT) In-Reply-To: <55665776.6000104@mozilla.com> References: <5564A5F0.1040504@mozilla.com> <55665776.6000104@mozilla.com> Date: Wed, 27 May 2015 21:13:07 -0700 Message-ID: From: Costin Manolache To: jr conlin Content-Type: multipart/alternative; boundary=047d7b10ce47ad00b505171c93ee Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Guidance requested for Cross protocol bridging 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, 28 May 2015 04:13:11 -0000 --047d7b10ce47ad00b505171c93ee Content-Type: text/plain; charset=UTF-8 On Wed, May 27, 2015 at 4:47 PM, jr conlin wrote: > On 5/27/2015 2:45 PM, Costin Manolache wrote: > > > > > > On Tue, May 26, 2015 at 9:57 AM, JR Conlin > > wrote: > > > > In order to reduce battery requirements on mobile devices, it's often > > preferable to use existing messaging architectures for notification > > delivery. As an example, Google Cloud Messaging (GCM) maintains a > > proprietary connection between their servers and remote android > > devices. > > It would be wasteful for applications to maintain a separate, long > > lived > > connection back to a different server, since this connection might > > mean > > that the device CPU or network runs more often that the native > > connection. > > > > > > Strongly agreed :-) > > > > > > > > One approach is that a remote device pass a bridge descriptor object > > attached to the initial subscription request which contains device > > specific information. For instance, the object could contain the > > preferred protocol, the local device ID required by GCM and any other > > device specific information that might be required to use the > > proprietary bridge network. This bridge descriptor may be common > among > > subscription requests. > > > > > > I think it would be even cleaner if GCM would return a regular webpush > > subscription ( i.e. capability URL ), so the app can use the same send > > protocol. > Agreed. However there may be some protocols (say, one for an operator or > some legacy system that may not be able or even want to provide a modern > system), which we could use as a wrapper. > I remember the UUCP to SMTP gateways :-) For a developer using the webpush specification - what matters is that the UA returns a subscription ID, and the push services provides a HTTP endpoint following the standard. I think the UA and push service developers will need to implement the adaptation, and I don't think the current requirements are too hard to adapt to things like SMS for example. > > > > The main issue is that GCM requires a separate > > authentication/registration. > > We have several options we're exploring to make it smoother, but > > I don't think we can drop the requirement to authenticate/authorize > > all senders, and this will apply to the webpush endpoint as well. > Hmm... that might be a bit of an issue. I know that services such as AWS > can hold credentials in escrow and effectively be a proxy for a user > rather than a proxy for the service. The problem there is that it means > the service has to hold user credentials, and all the fun issues that > can come with that. > > At least in GCM - there is no 'user' involved, and I don't see why webpush would need user credentials. The application instance running on the device/UA needs to have an identifier ( subscription ) and a public key. I think expecting the sender to also have an identifier - and a public key - using the same mechanisms that the receiver uses - makes the protocol symmetrical. Both ends can use the private key to generate for example JWT tokens that would authenticate the subscription. Webpush is a messaging system - SMTP and XMPP have an interesting history and many lessons. XMPP has authentication for both sender and receivers, and that worked quite well. SMTP relied on keeping the email address 'private' - similar with the subscriptions in webpush, and had many problems - eventually added back some complicated forms of sender authentication. > > > > > > > > > > The server then stores this information for the device. When the > > server > > receives a new push message delivery request, it wraps the request > > data > > to fit the proprietary bridge system requirements and sends the > > event to > > the device. An app on the device would then process the incoming > > bridged > > data and distribute it as if it was carried by HTTP2. The server > could > > return a 202 response to indicate that the message was "handed > > off" to a > > bridge system. > > > > It's also possible for the push system to "fall back" to HTTP2 if the > > proprietary bridge fails, but there are still unresolved issues > around > > how the client might detect that a proprietary bridge has failed. > > > > There are many benefits to such an approach: > > * Reduced device battery requirements > > * Wider device support for Push provider systems > > * Push availability on legacy systems that may not yet support the > > Push > > standard. > > * "Seamless" cross-notification system support for app developers. > > * etc. > > > > There are also significant drawbacks, the largest being that it is > > dependent on support by bridge providers. > > > > Is this a reasonable approach? > > > > > > The protocol between user agent and push service should have little > > impact on > > the protocol used by a server to send messages. > > > > As long as the client gets a subscription from the UA - using the > > defined W3C API - > > and the server sends using the defined IETF protocol - everything > > should work. > > > > I would expect other push services to have special protocols for mobile - > > less chatty, with various optimizations for unreliable connections, > > etc - but > > providing same features as HTTP/2. > > Ideally, yes. I'm also fine with having a "minimal set" of functions for > this. If a given app wants to take advantage of the amazing features > available using a proprietary notification system, awesome! Use that > system. No need to reproduce it. Instead, we should try to provide > enough of a system that J. Random Developer can use to write an app and > not worry about who is using it on what device or which network. > Agreed, and the random developer will only need to be concerned with the 2 ends of the protocol - the W3C js API and the send part of the spec. There will be enough pain for him dealing with the encryption :-). What's in the middle has more opportunities for optimization and bridging to other systems, without leaking into what developers just using webpush have to deal with. Costin --047d7b10ce47ad00b505171c93ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, May 27, 2015 at 4:47 PM, jr conlin <jconlin@mozilla.com&= gt; wrote:
On 5/2= 7/2015 2:45 PM, Costin Manolache wrote:
>
>
> On Tue, May 26, 2015 at 9:57 AM, JR Conlin <jconlin@mozilla.com
> <mailto:jconlin@mozilla.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0In order to reduce battery requirements on mobile d= evices, it's often
>=C2=A0 =C2=A0 =C2=A0preferable to use existing messaging architectures = for notification
>=C2=A0 =C2=A0 =C2=A0delivery. As an example, Google Cloud Messaging (GC= M) maintains a
>=C2=A0 =C2=A0 =C2=A0proprietary connection between their servers and re= mote android
>=C2=A0 =C2=A0 =C2=A0devices.
>=C2=A0 =C2=A0 =C2=A0It would be wasteful for applications to maintain a= separate, long
>=C2=A0 =C2=A0 =C2=A0lived
>=C2=A0 =C2=A0 =C2=A0connection back to a different server, since this c= onnection might
>=C2=A0 =C2=A0 =C2=A0mean
>=C2=A0 =C2=A0 =C2=A0that the device CPU or network runs more often that= the native
>=C2=A0 =C2=A0 =C2=A0connection.
>
>
> Strongly agreed :-)
>
>
>
>=C2=A0 =C2=A0 =C2=A0One approach is that a remote device pass a bridge = descriptor object
>=C2=A0 =C2=A0 =C2=A0attached to the initial subscription request which = contains device
>=C2=A0 =C2=A0 =C2=A0specific information. For instance, the object coul= d contain the
>=C2=A0 =C2=A0 =C2=A0preferred protocol, the local device ID required by= GCM and any other
>=C2=A0 =C2=A0 =C2=A0device specific information that might be required = to use the
>=C2=A0 =C2=A0 =C2=A0proprietary bridge network. This bridge descriptor = may be common among
>=C2=A0 =C2=A0 =C2=A0subscription requests.
>
>
> I think it would be even cleaner if GCM would return a regular webpush=
> subscription ( i.e. capability URL ), so the app can use the same send=
> protocol.
Agreed. However there may be some protocols (say, one for an operato= r or
some legacy system that may not be able or even want to provide a modern system), which we could use as a wrapper.

I remember the UUCP to SMTP gateways :-)=C2=A0

= For a developer using the webpush specification - what =C2=A0matters is tha= t the UA=C2=A0
returns a subscription ID, and the push services p= rovides a HTTP endpoint following the=C2=A0
standard.
<= br>
I think the UA and push service developers will need to imple= ment the adaptation,
and I don't think the current requiremen= ts are too hard to adapt to things like SMS
for example.

=C2=A0
>
> The main issue is that GCM requires a separate
> authentication/registration.
> We have several options we're exploring to make it smoother, but > I don't think we can drop the requirement to authenticate/authoriz= e
> all senders, and this will apply to the webpush endpoint as well.
Hmm... that might be a bit of an issue. I know that services such as= AWS
can hold credentials in escrow and effectively be a proxy for a user
rather than a proxy for the service. The problem there is that it means
the service has to hold user credentials, and all the fun issues that
can come with that.


At = least in GCM - there is no 'user' involved, and I don't see why= webpush would need
user credentials.=C2=A0

<= div>The application instance running on the device/UA needs to have an iden= tifier ( subscription )
and a public key. I think expecting the s= ender to also have an identifier - and a public key -=C2=A0
using= the same mechanisms that the receiver uses - makes the protocol symmetrica= l.=C2=A0
Both ends can use the private key to generate for exampl= e JWT tokens that would authenticate
the subscription.=C2=A0<= /div>

Webpush is a messaging system - SMTP and XMPP have= an interesting history and many lessons.
XMPP has authentication= for both sender and receivers, and that worked quite well.
SMTP = relied on keeping the email address 'private' - similar with the su= bscriptions in webpush,
and had many problems - eventually added = back some complicated forms of sender authentication.

<= div>
=C2=A0
>
>
>
>
>=C2=A0 =C2=A0 =C2=A0The server then stores this information for the dev= ice. When the
>=C2=A0 =C2=A0 =C2=A0server
>=C2=A0 =C2=A0 =C2=A0receives a new push message delivery request, it wr= aps the request
>=C2=A0 =C2=A0 =C2=A0data
>=C2=A0 =C2=A0 =C2=A0to fit the proprietary bridge system requirements a= nd sends the
>=C2=A0 =C2=A0 =C2=A0event to
>=C2=A0 =C2=A0 =C2=A0the device. An app on the device would then process= the incoming
>=C2=A0 =C2=A0 =C2=A0bridged
>=C2=A0 =C2=A0 =C2=A0data and distribute it as if it was carried by HTTP= 2. The server could
>=C2=A0 =C2=A0 =C2=A0return a 202 response to indicate that the message = was "handed
>=C2=A0 =C2=A0 =C2=A0off" to a
>=C2=A0 =C2=A0 =C2=A0bridge system.
>
>=C2=A0 =C2=A0 =C2=A0It's also possible for the push system to "= ;fall back" to HTTP2 if the
>=C2=A0 =C2=A0 =C2=A0proprietary bridge fails, but there are still unres= olved issues around
>=C2=A0 =C2=A0 =C2=A0how the client might detect that a proprietary brid= ge has failed.
>
>=C2=A0 =C2=A0 =C2=A0There are many benefits to such an approach:
>=C2=A0 =C2=A0 =C2=A0* Reduced device battery requirements
>=C2=A0 =C2=A0 =C2=A0* Wider device support for Push provider systems >=C2=A0 =C2=A0 =C2=A0* Push availability on legacy systems that may not = yet support the
>=C2=A0 =C2=A0 =C2=A0Push
>=C2=A0 =C2=A0 =C2=A0standard.
>=C2=A0 =C2=A0 =C2=A0* "Seamless" cross-notification system su= pport for app developers.
>=C2=A0 =C2=A0 =C2=A0* etc.
>
>=C2=A0 =C2=A0 =C2=A0There are also significant drawbacks, the largest b= eing that it is
>=C2=A0 =C2=A0 =C2=A0dependent on support by bridge providers.
>
>=C2=A0 =C2=A0 =C2=A0Is this a reasonable approach?
>
>
> The protocol between user agent and push service should have little > impact on
> the protocol used by a server to send messages.
>
> As long as the client gets a subscription from the UA - using the
> defined W3C API -
> and the server sends using the defined IETF protocol - everything
> should work.
>
> I would expect other push services to have special protocols for mobil= e -
> less chatty, with various optimizations for unreliable connections, > etc - but
> providing same features as HTTP/2.

Ideally, yes. I'm also fine with having a "minimal set= " of functions for
this. If a given app wants to take advantage of the amazing features
available using a proprietary notification system, awesome! Use that
system. No need to reproduce it. Instead, we should try to provide
enough of a system that J. Random Developer can use to write an app and
not worry about who is using it on what device or which network.

Agreed, and the ran= dom developer will only need to be concerned with the 2 ends
of the protocol - the W3C js API and the send part of the= spec. There will be enough
pain for him de= aling with the encryption :-).

What's in the middle has more opportunities fo= r optimization and bridging to other=C2=A0
= systems, without leaking into what developers just using webpush have to de= al with.=C2=A0

Costin



--047d7b10ce47ad00b505171c93ee-- From nobody Thu May 28 14:14:49 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7C511A8A09 for ; Thu, 28 May 2015 14:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3b-vf0JluEf1 for ; Thu, 28 May 2015 14:14:44 -0700 (PDT) Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com [209.85.213.179]) (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 374781A89ED for ; Thu, 28 May 2015 14:14:39 -0700 (PDT) Received: by igbpi8 with SMTP id pi8so122963266igb.1 for ; Thu, 28 May 2015 14:14:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=cjdp6ogWMVjOYKvVWKbzyNpYfPRTuA3PlCh6U2t5EtI=; b=ia/C5vrLwdj3UKHq6AevuXvD8GOlJ9GmYpzT2ZIuO87gB9h39Ct2ISll1CGUEQyoHF uzMxD3w7n1Pru7EBvCell+q08lHFFZbMD7fMKXCc0v1VWHShMBAZ44RgbAddTn3OmExX tz0z5BUE74Dysp2S9M2wl7VxL006savIYL4oc1UeR3qMCst4UbUp6/HdU1qAAFg/RO9p jqcIecdDEZmxs+G+i9s6sojgjWSKZHxtvY82G6/A9UFdvqUKkK5yllsB15oi3aKTiQym j0e3b9SRGeVUFd80XkHwyWvUHVGJ1uut8ei27q8MuH7rcYMFue8aFdO6xCkdiitK+HfX vSuA== X-Gm-Message-State: ALoCoQkd1+d++cuIyfofDMDyN9yed5vgY14xnCgPF8WRTU0K9UMOOjRP/CUE6PInKapiNBworepU X-Received: by 10.50.64.147 with SMTP id o19mr13732403igs.33.1432847678417; Thu, 28 May 2015 14:14:38 -0700 (PDT) Received: from [192.168.2.102] (107-130-102-77.lightspeed.sntcca.sbcglobal.net. [107.130.102.77]) by mx.google.com with ESMTPSA id o21sm2643431ioo.31.2015.05.28.14.14.37 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 May 2015 14:14:37 -0700 (PDT) To: Costin Manolache References: <5564A5F0.1040504@mozilla.com> <55665776.6000104@mozilla.com> From: jr conlin X-Enigmail-Draft-Status: N1110 Organization: Mozilla Message-ID: <55678541.2090506@mozilla.com> Date: Thu, 28 May 2015 14:14:41 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Guidance requested for Cross protocol bridging 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, 28 May 2015 21:14:49 -0000 On 5/27/2015 9:13 PM, Costin Manolache wrote: > > > On Wed, May 27, 2015 at 4:47 PM, jr conlin > wrote: > > On 5/27/2015 2:45 PM, Costin Manolache wrote: > > > > > > On Tue, May 26, 2015 at 9:57 AM, JR Conlin > > >> wrote: > > > > In order to reduce battery requirements on mobile devices, > it's often > > preferable to use existing messaging architectures for > notification > > delivery. As an example, Google Cloud Messaging (GCM) > maintains a > > proprietary connection between their servers and remote android > > devices. > > It would be wasteful for applications to maintain a > separate, long > > lived > > connection back to a different server, since this connection > might > > mean > > that the device CPU or network runs more often that the native > > connection. > > > > > > Strongly agreed :-) > > > > > > > > One approach is that a remote device pass a bridge > descriptor object > > attached to the initial subscription request which contains > device > > specific information. For instance, the object could contain the > > preferred protocol, the local device ID required by GCM and > any other > > device specific information that might be required to use the > > proprietary bridge network. This bridge descriptor may be > common among > > subscription requests. > > > > > > I think it would be even cleaner if GCM would return a regular > webpush > > subscription ( i.e. capability URL ), so the app can use the > same send > > protocol. > Agreed. However there may be some protocols (say, one for an > operator or > some legacy system that may not be able or even want to provide a > modern > system), which we could use as a wrapper. > > > I remember the UUCP to SMTP gateways :-) > > For a developer using the webpush specification - what matters is > that the UA > returns a subscription ID, and the push services provides a HTTP > endpoint following the > standard. > > I think the UA and push service developers will need to implement the > adaptation, > and I don't think the current requirements are too hard to adapt to > things like SMS > for example. > > > > > > > The main issue is that GCM requires a separate > > authentication/registration. > > We have several options we're exploring to make it smoother, but > > I don't think we can drop the requirement to authenticate/authorize > > all senders, and this will apply to the webpush endpoint as well. > Hmm... that might be a bit of an issue. I know that services such > as AWS > can hold credentials in escrow and effectively be a proxy for a user > rather than a proxy for the service. The problem there is that it > means > the service has to hold user credentials, and all the fun issues that > can come with that. > > > At least in GCM - there is no 'user' involved, and I don't see why > webpush would need > user credentials. I'm not sure I follow, perhaps I wasn't clear. If GCM has an individual authentication/registration cycle per individual, does that not imply that any system that wishes to bridge over GCM would require it's own authentication/registration tied to a given individual (user/app/whatever)? If that's the case, when a system such as Push bridges across a system like GCM, we would either have to use a common set of credentials tied to a trusted carrier. Maybe a user story might help. Let's say that A is acting as a Push provider for B. who wants to use C's Cloud Messaging (CCM). A wants to send a message to a device that's connected via CCM. There are two ways that this could be done. 1) B sends data to A's Push service. A bundles it and submits it to CCM using A's credentials. On the device, an app created by A gets the message, unbundles it, and passes the information on to B's device app. 2) B registers to use CCM and gets authentication credentials. B then sends B credentials to A as part of the initial registration. When B wants to send messages over CCM, A uses B's credentials (in essence, acting as a proxy for B) which then can either go to the A client app, or the B client app (depending on how the CCM registration process is designed). Scenario 1 would be preferable from a privacy and developer simplicity point of view, but does mean that if CCM shuts down As channel, the bridge fails for everyone. If I understand the presentation made at Google I/O on the 28th, GCM appears to be adopting the second approach. Is this correct? > The application instance running on the device/UA needs to have an > identifier ( subscription ) > and a public key. I think expecting the sender to also have an > identifier - and a public key - > using the same mechanisms that the receiver uses - makes the protocol > symmetrical. > Both ends can use the private key to generate for example JWT tokens > that would authenticate > the subscription. Agreed. The content should be encrypted against the carrier in any case. That would make handling broadcast messages tricky, since the message would need to be decrypted by multiple keys, or each message would need to target a given device. Granted, distributing in plain text would be far simpler, but would expose potentially sensitive user data. > > Webpush is a messaging system - SMTP and XMPP have an interesting > history and many lessons. > XMPP has authentication for both sender and receivers, and that worked > quite well. > SMTP relied on keeping the email address 'private' - similar with the > subscriptions in webpush, > and had many problems - eventually added back some complicated forms > of sender authentication. > > > > > > > > > > > > > > The server then stores this information for the device. When the > > server > > receives a new push message delivery request, it wraps the > request > > data > > to fit the proprietary bridge system requirements and sends the > > event to > > the device. An app on the device would then process the incoming > > bridged > > data and distribute it as if it was carried by HTTP2. The > server could > > return a 202 response to indicate that the message was "handed > > off" to a > > bridge system. > > > > It's also possible for the push system to "fall back" to > HTTP2 if the > > proprietary bridge fails, but there are still unresolved > issues around > > how the client might detect that a proprietary bridge has > failed. > > > > There are many benefits to such an approach: > > * Reduced device battery requirements > > * Wider device support for Push provider systems > > * Push availability on legacy systems that may not yet > support the > > Push > > standard. > > * "Seamless" cross-notification system support for app > developers. > > * etc. > > > > There are also significant drawbacks, the largest being that > it is > > dependent on support by bridge providers. > > > > Is this a reasonable approach? > > > > > > The protocol between user agent and push service should have little > > impact on > > the protocol used by a server to send messages. > > > > As long as the client gets a subscription from the UA - using the > > defined W3C API - > > and the server sends using the defined IETF protocol - everything > > should work. > > > > I would expect other push services to have special protocols for > mobile - > > less chatty, with various optimizations for unreliable connections, > > etc - but > > providing same features as HTTP/2. > > Ideally, yes. I'm also fine with having a "minimal set" of > functions for > this. If a given app wants to take advantage of the amazing features > available using a proprietary notification system, awesome! Use that > system. No need to reproduce it. Instead, we should try to provide > enough of a system that J. Random Developer can use to write an > app and > not worry about who is using it on what device or which network. > > > Agreed, and the random developer will only need to be concerned with > the 2 ends > of the protocol - the W3C js API and the send part of the spec. There > will be enough > pain for him dealing with the encryption :-). > > What's in the middle has more opportunities for optimization and > bridging to other > systems, without leaking into what developers just using webpush have > to deal with. Absolutely agree! Likewise it would be fantastic if we could protect user privacy, including as much of the "metadata" as we can. From nobody Sat May 30 14:48:17 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFCF1ACE1D for ; Sat, 30 May 2015 14:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 ioDxiwPmY6-K for ; Sat, 30 May 2015 14:48:11 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0B211ACE1F for ; Sat, 30 May 2015 14:48:10 -0700 (PDT) Received: by igbjd9 with SMTP id jd9so37682222igb.1 for ; Sat, 30 May 2015 14:48:10 -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=PQXL+HIc+Ygob7HMqtaqCNsFnFG3Q05eBCSAj5DBr78=; b=FbhViWUIfh3W2AhA9grvtzPygLbs9TR6VZNciS+Hz4nbBleOBWzi83k70V4uSuQaQx k6Uf+rQKF61LLv/faF3D8tPOuDuwFcuAN+dYKXPeQDUTBmAwahmiQNOFnCD1P2W2r78j Alv3+1NLoWDERwWtK8exsESR3yMIs07GJC/n5ZqosE8eMDQOI2AlRYZHeWy7+hKzmyav +EpYvGTXrxNJDoT7+RfleU/wQPRmDCcGjaSHLgzatwvzXheVAOJ/h+3XNKtxUakSdmVj 175YQGBvAGLTILPHM9PbzcANCJpBa8rBwBR/X2WiPFhjkVkTREGCR25ljTw5LbT2w97h V+KA== MIME-Version: 1.0 X-Received: by 10.50.59.211 with SMTP id b19mr4670767igr.42.1433022490361; Sat, 30 May 2015 14:48:10 -0700 (PDT) Received: by 10.36.9.207 with HTTP; Sat, 30 May 2015 14:48:10 -0700 (PDT) In-Reply-To: <55678541.2090506@mozilla.com> References: <5564A5F0.1040504@mozilla.com> <55665776.6000104@mozilla.com> <55678541.2090506@mozilla.com> Date: Sat, 30 May 2015 14:48:10 -0700 Message-ID: From: Costin Manolache To: jr conlin Content-Type: multipart/alternative; boundary=047d7bd757587e4a150517538c63 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Guidance requested for Cross protocol bridging 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, 30 May 2015 21:48:15 -0000 --047d7bd757587e4a150517538c63 Content-Type: text/plain; charset=UTF-8 On Thu, May 28, 2015 at 2:14 PM, jr conlin wrote: > On 5/27/2015 9:13 PM, Costin Manolache wrote: > > > > > > On Wed, May 27, 2015 at 4:47 PM, jr conlin > > wrote: > > > > On 5/27/2015 2:45 PM, Costin Manolache wrote: > > > > > > > > > On Tue, May 26, 2015 at 9:57 AM, JR Conlin > > > > >> wrote: > > > > > > In order to reduce battery requirements on mobile devices, > > it's often > > > preferable to use existing messaging architectures for > > notification > > > delivery. As an example, Google Cloud Messaging (GCM) > > maintains a > > > proprietary connection between their servers and remote android > > > devices. > > > It would be wasteful for applications to maintain a > > separate, long > > > lived > > > connection back to a different server, since this connection > > might > > > mean > > > that the device CPU or network runs more often that the native > > > connection. > > > > > > > > > Strongly agreed :-) > > > > > > > > > > > > One approach is that a remote device pass a bridge > > descriptor object > > > attached to the initial subscription request which contains > > device > > > specific information. For instance, the object could contain > the > > > preferred protocol, the local device ID required by GCM and > > any other > > > device specific information that might be required to use the > > > proprietary bridge network. This bridge descriptor may be > > common among > > > subscription requests. > > > > > > > > > I think it would be even cleaner if GCM would return a regular > > webpush > > > subscription ( i.e. capability URL ), so the app can use the > > same send > > > protocol. > > Agreed. However there may be some protocols (say, one for an > > operator or > > some legacy system that may not be able or even want to provide a > > modern > > system), which we could use as a wrapper. > > > > > > I remember the UUCP to SMTP gateways :-) > > > > For a developer using the webpush specification - what matters is > > that the UA > > returns a subscription ID, and the push services provides a HTTP > > endpoint following the > > standard. > > > > I think the UA and push service developers will need to implement the > > adaptation, > > and I don't think the current requirements are too hard to adapt to > > things like SMS > > for example. > > > > > > > > > > > > The main issue is that GCM requires a separate > > > authentication/registration. > > > We have several options we're exploring to make it smoother, but > > > I don't think we can drop the requirement to authenticate/authorize > > > all senders, and this will apply to the webpush endpoint as well. > > Hmm... that might be a bit of an issue. I know that services such > > as AWS > > can hold credentials in escrow and effectively be a proxy for a user > > rather than a proxy for the service. The problem there is that it > > means > > the service has to hold user credentials, and all the fun issues that > > can come with that. > > > > > > At least in GCM - there is no 'user' involved, and I don't see why > > webpush would need > > user credentials. > > I'm not sure I follow, perhaps I wasn't clear. If GCM has an individual > authentication/registration cycle per individual, does that not imply > that any system that wishes to bridge over GCM would require it's own > authentication/registration tied to a given individual > (user/app/whatever)? If that's the case, when a system such as Push > bridges across a system like GCM, we would either have to use a common > set of credentials tied to a trusted carrier. > > Maybe a user story might help. > > Let's say that A is acting as a Push provider for B. who wants to use > C's Cloud Messaging (CCM). A wants to send a message to a device that's > connected via CCM. > > There are two ways that this could be done. > 1) B sends data to A's Push service. A bundles it and submits it to CCM > using A's credentials. On the device, an app created by A gets the > message, unbundles it, and passes the information on to B's device app. > > > 2) B registers to use CCM and gets authentication credentials. B then > sends B credentials to A as part of the initial registration. When B > wants to send messages over CCM, A uses B's credentials (in essence, > acting as a proxy for B) which then can either go to the A client app, > or the B client app (depending on how the CCM registration process is > designed). > > Scenario 1 would be preferable from a privacy and developer simplicity > point of view, but does mean that if CCM shuts down As channel, the > bridge fails for everyone. > > > If I understand the presentation made at Google I/O on the 28th, GCM > appears to be adopting the second approach. Is this correct? > I'm not sure I understood the A/B/C example, let me try to describe what I think you meant. GCM - and I suspect other push providers - requires sender authentication. Current webpush drafts allow this - and many other messaging protocols have this requirement - XMPP, even many modern SMTP servers, and I think it is essential in any large-scale system, for many reasons ( security, abuse, network management, etc). So assuming C is the push service requiring sender authentication - like GCM, B is a developer running an app or page on a device connected to C, and A is another push service that needs to bridge to C. B will use A's webpush service to send the message. The options are: 1. A doesn't require any authentication ( open relay ). It will have to use it's own credentials, registered with C, and send everything with their credentials. If there are problems with any of the apps sharing the open relay - all traffic may be blocked. 2. A may have some mechanism to generate different credentials for each app - this still require that A identifies the different applications, so I don't know how it could work if A is an open relay ( i.e. doesn't know who sends messages and for which app they are ). If A would have a way to know how to group the messages - it could manage separate credentials for each app. 3. A requires authentication with same scheme as C - it can just pass the auth header to C. This would work if A and C accept the same authentication - and it would help if webpush defined at least one schema, for example based on JWT tokens. 4. A requires authentication - with a different scheme than C. In this case A would need to generate or register a mapping between its user scheme for senders and C, and automatically register them with C. This would work better if webpush defined a registration protocol for senders - similar ( or same) with the one defined for registering/subscribing apps and UAs. > The application instance running on the device/UA needs to have an > > identifier ( subscription ) > > and a public key. I think expecting the sender to also have an > > identifier - and a public key - > > using the same mechanisms that the receiver uses - makes the protocol > > symmetrical. > > Both ends can use the private key to generate for example JWT tokens > > that would authenticate > > the subscription. > Agreed. The content should be encrypted against the carrier in any case. > That would make handling broadcast messages tricky, since the message > would need to be decrypted by multiple keys, or each message would need > to target a given device. > > Granted, distributing in plain text would be far simpler, but would > expose potentially sensitive user data. > > > > Webpush is a messaging system - SMTP and XMPP have an interesting > > history and many lessons. > > XMPP has authentication for both sender and receivers, and that worked > > quite well. > > SMTP relied on keeping the email address 'private' - similar with the > > subscriptions in webpush, > > and had many problems - eventually added back some complicated forms > > of sender authentication. > > > > > > > > > > > > > > > > > > > > > > > The server then stores this information for the device. When > the > > > server > > > receives a new push message delivery request, it wraps the > > request > > > data > > > to fit the proprietary bridge system requirements and sends the > > > event to > > > the device. An app on the device would then process the > incoming > > > bridged > > > data and distribute it as if it was carried by HTTP2. The > > server could > > > return a 202 response to indicate that the message was "handed > > > off" to a > > > bridge system. > > > > > > It's also possible for the push system to "fall back" to > > HTTP2 if the > > > proprietary bridge fails, but there are still unresolved > > issues around > > > how the client might detect that a proprietary bridge has > > failed. > > > > > > There are many benefits to such an approach: > > > * Reduced device battery requirements > > > * Wider device support for Push provider systems > > > * Push availability on legacy systems that may not yet > > support the > > > Push > > > standard. > > > * "Seamless" cross-notification system support for app > > developers. > > > * etc. > > > > > > There are also significant drawbacks, the largest being that > > it is > > > dependent on support by bridge providers. > > > > > > Is this a reasonable approach? > > > > > > > > > The protocol between user agent and push service should have little > > > impact on > > > the protocol used by a server to send messages. > > > > > > As long as the client gets a subscription from the UA - using the > > > defined W3C API - > > > and the server sends using the defined IETF protocol - everything > > > should work. > > > > > > I would expect other push services to have special protocols for > > mobile - > > > less chatty, with various optimizations for unreliable connections, > > > etc - but > > > providing same features as HTTP/2. > > > > Ideally, yes. I'm also fine with having a "minimal set" of > > functions for > > this. If a given app wants to take advantage of the amazing features > > available using a proprietary notification system, awesome! Use that > > system. No need to reproduce it. Instead, we should try to provide > > enough of a system that J. Random Developer can use to write an > > app and > > not worry about who is using it on what device or which network. > > > > > > Agreed, and the random developer will only need to be concerned with > > the 2 ends > > of the protocol - the W3C js API and the send part of the spec. There > > will be enough > > pain for him dealing with the encryption :-). > > > > What's in the middle has more opportunities for optimization and > > bridging to other > > systems, without leaking into what developers just using webpush have > > to deal with. > Absolutely agree! Likewise it would be fantastic if we could protect > user privacy, including as much of the "metadata" as we can. > > Some metadata is needed for operating the service. Authenticating the sender doesn't need to expose more than absolutely needed. For example each sender could generate a key pair, and use JWT tokens to authenticate. I think it would be important to have at least some way to contact the sender - almost all problems can be resolved without resorting to completely blocking a sender. So IMHO the minimum metadata is a public key and some way to contact - the origin of the domain would be great, since it can be used for some verification and contact ( whois, postmaster). Costin --047d7bd757587e4a150517538c63 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, May 28, 2015 at 2:14 PM, jr conlin <jconlin@mozilla.com&= gt; wrote:
On 5/27/2015 9:13 PM= , Costin Manolache wrote:
>
>
> On Wed, May 27, 2015 at 4:47 PM, jr conlin <jconlin@mozilla.com
> <mailto:jconlin@mozilla.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On 5/27/2015 2:45 PM, Costin Manolache wrote:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> On Tue, May 26, 2015 at 9:57 AM, JR Conlin <= ;jconlin@mozilla.com
>=C2=A0 =C2=A0 =C2=A0<mailto:j= conlin@mozilla.com>
>=C2=A0 =C2=A0 =C2=A0> <mailto:jconlin@mozilla.com <mailto:jconlin@mozilla.com>>> wrote:=
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0In order to reduce battery = requirements on mobile devices,
>=C2=A0 =C2=A0 =C2=A0it's often
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0preferable to use existing = messaging architectures for
>=C2=A0 =C2=A0 =C2=A0notification
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0delivery. As an example, Go= ogle Cloud Messaging (GCM)
>=C2=A0 =C2=A0 =C2=A0maintains a
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0proprietary connection betw= een their servers and remote android
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0devices.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0It would be wasteful for ap= plications to maintain a
>=C2=A0 =C2=A0 =C2=A0separate, long
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0lived
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0connection back to a differ= ent server, since this connection
>=C2=A0 =C2=A0 =C2=A0might
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0mean
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0that the device CPU or netw= ork runs more often that the native
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0connection.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Strongly agreed :-)
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0One approach is that a remo= te device pass a bridge
>=C2=A0 =C2=A0 =C2=A0descriptor object
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0attached to the initial sub= scription request which contains
>=C2=A0 =C2=A0 =C2=A0device
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0specific information. For i= nstance, the object could contain the
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0preferred protocol, the loc= al device ID required by GCM and
>=C2=A0 =C2=A0 =C2=A0any other
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0device specific information= that might be required to use the
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0proprietary bridge network.= This bridge descriptor may be
>=C2=A0 =C2=A0 =C2=A0common among
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0subscription requests.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> I think it would be even cleaner if GCM would = return a regular
>=C2=A0 =C2=A0 =C2=A0webpush
>=C2=A0 =C2=A0 =C2=A0> subscription ( i.e. capability URL ), so the a= pp can use the
>=C2=A0 =C2=A0 =C2=A0same send
>=C2=A0 =C2=A0 =C2=A0> protocol.
>=C2=A0 =C2=A0 =C2=A0Agreed. However there may be some protocols (say, o= ne for an
>=C2=A0 =C2=A0 =C2=A0operator or
>=C2=A0 =C2=A0 =C2=A0some legacy system that may not be able or even wan= t to provide a
>=C2=A0 =C2=A0 =C2=A0modern
>=C2=A0 =C2=A0 =C2=A0system), which we could use as a wrapper.
>
>
> I remember the UUCP to SMTP gateways :-)
>
> For a developer using the webpush specification - what=C2=A0 matters i= s
> that the UA
> returns a subscription ID, and the push services provides a HTTP
> endpoint following the
> standard.
>
> I think the UA and push service developers will need to implement the<= br> > adaptation,
> and I don't think the current requirements are too hard to adapt t= o
> things like SMS
> for example.
>
>
>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> The main issue is that GCM requires a separate=
>=C2=A0 =C2=A0 =C2=A0> authentication/registration.
>=C2=A0 =C2=A0 =C2=A0> We have several options we're exploring to= make it smoother, but
>=C2=A0 =C2=A0 =C2=A0> I don't think we can drop the requirement = to authenticate/authorize
>=C2=A0 =C2=A0 =C2=A0> all senders, and this will apply to the webpus= h endpoint as well.
>=C2=A0 =C2=A0 =C2=A0Hmm... that might be a bit of an issue. I know that= services such
>=C2=A0 =C2=A0 =C2=A0as AWS
>=C2=A0 =C2=A0 =C2=A0can hold credentials in escrow and effectively be a= proxy for a user
>=C2=A0 =C2=A0 =C2=A0rather than a proxy for the service. The problem th= ere is that it
>=C2=A0 =C2=A0 =C2=A0means
>=C2=A0 =C2=A0 =C2=A0the service has to hold user credentials, and all t= he fun issues that
>=C2=A0 =C2=A0 =C2=A0can come with that.
>
>
> At least in GCM - there is no 'user' involved, and I don't= see why
> webpush would need
> user credentials.
=C2=A0
I'm not sure I follow, perhaps I wasn't clear. If GCM h= as an individual
authentication/registration cycle per individual, does that not imply
that any system that wishes to bridge over GCM would require it's own authentication/registration tied to a given individual
(user/app/whatever)? If that's the case, when a system such as Push
bridges across a system like GCM, we would either have to use a common
set of credentials tied to a trusted carrier.

Maybe a user story might help.

Let's say that A is acting as a Push provider for B. who wants to use C's Cloud Messaging (CCM). A wants to send a message to a device that&#= 39;s
connected via CCM.

There are two ways that this could be done.
1) B sends data to A's Push service. A bundles it and submits it to CCM=
using A's credentials. On the device, an app created by A gets the
message, unbundles it, and passes the information on to B's device app.=
=C2=A0

2) B registers to use CCM and gets authentication credentials. B then
sends B credentials to A as part of the initial registration. When B
wants to send messages over CCM, A uses B's credentials (in essence, acting as a proxy for B) which then can either go to the A client app,
or the B client app (depending on how the CCM registration process is
designed).

Scenario 1 would be preferable from a privacy and developer simplicity
point of view, but does mean that if CCM shuts down As channel, the
bridge fails for everyone.

=C2=A0

If I understand the presentation made at Google I/O on the 28th, GCM
appears to be adopting the second approach. Is this correct?

I'm not sure I understood the A/B/C example, let = me try to describe what I think you meant.

GCM - a= nd I suspect other push providers - requires sender authentication.
Current webpush drafts allow this - and many other messaging protocols h= ave
=C2=A0this requirement - XMPP, even many modern SMTP servers,= and I think=C2=A0
it is essential in any large-scale system, for= many reasons ( security, abuse,=C2=A0
network management, etc).<= /div>

So assuming C is the push service requiring s= ender authentication - like GCM, B is=C2=A0
a developer run= ning an app or page on a device connected to C, and=C2=A0
A is an= other push service that needs to bridge to C.

B wi= ll use A's webpush service to send the message.=C2=A0

The options are:

1. A doesn't require = any authentication ( open relay ). It will have to use it's own
credentials, registered with C, and send everything with their credentia= ls.=C2=A0
If there are problems with any of the apps sharing the = open relay - all traffic may be
blocked.

2. A may have some mechanism to generate different credentials for each ap= p - this still require
that A identifies the different applicatio= ns, so I don't know how it could work if A is an=C2=A0
open r= elay ( i.e. doesn't know who sends messages and for which app they are = ).
If A would have a way to know how to group the messages - it c= ould manage separate=C2=A0
credentials for each app.
3. A requires authentication with same scheme as C - it can ju= st pass the auth header to C.=C2=A0
This would work if A and C ac= cept the same authentication - and it would help if webpush defined=C2=A0
at least one schema, for example based on JWT tokens.
4. A requires authentication - with a different scheme than C.= In this case A would need
to generate or register a mapping betw= een its user scheme for senders and C, and=C2=A0
automatically re= gister them with C. This would work better if webpush defined=C2=A0
a registration protocol for senders - similar ( or same) =C2=A0with the = one defined for registering/subscribing
=C2=A0apps and UAs.
=



> The application instance running on the device/UA nee= ds to have an
> identifier ( subscription )
> and a public key. I think expecting the sender to also have an
> identifier - and a public key -
> using the same mechanisms that the receiver uses - makes the protocol<= br> > symmetrical.
> Both ends can use the private key to generate for example JWT tokens > that would authenticate
> the subscription.
Agreed. The content should be encrypted against the carrier in any c= ase.
That would make handling broadcast messages tricky, since the message
would need to be decrypted by multiple keys, or each message would need
to target a given device.

Granted, distributing in plain text would be far simpler, but would
expose potentially sensitive user data.
>
> Webpush is a messaging system - SMTP and XMPP have an interesting
> history and many lessons.
> XMPP has authentication for both sender and receivers, and that worked=
> quite well.
> SMTP relied on keeping the email address 'private' - similar w= ith the
> subscriptions in webpush,
> and had many problems - eventually added back some complicated forms > of sender authentication.
>
>
>
>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0The server then stores this= information for the device. When the
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0server
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0receives a new push message= delivery request, it wraps the
>=C2=A0 =C2=A0 =C2=A0request
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0data
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0to fit the proprietary brid= ge system requirements and sends the
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0event to
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0the device. An app on the d= evice would then process the incoming
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0bridged
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0data and distribute it as i= f it was carried by HTTP2. The
>=C2=A0 =C2=A0 =C2=A0server could
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0return a 202 response to in= dicate that the message was "handed
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0off" to a
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0bridge system.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0It's also possible for = the push system to "fall back" to
>=C2=A0 =C2=A0 =C2=A0HTTP2 if the
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0proprietary bridge fails, b= ut there are still unresolved
>=C2=A0 =C2=A0 =C2=A0issues around
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0how the client might detect= that a proprietary bridge has
>=C2=A0 =C2=A0 =C2=A0failed.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0There are many benefits to = such an approach:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0* Reduced device battery re= quirements
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0* Wider device support for = Push provider systems
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0* Push availability on lega= cy systems that may not yet
>=C2=A0 =C2=A0 =C2=A0support the
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Push
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0standard.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0* "Seamless" cros= s-notification system support for app
>=C2=A0 =C2=A0 =C2=A0developers.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0* etc.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0There are also significant = drawbacks, the largest being that
>=C2=A0 =C2=A0 =C2=A0it is
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0dependent on support by bri= dge providers.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Is this a reasonable approa= ch?
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> The protocol between user agent and push servi= ce should have little
>=C2=A0 =C2=A0 =C2=A0> impact on
>=C2=A0 =C2=A0 =C2=A0> the protocol used by a server to send messages= .
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> As long as the client gets a subscription from= the UA - using the
>=C2=A0 =C2=A0 =C2=A0> defined W3C API -
>=C2=A0 =C2=A0 =C2=A0> and the server sends using the defined IETF pr= otocol - everything
>=C2=A0 =C2=A0 =C2=A0> should work.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> I would expect other push services to have spe= cial protocols for
>=C2=A0 =C2=A0 =C2=A0mobile -
>=C2=A0 =C2=A0 =C2=A0> less chatty, with various optimizations for un= reliable connections,
>=C2=A0 =C2=A0 =C2=A0> etc - but
>=C2=A0 =C2=A0 =C2=A0> providing same features as HTTP/2.
>
>=C2=A0 =C2=A0 =C2=A0Ideally, yes. I'm also fine with having a "= ;minimal set" of
>=C2=A0 =C2=A0 =C2=A0functions for
>=C2=A0 =C2=A0 =C2=A0this. If a given app wants to take advantage of the= amazing features
>=C2=A0 =C2=A0 =C2=A0available using a proprietary notification system, = awesome! Use that
>=C2=A0 =C2=A0 =C2=A0system. No need to reproduce it. Instead, we should= try to provide
>=C2=A0 =C2=A0 =C2=A0enough of a system that J. Random Developer can use= to write an
>=C2=A0 =C2=A0 =C2=A0app and
>=C2=A0 =C2=A0 =C2=A0not worry about who is using it on what device or w= hich network.
>
>
> Agreed, and the random developer will only need to be concerned with > the 2 ends
> of the protocol - the W3C js API and the send part of the spec. There<= br> > will be enough
> pain for him dealing with the encryption :-).
>
> What's in the middle has more opportunities for optimization and > bridging to other
> systems, without leaking into what developers just using webpush have<= br> > to deal with.
Absolutely agree! Likewise it would be fantastic if we could pr= otect
user privacy, including as much of the "metadata" as we can.


Some metadata is needed for operating = the service.=C2=A0

Authenticating the sender doesn= 't need to expose more than absolutely needed.

For example each sender could generate a key pair, and use JWT tokens to a= uthenticate.
I think it would be important to have at least some = way to contact the sender - almost all
problems can be resolved w= ithout resorting to completely blocking a sender.=C2=A0

So IMHO the minimum metadata is a public key and some way to contact = - the origin of the
domain would be great, since it can be used f= or some verification and contact ( whois, postmaster).

=
Costin
--047d7bd757587e4a150517538c63--