Ericsson

Jorvas 02420 Finland jari.arkko@piuha.net

Cisco

170 West Tasman Drive San Jose CA 95134 United States of America +1 408 421-9990 fluffy@iii.ca

Edge Impulse

3031 Tisch Way San Jose CA 95128 United States of America zach@edgeimpulse.com

URN device identifier IMEI 1-Wire MAC address EUI-48 EUI-64 This document describes a new Uniform Resource Name (URN) namespace for hardware device identifiers. A general representation of device identity can be useful in many applications, such as in sensor data streams and storage or in equipment inventories. A URN-based representation can be passed along in applications that need the information.

Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• .  Introduction
• .  Requirements Language
• .  DEV URN Definition
  • .  Purpose
  • .  Syntax
    • .  Character Case and URN-Equivalence
  • .  Assignment
  • .  Security and Privacy
  • .  Interoperability
  • .  Resolution
  • .  Documentation
  • .  Additional Information
  • .  Revision Information
• .  DEV URN Subtypes
  • .  MAC Addresses
  • .  1-Wire Device Identifiers
  • .  Organization-Defined Identifiers
  • .  Organization Serial Numbers
  • .  Organization Product and Serial Numbers
  • .  Future Subtypes
• .  Examples
• .  Security Considerations
  • .  Privacy
  • .  Validity
• .  IANA Considerations
• .  References
  • .  Normative References
  • .  Informative References
• Acknowledgments
• Authors' Addresses

Introduction This document describes a new Uniform Resource Name (URN) namespace for hardware device identifiers. A general representation of device identity can be useful in many applications, such as in sensor data streams and storage or in equipment inventories . A URN-based representation can be passed along in applications that need the information. It fits particularly well for protocols mechanisms that are designed to carry URNs . Finally, URNs can also be easily carried and stored in formats such as XML , JSON , or SenML . Using URNs in these formats is often preferable as they are universally recognized and self-describing and therefore avoid the need to agree to interpret an octet string as a specific form of a Media Access Control (MAC) address, for instance. Passing URNs may consume additional bytes compared to, for instance, passing 4-byte binary IPv4 addresses, but the former offers some flexibility in return. This document defines identifier URN types for situations where no such convenient type already exists. For instance, defines cryptographic identifiers, defines International Mobile station Equipment Identity (IMEI) identifiers for use with 3GPP cellular systems, and defines Mobile Equipment Identity (MEID) identifiers for use with 3GPP2 cellular systems. Those URN types should be employed when such identifiers are transported; this document does not redefine these identifiers in any way. Universally Unique Identifier (UUID) URNs are another alternative way to represent device identifiers and already support MAC addresses as one type of identifier. However, UUIDs can be inconvenient in environments where it is important that the identifiers be as simple as possible and where additional requirements on stable storage, real-time clocks, and identifier length can be prohibitive. Often, UUID-based identifiers are preferred for general purpose uses instead of the MAC-based device URNs defined in this document. The device URNs are recommended for constrained environments. Future device identifier types can extend the device URN type defined in this document (see ), or they can define their own URNs. Note that long-term stable unique identifiers are problematic for privacy reasons and should be used with care as described in . The rest of this document is organized as follows. defines the "DEV" URN type, and defines subtypes for IEEE MAC-48, EUI-48 and EUI-64 addresses, and 1-Wire device identifiers. gives examples. discusses the security and privacy considerations of the new URN type. Finally, specifies the IANA registration for the new URN type and sets requirements for subtype allocations within this type.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

DEV URN Definition

Namespace Identifier:

"dev"

Version:

1

Date:

2020-06-24

Registrant:

IETF and the CORE Working Group. Should the working group cease to exist, discussion should be directed to the Applications and Real-Time Area or general IETF discussion forums, or the IESG.

