[core] Re: I-D Action: draft-ietf-core-uri-path-abbrev-01.txt

[Jon Shallow <[e-mail]>]

Hi Esko,

 

Regarding 1.

 

If no client “option value = path” sets are defined, there will be no client fallback for the response if the request contained Uri-Path-Abbrev.  There will never be fallback if the request does not contain a Uri-Path-Abbrev.

 

However, what I think you are asking / thinking is that the CoAP URI parser (that is building the PDU) converts “/some/path” to an Uri-Path-Abbrev option + value if there is a complete path match against some list, otherwise the parser creates zero or more Uri-Path options.

 

I guess I was thinking the app would be doing this – however, there is no reason why the URI parser gets told a list of “path = option value” and then the client library does all the heavy lifting when building the options.  This list would be different to the fallback list for the client.  This (same) list would however need to be pushed to the server’s CoAP library for path expansion on receipt of a request.

 

Regards

 

Jon

 

From: Esko Dijk <[e-mail]> 
Sent: 21 October 2025 15:30
To: [e-mail]
Cc: [e-mail]
Subject: Re: [core] Re: I-D Action: draft-ietf-core-uri-path-abbrev-01.txt

 

Regarding 1. "fallback", the use case I had in mind is shortening certain paths (as supplied by the application layer) using Uri-Path-Abbrev: 
- without ever doing any fallback behavior (for that particular application layer / caller at least) ; and
- without remembering the server as "doesn't support Uri-Path-Abbrev" in case of error. (So next time the Uri-Path-Abbrev option will be sent, as usual.)

This is required for those use cases I mentioned where servers are known to support the option + value.  Errors like 4.02 or RST may be caused by other things in this case, and shouldn't trigger extra traffic on the network.
Just wanted to make sure this is possible with libcoap!

> RST bubbling up to the application could be done as an Event (which libcoap currently does – gets sent to the NACK handler if defined).

Ok, sounds good.

> If the proxy-client has no valid matching “option value = path” pairs, then it will not try an expansion and any  upstream-server 4.02 response gets passed back to original-client (and 5.02 if RST received).

Sounds good also; then we get the expected default proxy behavior while it can still be configured optimally for a specific application/use-case.

Esko

On 21-10-2025 12:11, Jon Shallow wrote:

Hi Esko,

 

Thanks for the clarifications.

 

Re 1 Fallback.

 

I am thinking of optionally providing a set of valid “option value = path” pairs (which by default is no pairs) for the client.  If Uri-Path-Abbrev option gets rejected, and the option value is in the valid set, then fallback, otherwise there will be no fall back – so client application is in control.  With libcoap, both the library and application can easily determine that the current request is going to a multicast address. The valid pairs can easily be extended to “mcast yes|no, option value = path” to give some possible flexibility.

 

RST bubbling up to the application could be done as an Event (which libcoap currently does – gets sent to the NACK handler if defined).

 

Re 2 Proxy handling 4.02

 

If the proxy-client has no valid matching “option value = path” pairs, then it will not try an expansion and any  upstream-server 4.02 response gets passed back to original-client (and 5.02 if RST received).

 

Regards

 

Jon

 

From: Esko Dijk  <mailto:[e-mail]> <[e-mail]> 
Sent: 21 October 2025 09:59
To: [e-mail] <mailto:[e-mail]> 
Cc: [e-mail] <mailto:[e-mail]> 
Subject: Re: [core] Re: I-D Action: draft-ietf-core-uri-path-abbrev-01.txt

 

Thanks Jon,

 see below for my set of responses where I had something to add still. 
