RE: [manifest] Is the Webapp Manifest spec ready for FPWD?

[EDUARDO FULLEA CARRERA]

Hi all,

First of all let me introduce myself. I work for Telefónica, I am based in 
Madrid and I have recently joined the WebApps WG.

I find very interesting the proposal to specify a Web Apps manifest and thus it 
is the first topic around which I want to start contributing to the group, even 
a co-editor if you accept the offer from a newcomer.

I am looking forward to starting to collaborate with you on this topic.

Best regards,
Eduardo.

-Mensaje original-
De: Adam Barth [mailto:w...@adambarth.com]
Enviado el: jueves, 31 de mayo de 2012 23:24
Para: Arthur Barstow
CC: ext Anant Narayanan; public-webapps; Marcos Caceres; 
public-native-web-a...@w3.org
Asunto: Re: [manifest] Is the Webapp Manifest spec ready for FPWD?

Is anyone besides Mozilla interested in implementing this specification?

Adam


On Wed, May 30, 2012 at 11:36 AM, Arthur Barstow  wrote:
> Hi All,
>
> Besides the thread below that Anant started a few weeks re the Webapp
> Manifest spec, Marcos also started a few threads on this spec ...
>
> What are people's thoughts on whether or not the Quota Management API
> spec is ready for First Public Working Draft (FPWD)?
>
> A "rule of thumb" for FPWD is that the ED's scope should cover most of
> the expected functionality although the depth of some functionality
> may be very shallow, and it is OK if the ED has some open bugs/issues.
>
> -Thanks, AB
>
> On 5/12/12 2:02 PM, ext Anant Narayanan wrote:
>>
>> Hi everyone,
>>
>> I recently joined the webapps working group and I'd like to introduce
>> myself! I work at Mozilla and for the past year or so have been
>> working on our Apps initiative [1]. Our goal has been to make it very
>> easy for developers to build apps using web technologies that can go
>> above and beyond what one might achieve using "native" SDKs on
>> platforms like iOS and Android. We're also trying to make it really
>> easy for users to find and acquire these apps, and use them on any
>> device they happen to own regardless of platform.
>>
>> As part of this work we have devised a simple JSON based manifest
>> format to describe an installable web app, in addition to a few DOM
>> APIs to install and manage these apps. We have a working
>> implementation of the entire system in our latest Nightly builds.
>>
>> The manifest and corresponding APIs are described in an early draft at:
>> http://dvcs.w3.org/hg/app-manifest/raw-file/tip/index.html
>>
>> We'd like to propose using that draft as the basis for a FPWD on this
>> topic. I look forward to your feedback!
>>
>>
>> FAQs
>> --
>> There are a few questions I anticipate in advance, which I will try
>> to answer here, but we can definitely go in more depth as necessary
>> on the
>> list:
>>
>> Q. Why not simply reuse the widgets spec [2]?
>>
>> A. Aside from naming (we're talking about apps, the word "widget"
>> seems to imply an artificial limitation), and replacing XML with
>> JSON; the other fundamental difference is that the widget spec
>> describes packaged apps, whereas our manifest describes hosted apps.
>>
>> We think hosted apps have several interesting and unique web-like
>> properties that are worth retaining. Hosted apps can be made to work
>> offline just as well as packaged apps with AppCache (which is in need
>> of some improvement, but can be made to work!). Packaged apps do have
>> their own advantages though, which we acknowledge, and are open to
>> extending the spec to support both types of apps.
>>
>>
>> Q. Why is the DOM API in the same spec as the manifest?
>>
>> A. One success condition for us would be standardize the DOM APIs so
>> that users will be able to visit any app marketplace that publishes
>> web apps conforming to the manifest spec in any browser and be able
>> to install and use them.
>>
>> We understand there might be other platforms on which a JS API may
>> not be feasible (for eg: A Java API to install and manage these apps
>> is equally important), but that shouldn't preclude us from
>> standardizing the DOM API in browsers. The manifest and the API go
>> hand-in-hand, as we think each of them is dramatically less useful without 
>> the other.
>>
>>
>> Q. Why only one app per origin?
>>
>> A. We originally placed this restriction for security reasons. In
>> Firefox (and most other browsers), the domain name is the primary
>> security boundary
>> - cookie jars, localStorage, XHRs are all bound to the domain. For
>> supporting multiple apps per domain we would have to do some extra
>> work to ensure that (potentially sensitive) permissions granted to
>> one app do not leak into another app from the same domain.
>> Additionally, this lets us use the origin of the domain as a globally
>> unique identifier. Note that app1.example.org and app2.example.org
>> are two different origins under this scheme.
>>
>> That said, we've received a lot of developer feedback about the
>> inconvenience of this restriction, and we are actively looking to
>> lift it [3]. We cannot do this without a few

