<?xml version="1.0" encoding="utf-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version  -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY SELF "[RFC-XXXX]">
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc ipr="trust200902" docName="draft-shelby-exi-registration-02" category="info">

  <front>
    <title abbrev="+exi">The +exi Media Type Suffix</title>

    <author initials="Z." surname="Shelby" fullname="Zach Shelby">
      <organization>Micro:bit Foundation</organization>
      <address>
        <phone>+358 407796297</phone>
        <email>zach@microbit.org</email>
      </address>
    </author>
    <author initials="O." surname="Bergmann" fullname="Olaf Bergmann">
      <organization>Universität Bremen TZI</organization>
      <address>
        <postal>
          <street>Postfach 330440</street>
          <city>Bremen</city>
          <code>D-28359</code>
          <country>Germany</country>
        </postal>
        <phone>+49-421-218-63904</phone>
        <email>bergmann@tzi.org</email>
      </address>
    </author>
    <author initials="C." surname="Bormann" fullname="Carsten Bormann">
      <organization>Universität Bremen TZI</organization>
      <address>
        <postal>
          <street>Postfach 330440</street>
          <city>Bremen</city>
          <code>D-28359</code>
          <country>Germany</country>
        </postal>
        <phone>+49-421-218-63921</phone>
        <email>cabo@tzi.org</email>
      </address>
    </author>

    <date year="2017" month="February" day="22"/>

    
    <workgroup>Appsawg</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>Efficient XML Interchange (EXI) is an XML representation technique
specified by the W3C to provide a time and space efficient encoding
for XML documents. This document defines a new Structured Syntax
Suffix “+exi” for use in a specific class of protocols, where “exi”
content-type encoding or the generic “application/exi” media type are
not applicable.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>Efficient XML Interchange (EXI) <xref target="W3C.REC-exi-20140211"/>
is an XML representation technique specified by the W3C to provide a
time and space efficient binary encoding alternative to the standard text XML representation. EXI is not
a generic compression technique like gzip or deflate, but an encoding
technique specifically for XML structured documents, which uses either learned or pre-informed
schema information.</t>

<t><xref target="W3C.REC-exi-20140211"/> defines a generic media type for documents encoded in EXI,
“application/exi”; this does not provide a way to indicate more
information about structure and semantics of the EXI-encoded XML.
Also, <xref target="W3C.REC-exi-20140211"/> defines an HTTP content encoding, “exi”, that can be used to
indicate EXI coding in combination with an existing XML media type.</t>

<t>This document defines a new Structured Syntax Suffix “+exi” for use in
media types for a specific class of protocols, where the “exi” content-type encoding
or the generic “application/exi” media type are not
viable. In particular, the Constrained Application Protocol (CoAP)
<xref target="RFC7252"/> combines the media type and its encoding in a single option
value. Thus, a client would include an <spanx style="emph">Accept</spanx> option in a <spanx style="verb">GET</spanx>
request to indicate its capability of processing, e.g., <spanx style="verb">text/plain</spanx>
in UTF-8 encoding, or <spanx style="verb">application/exi</spanx>, while the actual media type
and encoding of a transferred payload would be described by the
<spanx style="emph">Content-Format</spanx> option. CoAP servers can provide a description of
their hosted resources as specified in Section 7.2 of <xref target="RFC7252"/>. A
description usually contains an attribute <spanx style="verb">ct</spanx> that lists the
Content-Format codes the server offers for a respective resource.</t>

<t>Since EXI-encoded documents may or may not contain explicit
information on the schema that is applicable to this document, the
receiver of an EXI document would have to inspect its contents to
decide if it can continue processing. The structure syntax suffix
specified in this document can be used by a sender to provide explicit
information about the media types and encodings it can process.</t>

<section anchor="terminology" title="Terminology">

<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this
document are to be interpreted as described in RFC 2119 <xref target="RFC2119"/>.</t>

</section>
</section>
<section anchor="when" title="When to Use the +exi Suffix">

<t>The EXI standard already defines both an “exi” content-type encoding
and an “application/exi” media type. This section discusses when it
is appropriate to use the new “+exi” structured syntax suffix when
registering a media type.</t>

<t>Appendix F.1 of <xref target="W3C.REC-exi-20140211"/> clearly describes when the
exi content-type encoding should be used: “Protocols that can identify
and negotiate the content coding of XML information independent of its
media type, SHOULD use the content coding “exi” (case-insensitive) to
convey the acceptance or actual use of EXI encoding for XML
information.”</t>

<t>Thus when a protocol depends on the media type to identify that the
payload is EXI, it can make use of the “application/exi” media type
defined in Appendix F.2 of <xref target="W3C.REC-exi-20140211"/>.  This works particularly well for
applications using EXI in a generic way, and in particular in
schema-less EXI streams, where protocol specific information such as
the XML schema used is not needed to process the payload, or where the
EXI stream contains the <spanx style="verb">schemaId</spanx> option to reference an applicable
XML schema.  In these cases it is RECOMMENDED to use either the
“application/exi” media type or “exi” content-type encoding with an
existing media type.</t>

<t>The “+exi” structure syntax suffix is appropriate for use in either of
the following cases:</t>

<t><list style="numbers">
  <t>In protocols that have no means of separately transferring the
media type and content coding information, the “+exi” suffix can be
used to inform the recipient of a payload that the EXI
serialization for the given media type has been used. This SHOULD
be used if and only if the EXI payload does not contain a
<spanx style="verb">schemaId</spanx> option and the EXI payload has been produced using the
XML schema that is registered with the respective media type.
This is typically the case for protocols that use EXI as a native
encoding (without the use of character-based XML as an intermediate).</t>
  <t>To list the available combinations of media types and encodings in
a Web Linking attribute <xref target="RFC5988"/>. CoAP <xref target="RFC7252"/>, for example,
defines the attribute “ct” as a list of Content-Format codes. The
Content-Format aggregates the media type and coding information.</t>
</list></t>

<t>Both application areas address a very specific set of use cases where
the media type “application/exi” or the content coding “exi” do not
provide sufficient information for a receiver to decide if it is able
to process the respective payload.</t>

</section>
<section anchor="security" title="Security Considerations">

<t>Security considerations are discussed in <xref target="iana"/>.</t>

</section>
<section anchor="iana" title="IANA Considerations">

<t>This document requests registration of the Structured Syntax Suffix
“+exi” as follows, following the registration template from Section
4.2.8 of <xref target="RFC6838"/></t>

<t><list style="hanging">
  <t hangText='Name:'>
  Efficient XML Interchange</t>
  <t hangText='+suffix:'>
  “+exi”</t>
  <t hangText='References:'>
  The EXI standard is defined in <xref target="W3C.REC-exi-20140211"/>, in
particular schema-informed grammars are defined in Section 8.5 and
the “applicatio/exi” media type is defined in Appendix F.2.</t>
  <t hangText='Encoding considerations:'>
  Binary</t>
  <t hangText='Interoperability considerations:'>
  The registration of a media type using this suffix MUST describe how
     to determine the XML Schema that is used to encode/decode a
     payload identified by that media type. In particular this
     description defines how to determine the schema used to encode
     a payload using the <spanx style="verb">schemaId</spanx> option of the EXI header, if present. The
     format of the identifier to be used in the <spanx style="verb">schemaId</spanx>, a
     reference to where the corresponding schema is defined, and a
     description of how future versions of such schemas will be
     handled MUST be included. A default schema version in the
     absence of the <spanx style="verb">schemaId</spanx> field MAY be defined.</t>
  <t hangText='Security considerations:'>
  The “+exi” suffix shares the same security considerations as XML,
     described in <xref target="RFC7303"/>, Section 10. In addition, the security
     considerations discussed in the media type registration for
     “application/exi” apply as defined in Appendix F.2 of
     <xref target="W3C.REC-exi-20140211"/>}.</t>
  <t hangText='Contact:'>
  Applications and Real-Time Area (ART) General Applications Working Group (art@ietf.org)</t>
  <t hangText='Author/Change controller:'>
  The ART General Applications Area Working Group has change control over this registration.</t>
