idnits 2.17.1 draft-doi-core-parameter-option-03.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 (August 8, 2013) is 3914 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2046' is defined on line 278, but no explicit reference was found in the text == Unused Reference: 'RFC2616' is defined on line 282, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-wilde-atom-profile-01 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Y. Doi 3 Internet-Draft TOSHIBA Corporation 4 Intended status: Informational K. Lynn 5 Expires: February 9, 2014 Consultant 6 August 8, 2013 8 CoAP Content-Type Parameter Option 9 draft-doi-core-parameter-option-03 11 Abstract 13 Content-Types may have 'parameter' to make fine-grained description 14 of contents. The CoAP Accept Content-Type Parameter Option (Accept- 15 CT-Parameter Option) is CoAP options to add a parameter to a content 16 type specified in CoAP Accept Options. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on February 9, 2014. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Use Cases of Option Parameter in CoAP . . . . . . . . . . . . . 3 54 2.1. Clarification on URI, Resource, and Representation . . . . 3 55 2.2. Parameter Coordination . . . . . . . . . . . . . . . . . . 3 56 2.3. Schema Negotiation of Schema-Informed EXI Communication . . 4 57 3. Accept Content-Type Parameter Option . . . . . . . . . . . . . 4 58 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.2. Accept-CT-Parameter Option . . . . . . . . . . . . . . . . 5 60 3.2.1. Attribute ID . . . . . . . . . . . . . . . . . . . . . 6 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 63 6. Normative References . . . . . . . . . . . . . . . . . . . . . 7 64 Appendix A. Consideration on Compact Encodings of 65 Content-Type Parameter . . . . . . . . . . . . . . . . 8 66 Appendix B. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 8 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 69 1. Introduction 71 Content-Type field[RFC2045] have 'parameter' to make fine-grained 72 description of contents. The document proposes the CoAP Content-Type 73 Parameter Option that enables wide range of parameter description 74 over content types used in CoAP. 76 2. Use Cases of Option Parameter in CoAP 78 2.1. Clarification on URI, Resource, and Representation 80 In CoAP, a resource is specified by a CoAP URI. However, in some use 81 cases described in followings, an URI may correspond to multiple 82 versions of the resource, or a resource may have multiple 83 representations. As best practices, there are several ways to 84 identify a version and a representation on a resource pointed by an 85 URI. Some of discussions are given in 86 [W3C.Finding.alternatives-discovery]. 88 One of the approaches commonly used is to parameterize contents with 89 content-type parameter and make a server-side content negotiation. 91 Basic specification of CoAP[I-D.ietf-core-coap] does not cover such 92 content negotiation and this draft is to propose a way to mimic 93 server-side content negotiation by making room for content type 94 parameters with a new option. 96 2.2. Parameter Coordination 98 If a resource has wide range of representations, a client may try to 99 specify what representation of the resource is requested by a GET 100 message. In HTTP, Accept: header and content type (media type) 101 parameter is used to coordinate parameters between clients and 102 servers. audio/rtp-midi[RFC6295] is an example of a content-type with 103 various parameters. 105 The audio use case seems not to be widely used in CoAP so far. 106 However, the same use case is applicable for sensor data. Sensor 107 data is time series data and it is possible to define a content type 108 with preferred sensing interval to avoid over/underquality of 109 sampling. In such cases, parameters with wildcard (rate=*) or range 110 (rate=10-20) is useful. 112 Similar parameter coordination is also proposed in 113 [I-D.wilde-atom-profile]. In the draft, several representations can 114 exist on a resource defined with a URI, and a client can negotiate 115 representation of the resource. 117 2.3. Schema Negotiation of Schema-Informed EXI Communication 119 In some use case of Schema-Informed EXI [W3C.REC-exi-20110310], a 120 server and a client need to coordinate a XML schema to encode a 121 message. If there are some versions of XML schemas in an 122 application, a sender (may be server or client) needs to know schemas 123 a receiver has. 125 There are two choices. First choice is to define a content-type for 126 each version of XML schema. However, there are two problems. First, 127 the Content-type ID space is a global space and not suitable to 128 describe every minor revision. Second, Content-type ID per schema 129 cannot describe relation between a linage of schemas. XML schema 130 could be backward compatible and newer schema version can be applied 131 on older document validation and EXI encoding. Common practice on 132 this is to use (major).(minor) style versioning. 134 However, content-ID or other class of ID cannot describe which 135 version is compatible and which version is not compatible. 137 The other choice is to make use of content-type parameters. It seems 138 to be more acceptable because parameter is local to each content- 139 type. For example, an application may define 'application/ 140 example-exi' as a content-type for the application. The application 141 may use 'sv' parameter as acceptable schema version. If the 142 application use backward-compatible approach, 'Accept: application/ 143 example-exi;sv=1.4' from a client means the client can receive schema 144 version 1.0, 1.1, 1.2, 1.3, and 1.4. 146 Detailed discussion on EXI schema negotiation can be found in 147 [I-D.doi-exi-messaging-requirements]. 149 3. Accept Content-Type Parameter Option 151 3.1. Requirements 153 In general, a content-type parameter has following notations. 155 parameter := ";" attribute "=" value 156 attribute := token ; case insensitive 157 value := token / quoted-string 159 In CoAP, a content-type parameter should have similar ability of 160 expression with regards to use cases. At the same time, a CoAP 161 option should be compact enough to fit in constrained environments. 163 As CoAP options do not have room for parameters, the content-type 164 parameter option is designed to be an independent option that gives 165 additional description on a content-type in a CoAP message. 167 An attribute of CoAP option parameter should be fit in relatively 168 smaller set. The authors consider the attribute part could be 169 described in short integer (16 bits). On the other hand, the value 170 part should have higher degree of freedom for applications including 171 wildcards and range description. The author believes it is simple 172 and safe to have a string value in option parameter option. 174 3.2. Accept-CT-Parameter Option 176 To enable server-side content type negotiation, an option to describe 177 content type parameter is required. This document defines Accept-CT- 178 Parameter option for the purpose. 180 Table 1: List of options. U: proxy-Unsafe, C: Critical, R: 181 Repeatable 183 +----+---+---+---+---+------------------+--------+--------+---------+ 184 | No | C | U | N | R | Name | Format | Length | Default | 185 | . | | | | | | | | | 186 +----+---+---+---+---+------------------+--------+--------+---------+ 187 | TB | | | | x | Accept-CT-Parame | (see | 3-270B | (none) | 188 | D | | | | | ter | below) | | | 189 +----+---+---+---+---+------------------+--------+--------+---------+ 191 The Accept-CT-Parameter option is used to attach a parameter on an 192 Accept option on the same CoAP message. The Accept-CT-parameter 193 options are proxy safe, elective. 195 An Accept-CT-Parameter option has two fields: attribute ID(aid), and 196 value. 198 |<--- option length ---->| 200 +---------+---------....-+ 201 | aid | value | 202 +---------+---------....-+ 204 |<2 Bytes>|<- optlen-2 ->| 206 :Figure 2: Structure of Accept-CT-Parameter Option 208 Attribute ID (aid) is a two-byte integer that describes the attribute 209 name (key) of the parameter. Details are described in later section 210 (see Table 2). 212 A value is opaque octets (Unicode string in most cases) with the 213 length of the option length minus two (2) octets. A value may be 214 empty. Meanings of the values should be defined by the content-type 215 authority. 217 3.2.1. Attribute ID 219 Attribute ID is a 2-byte integer. An attribute is described in 220 2-byte integer as shown in the following table. 222 Table 2: List of Attribute IDs 224 +---------------+------------+-----------------+ 225 | ID | Name | Reference | 226 +---------------+------------+-----------------+ 227 | 0 | (reserved) | | 228 | 1 | charset | RFC2045 | 229 | 2 | version | RFC2045,RFC2046 | 230 | 3 | boundary | RFC2045 | 231 | 4 | type | RFC2046 | 232 | 5 | padding | RFC2046 | 233 | 6 | msgtype | RFC2616 | 234 | 7 | filename | RFC2616 | 235 | 8 | level | RFC2616 | 236 | 0xf000-0xffff | (reserved) | | 237 +---------------+------------+-----------------+ 239 Other attribute ID may be managed and added by IANA, based on first- 240 come-first-serve basis for parameters defined in RFCs. Parameters 241 described in an internet draft or in proprietary extensions may be 242 added upon approval of core WG experts. 244 4. Security Considerations 246 Applications on CoAP servers should check the validity of parameters 247 before use. It may contain arbitrary string value. 249 5. IANA Considerations 251 This document requests a CoAP option ID assigned to Accept-CT- 252 Parameter option. 254 Attribute ID registry policy should be lined up with IANA 255 considerations of ()[#I-D.ietf-core-coap]. 257 6. Normative References 259 [I-D.doi-exi-messaging-requirements] 260 Doi, D., "EXI Messaging Requirements", 261 draft-doi-exi-messaging-requirements (work in progress), 262 October 2012. 264 [I-D.ietf-core-coap] 265 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 266 Application Protocol (CoAP)", draft-ietf-core-coap-18 267 (work in progress), June 2013. 269 [I-D.wilde-atom-profile] 270 Wilde, E., "Profile Support for the Atom Syndication 271 Format", draft-wilde-atom-profile-01 (work in progress), 272 April 2013. 274 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 275 Extensions (MIME) Part One: Format of Internet Message 276 Bodies", RFC 2045, November 1996. 278 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 279 Extensions (MIME) Part Two: Media Types", RFC 2046, 280 November 1996. 282 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 283 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 284 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 286 [RFC6295] Lazzaro, J. and J. Wawrzynek, "RTP Payload Format for 287 MIDI", RFC 6295, June 2011. 289 [W3C.Finding.alternatives-discovery] 290 Raman, T., "On Linking Alternative Representations To 291 Enable Discovery And Publishing", World Wide Web 292 Consortium Finding Finding-alternatives-discovery, 293 November 2006, . 296 [W3C.REC-exi-20110310] 297 Kamiya, T. and J. Schneider, "Efficient XML Interchange 298 (EXI) Format 1.0", World Wide Web Consortium 299 Recommendation REC-exi-20110310, March 2011, 300 . 302 Appendix A. Consideration on Compact Encodings of Content-Type 303 Parameter 305 The use of 'value' part of parameter is up to the content-type. Some 306 content-type may use non-string integer or other format to describe 307 values in compact format, e.g. TLV, fixed-length integers, etc. 309 The specification that defines a content-type may define ASCII/UTF-8 310 notation for HTTP use and binary compact notation for CoAP. Anyway, 311 CoAP software/library will not need to understand content-type 312 parameter. The parameter should be transferred from/to application 313 without modification. 315 Appendix B. ChangeLog 317 o from draft-doi-core-parameter-option-01 to 02 319 * Removed content-type parameter of message content, and this 320 draft is now for content type parameter for Accept option 322 * Added description on relation between resource and 323 representation on RESTful architecture 325 * Added even some more use cases 327 o from draft-doi-core-parameter-option-00 to 01 329 * Added more use cases 331 * Parameter format has changed and now have clearly different 332 format for content-type and accept-content-type 334 o from draft-doi-core-option-parameter-option-00 to 335 draft-doi-core-ct-parameter-option-00 337 * Effect of the option is limited to Content-Type parameter (i.e. 338 Content-Type and Accept option). 340 * Name of the option has changed to 'Content-Type Parameter 341 Option' 343 * Removed Accept: preference use case (CoAP already defines 344 accept option order as preference) 346 * Removed Option Parameter Option 2 and 3. 348 * Option Parameter Option is replaced with content-type parameter 349 option and accept content-type parameter option. 351 * Options are now considered to be proxy-safe (is it the right 352 assumption?) 354 * Some other unnecessary descriptions on option parameters (such 355 as option order constraint) are removed 357 Authors' Addresses 359 Yusuke Doi 360 TOSHIBA Corporation 361 Komukai Toshiba Cho 1 362 Saiwai-Ku 363 Kawasaki, Kanagawa 2128582 364 JAPAN 366 Phone: +81-45-342-7230 367 Email: yusuke.doi@toshiba.co.jp 369 Kerry Lynn 370 Consultant 372 Phone: +1 978 460 4253 373 Email: kerlyn@ieee.org