Re: Intro & Project Status

>
> Zoltan, whenever my Android tablet taps a tag programmed with a URL, the
> default web-browser navigates to that address. So I won't cover the native
> app handler option you raised.
>
>
However, that is a policy/choice your Android tablet has made and
implemented and need not be the same on all user agents.


> Your comments suggest that
>
> (1) A device receiving from a tag or a peer a Web NFC message with a URL
> payload will indeed navigate to this URL, despite the extra Web-NFC record,
> and this will occur even if there's an active Web-NFC watch (no message
> absorption, always a nav). And
>

When you have a default underlying platform policy like the above, then
yes, the native dispatcher may choose to give it to another handler, fetch
the URL, and open it in the browser in a different tab than a listening
page expecting Web NFC content. However, the user agent should declare the
right NFC intent filters on Android. You'd be right saying that the Web NFC
record should then be the first record, and the implementation could use an
AAR for the user agent handling Web NFC. But that is thick implementation
detail.
What boils down to the spec is that it should not mandate the Web NFC
record being the last record in a message.
Is that where you wanted to go with this example?


>
> (2) If the page at the payload URL contains a watch that's activated on
> page load, that watch will receive some form of the original message.
>

Correct, if it switches to the same browsing context. Though then it works
by side effect. I'd like to see user agents configuring correctly the
underlying platform's tag dispatching. Maybe it's worth a note in the spec.

Best regards,
Zoltan