- From: Bryan Sullivan <blsaws@gmail.com>
- Date: Fri, 05 Oct 2012 13:06:19 +0200
- To: EDUARDO FULLEA CARRERA <efc@tid.es>, "SULLIVAN, BRYAN L" <bs3131@att.com>, Arthur Barstow <art.barstow@nokia.com>
- CC: "public-webapps@w3c.org" <public-webapps@w3c.org>
Hi all, With Eduardo's help I updated the spec [1] for Art's comments as below. Here is a summary from the commit: - security section text - service bindings text - more info on serverProtocols - updated the definitions - additional references (I still need to update the respec biblio) - example code and flow in the Framework section - general editorial cleanup I would like to request a CFC for FPWD publication, if there are no more substantive comments on the updated version. We look forward to a good discussion on this API during TPAC and would like that to occur on a FPWD basis. Thanks Bryan Sullivan [1] http://dvcs.w3.org/hg/push/raw-file/default/index.html On 9/27/12 3:09 AM, "EDUARDO FULLEA CARRERA" <efc@tid.es> wrote: >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
Received on Friday, 5 October 2012 11:06:55 UTC