Push API draft update

[EDUARDO FULLEA CARRERA]

Hi all,

Bryan Sullivan and myself have been working together on updating the Push API 
draft based upon feedback received and the work being driven by Mozilla and 
Telefonica to build a Push solution for Firefox OS (B2G).

You can find it at: http://dvcs.w3.org/hg/push/raw-file/default/index.html

This update does not intend to address yet each and every comment received, as 
some may deserve further discussions, but we think is a good step forward. We 
are looking forward to receiving your feedback.

Thanks and regards,
Eduardo Fullea
Telefonica Digital


Este mensaje se dirige exclusivamente a su destinatario. Puede consultar 
nuestra política de envío y recepción de correo electrónico en el enlace 
situado más abajo.
This message is intended exclusively for its addressee. We only send and 
receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

RE: [push-api] Moving Push API to FPWD [Was: Re: [admin] Publishing specs before TPAC: CfC start deadline is Oct 15]

[EDUARDO FULLEA CARRERA]

On 27 sep 2012 at 05:51:51, SULLIVAN, BRYAN L wrote:
> Thanks for the feedback, Art. I've responded below. I will work on a new
> draft to address as many of your comments as I can.
>
> Thanks,
> Bryan Sullivan | Service Standards | AT&T
> +1-425-580-6514
>
> Arthur Barstow wrote on September 26, 2012 11:59 AM:
>> specs before TPAC: CfC start deadline is Oct 15]
>>
>> On 9/26/12 1:49 PM, ext SULLIVAN, BRYAN L wrote:
>>> We've previously called for any comments to the current Push API draft
>> [1], and would like to promote it to FPWD before TPAC. We haven't
>> received any substantive comments as far as I know, which tells me that
>> it could be in good shape for publication. With the addition of
>> Telefonica (Eduardo) as co-editor and simplification / better alignment
>> with proposals for B2G / Firefox OS, I believe we are in shape for FPWD
>> now. So if I could request a CFC for publication as FPWD before Oct 15,
>> that would be our preference.
>>>
>>> Alternatively we can put this on the agenda for TPAC and
>> discuss/promote it then as possible. But in the absence of substantive
>> comments (which tells me we have addressed most of the comments on the
>> first ED), I think we should be ready for FPWD.
>>>
>>> [1] http://dvcs.w3.org/hg/push/raw-file/default/index.html
>>
>> The requirements for FPWD are relatively loose but because the
>> publication of a FPWD starts a Call for (IP) Exclusions, it is helpful
>> for some reviewers if the breath of the spec is mostly complete,
>> although the depth can certainly be lacking.
>>
>> What is your view on the set of features/scope? Is the ED covering most
>> of the scope? If there are any high priority features missing, what are
>> they?
>>
>
> IMO the ED is covering the scope well. I don't think any high priority 
> features
> are missing. We removed some of the earlier proposed features in the
> current draft.

I agree we are covering most of the scope. It is a matter of adding more depth.
>
>> Based on a very quick scan, I noticed:
>>
>> * The Privacy and Security section is empty and I think it would be
>> helpful if some additional informational was added before FPWD.
>>
>
> I have some text I can add for that.
>
>> * The Specific Service Bindings section is empty. It seems like this
>> should have some information before FPWD, especially if it is going to
>> be a normative section. (Are some of these "bindings" specified outside
>> the W3C?)
>>
>
> I think this was intended to be an informative section, unless at least
> one push service is proposed to be standardized. I can provide
> informative text for SMS, SIP, and OMA Push. Browser-specific push
> serices could also be included.
>
>> * Push Framework - it appears this section should be marked as
>> non-normative. I think it would be helpful if some type of flow diagram
>> was included as well as example application code to use the API
>> (although this non-normative info is not necessarily a blocker for
>> FPWD).
>>
>
> Agreed, this should be informative.

