Subject: [quicwg/base-drafts] [feature] Push messaging from server to client (#2664)

From: Patrick <[email-masked]>
Date: Wed, 01 May 2019 08:23:03 -0700

Hi all,

based on the work we did on https://www.w3.org/Submission/viwi-protocol/ I want to request adding new functionality which can be implemented with two new VERBS and two new headers.

**Use Case:**
Clients want to subscribe to `urls`, as topics with all the filtering, paging information etc. being expressed in the `url`. This would allow services to push information into clients whenever it is considered necessary.

**Implementation:**
As subscriptions are a "convenience" method compared to polling via `GET`, I propose two new HTTP Verbs

* SUB for subscription to `url`
* UNSUB for un-subscribing from `url`

To control the frequency of updates, we would need additional headers:

* subscription-interval: <timeStepInMs> 
* subscription-updatelimit: <timeStepInMs>

_Periodic_
The optional interval attribute specifies the update frequency in milliseconds for periodic updates, while the optional updatelimit attribute specifies the maximum update rate in milliseconds for ‘on change’ notification. If interval is set, updatelimit is always overruled.

_On change_
If interval is not set, the notification interval is defined ‘on change’ and can be limited by specifying an updatelimit. If an ‘on change’ occours before updatelimit elapsed, an event will be sent as soon as updatelimit elapsed. If there are multiple changes before the next possible update, only the last one know state is sent after updatelimit elapsed.

**Summary**
As this is very close to a regular GET, it would be easy and we could also standardise that per each client-server relation, there would just be a single UDP/IP channel for notifications used and held up. We could also specify that this is a "simplex" connection regarding payload data. as clients would use other HTTP verbs to send data. Each data sent from the server to the client would be exactly the same as a GET response. Very straight forward from my perspective and a valuable extension of the standard for all things "realtime". 

All the Headers we replicate in WebSockets today.. puuuffff gone ;) we can just plain HTTP headers... 

The viwi/RSI spec would than be just rewrote to hold the interface design rules etc. the entire WebSocket parts would be obsolete.

Also It would than not be relevant anymore wether we transmit JSON (text) or binary content.. 

Think of it as a GET with multiple responses.. same formats, payloads, everything.. just not req/res but req/res/res/res/res... including all status codes etc.

Re-Auth would also just be another SUB request with a new Token.. super easy ;)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2664

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 01 May 2019 08:41:41 -0700

Hi, thanks for sharing. 

I'm curious if your request requires anything specific from either QUIC or HTTP/3. If not, then HTTPbis is probably a more appropriate forum for discussion of verbs etc.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2664#issuecomment-488319137

---

From: MikkelFJ <[email-masked]>
Date: Wed, 01 May 2019 15:47:56 +0000 (UTC)

Why don’t you use MQTT for this?
Work is needed on standardising MQTT for QUIC though.

The intervals could be handled through a separate control topic.

Mikkel

On 1 May 2019 at 17.22.57, Patrick ([email-masked]) wrote:

Hi all,

based on the work we did on https://www.w3.org/Submission/viwi-protocol/ I
want to request adding new functionality which can be implemented with two
new VERBS and two new headers.

*Use Case:*
Clients want to subscribe to urls, as topics with all the filtering, paging
information etc. being expressed in the url. This would allow services to
push information into clients whenever it is considered necessary.

*Implementation:*
As subscriptions are a "convenience" method compared to polling via GET, I
propose two new HTTP Verbs

   - SUB for subscription to url
   - UNSUB for un-subscribing from url

   - subscription-interval:
   - subscription-updatelimit:

*Periodic*
The optional interval attribute specifies the update frequency in
milliseconds for periodic updates, while the optional updatelimit attribute
specifies the maximum update rate in milliseconds for ‘on change’
notification. If interval is set, updatelimit is always overruled.

*On change*
If interval is not set, the notification interval is defined ‘on change’
and can be limited by specifying an updatelimit. If an ‘on change’ occours
before updatelimit elapsed, an event will be sent as soon as updatelimit
elapsed. If there are multiple changes before the next possible update,
only the last one know state is sent after updatelimit elapsed.

