Thanks for starting this thread, Arnaud. I have some responses below, and look forward to discussions on these topics.
Bryan Sullivan -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Monday, June 03, 2013 9:05 AM To: [email protected] 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). 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. - 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. - 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.
