"request URI" not defined

[cdh4u]

The RFC uses "request URI" terminology, but there is no definition or reference of what a request URI is.

Also, while the RFC document does describe how the request URI can be generated based on CoAP message elements, it is not very clear that the request URI is not a message element itself (in SIP, the request URI is part of the message syntax).

[ektrah]

Thanks! We should probably include some bits from section 2 of RFC 7230 on this (where it's called "target URI"). It might also be a good idea to emphasize the distinction between the concept (request URI) and its representation (Uri-* options).

[cabo]

Reopen due to large PENDING

[chrysn]

Let's try to enumerate all the URIs that come with a CoAP request/response:

• The "Request URI", eg. coap://[ff02::1]/foo. Described in this document since Close #10: "request URI" not defined #33
• The URI that was actually acted on, which the client (in the multicast case) only learns when a response comes, eg coap://[2001:db8::1]/foo. I'm not sure this is relevant anywhere other than being the starting point for the next step.
• The URI that the response tells us something about, which is different from the acted-on URI when there are Location options. If there is a response body, that is also the base URI for resolving URI references in the response body. Eg. if the Location was ["a", "b"], that is coap://[2001:db8::1]/a/b. When there is no response body, that can still have an impact on caches. This may be related .
• The URI the of the client for when a role reversal happens. This has no path components so it may be coap://[2001:db8::2]:61616. In some transports that may not be expressible or limited in its usefulness (a TCP client has a port but only the connected server can send). This is relevant eg. for a Resource Directory.