One document matched: draft-doi-exi-messaging-requirements-01.xml

<?xml version="1.0" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc ipr="trust200902" category="info" docName="draft-doi-exi-messaging-requirements-01">
<?rfc toc="yes"?>         <!-- generate a table of contents -->
<?rfc symrefs="yes"?>     <!-- use anchors instead of numbers for references -->
<?rfc sortrefs="yes" ?>   <!-- alphabetize the references -->
<?rfc compact="yes" ?>    <!-- conserve vertical whitespace -->
<?rfc subcompact="no" ?>  <!-- but keep a blank line between list items -->
 <front>
        <title abbrev="EXI Messaging Requirements">EXI Messaging Requirements</title>

        <author initials="Y." surname="Doi"
                fullname="Yusuke Doi">
            <organization>TOSHIBA Corporation</organization>

            <address>
                <postal>
                    <street>Komukai Toshiba Cho 1</street>
                    <street>Saiwai-Ku</street>
                    <city>Kawasaki</city> <region>Kanagawa</region>
                    <code>2128582</code>
                    <country>JAPAN</country>
                </postal>

                <phone>+81-45-342-7230</phone>
                <email>yusuke.doi@toshiba.co.jp</email>
                <uri></uri>
            </address>
        </author>

        <date month="February" year="2013"/>

        <area>Application</area>
        <workgroup>Application</workgroup>
        <keyword>EXI</keyword>
        <abstract>
            <t>
EXI (Efficient XML Interchange) is a specification on
efficient encoding of XML.  EXI is useful if an application requires
XML based message exchange but no sufficient resource is available.
However, schema-informed mode of EXI
needs some out-of-band coordination between communicating nodes.
This
document discusses requirement on use of schema-informed EXI
as a message exchange format on the Internet systems.
</t>
        </abstract>
</front>

<middle>
<!-- This document was prepared using Pandoc2rfc -->
<!-- https://github.com/miekg/pandoc2rfc -->

  
<section title="Introduction" anchor="introduction">
  
  <t>
    EXI<xref target="W3C.REC-exi-20110310"/> (Efficient XML
    Interchange) is a specification on efficient encoding of XML. EXI is
    useful if an application requires XML based message exchange but no
    sufficient resource is available, such as environments discussed in
    <xref target="I-D.shelby-core-coap-req"/>. However, EXI may
    need some out-of-band coordination between communicating nodes.
  </t>
  <t>
    The target of this document is not to discuss EXI spec itself. This
    document discusses how to use it as a message exchange format (a
    presentation layer) on the Internet systems to support development
    and deployment of EXI systems in the Internet including constrained
    nodes.
  </t>
</section>
<section title="Schema Update and Data Type Derivation" anchor="schema-update-and-data-type-derivation">
  
  <t>
    In communication use cases of XML/EXI, XML schema (or equivalents)
    is often used to define a standard message format. A schema defines
    a message format, and such message format is expected to be able to
    extend. There are at least two ways of extension.
  </t>
  <t>
    First way is to update the schema. Brand-new devices with a new
    functionality may have updated schema to support extended message.
    In this scenario, a system consists of multiple versions of schema.
    As schema-informed EXI requires communicating nodes to use identical
    schema, this scenario requires schema negotiation.
  </t>
  <t>
    Second way is to use derived data types from the schema. Built-in
    grammar or non-strict schema-informed grammar allow derived XML
    instances from the definition in the XML schema. To accommodate
    resource-constrained nodes, an application spec may specify a
    parameter set with EXI
    Profile<xref target="W3C.WD-exi-profile-20120731"/>.
  </t>
  <t>
    Schema update and data derivation are not exclusive. Application
    designers may choose one or both approaches. This is tradeoff
    between extensiblity and interoperability.
  </t>
