- From: EDUARDO FULLEA CARRERA <efc@tid.es>
- Date: Thu, 27 Sep 2012 10:09:15 +0000
- To: "SULLIVAN, BRYAN L" <bs3131@att.com>, Arthur Barstow <art.barstow@nokia.com>
- Cc: "public-webapps@w3c.org" <public-webapps@w3c.org>
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 Thursday, 27 September 2012 10:10:46 UTC