RE: CfC to publish NFC API WD under new W3C Process

Hi Wayne:

I think my main question is about the following statement:
create an API that would be appropriate for use in Web Browsers, rather than the approach that was to be taken in the SysApps WG

Will the new API still be defined in WebIDL?  Or is that deemed part of the problem?  Or is it something else?

I don’t know what “appropriate” for web browsers means, as long as the API can be called.  I think I’m missing a piece of knowledge.  As one of the co-chairs of Web Payments IG I have interest in how these kinds of APIs evolve, since we are likely to call for some additional development ourselves for other interfaces, I’d like to make sure what we suggest is “appropriate.”

Best regards,
David

From: Wayne Carr [mailto:wayne.carr@linux.intel.com]
Sent: Wednesday, January 21, 2015 11:50 AM
To: Kenneth Rohde Christiansen; Kis, Zoltan; David Ezell
Cc: Bourhis, Jacques; public-nfc@w3.org
Subject: Re: CfC to publish NFC API WD under new W3C Process


I wanted to add a little more on how the new draft fits into the rechartering side of this.  The WG didn't look like it could continue as it was going and successfully recharter and complete a specification.

The NFC WG was identified recently as one of the 4 WGs at the bottom of a list that was generated to try discover WGs that may be having difficulties [1].  Additionally, there isn't a second independent implementation at this point and without two implementations the spec could never get to REC [2].  The WG Charter also expired at the beginning on  1 November 2014 [3].  If a spec can't get to Recomendation (final spec) in a WG, it never gets patent licensing because that only kicks in at REC [4].  For specs that can't get 2 independent implementations, Community Groups can be a better approach - they don't need multiple implementations[5].  Given the current situation, it could be difficult to get approval from the Advisory Committee and Director for rechartering the WG.

Something needs to happen now to try to improve the situation, given that the Charter expired 2 1/2 months ago.

The Bluetooth CG [6] was started recently to create an API that would be appropriate for use in Web Browsers, rather than the approach that was to be taken in the SysApps WG (which is similar to the previous NFC approach).  That looks promising and it looks like that will have implementer support.  The current Web NFC API spec (this CfC) is an attempt to head in a similar direction.  The hope is that would attract interest in implementing and participating from at least one of the major Browser implementers.

One possible plan is to:
1. publish a new TR for the new direction (this CfC)
2. prepare a new Charter reflecting the new approach.   That Charter could require indication of implementer support in the AC Review, and implementation interest from at least one Web Browser implementer in order to pass.
3. if rechartering didn't look possible or failed, the work could move to a Community Group.  If rechartering seems feasible, conduct a CfC on proposing the new charter.
4. conduct a CfC now for asking the Director to relicense specs if the WG drops them or the WG disbands, so that they can be moved to a CG [7].
5. conduct a CfC, pointing to the new TR and proposed draft charter, and asking the Director for a Charter extension to cover the period of rechartering or closing the WG, a 2 or 3 month extension from now.

[1] https://lists.w3.org/Archives/Public/public-w3process/2015Jan/0011.html

[2] http://www.w3.org/2012/09/nfc-wg-charter.html#scope

[3] http://www.w3.org/2012/09/nfc-wg-charter.html

[4] http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential-definition

[5] http://www.w3.org/community/about/agreements/cla/

[6] http://www.w3.org/community/web-bluetooth/

[7] http://www.w3.org/2014/12/relicense.html

On 2015-01-21 00:43, Kenneth Rohde Christiansen wrote:
Hi there,

As Zoltan said, the focus of the new work is an API for the open web, which enabled new and exciting use-cases on the web. This is in contrast to an API for interacting with existing (or legacy) systems.

That said, we are not explicitly blocking people from interacting with existing systems, au contraire - we are just not making it the driving force behind the new spec.

The main focus is:

