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

[Arthur Barstow]

On 10/5/12 7:06 AM, ext Bryan Sullivan wrote:

- more info on serverProtocols


It still seems like the set of valid strings will need to be defined. 
Perhaps at this point, it would be sufficient if a related Issue Block 
was added. (I'll ask Mike to create a Bugzilla component for the spec.)



- additional references (I still need to update the respec biblio)


Yes, please do as this must be fixed before the FPWD is actually 
published in /TR/. (Robin provided some related info in [1].)



I would like to request a CFC for FPWD publication, if there are no more
substantive comments on the updated version.


I will start a CfC for the FPWD.

(If you haven't prepared a doc for publication as a TR, please see 
 for some information about 
the PubRules and such.)


-Thanks, AB

[1] 



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

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

[Bryan Sullivan]

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"  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ít

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: [push-api] Moving Push API to FPWD [Was: Re: [admin] Publishing specs before TPAC: CfC start deadline is Oct 15]

[SULLIVAN, BRYAN L]

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.bars...@nokia.com]
> Sent: Wednesday, September 26, 2012 11:59 AM
> To: SULLIVAN, BRYAN L
> Cc: public-weba...@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
>