Subject: [Webpush] Feedback on Martin's WebPush draft

From: Peter Beverloo <[email-masked]>
Date: Wed, 14 May 2014 10:33:19 +0200

Context: http://tools.ietf.org/html/draft-thomson-webpush-http2-00

Hi Martin,

Thank you for putting up your proposal for a HTTP 2.0-based Push service
mechanism. The omission of a dependency on WebSockets is something we
support, given that this raises implementation complexities for us.

I have reviewed your proposal, and want to provide the following feedback.

    * Defining the scope of this specification.

I consider there to be three primary pieces in an entire push transaction.
These are:

a) client <====> push service, registering for a push channel to be opened;
b) app server ====> push service, asking the push service to deliver a
message to a client;
c) push service ====> client, informing the client of the pushed message.

I consider (a) and (c) to be implementation details of the Push service,
which users will rarely get in contact with.

The draft mentions that discovery of push services is considered out of
scope. My recommendation is to consider (a), establishing a registration,
part of that.

This is relevant to sections the registration part, as well as the concept
of monitoring channels (most notably section 6).

    * Definition of the payload itself.

This seems to be missing in the draft. I assume we’ll work on this later?
:-).

    * Separate channel name from URL / enabling multi-cast delivery.

Moving the channel name (or the registration Id, depending on context) to
the message contents allows us to accept an array of recipients, allowing
the Push service to multi-cast the message. This would significantly lower
the number of requests required for larger broadcasts.

I would recommend having a SHOULD requirement on supporting at least a
thousand targets.

    * Explicit responses for push requests to the push service.

There are a few reasons why a push request may fail: (1) invalid
formatting, (2) invalid channel/target, (3) invalid authentication
information where required. Having a short JSON reply indicating *why* it
failed would be very helpful here.

Furthermore, in case we want to enable a continuous WebSocket-like flow in
the future (a persistent channel would also allow for asynchronous delivery
receipts or an upstream channel), the HTTP response code may not always be
relied upon.

    * Push services to make a best effort for message delivery.

Section 7 currently provides very weak guidance on what level of message
delivery could be expected. I would like to see stronger wording here,
expressing that push services are expected to make a best effort at
delivering the message (possibly through an RFC2119 SHOULD).

    * Synchronous status reporting by the push service.

Section 3 defines that the push service can reply with specific status
codes depending on whether the message could be delivered.

How realistic is it to expect a push service to reply with 200 OK
responses? Does any current service support that? I expect this to become
much more asynchronous over time.

It would also be good to specify the response when a message has been
rejected, for example because of invalid formatting. I would recommend to
change these to be RFC2119 MAYs.

Thanks,
Peter

NB: considering GCM terminology, “channel” maps to “registration Id”

---

From: Martin Thomson <[email-masked]>
Date: Thu, 15 May 2014 09:16:37 -0700

Hi Peter,

Responses inline...

> of monitoring channels (most notably section 6).

I consider the proprietary nature of this interface to be a problem.

> This seems to be missing in the draft. I assume we’ll work on this later?

Doug asked about it too.

That was entirely intentional.  The payload is defined.  It's whatever
you can put in an HTTP PUT.

> I would recommend having a SHOULD requirement on supporting at least a

I think that we need to discuss this further.  There's definitely a
case for optimization.

I didn't include this for a couple of reasons: a) it compromises
end-to-end security, and b) I want to find a better way.

> There are a few reasons why a push request may fail: (1) invalid formatting,
> (2) invalid channel/target, (3) invalid authentication information where
> required. Having a short JSON reply indicating *why* it failed would be very
> helpful here.

I wasn't going to write this down.  It turns out that most of these
failures aren't actionable in any automated fashion, so the
combination of the mechanisms available in HTTP (retry-after, various
status codes) and textual bodies for the purposes of manual diagnosis
seemed adequate to me.

> receipts or an upstream channel), the HTTP response code may not always be

Whoa, why would you want a continuous flow?  Why not actually use
websockets, triggered by a push?

> delivering the message (possibly through an RFC2119 SHOULD).

The purpose of the push server is to perform this function.  I'm not
sure that there is any sense in attempting to mandate that a push
server do what a push server exists for.  Even more so for normative
language.

> Section 3 defines that the push service can reply with specific status codes
> depending on whether the message could be delivered.
>
> How realistic is it to expect a push service to reply with 200 OK responses?

Fairly, I think.

> Does any current service support that?

Yes.

> I expect this to become much more
> asynchronous over time.

That's an interesting perspective.  It turns out that an end-to-end,
positive acknowledgement is an extremely useful property when it comes
to reliable distributed system design.

> change these to be RFC2119 MAYs.

Invalid formatting?  And I'm not following you on the second point
either, what exactly do you think needs changing?