</section>
<section title="Schema Negotiation for Strict Schema-Informed EXI Messaging" anchor="schema-negotiation-for-strict-schema-informed-exi-messaging">
  
  <t>
    In short, EXI has two grammar modes: Schema-informed and Built-in.
    Built-in grammar uses dynamic state machines that learn document
    structure on-the fly. On the other hand, Schema-informed grammar
    makes a set of state machines from a schema and the state machines
    are used to encode/decode document structure. Strict mode of
    schema-informed grammar uses static state machines for XML elements
    and attributes defined in the XML schema. Wildcard elements are
    handled in the built-in grammar (dynamic state machines). Non-strict
    mode allows XML data to be derived from that defined in the XML
    schema.
  </t>
  <t>
    Because schema-informed grammars can make smallest messages in most
    cases, some applications may want to make use of schema-informed
    grammar as its message format.
  </t>
  <t>
    To decode an EXI message, the sender and receiver must have exactly
    same schema. However, the way to negotiate and match schema between
    communicating nodes is not yet well defined.
  </t>
  <t>
    To use EXI as application message encodings, clients and servers
    should have a way to coordinate the schema used in the
    communication. This is similar to content negotiation defined in
    HTTP<xref target="RFC2616"/>. This section describes schema
    negotiation cases based on common communication pattern.
  </t>
  <section title="Content-Type and Schema Identification" anchor="content-type-and-schema-identification">
    
    <t>
      To negotiate schema, an application must have a way to identify a
      schema.
    </t>
    <t>
      A content-type may use schema-informed EXI as its encoding. Each
      content-type should define how to identify a schema used in a
      communication. The identifier (schemaId) may have internal
      structure to indicate backward compatibility.
    </t>
    <t>
      A good practice is to have schema version number (Major.Minor) as
      a schema ID. Between minor modifications, schemas should have
      backward compatibility (a node with schema 4.3 shall have schema
      4.0, 4.1 and 4.2). Between major modifications, schema should not
      have it (a node with schema 4.3 may not have schema 1.x, 2.x and
      3.x). Note that schemaId is local identifier space that belongs to
      a content-type. There is no need to have global schema ID
      registry.
    </t>
    
    <t>
      On schema negotiation, a receiver of a message declares a set of
      acceptable schema IDs and a sender selects a schema ID among the
      given set. The selected schema ID should be in schemaId field of
      EXI option header.
    </t>
  </section>
  <section title="Client-Driven Schema Negotiation" anchor="client-driven-schema-negotiation">
    
    <t>
      Client-driven schema negotiation is the way that a client decides
      actual schema version used in a communication. This happens in
      POST or PUT style communications. In
      <xref target="RFC2616"/>, try-and-redirect style of
      client-driven content negotiation is described. Similar way should
      be possible in schema negotiation. However, it may be simpler to
      have a way to declare a server's acceptable schema set.
    </t>
    <t>
      As an alternative, a server (or a resource on a server) may
      declare its available schema set via some service discovery
      mechanisms. Candidates are such as
      DNS-SD<xref target="I-D.cheshire-dnsext-dns-sd"/> TXT
      resource records or media type in link
      format<xref target="I-D.nottingham-http-link-header"/> that
      represents a resource. If an application can assume a client does
      service discovery before using the service, it may assume the
      client knows server's schema set.
    </t>
  </section>
  <section title="Server-Driven Schema Negotiation" anchor="server-driven-schema-negotiation">
    
    <t>
      Server-driven schema negotiation is the way that a server decides
      actual schema version used in a communication. In HTTP, schema
      negotiation in GET requests should do server-driven negotiation.
      In <xref target="RFC2616"/>, Accept: header is defined to
      make server-driven content negotiation. Schema negotiation can be
      piggybacked on it by using some content type parameter to carry
      acceptable schema ID set.
    </t>
  </section>
  <section title="Publisher-Driven Schema Negotiation" anchor="publisher-driven-schema-negotiation">
    
    <t>
      CoAP<xref target="I-D.ietf-core-coap"/> and some other
      protocols may have publish-subscribe (observer) pattern in
      communication. In this case, a subscriber should give its
      acceptable schema ID set to a publisher as it registers its
      subscription request.
    </t>
  </section>
</section>
<section title="Security Considerations" anchor="security-considerations">
  
  <t>
    No particular security concern is raised by this document.
    Applications should be able to detect malformed input as usual.
  </t>
</section>
<section title="IANA Considerations" anchor="iana-considerations">
  
  <t>
    This document has no actions for IANA.
  </t>