* An easy-to-use API for the open web, fitting in the open web security model
* Integrate well with contemporary JS/Web API design, such as ES6 (promises, etc)
* Enable exciting new use-cases on the web using NFC technology
* Make sure the tech supported is generally supported by all NFC adapters (ie. we don't try to support legacy/proprietary systems like MIFARE Classic)

Systems that have a different security model, like the so-called systems applications (e.g. "native web apps" on Chrome OS and Firefox OS) or hybrid frameworks (like Cordova) are fine to extend the API to cover all their use-cases as long as this is not exposed to regular sites and web apps. We are OK with adapting the API or adding extension points to the API for such use-cases, as long as it doesn't go against the main focus.

Cheers
Kenneth




On Wed Jan 21 2015 at 9:26:26 AM Kis, Zoltan <zoltan.kis@intel.com<mailto:zoltan.kis@intel.com>> wrote:
Hi David,

In short, the new spec proposal does not attempt to be a full system
API any more, but an API that can be used from web pages, so that the
web security model could be used. This is expected to be easier to
standardize and easier to attract browser implementations.

Expanding a bit, the price for this is that the new proposal
deliberately supports only a part of the functionality usually covered
in NFC implementations.

That does not prevent any platform from implementing e.g. a system
component/app for NFC which would support all NFC Forum and legacy
technologies. We're only saying that at the moment it does not seem
feasible to expose and standardize the full NFC legacy for web pages,
and the security and run-time model for system applications has not
matured enough in SysApps WG to be widely usable. Therefore we need to
re-think the use cases and the API.

The new proposal is far from ready (as we speak, there are github
issues for further clarifying the scope and simplifying the API even
more), but it provides a baseline for the new thinking. Early feedback
from browser makers is good, but likely there is a lot of work ahead.

The CfC basically is for polling interest in rebasing further
development of the spec to this new baseline. Any comments and
alternative ideas are very much welcome.

The old draft will be kept along in github, visible and referenced, as
a low level system API.

Best regards,
Zoltan


On Wed, Jan 21, 2015 at 12:00 AM, David Ezell <David_E3@verifone.com<mailto:David_E3@verifone.com>> wrote:
> Hi Jacques:
>
> Can you explain specifically (and very briefly) how the document is proposed
> to differ from the previous draft?
>
> Best regards,
>
> David Ezell
>
>
>
> From: Bourhis, Jacques [mailto:jacques.bourhis@intel.com<mailto:jacques.bourhis@intel.com>]
> Sent: Tuesday, January 20, 2015 10:32 AM
> To: public-nfc@w3.org<mailto:public-nfc@w3.org>
> Subject: CfC to publish NFC API WD under new W3C Process
>
>
>
> Hello,
>
>
>
> This is a CfC to publish a “The Web NFC API” as a WD and to switch this spec
> to the latest version of the W3C Process.  The current Editor’s Draft that
> Zoltan announced in December
> (https://lists.w3.org/Archives/Public/public-nfc/2014Dec/0003.html ) will be
> used as the basis of this CfC:
>
> http://w3c.github.io/nfc/index.html

>
>
>
> The new Process and information about transition are available at:
>
> http://www.w3.org/2014/Process-20140801/

>
> https://www.w3.org/wiki/ProcessTransition2014#How_does_a_group_decide_to_publish_under_the_new_Process.3F

>
>
>
> This draft is a complete rewrite of the previous FPWD, motivated by the
> desire to make it usable in Web Browsers.   The WG will need to decide (not
> in this CfC) whether to re-charter or to move this work to a Community Group
> and we hope this draft will make the work more attractive to implementers,
> especially Web Browser implementers.   The draft currently has only one
> implementer and it needs at least two to become a W3C REC, while Community
> Groups do not have that requirement.  To continue the work in a WG,
> attracting other implementers is essential.
>
>
>
> By publishing this WD, the group sends a signal to the community to begin
> reviewing the document. The WD reflects where the WG is on this spec at the
> time of publication; it does not necessarily mean that there is consensus on
> the spec's contents.
>
>
>
> If you have any comments or concerns about this CfC, please reply to this
> e-mail by January 30th (end of next week) at the latest.
>
> Positive response is preferred and encouraged, and silence will be
> considered as agreement with the proposal.
>
>
>
> Thanks,
>
> Jacques
>
>
>
> ---------------------------------------------------------------------
> Intel Corporation SAS (French simplified joint stock company)
> Registered headquarters: "Les Montalets"- 2, rue de Paris,
> 92196 Meudon Cedex, France
> Registration Number:  302 456 199 R.C.S. NANTERRE
> Capital: 4,572,000 Euros
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
> ________________________________
> This electronic message, including attachments, is intended only for the use
> of the individual or company named above or to which it is addressed. The
> information contained in this message shall be considered confidential and
> proprietary, and may include confidential work product. If you are not the
> intended recipient, please be aware that any unauthorized use,
> dissemination, distribution or copying of this message is strictly
> prohibited. If you have received this email in error, please notify the
> sender by replying to this message and deleting this email immediately.

________________________________
This electronic message, including attachments, is intended only for the use of the individual or company named above or to which it is addressed. The information contained in this message shall be considered confidential and proprietary, and may include confidential work product. If you are not the intended recipient, please be aware that any unauthorized use, dissemination, distribution or copying of this message is strictly prohibited. If you have received this email in error, please notify the sender by replying to this message and deleting this email immediately.