idnits 2.17.1 draft-doi-exi-messaging-requirements-01.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 25, 2013) is 4077 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-11 == Outdated reference: A later version (-04) exists of draft-shelby-core-coap-req-02 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Application Y. Doi 3 Internet-Draft TOSHIBA Corporation 4 Intended status: Informational February 25, 2013 5 Expires: August 29, 2013 7 EXI Messaging Requirements 8 draft-doi-exi-messaging-requirements-01 10 Abstract 12 EXI (Efficient XML Interchange) is a specification on efficient 13 encoding of XML. EXI is useful if an application requires XML based 14 message exchange but no sufficient resource is available. However, 15 schema-informed mode of EXI needs some out-of-band coordination 16 between communicating nodes. This document discusses requirement on 17 use of schema-informed EXI as a message exchange format on the 18 Internet systems. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 29, 2013. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Schema Update and Data Type Derivation . . . . . . . . . . . . 3 56 3. Schema Negotiation for Strict Schema-Informed EXI Messaging . . 3 57 3.1. Content-Type and Schema Identification . . . . . . . . . . 4 58 3.2. Client-Driven Schema Negotiation . . . . . . . . . . . . . 4 59 3.3. Server-Driven Schema Negotiation . . . . . . . . . . . . . 5 60 3.4. Publisher-Driven Schema Negotiation . . . . . . . . . . . . 5 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 63 6. Normative References . . . . . . . . . . . . . . . . . . . . . 5 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 EXI[W3C.REC-exi-20110310] (Efficient XML Interchange) is a 69 specification on efficient encoding of XML. EXI is useful if an 70 application requires XML based message exchange but no sufficient 71 resource is available, such as environments discussed in 72 [I-D.shelby-core-coap-req]. However, EXI may need some out-of-band 73 coordination between communicating nodes. 75 The target of this document is not to discuss EXI spec itself. This 76 document discusses how to use it as a message exchange format (a 77 presentation layer) on the Internet systems to support development 78 and deployment of EXI systems in the Internet including constrained 79 nodes. 81 2. Schema Update and Data Type Derivation 83 In communication use cases of XML/EXI, XML schema (or equivalents) is 84 often used to define a standard message format. A schema defines a 85 message format, and such message format is expected to be able to 86 extend. There are at least two ways of extension. 88 First way is to update the schema. Brand-new devices with a new 89 functionality may have updated schema to support extended message. 90 In this scenario, a system consists of multiple versions of schema. 91 As schema-informed EXI requires communicating nodes to use identical 92 schema, this scenario requires schema negotiation. 94 Second way is to use derived data types from the schema. Built-in 95 grammar or non-strict schema-informed grammar allow derived XML 96 instances from the definition in the XML schema. To accommodate 97 resource-constrained nodes, an application spec may specify a 98 parameter set with EXI Profile[W3C.WD-exi-profile-20120731]. 100 Schema update and data derivation are not exclusive. Application 101 designers may choose one or both approaches. This is tradeoff 102 between extensiblity and interoperability. 104 3. Schema Negotiation for Strict Schema-Informed EXI Messaging 106 In short, EXI has two grammar modes: Schema-informed and Built-in. 107 Built-in grammar uses dynamic state machines that learn document 108 structure on-the fly. On the other hand, Schema-informed grammar 109 makes a set of state machines from a schema and the state machines 110 are used to encode/decode document structure. Strict mode of schema- 111 informed grammar uses static state machines for XML elements and 112 attributes defined in the XML schema. Wildcard elements are handled 113 in the built-in grammar (dynamic state machines). Non-strict mode 114 allows XML data to be derived from that defined in the XML schema. 116 Because schema-informed grammars can make smallest messages in most 117 cases, some applications may want to make use of schema-informed 118 grammar as its message format. 120 To decode an EXI message, the sender and receiver must have exactly 121 same schema. However, the way to negotiate and match schema between 122 communicating nodes is not yet well defined. 124 To use EXI as application message encodings, clients and servers 125 should have a way to coordinate the schema used in the communication. 126 This is similar to content negotiation defined in HTTP[RFC2616]. 127 This section describes schema negotiation cases based on common 128 communication pattern. 130 3.1. Content-Type and Schema Identification 132 To negotiate schema, an application must have a way to identify a 133 schema. 135 A content-type may use schema-informed EXI as its encoding. Each 136 content-type should define how to identify a schema used in a 137 communication. The identifier (schemaId) may have internal structure 138 to indicate backward compatibility. 140 A good practice is to have schema version number (Major.Minor) as a 141 schema ID. Between minor modifications, schemas should have backward 142 compatibility (a node with schema 4.3 shall have schema 4.0, 4.1 and 143 4.2). Between major modifications, schema should not have it (a node 144 with schema 4.3 may not have schema 1.x, 2.x and 3.x). Note that 145 schemaId is local identifier space that belongs to a content-type. 146 There is no need to have global schema ID registry. 148 On schema negotiation, a receiver of a message declares a set of 149 acceptable schema IDs and a sender selects a schema ID among the 150 given set. The selected schema ID should be in schemaId field of EXI 151 option header. 153 3.2. Client-Driven Schema Negotiation 155 Client-driven schema negotiation is the way that a client decides 156 actual schema version used in a communication. This happens in POST 157 or PUT style communications. In [RFC2616], try-and-redirect style of 158 client-driven content negotiation is described. Similar way should 159 be possible in schema negotiation. However, it may be simpler to 160 have a way to declare a server's acceptable schema set. 162 As an alternative, a server (or a resource on a server) may declare 163 its available schema set via some service discovery mechanisms. 164 Candidates are such as DNS-SD[I-D.cheshire-dnsext-dns-sd] TXT 165 resource records or media type in link 166 format[I-D.nottingham-http-link-header] that represents a resource. 167 If an application can assume a client does service discovery before 168 using the service, it may assume the client knows server's schema 169 set. 171 3.3. Server-Driven Schema Negotiation 173 Server-driven schema negotiation is the way that a server decides 174 actual schema version used in a communication. In HTTP, schema 175 negotiation in GET requests should do server-driven negotiation. In 176 [RFC2616], Accept: header is defined to make server-driven content 177 negotiation. Schema negotiation can be piggybacked on it by using 178 some content type parameter to carry acceptable schema ID set. 180 3.4. Publisher-Driven Schema Negotiation 182 CoAP[I-D.ietf-core-coap] and some other protocols may have publish- 183 subscribe (observer) pattern in communication. In this case, a 184 subscriber should give its acceptable schema ID set to a publisher as 185 it registers its subscription request. 187 4. Security Considerations 189 No particular security concern is raised by this document. 190 Applications should be able to detect malformed input as usual. 192 5. IANA Considerations 194 This document has no actions for IANA. 196 6. Normative References 198 [I-D.cheshire-dnsext-dns-sd] 199 Cheshire, S. and M. Krochmal, "DNS-Based Service 200 Discovery", draft-cheshire-dnsext-dns-sd-11 (work in 201 progress), December 2011. 203 [I-D.ietf-core-coap] 204 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 205 "Constrained Application Protocol (CoAP)", 206 draft-ietf-core-coap-11 (work in progress), July 2012. 208 [I-D.nottingham-http-link-header] 209 Nottingham, M., "Web Linking", 210 draft-nottingham-http-link-header-10 (work in progress), 211 May 2010. 213 [I-D.shelby-core-coap-req] 214 Shelby, Z., Stuber, M., Sturek, D., Frank, B., and R. 215 Kelsey, "CoAP Requirements and Features", 216 draft-shelby-core-coap-req-02 (work in progress), 217 October 2010. 219 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 220 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 221 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 223 [W3C.REC-exi-20110310] 224 Kamiya, T. and J. Schneider, "Efficient XML Interchange 225 (EXI) Format 1.0", World Wide Web Consortium 226 Recommendation REC-exi-20110310, March 2011, 227 . 229 [W3C.WD-exi-profile-20120731] 230 Fablet, Y. and D. Peintner, "Efficient XML Interchange 231 (EXI) Profile", World Wide Web Consortium LastCall WD-exi- 232 profile-20120731, July 2012, 233 . 235 Author's Address 237 Yusuke Doi 238 TOSHIBA Corporation 239 Komukai Toshiba Cho 1 240 Saiwai-Ku 241 Kawasaki, Kanagawa 2128582 242 JAPAN 244 Phone: +81-45-342-7230 245 Email: yusuke.doi@toshiba.co.jp 246 URI: