Re: Draft for note to send to Push API editors/authors


On 18 déc. 2013, at 13:46, Anne van Kesteren wrote:

> On Tue, Dec 17, 2013 at 1:52 PM, Konstantinov Sergey
> <twirl@yandex-team.ru> wrote:
>> In general, specifying push server <-> app server protocol is out of scope of Push API spec.
>
> I don't see why it would be really.

Just to think about currently existing contexts
I can actually think of at least 3 different previous protocol dependent API specs which look to me in 2 different situations:

1) XMLHttpRequest

It has dependencies on the HTTP protocol
This protocol is not defined in the API specification as it already existed
The reference link to the IETF edition of HTTP:
- http://www.w3.org/TR/XMLHttpRequest/#refsHTTP



2) Web Sockets

The HTTP protocol is not listed in the dependencies, nor is the Web Socket protocol:
- http://www.w3.org/TR/websockets/#dependencies

But the Web Socket protocol is at least listed in the references:
- http://www.w3.org/TR/websockets/#refsWSP


In this specification the protocol is defined outside of the API spec, in a dedicated IETF RFC:
- http://tools.ietf.org/html/rfc6455




3) Server-Sent Event aka EventSource

The HTTP protocol is not listed in the dependencies
- http://www.w3.org/TR/eventsource/#dependencies

while I think it probably should as there (see reason below)

Looking at the "Processing Model" section, it looks like the working group initially considered an HTTP independent protocol
ex: "For HTTP connections, the Accept header may be included"
Still, the rest of this section make it totally dependent. It has many mentions of HTTP status code and HTTP headers and says:

        "Any other HTTP response code not listed here must cause the user agent to fail the connection."

        "For non-HTTP protocols, UAs should act in equivalent ways."

A Media type (text/event-stream) and a specific HTTP header (Last-Event-ID) are mentioned as registered at IANA

The "protocol" is not exactly defined as a specific one. In fact, it is the format of event-stream "representation" (REST term) which is defined with its whole parsing and interpretation algorithms integrated in the API spec.

It is still referred on Wikipedia as "the Server-Sent Event protocol", and, in fact it is occasionally mentioned  as a protocol in the API spec
- the (non-normative) "Introduction" section of the spec says:
        "To enable servers to push data to Web pages over HTTP or using dedicated server-push protocols"
- the "Note"  section says:
        "Authors are also cautioned that HTTP chunking can have unexpected negative effects on the reliability of this protocol. "
(where "this" looks to refer to the unnamed "Server-Sent Event", or "server-push" protocol)



I'm not sure if a W3C guideline exists for API proposals introducing new protocols
It looks to me that, if it can be quite simple, as the Server-Sent event one, it could be included in the API spec
Otherwise, a dedicated Working Group with an IETF process and mailing list might be required

The Push API spec related protocol may or may not run on top HTTP, on top of Server Sent events, or on top of WebSockets
If no response is expected by the application server from the push server, the Server-Sent event might be an option.
Otherwise, an interesting fact is that the Web Socket protocol is already used by so-called sub-protocols registered at IANA:
- http://www.iana.org/assignments/websocket/websocket.xml

So it could also be an interesting approach








Alexandre Morgaut
Wakanda Community Manager

4D SAS
60, rue d'Alsace
92110 Clichy
France

Standard : +33 1 40 87 92 00
Email :    Alexandre.Morgaut@4d.com
Web :      www.4D.com

Received on Wednesday, 18 December 2013 14:14:46 UTC