Purpose The DEV URNs identify devices with device-specific identifiers such as network card hardware addresses. DEV URNs are scoped to be globally applicable (see ) and, in general, enable systems to use these identifiers from multiple sources in an interoperable manner. Note that in some deployments, ensuring uniqueness requires care if manual or local assignment mechanisms are used, as discussed in . Some typical DEV URN applications include equipment inventories and smart object systems. DEV URNs can be used in various ways in applications, software systems, and network components, in tasks ranging from discovery (for instance, when discovering 1-Wire network devices or detecting MAC-addressable devices on a LAN) to intrusion detection systems and simple catalogues of system information. While it is possible to implement resolution systems for specific applications or network locations, DEV URNs are typically not used in a way that requires resolution beyond direct observation of the relevant identifier fields in local link communication. However, it is often useful to be able to pass device identifier information in generic URN fields in databases or protocol fields, which makes the use of URNs for this purpose convenient. The DEV URN namespace complements existing namespaces such as those involving IMEI or UUID identifiers. DEV URNs are expected to be a part of the IETF-provided basic URN types, covering identifiers that have previously not been possible to use in URNs.

Syntax The identifier is expressed in ASCII characters and has a hierarchical structure as follows: devurn = "urn:dev:" body componentpart body = macbody / owbody / orgbody / osbody / opsbody / otherbody macbody = %s"mac:" hexstring owbody = %s"ow:" hexstring orgbody = %s"org:" posnumber "-" identifier *( ":" identifier ) osbody = %s"os:" posnumber "-" serial *( ":" identifier ) opsbody = %s"ops:" posnumber "-" product "-" serial *( ":" identifier ) otherbody = subtype ":" identifier *( ":" identifier ) subtype = LALPHA *(DIGIT / LALPHA) identifier = 1*devunreserved identifiernodash = 1*devunreservednodash product = identifiernodash serial = identifier componentpart = *( "_" identifier ) devunreservednodash = ALPHA / DIGIT / "." devunreserved = devunreservednodash / "-" hexstring = 1*(hexdigit hexdigit) hexdigit = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" posnumber = NZDIGIT *DIGIT ALPHA = %x41-5A / %x61-7A LALPHA = %x41-5A NZDIGIT = %x31-39 DIGIT = %x30-39 The above syntax is represented in Augmented Backus-Naur Form (ABNF) as defined in and . The syntax also copies the DIGIT and ALPHA rules originally defined in , exactly as defined there. The device identifier namespace includes five subtypes (see ), and more may be defined in the future as specified in . The optional underscore-separated components at the end of the DEV URN depict individual aspects of a device. The specific strings and their semantics are up to the designers of the device but could be used to refer to specific interfaces or functions within the device. With the exception of the MAC address and 1-Wire DEV URNs, each DEV URN may also contain optional colon-separated identifiers. These are provided for extensibility. There are no special character encoding rules or considerations for conforming with the URN syntax beyond those applicable for URNs in general or the context where these URNs are carried (e.g., inside JSON or SenML ). Due to the SenML rules in , it is not desirable to use percent-encoding in DEV URNs, and the subtypes defined in this specification do not really benefit from percent-encoding. However, this specification does not deviate from the general syntax of URNs or their processing and normalization rules as specified in and . DEV URNs do not use r-, q-, or f-components as defined in . Specific subtypes of DEV URNs may be validated through mechanisms discussed in . The string representation of the device identifier URN is fully compatible with the URN syntax.

Character Case and URN-Equivalence The DEV URN syntax allows both uppercase and lowercase characters. The URN-equivalence of the DEV URNs is defined per , i.e., two URNs are URN-equivalent if their assigned-name portions are octet-by-octet equal after applying case normalization to the URI scheme ("urn") and namespace identifier ("dev"). The rest of the DEV URN is compared in a case-sensitive manner. It should be noted that URN-equivalence matching merely quickly shows that two URNs are definitely the same for the purposes of caching and other similar uses. Two DEV URNs may still refer to the same entity and may not be found to be URN-equivalent according to the definition. For instance, in ABNF, strings are case insensitive (see ), and a MAC address could be represented either with uppercase or lowercase hexadecimal digits. Character case is not otherwise significant for the DEV URN subtypes defined in this document. However, future subtypes might include identifiers that use encodings such as base64, which encodes strings in a larger variety of characters and might even encode binary data. To facilitate equivalence checks, it is RECOMMENDED that implementations always use lowercase letters where they have a choice in case, unless there is a reason otherwise. (Such a reason might be, for instance, the use of a subtype that requires the use of both uppercase and lowercase letters.)

