Return-Path: X-Original-To: core@mail2.ietf.org Delivered-To: core@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 216E27997EBB for ; Tue, 21 Oct 2025 08:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=jpshallow.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5_PoQ7xYggV for ; Tue, 21 Oct 2025 08:21:40 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [31.22.13.189]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id C2ACD7997EAE for ; Tue, 21 Oct 2025 08:21:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=jpshallow.com; s=key; h=Sender:Content-Type:MIME-Version:Message-ID:Date: Subject:In-Reply-To:References:Cc:To:From:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=IT285b407EQ8GZHTLHv3k3flgD6frxsKkCPoGd4VNE8=; b=l987w7Gr4xp9iRMMGmRsNthyY7 HFNWKu7OuDiG0kIXLC40oZnv4TQuddJ2najpQsDQwruVXdvu7T3+rvHa3QszwFaZ47naoqEdeAT7L aA/4Fe77/rYNBK8U1Wd9u1YhOnV4RYPTtR96/f3x0319GxtqHiUJ6W2oAwXHmezsN7c9KJgPFatWd piCC6TaHKvLwu0PxhiwWkpbN2AViFrXca67sujd1mtIVt4ZnNiYkvraIOYjr4MfYVXjKrdPZN2AbV aEhXqp2Z5SOKupjw35BAiJComaRI7872cE+iO+nNh6ZqlwL8NXa3iI/DZWzwlrq0prsXXFV54tQM+ AtGWNneg==; Received: from router.jpshallow.com ([192.168.0.1] helo=DESKTOP433R5TL) by mail.jpshallow.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1vBEB8-0005Sg-7O; Tue, 21 Oct 2025 16:21:38 +0100 From: "Jon Shallow" To: "'Esko Dijk'" References: <175892923928.1872244.8058801630242481978@dt-datatracker-6c6cdf7f94-h6rnn> <148c01dc32d3$a61a6c30$f24f4490$@jpshallow.com> <0e962ec7-3597-4cc1-b4b6-b13a9b979404@iotconsultancy.nl> <12d801dc36ce$4f18f1f0$ed4ad5d0$@jpshallow.com> <175a0fad-7841-462f-97a5-7a2e7ebc0eb8@iotconsultancy.nl> <054001dc41df$506ceae0$f146c0a0$@jpshallow.com> <1d6bb3cd-b458-40e6-a2af-49cdb55b9590@iotconsultancy.nl> <07b001dc4273$0d67f020$2837d060$@jpshallow.com> <9ccc2edf-63e5-45b9-ba46-846b6965c4ce@iotconsultancy.nl> In-Reply-To: <9ccc2edf-63e5-45b9-ba46-846b6965c4ce@iotconsultancy.nl> Date: Tue, 21 Oct 2025 16:21:37 +0100 Message-ID: <096301dc429e$648ed320$2dac7960$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0964_01DC42A6.C6555E00" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHZ3xKcVDQbCKWjWo495PqytG0heALll0r1AhuAC6YCJGoIvQGyFBsaAZsQCgsBhc4LvwFgl11KAiCyqRgCUO+937RDHQlg Content-Language: en-gb Sender: supjps-ietf@jpshallow.com Message-ID-Hash: Q73X4NZRFPXRA5LQ5C23ASQ7C2HS5IWG X-Message-ID-Hash: Q73X4NZRFPXRA5LQ5C23ASQ7C2HS5IWG X-MailFrom: supjps-ietf@jpshallow.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-core.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: core@ietf.org X-Mailman-Version: 3.3.9rc6 Precedence: list Reply-To: supjps-ietf@jpshallow.com Subject: =?utf-8?q?=5Bcore=5D_Re=3A_I-D_Action=3A_draft-ietf-core-uri-path-abbrev-01?= =?utf-8?q?=2Etxt?= List-Id: "Constrained RESTful Environments (CoRE) Working Group list" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: This is a multipart message in MIME format. ------=_NextPart_000_0964_01DC42A6.C6555E00 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Esko, =20 Regarding 1. =20 If no client =E2=80=9Coption value =3D path=E2=80=9D 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. =20 However, what I think you are asking / thinking is that the CoAP URI = parser (that is building the PDU) converts =E2=80=9C/some/path=E2=80=9D = 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. =20 I guess I was thinking the app would be doing this =E2=80=93 however, = there is no reason why the URI parser gets told a list of =E2=80=9Cpath = =3D option value=E2=80=9D 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=E2=80=99s CoAP library for path expansion on = receipt of a request. =20 Regards =20 Jon =20 From: Esko Dijk =20 Sent: 21 October 2025 15:30 To: supjps-ietf@jpshallow.com Cc: core@ietf.org Subject: Re: [core] Re: I-D Action: = draft-ietf-core-uri-path-abbrev-01.txt =20 Regarding 1. "fallback", the use case I had in mind is shortening = certain paths (as supplied by the application layer) using = Uri-Path-Abbrev:=20 - 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 =E2=80=93 gets sent to the NACK handler if = defined). Ok, sounds good. > If the proxy-client has no valid matching =E2=80=9Coption value =3D = path=E2=80=9D 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, =20 Thanks for the clarifications. =20 Re 1 Fallback. =20 I am thinking of optionally providing a set of valid =E2=80=9Coption = value =3D path=E2=80=9D 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 = =E2=80=93 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 = =E2=80=9Cmcast yes|no, option value =3D path=E2=80=9D to give some = possible flexibility. =20 RST bubbling up to the application could be done as an Event (which = libcoap currently does =E2=80=93 gets sent to the NACK handler if = defined). =20 Re 2 Proxy handling 4.02 =20 If the proxy-client has no valid matching =E2=80=9Coption value =3D = path=E2=80=9D 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). =20 Regards =20 Jon =20 From: Esko Dijk = =20 Sent: 21 October 2025 09:59 To: supjps-ietf@jpshallow.com =20 Cc: core@ietf.org =20 Subject: Re: [core] Re: I-D Action: = draft-ietf-core-uri-path-abbrev-01.txt =20 Thanks Jon, see below for my set of responses where I had something to add still.=20 (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 =3D 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=20 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=E2=80=99t 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, =20 Apologies for the late response. See responses inline. =20 Regards =20 Jon =20 From: Esko Dijk = =20 Sent: 13 October 2025 21:31 To: supjps-ietf@jpshallow.com =20 Cc: core@ietf.org =20 Subject: Re: [core] Re: I-D Action: = draft-ietf-core-uri-path-abbrev-01.txt =20 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.=20 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=E2=80=99t work will be resource consuming and I = don=E2=80=99t think necessary. Jon> The =E2=80=98rfc to be=E2=80=99 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 =E2=80=98this option number is that path=E2=80=99 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.=20 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#nam= e-reverse-proxies https://datatracker.ietf.org/doc/html/draft-ietf-core-groupcomm-bis-14#se= ction-3.5.2 Jon1> Multicast-Timeout option works for me here. Jon> Certainly possible. Libcoap currently does this with N =3D 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 = =E2=80=93 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.=20 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. =20 Jon1> I guess the challenge here is if the upstream server sends back a = RST (as NON is in use), I don=E2=80=99t 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, =20 Thanks for this. =20 Please see inline for comments. =20 Regards =20 Jon =20 From: Esko Dijk = =20 Sent: 03 October 2025 17:28 To: supjps-ietf@jpshallow.com; = 'Christian Ams=C3=BCss' = Cc: core@ietf.org Subject: Re: [core] Re: I-D Action: = draft-ietf-core-uri-path-abbrev-01.txt =20 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.=20 =20 Jon> OK. =20 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. =20 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.=20 =20 Jon> The =E2=80=98rfc to be=E2=80=99 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. =20 Jon> I=E2=80=99m now thinking of making this optional in the library = layer. =20 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. =20 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) =20 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). =20 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. =20 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 =3D 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.=20 =20 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.=20 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).=20 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).=20 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.=20 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 = =E2=80=93 hence 5.02. =20 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)=20 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.=20 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.=20 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 --=20 IoTconsultancy.nl | Email/Teams: esko.dijk@iotconsultancy.nl = | +31 6 2385 8339 =20 =20 --=20 IoTconsultancy.nl | Email/Teams: esko.dijk@iotconsultancy.nl = | +31 6 2385 8339 =20 =20 --=20 IoTconsultancy.nl | Email/Teams: esko.dijk@iotconsultancy.nl = | +31 6 2385 8339 =20 =20 --=20 IoTconsultancy.nl | Email/Teams: esko.dijk@iotconsultancy.nl = | +31 6 2385 8339 =20 ------=_NextPart_000_0964_01DC42A6.C6555E00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Esko,

 

