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

On 2013-12 -18, at 19:56, Alex Russell wrote:

> On Wed, Dec 18, 2013 at 4:46 AM, Anne van Kesteren <annevk@annevk.nl> 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.
> 
> We can imagine the API being standardized and the transport iterating underneath it. That's just good layering.
> 

That is absolutely true.  It is a good design for the functionality of the API to be
independent of the underlying protocol.
A good test in fact would be to implement it over some random protocol
 to make sure it is independent. (This might as with XMLHTTPRequest would,
show that in fact the API is totally protocol linked and the protocol-independence is very weak but 
at least then you know).  

However it is also absolutely true that the web works trough standard protocols where there 
is a massive consensus on which one to use and stable if evolving spec.

Historically, of course, the network protocols have been the key essential and the APIs have been icing
on the cake.  We are entering the new (exciting but dangerous) phase where
are designing more of the system -- APIs and protocols, software arch as well as network system  architceture.
We don't want to throw the baby out with the bathwater, and end up with a nice API but no interop across the net
(or between processes).

There should be statement in the spec of these values, I think.
Maybe two names for the standard, one which includes conformance with the standard protocol.
- This spec is a standard API which gives functionality independent of the protocol?
- To get full conformance, you must implement the standard protocol?

I think it is important to standardize the net protocol early so it gets feedback from protocol people.

Then there is the question of where the protocol done, in the WG or in a new IETF WG etc.

(There is also an interesting question of whether a system is better designed by starting with the
ways that two machines talk to each other across the net and then figuring out how best to surface that 
in in API, which is a rat-hole I am not interested in going down)

Tim

> For instance, if some system decides to deliver push notifications from the SMS baseband protocol, should we, as the web platform, decide that's a bad thing for them to be doing? I say "no", not because I don't want full specs, but because precluding opening this power to developers seems foolhardy at the level of an API contract.
> 
> If we want to recommend that this WG open up a new effort to specify transport and message formats, great. But their API doesn't require it. We shouldn't either.
> 
> Regards
>