Re: [web-nfc] "typedef DOMString NDEFRecordType" is expected to be case sensitive or not? (#331)

Small recap. NFC specs says comparisons should be done case-insensitive.

Therefore apps can use mixed case without issues, there is no constraint from NFC.

However, the Web NFC spec (as an NFC _app_) can impose policies like:
1. We allow writing only FQDN and be specific in the spec on how we do comparisons and what is left to applications to figure out about how to specify filtering URL patterns.
2. We lowercase the input from NDEF messages we read, use that in comparisons and present that to the web page/apps.
3. We don't lowercase input from NDEF messages we read, use case-insensitive comparison where the NDEF specs dictate, but expose the unchanged content to web pages/apps.
4. We only accept lowercase input from web pages.
5. We silently convert input from web pages to lowercase.
6. We write input from web pages as it is (consistent with 1).
(7. We can use encoding that is best for the web, an issue discussed earlier.)

Note that out of the above, Kenneth  2+4.

My own opinion: 
- for policy 1, we got useful input from @sleevi (thanks!) that we must have this (with reasons/examples to be exposed in the spec).
- for 2+4, [suggested](https://github.com/w3c/web-nfc/issues/331#issuecomment-531616728) by Kenneth, I am neutral, but if anything, I find it slightly inconsistent, since if we silently lowercase output, why not _silently_ lowercase input as well (policy 5)? So 2+5 would be more consistent. This might simplify things for implementation and developers who don't read the spec, just intuitively want to do something with Web NFC API as it is, write mixed case to tags and wonder why do they get a match when they (for instance) have expected case-sensitive comparisons. 2+5 would fix that, they'd soon realize that we are the knights who say _lowercase_ :).

The alternative to 2+4 (or 2+5) would be case-transparency (3+6): only the comparisons done case-insensitive where the NDEF specs require it, and we are clear about this in the spec, but we don't change content.

IMHO 1+3+6 would be a more consistent set of policies, so there my vote goes. I am open to corrections/suggestions.


-- 
GitHub Notification of comment by zolkis
Please view or discuss this issue at https://github.com/w3c/web-nfc/issues/331#issuecomment-531666633 using your GitHub account

Received on Monday, 16 September 2019 07:19:48 UTC