*Summary*
As this is very close to a regular GET, it would be easy and we could also
standardise that per each client-server relation, there would just be a
single UDP/IP channel for notifications used and held up. We could also
specify that this is a "simplex" connection regarding payload data. as
clients would use other HTTP verbs to send data. Each data sent from the
server to the client would be exactly the same as a GET response. Very
straight forward from my perspective and a valuable extension of the
standard for all things "realtime".

All the Headers we replicate in WebSockets today.. puuuffff gone ;) we can
just plain HTTP headers...

The viwi/RSI spec would than be just rewrote to hold the interface design
rules etc. the entire WebSocket parts would be obsolete.

Also It would than not be relevant anymore wether we transmit JSON (text)
or binary content..

Think of it as a GET with multiple responses.. same formats, payloads,
everything.. just not req/res but req/res/res/res/res... including all
status codes etc.

Re-Auth would also just be another SUB request with a new Token.. super
easy ;)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<https://github.com/quicwg/base-drafts/issues/2664>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AABPGN4Q72UZHDL3HUZBQJTPTGYVDANCNFSM4HJUGB6Q>
.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2664#issuecomment-488321001

---

From: Patrick <[email-masked]>
Date: Wed, 01 May 2019 17:41:35 +0000 (UTC)

well there are a couple of solutions possible. As described in the spec I reference to, WebSockets are used, replicating some of the HTTP headers and a topic. 

With this proposal, I want to reduce friction. Why setup two sockets, if you can handle it via one?

The socket you use for HTTP GET, PUT, POST etc. would have to kept open but could then be used to push information in the other direction.

Think of a multi-repsonse GET request. Super convenient to work with from developers point of view on both ends of the connection. No extra protocol needed, no extra syntax to learn. Just multiple responses to the same GET request, either on an `on change` or a periodic basis, limited to a certain rate by either the client or the server.

**Use-case 1 - chat messages**
```
SUB /messages/
```

initial response
```
290 OK
```

1st data response
```
200 OK
[
  "foo",
  "bar"
]
```

2nd data response (100ms later)
```
200 OK
[
  "foo",
  "bar",
  "boo"
]
```

etc.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2664#issuecomment-488354470

---

From: MikkelFJ <[email-masked]>
Date: Wed, 01 May 2019 11:03:15 -0700

You'd also need to define session resumption if you haven't done so already.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2664#issuecomment-488361118

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 01 May 2019 11:58:55 -0700

Fwiw If you want HTTP semantics, I think the work on web push is a closer match e.g. https://tools.ietf.org/html/rfc8030

Server push with additional policies...

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2664#issuecomment-488379949

---

From: Mike Bishop <[email-masked]>
Date: Wed, 01 May 2019 14:15:20 -0700

Agree with other comments -- this isn't an HTTP/3 mapping issue, it's a proposal for new things at the HTTP semantic layer with some use of existing server push capabilities.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2664#issuecomment-488431239

---

From: Mike Bishop <[email-masked]>
Date: Wed, 01 May 2019 14:15:20 -0700

Closed #2664.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2664#event-2312910400

---

From: Patrick <[email-masked]>
Date: Thu, 02 May 2019 06:20:56 +0000 (UTC)

Agreed, it is.. so where do I file this request best?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2664#issuecomment-488564148

---

From: Martin Thomson <[email-masked]>
Date: Thu, 02 May 2019 02:39:02 -0700

I would start by socializing it with the [HTTP working group](https://httpwg.org/).  That site should provide you with the necessary pointers.

After taking a look at your doc, it's very long and detailed.  What is usually best in these things is to find the kernel of what you want and concentrate on that.  Write a concise summary of what you want (as an Internet-Draft if you a really serious, but a well-consider email is probably best for a first pass).

There's lots of interest in HTTP in this sort of bidirectional messaging stuff, but also a lot of experience with things that have failed (and lots of different theories as to why).  Don't be surprised if you get lots of pointers to other work.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2664#issuecomment-488611564

---

From: Patrick <[email-masked]>
Date: Thu, 02 May 2019 10:06:07 +0000 (UTC)

Will do, thanks!

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2664#issuecomment-488618825