CoRE Y. Doi Internet-Draft TOSHIBA Corporation Intended status: Informational August 22, 2012 Expires: February 23, 2013 CoAP Option Parameter Option draft-doi-core-parameter-option-00 Abstract Content-Type and some HTTP headers have 'parameter' to make fine- grained description of contents and options. The CoAP Option Parameter Option is a CoAP option to add a parameter to a CoAP option. 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 February 23, 2013. Copyright Notice Copyright (c) 2012 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. Doi Expires February 23, 2013 [Page 1] Internet-Draft CoAP Option Parameter Option August 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Use Cases of Option Parameter in CoAP . . . . . . . . . . . . . 3 2.1. Additional Content Negotiation . . . . . . . . . . . . . . 3 2.2. Parameter Coordination . . . . . . . . . . . . . . . . . . 3 2.3. Schema Negotiation of Schema-Informed EXI Communication . . 4 3. Option Parameter Option . . . . . . . . . . . . . . . . . . . . 4 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Proposed Option Parameter Option . . . . . . . . . . . . . 5 3.2.1. Option-Parameter1, 2, 3 . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 6. Normative References . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Doi Expires February 23, 2013 [Page 2] Internet-Draft CoAP Option Parameter Option August 2012 1. Introduction Content-Type field[RFC2045] and some HTTP headers[RFC2616] have 'parameter' to make fine-grained description of contents and options. The document proposes the CoAP Option Parameter Option that enables wide range of parameter description over CoAP options. 2. Use Cases of Option Parameter in CoAP 2.1. Additional Content Negotiation [RFC2616] describes several use cases of parameters. An example is use of Accept: headers defined in section 14.1. If a node has preference of encodings, use of 'q=' parameter with other content type parameters is recommended to declare content type preference in Accept headers. A constrained data collector may have its preference in its acceptance data format. A case is (SenML)[#I-D.jennings-senml-09] data receiver that supports both JSON and EXI. With preference for EXI format, the accept line of the node in HTTP GET request may be as the followings. Accept: senml-exi, senml+json;q=0.8 2.2. Parameter Coordination If a content-type have wide variety of parameters, a node need to know which parameter is acceptable or not via Accept: header. audio/ rtp-midi[RFC6295] is an example of a content-type with various parameters. A constrained client is able to create payloads with specific rate=32500. A server accepts any rate of audio/rtp-midi and it can receive 'audio/rtp-midi;rate=*'. The client posts a payload Content- Type with 'audio/rtp-midi;rate=32500'. The server may need to check if the content type of posted payload matches the expected content- type. The audio use case seems not to be widely used in CoAP so far. However, the same use case is applicable for sensor data. Sensor data is time series data and it is possible to define a content type with preferred sensing interval to avoid over/underquality of sampling. Doi Expires February 23, 2013 [Page 3] Internet-Draft CoAP Option Parameter Option August 2012 2.3. Schema Negotiation of Schema-Informed EXI Communication In some use case of Schema-Informed (EXI)[#W3C.REC-exi-20110310], a server and a client need to coordinate a XML schema to encode a message. If there are some versions of XML schemas in an application, a sender (may be server or client) needs to know schemas a receiver has. There are two choices. First choice is to define a content-type for each version of XML schema. But this is not widely acceptable. Content-type is a global space and not suitable to describe every minor revision. Second choice is make use of content-type parameters. It seems to be more acceptable because parameter is local to its options or content- types. 3. Option Parameter Option 3.1. Requirements In general, an option parameter has following notations. parameter := ";" attribute "=" value attribute := token ; case insensitive value := token / quoted-string In CoAP, an option parameter should have similar ability of expression with regards to some use cases. At the same time, CoAP option should be compact enough to fit in constrained environments. As CoAP options do not have room for parameters, the option parameter option is designed to be an independent option that gives additional description on another option in a CoAP message. An attribute of CoAP option parameter should be fit in relatively smaller set. The author considers the attribute part could be described in short integer (16 bits). On the other hand, the value part should have higher degree of freedom for applications including wildcards and range description. The author believes it is simple and safe to have a string value in option parameter option. Doi Expires February 23, 2013 [Page 4] Internet-Draft CoAP Option Parameter Option August 2012 3.2. Proposed Option Parameter Option +------+---+---+---+-------------------+---------+--------+---------+ | No. | U | C | R | Name | Format | Length | Default | +------+---+---+---+-------------------+---------+--------+---------+ | TBD1 | x | | x | Option-Parameter1 | (see | 3-270B | (none) | | | | | | | below) | | | | TBD2 | x | | x | Option-Parameter2 | (see | 3-270B | (none) | | | | | | | below) | | | | TBD3 | x | | x | Option-Parameter3 | (see | 3-270B | (none) | | | | | | | below) | | | +------+---+---+---+-------------------+---------+--------+---------+ Table 1: List of options. U: proxy-Unsafe, C: Critical, R: Repeatable 3.2.1. Option-Parameter1, 2, 3 The Option-Parameter options are used to attach a parameter on an option on the same CoAP message. The option-parameter options are proxy unsafe, elective. An Option-Parameter option has three fields: option index(oidx), attribute ID(aid), and value. |<---- option length -------->| +----+---------+---------....-+ |oidx| aid | value | +----+---------+---------....-+ |<1B>|<2 Bytes>|<- optlen-3 ->| Figure 1: Structure of Option Parameter Options An option index is a 1-byte integer. If an Option-Parameter has option index 3, the parameter is for 4th option in the header (0-origin). Option index 255 is reserved. Parameter assignment for 255th or further in option index is not defined in this document. A parameter option SHOULD NOT be attached to another parameter option. If proxy or other intermediate nodes add/remove options of an existing message, the node SHALL update option index of option parameter options accordingly, or parameter options SHALL be dropped from the message. Attribute ID is a 2-byte integer. An attribute is described in 2-byte integer as shown in the following table. Doi Expires February 23, 2013 [Page 5] Internet-Draft CoAP Option Parameter Option August 2012 +-------+------------+-----------------+ | ID | Name | Reference | +-------+------------+-----------------+ | 0 | (reserved) | | | 1 | charset | RFC2045 | | 2 | version | RFC2045,RFC2046 | | 3 | boundary | RFC2045 | | 4 | type | RFC2046 | | 5 | padding | RFC2046 | | 6 | q | RFC2616 | | 7 | msgtype | RFC2616 | | 8 | filename | RFC2616 | | 9 | level | RFC2616 | | 65535 | (reserved) | | +-------+------------+-----------------+ Table 2: List of Attribute IDs Other attribute ID may be managed and added by IANA, based on first- come-first-serve basis for parameters defined in RFCs. Parameters described in an internet draft or in proprietary extensions may be added upon approval of core WG experts. A value is opaque octets (Unicode string in most cases) with the length of the option length minus three (3) octets. A value may be empty. Meanings of the values are up to the option or the content- type. Since the option parameter option use index of option order, adding parameter option after building up other options may cause unnecessary implementation complexity. To avoid it, there are three options per option number regions. The Option-Parameter1 is for option number 0-(TBD1-1). The Option Parameter2 is for option number (TBD1+1)-(TBD2-1). The Option Parameter3 is for option number (TBD2+ 1)-65535. Note that options with option number (TBD3+1) to 65535 needs careful calculation of option index, because option parameter options should be inserted before the options with the option numbers. Proposed option numbers for TBD1, TBD2, TBD3 are 253, 2045, and 65533. 4. Security Considerations Applications on the CoAP should check the validity of parameters before use. It may contain arbitrary string value. Doi Expires February 23, 2013 [Page 6] Internet-Draft CoAP Option Parameter Option August 2012 5. IANA Considerations Attribute ID registry policy should be lined up with IANA considerations of [#I-D.ietf-core-coap]. 6. Normative References [I-D.ietf-core-coap] Shelby, Z., Hartke, K., Bormann, C., and B. Frank, "Constrained Application Protocol (CoAP)", draft-ietf-core-coap-11 (work in progress), July 2012. [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC6295] Lazzaro, J. and J. Wawrzynek, "RTP Payload Format for MIDI", RFC 6295, June 2011. Author's Address Yusuke Doi TOSHIBA Corporation Komukai Toshiba Cho 1 Saiwai-Ku Kawasaki, Kanagawa 2128582 JAPAN Phone: +81-45-342-7230 Email: yusuke.doi@toshiba.co.jp URI: Doi Expires February 23, 2013 [Page 7]