Efficient XML Encoding and 6LowApp
draft-shelby-6lowapp-encoding-00

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on April 19, 2010.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

For the resource constrained devices and networks of 6LowApp it is essential that the payload of messages are compact. The use of XML to represent data in web applications has become almost universal. The interoperability of 6LowApp with these applications will require that XML can also be carried over the embedded web. This document introduces and compares techniques for encoding or compressing XML for use with 6LowApp including EXI, BXML and Fast Infoset. The performance and requirements for using these encodings are analyzed in the scope of 6LowApp. It is shown that these standard encodings can represent XML in a compact form, with reasonable overhead, and require only Internet media type and content transfer encoding indication from the application protocol.

Table of Contents

1.  Introduction
2.  Efficient XML Encoding
    2.1.  Efficient XML Interchange (EXI)
    2.2.  Fast Infoset (FI)
    2.3.  Binary XML (BXML)
3.  Results
4.  6LowApp Requirements
5.  Conclusions
6.  Security Considerations
7.  IANA Considerations
8.  Acknowledgments
9.  References
    9.1.  Normative References
    9.2.  Informative References
§  Authors' Addresses

1.  Introduction

For the resource constrained devices and networks of 6LowApp [I‑D.bormann‑6lowpan‑6lowapp‑problem] (Bormann, C., Sturek, D., and Z. Shelby, “6LowApp: Problem Statement for 6LoWPAN and LLN Application Protocols,” July 2009.) it is essential that the message payloads are compact. The use of XML to represent data in web applications has become almost universal. The interoperability of 6LowApp with these applications will require that XML can also be carried over the embedded web. Examples include Smart Energy using IEC XML markup, building automation with open Building Information Exchange (oBIX), and the OGC Sensor Markup Language (SensorML) [OGC‑SensorML] (Open Geospatial Consortium, “OpenGIS Sensor Model Language (SensorML) Implementation Specification, Version 1.0.0,” June 2007.) to name a few. In the vast majority of enterprise and machine-to-machine (M2M) systems it is expected that data is represented in some form of XML. The size of typical XML payloads for even simple sensor data ranges from 100s to 1000s of bytes. This overhead is unreasonable over e.g. 6LoWPAN networks [RFC4944] (Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, “Transmission of IPv6 Packets over IEEE 802.15.4 Networks,” September 2007.). Furthermore, full XML parsing requires additional resources from embedded devices.

Fortunately, the text form of XML we are all familiar with is only one way to represent an XML document or fragment. XML can also be respresented using much more compact and easy to parse encodings. The underlying XML Information Set is the same. One good example is the new Efficient XML Interchange (EXI) standard from the W3C [W3C.WD‑exi‑20080919] (Schneider, J. and T. Kamiya, “Efficient XML Interchange (EXI) Format 1.0,” September 2008.). This alternative encoding for XML represents namespaces, tags, attributes and data using optimal bit codes, supporting very simple encoding/decoding based on well-known schema knowledge. Other examples include the Binary XML (BXML) specification from the OGC [OGC‑BXML] (Open Geospatial Consortium, “Binary Extensible Markup Language (BXML) Encoding Specification, Version 0.0.8,” Jan 2006.), the Fast Infoset (FI) standard from the ITU [FI] (International Telecommunications Union, “Information technology - Generic applications of ASN.1: Fast infoset,” 2005.) and the WAP Binary XML (WBXML) technique from the mobile industry.

This document introduces and compares techniques for encoding or compressing XML for use with 6LowApp including EXI, BXML and Fast Infoset. The performance and requirements for using these encodings are analyzed in the scope of 6LowApp. It is shown that these standard encodings can represent XML in a compact form, with reasonable overhead, and require only Internet media type and possible transfer encoding indication from the application protocol.

2.  Efficient XML Encoding

In this section we introduce a few of the promising efficient XML encoding schemes available as standards or draft standards. We are aware of other standard encodings such as WBXML and compression schemes like gzip and deflate. These techniques have similar properties and requirements to the ones presented here. In general techniques can be categorized into two categories, encoding techniques and compression techniques. The following three techniques can be categorized as encodings, which are typically more suitable for very limited devices.

2.1.  Efficient XML Interchange (EXI)

