Is it practical to have the GET version altogether?

[chrysn]

All I've found so far on why there's both the GET and the POST version of DoH in HTTP is that GETs are cachable.

In CoAP, we have FETCH, which is just there for cases like this, and does away with both contender's downsides:

• Compared to POST, it's cachable (and safe and thus idempotent)
• Compared to GET, it doesn't need
  • URI template handling (which I'd discourage in an embedded context -- it's reasonably simple here, but I wouldn't want to have to think of the different rules that'd apply if the template occurs in the path or query string), and
  • base64 encoding (which adds both processing and wire overhead).

The only upside I see of keeping GET/POST over FETCH is that DoC could then be implemented by just cross-proxying to a DoH server, but given that such a proxy is unconstrained, reasonably straightforward to implement on its own and can thus take load off the constrained client, I advocate going all FETCH.

[miri64]

I was also thinking about getting rid of GET. However, apart from the cross-proxying argument you gave, I also wanted to provide a method for "legacy CoAP" (so a CoAP implementation where FETCH is not implemented).

But then again, FETCH-support is relatively easy to deploy on the client side (you literally just need to provide the number for it). Mhh...

[miri64]

• URI template handling (which I'd discourage in an embedded context -- it's reasonably simple here, but I wouldn't want to have to think of the different rules that'd apply if the template occurs in the path or query string), and

IMHO a URI template processor does not need to have more complexity than say a URI parser (which in some cases we need with CoAP). The one I provided for RIOT takes ~400 bytes of ROM on a Cortex-M0. Once that's there, the question of adding a URI-Query option is just a matter of checking if the dns query is there or not when the URI template is resolved.

[chrysn]

There haven't been implementer complaints about FETCH in 2019 when OSCORE was finalized, which indicates that FETCH was indeed simple to support.

IMHO a URI template processor does not need to have more complexity than say a URI parser (which in some cases we need with CoAP).

I have hopes that many CoAP clients can do without a URI parser when the efforts of CoRAL and [CRI](https://datatracker.ietf.org/doc/draft-ietf-core-href/) bear fruit.

The one [I provided for RIOT](RIOT-OS/RIOT#16702) takes ~400 bytes of ROM on a Cortex-M0. Once that's there the question of adding a URI-Query option is just a matter of checking if the `dns` query is there or not when the URI template is resolved.

That does indeed look like a comprehensive implementation testing for several of the pitfalls. But it's still 400 byte (and a lot of code-to-be-maintained), and compatibility dangers from implementers who don't go all the way but just `s/{?dns}/?dns=$QUERY/` because that's all they've ever seen -- especially when the alternative is so much easier.

[miri64]

Another drawback of GET (as pointed out in the current draft version) is that with it block-wise transfer is not possible with large requests.

[miri64]

Ok, I think we agree for now that in the long run, we should remove GET and POST. However, at least for version -00 of the draft I would like to keep it in for two reasons: a) to document our thought process for posterity and b) in case we find a use case that requires GET and need to revert back to the current version of CoAP messaging. I documented the future removal of GET and POST by linking this issue in the future Change Log section in a8dcfd4.

[waehlisch]

Do we have an overview of FETCH support in CoAP implementations?

[chrysn]

I don't; Francesca and I started preparing a survey, but didn't even finish the requirements.

[waehlisch]

oops, ... then we do a brief survey offline. we need an overview, which implementation supports FETCH, for example.

[chrysn]

If it's a helpful data point: In all the interops and implementation discussions around OSCORE that I can remember (and I've been in many of them), never has any implementer complained about the use of FETCH that'd have kept them from using OSCORE with that library.

[miri64]

oops, ... then we do a brief survey offline. we need an overview, which implementation supports FETCH, for example.

Is that really necessary? As mentioned above, adding FETCH support is just a matter of adding a FETCH = 5 constant and using it in an application in accordance with RFC 8132. Checking all implementations in the list if they do that, on the other hand, seems like much more work.

[miri64]

The only nodes where FETCH is interesting is at proxies that cache. Here an (equally minor) adaptation needs to be made, that the payload of a FETCH request is considered for the cache key.

[waehlisch]

hard to follow. will talk offline.

[miri64]

Is that really necessary? As mentioned above, adding FETCH support is just a matter of adding a FETCH = 5 constant and using it in an application in accordance with RFC 8132. Checking all implementations in the list if they do that, on the other hand, seems like much more work.

Regardless, I looked a bit into this, and the data is a bit crushing. Of the 19 implementations I looked into so far, only 6 support FETCH. Granted, most of these implementations haven't received an update in years (many last before the publication of RFC8132), but even some implementations I would call reference implementations such as Erbium (in all its flavors known to me, Contiki, Contiki-NG, and Wakaama) do not support FETCH. 😕