Internet DRAFT - draft-shelby-exi-registration
draft-shelby-exi-registration
Appsawg Z. Shelby
Internet-Draft Micro:bit Foundation
Intended status: Informational O. Bergmann
Expires: August 26, 2017 C. Bormann
Universitaet Bremen TZI
February 22, 2017
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
Shelby, et al. Expires August 26, 2017 [Page 1]
Internet-Draft +exi February 2017
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. When to Use the +exi Suffix . . . . . . . . . . . . . . . . . 3
3. Security Considerations . . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Normative References . . . . . . . . . . . . . . . . . . 5
6.2. Informative References . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
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.
Shelby, et al. Expires August 26, 2017 [Page 2]
Internet-Draft +exi February 2017
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
Shelby, et al. Expires August 26, 2017 [Page 3]
Internet-Draft +exi February 2017
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.
Shelby, et al. Expires August 26, 2017 [Page 4]
Internet-Draft +exi February 2017
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
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<http://www.rfc-editor.org/info/rfc6838>.
[W3C.REC-exi-20140211]
Schneider, J., Kamiya, T., Peintner, D., and R. Kyusakov,
"Efficient XML Interchange (EXI) Format 1.0 (Second
Edition)", World Wide Web Consortium Recommendation REC-
exi-20140211, February 2014,
<http://www.w3.org/TR/2014/REC-exi-20140211>.
6.2. Informative References
[RFC5988] Nottingham, M., "Web Linking", RFC 5988,
DOI 10.17487/RFC5988, October 2010,
<http://www.rfc-editor.org/info/rfc5988>.
Shelby, et al. Expires August 26, 2017 [Page 5]
Internet-Draft +exi February 2017
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<http://www.rfc-editor.org/info/rfc7252>.
[RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303,
DOI 10.17487/RFC7303, July 2014,
<http://www.rfc-editor.org/info/rfc7303>.
Authors' Addresses
Zach Shelby
Micro:bit Foundation
Phone: +358 407796297
Email: zach@microbit.org
Olaf Bergmann
Universitaet Bremen TZI
Postfach 330440
Bremen D-28359
Germany
Phone: +49-421-218-63904
Email: bergmann@tzi.org
Carsten Bormann
Universitaet Bremen TZI
Postfach 330440
Bremen D-28359
Germany
Phone: +49-421-218-63921
Email: cabo@tzi.org
Shelby, et al. Expires August 26, 2017 [Page 6]
