CoAP Content-Type Parameter OptionTOSHIBA CorporationKomukai Toshiba Cho 1Saiwai-KuKawasakiKanagawa2128582JAPAN+81-45-342-7230yusuke.doi@toshiba.co.jpConsultant+1 978 460 4253kerlyn@ieee.org
Application
CoRECoAPOptionParameter
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.
Content-Type field 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.
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
.
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 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.
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 (media type)
parameter is used to coordinate parameters between clients and
servers. audio/rtp-midi 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 also proposed in
. In the draft,
several representations can exist on a resource defined with a
URI, and a client can negotiate representation of the resource.
In some use case of Schema-Informed
EXI, 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
.
In general, a content-type parameter has following notations.
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 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.
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
TBD
x
Accept-CT-Parameter
(see below)
3-270B
(none)
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.
:Figure 2: Structure of Accept-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 should be defined by the
content-type authority.
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.
Applications on CoAP servers should check the validity of parameters
before use. It may contain arbitrary string value.
This document requests a CoAP option ID assigned to
Accept-CT-Parameter option.
Attribute ID registry policy should be lined up with IANA
considerations of ()[#I-D.ietf-core-coap].
Efficient XML Interchange (EXI) Format 1.0Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message BodiesInnosoft International, Inc.1050 East Garvey Avenue SouthWest CovinaCA91790US+1 818 919 3600+1 818 919 3614ned@innosoft.comFirst Virtual Holdings25 Washington AvenueMorristownNJ07960US+1 201 540 8967+1 201 993 3032nsb@nsb.fv.comSTD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for(1) textual message bodies in character sets other than US-ASCII,(2) an extensible set of different formats for non-textual message bodies,(3) multi-part message bodies, and(4) textual header information in character sets other than US-ASCII.These documents are based on earlier work documented in RFC 934, STD 11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822.This initial document specifies the various headers used to describe the structure of MIME messages. The second document, RFC 2046, defines the general structure of the MIME media typing system and defines an initial set of media types. The third document, RFC 2047, describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields. The fourth document, RFC 2048, specifies various IANA registration procedures for MIME-related facilities. The fifth and final document, RFC 2049, describes MIME conformance
criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography.These documents are revisions of RFCs 1521, 1522, and 1590, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC 2049 describes differences and changes from previous versions.Multipurpose Internet Mail Extensions (MIME) Part Two: Media TypesInnosoft International, Inc.1050 East Garvey Avenue SouthWest CovinaCA91790US+1 818 919 3600+1 818 919 3614ned@innosoft.comFirst Virtual Holdings25 Washington AvenueMorristownNJ07960US+1 201 540 8967+1 201 993 3032nsb@nsb.fv.comSTD 11, RFC 822 defines a message representation protocol specifying considerable detail about US-ASCII message headers, but which leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for(1) textual message bodies in character sets other than US-ASCII,(2) an extensible set of different formats for non-textual message bodies,(3) multi-part message bodies, and(4) textual header information in character sets other than US-ASCII.These documents are based on earlier work documented in RFC 934, STD 11 and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822.The initial document in this set, RFC 2045, specifies the various headers used to describe the structure of MIME messages. This second document defines the general structure of the MIME media typing sytem and defines an initial set of media types. The third document, RFC 2047, describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields. The fourth document, RFC 2048, specifies various IANA registration procedures for MIME-related facilities. The fifth and final document, RFC 2049, describes MIME
conformance criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography.These documents are revisions of RFCs 1521 and 1522, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC 2049 describes differences and changes from previous versions.Hypertext Transfer Protocol -- HTTP/1.1Department of Information and Computer ScienceUniversity of California, IrvineIrvineCA92697-3425+1(949)824-1715fielding@ics.uci.eduWorld Wide Web ConsortiumMIT Laboratory for Computer Science, NE43-356545 Technology SquareCambridgeMA02139+1(617)258-8682jg@w3.orgCompaq Computer CorporationWestern Research Laboratory250 University AvenuePalo AltoCA94305mogul@wrl.dec.comWorld Wide Web ConsortiumMIT Laboratory for Computer Science, NE43-356545 Technology SquareCambridgeMA02139+1(617)258-8682frystyk@w3.orgXerox CorporationMIT Laboratory for Computer Science, NE43-3563333 Coyote Hill RoadPalo AltoCA94034masinter@parc.xerox.comMicrosoft Corporation1 Microsoft WayRedmondWA98052paulle@microsoft.comWorld Wide Web ConsortiumMIT Laboratory for Computer Science, NE43-356545 Technology SquareCambridgeMA02139+1(617)258-8682timbl@w3.org
The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information
systems. It is a generic, stateless, protocol which can be used for
many tasks beyond its use for hypertext, such as name servers and
distributed object management systems, through extension of its
request methods, error codes and headers . A feature of HTTP is
the typing and negotiation of data representation, allowing systems
to be built independently of the data being transferred.
HTTP has been in use by the World-Wide Web global information
initiative since 1990. This specification defines the protocol
referred to as "HTTP/1.1", and is an update to RFC 2068 .
RTP Payload Format for MIDIThis memo describes a Real-time Transport Protocol (RTP) payload format for the MIDI (Musical Instrument Digital Interface) command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as network musical performance) and content-delivery applications (such as file streaming). The format may be used over unicast and multicast UDP and TCP, and it defines tools for graceful recovery from packet loss. Stream behavior, including the MIDI rendering method, may be customized during session setup. The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds Level 2, and Structured Audio. This document obsoletes RFC 4695. [STANDARDS-TRACK]Constrained Application Protocol (CoAP)The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as 6LoWPAN often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine-to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead and simplicity for constrained environments.EXI Messaging RequirementsT
EXI (Efficient XML Interchange) is a specification on
efficient encoding of XML. EXI is useful if an application requires
XML based message exchange but no sufficient resource is available.
However, schema-informed mode of EXI
needs some out-of-band coordination between communicating nodes.
This
document discusses requirement on use of schema-informed EXI
as a message exchange format on the Internet systems.
Profile Support for the Atom Syndication FormatThe Atom syndication format is a generic XML format for representing collections. Profiles are one way how Atom feeds can indicate that they support specific extensions. To make this support visible on the media type level, this specification re-registers the Atom media type, and adds a "profile" media type parameter. This allows profiles to become visible at the media type level, so that servers as well as clients can indicate support for specific Atom profiles in conversations, for example when communicating via HTTP.On Linking Alternative Representations To Enable Discovery And Publishing
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.
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
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
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 unnecessary descriptions on option parameters
(such as option order constraint) are removed