Re: [core] HTTP-CoAP default URI mapping: some draft proposals

[Bert Greevenbosch <[e-mail]>]

Hi Esko,

Thank you for your extensive description of the options and requirements.

I ponder between #1 and #4. I think #1 is easier to parse, but it misses the scheme indication as is possible in #4. The scheme indicator needs a bit extra complexity though, as the parser needs to determine whether the HTTP URI component is a scheme indicator, or the domain name part. I guess there will never be domain names "coap" and "coaps" (I hope these domain names are forbidden?) so we should be safe with that.

If we have a default coap scheme, I think constructs like
http://proxy.example.com/.well-known/core-translate//server.coap.example.com/4567/foo%2Fbar/a=3&b=5
should be forbidden.

Another problem is how to handle the default port 5683. Does it need to be included in the HTTP URI or not? I think we should be clear on this, such that there is no ambiguity whether two different HTTP URIs point to the same resource or not. I guess in scheme #4 we should mandate inclusion of the port number in the HTTP URI, as otherwise the port number can be confused with the path component.

Best regards,
Bert


From: [e-mail] [mailto:[e-mail]] On Behalf Of Dijk, Esko
Sent: 2013年5月13日 20:18
To: core ([e-mail])
Subject: [core] HTTP-CoAP default URI mapping: some draft proposals


Dear all,



below I’ve listed a number of proposals that the authors of draft-castellani-core-http-mapping discussed. The formal specification of the solutions (in terms of URI template) is mostly missing, but hopefully the examples make the main ideas clear. Each example shows a http URI, with which a HTTP-CoAP cross-protocol proxy at host ‘proxy.example.com’ is called. After the arrow (->) the extracted CoAP URI is shown, via which the CoAP server at ‘server.coap.example.com’ is called by the proxy.



After the solutions there’s a short table showing my personal (not with my co-authors) first analysis of how each solution meets the requirements. The requirements were posted on May 8th to the list.

Any feedback is welcomed!



regards,

Esko



---



Solution #0: placeholder proposal in draft-bormann-core-cross-reverse-convention-00



URI template: tbd



Example:

      http://proxy.example.com/.well-known/core-translate/1.2.3.4_4567/foo/bar?a=3&b=5

-> coap://1.2.3.4:4567/foo/bar?a=3&b=5



Notes: how to include IPv6 literals was not defined. CoAP scheme is derived from HTTP scheme (http or https). ‘_{Port}’ part is optional.





Solution #1: adding IPv6 support to #0



URI Template:

/.well-known/core-translate/{authority-encoded}/{path}?{query}



Notes: the proxy will percent-decode the {authority-encoded} to {authority} before constructing the COAP URI. CoAP scheme is derived from HTTP scheme (http or https).



Examples:

                http://proxy.example.com/.well-known/core-translate/%5B2001::23:25%5D:4567/foo/bar?a=3&b=5

->            coap://[2001::23:25]:4567/foo/bar?a=3&b=5



                http://proxy.example.com/.well-known/core-translate/server.coap.example.com:4567/foo/bar?a=3&b=5

->            coap://server.coap.example.com:4567/foo/bar?a=3&b=5



                http://proxy.example.com/.well-known/core-translate/server.coap.example.com/foo/bar?a=3&b=5

->            coap://server.coap.example.com/foo/bar?a=3&b=5



                http://proxy.example.com/.well-known/core-translate/1.2.3.4:4567/foo/bar?a=3&b=5

->            coap://1.2.3.4:4567/foo/bar?a=3&b=5





Solution #2: Split CoAP URI in parts and put parts in query arguments



URI Template:

/.well-known/core-translate/host={host}&port={port}&path={path}?{query}



Note: the query parts ‘host’, ‘port’  , ‘path’ and ‘query’ are all optional in the URI.



http://proxy.example.com/.well-known/core-translate?host=%5B1234::5678%5D&port=4567&path=/foo/bar?a=3&b=5

->            coap://[1234::5678]:4567/foo/bar?a=3&b=5



Solution #3: Entire CoAP URI as single query parameter

Inspired by certain web services that put http callback URIs in URI-query parameters.



URI template: tbd



Example:

http://proxy.example.com/.well-known/core-translate?uri=coap%3A%2F%2F%5B1234%3A%3A5678%5D%3A4567%2Ffoo%2Fbar%3Fb%3Dbefore_colon%253Aafter_colon

->            coap://[1234::5678]:4567/foo/bar?b=before_colon%3Aafter_colon





Solution #4: split CoAP URI in parts and put these parts in path components



URI template:

/.well-known/core-translate/{scheme}/{+host}/{port}/{+path_abempty}/{+query}



where:

  scheme        = "coap" / "coaps" / ""



  host          = matches production defined in RFC 3986 Sec. 3.2.2.

                  NOTE: need to percent-encode '[' and ']' in IP-literal



  port          = matches production defined in RFC 3986 Sec. 3.2.3.



  path_abempty  = matches production defined in RFC 3986 Sec. 3.3.

                  NOTE: need to percent-encode any '/' occurrence



  query         = matches production defined in RFC 3986 Sec. 3.4.

                  NOTE: need to percent-encode any '/' and '?' occurrence



  CoAP URI is reconstructed as per RFC 3986 Sec. 5.3. carrying out the

  following substitutions before going through the algorithm:



  - if scheme is the empty string, make it "coap";

  - if port is the empty string, make it "5683";

[[ - if path-abempty is the empty string, make it "/"; -- possibly not needed ]]

Example:
http://proxy.example.com/.well-known/core-translate/coap/server.coap.example.com/4567/foo%2Fbar/a=3&b=5

->            coap://server.coap.example.com:4567/foo/bar?a=3&b=5

---

URI mapping requirements


Note for the current requirements : there’s currently no requirement that the HTTP client should somehow communicate, in the HTTP request, specific CoAP Option values to the proxy, e.g. whether the proxy should use the Observe option or not in a CoAP request. We assume, for now, that is correct.

R1. Syntactic correctness of the HTTP URI (e.g. handle percent-encoding when needed);

R2. HTTP URI must be able include all elements of a CoAP URI
    (e.g. coap(s) scheme, hostname, host literals IPv4/IPv6, port, path, query components, characters allowed in CoAP URI)

R3. The mapping operation must produce a string that can be directly used by a proxy as input to the process of core-coap section 6.4. "Decomposing URIs into Options".

R4. HTTP URI should be easily readable/writable by humans, if possible;
    (e.g. easy to read the CoAP URI embedded in it; avoid multiple levels of percent encoding, etc.)

R5. HTTP cache friendliness of the mapping solution, i.e. maximize the caching of CoAP resources by HTTP intermediaries;
   (e.g. a solution where entire CoAP URI is provided as a single query parameter is bad in this respect)

R6. Normalised form: preferably there should be only one "normal"/default way to encode the URI
    (e.g. so that we don't end up with multiple different cache entries for the same CoAP resource in intermediaries.);

R7. HTTP URI should be as short as possible.

   #0 #1 #2 #3 #4
R1  +  +  +  +  +
R2  -  +  +  +  +
R3  +  +  +  +  +  (where details need to be defined for each solution)
R4  +  +  o  -  o
R5  +  +  -  -  +
R6  <to be checked>
R7  +  +  -  -  +/o
                     ^
     tentative best option, #1





________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.