Are there any actual Web sites that can act as handlers for the coap and coaps schemes?

(In reply to comment #1)
> Are there any actual Web sites that can act as handlers for the coap and
> coaps schemes?

Chicken-and-egg problem maybe? Can you answer that question for all other schemes on the white list?

Hi Michael,

(In reply to comment #1)
> Are there any actual Web sites that can act as handlers for the coap and
> coaps schemes?

a bit of context to help you understand why I've raised this feature request.

In the IETF (within the CoRE WG) we are in the process of defining the interworking between CoAP and HTTP agents.  This same work will also have a direct impact on the profiles defined by ETSI M2M.

In this respect, the lack of support in browsers for URIs with the coap(s) scheme is a big hindrance, which needs specific plugins to be worked around.

A more CoAP-friendly registerProtocolHandler API would remove the need to create and maintain per-browser plugins, and substitute those with a standard, and native  mechanism.

Thanks, Thomas.

(In reply to comment #2)
> Chicken-and-egg problem maybe?

Yep, exactly.

What would a Web page that handles coap: do? What kind of information is given in coap: URLs?

(In reply to comment #5)
> What would a Web page that handles coap: do?

Mainly real-time display of the state of a sensor, and user interaction with an actuator.

Representations are usually short plain text data (e.g. a sensor's current state), or some json/exi for aggregate/more complex resources.

> What kind of information is
> given in coap: URLs?

Apart from the origin and path to the observed resource, there could be a simple query string -- e.g. when interacting with the .well-known/core discovery interface.

Could you elaborate some more? How would this work? Where is the sensor, how is the remote server getting the data from the sensor, what does a coas: URL look like, why would anyone link to one, etc?

(In reply to comment #7)
> Could you elaborate some more? How would this work? Where is the sensor, how
> is the remote server getting the data from the sensor, what does a coas: URL
> look like, why would anyone link to one, etc?

In the most basic scenario you have a sensor (say, reading the room's temperature) hosted on a device not powerful enough to be a TCP/HTTP speaker -- let's realistically assume that it implements a minimal UDP/CoAP stack over a 802.15.4 radio.

The device publish its internal status via a resource, e.g. coap://device/temp which, once dereferenced, returns some text/plain with the current measure in Celsius degrees.  However, the browser can't directly access it because it doesn't know CoAP.

So, the HTTP-CoAP gateway (say, http-coap.example.org:8080) may register itself as the handler for requests having a  Request-URI with coap scheme, therefore enabling access to the sensor by the browser: a "GET coap://device/temp HTTP/1.1" would be sent to http-coap.example.org:8080, that handles the syntactic translations needed to bridge the two.

A typical application may be a home appliance monitor which uses the HTTP-CoAP gateway to access those resources that would be otherwise invisible to the unconstrained hosts.

Surely all COAP hosts will thus be behind firewalls and inaccessible to world-wide accessible sites that would call registerProtocolHandler(), no?

(In reply to comment #9)
> Surely all COAP hosts will thus be behind firewalls and inaccessible to
> world-wide accessible sites that would call registerProtocolHandler(), no?

I'm not sure to catch on to what you mean... but, yes: CoAP nodes (at least the most constrained) won't be generally available in the wild.

We expect to find them behind these HTTP-CoAP proxies that act as application layer gateways, bridging the www infrastructure on one side, and a constrained intranet on the other).

A web application could registerProtocolHandler() to configure the needed HTTP-CoAP gateway to use, and then link to coap://device/resource as if the browser could speak natively with that constrained node.

I don't understand how that would work.


   User's machine
     +------------------,
                Firewall/Router ----- Internet ----- Web Server
     +------------------'
   COAP device

How is the Web Server going to implement the handler?

(In reply to comment #11)
> I don't understand how that would work.
> [...]
> How is the Web Server going to implement the handler?

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 which is under its control.

If user agrees, native CoAP resources can then 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 a pretty scalable approach to me.)

The security model is the one usually found in browsers: the user is requested to opt in for a specific capability.

Also, since the browser speaks plain HTTP with the HTTP-CoAP proxy, there would be no need to integrate the CoAP bits in to Mozilla, Chrome, Safari, IE, Opera, or whatever.

(In reply to comment #12)
> 
> On download/startup it asks the user to registerProtocolHandler() for a
> given HTTP-CoAP proxy which is under its control.

If the proxy is under the site's control (on the public Internet), how can it access the "native CoAP resources" on the user's network (behind the user's firewall)?

(In reply to comment #13)
> If the proxy is under the site's control (on the public Internet), how can
> it access the "native CoAP resources" on the user's network (behind the
> user's firewall)?

Ah, now I understand what your concern is !

Scenario 1: "home"

CoAP sensors and actuators are typically domestic appliances, light bulbs, meters, etc.
Both the browser and the proxy are behind the home gateway, thus no ACL/NAT/firewall prevents browser from interacting with the the HTTP-CoAP proxy.


Scenario 2: "city"

CoAP sensors and actuators are smog/temperature/etc. detectors scattered in the city territory.

HTTP-CoAP proxy is in the public internet and can be freely contacted by any browser.

This is a good first step to get CoAP support into the browser. Ian, we had a discussion via e-mail a few months ago and one main problem that came up was the security model. With this approach, security is handled by the cross-proxy and the browser does not introduce new vulnerabilities.
Thus, I would +1 this proposal.

I do have a question, however, what this protocol handler will cover, as I can only find information about links. Will it also work in other elements such as iframes or forms? What about the XMLHttpRequest object?
These things would be needed to actually mash things up.

(In reply to comment #14)
> Scenario 1: "home"
> 
> CoAP sensors and actuators are typically domestic appliances, light bulbs,
> meters, etc.
> Both the browser and the proxy are behind the home gateway, thus no
> ACL/NAT/firewall prevents browser from interacting with the the HTTP-CoAP
> proxy.

So how is the user going to get this proxy? How is the user going to get the proxy set up as a handler for the coap: protocol? How will sites be restricted from communicating with this coap: protocol handler without the user's permission?


> Scenario 2: "city"
> 
> CoAP sensors and actuators are smog/temperature/etc. detectors scattered in
> the city territory.
> 
> HTTP-CoAP proxy is in the public internet and can be freely contacted by any
> browser.

What Web pages are going to be using coap: URLs instead of just communicating with the proxy directly?

Consider a case of a user with a laptop in charge of two cities, each with its own set of devices and a proxy. When the user goes to the page for one city, he has to select a different proxy than when he goes to the page for the other city? That seems highly unusable. Wouldn't it be better for those pages just to hardcode their link to the proxies?


(In reply to comment #15)
> This is a good first step to get CoAP support into the browser. Ian, we had
> a discussion via e-mail a few months ago and one main problem that came up
> was the security model. With this approach, security is handled by the
> cross-proxy and the browser does not introduce new vulnerabilities.

That isn't clear to me at _all_. If anything, it seems to make it _easier_ for hostile sites to do damage, since they can just attempt to communicate with coap: resources and the user will have taken care of providing a proxy!


> I do have a question, however, what this protocol handler will cover, as I
> can only find information about links. Will it also work in other elements
> such as iframes or forms? What about the XMLHttpRequest object?
> These things would be needed to actually mash things up.

In principle these could work for any situation, provided CORS headers are sent.

(In reply to comment #16)
> So how is the user going to get this proxy? How is the user going to get the
> proxy set up as a handler for the coap: protocol?

As already said, the model here is: a web application proposes its HTTP-CoAP proxy to the user.  If the user opts-in, the "coap" URIs that the web application needs to link, will be requested via the configured HTTP-CoAP proxy. 

> How will sites be
> restricted from communicating with this coap: protocol handler without the
> user's permission?

The access control function is not on the user.  It is on the HTTP-CoAP proxy.

The model you are describing doesn't seem compatible with registerProtocolHandler.