"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:

• [x] The "Request URI", eg. coap://[ff02::1]/foo. Described in this document since #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.

[chrysn]

As part of enumerating those URIs, we should also look at where the Reply-From option of https://www.ietf.org/archive/id/draft-ietf-core-groupcomm-proxy-02.html fits in here. @marco-tiloca-sics, can that be one of those 4 categories? (I'd guess it's the 2nd, because if there is a Location option…)

[marco-tiloca-sics]

Yes, I think that the "Reply-From" option conceptually fits in the second category. More in detail:

• The option conceptually provides the client with "instructions" about where to send a follow-up request that reaches the originator of the response.

• In case the option is added by a forward-proxy or by a reverse-proxy that does not hide individual servers in the group, then the option specifies actual addressing information of the origin server. That's a strong fitting with the second category.

• In case the option is added by a reverse-proxy that hides also the individual servers in the group, then the option specifies addressing information pertaining to the proxy, such a that a request sent there will be forwarded by the proxy to the server in the group that originated the response. It feels like even this case still fits the second category, although in a broader sense.