Re: Intro & Project Status

Thanks Mark,

The points you made are very helpful in making clear where the spec needs
clarifications. Based on these, and Jeffrey's comments I will make changes
and then will ask for re-review.

Best regards,
Zoltan


On Tue, Sep 8, 2015 at 4:51 AM, Mark James <mrj@rbate.com> wrote:

> On 08/09/15 07:25, Kis, Zoltan wrote:
>
> I'm not understanding the significance of the record order. What is an AAR?
>
> Android Application Record, which can be used for making sure no other
> apps than the specified package will get the dispatched NDEF message. The
> Web NFC record needs to be the first record because intent filters work on
> the first NDEF record in Android (so far), and we do want to differentiate
> on that record when determining whether the message is a Web NFC message or
> not: it contains a URN specific to w3c and web-nfc.
>
>
> OK, that's helpful Zoltan.
>
> The spec currently puts the Web NFC record at the end of the message
> <https://w3c.github.io/web-nfc/#web-nfc-message-format>.
>
> So would a summary of the situation be:
>
> 1. Web NFC messages are ordinary NFC messages that must include a record
> that declares an originating server and URL.
>
> 2. The Web-NFC API is silent on message routing. It just exposes a JS API
> for web pages to send NFC messages with an identified origin, and exposes a
> JS API for web pages to watch for certain types and origins of NFC messages
> that happen to reach it.
>
> 3. However it is likely that receiving OSs, by default, by user
> preference, or by request of installed apps, will route NFC messages that
> have a leading Web NFC record differently than other messages. For example,
> giving a browser first dibs on text and data messages.
>
> 4. If an NFC message without a URL payload is routed to a web browser,
> the Web-NFC API provides means for pages to watch for and process messages
> of chosen types. But only messages with an Web NFC record can be
> selectively watched by URL. Messages routed to a browser that do not match
> the filter of an active watch are (discarded / re-routed to lower-ranked
> apps, including other open browsers  ??).
>
> 5. What happens with NFC messages with a URL payload is again not part of
> the Web-NFC API spec. But the likely situation is that a browser will be
> opened at that URL, with any Web-NFC watches on that page applied to the
> message. If a web page wants to send a URL to a watching web page on
> another device by NFC, that should be done as a non-URI message.
>
> Mark
>