W3C home > Mailing lists > Public > public-nfc@w3.org > January 2014

RE: Feedback on the Web NFC API Public Draft

From: Yriarte, Luc <luc.yriarte@intel.com>
Date: Fri, 31 Jan 2014 19:05:24 +0000
To: Michael Roland <mi.roland@gmail.com>, "public-nfc@w3.org" <public-nfc@w3.org>
Message-ID: <8A6036327A83774CAEB939CB8A720E8345805B3F@IRSMSX101.ger.corp.intel.com>
Hi Michael,

Thanks for the feedback. Regarding points 1-2-3, we are planning to add a mean to explicitly get the record TNF - even though we'd like the spec to abstract it as much as possible. Also, yes the NDEFRecordURI is supposed to wrap the well-known type.

Points 4 and 5 - that's a possibility, though it could also be left to error handling.

Point 6, power on/off API is on the way out already. The work in progress is on the w3c github http://w3c.github.io/nfc/proposals/common/nfc.html 

Again, thanks for the feedback and following the work in progress.


-----Original Message-----
From: Michael Roland [mailto:mi.roland@gmail.com] 
Sent: Wednesday, January 29, 2014 10:17 PM
To: public-nfc@w3.org
Subject: Feedback on the Web NFC API Public Draft

Dear NFC working group,

I would like to give some feedback on the Web NFC API public draft:

1. From reading the specification it was unclear to me if the NDEFRecordURI interface wraps an absolute URI type record or the NFC Forum well-known type "uri:nfc:wkt:U" (according to the URI Record Type Definition). I strongly hope it is the latter one because an absolute URI type record without a payload would not make much sense. However, I would suggest to add clarification to the API specification.

2. I would really like to see an NDEFRecordExternal interface wrapping NFC Forum external types. External types allow for more compact custom type names in comparison to MIME types. This is particularly useful to efficiently use the limited space on NFC tags. Also the external type scheme permits clear separation of service provider name spaces due to requiring a domain name prefix for the type name.

3. The item "unknown" in the enumeration NDEFRecordType might be misleading as there is a TNF value unknown with a slightly different meaning.

4. In my opinion it would make sense if the NFCTag interface had an attribute (or method?) to retrieve the maximum supported NDEF message size. This would be useful to determine if a message will fit on a tag.
In an application this information could be used to decide, for instance, if a smartposter record or a simple URI record should be written to a tag. I know that at least Android and Windows permit to retrieve the available memory as per the NFC Forum Tag Operation specifications.

5. Similarly to the above it would be interesting to have a read-only attribute.

6. The powerOn/powerOff methods as well as several of the NFCManager's event handlers seem to be impossible to implement at least on top of the current Android API (but I believe also on top of Windows' proximity API). Are these methods require to have functionality behind them?
Particularly regarding the event handlers I wonder how a developer could find out if a certain event is supported. (Coming from the NFC side, I'm not familiar with web specifications so please point me to the right direction if there is any general guideline on this.)

7. Regarding the terminology section:

a. Is there a reason why there is no definition of a "NFC peer device"
as used within the specification.

b. I would like to note that an NFC tag is not necessarily passive and unpowered. There exist many tags (and devices with NFC tag
functionality) where the device itself is powered while the RF interface is passive (through inductive coupling). There also exist tags (or at least concepts and prototypes) where the RF interface uses active load modulation (i.e. the modulation scheme used with passive tags but with the load modulation part supported by a power supply independent of the RF (NFC) field.

Best regards,

Dr. Michael Roland
Research Associate | NFC Research Lab Hagenberg School of Informatics/Communications/Media

*University of Applied Sciences Upper Austria* *FH O Forschungs & Entwicklungs GmbH* Softwarepark 11
4232 Hagenberg/Austria
Phone: +43 (0)50804-27149
Fax:   +43 (0)50804-27199
E-Mail: michael.roland at fh-hagenberg (.) at
Web: http://www.fh-ooe.at/ | http://www.nfc-research.at/

Firmenbuchgericht/Court of registry: Landesgericht Wels Firmenbuchnummer/Company registration: FN 236733 m
Received on Friday, 31 January 2014 19:05:55 UTC

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