One document matched: draft-doi-core-parameter-option-01.txt
Differences from draft-doi-core-parameter-option-00.txt
CoRE Y. Doi
Internet-Draft TOSHIBA Corporation
Intended status: Informational K. Lynn
Expires: April 18, 2013 Consultant
October 15, 2012
CoAP Content-Type Parameter Option
draft-doi-core-parameter-option-01
Abstract
Content-Types may have 'parameter' to make fine-grained description
of contents. The CoAP Content-Type Parameter Option (CT-Parameter
Option) and Accept Content-Type Parameter Option (Accept-CT-Parameter
Option) are CoAP options to add a parameter to a Content-Type.
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 April 18, 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 & Lynn Expires April 18, 2013 [Page 1]
Internet-Draft CoAP Content-Type Parameter Option October 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Use Cases of Option Parameter in CoAP . . . . . . . . . . . . . 3
2.1. Parameter Coordination . . . . . . . . . . . . . . . . . . 3
2.2. Schema Negotiation of Schema-Informed EXI Communication . . 3
3. Content-Type Parameter Option . . . . . . . . . . . . . . . . . 4
3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Proposed Content-Type Parameter Option . . . . . . . . . . 4
3.2.1. CT-Parameter . . . . . . . . . . . . . . . . . . . . . 5
3.2.2. Accept-CT-Parameter . . . . . . . . . . . . . . . . . . 5
3.2.3. Attribute ID . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Appendix A. Consideration on Compact Encodings of
Content-Type Parameter . . . . . . . . . . . . . . . . 7
Appendix B. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Doi & Lynn Expires April 18, 2013 [Page 2]
Internet-Draft CoAP Content-Type Parameter Option October 2012
1. Introduction
Content-Type field[RFC2045] have 'parameter' to make fine-grained
description of contents. The document proposes the CoAP Content-Type
Parameter Option that enables wide range of parameter description
over content types used in CoAP.
2. Use Cases of Option Parameter in CoAP
2.1. 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.
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. In such cases, parameters with wildcard (rate=*) or range
(rate=10-20) is useful.
2.2. 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. However, there are two problems. First,
the Content-type ID space is a global space and not suitable to
describe every minor revision. Second, Content-type ID per schema
cannot describe relation between a linage of schemas. XML schema
could be backword compatible and newer schema version can be applied
on older document validation and EXI codings. Common practice on
this is to use (major).(minor) style versioning.
However, content-ID or other class of ID cannot describe which
version is compatible and which version is not compatible.
The other choice is to make use of content-type parameters. It seems
to be more acceptable because parameter is local to each content-
type. For example, an application may define 'application/
example-exi' as a content-type for the application. The application
Doi & Lynn Expires April 18, 2013 [Page 3]
Internet-Draft CoAP Content-Type Parameter Option October 2012
may use 'sv' parameter as acceptable schema version. If the
application use backword-compatible approach, 'Accept: application/
example-exi;sv=1.4' from a client means the client can receive schema
version 1.0, 1.1, 1.2, 1.3, and 1.4.
Detailed discussion on EXI schema negotiation can be found in
(#I-D.doi-exi-messaging-requirements).
3. Content-Type Parameter Option
3.1. Requirements
In general, a content-type parameter has following notations.
parameter := ";" attribute "=" value
attribute := token ; case insensitive
value := token / quoted-string
In CoAP, a content-type parameter should have similar ability of
expression with regards to use cases. At the same time, a CoAP
option should be compact enough to fit in constrained environments.
As CoAP options do not have room for parameters, the content-type
parameter option is designed to be an independent option that gives
additional description on a content-type 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.
3.2. Proposed Content-Type Parameter Option
Table 1: List of options. U: proxy-Unsafe, C: Critical, R:
Repeatable
+-----+---+---+---+---------------------+--------+--------+---------+
| No. | U | C | R | Name | Format | Length | Default |
+-----+---+---+---+---------------------+--------+--------+---------+
| TBD | | | x | CT-Parameter | (see | 2-270B | (none) |
| 1 | | | | | below) | | |
| TBD | | | x | Accept-CT-Parameter | (see | 3-270B | (none) |
| 2 | | | | | below) | | |
+-----+---+---+---+---------------------+--------+--------+---------+
Doi & Lynn Expires April 18, 2013 [Page 4]
Internet-Draft CoAP Content-Type Parameter Option October 2012
3.2.1. CT-Parameter
The CT-Parameter option is used to attach a parameter on a Content-
Type option on the same CoAP message. The CT-parameter options are
proxy safe, elective.
An CT-Parameter option has two fields: attribute ID(aid) and value.
|<-- option length ----->|
+---------+---------....-+
| aid | value |
+---------+---------....-+
|<2 Bytes>|<- optlen-2 ->|
Figure 1: Structure of CT-Parameter Option
Attribute ID (aid) is a two-byte integer that describes the attribute
name (key) of the parameter. Details are described in later section
(see Table 2).
A value is opaque octets (Unicode string in most cases) with the
length of the option length minus two (2) octets. A value may be
empty. Meanings of the values are up to the content-type.
3.2.2. Accept-CT-Parameter
The Accept-CT-Parameter option is used to attach a parameter on a
Accept option on the same CoAP message. The Accept-CT-parameter
options are proxy safe, elective.
An Accept-CT-Parameter option has three fields: option index(idx),
attribute ID(aid), and value.
|<---- option length -------->|
+----+---------+---------....-+
| idx| aid | value |
+----+---------+---------....-+
|<1B>|<2 Bytes>|<- optlen-3 ->|
:Figure 2: Structure of Accept-CT-Parameter Option
An option index is a 1-byte integer. Since a coap message may have
multiple accept options, each Accept-CT-Parameter option needs index
to the Accept option to parameterize. The index is 0-origin and less
Doi & Lynn Expires April 18, 2013 [Page 5]
Internet-Draft CoAP Content-Type Parameter Option October 2012
than the number of accept headers in the message. Index 255 is
reserved and SHOULD not be used.
For example, if a message has three Accept options, idx=0 is for the
first Accept option, idx=1 is for the second, idx=2 is for the last.
Attribute ID (aid) is a two-byte integer that describes the attribute
name (key) of the parameter. Details are described in later section
(see Table 2).
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 content-type.
3.2.3. Attribute ID
Attribute ID is a 2-byte integer. An attribute is described in
2-byte integer as shown in the following table.
Table 2: List of Attribute IDs
+-------+------------+-----------------+
| ID | Name | Reference |
+-------+------------+-----------------+
| 0 | (reserved) | |
| 1 | charset | RFC2045 |
| 2 | version | RFC2045,RFC2046 |
| 3 | boundary | RFC2045 |
| 4 | type | RFC2046 |
| 5 | padding | RFC2046 |
| 6 | msgtype | RFC2616 |
| 7 | filename | RFC2616 |
| 8 | level | RFC2616 |
| 65535 | (reserved) | |
+-------+------------+-----------------+
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.
4. Security Considerations
Applications on the CoAP should check the validity of parameters
before use. It may contain arbitrary string value.
Doi & Lynn Expires April 18, 2013 [Page 6]
Internet-Draft CoAP Content-Type Parameter Option October 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.doi-exi-messaging-requirements]
Doi, D., "EXI Messaging Requirements",
draft-doi-exi-messaging-requirements (work in progress),
October 2012.
[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.
[W3C.REC-exi-20110310]
Kamiya, T. and J. Schneider, "Efficient XML Interchange
(EXI) Format 1.0", World Wide Web Consortium
Recommendation REC-exi-20110310, March 2011,
<http://www.w3.org/TR/2011/REC-exi-20110310>.
Appendix A. Consideration on Compact Encodings of Content-Type
Parameter
The use of 'value' part of parameter is up to the content-type. Some
content-type may use non-string integer or other format to describe
values in compact format, e.g. TLV, fixed-length integers, etc.
The specification that defines a content-type may define ASCII/UTF-8
Doi & Lynn Expires April 18, 2013 [Page 7]
Internet-Draft CoAP Content-Type Parameter Option October 2012
notation for HTTP use and binary compact notation for CoAP. Anyway,
CoAP software/library will not need to understand content-type
parameter. The parameter should be transferred from/to application
without modification.
Appendix B. ChangeLog
o from draft-doi-core-option-parameter-option-00 to
draft-doi-core-ct-parameter-option-00
* Effect of the option is limited to Content-Type parameter (i.e.
Content-Type and Accept option).
* Name of the option has changed to 'Content-Type Parameter
Option'
* Removed Accept: preference use case (CoAP already defines
accept option order as preference)
* Removed Option Parameter Option 2 and 3.
* Option Parameter Option is replaced with content-type parameter
option and accept content-type parameter option.
* Options are now considered to be proxy-safe (is it the right
assumption?)
* Some other unneccessary descriptions on option parameters (such
as option order constraint) are removed
Authors' Addresses
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
Doi & Lynn Expires April 18, 2013 [Page 8]
Internet-Draft CoAP Content-Type Parameter Option October 2012
Kerry Lynn
Consultant
Phone: +1 978 460 4253
Email: kerlyn@ieee.org
Doi & Lynn Expires April 18, 2013 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-23 13:21:40 |