The +exi Media Type Suffix
draft-shelby-exi-registration-02

Abstract

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.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

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."

This Internet-Draft will expire on August 26, 2017.

Copyright Notice

Copyright (c) 2017 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 1.1. Terminology
• 2. When to Use the +exi Suffix
• 3. Security Considerations
• 4. IANA Considerations
• 5. Acknowledgments
• 6. References
• 6.1. Normative References
• 6.2. Informative References
• Authors' Addresses

1. Introduction

Efficient XML Interchange (EXI) [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.

[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, [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.

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) [RFC7252] combines the media type and its encoding in a single option value. Thus, a client would include an Accept option in a GET request to indicate its capability of processing, e.g., text/plain in UTF-8 encoding, or application/exi, while the actual media type and encoding of a transferred payload would be described by the Content-Format option. CoAP servers can provide a description of their hosted resources as specified in Section 7.2 of [RFC7252]. A description usually contains an attribute ct that lists the Content-Format codes the server offers for a respective resource.

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.

1.1. Terminology

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 [RFC2119].

2. When to Use the +exi Suffix

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.

Appendix F.1 of [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.”

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 [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 schemaId 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.

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

1. 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 schemaId 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).
2. To list the available combinations of media types and encodings in a Web Linking attribute [RFC5988]. CoAP [RFC7252], for example, defines the attribute “ct” as a list of Content-Format codes. The Content-Format aggregates the media type and coding information.

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.

3. Security Considerations

Security considerations are discussed in Section 4.

4. IANA Considerations

This document requests registration of the Structured Syntax Suffix “+exi” as follows, following the registration template from Section 4.2.8 of [RFC6838]

Name:

Efficient XML Interchange

+suffix:

“+exi”

References:

The EXI standard is defined in [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.

Encoding considerations:

Binary

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 schemaId option of the EXI header, if present. The format of the identifier to be used in the schemaId, 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 schemaId field MAY be defined.

Security considerations:

The “+exi” suffix shares the same security considerations as XML, described in [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 [W3C.REC-exi-20140211]}.

Contact:

Applications and Real-Time Area (ART) General Applications Working Group (art@ietf.org)

Author/Change controller:

The ART General Applications Area Working Group has change control over this registration.

5. Acknowledgments

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.

6. References

6.1. Normative References

6.2. Informative References

Authors' Addresses