Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [m2m-iwg] COAP

Rick/David/all,

Depending on the layer we're talking about, see e.g. this publication on page 3:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.68.397&rep=rep1&type=pdf
different protocols or taking care of payload may apply.
  • Application Layer
  • Service Layer
  • Sensor Layer
  • Physical Layer
Between the Physical and Sensor Layer things are often device specific or proprietary, while from there upwards (in M2M one Sensor Layer may of course also talk directly to another Sensor Layer, without going through Service or Application Layer of the Sensor Web) regardless of the data format, if it's JSON, CSV or XML and specialized Markup Languages like SensorML or UnitsML (more common from Service Layer upwards, or in times of REST/JSON getting less frequent everyhere) there a common understanding of measurement units both between autonomous devices and services is crucial if you want to avoid "Gimli" or worse.

Regards,
Werner

On Tue, Apr 16, 2013 at 7:03 PM, <m2m-iwg-request@xxxxxxxxxxx> wrote:
Send m2m-iwg mailing list submissions to
        m2m-iwg@xxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
        http://dev.eclipse.org/mailman/listinfo/m2m-iwg
or, via email, send a message with subject or body 'help' to
        m2m-iwg-request@xxxxxxxxxxx

You can reach the person managing the list at
        m2m-iwg-owner@xxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of m2m-iwg digest..."


Today's Topics:

   1. Re: COAP (Rick Bullotta)
   2. Re: COAP (Navarro, David)


----------------------------------------------------------------------

Message: 1
Date: Tue, 16 Apr 2013 16:50:32 +0000
From: Rick Bullotta <rick.bullotta@xxxxxxxxxxxxx>
To: m2m Industry Working Group <m2m-iwg@xxxxxxxxxxx>
Subject: Re: [m2m-iwg] COAP
Message-ID:
        <C7D31C647F791B439B6E65E10053D5370D9D8193@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>

Content-Type: text/plain; charset="us-ascii"

Completely agree, David!

I'm envisioning something along the lines of websockets, with COAP-like payloads.  That same pipe could be used to deliver change-based notifications (events, data updates/reads/writes), request/response (service invocations).  Event notifications and data updates are really just a special case of a service invocation.  With some creativity, advanced functionality such as file transfers, chunked streams, and so on can easily use the same mechanism.  The content of the messages could be format agnostic (JSON or binary) though some work needs to be done on the content formats to enable interop.  Not coincidentally, this is pretty much what we're doing with our M2M agents at ThingWorx today.  We leverage HTTP/XMPP/WebSockets/TCP Sockets as the transport, effectively overlaying a REST-like API that can be invoked across a variety of transports and wire formats.




Back to the top