Clarify the use cases and the scope of the _Web_ NFC API

[zolkis]

No description provided.

[kenchris]

Feel free to pick stuff from the email I sent to the ML.

[kenchris]

Some info about Mifare Classic which we shouldn't support IMHO: http://www.andytags.com/nfc-tags-compatibility-issues.html#.VL_Cv49GjUY

[don]

I think it makes sense for version 1.0 of this spec to deal with NDEF message and Simple NDEF Exchange Protocol (SNEP) for Peer to Peer.

I'd only add support for Mifare Classic as NDEF. Phones with NXP chipsets can read and write NDEF data from Mifare Classic tags, once they are formatted as NDEF tags. This works, even though Mifare Classic tags are not a true NFC forum tag type. Phones with Broadcom chipsets will not read or write Mifare Classic tags, even if they are formatted as NDEF.

As long as the spec deals with NDEF, the tag type will be (mostly) transparent to the implementation and Mifare Classic support will depend on the underlying hardware.

I'd also move things like Host Card Emulation (HCA) #52, ISO-DEP support #47, NFC-V #54, NFC-A & NFC-F #55 into future versions.

[jyasskin]

It'd be great to get a use-cases document into the repository, along the lines of Web Bluetooth Use Cases or Use cases for the navigator.connect() API.

In addition to the list of devices the spec supports, though, I'd like to see a set of user flows that should work. Two examples I know of are:

1. When the user touches a UA to an NFC tag, a website can open to handle that tag. If multiple websites can handle the tag, there's some way for the user to pick which they prefer.
2. While a user is actively interacting with https://images.example.com/, if they tap their UA with the UA of another user actively interacting with https://images.example.com/, they can send an image across the connection. Maybe this can be generic enough that https://images.example.com/ can send an image to any image-viewing software.

[zolkis]

It could be indeed in a separate doc. For the BT CG, the use cases doc also includes security and privacy sections. For NFC, the latter is also mentioned in the charter, and that would make information scattered across 3 (too many) places. I would actually prefer having use cases and then security and privacy as sections in the NFC spec. It is a relatively short spec anyway, and it seems there are sufficiently limited number of use cases for the web. If it turns too big, we could split use cases off to a separate document later.
Also, based on SysApps experience, it is good if API design choices can be traced back to real use cases and requirements, therefore at least in the beginning I would keep them in the spec.
@kenchris, @don, opinions?

[jyasskin]

I don't mean to argue that it has to be separate from the spec. But the use cases should be descriptions of tasks that users want to perform. http://w3c.github.io/nfc/index.html#use-cases currently just has requirements derived from those tasks.

[zolkis]

Indeed, there were only the 3 main groups of user scenarios presented. I started to add more user scenarios, expect a PR soon.