Subject: [core] #259: Standardize a workaround for HTTP library limitations in talking to forward HTTP-COAP cross-proxies?

From: "core issue tracker" <[email-masked]>
Date: Tue, 06 Nov 2012 12:12:49 -0000

#259: Standardize a workaround for HTTP library limitations in talking to forward
HTTP-COAP cross-proxies?

 Cullen Jennings notes (msg03072bu):

 Section 8 - I tried passing a COAP URL in a HTTP request line  of various
 libraries, firewalls, and other tools. In theory it might work, but my
 observation is that in practice, it does not. I'm not sure how to fix
 this. One possible solution  is making a way to translate well know http
 URL into a coap URL. So for example, the translator proxy that received an
 HTTP request like

 http://www.proxy.com/.wellknonw/core-translate/1.2.3.4_4567/foo/bar?a=3

 would translate that to

 coap://1.2.3.4:4567/foo/bar?a=3

 If we did something like this, your standard web libraries running on
 things like google app engine could make REST calls to the proxy that
 resulted in a request to the CoAP device. Perhaps you think this approach
 is the reverse proxy approach but one way or another, I can see how to get
 the current solution working very well in practice.

 Solution: Defining such a workaround mapping (carrying a CoAP URI "in" a
 URI) is straightforward (with a little bike-shedding needed).  Do we do
 this in core-coap or separately?

-- 
-----------------------------+------------------------------------
 Reporter:  cabo@…           |      Owner:  draft-ietf-core-coap@…
     Type:  other technical  |     Status:  new
 Priority:  minor            |  Milestone:  post-WGLC-1
Component:  coap             |    Version:  coap-09
 Severity:  In WG Last Call  |   Keywords:
-----------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/259>
core <http://tools.ietf.org/core/>

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 6 Nov 2012 13:25:21 +0000

> #259: Standardize a workaround for HTTP library limitations in talking to forward

Re to this, I've added a feature request to HTML5:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=19582

to let browsers configure their HTTP-CoAP forward proxy via the
registerProtocolHandler API.

Maybe worth doing some lobbying in this direction ?

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Tue, 6 Nov 2012 16:31:57 +0000

> Maybe worth doing some lobbying in this direction ?

I already had a longer e-mail discussion with Ian Hickson after IETF 83 on this.
The consensus was that we will have to convince the browser vendors and bring up a solid security model, as "Application X wants to access device Y"-listing might not scale.

When I talked to Patrick McManus from Mozilla Firefox at last IETF, he was quite positive about integrating CoAP directly into the browser. They are already integrating DTLS 1.2 for RTCWeb (not scriptable so far, though)...
Unfortunately, I do not have the time to work on a patch that brings a C++ CoAP implementation to Firefox. Patrick said that would be a good first step to get CoAP integration started...
I am planning, though, to extend my Copper Firefox extension, so that people can use a CoapRequest object similar to the XMLHttpRequest object in Web applications, or even provide a unified REST object API (XHR is still very soapy..). This might also be a good demo to convince people.

Help and input on this would be very welcome!

Ciao
Matthias

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 6 Nov 2012 16:59:31 +0000

Hi Matthias,

> I already had a longer e-mail discussion with Ian Hickson after IETF 83 on this.

my scenario is:

a web application needs mashing up both CoAP and HTTP resources in one
single page.

On download/startup it asks the user to registerProtocolHandler() for
a given HTTP-CoAP proxy under its control.

If user agrees, native CoAP resources can be interacted via HTTP back
and forth the translating gateway.

Another web application could do the same but with a different
HTTP-CoAP proxy in another tab at the same time.

It seems pretty scalable to me.

And the security model is the usual one in the browser world, asking
the user to opt in for a specific capability.

Also, since the browser speaks plain HTTP with the HTTP-CoAP proxy,
there's no need to integrate the CoAP bits in Mozilla or whatever.

Am I missing something ?

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Tue, 6 Nov 2012 20:57:21 +0000

> a web application needs mashing up both CoAP and HTTP resources in one

Yes, that is the general scenario I also imagine. The details depend on ownership and the relationships between application, devices, and user.
 
> On download/startup it asks the user to registerProtocolHandler() for a given
> HTTP-CoAP proxy under its control.
> If user agrees, native CoAP resources can be interacted via HTTP back and
> forth the translating gateway.

Ah, so the application Web server and the cross-proxy, i.e., also the devices behind it, belong to the same authority? ("its control" -> the application)
But if so, why does the server not contact the devices directly, so that there is only communication between browser and application server?

> Another web application could do the same but with a different HTTP-CoAP
> proxy in another tab at the same time.

Yes it is, because the actual access control is managed at a single cross-proxy that connects to all devices.

> And the security model is the usual one in the browser world, asking the user
> to opt in for a specific capability.

Yes, as a start I also believe in an access control list similar to microphone or webcam.
 
> Also, since the browser speaks plain HTTP with the HTTP-CoAP proxy, there's
> no need to integrate the CoAP bits in Mozilla or whatever.
> Am I missing something ?

Back then, I was thinking of different use cases (as well):
Imagine you buy a bunch of sensors and actuators for home automation and they all communicate in your local network but are shielded from the Internet by your router.
The vendor might provide a Web application to configure or update the HA system. Therefore the application needs access to the devices. This is done through the browser: "Site X wants to access device Y / all local devices. Allow?" Here we need CoAP support in the browser---or a local cross-proxy. It is still a bit fuzzy to me how RawPublicKeys or even certificates will be managed here. I would image that the owner installs something on her devices that allows to verify requests. The vendor could also have something pre-installed.

For mashups where multiple authorities are involved, registering a single cross-proxy will not help. The application could solve access to CoAP devices by directly using HTTP cross-proxy URIs in cross-domain AJAX requests. But I like the idea of actually having real observe notifications for real-time Web applications. Thus, again CoAP support in the browser. Still, there will be intercepting proxies involved, as even public devices need to be shielded by caches. Private devices will also have some sort of access control at the intercepting proxies, I guess.

Maybe we should collect these detailed scenarios and then think about the best APIs to cover them all.

Ciao
Matthias

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 6 Nov 2012 22:26:58 +0000

> Maybe we should collect these detailed scenarios and then think about the best APIs to cover them all.

Agreed, but (pragmatically speaking) we'd better not leave out the
chance to get an HTML5 API -- even if it gives a suboptimal solution.

At least we can count on all the major browsers for providing us with
a pervasive mechanism to create simple mashups.

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Tue, 6 Nov 2012 22:50:43 +0000

> Agreed, but (pragmatically speaking) we'd better not leave out the chance to
> get an HTML5 API -- even if it gives a suboptimal solution.
> 
> At least we can count on all the major browsers for providing us with a
> pervasive mechanism to create simple mashups.

Yes, it is a good start! If also posting to the Bugzilla discussion or something else could help, tell me (or us, I guess).
I just wanted to point out, that it is only a first step, as only a limited type of mashup is possible.

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 6 Nov 2012 23:06:07 +0000

On Tue, Nov 6, 2012 at 10:50 PM, Kovatsch  Matthias
<[email-masked]> wrote:
> Yes, it is a good start! If also posting to the Bugzilla discussion
> or something else could help, tell me (or us, I guess).

Please, do :-)

> limited type of mashup is possible.

Correct.

BTW I'd be more than happy to join efforts to model the "ideal"
HTTP-CoAP API (something that, among other things, has bubbled up
frequently in my conversations with Sal...), and which would also
provide a great benchmark for the HTTP-CoAP proxy.

---

From: Thomas Fossati <[email-masked]>
Date: Thu, 15 Nov 2012 09:44:26 +0000

On Tue, Nov 6, 2012 at 1:25 PM, Thomas Fossati <[email-masked]> wrote:
> Re to this, I've added a feature request to HTML5

Follow-up to notify the list about the unsuccessful lobbying attempt: