Re: [urn] Request for oneM2M URN Namespace registration

[Miguel Angel Reina Ortega <[e-mail]>]

Dear Juha, 

I have discussed the issues with the oneM2M delegates and we have updated the oneM2M URN namespace with the following:

- General rule to limit NSS-restoftree to printable ASCII characters, as you proposed. 
- parameters for the MGMT URN namespace will be part of the q-component, so starting with "?=" as should not be part of the URN resolution. Please, advise if that's correct.

Best regards.

-----------------------------------------------------------------------------------------------------------------
Miguel Angel Reina Ortega – Testing Expert
Centre for Testing and Interoperability (CTI)
ETSI ? www.etsi.org ? [e-mail]
Phone: [phone] ? Mobile: [phone]

This email may contain confidential information and is intended for 
the use of the addressee only. Any unauthorized use may be unlawful. 
If you receive this email by mistake, please advise the sender
immediately by using the reply facility in your email software. 
Thank you for your co-operation.

-----Original Message-----
From: Hakala, Juha E <[e-mail]> 
Sent: 23 February 2022 08:57
To: Dale R. Worley <[e-mail]>; Miguel Angel Reina Ortega <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: VS: [urn] Request for oneM2M URN Namespace registration

Hello, 

-----Alkuperäinen viesti-----
Lähettäjä: urn <[e-mail]> Puolesta Dale R. Worley
Lähetetty: keskiviikko 23. helmikuuta 2022 4.28
Vastaanottaja: Miguel Angel Reina Ortega <MiguelAngel.ReinaOrtega=[e-mail]>
Kopio: [e-mail]; [e-mail]; [e-mail]
Aihe: Re: [urn] Request for oneM2M URN Namespace registration

As ETSI is a recognized standards body, we should fast-track this.

+ 1. 

Also, there's little specific information to review.  

Subtree registration page 

https://wiki.onem2m.org/index.php?title=OneM2M_URN_Namespace

provides additional information about oneM2M URNs, but there are some gaps. 

Namespace specific strings will consist of two parts: 

<nss-root>:<nss-restoftree>

Character set of nss-root is specified as a-z, A-Z, 0-9, but nothing is said about the character set of nss-restoftree. I suppose you could limit it to printable ASCII characters, in order to eliminate the impact of Unicode confusables. 

 Within nss-root MGMT, the nss-restoftree will have the following structure:  

urn:onem2m:mgmt.:nwkType:<identifier>:[<parameters>]

I suppose the dot after mgmt is an error. If so, we get URNs like: 

urn:onem2m:mgmt:nwkType:lora or urn:onem2m:mgmt:nwkType:ansi_c_12:parameter

Within nss-restoftree colon has two different roles in the mgmt sub-namespace. It separates both nwkType from identifier and identifier from parameter (if any). This might create confusion regarding the role of the parameter, since nothing in the URN syntax says that the parameter is not part of the identifier. And if in the future you need to sub-divide nwkType, it might no longer be obvious for someone who does not know the syntax already where the identifier is and whether there is a parameter. 

Since onem2m parameters will not have a role in identification, you might be better off including them as URN R-components. Since your URNs will not be resolved, this should not be problematic in any way. 

URN namespace registrations do not need to be RFCs. An RFC can be provided if the identifier system has not been specified elsewhere, and it is considered useful to create an RFC for this purpose (see e.g. RFC 8458; https://datatracker.ietf.org/doc/html/rfc8458) In your case, I do not think that RFC is required or even justified. It will be easier both for you and IETF if you send us just a template as specified in RFC 8141. All registrations published as such templates are listed at https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml. 

ETSI has already made one namespace registration as a template, available at https://www.iana.org/assignments/urn-formal/etsi. 

All the best, 

Juha   

 

I would recommend that the registration template specify how the NSSs are to be compared, although looking at RFC 8141, it doesn't seem to be required.  (It used to be that specifying the comparison rule was important.)  I suspect that oneM2M intends to use case-sensitive comparison and largely assign NSSs in a single case.

Dale

_______________________________________________
urn mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/urn