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.
The DEV URNs identify devices with device-specific identifiers such as network card hardware addresses. DEV URNs are scoped to be globally applicable (see RFC 8141
, Section 6.4.1
) 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 Section 3.3
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.
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 [RFC 5234
] and [RFC 7405
]. The syntax also copies the DIGIT and ALPHA rules originally defined in [RFC 5234
], exactly as defined there.
The device identifier namespace includes five subtypes (see Section 4
), and more may be defined in the future as specified in Section 7
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 [RFC 8141
] or the context where these URNs are carried (e.g., inside JSON [RFC 8259
] or SenML [RFC 8428
]). Due to the SenML rules in RFC 8428
, Section 4.5.1
, 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 [RFC 3986
] and [RFC 8141
DEV URNs do not use r-, q-, or f-components as defined in [RFC 8141
Specific subtypes of DEV URNs may be validated through mechanisms discussed in Section 4
The string representation of the device identifier URN is fully compatible with the URN syntax.
The DEV URN syntax allows both uppercase and lowercase characters. The URN-equivalence of the DEV URNs is defined per RFC 8141
, Section 3.1
, 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 [RFC 8141
] definition. For instance, in ABNF, strings are case insensitive (see RFC 5234
, Section 2.3
), 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.)
The process for identifier assignment is dependent on the used subtype and is documented in the specific subsection under Section 4
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).
As discussed in Section 6
, 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.
There are no specific interoperability concerns.
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.
See Section 1
for a discussion of related namespaces.
This is the first version of this registration.