Assignment The process for identifier assignment is dependent on the used subtype and is documented in the specific subsection under . Device identifiers are generally expected to identify a unique device, barring the accidental issue of multiple devices with the same identifiers. In many cases, device identifiers can also be changed by users or are sometimes assigned in an algorithmic or local fashion. Any potential conflicts arising from such assignments are not something that the DEV URNs as such manage; they simply are there to refer to a particular identifier. And, of course, a single device may (and often does) have multiple identifiers, e.g., identifiers associated with different link technologies it supports. The DEV URN type SHOULD only be used for hardware-based identifiers that are expected to be persistent (with some limits, as discussed above).

Security and Privacy As discussed in , care must be taken in the use of device-identifier-based identifiers due to their nature as long-term identifiers that are not normally changeable. Leakage of these identifiers outside systems where their use is justified should be controlled.

Interoperability There are no specific interoperability concerns.

Resolution The device identifiers are not expected to be globally resolvable. No identifier resolution system is expected. Systems may perform local matching of identifiers to previously seen identifiers or configured information, however.

Documentation See RFC 9039.

Additional Information See for a discussion of related namespaces.

Revision Information This is the first version of this registration.

DEV URN Subtypes

MAC Addresses DEV URNs of the "mac" subtype are based on the EUI-64 identifier derived from a device with a built-in 64-bit EUI-64. The EUI-64 is formed from 24 or 36 bits of organization identifier followed by 40 or 28 bits of device-specific extension identifier assigned by that organization. In the DEV URN "mac" subtype, the hexstring is simply the full EUI-64 identifier represented as a hexadecimal string. It is always exactly 16 characters long. MAC-48 and EUI-48 identifiers are also supported by the same DEV URN subtype. To convert a MAC-48 address to an EUI-64 identifier, the Organizationally Unique Identifier (OUI) of the MAC-48 address (the first three octets) becomes the organization identifier of the EUI-64 (the first three octets). The fourth and fifth octets of the EUI are set to the fixed value 0xffff (hexadecimal). The last three octets of the MAC-48 address become the last three octets of the EUI-64. The same process is used to convert an EUI-48 identifier, but the fixed value 0xfffe is used instead. Identifier assignment for all of these identifiers rests within the IEEE Registration Authority. Note that where randomized MAC addresses are used, the resulting DEV URNs cannot be expected to have uniqueness, as discussed in .

1-Wire Device Identifiers The 1-Wire system is a device communications bus system designed by Dallas Semiconductor Corporation. (1-Wire is a registered trademark.) 1-Wire devices are identified by a 64-bit identifier that consists of an 8-bit family code, a 48-bit identifier unique within a family, and an 8-bit Cyclic Redundancy Check (CRC) code . In DEV URNs with the "ow" subtype, the hexstring is a representation of the full 64-bit identifier as a hexadecimal string. It is always exactly 16 characters long. Note that the last two characters represent the 8-bit CRC code. Implementations MAY check the validity of this code. Family code and identifier assignment for all 1-Wire devices rests with the manufacturers.

Organization-Defined Identifiers Device identifiers that have only a meaning within an organization can also be used to represent vendor-specific or experimental identifiers or identifiers designed for use within the context of an organization. Organizations are identified by their Private Enterprise Number (PEN) . These numbers can be obtained from IANA. Current PEN assignments can be viewed at , and new assignments are requested at . Note that when included in an "org" DEV URN, the number cannot be zero or have leading zeroes, as the ABNF requires the number to start with a non-zero digit.

Organization Serial Numbers The "os" subtype specifies an organization and serial number. Organizations are identified by their PEN. As with the organization-defined identifiers (), PEN number assignments are maintained by IANA, and assignments for new organizations can be made easily. Organization serial number DEV URNs consist of the PEN number and the serial number. As with other DEV URNs, for carrying additional information and extensibility, optional colon-separated identifiers and underscore-separated components may also be included. The serial numbers themselves are defined by the organization, and this specification does not specify how they are allocated. Organizations are also encouraged to select serial number formats that avoid the possibility of ambiguity in the form of leading zeroes or otherwise.

Organization Product and Serial Numbers The DEV URN "ops" subtype was originally defined in the LwM2M standard but has been incorporated here to collect all syntaxes associated with DEV URNs in one place. The "ops" subtype specifies an organization, product class, and a serial number. Organizations are identified by their PEN. Again, as with the organization-defined identifiers (), PEN number assignments are maintained by IANA. Organization product and serial number DEV URNs consist of the PEN number, product class, and the serial number. As with other DEV URNs, for carrying additional information and extensibility, optional colon-separated identifiers and underscore-separated components may also be included. Both the product class and serial numbers themselves are defined by the organization, and this specification does not specify how they are allocated. Organizations are also encouraged to select product and serial number formats that avoid possibility for ambiguity.

