idnits 2.17.1 draft-shelby-exi-registration-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 22, 2017) is 2620 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 5988 (Obsoleted by RFC 8288) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Appsawg Z. Shelby 3 Internet-Draft Micro:bit Foundation 4 Intended status: Informational O. Bergmann 5 Expires: August 26, 2017 C. Bormann 6 Universitaet Bremen TZI 7 February 22, 2017 9 The +exi Media Type Suffix 10 draft-shelby-exi-registration-02 12 Abstract 14 Efficient XML Interchange (EXI) is an XML representation technique 15 specified by the W3C to provide a time and space efficient encoding 16 for XML documents. This document defines a new Structured Syntax 17 Suffix "+exi" for use in a specific class of protocols, where "exi" 18 content-type encoding or the generic "application/exi" media type are 19 not applicable. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 26, 2017. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. When to Use the +exi Suffix . . . . . . . . . . . . . . . . . 3 58 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 59 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 60 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 61 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 63 6.2. Informative References . . . . . . . . . . . . . . . . . 5 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 Efficient XML Interchange (EXI) [W3C.REC-exi-20140211] is an XML 69 representation technique specified by the W3C to provide a time and 70 space efficient binary encoding alternative to the standard text XML 71 representation. EXI is not a generic compression technique like gzip 72 or deflate, but an encoding technique specifically for XML structured 73 documents, which uses either learned or pre-informed schema 74 information. 76 [W3C.REC-exi-20140211] defines a generic media type for documents 77 encoded in EXI, "application/exi"; this does not provide a way to 78 indicate more information about structure and semantics of the EXI- 79 encoded XML. Also, [W3C.REC-exi-20140211] defines an HTTP content 80 encoding, "exi", that can be used to indicate EXI coding in 81 combination with an existing XML media type. 83 This document defines a new Structured Syntax Suffix "+exi" for use 84 in media types for a specific class of protocols, where the "exi" 85 content-type encoding or the generic "application/exi" media type are 86 not viable. In particular, the Constrained Application Protocol 87 (CoAP) [RFC7252] combines the media type and its encoding in a single 88 option value. Thus, a client would include an _Accept_ option in a 89 "GET" request to indicate its capability of processing, e.g., "text/ 90 plain" in UTF-8 encoding, or "application/exi", while the actual 91 media type and encoding of a transferred payload would be described 92 by the _Content-Format_ option. CoAP servers can provide a 93 description of their hosted resources as specified in Section 7.2 of 94 [RFC7252]. A description usually contains an attribute "ct" that 95 lists the Content-Format codes the server offers for a respective 96 resource. 98 Since EXI-encoded documents may or may not contain explicit 99 information on the schema that is applicable to this document, the 100 receiver of an EXI document would have to inspect its contents to 101 decide if it can continue processing. The structure syntax suffix 102 specified in this document can be used by a sender to provide 103 explicit information about the media types and encodings it can 104 process. 106 1.1. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119]. 112 2. When to Use the +exi Suffix 114 The EXI standard already defines both an "exi" content-type encoding 115 and an "application/exi" media type. This section discusses when it 116 is appropriate to use the new "+exi" structured syntax suffix when 117 registering a media type. 119 Appendix F.1 of [W3C.REC-exi-20140211] clearly describes when the exi 120 content-type encoding should be used: "Protocols that can identify 121 and negotiate the content coding of XML information independent of 122 its media type, SHOULD use the content coding "exi" (case- 123 insensitive) to convey the acceptance or actual use of EXI encoding 124 for XML information." 126 Thus when a protocol depends on the media type to identify that the 127 payload is EXI, it can make use of the "application/exi" media type 128 defined in Appendix F.2 of [W3C.REC-exi-20140211]. This works 129 particularly well for applications using EXI in a generic way, and in 130 particular in schema-less EXI streams, where protocol specific 131 information such as the XML schema used is not needed to process the 132 payload, or where the EXI stream contains the "schemaId" option to 133 reference an applicable XML schema. In these cases it is RECOMMENDED 134 to use either the "application/exi" media type or "exi" content-type 135 encoding with an existing media type. 137 The "+exi" structure syntax suffix is appropriate for use in either 138 of the following cases: 140 1. In protocols that have no means of separately transferring the 141 media type and content coding information, the "+exi" suffix can 142 be used to inform the recipient of a payload that the EXI 143 serialization for the given media type has been used. This 144 SHOULD be used if and only if the EXI payload does not contain a 145 "schemaId" option and the EXI payload has been produced using the 146 XML schema that is registered with the respective media type. 147 This is typically the case for protocols that use EXI as a native 148 encoding (without the use of character-based XML as an 149 intermediate). 151 2. To list the available combinations of media types and encodings 152 in a Web Linking attribute [RFC5988]. CoAP [RFC7252], for 153 example, defines the attribute "ct" as a list of Content-Format 154 codes. The Content-Format aggregates the media type and coding 155 information. 157 Both application areas address a very specific set of use cases where 158 the media type "application/exi" or the content coding "exi" do not 159 provide sufficient information for a receiver to decide if it is able 160 to process the respective payload. 162 3. Security Considerations 164 Security considerations are discussed in Section 4. 166 4. IANA Considerations 168 This document requests registration of the Structured Syntax Suffix 169 "+exi" as follows, following the registration template from 170 Section 4.2.8 of [RFC6838] 172 Name: Efficient XML Interchange 174 +suffix: "+exi" 176 References: The EXI standard is defined in [W3C.REC-exi-20140211], 177 in particular schema-informed grammars are defined in Section 8.5 178 and the "applicatio/exi" media type is defined in Appendix F.2. 180 Encoding considerations: Binary 182 Interoperability considerations: The registration of a media type 183 using this suffix MUST describe how to determine the XML Schema 184 that is used to encode/decode a payload identified by that media 185 type. In particular this description defines how to determine the 186 schema used to encode a payload using the "schemaId" option of the 187 EXI header, if present. The format of the identifier to be used 188 in the "schemaId", a reference to where the corresponding schema 189 is defined, and a description of how future versions of such 190 schemas will be handled MUST be included. A default schema 191 version in the absence of the "schemaId" field MAY be defined. 193 Security considerations: The "+exi" suffix shares the same security 194 considerations as XML, described in [RFC7303], Section 10. In 195 addition, the security considerations discussed in the media type 196 registration for "application/exi" apply as defined in 197 Appendix F.2 of [W3C.REC-exi-20140211]}. 199 Contact: Applications and Real-Time Area (ART) General Applications 200 Working Group (art@ietf.org) 202 Author/Change controller: The ART General Applications Area Working 203 Group has change control over this registration. 205 5. Acknowledgments 207 This draft is the result of discussions on the former Apps Area 208 Working Group mailing list. Thanks to Carine Bournez and Guido 209 Moritz for their helpful comments. 211 6. References 213 6.1. Normative References 215 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 216 Requirement Levels", BCP 14, RFC 2119, 217 DOI 10.17487/RFC2119, March 1997, 218 . 220 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 221 Specifications and Registration Procedures", BCP 13, 222 RFC 6838, DOI 10.17487/RFC6838, January 2013, 223 . 225 [W3C.REC-exi-20140211] 226 Schneider, J., Kamiya, T., Peintner, D., and R. Kyusakov, 227 "Efficient XML Interchange (EXI) Format 1.0 (Second 228 Edition)", World Wide Web Consortium Recommendation REC- 229 exi-20140211, February 2014, 230 . 232 6.2. Informative References 234 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, 235 DOI 10.17487/RFC5988, October 2010, 236 . 238 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 239 Application Protocol (CoAP)", RFC 7252, 240 DOI 10.17487/RFC7252, June 2014, 241 . 243 [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, 244 DOI 10.17487/RFC7303, July 2014, 245 . 247 Authors' Addresses 249 Zach Shelby 250 Micro:bit Foundation 252 Phone: +358 407796297 253 Email: zach@microbit.org 255 Olaf Bergmann 256 Universitaet Bremen TZI 257 Postfach 330440 258 Bremen D-28359 259 Germany 261 Phone: +49-421-218-63904 262 Email: bergmann@tzi.org 264 Carsten Bormann 265 Universitaet Bremen TZI 266 Postfach 330440 267 Bremen D-28359 268 Germany 270 Phone: +49-421-218-63921 271 Email: cabo@tzi.org