(sorry for the long text, but it's getting smaller when counted by number of items :) )

1. --- Optional "fall back" functionality ---
ED1> The app-layer caller could of course set a special flag in its API call that indicates "fall back to, and resend with, expanded Uri-Path options if I see at least N replies that are either 4.02 or RST". This would let the library handle the fallback itself with some knowledge input by the app-layer. But given that we target use cases where all parties involved would support the option by design, it may be not so useful to implement this in a library.

Jon> Certainly possible.  Libcoap currently does this with N = 1 and I am thinking about making that optional.

ED2> So for the (expected, typical) case where the client does know that all servers in the group do support the option, the optional behavior could be disabled.
Therefore I had some doubt that such mechanism would be useful for any case.
(Brainstorming here:) it could still be useful for the application layer on a client to get notified about any RST messages of group members, even though it's not a proper CoAP response. After all it could be really a 4.02 response that the server has decided to convert to a RST instead and has taken the effort to send out. Like a "pseudo-4.02-or-4.00".

Jon1> For the multicast scenario it does not make that much sense to disable as NON is in use and any legacy server will not know about converting a RST to a 4.02 for Uri-Path-Abbrev.

Not sure if we had the same thing in mind here! I was arguing that if the client sending a multicast by design "knows" (i.e. the application designer knows) that 
 1. it always enables the Uri-Path-Abbrev option in its requests;
 2. it knows it never wants to fall back to sending long paths because e.g. that would push the message length over the 1-radio-frame limit;
 3. it knows that all servers it is sending to (by design) support Uri-Path-Abbrev with the specific values used;
then this client MUST have some way in the CoAP library API to disable any "fall back" functionality that automatically switches from Uri-Path-Abbrev to Uri-Paths and may autonomously resend the multicast request in case of any indication of a server's failure (like 4.02).
Hence my proposal was that the app layer on the client node should disable any "fall back" functionality on the CoAP stack at least for itself, before sending the multicast request.
Or otherwise that functionality could be disabled by default; as discussed in the draft the option ought to be used only when it's known more or less the server would support it, and the CoAP library doesn't have that knowledge.

In addition to this, there was a (more brainstorm like) idea that a CoAP library API should also have a way to notify this client when some of the server(s) respond RST instead of a CoAP response. I.e. the info of "there was a RST" is passed on to the higher layer just like it would pass up a response.
Normally this is a layer violation, but in the CoAP case there's some layer conflation and this RST may carry useful information for the client as it can be a substitute for certain error responses like 4.02 or 4.00.
This feature could be used precisely to handle cases where a legacy server doesn't know about converting a RST to a 4.02 for Uri-Path-Abbrev. If the app-layer on the client knows there could be legacy servers in the group, it's useful to get their "RST responses" as well.

2. --- Proxy handling of 4.02 responses ---

Jon1> I guess the challenge here is if the upstream server sends back a RST (as NON is in use), I don’t think I am expecting the Proxy to convert this to a 4.02 to send back to the client (as perhaps CON is in use).  But the Proxy may convert it to a 5.02.

Definitely, in case the proxy receives a RST it indicates the 5.7.1 RFC 7252 case of "a response that cannot be processed by the proxy" which includes all cases of rejected messages. Then it's a MUST to send back the 5.02 response per 7252.
But when the server's response is a 4.02, (and there's typically no critical not-understood option in this response message), then the proxy just sends back that response as is (4.02).
The client may therefore receive a mix of success / 4.02 / 5.02 responses for example.

Esko

On 20-10-2025 18:33, Jon Shallow wrote:

Hi Esko,

 

Apologies for the late response.  See responses inline.

 

Regards

 

Jon

 

From: Esko Dijk  <mailto:[e-mail]> <[e-mail]> 
Sent: 13 October 2025 21:31
To: [e-mail] <mailto:[e-mail]> 
Cc: [e-mail] <mailto:[e-mail]> 
Subject: Re: [core] Re: I-D Action: draft-ietf-core-uri-path-abbrev-01.txt

 

Hi Jon,

Here a few follow-up comments again to your mail. I copied below only a subset of your answers; where I had something to respond further. 

Jon> The libcoap implementation tagging only occurs following a 4.02 response to PDU with Uri-Path-Abbrev, expansion sent and then success response.  Christian has asked what happens when a server only supports a subset of the Uri-Path-Abbrev option values and a missing one was chosen.  Not sure how to handle that.

It sounds like the same recipe would apply here: if the subsequent expansion succeeds, then tag the server as "not supporting Uri-Path-Abbrev" ? Assuming we don't want to track what individual numbers a server does/does not support ...

Jon1> Yes, if using Option Uri-Path-Abbrev elicits a 4.02 response, then when the same request is resubmitted with Uri-Path-Abbrev expanded out to one or more Uri-Path options then that server is tagged as "not supporting Uri-Path-Abbrev".  Maintaining a list of individual numbers that work / don’t work will be resource consuming and I don’t think necessary.

Jon> The ‘rfc to be’ values (and updated as per Uri-Path-Abbrev registry) are known by the libcoap layer.  Expansion cannot take place at the library level if not known and would have to be passed back to the implementation to decide what to do.  I was trying to reduce some of the heavy lifting here.