EXI is a very compact representation for the XML Information Set that is intended to simultaneously optimize performance and the utilization of computational resources [W3C.WD‑exi‑20080919] (Schneider, J. and T. Kamiya, “Efficient XML Interchange (EXI) Format 1.0,” September 2008.). The EXI format uses a hybrid approach drawn from the information and formal language theories, plus practical techniques verified by measurements, for entropy encoding XML information. Using a relatively simple algorithm, which is amenable to fast and compact implementation, and a small set of data types, it reliably produces efficient encodings of XML event streams. The event production system and format definition of EXI are introduced in [W3C.WD‑exi‑primer‑20071219] (Pericas-Geertsen, S. and D. Peintner, “Efficient XML Interchange (EXI) Primer,” December 2007.).

The EXI specification allows for a simplified mode of operation called schema-informed mode. Here a schema is used to form a grammar and state-machine limited to that schema, enabling an extremely efficient encoding. The result of the simple state machine is that even the most minimal embedded devices can work directly with the encoding without the need to work with a full XML parser.

2.2.  Fast Infoset (FI)

Fast Infoset is an ITU-T (X.891) [FI] (International Telecommunications Union, “Information technology - Generic applications of ASN.1: Fast infoset,” 2005.) and ISO (IEC 24824-1) defined standard that specifies a binary encoding for the XML Information Set. Unlike other XML representations, the Fast Infoset standard has the dual benefits of both compression and performance, making it the ideal choice for moving large XML data between disparate low bandwidth systems or for high performance systems such as those utilizing Web services.

2.3.  Binary XML (BXML)

BXML is a straightforward encoding for XML that is designed for efficient processing in general with an emphasis on dense numeric data, which is one of the weakest areas for textual XML. This encoding specification designed by Open Geospatial Consortium (OGC) is specified for GML compression [OGC‑BXML] (Open Geospatial Consortium, “Binary Extensible Markup Language (BXML) Encoding Specification, Version 0.0.8,” Jan 2006.). Thus it is an interesting technique even though it is still in best practices phase and currently meant only for GML. It is open and about as straightforward to implement a parser/generator for as for textual XML.

3.  Results

In this section the results of encoding XML content with EXI, BXML and Fast Infoset techniques are presented. The goal is to give an example of how the encoding of some typical XML content for simple embedded devices works. In this comparison RDF/XML sensor data, a Smart Energy example and a simplified SensorML example have been used which represent a good range of content for 6LowApp applications.

The results were carried out using EXIficcient v0.3 (, “EXIficient Project Home Page,” .) [EXIficient] and FastInfoset v1.1.9 (, “Fast Infoset GlassFish Project Home Page,” .) [FI@GlassFish] from GlassFish along with a custom BXML implementation from CENTRIA [Locawe‑BXML] (, “Developing geosensor network support for Locawe platform - application of standards in low-rate communication context,” .). All test content had a corresponding XML Schema, and the original content size was normalized. EXI encoding was performed in schema-informed mode using bit-alignment. Fast Infoset and BXML were both performed with schema information. Complexity is considered for using the technique on constrained microcontrollers and was estimated based on implementations of EXI and BXML on CC2430 and MSP430 platforms, and an estimation of FI complexity to be similar to BXML.

The following figures show the XML content used for the comparison:

<?xml version='1.0' encoding='UTF-8'?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:res="urn:sensei:rai">
    <res:Temperature rdf:about="2"
     res:hasDecimalValue="5.5"/>
</rdf:RDF>

<?xml version="1.0" encoding="UTF-8"?>
<simpleMetering>
   <CurrentSummationDelivered>0</CurrentSummationDelivered>
   <Status>0</Status>
   <UnitOfMeasure>0</UnitOfMeasure>
   <SummationFormatting>85</SummationFormatting>
   <MeteringDeviceType>0</MeteringDeviceType>
   <InstantaneousDemand>1234</InstantaneousDemand>
   <CurrentDayConsumptionReceived>23
   </CurrentDayConsumptionReceived>
</simpleMetering>

<?xml version="1.0" encoding="utf-8"?>
<GPS_Temperature_System>
   <TimeOfSample>2009-04-08T09:30:10+02:00</TimeOfSample>
   <Longitude>6404.48220N</Longitude>
   <Latitude>02430.91188E</Latitude>
   <Temperature>20.50</Temperature>
</GPS_Temperature_System>