Yes, it is intended to be an informative section. Flow diagram would definitely 
be useful, though not necessary to go to FPWD
>
>> * serverProtocols - what are the expectations for the "valid" set of
>> values; where are they specified?
>>
>
> Good question. We need some means of registration of well-known services
> so the protocols can be recognized.
>
>> Some editorial comments ...
>>
>> * Define "Web Intent Push Service provider", "Push server" and "webapp"
>> or add a link to the definitions.
>>
>
> Will do.
>
>> * Update the references that are out of date (e.g. HTML5).
>>
>
> Will do. This is respec.js magic.
>
>> * Not clear what onopen event is since it isn't part of the PushService
>> API
>>
>
> I think this may have been an omission, or we were thinking to use a listener
> for changes to the readyState as the "open" event. I will check with Eduardo
> on that.

I think for the time being we can remove onopen as there is no other reference 
to it in the draft.

>
>> -Thanks, Art
>>
>



Este mensaje se dirige exclusivamente a su destinatario. Puede consultar 
nuestra política de envío y recepción de correo electrónico en el enlace 
situado más abajo.
This message is intended exclusively for its addressee. We only send and 
receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

RE: CfC: publish FPWD of Push API; deadline October 12

[EDUARDO FULLEA CARRERA]

Hi Jonas,

Thanks for your feedback. See comments inline.

Regards,
Eduardo.

On 6 oct 2012 at 00:06:53, Jonas Sicking wrote:
> Hi All,
>
> As usual, this is not the official mozilla position, as there is no such 
> thing.
>
> Several of us at at mozilla has been looking at push quite a bit
> lately. We still don't have a clear idea of exactly what we think a
> push system should look like. However we are concerned that a system
> like the one in http://dvcs.w3.org/hg/push/raw-file/default/index.html
> would be hard to implement at internet scale in a manner which keeps
> it stable enough to be reliable for webapp developers.
>
One of the merits of the proposed solution is that it is a distributed 
architecture. There is not a single push server for the whole internet but 
instead a variety of servers may arise independently deployed by any kind of 
player (browser vendors, handset manufacturers, MNOs, app developers, etc), 
each of them dealing with as many users as it can/want. This plays in favor of 
scalability.

> First of all the fact that a single message from the application
> server to the notification server can cause millions of messages from
> the notification server to end-user devices makes us concerned that
> it's too easy to DoS the notification server.
>
Of course push servers should have policies that prevent non appropriate 
behavior by apps. We see multicast messages as an optimization to allow sending 
a single message to several webapp instances rather than having to send 
individual messages from the app server to the push server. However those 
servers having problems with this approach may decide not to offer this 
capability.

