W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2012

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

From: SULLIVAN, BRYAN L <bs3131@att.com>
Date: Thu, 27 Sep 2012 03:51:51 +0000
To: Arthur Barstow <art.barstow@nokia.com>
CC: "public-webapps@w3c.org" <public-webapps@w3c.org>
Message-ID: <59A39E87EA9F964A836299497B686C351001A76E@WABOTH9MSGUSR8D.ITServices.sbc.com>
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

> -----Original Message-----
> From: Arthur Barstow [mailto:art.barstow@nokia.com]
> Sent: Wednesday, September 26, 2012 11:59 AM
> To: SULLIVAN, BRYAN L
> Cc: public-webapps@w3c.org
> Subject: [push-api] Moving Push API to FPWD [Was: Re: [admin] Publishing
> 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.

> 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.

> * 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.

> -Thanks, Art
> 
Received on Thursday, 27 September 2012 03:52:46 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:54 GMT