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,
Michael

-- 
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 Thursday, 30 January 2014 16:40:48 UTC