One document matched: draft-doi-core-parameter-option-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 02:40:26 |