</section>

</middle>

<back>
    <references title="Normative References">
<?xml version='1.0' encoding='UTF-8'?>

<reference anchor='RFC2616'>

<front>
<title abbrev='HTTP/1.1'>Hypertext Transfer Protocol -- HTTP/1.1</title>
<author initials='R.' surname='Fielding' fullname='Roy T. Fielding'>
<organization abbrev='UC Irvine'>Department of Information and Computer Science</organization>
<address>
<postal>
<street>University of California, Irvine</street>
<city>Irvine</city>
<region>CA</region>
<code>92697-3425</code></postal>
<facsimile>+1(949)824-1715</facsimile>
<email>fielding@ics.uci.edu</email></address></author>
<author initials='J.' surname='Gettys' fullname='James Gettys'>
<organization abbrev='Compaq/W3C'>World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>jg@w3.org</email></address></author>
<author initials='J.' surname='Mogul' fullname='Jeffrey C. Mogul'>
<organization abbrev='Compaq'>Compaq Computer Corporation</organization>
<address>
<postal>
<street>Western Research Laboratory</street>
<street>250 University Avenue</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94305</code></postal>
<email>mogul@wrl.dec.com</email></address></author>
<author initials='H.' surname='Frystyk' fullname='Henrik Frystyk Nielsen'>
<organization abbrev='W3C/MIT'>World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>frystyk@w3.org</email></address></author>
<author initials='L.' surname='Masinter' fullname='Larry Masinter'>
<organization abbrev='Xerox'>Xerox Corporation</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94034</code></postal>
<email>masinter@parc.xerox.com</email></address></author>
<author initials='P.' surname='Leach' fullname='Paul J. Leach'>
<organization abbrev='Microsoft'>Microsoft Corporation</organization>
<address>
<postal>
<street>1 Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code></postal>
<email>paulle@microsoft.com</email></address></author>
<author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'>
<organization abbrev='W3C/MIT'>World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>timbl@w3.org</email></address></author>
<date year='1999' month='June' />
<abstract>
<t>
   The Hypertext Transfer Protocol (HTTP) is an application-level
   protocol for distributed, collaborative, hypermedia information
   systems. It is a generic, stateless, protocol which can be used for
   many tasks beyond its use for hypertext, such as name servers and
   distributed object management systems, through extension of its
   request methods, error codes and headers . A feature of HTTP is
   the typing and negotiation of data representation, allowing systems
   to be built independently of the data being transferred.
</t>
<t>
   HTTP has been in use by the World-Wide Web global information
   initiative since 1990. This specification defines the protocol
   referred to as "HTTP/1.1", and is an update to RFC 2068 .
</t></abstract></front>

<seriesInfo name='RFC' value='2616' />
<format type='TXT' octets='422317' target='http://www.rfc-editor.org/rfc/rfc2616.txt' />
<format type='PS' octets='5529857' target='http://www.rfc-editor.org/rfc/rfc2616.ps' />
<format type='PDF' octets='550558' target='http://www.rfc-editor.org/rfc/rfc2616.pdf' />
<format type='HTML' octets='636125' target='http://xml.resource.org/public/rfc/html/rfc2616.html' />
<format type='XML' octets='493420' target='http://xml.resource.org/public/rfc/xml/rfc2616.xml' />
</reference>
<?xml version='1.0' encoding='UTF-8'?>

<reference anchor='I-D.ietf-core-coap'>
<front>
<title>Constrained Application Protocol (CoAP)</title>

<author initials='Z' surname='Shelby' fullname='Zach Shelby'>
    <organization />
</author>

<author initials='K' surname='Hartke' fullname='Klaus Hartke'>
    <organization />
</author>

<author initials='C' surname='Bormann' fullname='Carsten Bormann'>
    <organization />
</author>

<author initials='B' surname='Frank' fullname='Brian Frank'>
    <organization />
</author>

<date month='July' day='16' year='2012' />

