Re: Feedback on the Web NFC API Public Draft

Michael,

Thanks for the feedback. I'm going to clarify NDEFRecordURI is TNF 1, RTD U
in the next edits.

The record types in the spec mix TNF 1 well-known types (text, uri, smart
poster) and other TNFs like MIME Media, which is potentially confusing. I'm
not sure how we can/should make this clearer.

Adding NDEFRecordExternal is a good idea. I'm also considering
NDEFRecordAbsoluteURI,
which could be used for things like Windows LaunchApp records.

For #3 "unknown" in NDEFRecordType: I'd like to remove NDEFRecordType and
rely on TNF and Payload Type if possible. (NDEF has enough types already.)

For #4, Android has good support for tag meta info, so this could be very
useful. My experience with Windows is the Proximity API only give you NDEF
data and not tag info. Are there other APIs I'm missing?





On Fri, Jan 31, 2014 at 2:05 PM, Yriarte, Luc <luc.yriarte@intel.com> wrote:

> 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.
>
> Luc
>
> -----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,
> 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
>
>
>
>