Re: status of phase 1 work items?

[apologies for cross posting, this is a subject of interest for 
public-nfc as well]

Hi all,

I'm working on a NFC draft, and we'd like the Secure Elements API to 
stay on the table for phase 2 indeed. Basically all payment-related NFC 
use cases require some S.E. API.

I just joined the sysapps group a couple weeks ago mostly to review the 
existing S.E. APIs and try to make sure it works well with the NFC API. 
I'm only getting started for now, but I'd be glad to review and provide 
editorial help for the S.E. draft.

Cheers

Luc

On 06/21/2013 10:06 AM, GALINDO Virginie wrote:
> Hi Dave and all,
>
> Yes, gemalto will offer editorship on the access to secure element.
>
> We would be happy to have a short slot on that topic provisioned in the agenda of next F2F meeting, to present use cases, requirements, and collect participants comment on the submitted draft [1].
>
> Regards,
> Virginie
>
> [1] http://lists.w3.org/Archives/Public/public-sysapps/2012Jun/0058.html
>
>
> -----Original Message-----
> From: Dave Raggett [mailto:dsr@w3.org]
> Sent: jeudi 20 juin 2013 19:08
> To: Marcos Caceres
> Cc: public-sysapps@w3.org
> Subject: Re: status of phase 1 work items?
>
> On 20/06/13 17:45, Marcos Caceres wrote:
>> Hi Dave,
>>
>> On Thursday, June 20, 2013 at 5:29 PM, Dave Raggett wrote:
>>
>>> We now have first public working drafts for all of the phase 1 work
>>> items with the exception of App URI, and the manifest extension spec.
>>
>> Actually, app: uri was published a while back:
>> http://www.w3.org/TR/2013/WD-app-uri-20130516/
>
> Thanks - somehow that wasn't reflected on the SysApps home page, now fixed.
>
>>
>>> Several of the specs have been updated since the FPWD was published,
>>> and are candidates for updated public working drafts. Any suggestions
>>> for which ones are ready, or soon will be?
>>
>> I would not be in favor of republishing any of the specs until we feel they are ready for LC (or only to meet the heartbeat requirement). In the specs we have published so far, we are still dealing with the feedback from public-script-coord.
>
> The usual idea is to update the public Working Draft to mark progress whenever there has been significant round of changes to the editor's draft.
>
>>> I am also interested in a crisper understanding of where we are in
>>> respect to the manifest and App URI work items.
>>
>> I want to layer app: URI on top of the fetch spec [1] (it's mostly a cosmetic change). But apart from that, app: URI just needs a test suite, the privacy aspects need to be tightened, and then it's ready for LC.
>>
>> Anyone wanna help with the test suite? ;)
>
> Good ask!  We need to do this for all of the phase 1 work items.
>
>>> We handed the JSON
>>> manifest format over to WebApps, with the understanding that we would
>>> develop an extension spec to cover the specific requirements for
>>> SysApps.
>>
>> Right, those extensions remain in the runtime spec for now.
>>
>> See:
>> http://runtime.sysapps.org/#manifest
>>
>>> WebApps have started discussion on the manifest format, along with
>>> the realization that it should be usable for ebooks as well as
>>> packaged apps.
>>
>> It will be interesting to see where the discussion goes with regards to ebooks… there are already popular formats for ebooks (e.g., ePub).
>
>>> However, I am not quite sure where things stand with respect to the
>>> SysApps extension spec, and the SysApps AppURI spec.
>>>
>>> A further question is where are in respect to starting phase 2? Am I
>>> correct in assuming that we are already welcoming contributions on
>>> use cases and requirements? Are we expecting to see draft
>>> specifications in time for the Toronto face to face in late August?
>>
>> I don't think we should rush into those unless we have editorial resources (and currently we are stretched pretty thin). IMHO, we should continue to work hard towards getting the current Phase 1 specs to Last Call by the Toronto meeting.
>
> I suspect that we will get some additional editors for the phase 2 items, e.g. Gemalto may offer to edit the Secure Element API.
>
>

Received on Friday, 21 June 2013 08:22:57 UTC