Uri-Path and Uri-Query of Server URI

[kFYatek]

Up until the second-to-last pre-1.0 draft, the LwM2M Server URI Resource in Section E.1 (LwM2M Object: LwM2M Security) read:

Uniquely identifies the LwM2M Server or LwM2M Bootstrap-Server, and is in the form: "coaps://host:port", where host is an IP address or FQDN, and port is the UDP port of the Server.

However, it has been changed in 2017-0051R02-CR_security_object_bugfix_uri_format, and in all current versions, including the 1.0 and 1.0.1 approved versions, it reads:

Uniquely identifies the LwM2M Server or LwM2M Bootstrap-Server. The format of the CoAP URI is defined in Section 6 of RFC 7252.

Allowing all URIs that are valid as per RFC suggests that things like paths and query-strings are now allowed, so that e.g. coaps://example.com:1234/some/crazy/path?and=more&craziness now seems a valid LwM2M Server URI.

However, other parts of the spec do not seem to be prepared for such URIs; for example, section 8.2.4 mentions that Register shall be sent on the "/rd" URI and also that "The LwM2M Server MUST return a location under the /rd path segment" in Location-Path Options. It might be interpreted as requiring an absolute "/rd" path, essentially discarding any Uri-Path present in the Server URI.

There are more unresolved questions if the configured Server URI includes a query string. Shall these values be reproduced when sending Register or Bootstrap-Request? What if the configured URI already contains some query-string arguments that are meaningful for LwM2M, such as ep? Also, what about Update?

All in all:

• Is it legal for LwM2M Server URI to contain a non-empty path segment, e.g. coaps://example.com:1234/some/path?
  • If so, what are the semantics?
  • Shall it precede the /rd path of a Register URI or /bs path of a Bootstrap Request URI?
  • Or shall it be ignored, with absolute /rd and /bs paths always used?
  • If it is allowed and meaningful, shall the Location-Path returned in response to Register contain an absolute path or a path relative to the Server URI?
• Is it legal for LwM2M Server URI to contain a query, e.g. coaps://example.com:1234?some=query?
  • If so, what are the semantics?
  • Shall it be included in Register or Bootstrap Request URIs?
  • Or shall it be ignored?
  • Shall it also be included in Update URIs? (note that Update URI is dynamically built when performing the Register operation)
  • If it is allowed and meaningful, what happens if it includes options meaningful for LwM2M messages? For example what happens when the Server URI is coaps://example.com:1234?ep=iamcrazy? What will be the Register URI?
  • Shall it replace the ep attribute with Endpoint Client Name?
  • Shall it include another ep attribute? In what order?

[kFYatek]

Another interpretation that didn't occur to me while originally writing this ticket is that the Server URI written to the data model should actually include the /rd or /bs path.

So another question is: if Uri-Path in the Server URI resource is allowed and meaningful

• should the path on which the client sends the Register request, be "{Uri-Path from the Server URI}/rd", or
• should it be just "{Uri-Path from the Server URI}", and the /rd segment is supposed to be included in the value of the resource?

[kFYatek]

Also, just noting that on-site input from @hannestschofenig during the meeting of the Working Group with TestFest Warsaw participants on Wednesday seemed to suggest that:

• Both Uri-Path and Uri-Query is allowed
• /rd or /bs shall be appended to the Uri-Path present in the Server URI resource
• Uri-Query parameters as required by the Register operation shall be appended to those present in the Server URI resource; if there are query key duplicates (e.g. the Server URI contains ep=... query), both values shall be passed in the resulting URI

As for me, I think this would be a perfectly suitable conclusion.

[hannestschofenig]

From a related issue:

• OMA-TS-LightweightM2M-V1_0_1-20170704-A
• section: E.1

Allow to include uri-path and any uri-query in a resource of LwM2M server URI (/0/0/0). This will enable passing extra information (like tenancy) to LwM2M server.

For example: coaps://example.com:5684/my-creazy-rd?parameter=value then client registers: POST coaps://example.com:5684/my-creazy-rd?parameter=value&ep=device0123

[hannestschofenig]

For v1.1 we have to clarify the security processing that relates to the comparison between the content of a certificate (such as the string contained in the CN field of a cert) with the LwM2M Server URI resource value. A dedicated resource carrying the Server Name Indication (SNI) has been defined already.

[hannestschofenig]

If this issue is still valid, please re-issue it against the LwM2M v1.1 release.