When sending the request: in general the application layer still has to "bless" the attempted use of Uri-Path-Abbrev before the library would be allowed to attempt to use it. If it does this, the application layer may as well supply the value - was my thought. Of course for the specific values of RFC-to-be , the CoAP library could do this translation.   I was more thinking of the foreseen cases like for example the EST-coaps protocol which we discussed, where every resource of the protocol get its unique number assigned. A generic CoAP library might not know all these allocated values for all protocols running on top of CoAP. (Although it could be compiled specifically for support of, say, EST-coaps in which case these numbers are added to the library code, while numbers of potentially 10s of other protocols are not compiled in if not needed, to save code space.)
When receiving a request: yes, an application would either need to receive the Uri-Path-Abbrev number and decide how to react; or the application would need to preregister its known pairs (number, path) to prime the library for the expansions it's going to do.

Jon1> Certainly possible a new option number comes along that the CoAP layer does not know about and therefore cannot expand when a client does a retransmit with expansion.  The server CoAP layer will need to know how to expand out an option number when looking up a resource, unless resources can be defined by option number.  So here, the libcoap layer for both the client and server currently hold the known option numbers.  That said, there is no reason as to why there cannot be an API that defines ‘this option number is that path’ and does make sense for usage of code space.  Again, the server can also invoke the same API or define a set of resources based on option numbers as an alternative to the full path name. 

Jon> It is possible the servers behind a reverse-proxy could be multicast, so the client may not know this.

There's some discussion of this in groupcomm-bix and groupcomm-proxy: in short, it should be built such that a (legitimate) client will know this.
https://datatracker.ietf.org/doc/html/draft-ietf-core-groupcomm-proxy#name-reverse-proxies
https://datatracker.ietf.org/doc/html/draft-ietf-core-groupcomm-bis-14#section-3.5.2





Jon1>  Multicast-Timeout option works for me here.


Jon> Certainly possible.  Libcoap currently does this with N = 1 and I am thinking about making that optional.

So for the (expected, typical) case where the client does know that all servers in the group do support the option, the optional behavior could be disabled.
Therefore I had some doubt that such mechanism would be useful for any case.
(Brainstorming here:) it could still be useful for the application layer on a client to get notified about any RST messages of group members, even though it's not a proper CoAP response. After all it could be really a 4.02 response that the server has decided to convert to a RST instead and has taken the effort to send out. Like a "pseudo-4.02-or-4.00".

Jon1> For the multicast scenario it does not make that much sense to disable as NON is in use and any legacy server will not know about converting a RST to a 4.02 for Uri-Path-Abbrev.

Jon> OK.  I had read in RFC7252 5.7.1 Proxy Operation
   If the request to the
   destination returns a response that cannot be processed by the proxy
   (e.g, due to unrecognized critical options or message format errors),
   then a 5.02 (Bad Gateway) response MUST be returned.
Jon> as the proxy knew it had forwarded an unrecognized critical option and got back a 4.02 response that it did not know what to with it – hence 5.02.

