Re: Registration request for urn:thread:

Hallo Esko,

In general we are very supportive of registration requests from 
standards development organizations, so at a high level this seems fine.

However, it's unfortunate that you can provide no insights about the 
form of the URNs that will be generated (e.g., structure, allowable 
characters). As a result, we need to take it on faith that Thread Group 
will do the right thing. Would it be more sensible to make this request 
once the spec update is available?

Peter

On 1/22/24 7:55 AM, Esko Dijk wrote:
> Hi all,
> 
> Below is the RFC 8141 registration template for this request for 
> “urn:thread:”. I’m making this request on behalf of the registrant. Any 
> review comments or questions are welcome!
> 
> A spec update that shows concrete usage of URNs is expected to come 
> later in 2024 – so not available at this time.
> 
> Best regards,
> 
> Esko Dijk
> 
> **
> 
> *URN Namespace Registration for Thread Group, Inc.*
> 
> Namespace Identifier:  thread
> 
> Version:               1
> 
> Date:                  2024-01-22
> 
> Registrant:
> 
>    Name:                Thread Group, Inc.
> 
>    Address:             5000 Executive Parkway, Suite 302
> 
>                         San Ramon, CA 94583
> 
>                         United States of America
> 
>    Website: https://www.threadgroup.org/ <https://www.threadgroup.org/>
> 
>    Contact (general):   help&threadgroup.org
> 
>    Contacts(technical): tom&threadgroup.org
> 
>                         esko.dijk&iotconsultancy.nl
> 
>    Organization Type:   Standards Development Organization (non-profit corp)
> 
>                         (requesting fast-track registration procedure)
> 
> 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 either 1) 
> published by the Thread Group as part of its Thread Specification series 
> of standards, or 2) used in communication between devices implementing 
> the Thread Specification. The "thread" namespace URNs can be used in 
> standardized communication between Thread devices, or in communication 
> between Thread devices and non-Thread devices (e.g. carried over an IPv6 
> communication protocol, over a non-IP wired or wireless link, written 
> form, encoded as physical signals, etc.)
> 
> This communication is typically local to a site (e.g. home or business) 
> but may also be carried over the Internet in the future, for remote 
> management use cases. The main purposes for using URNs for the above 
> functions are interoperability and identifiability: there is a clear 
> semantic definition for each URN provided by the Thread Specification, 
> and the scope/purpose of the URN can be identified from its contents 
> alone. The latter is useful when e.g. scanning a URN in written form, 
> bar code, or as a QR code. Also by using the URN standard the data may 
> be easily handled or transited by third party software/processes that 
> are not necessarily aware of the Thread Specification.
> 
> Syntax:
> 
> The syntax of the URNs complies to the Namespace Specific String (NSS) 
> rules as defined by [RFC 8141]. The Thread Group will operate its own 
> registry for any URNs (including sub-namespaces) within the namespace; 
> and additional requirements for each of the allowed sub-namespaces will 
> be defined by the Thread Specification.
> 
> Any use of r-components, q-components or f-components will also be 
> defined by the Thread Specification and noted in the internal registry. 
> At the time of registration, no such use of components is foreseen yet.
> 
> 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 internal registry kept by Thread Group. 
> An assignment may consist of a final URN or a URN sub-namespace for a 
> particular purpose.
> 
> Security and Privacy:
> 
> Any registered URNs (or URN sub-namespaces) will not contain 
> privacy-sensitive information about persons such as names, addresses, or 
> personal data. URNs used in communication within designated 
> sub-namespaces may contain privacy-sensitive information or sensitive 
> security material only if the communication is cryptographically 
> protected as defined by the Thread Specification.
> 
> Interoperability:
> 
> 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:
> 
> Thread Specification (most recent version higher than v1.3) as published 
> by Thread Group. Available at: https://www.threadgroup.org/ThreadSpec 
> <https://www.threadgroup.org/ThreadSpec>
> 
> Note: some versions of the Thread Specification are only available to 
> members of the Thread Group, or its affiliates. Future versions of the 
> Thread Specification are expected to contain URN definitions and the 
> contents of the internal registry as described in this registration request.
> 
> Additional Information:        None.
> 
> Revision Information:          Not applicable (this is version 1).
> 
> 
> _______________________________________________
> urn mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/urn

_______________________________________________
urn mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/urn