Author: Jaime Jiménez
@due(16-06-15 21:30).
@due(16-06-22 15:28).
@due(16-07-09 15:28).
@due(16-07-19 15:31) @done(16-07-22 15:31) .
{+cu} or {+su} if {+tu} superseeds both?
{+cu} only.{+tu} is used probably should be expanded to target urior similar.
There is no default mapping for the HC Proxy URI.
it would be able to successfully forward.
Guidelines for HTTP-to-CoAP Mapping Implementations
Describes how to do HTTP-to-CoAP Mapping to allow HTTP clients to access a CoAP Server via a proxy.
It introduces four possible entities, the HC Proxy, a Forward Proxy, a Reverse Proxy and an Interception Proxy.
They define basic use cases: legacy building control apps, making sensor data available to 3rd parties and smartphone for using home sensors.
The mapping has multiple parts: URI Mapping, Media Type Mapping, Response Mapping and Other Additional Mapping Guidelines.
CoAP URI mapping is needed on cases where coap and coaps are is not supported by default on browsers/network tools.
In the simple form there are few mapping templates for coap. The default URI mapping consist on appending one URI after the other (i.e. adding target uri or /{+tu}), for example: http://p.example.com/hc/coap://s.example.com/light. Other mapping might be discovered on ./well-known/core, on those cases the HC should use resource type: core.hc and attribute type hct. All the possible mappings are:
// default mapping
/{+tu}
// for coap uris
?coap_target_uri={+cu}
// for coaps uris
?coaps_target_uri={+su}
// either
?target_uri={+tu}
In the enhanced form more sophisticated mappings can be expressed. And certain template variables have been created for it:
s = "coap" / "coaps"
hp = host [":" port]
p = path-abempty
q = query
qq = [ "?" query ] The ABNF forms make use of RFC5234, RFC7252 and RFC6690. So you can do things like queries or specific paths to the sensor. For example you can specify you use secure coap and query for lights that are on.
http://p.example.com/hc?s=coaps&hp=s.example.com&p=/light&q=onThere is a discovery process for the HC functionality both on the HTTP and the CoAP side. A sample discovery on the HTTP would look like this:
Req: GET /.well-known/core?rt=core.hc HTTP/1.1
Host: p.example.com
Res: HTTP/1.1 200 OK
Content-Type: application/link-format
Content-Length: 18
// if plain link-format
</hc>;rt="core.hc"
// if JSON link-format
[{"href":"/hc","rt":"core.hc"}]For CoAP devices, they should also get back an anchor URI of the HC proxy as well as the URI mapping. The following example shows a CoaP request with the hct attribute.
Req: GET coap://[ff02::1]/.well-known/core?rt=core.hc
Res: 2.05 Content
</hc>;anchor="http://p.example.com";
rt="core.hc";hct="?uri={+tu}"The HC proxy also performs bidirectional Media Type Mapping of Media Types and content encodings into CoAP Content-Formats
The mapping will depend on whether the application is tightly or loosely coupled with the proxy. For HTTP unsupported media types the HC Proxy should simply answer with a 415 Unsupported Media Type response.
When dealing with an unrecognised CoAP cf
the HC proxy can use the application/coap-payload and append that content format ;cf= whichever is the content format number.
CoAP content formats are more limited or tightly coupled to applications than Internet ones. Thus, it is not possible to have fine-grained subclasses and optional parameters, instead you get a simple integer value. To solve that the draft optionally proposes looser coupling for specific types like XML, JSON or others.
Although possible, content transcoding is generally not advisable as it would tamper with the payload and might cause loss of information.
Document Shepherd: Jaime Jiménez, jaime.jimenez@ericsson.com
Area Director: Alexey Melnikov, aamelnikov@fastmail.fm
This document provides reference information for implementing a cross-protocol network proxy that performs translation from the HTTP protocol to the CoAP protocol. This will enable a HTTP client to access resources on a CoAP server through the proxy. This document describes how a HTTP request is mapped to a CoAP request, and then how a CoAP response is mapped back to a HTTP response. This includes guidelines for URI mapping, media type mapping and additional proxy implementation issues. This document covers the Reverse, Forward and Interception cross-protocol proxy cases.
The document is intended as an Informational RFC.
The document has gone through multiple expert reviews over the years and was last presented on IETF95.
There are several implementations available:
Each author has stated that they do not have direct, personal knowledge of any IPR related to this document. I am not aware of any IPR discussion about this document on the CoRE WG.
Appendix-A should be removed before publication. https://tools.ietf.org/html/draft-ietf-core-http-mapping-12#appendix-A
On the IANA section, the part that describes Interoperability considerations: should be updated with the
Published specification: (this I-D - TBD)RFCXXXX reference.
Few changes since the shepherds review, see: https://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-core-http-mapping-10.txt&url2=https://tools.ietf.org/id/draft-ietf-core-http-mapping-13.txt
The working group has very good consensus on this document as it is. HTTP mapping aspects raised by future CoAP extensions will then be addressed by these extensions or in separate documents.
Yes, some edits have been done, see https://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-core-http-mapping-10.txt&url2=https://tools.ietf.org/id/draft-ietf-core-http-mapping-13.txtNo errors, but some warnings are shown about existing ABNF.
I aggregated all CoAP ABNF refs here: http://jaimejim.github.io/temp/coap-abnfHas each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79?
Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified?
Are all normative references made to documents that are ready for advancement and are otherwise in a clear state?
Clear state, but non-Standard reference
[I-D.ietf-core-block]Does not apply
If this is a bis
document, have all of the errata been considered? Does not apply
IANA Considerations:
No registries are created.
No registries are created.