- From: Kis, Zoltan <zoltan.kis@intel.com>
- Date: Tue, 16 Dec 2014 13:08:36 +0200
- To: Don Coleman <dcoleman@chariotsolutions.com>
- Cc: "public-nfc@w3.org" <public-nfc@w3.org>
Hi Don, Thank you for the feedback. I am sorry to be a bit late to announce that the spec has been pulled from under you, and there is a new draft. On Mon, Dec 15, 2014 at 11:17 PM, Don Coleman <dcoleman@chariotsolutions.com> wrote: > http://w3c.github.io/nfc/index.html#the-nfcmessagedata-interface > Does the NfcMessageData.arrayBuffer contain the raw bytes for the NDEF > record? No. > > Does the NfcMessageData.blob contain only the payload data? Yes. > > How do I get additional TNF and/or Record Type data from the NfcMessageData > to interpret the Blob? For these 2 records, I'd need different logic to > parse the payload into something usable. > > TNF: 4 (External) > Type: example.com:patientRecord > Payload: <some binary content> > > TNF: 2 (Media-type) > Type: text/led > Payload: <some binary content> > > Will TNF External (TNF=4) records end up as a Blob? Yes. I was under the impression this (TNF=4) was also listed in section 6.1. but it's not. I will fix this. When reading NFC data, implementations will have the full NDEF records, and can do a translation to NfcMessageData. They can use NfcMessageData.contentType (e.g. application/octet-stream) in order to indicate the type of content delivered to applications. When writing data, NfcMessageType needs to be translated to NDEF records by the implementation. Perhaps we could to list recommended mappings (like with read), but as a first draft, I thought it can be regarded as an implementation detail. Best regards, Zoltan
Received on Tuesday, 16 December 2014 11:10:28 UTC