Re: [urn] Registration request for urn:thread:

Esko Dijk <esko.dijk@iotconsultancy.nl> Tue, 23 January 2024 15:48 UTC

Return-Path: <esko.dijk@iotconsultancy.nl>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE27EC14F711 for <urn@ietfa.amsl.com>; Tue, 23 Jan 2024 07:48:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.108
X-Spam-Level:
X-Spam-Status: No, score=-7.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iotconsultancy.nl
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HN4oh67Tb6o8 for <urn@ietfa.amsl.com>; Tue, 23 Jan 2024 07:48:52 -0800 (PST)
Received: from EUR03-DBA-obe.outbound.protection.outlook.com (mail-dbaeur03on2100.outbound.protection.outlook.com [40.107.104.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0159CC14F6E9 for <urn@ietf.org>; Tue, 23 Jan 2024 07:48:51 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OTKcVGKYSFOprlk5ehzZwYeLBvqONCxzTA+7eibaCOIxdytG3cCkvmpOJ7hQRei4i96tAnP2J3PN51/CwwQR9w6g5noMs8gr8QPqPUAQ83h/ISllAwQwnvFDSJVmk37LNrvhmz9RpqVsTst2rlGqo4uIVRgBIKXo1SKvfuLzCWfmW4NaOeI1pmYPzYBtS4DocNoL75WOwSEp/G9QLzq5MN9hffRVqd/TVyNAVAGrYpiXkCfSdQjohEiX7UmypbGSrIA65lseiN7nOYTkldjaPGGMXNr39xGjDJuMuvRw2r8RP3TvyoR2H8EmA54d+JYRcgN5APPBgGQps0CLuFDwIQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qX0xgHlAncQYcdjFeqTnCp0KKCG2GGRmngyIJYHlLoU=; b=aOlbpDN4xlEGe2V3zshw4OmqUFsWpxke5RJQMNUcEX48ce2QoCwRxTxR0r7zEeVxqTEXB3fdvT+xx/jMRAngYUni0rc1lewKxpQKvzZ3MFs8PwpaFulvsJfEHBHO+/GBB4gq+gskzT/drm3LRo8xn8rKARx8BgxOEo3o6FiucH3LTEwbHW66noUsrgw8jkV4PpetVg7kBbIRx3O8QW8ZGtOGwshNdY6Uc2BjOWPbhom+HxrkMpXoDIffdmmp+oCEUAxqgkXnfofFpHccsa9hbddEPeF/g+MO3KcBWD6/6pwoWhzPtAT2E29IvpXDomHLB/MnZxB3lZTGxTLxu8wOGA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancy.nl; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qX0xgHlAncQYcdjFeqTnCp0KKCG2GGRmngyIJYHlLoU=; b=lHMnguDA+Yp4RTMzmqdxOg3klVoP+Q877PEoq+2cIfnNq+sTbxOv6uaH7T1AHx0nc3/fsq2tADh0tXSr/QNUV2zR28SQUD3PRx5YBAiEZxAE5Ow2Fmg/SBTFGd3z+NQUYHS8kXnG1J6QMP8rCOaJojoxxsoJP0e/5AFjt+g4/FU=
Received: from DU0P190MB1978.EURP190.PROD.OUTLOOK.COM (2603:10a6:10:3b9::20) by DB9P190MB1227.EURP190.PROD.OUTLOOK.COM (2603:10a6:10:222::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7228.21; Tue, 23 Jan 2024 15:48:48 +0000
Received: from DU0P190MB1978.EURP190.PROD.OUTLOOK.COM ([fe80::1a28:be0b:8c84:d18]) by DU0P190MB1978.EURP190.PROD.OUTLOOK.COM ([fe80::1a28:be0b:8c84:d18%3]) with mapi id 15.20.7228.020; Tue, 23 Jan 2024 15:48:48 +0000
From: Esko Dijk <esko.dijk@iotconsultancy.nl>
To: Peter Saint-Andre <stpeter@stpeter.im>, "urn@ietf.org" <urn@ietf.org>
Thread-Topic: [urn] Registration request for urn:thread:
Thread-Index: AdpNQeOCsiFeA2JWQxeZEGjDLLYCWgAKU4aAACf43fA=
Date: Tue, 23 Jan 2024 15:48:47 +0000
Message-ID: <DU0P190MB1978B419F08C5281A4712D9DFD742@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM>
References: <DU0P190MB197807533371C3C42A66D841FD752@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM> <c5af069e-1538-443f-900c-eb77f299bf40@stpeter.im>
In-Reply-To: <c5af069e-1538-443f-900c-eb77f299bf40@stpeter.im>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=iotconsultancy.nl;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DU0P190MB1978:EE_|DB9P190MB1227:EE_
x-ms-office365-filtering-correlation-id: b97c0ba9-86fc-4a9b-aa72-08dc1c2ac9d2
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: dO2phWoUbUSvolxqbUKhdxW0mzeDpdOrPgqpLwvxsj/cdL302nZUKnRy00XgZiXtKuo0nZlhfwlXd5jmPcTaU0CtkW3zSbcmwDk3ubMSfSxIo3Ygfz4WK2xVMhz75NYeg6zI1W986bTCZhIQ7tnt4tpnB4b2lfhdZglJ9zMj7MLXt/KREHV21q9rTdT7yZ2U8te/I1H6ncS0KHU8hUt2yv9MRDhgVG+Lm/8GHxdsICmPvjj5S45Od01vy5eHeHkhzM4EY7m+hkYXftpyMDzDFKIZb3L6NB3G1LHhnCKCoXKOfutwRb3uLmgcob1a+ih5EPss97Ov2eX61k9EAdLut5HpwYx7Jw1Ea4sZOHFTGaf8hVfQwtxnsVLgH5quo6JC1PSDHtvOeQ2qW55m0yZ1C0SlSssYl1+OFsEcKS3MpXPAOogd3G/nEVlQoz7NTzXPCghlELO1IZldnMOSDaV4DTmoYqaKhCTqyjZtxOrhMhObl3mGCIWuQJFZfwLwKNG6J3XAvOwJMhQHdDNbsqEMfqakG8lLwprE8SVjOYiXz5v5Wxt69VtdJxZpyuFZraMhbWJzSeeGzYP1PCvtLbt8/MTzXqYb632DbMVvRNw01bs=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DU0P190MB1978.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230031)(346002)(366004)(376002)(39830400003)(396003)(136003)(230922051799003)(1800799012)(451199024)(64100799003)(186009)(110136005)(8676002)(8936002)(66446008)(83380400001)(966005)(38100700002)(9686003)(122000001)(316002)(66946007)(76116006)(64756008)(55016003)(478600001)(7696005)(71200400001)(6506007)(53546011)(44832011)(5660300002)(2906002)(52536014)(86362001)(66574015)(33656002)(38070700009)(41300700001)(66556008)(66476007)(66899024); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: onsNO5GzgAUHs/UsCN5BmkoSfAMhLOLkX9HQmPIhB5OT/KzAJhO5PIcG6ZV2xFyWidgEKiSY7SW4Jxjz81ukHeYOh0JFMhU6xzqwdJHQ0ZfmVMyqTdXFZqJBID6x/HK1P4NlujtNrvXh/7TGurj1CCepMgd/qqMPMOsC+MCY7q6Uc9V037dD/Br84eiM31tPcbKLQ3Lbasr8vPl3RC8tP8tyIOOVHRwvfPLEYk5LzxheqXfPfH7KoNWKL/7XMHJtlheE7ZZP+GblJcf80GMEl8hRIXVJdY3CT2JmiLC5jhswsH+R25VeyMC2PTwHagUID5+5iNbzL4o57TI2iSmUm7iOg5pGRuQJ6hTJvlsG8mgrqnIWWU/+6Dp/7Bz+68io630+xJxiujKa3Rb6JTlCiqFk7BnV+ObIbj67v0+R4AzzOprijjjmTyh2Xefl76pOKVIqYFtixHY1c50NabFJjOn3eiXwJ8Qzuv5eQzYMI+FhBsmrEgeK7XscVXvgDJ7qA7kfhqFEKBrFgzWDLtFNVxQWMip6t4lY/Rc4lX13rPwhG2bZHTUOQTlxpAV6pcyZ19tsE8ZskE4kdZxhm/i6RHpM7QBOKYlo8VbA7OGpaa2qYs5r24nflmx6G3tCrdEQJbiAIgTRprvYPMVNrv+az3vyBjcR4k7jU74payjaVkU6UKP5L4qFsimJnEtD7pTMtZu0SBiqfmrUSm70UbCLWmuSBKQoOjo5JrbmnYGAVYlIAypMW/yst/ZtiwnJab5Ff47Z3JK1TVsEk62sGJtWB7yr1IPdRTTGn/Qx9fHsP/wKa3e3X7yWviLgwpIBBhNBNKax7GGXlAh6JOZfYwDXx11KrUNuBB7yM4AG1QD9EPHQzEFzeRja+Oy0YPY5caBp9HWOIP7kEyJ58tKeZ0+vJj4Idoe5GG8XJf4IbRmGPHMeQvsraczREKK2xT3h0pxU3e+L73sau37ksHfnRq5oNMBzKUDTTHM6tRvpH13WY0O28myZojZxAeK/Byg7sswHlW6h3gKhWT3UruwR8IAND/JtdPY5ZhUD2M3/4+YLVJ6Mq7wC1c8lOmfMy0u0c6Dgk3wqteWWB1+Xird92f8jWP1YgtYRUkFrc8G9q2c4AJDUxpEFpPBrHxjTV4POpRaqENEo4+zg8WPuda7x7rJsIwcxbrrMjRPF1cxtRKrYFfxpbCicPsKZTUWYIUGYkTnw08oRq8csDTKQLBSq6fCexItFAyPEJovYfwWVWBU8cYhx9gV0YNSIwFW1hKrjk4nrS26TjJWdSPVPFD9dq2XUaY73J6Zpz9QYuE9zLHzwlRgTmShXkCwrffficTqfZiwcfr10OexnLa2GrYih0M0vYoKqIVpNyHPmTK8iEaFiLMPNLNXsDY0rE/1xQypnSDD+XhNz6mFgQpKPUL9k1PKOpMIsXvOGbOmx4yMiGUbDLeN1Xr/d9WtXZfx72xPAQWkrlcaBL7oMMVTwQ/q2onIO03GYb1TNMSb02AjjRtjQUBeXuilB9VX3wDWKI2O/Lviy/jW7q/9hyb6D0FPt7veiM2LRKOsCh1mmgC2r/rwZFqmOZKXUfLvW5tEqU6lztGaOX2SGqtIbUsy2bLEF41vYWvhy4ATohd5U2zi33e1kvvPp9HHU8I3ia7zuCdANNHy5yaKC4XTzRwg/8Qd5pPpXbA==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: iotconsultancy.nl
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DU0P190MB1978.EURP190.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: b97c0ba9-86fc-4a9b-aa72-08dc1c2ac9d2
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2024 15:48:47.9412 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: L0AhKHzc0TnB5tf/oX01/UU+ZDp04f6THpk0nkVixs02LHiJoT/ARiATrIudWjGMZCnjMCK7KUiJ/AgdCmTQZlLALygmZ0Cy6xSLxju7eGU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9P190MB1227
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/I7TnKeaq02s6LDbEJWXY1tRsAws>
Subject: Re: [urn] Registration request for urn:thread:
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/urn/>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jan 2024 15:48:57 -0000

Hallo Peter,

Thanks. Yes I could make the request later in the year. But, the spec update is likely not publicly available at that time. This could be solved by including a summary of the initial URN usage in the registration request, or in the email thread (not in the registration template) as a FYI ?
Or sending it by private email if people don't want to disclose the information.

The request we made defines an internal registry for URNs maintained by Thread Group. So once this is established, it won't be possible for IETF to have influence on what our members decide to register in there. Maybe they choose the wrong structure, or bad characters :)
For this a solution could be to constrain the allowable characters on the top level for all urn:thread:... items. For the structure/hierarchy, I don't see how we could or should constrain this now.   Future uses may vary wildly!

Below for illustration some examples of URNs that *might* be used in the future:

urn:thread:devid:23456789567   ->  a unique numerical identifier of a Thread Device
urn:thread:ver:4  ->  a Thread protocol version numerical reference
urn:thread:psk:d08cc32d4e36369899bd686d4eb881  ->  a pre-shared key (data in hex format)
urn:thread:psk:0IzDLU42NpiZvWhtTriB  -> same in base64 encoding (in this case the 'psk' sub-namespace is also defined differently)
urn:thread:spec:1.3.0:8.12  ->  a reference into the Thread spec (specific doc version, specific section)
urn:thread:dataset:a:b64:DggAAAAAAAEAAAADAAAPNQYABAAf/+ACCDl1jsgUSwf7Bwj98fGt0Hl9wAUQ82bOx6RGurl42Q0nq+OPIwMPT3BlblRocmVhZC01OTM4AQJZOAQQPKZ8lp77DQx0pNjukjtXbAwEAqD3+A==
  -> refers to one specific set of Thread network data used in a Thread network. It's base64 encoded.
urn:thread:some:hierarchy:allowed:foo

The idea is for the internal registry to record these 'sub-namespaces' as used in all the examples above.

regards
Esko

-----Original Message-----
From: Peter Saint-Andre <stpeter@stpeter.im> 
Sent: Monday, January 22, 2024 20:43
To: Esko Dijk <esko.dijk@iotconsultancy.nl>; urn@ietf.org
Subject: Re: [urn] 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
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn