Re: NfcMessageData

I'm glad you're working to make the API simpler. I'm concerned about adding
another abstraction on top of NDEF Records.

It is nice to have abstractions or helper methods for simple cases like for
Text (TNF Well Known, RTD T) and URLs (TNF Well Known, RTF U). Encoding and
decoding text and URIs is something that should be written once and easy
for everyone to use.

There are other cases when you need to be explicit about the data that is
read from the tag or written to the tag, especially for types like TNF Mime
Media and TNF External Type. As a user of the API, I'd like to know the TNF
and the Record Type so I can decode the bytes in the Payload. If I'm
writing data to a tag, I need to explicitly set the TNF, Record Type, and
Payload so my tags to work with other applications. A generic browser
implementation is not going to be able to do this correctly for custom tags.

NDEF and TNF seems a bit obtuse at first, but it's actually pretty straight
forward.

 * The TNF describes how to interpret the Record Type.
 * The Record Type tells how to interpret the data in the Payload.

I'd like you to consider exposing TNF, Record Type and Payload (as an
ArrayBuffer) in the NDEF record. It would be convenient to have another
property with the payload automatically converted to a string where
possible. I have an implementation of this in my NDEF library for Nodejs.
https://github.com/don/ndef-js

    $ npm install ndef
    $ node
    > ndef = require('ndef')
    > ndef.textRecord("hello, world")
    { tnf: 1,
      type: 'T',
      id: [],
      payload: [ 2, 101, 110, 104, 101, 108, 108, 111, 44, 32, 119, 111,
114, 108, 100 ],
      value: 'hello, world'
    }
    > ndef.uriRecord("http://example.com")
    { tnf: 1,
      type: 'U',
      id: [],
      payload: [ 3, 101, 120, 97, 109, 112, 108, 101, 46, 99, 111, 109 ],
      value: 'http://example.com'
    }
    > payload = Buffer(2)
    > payload[0] = 0xFF
    > payload[1] = 0x86
    > ndef.record(ndef.TNF_EXTERNAL_TYPE, "example.com:foo", [], payload)
    { tnf: 4,
      type: 'example.com:foo',
      id: [],
      payload: [ 255, 134 ]
    }

If you don't want to expose TNF and Record Type in the NDEF Record can you
make the raw NDEF bytes readable and writeable from the NDEF Message?



On Tue, Dec 16, 2014 at 6:08 AM, Kis, Zoltan <zoltan.kis@intel.com> wrote:

> 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
>