URN Namespace Registration for Thread Group, Inc. Namespace Identifier: thread Version: 1 Date: 2024-12-09 Registrant: Name: Thread Group, Inc. Address: 5000 Executive Parkway, Suite 302 San Ramon, CA 94583 United States of America Website: https://www.threadgroup.org/ E-mail: help&threadgroup.org Purpose: The Namespace Identifier (NID) "thread" for Uniform Resource Names (URNs) will be used to identify resources, protocol elements, specification elements, or structured data items that are defined by Thread Group in its Thread Specification standards. The "thread" namespace URNs can be used in standardized communication between any combination of actors: Thread devices, non-Thread devices, or persons. This can include URNs carried over an IPv6 communication protocol, over a non-IP wired/wireless link, shown in written form or graphical form, in spoken form, or encoded as audio. URNs are typically communicated locally within a site (e.g. home or business) but may also be carried over the Internet, for example for remote management use cases. The main purposes for using URNs for the above functions are inter- operability and identifiability: there is a clear semantic definition for each URN in the Thread Specification, and the scope/purpose of the URN can be identified from its NID and NSS alone. The latter is useful when e.g. scanning a URN in written form, or as a QR code. Also by using the URN standard, the included data may be more easily handled or transited by third party software/processes that are not necessarily aware of the Thread Specification, but can handle strings/URNs. Syntax: The general version 1 syntax of URNs for this NID is defined by the following ABNF ([RFC 5234]) rules: urn-thread = "urn:thread:" sub-namespace *( ":" sn-content ) sub-namespace = sn-label *( ":" sn-label ) sn-label = 1*unreserved sn-content = *( pchar / "/" ) where 'pchar' and 'unreserved' ABNF are defined by [RFC 3986]. The URN is encoded as US-ASCII and complies to the Namespace Specific String (NSS) rules as defined by [RFC 8141]. The Thread Group will operate its own registry for registering any sub-namespace elements. This registry will define any additional requirements for the sn-content element for each registered sub-namespace element. Any use of r-components, q-components or f-components is not defined in the current version 1 definition. Note that sn-content allows for the inclusion of base64 encoded data, or hexadecimal encoded data, as well as data with the ":" character. In most cases, a particular sub-namespace will impose stricter constraints on the allowed characters for sn-content than the constraints as specified by the above ABNF rules. A generic parser for "thread" URNs, which does not have knowledge of these sub-namespace constraints, therefore cannot validate URNs based only on the ABNF rules. A parser for "thread" URNs is expected to apply the syntax rules listed here in combination with a list of known (registered) sub-namespaces of interest and their associated sn-content constraints. For unrecognized sub-namespace elements, a parser may not be able to identify where in the string the sub-namespace stops and the sn-content starts. This is deemed acceptable, since the parser will be unable to interpret the resulting URN in any case. Assignment: Any assignment will be managed by the Technical Committee of the Thread Group based on the rules of engagement as defined for this committee. Assignments are recorded in the URN "thread" registry kept by Thread Group. An assignment may consist of a final URN (i.e. without the optional sn-content element) or of a sub-namespace definition for a particular purpose, where the sn-content element is present and may vary in contents. Each registry entry MUST define at least five elements: sub-namespace definition, whether it includes sn-content, a short description, security classification, and a link/reference to the detailed specifications for it. Each registered sub-namespace element MUST NOT be a prefix of any other registered sub-namespace element. A new registration entry MAY reuse an existing sub-namespace element and extend the sn-content definition for it. Any such extension MUST be made within the constraints for sn-content defined by the original sub-namespace element registration. Security and Privacy: Any registered URNs MUST NOT contain privacy-sensitive information about persons such as names, addresses, or personal data. URNs with desig- nated sub-namespaces may contain privacy-sensitive information or sensitive security material in the sn-content element. Such sensitive URNs are classified as "private" in the URN registry. In such cases, a URN must be protected cryptographically and/or physically as defined by the Thread Specification per case. Interoperability: Use of r-components, q-components or f-components is not defined in this version of the namespace registration document but may be added in a future version. There are no known interoperability issues at this time. Thread Group's internal registration procedure aims to cross-check for interoperability issues at the time of registration for each new addition to the internal registry. Resolution: It is not foreseen that URNs within this namespace will undergo resolution. Thread Group does not plan to operate any resolution services for "thread" URNs. Usage of information encoded within these URNs is as defined by the Thread Specification. Documentation: The items registered in the URN "thread" registry are published in a document that can be publicly accessed at: https://github.com/ThreadGroup/urn-thread-registry/ Additional Information: The Thread Specification 1.4 or higher created by Thread Group contains additional information about URN definitions which is referenced by the entries in the URN "thread" registry. See for more information and getting access to the document: https://www.threadgroup.org/support/ Revision Information: None (this is version 1).