</list></t>

</section>
<section anchor="acknowledgments" title="Acknowledgments">

<t>This draft is the result of discussions on the former Apps Area Working Group
mailing list. Thanks to Carine Bournez and Guido Moritz for their
helpful comments.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor='RFC2119' target='http://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>



<reference  anchor='RFC6838' target='http://www.rfc-editor.org/info/rfc6838'>
<front>
<title>Media Type Specifications and Registration Procedures</title>
<author initials='N.' surname='Freed' fullname='N. Freed'><organization /></author>
<author initials='J.' surname='Klensin' fullname='J. Klensin'><organization /></author>
<author initials='T.' surname='Hansen' fullname='T. Hansen'><organization /></author>
<date year='2013' month='January' />
<abstract><t>This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols.  This memo documents an Internet Best Current Practice.</t></abstract>
</front>
<seriesInfo name='BCP' value='13'/>
<seriesInfo name='RFC' value='6838'/>
<seriesInfo name='DOI' value='10.17487/RFC6838'/>
</reference>



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

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

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

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

<author initials='R.' surname='Kyusakov' fullname='Rumen Kyusakov'>
    <organization />
</author>

<date month='February' day='11' year='2014' />
</front>

<seriesInfo name='World Wide Web Consortium Recommendation' value='REC-exi-20140211' />
<format type='HTML' target='http://www.w3.org/TR/2014/REC-exi-20140211' />
</reference>




    </references>

    <references title='Informative References'>





<reference  anchor='RFC5988' target='http://www.rfc-editor.org/info/rfc5988'>
<front>
<title>Web Linking</title>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham'><organization /></author>
<date year='2010' month='October' />
<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.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5988'/>
<seriesInfo name='DOI' value='10.17487/RFC5988'/>
</reference>



<reference  anchor='RFC7252' target='http://www.rfc-editor.org/info/rfc7252'>
<front>
<title>The Constrained Application Protocol (CoAP)</title>
<author initials='Z.' surname='Shelby' fullname='Z. Shelby'><organization /></author>
<author initials='K.' surname='Hartke' fullname='K. Hartke'><organization /></author>
<author initials='C.' surname='Bormann' fullname='C. Bormann'><organization /></author>
<date year='2014' month='June' />
<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 IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) 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.</t><t>CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types.  CoAP is designed to easily interface 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='RFC' value='7252'/>
<seriesInfo name='DOI' value='10.17487/RFC7252'/>
</reference>



<reference  anchor='RFC7303' target='http://www.rfc-editor.org/info/rfc7303'>
<front>
<title>XML Media Types</title>
<author initials='H.' surname='Thompson' fullname='H. Thompson'><organization /></author>
<author initials='C.' surname='Lilley' fullname='C. Lilley'><organization /></author>
<date year='2014' month='July' />
<abstract><t>This specification standardizes three media types -- application/xml, application/xml-external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML) while defining text/xml and text/ xml-external-parsed-entity as aliases for the respective application/ types.  This specification also standardizes the '+xml' suffix for naming media types outside of these five types when those media types represent XML MIME entities.</t></abstract>
</front>
<seriesInfo name='RFC' value='7303'/>
<seriesInfo name='DOI' value='10.17487/RFC7303'/>
</reference>




    </references>


<!--  LocalWords:
 -->

<!-- Local Variables: -->
<!-- coding: utf-8 -->
<!-- ispell-local-dictionary: "american" -->
<!-- End: -->



  </back>
</rfc>

