RE: [PUSH API] Scope of the specification

Greetings,
Sorry for the very long delay some answers inline

 
> -----Original Message-----
> From: arnaud.braud@orange.com [mailto:arnaud.braud@orange.com]
> Sent: Monday, June 03, 2013 9:05 AM
> To: public-webapps@w3.org
> Subject: [PUSH API] Scope of the specification
> 
> Greetings,
> 
> During the last face to face we had a start of a discussion on what
> should fall within the scope of the PUSH specification. I feel we
> should go a little further on this matter.
> 
> As it is designed right now the whole system requires 3 APIs :
> - one between the web application and the browser (the core of this
> spec)
> - one between the push server and the application server
> - one between the push server and the device.
> 
> During the face to face I think we agreed that the first two at the
> very least should fall within the scope of the spec, do we feel the
> third one is trivial enough to not require any sort of specification ?
> 
> <bryan> One key current rationale for leaving this out of scope was not
> its triviality, but rather to be opaque to the different protocols that
> implementations may use between their push server and client, or even
> different bearers (OMA Push for example is spec'd for use across SMS,
> UDP, TCP, HTTP, SIP, and multicast/broadcast bearers - but usually the
> actual used bearer is abstracted from the target application, being a
> function of a push client on device which exposes an API to the
> applications, e.g. Android's broadcast events for WAP Push).
<arnaud> I still feel we could specify what we put in the data part of the messages


> 
> There are other parts that I also feel would require some attention:
> - How the push server is discovered and selected (currently the spec
> speaks of an intent server but with intent currently being shelved I am
> unsure whether this is the right path to take. Also it seemed to me
> that the user journey on proxy selection was rather different than the
> one imagined for web intents).
> 
> <bryan> Service discovery and selection are things that we still need
> to address, and the UI-related obstacles that the browser vendors have
> reported with their Web Intents implementation experiments should not
> prevent us from continuing discussion on these important facets of the
> web architecture. I don't think however that this should be a normative
> dependency upon the Push API as a UA/app interface, but rather a
> separate spec. That separate spec may be useful in establishing a
> pattern for service discovery and selection that is useful for other
> APIs, e.g. payment, and the actions earlier envisioned for Web Intents.


<Arnaud> Same here I feel we need a distinct spec for discovery and selection, is it something this group needs to address or should it be done in another ? If we plan to do it in this group I guess we should set the use cases and look for an editor. And yes it could be reused for other specs, but I do feel its quite distinct from web intents.

> 
> - How a given application registers on the push server and how the push
> server may or may not allow access to its push service (I guess this
> falls within some of the security remarks and the general security
> model of the solution).
> 
> <bryan> Registration today is a largely manual process of establishing
> a developer relationship with a push service provider. The TOCs for
> push server API use are also service-specific. Going beyond that to
> enable dynamic registration and TOC/policy management is a more
> ambitious goal, and could be a part of the 2nd spec mentioned above,
> but discovery/selection is likely to be an easier thing to spec in the
> short term.

<Arnaud> I guess we should try work on both aspects and get them in a second version of the PUSH spec, if the first version requires developers to register to a specific push service wouldn't it make more sense to have a constructor for the manager allowing to input the push service provider ?

> 
> - How the push server should be designed (I think we agreed that
> writing some informational guidelines that would be non normative would
> be a good idea).
> 
> <bryan> I agree that operating store-and-forward messaging systems
> (push being one type) or even simple pass-thru push gateways can be
> complex. We can contribute to these guidelines based upon what we have
> spec'd (going back to pre-2000) in WAP Forum / OMA, and learned through
> operating push services for more than 10 years.
> 
> //Arnaud
> 
> _______________________________________________________________________
> __________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> exploites ou copies sans autorisation. Si vous avez recu ce message par
> erreur, veuillez le signaler a l'expediteur et le detruire ainsi que
> les pieces jointes. Les messages electroniques etant susceptibles
> d'alteration, France Telecom - Orange decline toute responsabilite si
> ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be
> distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, France Telecom - Orange is not liable for
> messages that have been modified, changed or falsified.
> Thank you.
> 


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

Received on Tuesday, 9 July 2013 08:35:48 UTC