Future Subtypes Additional subtypes may be defined in future specifications. See . The DEV URN "example" subtype is reserved for use in examples. It has no specific requirements beyond those expressed by the ABNF in .

Examples The following provides some examples of DEV URNs:

URN	Description
urn:dev:mac:0024beffff804ff1	The MAC-48 address of 0024be804ff1, converted to EUI-64 format
urn:dev:mac:0024befffe804ff1	The EUI-48 address of 0024be804ff1, converted to EUI-64 format
urn:dev:mac:acde48234567019f	The EUI-64 address of acde48234567019f
urn:dev:ow:10e2073a01080063	A 1-Wire temperature sensor
urn:dev:ow:264437f5000000ed_humidity	The humidity part of a multi-sensor device
urn:dev:ow:264437f5000000ed_temperature	The temperature part of a multi-sensor device
urn:dev:org:32473-foo	An organization-specific URN in the example organization 32473 in
urn:dev:os:32473-123456	Device 123456 in the example organization in
urn:dev:os:32473-12-34-56	A serial number with dashes in it
urn:dev:ops:32473-Refrigerator-5002	Refrigerator serial number 5002 in the example organization in
urn:dev:example:new-1-2-3_comp	An example of something that is not defined today, and is not one of the mac, ow, os, or ops subtypes

The DEV URNs themselves can then appear in various contexts. A simple example of this is the use of DEV URNs in SenML data. This example from shows a measurement from a 1-Wire temperature gauge encoded in the JSON syntax: [ {"n":"urn:dev:ow:10e2073a01080063","u":"Cel","v":23.1} ]

Security Considerations On most devices, the user can display device identifiers. Depending on circumstances, device identifiers may or may not be modified or tampered with by the user. An implementation of the DEV URN MUST preserve such limitations and behaviors associated with the device identifiers. In particular, a device identifier that is intended to be immutable should not become mutable as a part of implementing the DEV URN type. More generally, nothing in this document should be construed to override what the relevant device specifications have already said about the identifiers.

Privacy Other devices in the same network may or may not be able to identify the device. For instance, on an Ethernet network, the MAC address of a device is visible to all other devices. DEV URNs often represent long-term stable unique identifiers for devices. Such identifiers may have privacy and security implications because they may enable correlating information about a specific device over a long period of time, location tracking, and device-specific vulnerability exploitation . Also, in some systems, there is no easy way to change the identifier. Therefore, these identifiers need to be used with care, and special care should be taken to avoid leaking identifiers outside of the system that is intended to use them.

Validity Information about identifiers may have significant effects in some applications. For instance, in many sensor systems, the identifier information is used for deciding how to use the data carried in a measurement report. In some other systems, identifiers may be used in policy decisions. It is important that systems be designed to take into account the possibility of devices reporting incorrect identifiers (either accidentally or maliciously) and the manipulation of identifiers in communications by illegitimate entities. Integrity protection of communications or data objects, the use of trusted devices, and various management practices can help address these issues. Similar to the advice in : Do not assume that DEV URNs are hard to guess.

IANA Considerations Per this document, IANA has registered a new URN namespace for "dev", as described in . IANA has created a "DEV URN Subtypes" registry under "Device Identification". The initial values in this registry are as follows:

Subtype	Description	Reference
mac	MAC Addresses	RFC 9039,
ow	1-Wire Device Identifiers	RFC 9039,
org	Organization-Defined Identifiers	RFC 9039,
os	Organization Serial Numbers	RFC 9039,
ops	Organization Product and Serial Numbers	RFC 9039,
example	Reserved for examples	RFC 9039,

Additional subtypes for DEV URNs can be defined through Specification Required or IESG Approval . These allocations are appropriate when there is a new namespace of some type of device identifier that is defined in a stable fashion and has a publicly available specification. Note that the organization () device identifiers can also be used in some cases, at least as a temporary measure. It is preferable, however, that long-term usage of a broadly employed device identifier be registered with IETF rather than used through the organization device identifier type.