Regarding 1.

 

If no client =E2=80=9Coption value =3D path=E2=80=9D sets = are defined, there will be no client fallback for the response if the = request contained Uri-Path-Abbrev.=C2=A0 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 = =E2=80=9C/some/path=E2=80=9D 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 = =E2=80=93 however, there is no reason why the URI parser gets told a = list of =E2=80=9Cpath =3D option value=E2=80=9D and then the client = library does all the heavy lifting when building the options.=C2=A0 This = list would be different to the fallback list for the client.=C2=A0 This = (same) list would however need to be pushed to the server=E2=80=99s CoAP = library for path expansion on receipt of a = request.

 

Regards

 

Jon

 

From:<= /b> Esko Dijk = <esko.dijk@iotconsultancy.nl>
Sent: 21 October 2025 = 15:30
To: supjps-ietf@jpshallow.com
Cc: = core@ietf.org
Subject: Re: [core] Re: I-D Action: = draft-ietf-core-uri-path-abbrev-01.txt

<= p class=3DMsoNormal> 

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 =E2=80=93 gets sent to the NACK = handler if defined).

Ok, sounds good.

> If the = proxy-client has no valid matching =E2=80=9Coption value =3D = path=E2=80=9D 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 = =E2=80=9Coption value =3D path=E2=80=9D 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 =E2=80=93 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 =E2=80=9Cmcast yes|no, option = value =3D path=E2=80=9D to give some possible = flexibility.

 

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

 

