Re: Proposal for Alternate oBIX Encodings

[Brian Frank <brian.tridium@gmail.com>]

Now that summer is winding down, I'd like to get some thoughts on doing a binary encoding for oBIX and finalizing the 1.1 draft.

In the most recent IETF meeting, it was decided to form a new working group for an application level protocol to run over 6LoWPAN. �I have submitted a Internet Draft for a compressed UDP version of HTTP:

��http://tools.ietf.org/html/draft-frank-6lowpan-chopan-00

Who knows where an IETF standard might wind up, but I am hoping that it will be HTTP based and address resources with URIs.

Of course, we still need a modeling and payload encoding for data. �I think a binary encoding of oBIX would be a perfect fit for this brave new world!

I would like to propose adding a chapter to the oBIX 1.1 specification for binary encoding. �Assuming we are�satisfied�with that, I would like finalize 1.1 as a specification with the new content on timezone, time, date, and binary encoding. �Although Aaron has written an iCAL scheduling draft, I don't think we have any implementations - so I would suggest taking that off the table for 1.1 and instead focus on releasing a 1.1 this year.

What do you guys think?

Brian

On Tue, Mar 31, 2009 at 11:25 AM, Frank, Brian <bfrank@tridium.com> wrote:

Today oBIX defines an abstract object model with a single encoding based on XML. �But the original vision behind oBIX was that multiple encodings could be defined all sharing the same interoperable object model. �I would like to propose adding two alternate encodings of the oBIX object model to the 1.1 draft specification: JSON and Binary.

�

One of the things we are starting to see is many people are using oBIX as an AJAX data feed to their browser.� In this use case, it is preferable to deliver the oBIX information directly in a JSON format rather than requiring JavaScript to parse the XML into a usable format.

�

Why a binary oBIX encoding?� This requirement takes a little more background discussion. �One of the technologies I have been deeply involved in is 6LoWPAN which is an RFC specifying how to run IPv6 over 802.15.4 wireless networks.� I firmly believe that 6LoWPAN has the potential to unleash the Pervasive Internet by adding billions of new nodes to the Internet.� But putting these devices onto the Internet is just the first step.� The next step is to put them onto the Web so that they can be wired into humanities existing information infrastructure.� Due to their resource and power constraints, 6LoWPAN devices cannot fully run HTTP or mange �XML payloads.� To the solve the HTTP problem, I am working on an RFC to run a compressed version of HTTP over 6LoWPAN.� On the payload side,� oBIX fits perfectly for defining a RESTful information model.� But we need a compact encoding which can work with the small packet sizes required for 802.15.4 networks. �I have some good ideas on how to achieve this without loosing any of oBIX�s modeling capability.

�

Clients would perform negotiation with servers for their preferred encoding using the Accept header (standard HTTP content negotiation).

�

Comments?

�

I would suggest we try to setup a teleconference next week (Mon or Tue preferably) to discuss this strategy.

�

Brian

