The NFC Data Exchange Format (NDEF)
Near Field Communication (NFC) really shines when it comes to peer-to-peer data exchange. However, just as with any other form of data exchange, the two devices have to agree on how to communicate.
Think of it in human terms. If one person speaks German and the other French, neither party will understand the other and no communication can take place. It’s the same for any communication, even between NFC-enabled devices. The two devices must agree upon a standardized method of communication.
Understanding NDEF messages
NDEF messages provide a standardized method for a reader to communicate with an NFC device. The NDEF message contains multiple records, as shown. You get NDEF support only when working with standardized tags — proprietary tags typically don’t provide this support. The NFC standard supports five tag types, all of which support the same NDEF message format.
Each record contains a header and a payload. The header contains useful information for the reader, such as the record ID, its length, and type. The type defines the sort of payload that the record contains. The payload is simply data.
Understanding NDEF records
The NDEF record contains quite a lot of information, as shown. The first eight bits actually contain flags that define how to interpret the rest of the record. Depending on how these flags are set, you can use various resources to discover what the record has to say to you. Of course, the easy way to get through this task is to have an application do it all for you, but the remainder of this section provides you with a useful overview.
The Type Name Format (TNF) field identifies the kind of content that the record contains. Here are the standard kinds of content that you could find in an NDEF record:
- 0 – Empty: The record doesn’t contain any information.
- 1 – Well-known: The data is defined by the Record Type Definition (RTD) specification available from NFC Forum.
- 2 – Multipurpose Internet Mail Extensions (MIME): This is one of the data types normally found in Internet communications as defined by RFC 2046.
- 3 – Absolute Uniform Resource Identifier (URI): This is a pointer to a resource that follows the RFC 3986 syntax.
- 4 – External: This is user-defined data that relies on the format specified by the RTD specification.
- 5 – Unknown: The data type is unknown, which means that you must set the type length to 0.
- 6 – Unchanged: Some payloads are chunked, which means that the data is too large to fit within a single record. In this case, each record contains a piece of the data — a chunk. This TNF indicates that this is not the first record in the chunk — it’s one of the middle or the terminating records. The TNF is unchanged from the kind of data found in the first record of the chunked set.
- 7 – Reserved: This value is reserved for future use.
The IL flag tells you whether the record contains an ID length field. It doesn’t specify the ID length — it just tells you that this value is available.
The SR flag determines whether the record is a short record. A short record is one with a payload length <= 255 bytes. Normal records can have payload lengths exceeding 255 bytes up to a maximum 4 GB. Many use cases require the utmost economy of message size. The SR flag allows the use of a compressed record header by specifying the payload length in a single byte rather than requiring the normal four bytes. The CF flag tells you when a record is chunked. In other words, if you see this flag set, reading a single record won’t provide you with all the data for that data item. You must read all the records associated with that data item to get the complete information about it.
An NDEF message can contain multiple records. The first record in a message has the MB (message begin) flag set to true so that you know that this is the first record. The last record in the message has the ME flag set so that you know this is the last record. All the intermediate records have both the MB and the ME flags set to false.
The Type Length field contains the length of the payload type in bytes. The payload type specifies the precise kind of data found in the payload. For example, just knowing that the TNF is a MIME data type isn’t enough — you must know the precise MIME type (such as “
text/plain“) to process the data.
The Payload Length field contains the length of the payload in bytes. A record may contain up to 4,294,967,295 bytes (or 2^32 – 1 bytes) of data.
The ID Length field contains the length of the ID field in bytes.
The Type comes next. This is a definition of the precise kind of data that the payload contains.
The ID field provides the means for external applications to identify the whole payload carried within an NDEF record. Only the first record contains an ID; middle or terminating NDEF records don’t have an ID field.
Finally, after defining all these particulars, you get to the payload. The payload is the data. However, without knowing all this other information, the payload might not make sense. You need all this other information to understand what sort of data you’re working with.