W3C home > Mailing lists > Public > public-nfc@w3.org > May 2012

RE: draft charter for a W3C NFC working group - gemalto comments

From: GALINDO Virginie <Virginie.GALINDO@gemalto.com>
Date: Sat, 12 May 2012 23:23:32 +0200
To: Samuel Ortiz <sameo@linux.intel.com>
CC: Dave Raggett <dsr@w3.org>, "public-nfc@w3.org" <public-nfc@w3.org>
Message-ID: <1126F161F6F1B24FABD92B850CAFBD6E0102BDD4BF5D@CROEXCFWP04.gemalto.com>
Hi Samuel,

Just to make my remarks clear : I am not challenging the need of LLCP. I agree that the rich exchanges it allows are beneficial and should not be ignored by W3C. I just wanted to warn that the layers of transportation, communication and application should not be mixed in our discussion and deliverables. In case we need in the NFC API to keep contextual information about the link layer (LLCP), lets try to make this abstract and open. 



-----Original Message-----
From: Samuel Ortiz [mailto:sameo@linux.intel.com] 
Sent: Friday, May 11, 2012 4:41 PM
To: GALINDO Virginie
Cc: Dave Raggett; public-nfc@w3.org
Subject: Re: draft charter for a W3C NFC working group - gemalto comments

Hi Virginie,

I agree with you that ideally, when dealing exclusively with NDEFs, apps should only get the NDEFs without having to know anything about the link layer. But yesterday's discussion was about dealing with LLCP data that would not be NDEF encapsulated. While NDEFs have semantics associated to them, you won't be able to interpret raw LLCP payloads unless your webapp is bound to a specific LLCP service and receives/sends this data intentionally. Hence the need for some sort of LLCP handlers that apps could use to bind themselves to a specific (a.k.a. not defined by the NFC Forum) LLCP service.

Also, I would argue about p2p being "just a combination of reader mode and card emulation mode". I think an LLCP link provides much more flexibility and opens a wider range of NFC use cases than the reader or card emulation modes.


On Fri, May 11, 2012 at 03:22:44PM +0200, GALINDO Virginie wrote:
> Dave, and all,
> As gemalto, we welcome the W3C investigation on NFC and have some comments on this draft charter :  
> - by treating only NDEF format, there is a de facto exclusion of payment/transaction applications, as this format is not suitable to such interaction. One of the immediate use case that we see, is the interaction between web pages running in a NFC device and a contactless card which is swapped closed to this device to perform a transaction. This exchange between the device (which is in reader mode) and the contactless card will be held with other data format as NDEF - basically APDU format transported over the contactless interface being compliant with ISO/IEC 14443. 
> - The card emulation mode is excluded from this charter, but the P2P mode is included. The P2P mode is just a combination of reader mode and card emulation mode. I think that there is a mixing of layers in the charter description. If we decide to treat NDEF format, those NDEF can be transmitted to the web application by any mean (card emulation, reader, or P2P modes) and this is not the problem of the web application. To know in which mode it has been received. 
> - On the recent requests related to LLCP, I would recommend that the API deals only with the actual data transported thanks to LLCP, and is not LLCP specific. One of the rationale for that is to tailor a future proof API, which is not specific to the link layer (LLCP in that case). 
> If you wish to make the WG charter consistent with my comments, you may implement the following changes : 
> - Section 2 - scope of the API includes APDU message management
> - Section 3 - card emulation mode exclusion is removed
> Hope this helps. 
> Regards,
> Virginie
> gemalto
> -----Original Message-----
> From: Dave Raggett [mailto:dsr@w3.org]
> Sent: Tuesday, May 08, 2012 11:22 AM
> To: public-nfc@w3.org
> Subject: draft charter for a W3C NFC working group
> See http://www.w3.org/2012/05/nfc-wg-charter.html
> Your comments are welcomed!
> --
> Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett

Intel Open Source Technology Centre
Received on Saturday, 12 May 2012 21:24:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:43:36 UTC