The "unrecognized critical options" here refers to only critical unrecognized options in the server's response, not in the client's request. 
The "cannot be processed" here refers to a message from the server that's incorrectly formatted or needs to be treated as such by design (i.e. an unrecognized critical option that's not safe-to-forward).
It may be somewhat unclearly specified. The idea was I think that an error response, no matter its value, should just be relayed back to the client - from the Proxy point of view it's a valid error response that needs to go back to the client.
So, a 4.02 response would remain a 4.02 response - assuming there would typically not be an unrecognized critical option in this response. (It doesn't matter what options were in the request.)

"as the proxy knew it had forwarded an unrecognized critical option" - sounds to me like the proxy is here trying to do something smart which is not helpful for protocol operation in this case.
The client used the option in the first place, so the client needs to get back the 4.02 error information.

 

Jon1> I guess the challenge here is if the upstream server sends back a RST (as NON is in use), I don’t think I am expecting the Proxy to convert this to a 4.02 to send back to the client (as perhaps CON is in use).  But the Proxy may convert it to a 5.02.

best regards
Esko

On 6-10-2025 16:34, Jon Shallow wrote:

Hi Esko et al,

 

Thanks for this.

 

Please see inline for comments.

 

Regards

 

Jon

 

From: Esko Dijk  <mailto:[e-mail]> <[e-mail]> 
Sent: 03 October 2025 17:28
To:  <mailto:[e-mail]> [e-mail]; 'Christian Amsüss'  <mailto:[e-mail]> <[e-mail]>
Cc:  <mailto:[e-mail]> [e-mail]
Subject: Re: [core] Re: I-D Action: draft-ietf-core-uri-path-abbrev-01.txt

 

Hi Jon, Christian, (all,)

here a few selected thoughts/answers in this discussion - these may overlap with your answers or be superseded by them, not sure. Still catching up on it!







Q: What should happen with a 5.02 response?

In this case the client can't do much about it: a server, or proxy, returned something (like an Option) in the response, that the proxy in the chain just before it could not understand.


The best thing to do for a CoAP library is report the error back to the higher layer and not do anything else smart. 

 

Jon> OK.

 

Libcoap tags the CoAP session with 'no uri-path-abbrev support' on receipt
of 4.02 so subsequent application requests on the same session gets
Uri-Path-Abbrev expanded before transmission.

What if the 4.02 was due to other reasons/options? This tagging should perhaps only happen if a 4.02 occurred and doing the expansion to Uri-Path, after that, led to success.

 

Jon> The libcoap implementation tagging only occurs following a 4.02 response to PDU with Uri-Path-Abbrev, expansion sent and then success response.  Christian has asked what happens when a server only supports a subset of the Uri-Path-Abbrev option values and a missing one was chosen.  Not sure how to handle that.


I also wonder if a CoAP library could do these expansions, generally - in many use cases it wouldn't know the specific value to expand to, which only the higher layer (caller) would know. 

 

Jon> The ‘rfc to be’ values (and updated as per Uri-Path-Abbrev registry) are known by the libcoap layer.  Expansion cannot take place at the library level if not known and would have to be passed back to the implementation to decide what to do.  I was trying to reduce some of the heavy lifting here.

 

Jon> I’m now thinking of making this optional in the library layer.

 

Using NON for the first Uri-Path-Abbrev gets a RST response, so CON should
be used here.

Doesn't the caller application determine whether CON or NON is used?  Not sure if it's acceptable if the stack changes an intended NON into a CON.
Maybe just notify the caller of the result and not do anything else.

 

Jon> I was thinking that the application should build the PDU with Uri-Path-Abbrev with a CON, so as not to get the MAY response of a RST or not to a NON.


Unclear as to how Uri-Path-Abbrev should be used in a multicast environment

(servers likely to drop 4.xx if overriding RFC7252 for NON or likely to drop
RST responses)
 
Q: How will multicast get handled?

The way we now specify the option, the caller/application needs to indicate explicitly that a Uri-Path-Abbrev is to be used in a request. If then a 4.02 comes back, or a RST, or nothing, or a mixture of these reactions from different servers, then it's up to the caller/application to decide what to do. (E.g. continue, send again, or send again without Uri-Path-Abbrev).

 

Jon> Application decision making here is going to be interesting!


The expected use cases for multicast Uri-Path-Abbrev, as specified now, are those where the client knows by design that the target responding servers will support Uri-Path-Abbrev. In such case, there's no need to resend the request or fall back to expanded Uri-Path options. But only the app-layer/caller knows this information and knows what to do next.

 

Jon> It is possible the servers behind a reverse-proxy could be multicast, so the client may not know this. However, there does need to be some out of band knowledge for the client as to whether Uri-Path-Abbrev can be used or not.


The app-layer caller could of course set a special flag in its API call that indicates "fall back to, and resend with, expanded Uri-Path options if I see at least N replies that are either 4.02 or RST". This would let the library handle the fallback itself with some knowledge input by the app-layer. But given that we target use cases where all parties involved would support the option by design, it may be not so useful to implement this in a library.

Jon> Certainly possible.  Libcoap currently does this with N = 1 and I am thinking about making that optional.

Jon> The same could apply to ongoing proxy client session to the upstream server.

(legacy) Proxy - does not know Uri-Path-Abbrev)
------------
The test  for critical option is early on in libcoap stack - before any
proxy logic and so sends back a 4.02 or RST.

Safe-to-forward is defined by RFC 7252 as to be forwarded by a proxy that doesn't understand the (critical) option.
So this early check doesn't work for a proxy. Does this mean libcoap can't support a proxy? Or if it can, is this a bug in libcoap? Sorry if I got things wrong here. 

 

