IEC 63652-2:2026
(Main)NFC Forum Specifications - Part 2: NFC Data Exchange Format
General Information
- Abstract
IEC 62652-2:2026, the NFC Data Exchange Format (NDEF) specification, is a common data format for NFC Forum Devices. The NFC Data Exchange Format specification defines the NDEF data structure format as well as rules to construct a valid NDEF Message as an ordered and unbroken collection of NDEF Records. Furthermore, it defines the mechanism for specifying the types of application data encapsulated in NDEF Records. The NDEF specification defines only the data structure format to exchange application or service specific data in an interoperable way, and it does not define any NDEF Record Types in detail - NDEF Record Types are defined in separate specifications. This NDEF specification assumes a reliable underlying protocol and therefore this specification does not specify the data exchange between two NFC Forum Devices. An NFC Forum Device can process the NDEF information independently of the way it has received the NDEF Message. Because of the large number of existing message encapsulation formats, record marking protocols, and multiplexing protocols, it is best to be explicit about the design goals of NDEF and, in particular, about what is outside the scope of NDEF.
- Status
- Published
- Publication Date
- 04-Feb-2026
- Technical Committee
- TA 15 - Wireless Power Transfer
- Drafting Committee
- WG 2 - TC 100/TA 15/WG 2
- Current Stage
- PPUB - Publication issued
- Start Date
- 05-Feb-2026
- Completion Date
- 20-Feb-2026
Buy Documents
IEC 63652-2:2026 - NFC Forum Specifications - Part 2: NFC Data Exchange Format/5/2026
IEC 63652-2:2026 - Spécifications du NFC Forum - Partie 2: Format d'échange de données NFC
Overview
IEC 63652-2:2026 - NFC Forum Specifications – Part 2: NFC Data Exchange Format (NDEF) defines the standardized message format essential for communication between NFC Forum Devices. Developed by the International Electrotechnical Commission (IEC), this specification establishes a common structure for encapsulating, identifying, and transferring application data via Near Field Communication (NFC) technology.
NDEF is a compact, binary message format designed for efficient data exchange. It enables devices to wrap one or more application-defined payloads-such as encrypted data, XML, images, or even nested NDEF Messages-into a single, ordered message. The structure supports interoperability across the NFC ecosystem by standardizing how devices create and parse messages, regardless of their origin or the underlying transport protocol.
The NDEF specification strictly covers data formatting and message construction. It intentionally excludes record type definitions (handled by other specifications), transport protocols, and connection logic, ensuring focus and clarity for implementers.
Key Topics
NDEF Message Structure:
- Messages comprise one or more NDEF Records.
- Each message begins and ends explicitly using designated flags to ensure clear boundaries.
NDEF Records:
- Encapsulate a payload described by:
- Type: Defines the payload’s data type using URIs, MIME types, or NFC-specific formats.
- Length: Specifies the number of octets for efficient parsing.
- Identifier (optional): Offers referencing across or within messages.
- Records support ‘short’ (≤255 bytes) or standard layouts per payload size.
- Encapsulate a payload described by:
Payload Handling:
- Records may include single or chunked payloads, allowing partitioning of large or dynamically generated data into manageable pieces.
Design Goals:
- Facilitate encapsulation of arbitrary and unknown-sized documents or files.
- Aggregate logically-associated content (e.g., message plus attachments).
- Prioritize simplicity, efficiency, and compactness for NFC communication.
Scope Limitations:
- Does not define transport protocols or connection management.
- Does not specify details of payload or record content types.
Applications
Adhering to IEC 63652-2:2026 ensures interoperability for a broad range of NFC-enabled applications, such as:
Mobile Payments & Ticketing:
Secure and reliable formatting of transaction or pass data for swift device-to-device or card emulation interactions.Contactless Data Exchange:
Facilitates sharing of digital business cards (vCards), URLs, Bluetooth/WiFi pairing information, or promotional content.IoT and Smart Device Pairing:
Structured handover of configuration parameters between NFC-enabled smart devices.Access Control:
Securely encodes access credentials or temporary permission tokens in NDEF format for entry systems or time-limited events.Digital Identity & Authentication:
Transmits core identity attributes as standardized messages for verification routines in various security contexts.
The true value of the NDEF standard lies in its flexibility-enabling multiple payload types and record arrangements, while also being simple to implement and extend in evolving NFC environments.
Related Standards
NFC Record Type Definition (RTD) Specification:
Defines standardized and custom record types for use within NDEF messages.RFC 2046 / RFC 3986:
Underlays type identification mechanisms by leveraging MIME media types and Uniform Resource Identifiers (URIs).Other NFC Forum Specifications:
Cover physical communication protocols, device operation modes, and additional NFC message structures.ISO/IEC 14443, ISO/IEC 18092:
Specify lower-layer air interface and communication protocols for NFC.
Staying current with NDEF and its related specifications ensures robust, compatible, and efficient NFC application development across industries.
Buy Documents
IEC 63652-2:2026 - NFC Forum Specifications - Part 2: NFC Data Exchange Format/5/2026
IEC 63652-2:2026 - Spécifications du NFC Forum - Partie 2: Format d'échange de données NFC
Get Certified
Connect with accredited certification bodies for this standard
ANCE
Mexican certification and testing association.
Intertek Slovenia
Intertek testing, inspection, and certification services in Slovenia.
LNE (Laboratoire National de Métrologie et d'Essais)
French national laboratory for metrology and testing.
Sponsored listings
Frequently Asked Questions
IEC 63652-2:2026 is a standard published by the International Electrotechnical Commission (IEC). Its full title is "NFC Forum Specifications - Part 2: NFC Data Exchange Format". This standard covers: IEC 62652-2:2026, the NFC Data Exchange Format (NDEF) specification, is a common data format for NFC Forum Devices. The NFC Data Exchange Format specification defines the NDEF data structure format as well as rules to construct a valid NDEF Message as an ordered and unbroken collection of NDEF Records. Furthermore, it defines the mechanism for specifying the types of application data encapsulated in NDEF Records. The NDEF specification defines only the data structure format to exchange application or service specific data in an interoperable way, and it does not define any NDEF Record Types in detail - NDEF Record Types are defined in separate specifications. This NDEF specification assumes a reliable underlying protocol and therefore this specification does not specify the data exchange between two NFC Forum Devices. An NFC Forum Device can process the NDEF information independently of the way it has received the NDEF Message. Because of the large number of existing message encapsulation formats, record marking protocols, and multiplexing protocols, it is best to be explicit about the design goals of NDEF and, in particular, about what is outside the scope of NDEF.
IEC 62652-2:2026, the NFC Data Exchange Format (NDEF) specification, is a common data format for NFC Forum Devices. The NFC Data Exchange Format specification defines the NDEF data structure format as well as rules to construct a valid NDEF Message as an ordered and unbroken collection of NDEF Records. Furthermore, it defines the mechanism for specifying the types of application data encapsulated in NDEF Records. The NDEF specification defines only the data structure format to exchange application or service specific data in an interoperable way, and it does not define any NDEF Record Types in detail - NDEF Record Types are defined in separate specifications. This NDEF specification assumes a reliable underlying protocol and therefore this specification does not specify the data exchange between two NFC Forum Devices. An NFC Forum Device can process the NDEF information independently of the way it has received the NDEF Message. Because of the large number of existing message encapsulation formats, record marking protocols, and multiplexing protocols, it is best to be explicit about the design goals of NDEF and, in particular, about what is outside the scope of NDEF.
IEC 63652-2:2026 is classified under the following ICS (International Classification for Standards) categories: 33.160.60 - Multimedia systems and teleconferencing equipment. The ICS classification helps identify the subject area and facilitates finding related standards.
IEC 63652-2:2026 is available in PDF format for immediate download after purchase. The document can be added to your cart and obtained through the secure checkout process. Digital delivery ensures instant access to the complete standard document.
Standards Content (Sample)
IEC 63652-2 ®
Edition 1.0 2026-02
INTERNATIONAL
STANDARD
NFC Forum Specifications -
Part 2: NFC Data Exchange Format
ICS 33.160.60 ISBN 978-2-8327-1007-4
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or
by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from either
IEC or IEC's member National Committee in the country of the requester. If you have any questions about IEC copyright
or have an enquiry about obtaining additional rights to this publication, please contact the address below or your local
IEC member National Committee for further information.
IEC Secretariat Tel.: +41 22 919 02 11
3, rue de Varembé info@iec.ch
CH-1211 Geneva 20 www.iec.ch
Switzerland
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.
About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigendum or an amendment might have been published.
IEC publications search - IEC Products & Services Portal - products.iec.ch
webstore.iec.ch/advsearchform Discover our powerful search engine and read freely all the
The advanced search enables to find IEC publications by a
publications previews, graphical symbols and the glossary.
variety of criteria (reference number, text, technical With a subscription you will always have access to up to date
committee, …). It also gives information on projects, content tailored to your needs.
replaced and withdrawn publications.
Electropedia - www.electropedia.org
IEC Just Published - webstore.iec.ch/justpublished The world's leading online dictionary on electrotechnology,
Stay up to date on all new IEC publications. Just Published containing more than 22 500 terminological entries in English
details all new publications released. Available online and and French, with equivalent terms in 25 additional languages.
once a month by email. Also known as the International Electrotechnical Vocabulary
(IEV) online.
IEC Customer Service Centre - webstore.iec.ch/csc
If you wish to give us your feedback on this publication or
need further assistance, please contact the Customer
Service Centre: sales@iec.ch.
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
NFC Forum Specifications -
Part 2: NFC Data Exchange Format
FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising all national
electrotechnical committees (IEC National Committees). The object of IEC is to promote international co -operation on all
questions concerning standardization in the electrical and electronic fields. To this end and i n addition to other activities, IEC
publishes International Standards, Technical Specifications, Technical Reports, Publicly Available Specifications (PAS)
and Guides (hereafter referred to as “IEC Publication(s)”). Their preparation is entrusted to technical committees; any
IEC National Committee interested in the subject dealt with may participate in this preparatory work. International,
governmental and non-governmental organizations liaising with the IEC also participate in this preparation. IEC
collaborates closely with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all interested IEC
National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any misinterpretation by any
end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence between any IEC
Publication and the corresponding national or regional publication shall be clearly indicated in the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any services carried
out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and members of its
technical committees and IEC National Committees for any personal injury, property damage or other damage of any nature
whatsoever, whether direct or indirect, or for costs (including legal fees) and expenses arising out of the publication, use
of, or reliance upon, this IEC Publication or any other IEC Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) IEC draws attention to the possibility that the implementation of this document may involve the use of (a) patent(s). IEC
takes no position concerning the evidence, validity or applicability of any claimed patent rights in respect thereof. As of the
date of publication of this document, IEC had not received notice of (a) patent(s), which may be required to implement this
document. However, implementers are cautioned that this may not represent the latest information, which may be obtained
from the patent database available at https://patents.iec.ch. IEC shall not be held responsible for identifying any or all such
patent rights.
IEC 63652-2 has been prepared by technical area 15: Wireless Power Transfer, of IEC technical
committee 100: Audio, video and multimedia systems and equipment. It is an International
Standard.
It is based on NFC Data Exchange Format Version 1.0 and was submitted as a Fast-Track
document.
The text of this International Standard is based on the following documents:
Draft Report on voting
100/4400/FDIS 100/4435/RVD
Full information on the voting for its approval can be found in the report on voting indicated in the
above table.
The language used for the development of this International Standard is English.
The structure and editorial rules used in this publication reflect the practice of the organization
which submitted it.
This document was developed in accordance with ISO/IEC Directives, Part 1 and ISO/IEC
Directives, IEC Supplement, available at www.iec.ch/members_experts/refdocs. The main
document types developed by IEC are described in greater detail at www.iec.ch/publications.
The committee has decided that the contents of this document will remain unchanged until the
stability date indicated on the IEC website under webstore.iec.ch in the data related to the specific
document. At this date, the document will be
• reconfirmed,
• withdrawn, or
• revised.
NOTE In accordance with ISO/IEC Directives, Part 1, IEC PASs are automatically withdrawn after 4 years.
NFC Data Exchange Format
Technical Specification
Version 1.0
2021-08-23
[NDEF]
TM
NFC Forum
Contents
Contents
1 Overview. 1
1.1 Objectives . 1
1.1.1 Design Goals . 1
1.1.2 Anti-Goals . 2
1.2 Applicable Documents or References . 2
1.3 Administration . 3
1.4 Trademark and Logo Usage . 3
1.5 Intellectual Property . 3
1.6 Special Word Usage . 3
1.7 Abbreviations . 3
1.8 Glossary. 4
2 NDEF Mechanisms . 6
2.1 Introduction . 6
2.2 Intended Usage . 6
2.3 NDEF Encapsulation Constructs . 7
2.3.1 NDEF Message . 7
2.3.2 NDEF Record . 8
2.3.3 NDEF Record Chunks . 8
2.4 NDEF Payload Description . 11
2.4.1 NDEF Payload Length . 11
2.4.2 NDEF Payload Type . 11
2.4.3 Payload Identification . 13
2.5 Data Transmission Order. 13
2.6 NDEF Record Layout . 14
2.6.2 MB (Message Begin) . 14
2.6.3 ME (Message End) . 14
2.6.4 CF (Chunk Flag) . 15
2.6.5 SR (Short Record) . 15
2.6.6 IL (ID_LENGTH Field is Present) . 15
2.6.7 TNF (Type Name Format) . 16
2.6.8 TYPE_LENGTH . 18
2.6.9 ID_LENGTH . 18
2.6.10 PAYLOAD_LENGTH . 18
2.6.11 TYPE . 18
2.6.12 ID . 19
2.6.13 PAYLOAD . 19
3 Special considerations . 20
3.1 Internationalization . 20
3.2 Security . 20
3.3 Maximum Field Sizes . 20
3.4 Use of URIs in NDEF . 20
A. Exhibit A . 22
B. Revision History . 23
NFC Data Exchange Format Page ii
Figures
Figures
Figure 1. Example of an NDEF Message with a Set of NDEF Records . 7
Figure 2. NDEF Octet Ordering . 13
Figure 3. NDEF Record Layout . 14
Figure 4. NDEF Short Record Layout (SR=1) . 15
Tables
Table 1: Abbreviations . 4
Table 2. TNF Field Values . 16
Table 3: Revision History . 23
Requirements
Requirements 1: Intended Usage . 7
Requirements 2: NDEF Encapsulation - Message . 8
Requirements 3: NDEF Encapsulation – NDEF Record Chunks . 10
Requirements 4: NDEF Payload Length . 11
Requirements 5: NDEF Payload Type . 12
Requirements 6: Data Transmission Order . 13
Requirements 7: Normal Record Layout . 14
Requirements 8: SR (Short Record) . 15
Requirements 9: IL (ID_LENGTH Field is Present) . 16
Requirements 10: TNF (Type Name Format) . 17
Requirements 11: ID_LENGTH . 18
Requirements 12: PAYLOAD_LENGTH . 18
Requirements 13: TYPE . 19
Requirements 14: ID . 19
Requirements 15: Maximum Field Sizes. 20
Requirements 16: Use of URIs . 21
NFC Data Exchange Format Page iii
Overview
1 Overview
The NFC Data Exchange Format (NDEF) specification defines a message encapsulation format to
exchange information between two NFC Forum Devices.
NDEF is a lightweight, binary message format that can be used to encapsulate one or more
application-defined payloads of arbitrary type and size into a single message construct. Each
payload is described by a type, a length, and an optional identifier.
Type identifiers can be URIs, MIME media types, or NFC-specific types. This latter format
permits compact identification of well known types commonly used in NFC Forum applications,
or self-allocation of a name space for organizations that wish to use it for their own NFC-specific
purposes.
The NDEF Payload Length is an unsigned integer that indicates the number of octets in the
payload. A compact, NDEF short-record layout is provided for very small payloads.
The optional NDEF Payload Identifier enables association of multiple payloads and cross-
referencing between them.
NDEF Payloads can include nested NDEF Messages or chains of linked chunks of length
unknown at the time the data is generated.
NDEF is strictly a message format, which provides no concept of a connection or of a logical
circuit, nor does it address head-of-line problems.
1.1 Objectives
The NFC Data Exchange Format (NDEF) specification is a common data format for NFC Forum
Devices.
The NFC Data Exchange Format specification defines the NDEF data structure format as well as
rules to construct a valid NDEF Message as an ordered and unbroken collection of NDEF
Records. Furthermore, it defines the mechanism for specifying the types of application data
encapsulated in NDEF Records.
The NDEF specification defines only the data structure format to exchange application or service
specific data in an interoperable way, and it does not define any NDEF Record Types in detail —
NDEF Record Types are defined in separate specifications.
This NDEF specification assumes a reliable underlying protocol and therefore this specification
does not specify the data exchange between two NFC Forum Devices.
An NFC Forum Device can process the NDEF information independently of the way it has
received the NDEF Message.
Because of the large number of existing message encapsulation formats, record marking
protocols, and multiplexing protocols, it is best to be explicit about the design goals of NDEF
and, in particular, about what is outside the scope of NDEF.
1.1.1 Design Goals
The design goal of NDEF is to provide an efficient and simple message format that can
accommodate the following:
1. Encapsulating arbitrary documents and entities, including encrypted data, XML documents,
XML fragments, image data like GIF and JPEG files, etc.
NFC Data Exchange Format Page 1
Overview
2. Encapsulating documents and entities initially of unknown size. This capability can be used to
encapsulate dynamically generated content or very large entities as a series of chunks.
3. Aggregating multiple documents and entities that are logically associated in some manner into
a single message. For example, NDEF can be used to encapsulate an NFC-specific message
and a set of attachments of standardized types referenced from that NFC-specific message.
4. Compact encapsulation of small payloads should be accommodated without introducing
unnecessary complexity to parsers.
To achieve efficiency and simplicity, the mechanisms provided by this specification have been
deliberately limited to serve these purposes. NDEF has not been designed as a general message
description or document format such as MIME or XML. Instead, NFC applications can take
advantage of such formats by encapsulating them in NDEF Messages.
1.1.2 Anti-Goals
The following list identifies items outside the scope of NDEF:
1. NDEF does not make any assumptions about the types of payloads that are carried within
NDEF Messages or about the message exchange patterns implied by such messages.
2. NDEF does not in any way introduce the notion of a connection or a logical circuit (virtual or
otherwise).
3. NDEF does not attempt to deal with head-of-line blocking problems that might occur when
stream-oriented protocols like TCP are used.
1.2 Applicable Documents or References
[NFC RTD] NFC Record Type Definition (RTD) Specification, NFC Forum
[RFC 1700] Reynolds, J. and J. Postel, “Assigned Numbers”, STD 2, RFC 1700,
October 1994.
[RFC 1900] B. Carpenter, Y. Rekhter, “Renumbering Needs Work”, RFC 1900, IAB,
February 1996.
[RFC 2046] N. Freed, N. Borenstein, “Multipurpose Internet Mail Extensions
(MIME) Part Two: Media Types” RFC 2046, Innosoft, First Virtual,
November 1996.
[RFC 2047] K. Moore, “MIME (Multipurpose Internet Mail Extensions) Part Three:
Message Header Extensions for Non-ASCII Text”, RFC 2047,
University of Tennessee, November 1996.
[RFC 2048] N. Freed, J. Klensin, J. Postel, “Multipurpose Internet Mail Extensions
(MIME) Part Four: Registration Procedures”, RFC 2048, Innosoft, MCI,
ISI, November 1996.
[RFC 2119] S. Bradner, “Key words for use in RFCs to Indicate Requirement
Levels”, RFC 2119, Harvard University, March 1997.
[RFC 2616] R. Fielding, J. Gettys, J. C. Mogul, H. F. Nielsen, T. Berners-Lee,
“Hypertext Transfer Protocol -- HTTP/1.1”, RFC 2616, U.C. Irvine,
DEC W3C/MIT, DEC, W3C/MIT, W3C/MIT, January 1997.
NFC Data Exchange Format Page 2
Overview
[RFC 2717] R. Petke, I. King, “Registration Procedures for URL Scheme Names”,
BCP: 35, RFC 2717, UUNET Technologies, Microsoft Corporation,
November 1999.
[RFC 2718] L. Masinter, H. Alvestrand, D. Zigmond, R. Petke, “Guidelines for new
URL Schemes”, RFC 2718, Xerox Corporation, Maxware, Pirsenteret,
WebTV Networks, Inc., UUNET Technologies, November 1999.
[RFC 2732] R. Hinden, B. Carpenter, L. Masinter, “Format for Literal IPv6
Addresses in URL's”, RFC 2732, Nokia, IBM, AT&T, December 1999.
[RFC 3023] M. Murata, S. St. Laurent, D. Kohn, “XML Media Types” RFC 3023,
IBM Tokyo Research Laboratory, simonstl.com, Skymoon Ventures,
January 2001.
[RFC 3986] T. Berners-Lee, R. Fielding, L. Masinter, “Uniform Resource Identifiers
(URI): Generic Syntax”, RFC 3986, MIT/LCS, U.C. Irvine, Xerox
Corporation, January 2005.
[URI SCHEME] List of Uniform Resource Identifier (URI) schemes registered by IANA
is available at: http://www.iana.org/assignments/uri-schemes.
1.3 Administration
The NFC Forum NFC Data Exchange Format specification is an open specification supported by
the Near Field Communication Forum, Inc., located at:
401 Edgewater Place, Suite 600
Wakefield, MA, 01880
Tel.: +1 781-876-8955
Fax: +1 781-610-9864
http://www.nfc-forum.org/
1.4 Trademark and Logo Usage
The Near Field Communication Forum’s policy regarding the use of trademarks and logos is
described in the NFC Forum Brand Identity Guidelines and N-Mark Usage Guidelines, which can
be found on the NFC Forum website.
1.5 Intellectual Property
This document conforms to the Intellectual Property guidelines specified in the NFC Forum
Intellectual Property Rights Policy, as outlined in the NFC Forum Rules of Procedure. These
documents are available on the NFC Forum website.
1.6 Special Word Usage
The key words “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT” and “MAY” in this
document are to be interpreted as described in [RFC 2119].
1.7 Abbreviations
Table 1 contains the definitions of the abbreviations and acronyms used in this document.
NFC Data Exchange Format Page 3
Overview
Table 1: Abbreviations
Abbreviation Description
CF Chunk Flag
NDEF NFC Data Exchange Format
QoS Quality of Service
RFU Reserved for Future Use
URI Uniform Resource Identifier
1.8 Glossary
Big Endian
A method of recording or transmitting numerical data of more than one byte, with the
most significant byte placed at the beginning.
Chunked Payload
Application data that has been partitioned into multiple chunks, each carried in a separate
NDEF Record.
NDEF Application
The logical, higher-layer application on an NFC Forum Device using NDEF to format
information for exchange with other NFC Forum Devices.
NDEF Generator
An entity or module that encapsulates application-defined payloads within NDEF
Messages.
NDEF Message
The basic message construct defined by this specification. An NDEF Message contains
one or more NDEF Records.
NDEF Parser
An entity or module that parses NDEF Messages and hands off the payloads to an NDEF
Application.
NDEF Payload
The application data carried within an NDEF Record.
NDEF Payload Identifier
An optional Uniform Resource Identifier (URI) that can be used to identify a payload.
NDEF Payload Length
An unsigned integer that indicates the number of octets in the payload of a single NDEF
Record.
NDEF Payload Type
An identifier that indicates the type of the payload.
NFC Data Exchange Format Page 4
Overview
NDEF Record
An NDEF Record contains a payload described by a type, a length, and an optional
identifier.
NDEF Record Chunk
An NDEF Record that contains a chunk of a payload rather than a full payload.
NDEF Short Record
An NDEF Record that allows payloads or chunks of up to 255 bytes to be carried.
NFC Forum Device
A device that supports at least one communication protocol for at least one
communication mode defined by the NFC Forum specifications. Currently the following
NFC Forum Devices are defined:
NFC Universal Device, NFC Tag Device and NFC Reader Device.
NFC Reader Device
An NFC Forum Device that supports the following Modus Operandi: Reader/Writer. It
can also support Initiator.
NFC Tag Device
An NFC Forum Device that supports at least one communication protocol for Card
Emulator and NDEF.
NFC Universal Device
An NFC Forum Device that supports the following Modus Operandi: Initiator, Target,
and Reader/Writer. It can also support Card Emulator.
NFC Data Exchange Format Page 5
NDEF Mechanisms
2 NDEF Mechanisms
This section describes the mechanisms used in NDEF. The specific syntax for these mechanisms
is defined in Section 3.
2.1 Introduction
NFC Forum Data Exchange Format is a lightweight binary message format designed to
encapsulate one or more application-defined payloads into a single message construct. An NDEF
Message contains one or more NDEF Records, each carrying a payload of arbitrary type and up
to 232-1 octets in size. NDEF Records can be chained together to support larger payloads. An
NDEF Record carries three parameters for describing its payload: the NDEF Payload Length, the
NDEF Payload Type, and an optional NDEF Payload Identifier. The purpose of these parameters
is as follows:
NDEF Payload Length
The NDEF Payload Length indicates the number of octets in the payload (see Section
2.4.1). Providing the NDEF Payload Length within the first 8 octets of an NDEF Record
makes efficient record boundary detection possible.
NDEF Payload Type
The NDEF Payload Type identifier indicates the type of the payload. NDEF supports
Uniform Resource Identifiers (URIs) [RFC 3986], MIME media type constructs [RFC
2046], and an NFC-specific type format as type identifiers (see Section 2.4.2). The
indication of the type of the payload makes it possible to dispatch the payload to the
appropriate NDEF Application.
NDEF Payload Identifier
A payload can be given an optional identifier in the form of an absolute or relative URI
(see Section 2.4.3). The use of an identifier enables payloads that support URI linking
technologies to cross reference other payloads.
2.2 Intended Usage
The intended usage of NDEF is as follows: an NDEF Application is designed to encapsulate one
or more related documents into a single NDEF Message. For example, this can be an application-
specific message along with a set of attachments, each of standardized type. The NDEF Generator
encapsulates each document in NDEF Records as payload or Chunked Payload, indicating the
type and length of the payload along with an optional identifier. The NDEF Records are then put
together to form a single NDEF Message. The NDEF Message is transmitted via NFC to another
NFC Forum Device where it is received and parsed. The NDEF Parser deconstructs the NDEF
Message and hands the payloads to a (potentially different) NDEF Application. Each NDEF
Message has to be sent or received in its entirety.
NDEF Records can encapsulate documents of any type. It is possible to carry MIME messages in
NDEF Records by using a media type such as “message/rfc822”. An NDEF Message can be
encapsulated in an NDEF Record by using an NFC-specific predefined type (see [NFC RTD]).
It is important to note that although MIME entities are supported, there are no assumptions in
NDEF that a record payload is MIME; NDEF makes no assumption concerning the types of the
payloads carried in an NDEF Message. Said differently, an NDEF Parser need not inspect the
NDEF Record type nor peer inside an NDEF Record in order to parse the NDEF Message.
NFC Data Exchange Format Page 6
NDEF Mechanisms
NDEF provides no support for error handling. It is up to the NDEF Parser to determine the
implications of receiving a malformed NDEF Message or an NDEF Message containing a field
length beyond its processing capabilities. It is the responsibility of the NDEF Applications
involved to provide any additional functionality such as QoS that they need as part of the overall
system in which they participate.
Requirements 1: Intended Usage
NFC Forum Device
2.2.1.1 Each NDEF Message SHALL be sent or received in its entirety.
2.3 NDEF Encapsulation Constructs
2.3.1 NDEF Message
An NDEF Message is composed of one or more NDEF Records. The first NDEF Record in an
NDEF Message is marked with the MB (Message Begin) flag set and the last NDEF Record in
the NDEF Message is marked with the ME (Message End) flag set (see Sections 2.6.2 and 2.6.3).
The minimum NDEF Message length is one NDEF Record which is achieved by setting both the
MB and the ME flag in the same NDEF Record. Note that at least two record chunks are required
in orde
...
IEC 63652-2 ®
Edition 1.0 2026-02
NORME
INTERNATIONALE
Spécifications du NFC Forum -
Partie 2: Format d'échange de données NFC
ICS 33.160.60 ISBN 978-2-8327-1510-9
Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite ni
utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et
les microfilms, sans l'accord écrit de l'IEC ou du Comité national de l'IEC du pays du demandeur. Si vous avez des
questions sur le copyright de l'IEC ou si vous désirez obtenir des droits supplémentaires sur cette publication, utilisez
les coordonnées ci-après ou contactez le Comité national de l'IEC de votre pays de résidence.
IEC Secretariat Tel.: +41 22 919 02 11
3, rue de Varembé info@iec.ch
CH-1211 Geneva 20 www.iec.ch
Switzerland
A propos de l'IEC
La Commission Electrotechnique Internationale (IEC) est la première organisation mondiale qui élabore et publie des
Normes internationales pour tout ce qui a trait à l'électricité, à l'électronique et aux technologies apparentées.
A propos des publications IEC
Le contenu technique des publications IEC est constamment revu. Veuillez vous assurer que vous possédez l’édition la
plus récente, un corrigendum ou amendement peut avoir été publié.
Recherche de publications IEC - IEC Products & Services Portal - products.iec.ch
webstore.iec.ch/advsearchform Découvrez notre puissant moteur de recherche et consultez
La recherche avancée permet de trouver des publications gratuitement tous les aperçus des publications, symboles
IEC en utilisant différents critères (numéro de référence, graphiques et le glossaire. Avec un abonnement, vous aurez
texte, comité d’études, …). Elle donne aussi des toujours accès à un contenu à jour adapté à vos besoins.
informations sur les projets et les publications remplacées
ou retirées. Electropedia - www.electropedia.org
Le premier dictionnaire d'électrotechnologie en ligne au
IEC Just Published - webstore.iec.ch/justpublished monde, avec plus de 22 500 articles terminologiques en
Restez informé sur les nouvelles publications IEC. Just anglais et en français, ainsi que les termes équivalents
dans 25 langues additionnelles. Egalement appelé
Published détaille les nouvelles publications parues.
Disponible en ligne et une fois par mois par email. Vocabulaire Electrotechnique International (IEV) en ligne.
Service Clients - webstore.iec.ch/csc
Si vous désirez nous donner des commentaires sur cette
publication ou si vous avez des questions contactez-
nous: sales@iec.ch.
COMMISSION ÉLECTROTECHNIQUE INTERNATIONALE
____________
Spécifications du NFC Forum –
Partie 2: Format d'échange de
données NFC
AVANT-PROPOS
1) La Commission Électrotechnique Internationale (IEC) est une organisation mondiale de normalisation composée de l'ensemble
des comités électrotechniques nationaux (Comités nationaux de l'IEC). L'IEC a pour objet de favoriser la coopération
internationale pour toutes les questions de normalisation dans les domaines de l'électricité et de l'électronique. À cet effet, l'IEC –
entre autres activités – publie des Normes internationales, des Spécifications techniques, des Rapports techniques, des
Spécifications accessibles au public (PAS) et des Guides (ci-après dénommés "Publication(s) de l'IEC"). Leur élaboration est
confiée à des comités d'études, aux travaux desquels tout Comité national intéressé par le sujet traité peut participer. Les
organisations internationales, gouvernementales et non gouvernementales, en liaison avec l'IEC, participent également aux
travaux. L'IEC collabore étroitement avec l'Organisation Internationale de Normalisation (ISO), selon des conditions fixées par
accord entre les deux organisations.
2) Les décisions ou accords officiels de l'IEC concernant les questions techniques représentent, dans la mesure du possible,
un accord international sur les sujets étudiés, étant donné que les Comités nationaux de l'IEC intéressés sont représentés
dans chaque comité d'études.
3) Les Publications de l'IEC se présentent sous la forme de recommandations internationales et sont agréées comme telles par les
Comités nationaux de l'IEC. Tous les efforts raisonnables sont entrepris afin que l'IEC s'assure de l'exactitude du contenu
technique de ses publications; l'IEC ne peut pas être tenue responsable de l'éventuelle mauvaise utilisation ou interprétation qui
en est faite par un quelconque utilisateur final.
4) Dans le but d'encourager l'uniformité internationale, les Comités nationaux de l'IEC s'engagent, dans toute la mesure
possible, à appliquer de façon transparente les Publications de l'IEC dans leurs publications nationales et régionales. Toutes
divergences entre toutes Publications de l'IEC et toutes publications nationales ou régionales correspondantes doivent être
indiquées en termes clairs dans ces dernières.
5) L'IEC elle-même ne fournit aucune attestation de conformité. Des organismes de certification indépendants fournissent des
services d'évaluation de conformité et, dans certains secteurs, accèdent aux marques de conformité de l'IEC. L'IEC n'est
responsable d'aucun des services effectués par les organismes de certification indépendants.
6) Tous les utilisateurs doivent s'assurer qu'ils sont en possession de la dernière édition de cette publication.
7) Aucune responsabilité ne doit être imputée à l'IEC, à ses administrateurs, employés, auxiliaires ou mandataires, y compris ses
experts particuliers et les membres de ses comités d'études et des Comités nationaux de l'IEC, pour tout préjudice causé en cas
de dommages corporels et matériels, ou de tout autre dommage de quelque nature que ce soit, directe ou indirecte, ou pour
supporter les coûts (y compris les frais de justice) et les dépenses découlant de la publication ou de l'utilisation de cette
Publication de l'IEC ou de toute autre Publication de l'IEC, ou au crédit qui lui est accordé.
8) L'attention est attirée sur les références normatives citées dans cette publication. L'utilisation de publications référencées
est obligatoire pour une application correcte de la présente publication.
9) L'IEC attire l'attention sur le fait que la mise en application du présent document peut entraîner l'utilisation d'un ou de plusieurs
brevets. L'IEC ne prend pas position quant à la preuve, à la validité et à l'applicabilité de tout droit de brevet revendiqué à cet
égard. À la date de publication du présent document, l'IEC n'avait pas reçu notification qu'un ou plusieurs brevets pouvaient être
nécessaires à sa mise en application. Toutefois, il y a lieu d'avertir les responsables de la mise en application du présent
document que des informations plus récentes sont susceptibles de figurer dans la base de données de brevets, disponible à
l'adresse https://patents.iec.ch. L'IEC ne saurait être tenue pour responsable de ne pas avoir identifié de tels droits de brevets.
L'IEC 63652-2 a été établie par le domaine technique 15: Transfert d'énergie sans fil, du comité
d'études 100 de l'IEC: Systèmes et équipements audio, vidéo et services de données. Il s'agit d'une
Norme internationale.
Elle est fondée sur le Format d'échange de données NFC, Version 1.0 et a été soumise dans le cadre de
la procédure par voie express.
La présente version bilingue (2026-09) correspond à la version anglaise monolingue publiée en 2026-02.
La version française de cette norme n'a pas été soumise au vote.
La langue employée pour l'élaboration de cette Norme internationale est l'anglais.
Les règles structurelles et rédactionnelles utilisées dans la présente publication reflètent les pratiques en
vigueur au sein de l'organisme responsable de sa soumission.
Ce document a été développé selon les Directives ISO/IEC, Partie 1 et les Directives ISO/IEC,
Supplément IEC, disponibles sous www.iec.ch/members_experts/refdocs. Les principaux types de
documents développés par l'IEC sont décrits plus en détail sous www.iec.ch/publications.
Le comité a décidé que le contenu de ce document ne sera pas modifié avant la date de stabilité indiquée
sur le site web de l'IEC sous webstore.iec.ch dans les données relatives au document recherché. À cette
date, le document sera
• reconduit,
• supprimé, ou
• révisé.
NOTE Conformément aux Directives ISO/IEC, Partie 1, les PAS de l'IEC sont automatiquement supprimées après 4 ans.
Format d'échange de
données NFC
Spécification technique
Version 1.0
2021-08-23 [NDEF]
TM
NFC Forum
Sommaire
Sommaire
1 Vue d'ensemble. 1
1.1 Objectifs . 1
1.1.1 Objets de conception . 1
1.1.2 Anti-objets . 2
1.2 Documents ou références applicables . 2
1.3 Administration . 3
1.4 Utilisation de la marque et du logo . 3
1.5 Propriété intellectuelle . 3
1.6 Usage de termes spéciaux . 3
1.7 Abréviations . 3
1.8 Glossaire. 4
2 Mécanismes NDEF .6
2.1 Introduction . 6
2.2 Usage prévu .6
2.3 Constructions d'une encapsulation NDEF . 7
2.3.1 Message NDEF . 7
2.3.2 Enregistrement NDEF . 8
2.3.3 Fragments d'enregistrement NDEF . 8
2.4 Description d'une Charge utile NDEF .11
2.4.1 Longueur de charge utile NDEF .11
2.4.2 Type de charge utile NDEF .11
2.4.3 Identification d'une charge utile .13
2.5 Ordre de transmission des données.13
2.6 Cliché d'Enregistrement NDEF .14
2.6.2 MB (Message Begin) . 14
2.6.3 ME (Message End) . 14
2.6.4 CF (Chunk Flag) . 15
2.6.5 SR (Short Record) . 15
2.6.6 IL (le champ ID_LENGTH est présent) . 15
2.6.7 TNF (Type Name Format) . 16
2.6.8 TYPE_LENGTH . 18
2.6.9 ID_LENGTH . 18
2.6.10 PAYLOAD_LENGTH . 18
2.6.11 TYPE . 18
2.6.12 ID . 19
2.6.13 PAYLOAD . 19
3 Considérations spéciales . 20
3.1 Internationalisation . 20
3.2 Sécurité . 20
3.3 Tailles de champ maximales . 20
3.4 Utilisation d'URI dans le NDEF . 20
A. Annexe A .22
B. Historique des révisions .23
Format d'échange de données NFC Page ii
Figures
Figures
Figure 1. Exemple de Message NDEF avec un ensemble d'Enregistrements NDEF . 7
Figure 2. Ordonnancement des octets NDEF . 13
Figure 3. Cliché d'Enregistrement NDEF . 14
Figure 4. Cliché d'Enregistrement court NDEF (SR=1) . 15
Tableaux
Tableau 1: Abréviations . 4
Tableau 2. Valeurs du champ TNF . 16
Tableau 3: Historique des révisions . 23
Exigences
Exigences 1: Usage prévu . 7
Exigences 2: Encapsulation NDEF - Message . 8
Exigences 3: Encapsulation NDEF – Fragments d'enregistrement NDEF . 10
Exigences 4: Longueur de charge utile NDEF . 11
Exigences 5: Type de charge utile NDEF . 12
Exigences 6: Ordre de transmission des données . 13
Exigences 7: Cliché d'enregistrement normal . 14
Exigences 8: SR (Short Record) . 15
Exigences 9: IL (le champ ID_LENGTH est présent) . 16
Exigences 10: TNF (Type Name Format) . 17
Exigences 11: ID_LENGTH . 18
Exigences 12: PAYLOAD_LENGTH . 18
Exigences 13: TYPE . 19
Exigences 14: ID . 19
Exigences 15: Tailles de champ maximales. 20
Exigences 16: Utilisation d'URI . 21
Format d'échange de données NFC Page iii
Vue d'ensemble
1 Vue d'ensemble
La spécification Format d'échange de données NFC (NDEF) définit un format d'encapsulation de
message permettant d'échanger des informations entre deux Appareils NFC Forum.
Le NDEF est un format de message binaire léger qui peut être utilisé pour encapsuler dans
une unique construction de message une ou plusieurs charges utiles définies par une
application et de type et de taille arbitraires. Chaque charge utile est décrite par un type, une
longueur, et un identificateur facultatif.
Les identificateurs de type peuvent être des URI, des types de médias MIME, ou des types
spécifiques à la NFC. Ce dernier format permet l'identification compacte de types bien connus
couramment utilisés dans les applications du NFC Forum, ou l'autoattribution d'un espace de
noms pour les organisations qui souhaitent l'utiliser à des fins spécifiques à la NFC.
La Longueur de charge utile NDEF est un entier non signé qui indique le nombre d'octets
de la charge utile. Un cliché d'Enregistrement court NDEF compact est prévu pour les très
petites charges utiles.
L'Identificateur de charge utile NDEF facultatif permet l'association de plusieurs charges
utiles et l'établissement de références croisées entre elles.
Les Charges utiles NDEF peuvent comprendre des Messages NDEF imbriqués ou des
chaînes de fragments liés de longueur inconnue au moment où les données sont générées.
Le NDEF est strictement un format de message, qui ne prévoit pas de concept de connexion
ou de circuit logique, et ne traite pas non plus des problèmes de tête de ligne.
1.1 Objectifs
La spécification Format d'échange de données NFC (NDEF) est un format de données commun
pour les Appareils NFC Forum.
La spécification Format d'échange de données NFC définit le format de structure de données
NDEF ainsi que des règles permettant de construire un Message NDEF valide sous la forme
d'une collection ordonnée et ininterrompue d'Enregistrements NDEF. En outre, elle définit le
mécanisme permettant de spécifier les types de données d'application encapsulées dans des
Enregistrements NDEF.
La spécification NDEF définit uniquement le format de structure de données permettant
d'échanger des données spécifiques à une application ou à un service de manière interopérable, et
ne définit aucun Type d'enregistrement NDEF en détail — les Types d'enregistrement NDEF
sont définis dans des spécifications séparées.
La présente spécification NDEF prend pour hypothèse un protocole sous-jacent fiable, et par
conséquent, cette spécification ne définit pas l'échange de données entre deux Appareils
NFC Forum.
Un Appareil NFC Forum peut traiter les informations NDEF indépendamment de la façon
dont il a reçu le Message NDEF.
En raison du grand nombre de formats d'encapsulation de message, de protocoles de
marquage d'enregistrement et de protocoles de multiplexage existants, il est préférable de se
montrer explicite au sujet des objets de conception du NDEF et, en particulier, de ce qui
n'entre pas dans le domaine d'application du NDEF.
Format d'échange de données NFC Page 1
Vue d'ensemble
1.1.1 Objets de conception
L'objet de conception du NDEF est de fournir un format de message efficace et simple
qui peut remplir les fonctions suivantes:
1. Encapsulation de documents et d'entités arbitraires, y compris des données chiffrées, des
documents XML, des fragments XML, des données d'image comme des fichiers GIF
et JPEG, etc.
2. Encapsulation de documents et d'entités initialement de taille inconnue. Cette capacité peut être
utilisée pour encapsuler un contenu généré dynamiquement ou de très grandes entités sous la
forme d'une série de fragments.
3. Agrégation dans un unique message de plusieurs documents et entités qui sont logiquement
associés d'une certaine manière. Par exemple, le NDEF peut être utilisé pour encapsuler un
message spécifique à la NFC et un ensemble de pièces jointes de types normalisés référencés à
partir de ce message spécifique à la NFC.
4. Il convient qu'une encapsulation compacte de petites charges utiles soit assurée sans
ajouter de complexité inutile dans les analyseurs syntaxiques.
Dans un souci d'efficacité et de simplicité, les mécanismes prévus par la présente spécification
ont été délibérément limités afin de répondre à ces objets. Le NDEF n'a pas été conçu comme
une description de message ou un format de document général tel que MIME ou XML. Au
contraire, les applications NFC peuvent exploiter de tels formats en les encapsulant dans des
Messages NDEF.
1.1.2 Anti-objets
La liste suivante identifie les points extérieurs au domaine d'application du NDEF:
1. Le NDEF ne formule aucune hypothèse quant aux types de charges utiles qui sont
transportées au sein des Messages NDEF ou aux modèles d'échange de messages induits
par de tels messages.
2. Le NDEF n'adopte en aucune manière la notion de connexion ou de circuit logique (virtuel ou
autre).
3. Le NDEF ne cherche pas à traiter les problèmes de blocage en tête de ligne qui sont
susceptibles de se produire lorsque des protocoles orientés flux comme TCP sont utilisés.
1.2 Documents ou références applicables
[NFC RTD]
NFC Record Type Definition (RTD) Specification, NFC Forum
[RFC 1700]
J. Reynolds et J. Postel, "Assigned Numbers", STD 2, RFC 1700, octobre 1994.
[RFC 1900] B. Carpenter, Y. Rekhter, "Renumbering Needs Work", RFC 1900, IAB,
février 1996.
[RFC 2046] N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part
Two: Media Types", RFC 2046, Innosoft, First Virtual, novembre 1996.
K. Moore, "MIME (Multipurpose Internet Mail Extensions) Part Three:
[RFC 2047] Message Header Extensions for Non-ASCII Text", RFC 2047, University of
Tennessee, novembre 1996.
N. Freed, J. Klensin, J. Postel, "Multipurpose Internet Mail Extensions (MIME)
[RFC 2048] Part Four: Registration Procedures", RFC 2048, Innosoft, MCI, ISI,
novembre 1996.
Format d'échange de données NFC Page 2
Vue d'ensemble
[RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, Harvard University, mars 1997.
[RFC 2616] R. Fielding, J. Gettys, J. C. Mogul, H. F. Nielsen, T. Berners-Lee,
"Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, U.C. Irvine,
DEC W3C/MIT, DEC, W3C/MIT, W3C/MIT, janvier 1997.
[RFC 2717] R. Petke, I. King, "Registration Procedures for URL Scheme Names",
BCP: 35, RFC 2717, UUNET Technologies, Microsoft Corporation,
novembre 1999.
[RFC 2718] L. Masinter, H. Alvestrand, D. Zigmond, R. Petke, "Guidelines for new
URL Schemes", RFC 2718, Xerox Corporation, Maxware, Pirsenteret,
WebTV Networks, Inc., UUNET Technologies, novembre 1999.
[RFC 2732] R. Hinden, B. Carpenter, L. Masinter, "Format for Literal IPv6
Addresses in URL's", RFC 2732, Nokia, IBM, AT&T, décembre 1999.
[RFC 3023] M. Murata, S. St. Laurent, D. Kohn, "XML Media Types", RFC 3023,
IBM Tokyo Research Laboratory, simonstl.com, Skymoon Ventures,
janvier 2001.
[RFC 3986] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource Identifiers
(URI): Generic Syntax", RFC 3986, MIT/LCS, U.C. Irvine, Xerox
Corporation, janvier 2005.
[URI SCHEME] Une liste des schémas d'Identificateurs de ressource universels (URI)
enregistrés par l'IANA est disponible à l'adresse suivante:
http://www.iana.org/assignments/uri-schemes.
1.3 Administration
La spécification Format d'échange de données NFC du NFC Forum est une spécification ouverte
prise en charge par le Near Field Communication Forum, Inc., sis:
401 Edgewater Place, Suite 600
Wakefield, MA, 01880
Tél.: +1 781-876-8955
Fax: +1 781-610-9864
http://www.nfc-forum.org/
1.4 Utilisation de la marque et du logo
La politique du Near Field Communication Forum concernant l'utilisation des marques et des
logos est décrite dans les NFC Forum Brand Identity Guidelines et dans les N-Mark Usage
Guidelines, qui peuvent être consultées sur le site web du NFC Forum.
1.5 Propriété intellectuelle
Le présent document est conforme aux Lignes directrices de propriété intellectuelle spécifiées
dans la Politique des droits de propriété intellectuelle du NFC Forum, comme cela est
indiqué dans les Règles de procédure du NFC Forum. Ces documents sont disponibles sur le
site web du NFC Forum.
Format d'échange de données NFC Page 3
Vue d'ensemble
1.6 Usage de termes spéciaux
Dans le présent document, les mots et expressions clés "DOIT", "DOIVENT", "NE DOIT
PAS", "NE DOIVENT PAS", "IL CONVIENT QUE", "IL NE CONVIENT PAS QUE",
"PEUT" et "PEUVENT" doivent être interprétés comme cela est décrit dans la [RFC 2119].
1.7 Abréviations
Le Tableau 1 contient les définitions des abréviations et acronymes utilisés dans le présent document.
Tableau 1: Abréviations
Abréviation Description
CF (Chunk Flag) Fanion de fragment
NDEF (NFC Data Exchange Format) Format d'échange de données NFC
QoS (Quality of Service) Qualité de service
RFU (Reserved for Future Use) Réservé à un usage ultérieur
URI (Uniform Resource Identifier) Identificateur de ressource universel
1.8 Glossaire
Gros-boutiste
Méthode d'enregistrement ou de transmission de données numériques de plusieurs
octets, l'octet de poids fort étant placé au début.
Charge utile fragmentée
Données d'application qui ont été divisées en plusieurs fragments, chacun étant transporté
dans un Enregistrement NDEF séparé.
Application NDEF
Application logique de couche supérieure sur un Appareil NFC Forum utilisant
le NDEF pour formater des informations destinées à être échangées avec d'autres
Appareils NFC Forum.
Générateur NDEF
Entité ou module qui encapsule des charges utiles définies par une application au
sein de Messages NDEF.
Message NDEF
Construction de message de base définie par la présente spécification. Un message
NDEF contient un ou plusieurs enregistrements NDEF.
Analyseur syntaxique NDEF
Entité ou module qui analyse syntaxiquement les Messages NDEF et transmet les
charges utiles à une Application NDEF.
Charge utile NDEF
Données d'application transportées au sein d'un Enregistrement NDEF.
Format d'échange de données NFC Page 4
Vue d'ensemble
Identificateur de charge utile NDEF
Identificateur de ressource universel (URI) facultatif qui peut être utilisé pour identifier
une charge utile.
Longueur de charge utile NDEF
Entier non signé qui indique le nombre d'octets de la charge utile d'un unique
Enregistrement NDEF.
Type de charge utile NDEF
Identificateur qui indique le type de la charge utile.
Enregistrement NDEF
Un enregistrement NDEF contient une charge utile décrite par un type, une
longueur et un identifiant facultatif.
Fragment d'enregistrement NDEF
Enregistrement NDEF qui contient un fragment de charge utile plutôt qu'une charge
utile complète.
Enregistrement court NDEF
Enregistrement NDEF qui permet à des charges utiles ou des fragments allant
jusqu'à 255 octets d'être transportés.
Appareil NFC Forum
Dispositif qui prend en charge au moins un protocole de communication pour au moins
un mode de communication défini par les spécifications du NFC Forum. Les dispositifs
du NFC Forum suivants sont actuellement définis:
Appareil universel NFC, Appareil à étiquettes NFC et Appareil lecteur NFC.
Dispositif de lecteur NFC
Dispositif du NFC Forum qui prend en charge le mode opératoire suivant:
Lecteur/Enregistreur. Il peut également prendre en charge l'initiateur.
Dispositif d'étiquette NFC
Dispositif du NFC Forum qui prend en charge au moins un protocole de
communication pour l'Émulateur de cartes et le format NDEF.
Dispositif universel NFC
Dispositif du NFC Forum qui prend en charge le mode opératoire suivant: Initiateur,
Cible et Lecteur/Enregistreur. Il peut également prendre en charge l'Émulateur de
cartes.
Format d'échange de données NFC Page 5
Mécanismes NDEF
2 Mécanismes NDEF
Le présent article décrit les mécanismes utilisés dans le NDEF. La syntaxe spécifique de ces
mécanismes est définie à l'Article 3.
2.1 Introduction
Le Format d'échange de données NFC Forum est un format de message binaire léger conçu pour
encapsuler dans une unique structure de message une ou plusieurs charges utiles définies par une
application. Un Message NDEF contient un ou plusieurs Enregistrements NDEF, chacun
transportant une charge utile de type arbitraire et d'une taille allant jusqu'à 232-1 octets. Les
Enregistrements NDEF peuvent être enchaînés entre eux pour supporter des charges utiles plus
importantes. Un Enregistrement NDEF transporte trois paramètres pour décrire sa charge utile: la
Longueur de charge utile NDEF, le Type de charge utile NDEF, et un Identificateur de charge
utile NDEF facultatif. L'objet de ces paramètres est le suivant:
Longueur de charge utile NDEF
La Longueur de charge utile NDEF indique le nombre d'octets de la charge utile (voir
2.4.1). La fourniture de la Longueur de charge utile NDEF dans les 8 premiers octets
d'un Enregistrement NDEF rend possible la détection efficace des limites de
l'enregistrement.
Type de charge utile NDEF
L'identificateur Type de charge utile NDEF indique le type de la charge utile.
Le NDEF prend en charge les Identificateurs de ressource universels (URI)
[RFC 3986], les constructions de type de médias MIME [RFC 2046], et un format de
type spécifique à la NFC en tant qu'identificateurs de type (voir 2.4.2). L'indication du
type de la charge utile rend possible l'envoi de la charge utile vers l'Application NDEF
appropriée.
Identificateur de charge utile NDEF
Une charge utile peut se voir attribuer un identificateur facultatif sous la forme
d'un URI absolu ou relatif (voir 2.4.3). L'utilisation d'un identificateur permet aux
charges utiles qui prennent en charge les technologies de liaison par URI d'établir des
références croisées avec d'autres charges utiles.
2.2 Usage prévu
L'usage prévu du NDEF est le suivant: une Application NDEF est destinée à encapsuler dans un
unique Message NDEF un ou plusieurs documents liés. Par exemple, il peut s'agir d'un message
spécifique à une application accompagné d'un ensemble de pièces jointes, chacune étant de type
normalisé. Le Générateur NDEF encapsule chaque document dans des Enregistrements NDEF
sous forme de charge utile ou de Charge utile fragmentée, en indiquant le type et la longueur de la
charge utile ainsi qu'un identificateur facultatif. Les Enregistrements NDEF sont ensuite regroupés
pour former un unique Message NDEF. Le Message NDEF est transmis via NFC à un autre
Appareil NFC Forum, où il est reçu et analysé syntaxiquement. L'Analyseur syntaxique NDEF
déconstruit le Message NDEF et transmet les charges utiles à une Application NDEF
(potentiellement différente). Chaque Message NDEF doit être envoyé ou reçu dans son intégralité.
Les Enregistrements NDEF peuvent encapsuler des documents de n'importe quel type. Il est
possible de transporter des messages MIME dans des Enregistrements NDEF en utilisant un type
de médias tel que "message/rfc822". Un Message NDEF peut être encapsulé dans un
Enregistrement NDEF en utilisant un type prédéfini spécifique à la NFC (voir [NFC RTD]).
Format d'échange de données NFC Page 6
Mécanismes NDEF
Il est important de noter que, bien que les entités MIME soient prises en charge, il n'existe pas
d'hypothèses dans le NDEF selon lesquelles une charge utile d'enregistrement est au format
MIME; le NDEF ne formule aucune hypothèse concernant les types des charges utiles
transportées dans un Message NDEF. Dit autrement, il n'est pas nécessaire qu'un Analyseur
syntaxique NDEF examine le type d'Enregistrement NDEF ni n'étudie le contenu d'un
Enregistrement NDEF afin d'analyser syntaxiquement le Message NDEF.
Le NDEF ne fournit aucune prise en charge pour le traitement des erreurs. Il appartient à
l'Analyseur syntaxique NDEF de déterminer les implications de la réception d'un Message
NDEF mal formé ou d'un Message NDEF contenant un champ dont la longueur dépasse ses
capacités de traitement. Il incombe aux Applications NDEF mises en œuvre de fournir n'importe
quelle fonctionnalité supplémentaire, telle que la qualité de service (QoS), dont elles ont besoin
dans le cadre du système global auquel elles participent.
Exigences 1: Usage prévu
Appareil NFC Forum
2.2.1.1 Chaque Message NDEF DOIT être envoyé ou reçu dans son intégralité.
2.3 Constructions d'une encapsulation NDEF
2.3.1 Message NDEF
Un Message NDEF est composé d'un ou de plusieurs Enregistrements NDEF. Le premier
Enregistrement NDEF dans un Message NDEF est marqué avec le fanion MB (Message Begin)
activé, et le dernier Enregistrement NDEF dans le Message NDEF est marqué avec le fanion ME
(Message End) activé (voir 2.6.2 et 2.6.3). La longueur minimale d'un Message NDEF
correspond à un Enregistrement NDEF, ce qui s'obtient en activant à la fois les fanions MB et ME
dans le même Enregistrement NDEF. Noter qu'au moins deux fragments d'enregistrement sont
exigés afin de coder une Charge utile fragmentée (voir 2.3.3). Le nombre maximal
d'Enregistrements NDEF qui peuvent être transportés dans un Message NDEF est illimité.
Les Messages NDEF ne peuvent pas se chevaucher; c'est-à-dire que les fanions MB et ME ne
peuvent pas être utilisés pour imbriquer des Messages NDEF. Les Messages NDEF peuvent être
imbriqués en transportant un Message NDEF entier en tant que charge utile au sein d'un
Enregistrement NDEF.
Message NDEF
R1 MB=1 … Rr … Rs … Rt ME=1
Figure 1. Exemple de Message NDEF avec un ensemble d'Enregistrements NDEF
Dans un Message NDEF, l'en-tête se trouve à gauche et l'en-queue à droite, les indices logiques
de l'Enregistrement NDEF étant t > s > r > 1. Le fanion MB (Message Begin) est activé dans le
premier Enregistrement NDEF (index 1) et le fanion ME (Message End) est activé dans le
dernier Enregistrement NDEF (index t).
Les Enregistrements NDEF proprement dits ne comportent pas de numéro d'index;
l'ordonnancement est implicitement donné par l'ordre dans lequel les Enregistrements NDEF sont
sérialisés. Par exemple, si des Enregistrements NDEF se trouvent à nouveau regroupés par une
application intermédiaire, alors il incombe à cette application d'assurer que l'ordre des
Enregistrements NDEF est préservé.
Format d'échange de données NFC Page 7
Mécanismes NDEF
Exigences 2: Encapsulation NDEF - Message
Encapsulation de Message NDEF
2.3.1.1 Un Message NDEF DOIT être composé d'un ou de plusieurs Enregistrements
NDEF.
2.3.1.2 Le premier Enregistrement NDEF dans un Message NDEF DOIT être marqué
avec le fanion MB (Message Begin) activé.
2.3.1.3 Le dernier Enregistrement NDEF dans le Message NDEF DOIT être marqué
avec le fanion ME (Message End) activé.
2.3.1.4 Les Messages NDEF NE DOIVENT PAS se chevaucher; c'est-à-dire que les
fanions MB et ME NE DOIVENT PAS être utilisés pour imbriquer des
Messages NDEF.
2.3.1.5 Les Messages NDEF PEUVENT être imbriqués en transportant un Message
NDEF entier en tant que charge utile au sein d'un Enregistrement NDEF.
2.3.2 Enregistrement NDEF
Un Enregistrement NDEF est l'unité permettant de transporter une charge utile au sein d'un
Message NDEF. Chaque charge utile est décrite par son propre ensemble de paramètres (voir
2.4).
2.3.3 Fragments d'enregistrement NDEF
Un Fragment d'enregistrement NDEF transporte un fragment d'une charge utile. Des Charges
utiles fragmentées peuvent être utilisées pour diviser un contenu généré dynamiquement ou de
très grandes entités en plusieurs Fragments d'enregistrement NDEF consécutifs sérialisés au sein
d'un même Message NDEF.
La fragmentation n'est pas un mécanisme permettant d'adopter un multiplexage ou une diffusion
de données dans le format NDEF, et il est interdit de l'utiliser à ces fins. La fragmentation est un
mécanisme visant à réduire la nécessité d'une mise en mémoire tampon sortante du côté
génération, similaire au mécanisme de fragmentation de message défini dans HTTP/1.1
[RFC 2616].
Un Message NDEF peut contenir zéro ou plusieurs Charges utiles fragmentées. Chaque Charge
utile fragmentée est codée sous la forme d'un Fragment d'enregistrement NDEF initial, suivi de
zéro ou plusieurs Fragments d'enregistrement NDEF intermédiaires, et enfin, d'un Fragment
d'enregistrement NDEF terminal. Chaque Fragment d'enregistrement NDEF est codé sous la
forme d'un Enregistrement NDEF qui utilise les règles de codage suivantes:
• Le Fragment d'enregistrement NDEF initial est un Enregistrement NDEF avec le CF (Chunk
Flag) activé (voir 2.6.4). Le type de la Charge utile fragmentée entière est indiqué dans le
champ TYPE, que la valeur du champ PAYLOAD_LENGTH soit nulle ou non. Le champ ID
PEUT être utilisé pour transporter un identificateur de la Charge utile fragmentée entière. Le
champ PAYLOAD_LENGTH de cet Enregistrement NDEF initial indique la taille des données
transportées dans le champ PAYLOAD de l'Enregistrement NDEF initial uniquement, et non la
taille de la charge utile entière (voir 2.4.1).
Format d'échange de données NFC Page 8
Mécanismes NDEF
• Chaque Fragment d'enregistrement NDEF intermédiaire est un Enregistrement NDEF avec
son CF activé, ce qui indique que ce Fragment d'enregistrement NDEF contient le fragment de
données suivant du même type et avec le même identificateur que le Fragment
d'enregistrement NDEF initial. Les valeurs des champs TYPE_LENGTH et IL sont zéro, et la
valeur du champ TNF (Type Name Format) est 0x06 (Inchangée) (voir 2.6.7). Le champ
PAYLOAD_LENGTH indique la taille des données transportées dans le champ PAYLOAD
de cet unique Enregistrement NDEF intermédiaire seulement (voir 2.4.1).
• Le Fragment d'enregistrement NDEF terminal est un Enregistrement NDEF avec son CF effacé,
ce qui indique que ce Fragment d'enregistrement NDEF contient le dernier fragment de données
du même type et avec le même identificateur que le Fragment d'enregistrement NDEF initial.
Comme dans les Fragments d'enregistrement NDEF intermédiaires, les valeurs des champs
TYPE_LENGTH et IL sont zéro, et la valeur du champ TNF (Type Name Format) est 0x06
(Inchangée) (voir 2.6.7). Le champ PAYLOAD_LENGTH indique la taille des données
transportées dans le champ PAYLOAD de ce Fragment d'enregistrement NDEF terminal (voir
2.4.1).
Une Charge utile fragmentée doit être entièrement encapsulée au sein d'un unique Message
NDEF. Cela signifie qu'une Charge utile fragmentée ne peut pas s'étendre sur plusieurs Messages
NDEF. Par conséquent, ni un Fragment d'enregistrement NDEF initial ni un Fragment
d'enregistrement NDEF intermédiaire ne peuvent avoir le fanion ME (Message End) activé.
Format d'échange de données NFC Page 9
Mécanismes NDEF
Exigences 3: Encapsulation NDEF – Fragments d'enregistrement NDEF
Encapsulation de Fragments d'enregistrement
2.3.3.1 La fragmentation NE DOIT PAS être utilisée pour adopter un
multiplexage ou une diffusion de données dans le format NDEF.
2.3.3.2
Chaque Charge utile fragmentée DOIT être codée sous la forme d'un Fragment
d'enregistrement NDEF initial, suivi de 0 ou plusieurs Fragments d'enregistrement
NDEF intermédiaires, et enfin, d'un Fragment d'enregistrement NDEF terminal.
Le Fragment d'enregistrement NDEF initial DOIT être un Enregistrement
2.3.3.3 NDEF avec le CF (Chunk Flag) activé.
Le type de la Charge utile fragmentée entière DOIT être indiqué dans le
2.3.3.4 champ TYPE du Fragment d'enregistrement NDEF initial.
Le champ PAYLOAD_LENGTH de l'Enregistrement NDEF initial indique la
2.3.3.5 taille des données transportées dans le champ PAYLOAD de l'Enregistrement
NDEF initial uniquement, et non la taille de la charge utile entière.
Chaque Fragment d'enregistrement NDEF intermédiaire DOIT être un
2.3.3.6 Enregistrement NDEF avec le CF activé.
Pour chaque Fragment d'enregistrement NDEF intermédiaire, la valeur des
2.3.3.7 champs TYPE_LENGTH et IL DOIT être 0.
Pour chaque Fragment d'enregistrement NDEF intermédiaire, la valeur du
2.3.3.8 champ TNF (Type Name Format) DOIT être 0x06 (Inchangée).
Pour chaque Fragment d'enregistrement NDEF intermédiaire, le champ
2.3.3.9 PAYLOAD_LENGTH DOIT indiquer la taille des données transportées dans
le champ PAYLOAD de cet unique Enregistrement NDEF seulement.
Le Fragment d'enregistrement NDEF terminal DOIT être un Enregistrement
2.3.3.10
NDEF avec le CF effacé.
Pour le Fragment d'enregistrement NDEF terminal, la valeur des champs
2.3.3.11
TYPE_LENGTH et IL DOIT être 0.
Pour le Fragment d'enregistrement NDEF terminal, la valeur du champ TNF
2.3.3.12
(Type Name Format) DOIT être 0x06 (Inchangée).
Pour le Fragment d'enregistrement NDEF terminal, le champ
2.3.3.13
PAYLOAD_LENGTH DOIT indiquer la taille des données transportées
dans le champ PAYLOAD de cet Enregistrement NDEF seulement.
Une Charge utile fragmentée DOIT être entièrement encapsulée au sein d'un
2.3.3.14
unique Message NDEF.
Un Fragment d'enregistrement NDEF initial NE DOIT PAS avoir le fanion
2.3.3.15
ME (Message End) activé.
Un Fragment d'enregistrement NDEF intermédiaire NE DOIT PAS avoir le
2.3.3.16
fanion ME (Message End) activé.
Format d'échange de données NFC Page 10
Mécanismes NDEF
2.4 Description d'une Charge utile NDEF
Chaque Enregistrement NDEF contient des informations sur la charge utile transportée en son sein.
Ce paragraphe présente les mécanismes par lesquels ces charges utiles sont décrites.
2.4.1 Longueur de charge utile NDEF
Quelle que soit la relation d'un Enregistrement NDEF avec d'autres Enregistrements NDEF, la
Longueur de charge utile NDEF indique toujours la longueur de la charge utile encapsulée dans
cet Enregistrement NDEF. La longueur de la charge utile est indiquée dans le champ
PAYLOAD_LENGTH. Le champ PAYLOAD_LENGTH occupe un octet pour les
Enregistrements courts NDEF et quatre octets pour les enregistrements normaux. Les
Enregistrements courts NDEF so
...