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

From: "Dijk, Esko" <[email-masked]>
Date: Mon, 13 May 2013 12:17:33 +0000

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.

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 13 May 2013 14:58:34 +0200

Esko,

thanks for exploring this space some more.

I'm intrigued by this aspect:

On May 13, 2013, at 14:17, "Dijk, Esko" <[email-masked]> wrote:

> communicate, in the HTTP request, specific CoAP Option values

When I designed the URI scheme for coap.me, this was a requirement.
But where do you put those options?  There is a need to retain transparency for the path and the query.

I finally came up with something that looks like this:

http://coap.me/etag=9032625142006256669/coap://coap.me/

(the 9032625142006256669 is just a goedelized byte string here.
There is also syntax to specify the method, a payload (!), and non-confirmable use, which probably is very specific to the diagnostic purpose of coap.me.)

Grüße, Carsten

---

From: Bert Greevenbosch <[email-masked]>
Date: Tue, 14 May 2013 01:19:18 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Dijk, Esko
Sent: 2013年5月13日 20:18
To: core ([email-masked])
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.

regards,

Esko

---

URI template: tbd

Example:

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

URI Template:

Examples:

URI Template:

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

URI template: tbd

Example:

URI template:

where:

Example:

---

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.

   #0 #1 #2 #3 #4
R1  +  +  +  +  +
R2  -  +  +  +  +

---

From: "Dijk, Esko" <[email-masked]>
Date: Tue, 14 May 2013 14:36:11 +0000

Thanks for the pointer; it seems that including CoAP specific options is useful for diagnostic purposes.
Perhaps that is going to be less used for general protocol translation (i.e. as a default mapping for non-diagnostic applications). But we could add a requirement to at least allow, or be prepared, for inclusion of CoAP options/method-codes/etc. in the HTTP URI.

If the goal is to do any CoAP operations from the browser URL line, then indeed you need to include parameters for method, payload, etc.
(There are also various HTTP libraries that can only do HTTP GET!)

Esko

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: Monday, May 13, 2013 14:59
To: Dijk, Esko
Cc: core ([email-masked])
Subject: Re: [core] HTTP-CoAP default URI mapping: some draft proposals

Esko,

Grüße, Carsten

---

From: "Dijk, Esko" <[email-masked]>
Date: Tue, 14 May 2013 15:02:54 +0000

> but it misses the scheme indication as is possible
Yes, indicating the scheme explicitly is also useful perhaps. I was just thinking whether it is then allowed then to do a ‘http’ (non-secured) request to fetch a ‘coaps’ (secured) resource?
Maybe we should look at that in light of the recent IESG DISCUSS (Stephen Farell). There are arguments going in both directions.

> I guess in scheme #4 we should mandate inclusion of the port number in the HTTP URI
That’s possible; I think the current solution is to allow an empty string also (which gives // in the path. Is that an issue?)

Esko

From: Bert Greevenbosch [mailto:[email-masked]]
Sent: Tuesday, May 14, 2013 03:19
To: Dijk, Esko; core ([email-masked])
Subject: RE: HTTP-CoAP default URI mapping: some draft proposals

Hi Esko,

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<http://proxy.example.com/.well-known/core-translate/server.coap.example.com/4567/foo%2Fbar/a=3&b=5>
should be forbidden.

Best regards,
Bert

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

Dear all,

regards,

Esko

---

URI template: tbd

Example:

URI Template:

Examples:

URI Template:

URI template: tbd

Example:

URI template:

where:

Example:

---

URI mapping requirements

   #0 #1 #2 #3 #4
R1  +  +  +  +  +
R2  -  +  +  +  +