[core] Questions on RFC 8075 - http to CoAP mapping

[Jim Schaad]

Following a number of discussions at the F2F meeting, I decided that I
really needed to look at the proxy code that I inherited/stole and see if
what it does matches what was documented. At this point in time I am still
trying to trudge through the code (and I don't really expect any help
there), however I have come up with a number of comments/questions that I
would like to see if there are answers to.

1. Is there any real difference between the default mapping of section 5.3
and the simple form mapping of section 5.4.1 where the template is {+tu}. I
cannot see what the difference would be and am currently planning to
implement just section 5.4 and ignore section 5.3

2. In looking at example #2 of section 5.4.2.1, I think I got misled based
on the example. Is there any reason why

=> https://p.example.com/hc/?s=coap&hp=s.example.com&p=/light

Is not a valid result? That is why can I not omit the "&q=" if there is
nothing there.

3. I am not sure what the correct story would be for dealing with the
following

GET coap://10.10.80.200/resource HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0)
Host: 10.10.80.200
Proxy-Connection: Keep-Alive

I generated that based on an ftp over http example, so it could easily be
completely strange and illegal. However, what would this mean and is there
a reason it was not covered?


RFC 8132 --- PATCH/FETCH

This document did not define any text to help me do this mapping. This
applies both to the methods and to the error codes. From the text it
appears that FETCH is a new concept while PATCH and iPATCH are/might have
some support from HTTP and thus can be directly translated. However, trying
to find all of the errors and documents on this is somewhat painful and if
the section on how to do it and what the error matching is would be helpful
both now and in the next version of the docment.

Jim

[Jim Schaad]

Off list I was asked to be more detailed about what my thinking was related
to the patch drafts

As of today I think that the following would be true:

For an http->coap proxy:

PATCH maps to PATCH without any changes (just like POST maps to POST).
iPATCH and FETCH do not have any mapping as they are not defined for HTTP.

4.09 Conflict maps to 4.09
4.22 Unpossessable Entity maps to 4.09


For a coap->http proxy:

PATCH map to PATCH without any changes
iPATCH maps to PATCH
FETCH fails as no mapping exists - Error of 4.05 Method Not Allowed

Same error mapping

Does that sound correct?

Jim

Post by Jim Schaad
RFC 8132 --- PATCH/FETCH
This document did not define any text to help me do this mapping.
This applies both to the methods and to the error codes. From the
text it appears that FETCH is a new concept while PATCH and iPATCH
are/might have some support from HTTP and thus can be directly
translated. However, trying to find all of the errors and documents
on this is somewhat painful and if the section on how to do it and
what the error matching is would be helpful both now and in the next
version of the docment.