- From: Zoltan Kis via GitHub <sysbot+gh@w3.org>
- Date: Wed, 12 Aug 2015 21:45:22 +0000
- To: public-web-nfc@w3.org
@sicking > The best way to expose urls is through normal strings. We agree, for URL's, ```data``` is always a *url-string*. The discussion is whether - ```type``` = "text/uri-list" (MIME type), or "url" (our invented value for this) - or we add a new property ```kind``` = "url" (invented value) and ```type``` is irrelevant for URL (for types other than URL it contains the MIME type). Introducing ```kind``` (as a base type) + having ```type``` for MIME type was criticised by implementors as bringing complexity in validating the possible combinations, and the alternative of diluting ```type``` with extra non-MIME values like "url" is kind of ugly. > I'm not sure what relevance the security model has here? Anne asked why do we hide low level NFC information coming from NDEF records, i.e. why not exposing the lowest level of data to web pages (and leave beautification to libraries). I answered that was an outcome of the security related discussion which was outlined in #2. So in this API we try to focus on web-specific use cases of NFC (using types known in the browser), rely on the browser security mechanisms, and additionally use a data storage format which is specific to Web NFC (by adding a special record to the NDEF messages and storing the writing scope in the message). Nevertheless, we can still choose to expose selected low-level information, but then it will be hard to draw the line between low level and high level API's, with the former being needed to comply with NDEF standards. -- GitHub Notif of comment by zolkis See https://github.com/w3c/web-nfc/issues/26#issuecomment-130457742
Received on Wednesday, 12 August 2015 21:45:23 UTC