<abstract><t>The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks.  The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as 6LoWPAN often have high packet error rates and a typical throughput of 10s of kbit/s.  The protocol is designed for machine-to-machine (M2M) applications such as smart energy and building automation.  CoAP provides a request/response interaction model between application end-points, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types.  CoAP easily interfaces with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead and simplicity for constrained environments.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-core-coap-11' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-core-coap-11.txt' />
</reference>
<?xml version='1.0' encoding='UTF-8'?>

<reference anchor='I-D.shelby-core-coap-req'>
<front>
<title>CoAP Requirements and Features</title>

<author initials='Z' surname='Shelby' fullname='Zach Shelby'>
    <organization />
</author>

<author initials='M' surname='Stuber' fullname='Michael Stuber'>
    <organization />
</author>

<author initials='D' surname='Sturek' fullname='Don Sturek'>
    <organization />
</author>

<author initials='B' surname='Frank' fullname='Brian Frank'>
    <organization />
</author>

<author initials='R' surname='Kelsey' fullname='Richard Kelsey'>
    <organization />
</author>

<date month='October' day='18' year='2010' />

<abstract><t>This document considers the requirements for the design of the Constrained Application Protocol (CoAP).  The goal of the document is to provide a basis for protocol design and related discussion.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-shelby-core-coap-req-02' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-shelby-core-coap-req-02.txt' />
</reference>
<?xml version='1.0' encoding='UTF-8'?>

<reference anchor='I-D.cheshire-dnsext-dns-sd'>
<front>
<title>DNS-Based Service Discovery</title>

<author initials='S' surname='Cheshire' fullname='Stuart Cheshire'>
    <organization />
</author>

<author initials='M' surname='Krochmal' fullname='Marc Krochmal'>
    <organization />
</author>

<date month='December' day='9' year='2011' />

<abstract><t>This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this allows clients to discover a list of named instances of that desired service, using standard DNS queries. This is referred to as DNS-based Service Discovery, or DNS-SD.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-cheshire-dnsext-dns-sd-11' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-cheshire-dnsext-dns-sd-11.txt' />
</reference>
<?xml version='1.0' encoding='UTF-8'?>

<reference anchor='I-D.nottingham-http-link-header'>
<front>
<title>Web Linking</title>

<author initials='M' surname='Nottingham' fullname='Mark Nottingham'>
    <organization />
</author>

<date month='May' day='5' year='2010' />

<abstract><t>This document specifies relation types for Web links, and defines a registry for them.  It also defines the use of such links in HTTP headers with the Link header-field.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-nottingham-http-link-header-10' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-nottingham-http-link-header-10.txt' />
</reference>
<?xml version='1.0' encoding='UTF-8'?>

<reference anchor='W3C.REC-exi-20110310'
           target='http://www.w3.org/TR/2011/REC-exi-20110310'>
<front>
<title>Efficient XML Interchange (EXI) Format 1.0</title>

<author initials='T.' surname='Kamiya' fullname='Takuki Kamiya'>
    <organization />
</author>

<author initials='J.' surname='Schneider' fullname='John Schneider'>
    <organization />
</author>

<date month='March' day='10' year='2011' />
</front>

<seriesInfo name='World Wide Web Consortium Recommendation' value='REC-exi-20110310' />
<format type='HTML' target='http://www.w3.org/TR/2011/REC-exi-20110310' />
</reference>
<?xml version='1.0' encoding='UTF-8'?>

<reference anchor='W3C.WD-exi-profile-20120731'
           target='http://www.w3.org/TR/2012/WD-exi-profile-20120731'>
<front>
<title>Efficient XML Interchange (EXI) Profile</title>

<author initials='Y.' surname='Fablet' fullname='Youenn Fablet'>
    <organization />
</author>

<author initials='D.' surname='Peintner' fullname='Daniel Peintner'>
    <organization />
</author>

<date month='July' day='31' year='2012' />
</front>

<seriesInfo name='World Wide Web Consortium LastCall' value='WD-exi-profile-20120731' />
<format type='HTML' target='http://www.w3.org/TR/2012/WD-exi-profile-20120731' />
</reference>
    </references>
<!-- This document was prepared using Pandoc2rfc -->
<!-- https://github.com/miekg/pandoc2rfc -->

  


</back>
</rfc>