Subject: [Webpush] Alternate/fallback mechanism for receiving

From: Costin Manolache <[email-masked]>
Date: Sat, 20 Feb 2016 16:59:22 +0000

Hi,

I know this may be a bit controversial, and I love both HTTP/2 and push
promises :-)

However, to make it easier to implement/test/deploy, would it be possible
to add a small
change to sections 7, 7.1 and 7.3:

'if http/2 or push promises are not supported on a platform, the PS will
return
a mime-multipart response to the GET request, with the same content as the
push promise'

Nothing else needs to be changed - just instead of a push promise frame, it
will be a mime part.
A UA or PS can support only http/2 - but some may optionally also support
the multipart
response, and accept requests as http/1.1.

While many HTTP/2 stacks are now available, the APIs for push promises are
not very familiar
or well exposed.

This is a problem in particular for receipts, since the AS to PS
communication has to be implemented
by many developers. It will also help in the case of UA to PS, low-end IOT
devices tend to lack
http/2 support.

Costin

---

From: Martin Thomson <[email-masked]>
Date: Sat, 20 Feb 2016 16:02:51 -0800

Why not just implement a proprietary protocol?

On 20 February 2016 at 08:59, Costin Manolache <[email-masked]> wrote:
> However, to make it easier to implement/test/deploy, would it be possible to
> add a small
> _______________________________________________
> Webpush mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webpush
>

---

From: Costin Manolache <[email-masked]>
Date: Sun, 21 Feb 2016 03:22:43 +0000

We already implement an alternate protocol for receipts - based on XMPP,
so not even 'proprietary' :-)

The benefit of having a fallback in webpush standard is that it makes it
easier
for AS to adopt - it is a small extra effort for the PS, but big benefit
for many AS.
Compatibility with existing infrastructure - and backward compatibility in
general -
are good for any protocol. Webpush sending is defined as HTTP/1.1,
subscription and
 delete are HTTP/1.1 compatible - it's only receipts that require push
promises, with
no backward option.

Does anyone have a survey of platforms and APIs supporting push promises ?
Most that I know require custom HTTP implementations, even the
library/platform
supports HTTP/2, promises are not usually exposed and/or well
documented/understood.

Costin

---

From: Martin Thomson <[email-masked]>
Date: Sat, 20 Feb 2016 21:17:59 -0800

> Does anyone have a survey of platforms and APIs supporting push promises ?

Firefox has an API, though that is still pretty-much internal.

nghttp2 has an API:
https://www.nghttp2.org/documentation/types.html#c.nghttp2_on_begin_headers_callback

I'm not opposed to someone defining a fallback, but I think that it
would be better written as a separate document, because it isn't as
simple to do as what you describe by a long stretch.

---

From: Costin Manolache <[email-masked]>
Date: Sat, 20 Feb 2016 23:48:01 -0800

> simple to do as what you describe by a long stretch.

Push message delivery is defined as 'http' - and that's what most
developers will
do.

I'm ok with a separate document - and my main concern is delivery receipts,
since
that's the only point AS developers are required to use low level http2
APIs.
Most implementations I found so far are low level, similar with nghttp2 -
or 'pretty-much internal'.

Getting receipts is a GET request - it seems natural to return the receipts
as body if promises are
not available - json or any other format would be fine too.

Costin