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

From: Jim Schaad <[email-masked]>
Date: Mon, 24 Jul 2017 14:31:37 +0200

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

---

From: Jim Schaad <[email-masked]>
Date: Tue, 25 Jul 2017 11:12:06 -0700

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

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

---

From: peter van der Stok <[email-masked]>
Date: Wed, 26 Jul 2017 09:47:28 +0200

Hi Jim,

The analysis below looks correct to me.
All error mappings follow the standard mapping
Two exceptions, coap Patch explicitly returns 4.13 and 5.03, not 
mentioned by http Patch at first sight,
but they can be converted to http 413 and 503 as they are very standard 
error codes.
Advertising as specified for http patch is not specified for coap patch

I don't think that mapping of caching behavior of patch is more complex 
than for other methods.

does that help?

Peter

Jim Schaad schreef op 2017-07-25 20:12:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core