Re: [web-nfc] Web NFC API snapshot release 25 September 2015

On Fri, Sep 25, 2015 at 6:15 PM, Mark James <mrj@rbate.com> wrote:

> On 25/09/15 20:55, Anssi Kostiainen via GitHub wrote:
>
> The URL of the snapshot release is: https://w3c.github.io/web-nfc/releases/20150925/
>
>
> A comment on point 3 of Section 5.1
> <https://w3c.github.io/web-nfc/releases/20150925/#reading-nfc-tags>,
> which reads
>
> *Reading NFC tags when no web site using the Web NFC API is open or in
> focus. This use case is not supported in this version of the specification,
> and is has low priority for future versions as well.*
>
> In what way can a receiving device with no unsuspended Web NFC watches
> tell whether a tag or a peer is being read when those senders transmit
> identical NFC messages?
>

If you want to know whether a received message originates from a tag or
from a peer: at the moment there have been issues with support on every
platform, so at the moment we don't know if a Web NFC message comes from a
peer or from a tag. You can file an issue in order to track this.

The message is the same if the origins of the pages making the push are the
same (or a native 3rd party writes a compatible Web NFC record), and the
content which is pushed is the same. From that point of view it doesn't
matter if the message comes from a tag or peer: what is important is which
origin[/path] it belongs to. At least this API, which is deliberately not a
low level API, considers it so.



> I'd like that when a peer is tapped to either a tag wristband or a Web NFC
> message pusher, both of which are carrying a URL payload, and where the
> peer doesn't have an unsuspended watch for the message's origin (if any),
> to have that URL open on the peer in a new tab.
>

The underlying platform will likely handle this for you, in the way
described above (e.g. on Android it does), you can build an application
based on this. Indeed it is out of scope for the Web NFC API.


> Whatever is said in Section 5.3 should apply to point 3 of Section 5.1,
> with the note that watches can be set to exclusively target tags or peers.
> The use case should be supported, though the way it is supported is out of
> scope of the API.
>
>
The receiving example described in 5.3 refers to point 1 of Section 5.1,
not to point 3. I don't understand the point.

When the feature of telling if a message comes from a tag or peer can be
cleanly implemented on all platforms, we will be glad to expose the source
(tag/peer) on NFCMessage, and also in NFCWatchOptions. Again, you can
create an issue for tracking it.


>
> Here are some other comments that concern the English of the draft:
>

Thank you! We will address these shortly.

Best regards,
Zoltan