Skip to main content

CoAP Content-Type Parameter Option
draft-doi-core-parameter-option-02

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Yusuke Doi , Kerry Lynn
Last updated 2013-07-15
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-doi-core-parameter-option-02
CoRE                                                              Y. Doi
Internet-Draft                                       TOSHIBA Corporation
Intended status: Informational                                   K. Lynn
Expires: January 17, 2014                                     Consultant
                                                           July 16, 2013

                   CoAP Content-Type Parameter Option
                   draft-doi-core-parameter-option-02

Abstract

   Content-Types may have 'parameter' to make fine-grained description
   of contents.  The CoAP Accept Content-Type Parameter Option (Accept-
   CT-Parameter Option) is CoAP options to add a parameter to a content
   type specified in CoAP Accept Options.

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 January 17, 2014.

Copyright Notice

   Copyright (c) 2013 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 January 17, 2014                [Page 1]
Internet-Draft     CoAP Content-Type Parameter Option          July 2013

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Use Cases of Option Parameter in CoAP . . . . . . . . . . . . . 3
     2.1.  Clarification on URI, Resource, and Representation  . . . . 3
     2.2.  Parameter Coordination  . . . . . . . . . . . . . . . . . . 3
     2.3.  Schema Negotiation of Schema-Informed EXI Communication . . 4
   3.  Accept Content-Type Parameter Option  . . . . . . . . . . . . . 4
     3.1.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . 4
     3.2.  Accept-CT-Parameter Option  . . . . . . . . . . . . . . . . 5
       3.2.1.  Attribute ID  . . . . . . . . . . . . . . . . . . . . . 6
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   6.  Normative References  . . . . . . . . . . . . . . . . . . . . . 7
   Appendix A.  Consideration on Compact Encodings of
                Content-Type Parameter . . . . . . . . . . . . . . . . 8
   Appendix B.  ChangeLog  . . . . . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9

Doi & Lynn              Expires January 17, 2014                [Page 2]
Internet-Draft     CoAP Content-Type Parameter Option          July 2013

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.  Clarification on URI, Resource, and Representation

   In CoAP, a resource is specified by a CoAP URI.  However, in some use
   cases described in followings, an URI may correspond to multiple
   versions of the resource, or a resource may have multiple
   representations.  As best practices, there are several ways to
   identify a version and a representation on a resource pointed by an
   URI.  Some of discussions are given in
   [W3C.Finding.alternatives-discovery].

   One of the approaches commonly used is to parameterize contents with
   content-type parameter and make a server-side content negotiation.

   Basic specification of CoAP[I-D.ietf-core-coap] does not cover such
   content negotiation and this draft is to propose a way to mimic
   server-side content negotiation by making room for content type
   parameters with a new option.

2.2.  Parameter Coordination

   If a resource has wide range of representations, a client may try to
   specify what representation of the resource is requested by a GET
   message.  In HTTP, Accept: header and content type parameter is used
   to coordinate parameters between clients and servers. 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.

   Similar parameter coordination is discussed in
   [I-D.wilde-atom-profile].  In the draft, several representations can
   exist on a resource defined with a URI, and a client can negotiate
   representation of the resource.

Doi & Lynn              Expires January 17, 2014                [Page 3]
Internet-Draft     CoAP Content-Type Parameter Option          July 2013

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.  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 backward compatible and newer schema version can be applied
   on older document validation and EXI encoding.  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
   may use 'sv' parameter as acceptable schema version.  If the
   application use backward-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.  Accept 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

Doi & Lynn              Expires January 17, 2014                [Page 4]
Internet-Draft     CoAP Content-Type Parameter Option          July 2013

   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 authors consider 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.  Accept-CT-Parameter Option

   To enable server-side content type negotiation, an option to describe
   content type parameter is required.  This document defines Accept-CT-
   Parameter option for the purpose.

   Table 1: List of options.  U: proxy-Unsafe, C: Critical, R:
   Repeatable

   +----+---+---+---+---+------------------+--------+--------+---------+
   | No | C | U | N | R |       Name       | Format | Length | Default |
   | .  |   |   |   |   |                  |        |        |         |
   +----+---+---+---+---+------------------+--------+--------+---------+
   | TB |   |   |   | x | Accept-CT-Parame |  (see  | 3-270B | (none)  |
   | D  |   |   |   |   |        ter       | below) |        |         |
   +----+---+---+---+---+------------------+--------+--------+---------+

   The Accept-CT-Parameter option is used to attach a parameter on an
   Accept option on the same CoAP message.  The Accept-CT-parameter
   options are proxy safe, elective.

   An Accept-CT-Parameter option has two fields: attribute ID(aid), and
   value.

   |<--- option length ---->|

   +---------+---------....-+
   |   aid   | value        |
   +---------+---------....-+

   |<2 Bytes>|<- optlen-2 ->|

   :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
   than the number of accept headers in the message.  Index 255 is

Doi & Lynn              Expires January 17, 2014                [Page 5]
Internet-Draft     CoAP Content-Type Parameter Option          July 2013

   reserved and SHOULD NOT be used.

   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.1.  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         |
             | 0xf000-0xffff | (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 CoAP servers should check the validity of parameters
   before use.  It may contain arbitrary string value.

5.  IANA Considerations

   This document requests a CoAP option ID assigned to Accept-CT-
   Parameter option.

Doi & Lynn              Expires January 17, 2014                [Page 6]
Internet-Draft     CoAP Content-Type Parameter Option          July 2013

   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., and C. Bormann, "Constrained
              Application Protocol (CoAP)", draft-ietf-core-coap-18
              (work in progress), June 2013.

   [I-D.wilde-atom-profile]
              Wilde, E., "Profile Support for the Atom Syndication
              Format", draft-wilde-atom-profile-01 (work in progress),
              April 2013.

   [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.Finding.alternatives-discovery]
              Raman, T., "On Linking Alternative Representations To
              Enable Discovery And Publishing", World Wide Web
              Consortium Finding Finding-alternatives-discovery,
              November 2006, <http://www.w3.org/2001/tag/doc/
              alternatives-discovery.html>.

   [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>.

Doi & Lynn              Expires January 17, 2014                [Page 7]
Internet-Draft     CoAP Content-Type Parameter Option          July 2013

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
   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-parameter-option-01 to 02

      *  Removed content-type parameter of message content, and this
         draft is now for content type parameter for Accept option

      *  Added description on relation between resource and
         representation on RESTful architecture

      *  Added even some more use cases

   o  from draft-doi-core-parameter-option-00 to 01

      *  Added more use cases

      *  Parameter format has changed and now have clearly different
         format for content-type and accept-content-type

   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.

Doi & Lynn              Expires January 17, 2014                [Page 8]
Internet-Draft     CoAP Content-Type Parameter Option          July 2013

      *  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 unnecessary 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

   Kerry Lynn
   Consultant

   Phone: +1 978 460 4253
   Email: kerlyn@ieee.org

Doi & Lynn              Expires January 17, 2014                [Page 9]