> Second, using a message passing mechanism puts a lot of responsibility
> on the notification server to never lose any messages. In the event of
> a server crash or server overload the current solution seems to have
> no way for the notification server to avoid dataloss.
>
No push notification server ensures delivery at 100%, not even messaging 
services. Moreover the intent of this framework is to notify (e.g. "You have 
new mails", "You have to update") rather than dealing with the whole 
communication between app server and webapp.

> As points of reference, both Apple and Google has been creating
> similar Push solutions for iOS and Android respectively. Both of these
> systems have struggled with scalability. The result for Apple was to
> delay their solution for a year. The result for google was to
> deprecate the system and they are working on designing something new.
> The system proposed here is more powerful than both Apple's and
> Google's system.
>
As explained above, the distributed architecture will facilitate scalability.

> Finally we also have some security concerns. The messages passed
> through the current API will likely very often end up being cleartext.
> Application developers certainly can make sure to always encrypt the
> messages on the server and then manually decrypt them in the client
> (using for example the new crypt API). The API already requires
> passing two cryptographically strong tokens to the API. Requiring
> developers to also decrypt the message in the client means involving a
> third cryptographically strong token. This is a lot for developers to
> get right and if they don't, there's a risk of privacy or even
> security problems.
>
It is up to the app developers to encrypt the information E2E. I don't see it 
is such a big burden on the app developers. They may though decide it is not 
important for them.

> These are all hard problems to solve, and so far we do not have a
> counter proposal. But I figured that I should raise these concerns
> since they seem relevant.
>
> I'm also very aware that in the past I have pointed at message-passing
> based protocols in the past as mozilla experiments. However lately we
> have started at looking at alternatives due to the scalability issues
> discussed above. Letting people know about this is another reason I'm
> writing this email.
>
Any additional input from your side to enhance the solution is welcome.

> But since we don't have a counter proposal, and since I personally
> generally think that people should be allowed to publish working
> drafts, I don't oppose this FPWD.
>
> But I can't say with certainty at this time that this is an API that
> we're planning on implementing.
>
> / Jonas
>
> On Fri, Oct 5, 2012 at 4:38 AM, Arthur Barstow 
> wrote:
>> The Push API Editors would like to publish a First Public Working Draft
>> of their spec and this is a Call for Consensus to do so, using the
>> following spec as the basis > file/default/index.html>.
>>
>> This CfC satisfies the group's requirement to "record the group's decision
>> to request advancement".
>>
>> By publishing this FPWD, the group sends a signal to the community to
>> begin reviewing the document. The FPWD reflects where the group is on
>> this spec at the time of publicat

[PushAPI] New version of the Push API

[EDUARDO FULLEA CARRERA]

Hi,

There is a new version of the Push API draft available at [1]

The API has been simplified with regards to the previous version and is aligned 
with Mozilla's SimplePush API [2] used by the Firefox OS notification solution 
under development.

Looking forward to getting your feedback on Friday.

Regards,
Eduardo.

[1] http://dvcs.w3.org/hg/push/raw-file/tip/index.html
[2] https://wiki.mozilla.org/WebAPI/SimplePush




Este mensaje se dirige exclusivamente a su destinatario. Puede consultar 
nuestra política de envío y recepción de correo electrónico en el enlace 
situado más abajo.
This message is intended exclusively for its addressee. We only send and 
receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

RE: [PUSH API] Request for CFC on publication of new WD

[EDUARDO FULLEA CARRERA]

Hi,

On 12 jul 2013 at 00:10:49, pira...@gmail.com wrote:
> Seems it still make a distintion between Push Server and Application
> Server. Wouldn't a webapp send some data to a Push Server so it gets
> distributed on all the registered instances without needing to deploy
> a custom Application Server? For server-less webapps this can be a
> problem... :-/

The most usual scenario I can foresee is an application server sending the 
notifications to the web app instance(s). In any case nothing precludes that a 
server-less webapp acts as an app server and sends notification to the Push 
Server for delivery to other instances of the webapp.

> Also, is spected to have some type of federation
> between the diferents Push Server, or it's suposed each one is
> isolated from the others?
>

This API does not mandate any concrete deployment option. Different 
alternatives may be possible in terms of the communication between the Push 
Server and the UA. So Push Servers can work in an isolated fashion, but a 
federated scenario is also possible.


> 2013/7/12 SULLIVAN, BRYAN L :
>> Hi Webapps,
>>
>>
>>
>> Eduardo and I have uploaded a new ED of the Push API at
>> https://dvcs.w3.org/hg/push/raw-file/tip/index.html.
>>
>>
>>
>> This incorporates a variety of changes based upon comments received
>> since the last ED. See
>> https://github.com/telefonicaid/WebAPISpecs/commits/develop/Push for
>> details on these changes:
>>
>> · Correct issues with Pubrules Checker
>>
>> · moving push notification steps to system messages section
>>
>> · escaping character
>>
>> · Push server *may* skip version notifications …
>>
>> · if none, registrations() returns 0 length array …
>>
>> · Complete example code …
>>
>> · Replace references to web intents with "push service extension" …
>>
>> · editorial correction
>>
>> · renaming appToken to pushRegistrationId
>>
>> · splitting pushEndpoint into pushEndpoint and appToken
>>
>> · adding links to promises algorithms
>>
>> · fixing Promise-related descriptions
>>
>> · fix example 1 to use Promise
>>
>> · addressing Jonas' concern about transfering actual content in
>> notific… …
>>
>> · removing serverProtocols
>>
>> · changing version to unsigned long long and clarifying when it is
>> null… …
>>
>> · changing from DOMRequest to Promise
>>
>> · Add bit about semantics of push notification delivery guarantees
>>
>>
>>
>> We would like to request a CFC for publication of a new WD based upon this
>> ED.
>>
>>
>>
>> Thanks,
>>
>> Bryan Sullivan
>>
>>
>
>
>



Este mensaje se dirige exclusivamente a su destinatario. Puede consultar 
nuestra política de envío y recepción de correo electrónico en el enlace 
situado más abajo.
This message is intended exclusively for its addressee. We only send and 
receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

RE: Push API - use parameterized Promise types

[EDUARDO FULLEA CARRERA]

+1

On 20 mar 2014 at 18:13:34, Luke Hoban wrote:
> I agree that there is significant readability value to the consumer of a 
> WebIDL-
> based API spec if the return types of Promise-returning APIs are captured in 
> the
> IDL.  For the same reason that documenting return types is valuable to
> readability even though not enforced in the JavaScript projection of WebIDL.
> The IDL serves a useful documentation purpose even beyond the explicit
> semantics it conveys.
>
> Luke
>
> From: Michael van Ouwerkerk
> Sent: ‎3/‎20/‎2014 11:46
> To: Domenic Denicola
> Cc: public-webapps
> Subject: Re: Push API - use parameterized Promise types
> So it is not normative? It seems it would be very informative though, so still
> worth adding to the spec. But it seems it would be even better if it was 
> changed
> to be normative.
>
> Thanks,
>
> Michael
>
>
>
>
> On Thu, Mar 20, 2014 at 3:39 PM, Domenic Denicola
>  wrote:
> From: Michael van Ouwerkerk 
>> Ah I didn't know it has no effect on return values. Why not?
> Well, I believe it's the same with all WebIDL method return values. If you
> return something that doesn't match the declared return value, that's a spec
> bug, but it has no impact on anything. (This is unlike argument values, where 
> if
> the user passes in something that doesn't match the declared parameter type
> then conversion is performed.)
>
>



Este mensaje se dirige exclusivamente a su destinatario. Puede consultar 
nuestra política de envío y recepción de correo electrónico en el enlace 
situado más abajo.
This message is intended exclusively for its addressee. We only send and 
receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

Progress on Push API

[EDUARDO FULLEA CARRERA]

Hi all,

Last week the Push API editors (AT&T, Telefónica) and other interested parties 
(Mozilla, Google) met to progress this specification. It was a very productive 
meeting in which great support was shown to this piece of work and consensus 
was reached around many topics under discussion. This is a summary of these 
points, which will be incorporated into a new editor's draft shortly. Of course 
feel free to provide any feedback:

- App Server - Push Server protocol: Mozilla and Google to kick-off a new draft 
at the IETF to standardize it.

- Change references to webapp => service worker where it might be unclear that 
only Service Workers should use interfaces & get events etc. other than 
register (because of the need for permissions UI), all interfaces and events to 
SW only

- Security and privacy considerations:  describe that user may revoke 
permissions through UA UI and this will not result in a PushError event to the 
Service Worker

- PushMessage Interface:
- 'version' attribute to be dropped. Webapps do not need to get the 
version number. It can though be part of the wire protocol. The UA 
implementation should take care of 1- not conveying duplicated messages to the 
app, 2- informing the webapp whenever a push message is lost (e.g. detecting a 
gap in an incremental series of 'version').
-'data' attribute is changed to be a DOMString

- PushManager Interface
- to be renamed to PushRegistrationManager.  Navigator to expose: 
navigator.pushRegistrationManager
- Promise register (optional Object registerOptions); => Promise 
register ();  registerOptions parameter is dropped, as long as Service Workers 
require secure connection; to prevent MITM (e.g. snooping of registration info 
over non-secure connection from webapp to webapp server), Push Registrations 
should operate only over secure connections thus the webapp and Service Workers 
code should be served via HTTPS URI scheme; otherwise registration will be 
rejected - take the text lead from Service Workers spec
- A single registration is allowed per webapp
- Promise registrations (); => Promise isRegistered (); as a 
result of single registration allowed
- Promise unregister (DOMString pushRegistrationId); => Promise 
unregister (); as a result of single registration allowed
 - Permission can be persistent: as granted by user permission does 
not have to be reconfirmed for subsequent registration requests if a valid 
permission exists
 - add new function: Promise hasPermission 
();enumeration: Granted, Denied, Default (or NeedToAsk)
- if there is a need to ask for permission it is done by directly 
invoking the register() method
- add to steps that registration will fail if webapp scheme is not HTTPS

- PushRegistration Interface
  - Note that Endpoint may be common among multiple webapp 
instances running at multiple devices;
 - pushRegistrationId is expected to be unique and specific to a 
particular webapp instance running at a specific device;

- Push Events
- PushRegisterMessage => PushError with 'reason' attribute 
(enumeration). Now it covers at least 2 type of errors: 1-new registration is 
needed (e.g. due to fatal error at server), 2- "out of sync" (due to dropping 
"version") will be informational and not imply registration has ended
 - add data processing to event steps

- Errors:
- NoModificationAllowedError => NotFoundError
- AbortError to be kept as is. Note about changing to 
PermissionDeniedError once it is included as a new DOMError (non-resolved bug 
exists)

- History API: does not apply to Service Workers. Note to be removed.

Regards,
Eduardo.




Este mensaje se dirige exclusivamente a su destinatario. Puede consultar 
nuestra política de envío y recepción de correo electrónico en el enlace 
situado más abajo.
This message is intended exclusively for its addressee. We only send and 
receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

RE: Progress on Push API

[EDUARDO FULLEA CARRERA]

Hi Chaals, all,

It was not intended to be an official W3C meeting, but just an informal 
discussion to feed the official standardization track, which AFAIK this mailing 
list is part of. As you may note my previous email was not imposing any 
agreement to the group but just proposing a set of changes and asking from 
feedback from other parties. But sorry if my email has led to any 
misunderstanding.

Regards,
Eduardo.

On 29 abr 2014 at 15:42:40, Charles McCathie Nevile wrote:
> Hi Eduardo, all,
>
> On Tue, 29 Apr 2014 11:00:15 +0200, EDUARDO FULLEA CARRERA 
> wrote:
>
>> Hi all,
>>
>> Last week the Push API editors (AT&T, Telefónica) and other interested
>> parties (Mozilla, Google) met to progress this specification.
>
> Just a gentle reminder that if you are having a meeting there needs to be
> an announcement of it. I don't want to stop people doing work - obviously,
> we encourage that happening and applaud members who take initiative to get
> things done.
>
> But there is a process requirement, that you and your employer agreed to
> when joining the group. It isn't just a quid pro quo for the rest of us
> agreeing to go through a PAG if necessary. It is also based on an
> important legal requirement that standards be developed according to a
> fair process, to avoid being construed as engaging in anti-competitive or
> cartel behaviour.
>
> And of course it is good manners.
>
> As a quick reminder, the general notice times required are 1 week for a
> "distributed" telephone meeting (unless it is a regularly scheduled
> meeting) and 8 weeks for a physical meeting.
>
> If you want to organise a meeting for a particular topic the chairs and
> staff contacts will be very happy to help, both to make sure we meet the
> process requirements and with any necessary logistics. The notice period
> is the only one likely to have any real impact, and there is a way to
> approve shorter notice if it is really necessary.
>
> But I would ask people who want to organise a get-together that they
> provide the notice required by the Process, to ensure that "interested
> parties" in the working group have a fair opportunity to attend.
>
> cheers
>
> Chaals
>



Este mensaje se dirige exclusivamente a su destinatario. Puede consultar 
nuestra política de envío y recepción de correo electrónico en el enlace 
situado más abajo.
This message is intended exclusively for its addressee. We only send and 
receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

RE: Progress on Push API

[EDUARDO FULLEA CARRERA]

On 30 abr 2014 at 00:13:14, Jonas Sicking wrote:
> On Tue, Apr 29, 2014 at 2:00 AM, EDUARDO FULLEA CARRERA 
> wrote:
>> Hi all,
>>
>> Last week the Push API editors (AT&T, Telefónica) and other interested
> parties (Mozilla, Google) met to progress this specification. It was a very
> productive meeting in which great support was shown to this piece of work and
> consensus was reached around many topics under discussion. This is a summary
> of these points, which will be incorporated into a new editor's draft 
> shortly. Of
> course feel free to provide any feedback:
>

We developing the new version at [1], though not yet updated with the changes 
in my previous email.

But if may be a good idea to migrate is to the W3C GitHub official repo. What 
is the process to open the project there? Can anyone help?

Thanks.
Eduardo.

[1] https://github.com/telefonicaid/WebAPISpecs/tree/develop/Push



Este mensaje se dirige exclusivamente a su destinatario. Puede consultar 
nuestra política de envío y recepción de correo electrónico en el enlace 
situado más abajo.
This message is intended exclusively for its addressee. We only send and 
receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

RE: [admin] putting Push API in W3C's Github repo [Was: Re: Progress on Push API]

[EDUARDO FULLEA CARRERA]

On 30 abr 2014 at 16:52:49, Arthur Barstow wrote:
> On 4/30/14 10:44 AM, Arthur Barstow wrote:
>> I'll work with Mike/Robin to create a new "push-api" project, unless
>> you request otherwise. OK?
>
> Eduardo - Mike created this project .

Thanks! Once we deal with open pull requests in current repo will migrate to 
the new one.
A question, who has permission to accept pull requests? At least the editors 
should have.



Este mensaje se dirige exclusivamente a su destinatario. Puede consultar 
nuestra política de envío y recepción de correo electrónico en el enlace 
situado más abajo.
This message is intended exclusively for its addressee. We only send and 
receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

[push-api] Push API draft migrated to the W3C GitHub repo

[EDUARDO FULLEA CARRERA]

Hi all,

Push API draft has been migrated to the W3C GitHub repo:
https://github.com/w3c/push-api

Current version implements just part of the changes indicated in my email some 
days ago.

Regards,
Eduardo.



Este mensaje se dirige exclusivamente a su destinatario. Puede consultar 
nuestra política de envío y recepción de correo electrónico en el enlace 
situado más abajo.
This message is intended exclusively for its addressee. We only send and 
receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

RE: Progress on Push API

[EDUARDO FULLEA CARRERA]

Hi Arnaud,

On 29 abr 2014 at 14:03:46, arnaud.br...@orange.com wrote:
> EDUARDO FULLEA CARRERA wrote on  App Server - Push Server protocol: Mozilla 
> and Google to kick-off a:
> be available ?
>
>>
>> - Change references to webapp => service worker where it might be
>> unclear that only Service Workers should use interfaces & get events
>> etc. other than register (because of the need for permissions UI), all
>> interfaces and events to SW only
> Doesn't this make push slightly harder to implement on "WebOS type" context ?
> It also mean we have a strong requirement on the service worker spec which is
> just starting.
>
>> - Promise register (optional Object registerOptions); =>
>> Promise register ();  registerOptions parameter is dropped, as long as
>> Service Workers require secure connection; to prevent MITM (e.g.
>> snooping of registration info over non-secure connection from webapp to
>> webapp server), Push Registrations should operate only over secure
>> connections thus the webapp and Service Workers code should be served
>> via HTTPS URI scheme; otherwise registration will be rejected - take
>> the text lead from Service Workers spec
>
> This is going to require a lot of clarification I feel, the reason the 
> options were
> added in the first place was to deal with the non standard underlying push
> services, for example to provide app authentification details from the browser
> to the push server (I think this was a requirement on the GCM ? ). I don't see
> how this modification addresses the issue and I don't see why https is
> mandatory either. U
>

Including non-standard parameters in the 'register' method found significant 
opposition as you may have seen in previous messages to this list. It seems 
Google can live without it (maybe they can explain themselves in more detail), 
so having into account it was their proposal originally, we can drop it.

> Could you provide an updated end to end workflow with who's credentials are
> used in the exchanges ?
>
> Thanks
>
>
> 
> _
>
> 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.



Este mensaje se dirige exclusivamente a su destinatario. Puede consultar 
nuestra política de envío y recepción de correo electrónico en el enlace 
situado más abajo.
This message is intended exclusively for its addressee. We only send and 
receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx