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

On Mon, Sep 28, 2015 at 5:06 PM, Mark James <mrj@rbate.com> wrote:

> On 26/09/15 02:35, Kis, Zoltan wrote:
>
> 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.
> ....
> 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.
>
>
> You're right Zoltan. Section 5.3 only discusses the case in which a web
> browser is in focus on the receiving peer.
>
> The point I was trying to make was that Point 3 of Section 5.1
> <https://w3c.github.io/web-nfc/#reading-nfc-tags> disclaims support for
> reading tags with Web NFC messages when no browser is open. However
>
> (a), If the payload is a Web URL, native NFC support is going to open a
> browser at that URL, so this use-case is inherently supported, though the
> lack of Web NFC API support is reflected in undefined behaviour concerning
> whether that page also gets the URL as a Web NFC message if it has a watch
> on page load,
>
> and
>
> (b), this partial use-case support also applies to reading peers in Section
> 5.3 <https://w3c.github.io/web-nfc/#sending-data-to-nfc-peer-devices>.
>
>
>
Based on how I understand NFC work at least on Android and Linux/neard, the
page that opens at the URL -- both for tags and peers, as a result of a
default or programmed (native) platform behavior -- may indeed use the Web
NFC API, obtain an NFCAdapter, set up watches etc, but it is sure that it
won't get the same message that caused opening the web page. That intent
has already been acted upon and fulfilled. I don't see undefined behavior
in this case for the Web NFC API. The effect of reading a tag or peer and
opening a page is a behavior controlled by the underlying platform and
AFAICT it is independent of the Web NFC API.

Best regards,
Zoltan