Jon> My initial testing was with a reverse-proxy where the libcoap library failed to forward the safe-to-forward (a bug, now fixed).  As it happens, forwarding-proxy works as per RFC7272.  Sorry for the confusion here.

If proxy (safe-forward-test) test was to be done before critical option test
then things should get properly forwarded.  If however there is a
Proxy-Scheme and the proxy converts this and URI-* into Proxy-Uri (unlikely,
libcoap does not do this) this will get rejected by upstream server.

Christian did start the discussion (on this list and in corr-clar issues) about whether a proxy could decide to turn separate options into a single Proxy-Uri, or not. Still unclear to me. 

Jon> It is messy.  The resultant Proxy-Uri mut not contain any component that creates a Uri-Path when parsed into the separate options as they will clash with the Uri-Path-Abbrev option (both are not allowed). 

Jon> I have not seen any proxies that combine options into a Proxy-Uri (libcoap does not do it), but I have seen scenarios where the proxy added in / removes some of the Uri-Path options as the request gets passed on to different servers.

Q: If upstream server does not handle Uri-Path-Abbrev, would the legacy
proxy send back a 5.02 or 4.02?

The server would send a 4.02 response. The proxy would just forward this response back to the client (possibly via a chain of proxies). 
I think 5.02 in the proxy only occurs in specific case like e.g. the server sends back a critical Option that's unsafe-to-forward *and* the proxy doesn't understand. 

Jon> OK.  I had read in RFC7252 5.7.1 Proxy Operation

   If the request to the

   destination returns a response that cannot be processed by the proxy

   (e.g, due to unrecognized critical options or message format errors),

   then a 5.02 (Bad Gateway) response MUST be returned.

Jon> as the proxy knew it had forwarded an unrecognized critical option and got back a 4.02 response that it did not know what to with it – hence 5.02.

 

New Proxy - does know about Uri-Path-Abbrev
--------------
Will know not to reconstruct a Proxy-Uri if Uri-Path-Abbrev is present.

(Maybe it shouldn't ever reconstruct a Proxy-Uri - still under discussion - see above) 

Jon> I am of the opinion that this should not happen, even though there is a valid corner case.

The proxy-client component acts as per libcoap client, namely on detection
of 4.02 with Uri-Path-Abbrev in request will re-transmit the expanded
request with nothing passed back to client.  If that fails, then the
upstream server's response is passed back to downstream client.

The proxy itself by default shouldn't be expanding Uri-Path-Abbrev - it's expected to just forward options I think.
The -01 draft allows a proxy to expand "if it has reason to assume that the option is not understood" - how would libcoap know that reliably? A 4.02 alone is not sufficient maybe - it could be due to another option.

Jon> For libcoap, this can only happen when there is a 4.02 to a request that does have Uri-Path-Abbrev in it as currently client and proxy-client follow the same logic.


To do this right, it would need to be configured from a higher layer explicitly e.g. a proxy operator sets this behavior so that only then the proxy client code starts to automatically expand. 

Jon> Yes, I think this needs to be configurable.

Q: Should this proxy send back a 4.02 or 5.02 on getting a 4.02 from
upstream server when electing not to expand Uri-Path-Abbrev?

4.02 response is just sent back as 4.02.  If the proxy sees an unrecognized critical unsafe-to-forward Option in the *response* then it would send 5.02. 

Jon> Yes, it should only be a 4.02, but see my confusion about 5.02 above.

Q: For caching responses, should the cached request (hash) include the
Uri-Path-Abbrev, or should the proxy always (even if not forwarding it)
expand the request and cache the expanded request (hash)

Sounds like a topic for the CoRE interim! Another option is to cache both hashes - not sure if this is a real possibility or that I'm saying something ridiculous now.

Jon> Relatively easy to have two hashes when Uri-Path-Abbrev is used (just hash the expanded PDU as well), when Uri-Path-Abbrev is not used, then building the Uri-Path-Abbrev version of the hash would take time and may never be used.



best regards
Esko

-- 
IoTconsultancy.nl | Email/Teams: [e-mail] <mailto:[e-mail]>  | [phone]

 

 

-- 
IoTconsultancy.nl | Email/Teams: [e-mail] <mailto:[e-mail]>  | [phone]

 

 

-- 
IoTconsultancy.nl | Email/Teams: [e-mail] <mailto:[e-mail]>  | [phone]

 

 

-- 
IoTconsultancy.nl | Email/Teams: [e-mail] <mailto:[e-mail]>  | [phone]