Re 2 Proxy handling 4.02

 

If the proxy-client has no valid matching =E2=80=9Coption = value =3D path=E2=80=9D 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:<= /b> Esko Dijk = <esko.dijk@iotconsultancy.= nl>
Sent: 21 October 2025 09:59
To: supjps-ietf@jpshallow.comCc: core@ietf.org
Subject: Re: = [core] Re: I-D Action: = draft-ietf-core-uri-path-abbrev-01.txt

<= p class=3DMsoNormal> 

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 =3D 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=E2=80=99t 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:<= /b> Esko Dijk = <esko.dijk@iotconsultancy.= nl>
Sent: 13 October 2025 21:31
To: supjps-ietf@jpshallow.comCc: core@ietf.org
Subject: Re: = [core] Re: I-D Action: = draft-ietf-core-uri-path-abbrev-01.txt

<= p class=3DMsoNormal> 

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=E2=80=99t work = will be resource consuming and I don=E2=80=99t think = necessary.

Jon> The =E2=80=98rfc to be=E2=80=99 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 =E2=80=98this = option number is that path=E2=80=99 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-ie= tf-core-groupcomm-proxy#name-reverse-proxies
https://datatracker.ietf.org/doc/html/draft-ietf-cor= e-groupcomm-bis-14#section-3.5.2



Jon1>  = Multicast-Timeout option works for me here.


Jon> Certainly = possible.  Libcoap currently does this with N =3D 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 =E2=80=93 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=E2=80=99t = 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:<= /b> Esko Dijk = <esko.dijk= @iotconsultancy.nl> =
Sent: 03 October 2025 17:28
To: supjps-ietf@j= pshallow.com; 'Christian = Ams=C3=BCss' <christian= @amsuess.com>
Cc: core@ietf.org=
Subjec= t: Re: [core] Re: I-D Action: = draft-ietf-core-uri-path-abbrev-01.txt

<= p class=3DMsoNormal> 

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 = =E2=80=98rfc to be=E2=80=99 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=E2=80=99m 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 =3D 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)
------------
T=
he 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 =E2=80=93 = 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: esko.dijk@iotconsultancy.nl | +31 6 2385 8339

 

 

 

 

 

 

 

------=_NextPart_000_0964_01DC42A6.C6555E00--