References Normative References IEEE Maxim In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. It is the purpose of this document, the Structure of Management Information Version 2 (SMIv2), to define that adapted subset, and to assign a set of associated administrative values. [STANDARDS-TRACK] A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the "urn" URI scheme and a particular URN namespace, with the intent that the URN will be a persistent, location-independent resource identifier. With regard to URN syntax, this document defines the canonical syntax for URNs (in a way that is consistent with URI syntax), specifies methods for determining URN-equivalence, and discusses URI conformance. With regard to URN namespaces, this document specifies a method for defining a URN namespace and associating it with a namespace identifier, and it describes procedures for registering namespace identifiers with the Internet Assigned Numbers Authority (IANA). This document obsoletes both RFCs 2141 and 3406. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Work in Progress This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK] This specification defines a Uniform Resource Name namespace for UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID is 128 bits long, and can guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation\'s (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the DCE specification with the kind permission of the OSF (now known as The Open Group). Information from earlier versions of the DCE specification have been incorporated into this document. [STANDARDS-TRACK] This document describes an Enterprise Number (also known as SMI Network Management Private Enterprise Code) for use in documentation. This memo provides information for the Internet community. This document defines a set of ways to identify a thing (a digital object in this case) using the output from a hash function. It specifies a new URI scheme for this purpose, a way to map these to HTTP URLs, and binary and human-speakable formats for these names. The various formats are designed to support, but not require, a strong link to the referenced object, such that the referenced object may be authenticated to the same degree as the reference to it. The reason for this work is to standardise current uses of hash outputs in URLs and to support new information-centric applications and other uses of hash outputs in protocols. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations. The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. This specification defines a Uniform Resource Name (URN) namespace for the Global System for Mobile Communications Association (GSMA) and a Namespace Specific String (NSS) for the International Mobile station Equipment Identity (IMEI), as well as an associated parameter for the International Mobile station Equipment Identity and Software Version number (IMEISV). The IMEI and IMEISV were introduced as part of the specification for the GSM and are also now incorporated by the 3rd Generation Partnership Project (3GPP) as part of the 3GPP specification for GSM, Universal Mobile Telecommunications System (UMTS), and 3GPP Long Term Evolution (LTE) networks. The IMEI and IMEISV are used to uniquely identify Mobile Equipment within these systems and are managed by the GSMA. URNs from this namespace almost always contain personally identifiable information and need to be treated accordingly. This document extends the base definition of ABNF (Augmented Backus-Naur Form) to include a way to specify US-ASCII string literals that are matched in a case-sensitive manner. This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients. This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged. This document discusses privacy and security considerations for several IPv6 address generation mechanisms, both standardized and non-standardized. It evaluates how different mechanisms mitigate different threats and the trade-offs that implementors, developers, and users face in choosing different addresses or address generation mechanisms. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. This specification defines a format for representing simple sensor measurements and device parameters in Sensor Measurement Lists (SenML). Representations are defined in JavaScript Object Notation (JSON), Concise Binary Object Representation (CBOR), Extensible Markup Language (XML), and Efficient XML Interchange (EXI), which share the common SenML data model. A simple sensor, such as a temperature sensor, could use one of these media types in protocols such as HTTP or the Constrained Application Protocol (CoAP) to transport the measurements of the sensor or to be configured. This document defines a Uniform Resource Name (URN) namespace for the Third Generation Partnership Project 2 (3GPP2) and a Namespace Specific String (NSS) for the Mobile Equipment Identity (MEID). The structure of an MEID is 15 hexadecimal digits long and is defined in the 3GPP2 to uniquely identify each individual mobile equipment (e.g., a handset or mobile phone). The 3GPP2 has a requirement to be able to use an MEID as a URN. This document fulfills that requirement.

Acknowledgments The authors would like to thank , , , , , , , , , , , , , , , , , , , , , , , , , , , and for their feedback and interesting discussions in this problem space. We would also like to note prior documents that focused on specific device identifiers, such as and .

Authors' Addresses Ericsson

Jorvas 02420 Finland jari.arkko@piuha.net

Cisco

170 West Tasman Drive San Jose CA 95134 United States of America +1 408 421-9990 fluffy@iii.ca

Edge Impulse

3031 Tisch Way San Jose CA 95128 United States of America zach@edgeimpulse.com