Table 1 presentes the comparison results. The results show that EXI encoding represents XML content much more efficiently than BXML and FI encodings. The main reason for this can be found from the simplicity of EXI encoding, and the efficiency of its schema-informed grammar that resulsts in a limited state machine. The result is close to that achievable when representing the same raw data content in ASN.1. BXML encoding in turn will encode not only the values but also a part of the XML structure. However, BXML also offers also possibility to store the most common structures in a separate global string table which can be stored and used locally in the node side like the schema file of EXI encoding. The structure of BXML is closer to the stuctures of OGC's markups. Although not very dense, an advantage of BXML is its readability. Fast Infoset works like a compression algorithm for XML, although with higher performance than gzip. The results of Fast Infoset and BXML are on averge equivalent. Further test results for full web content for a wide range of encoding and compression techniques can be found from [W3C.WD‑exi‑evaluation‑20090407] (Bournez, C., “Efficient XML Interchange Evaluation,” April 2009.).

4.  6LowApp Requirements

The use of compact XML encoding requires very little from the application protocol of 6LowApp. In practice just a payload, and a way to indicate in the header what the Internet media type and the content transfer encoding of that payload are. This allows these standard techniques to be used without modification. One technique for encoding the type and transfer encoding in a binary header is included in [I‑D.frank‑6lowapp‑chopan] (Frank, B., “Chopan - Compressed HTTP Over PANs,” September 2009.).

When performing application commissioning in 6LowApp some well-known encoding must be used or included in the commissioning technique. If the same application protocol is used also for commissioning, such as done with DPWS, then the payload should use a well-known markup (XML) and encoding. Based on the findings here, EXI would be a recommended choice for XML.

The Internet media types (MIME) [RFC2046] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,” November 1996.) should be indicated by the application protocol header. This SHOULD be encoded in a compact form. Examples of typical content-types that need to be supported for efficient XML encoding:

• text/xml [RFC3023] (Murata, M., St. Laurent, S., and D. Kohn, “XML Media Types,” January 2001.)
• application/xml [RFC3023] (Murata, M., St. Laurent, S., and D. Kohn, “XML Media Types,” January 2001.)
• application/rdf+xml [RFC3870] (Swartz, A., “application/rdf+xml Media Type Registration,” September 2004.)
• application/soap+xml [RFC3902] (Baker, M. and M. Nottingham, “The "application/soap+xml" media type,” September 2004.)
• application/atom+xml [RFC5023] (Gregorio, J. and B. de hOra, “The Atom Publishing Protocol,” October 2007.)
• application/rss+xml
• text/x-bxml, application/x-bxml and *+x-bxml [OGC‑BXML] (Open Geospatial Consortium, “Binary Extensible Markup Language (BXML) Encoding Specification, Version 0.0.8,” Jan 2006.)
• application/fastinfoset, application/soap+fastinfoset and *+fastinfoset [FI] (International Telecommunications Union, “Information technology - Generic applications of ASN.1: Fast infoset,” 2005.)
• Unknown binary content SHOULD be treated as application/octet-stream [RFC2045] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” November 1996.)[RFC2046] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,” November 1996.)
• For simplicity it is not recommended that multipart/mixed is supported.

The content transfer encoding [RFC2045] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” November 1996.) should be optionally indicated by the application protocol header, and is needed at least by EXI. This SHOULD be encoded in a compact form. At least the following need to be supported:

• x-exi [W3C.WD‑exi‑best‑practices‑20071219] (Vogelheim, D. and M. Cokus, “Efficient XML Interchange (EXI) Best Practices,” December 2007.)
• binary

5.  Conclusions

Efficient XML encoding will be a key technology for enabling the embedded web, which 6LowApp will benefit greatly by supporting. The results of this analysis show that efficient XML encoding is possible within the payload and complexity constraints aimed at by 6LowApp. Although it was found that EXI is highly suitable for these types of applications, the conclusion is that any of these and other encodings may be appropriate depending on the application.

The recommendation is that 6LowApp should support a reasonable range of Internet media types and transfer encodings related to XML and common XML encodings.

6.  Security Considerations

No security issues have been identified in this draft.

7.  IANA Considerations

This draft requires no IANA consideration.

8.  Acknowledgments

9.  References

9.1. Normative References

9.2. Informative References

Authors' Addresses