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

[Esko Dijk <[e-mail]>]

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 ...

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.

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

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

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.

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 <[e-mail]>
> *Sent:* 03 October 2025 17:28
> *To:* [e-mail]; 'Christian Amsüss' 
> <[e-mail]>
> *Cc:* [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] | +31 6 
> 2385 8339
>

-- 
*IoTconsultancy.nl* | Email/Teams: [e-mail] | +31 6 
2385 8339