One document matched: draft-doi-core-parameter-option-03.xml
<?xml version="1.0" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc ipr="trust200902" category="info" docName="draft-doi-core-parameter-option-03">
<?rfc toc="yes"?> <!-- generate a table of contents -->
<?rfc symrefs="yes"?> <!-- use anchors instead of numbers for references -->
<?rfc sortrefs="yes" ?> <!-- alphabetize the references -->
<?rfc compact="yes" ?> <!-- conserve vertical whitespace -->
<?rfc subcompact="no" ?> <!-- but keep a blank line between list items -->
<front>
<title abbrev="CoAP Content-Type Parameter Option">CoAP Content-Type Parameter Option</title>
<author initials="Y." surname="Doi"
fullname="Yusuke Doi">
<organization>TOSHIBA Corporation</organization>
<address>
<postal>
<street>Komukai Toshiba Cho 1</street>
<street>Saiwai-Ku</street>
<city>Kawasaki</city> <region>Kanagawa</region>
<code>2128582</code>
<country>JAPAN</country>
</postal>
<phone>+81-45-342-7230</phone>
<email>yusuke.doi@toshiba.co.jp</email>
<!-- uri>http://www.toshiba.co.jp</uri -->
</address>
</author>
<author initials="K." surname="Lynn"
fullname="Kerry Lynn">
<organization>Consultant</organization>
<address>
<phone>+1 978 460 4253</phone>
<email>kerlyn@ieee.org</email>
</address>
</author>
<date month="August" year="2013"/>
<area>Application</area>
<workgroup>CoRE</workgroup>
<keyword>CoAP</keyword>
<keyword>Option</keyword>
<keyword>Parameter</keyword>
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<!-- This document was prepared using Pandoc2rfc -->
<!-- https://github.com/miekg/pandoc2rfc -->
<section title="Introduction" anchor="introduction">
<t>
Content-Type field<xref target="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.
</t>
</section>
<section title="Use Cases of Option Parameter in CoAP" anchor="use-cases-of-option-parameter-in-coap">
<section title="Clarification on URI, Resource, and Representation" anchor="clarification-on-uri-resource-and-representation">
<t>
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
<xref target="W3C.Finding.alternatives-discovery"/>.
</t>
<t>
One of the approaches commonly used is to parameterize contents
with content-type parameter and make a server-side content
negotiation.
</t>
<t>
Basic specification of
CoAP<xref target="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.
</t>
</section>
<section title="Parameter Coordination" anchor="parameter-coordination">
<t>
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<xref target="RFC6295"/> is an
example of a content-type with various parameters.
</t>
<t>
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.
</t>
<t>
Similar parameter coordination is also proposed in
<xref target="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.
</t>
</section>
<section title="Schema Negotiation of Schema-Informed EXI Communication" anchor="schema-negotiation-of-schema-informed-exi-communication">
<t>
In some use case of Schema-Informed
<xref target="W3C.REC-exi-20110310">EXI</xref>, 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.
</t>
<t>
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.
</t>
<t>
However, content-ID or other class of ID cannot describe which
version is compatible and which version is not compatible.
</t>
<t>
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.
</t>
<t>
Detailed discussion on EXI schema negotiation can be found in
<xref target="I-D.doi-exi-messaging-requirements"/>.
</t>
</section>
</section>
<section title="Accept Content-Type Parameter Option" anchor="accept-content-type-parameter-option">
<section title="Requirements" anchor="requirements">
<t>
In general, a content-type parameter has following notations.
</t>
<figure><artwork>
parameter := ";" attribute "=" value
attribute := token ; case insensitive
value := token / quoted-string
</artwork></figure>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="Accept-CT-Parameter Option" anchor="accept-ct-parameter-option">
<t>
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.
</t>
<t>
Table 1: List of options. U: proxy-Unsafe, C: Critical, R:
Repeatable
</t>
<texttable>
<ttcol align="left">
No.
</ttcol>
<ttcol align="left">
C
</ttcol>
<ttcol align="left">
U
</ttcol>
<ttcol align="left">
N
</ttcol>
<ttcol align="left">
R
</ttcol>
<ttcol align="center">
Name
</ttcol>
<ttcol align="center">
Format
</ttcol>
<ttcol align="left">
Length
</ttcol>
<ttcol>
Default
</ttcol>
<c>
TBD
</c>
<c>
</c>
<c>
</c>
<c>
</c>
<c>
x
</c>
<c>
Accept-CT-Parameter
</c>
<c>
(see below)
</c>
<c>
3-270B
</c>
<c>
(none)
</c>
</texttable>
<t>
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.
</t>
<t>
An Accept-CT-Parameter option has two fields: attribute ID(aid),
and value.
</t>
<figure><artwork>
|<--- option length ---->|
+---------+---------....-+
| aid | value |
+---------+---------....-+
|<2 Bytes>|<- optlen-2 ->|
</artwork></figure>
<t>
:Figure 2: Structure of Accept-CT-Parameter Option
</t>
<t>
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).
</t>
<t>
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.
</t>
<section title="Attribute ID" anchor="attribute-id">
<t>
Attribute ID is a 2-byte integer. An attribute is described in
2-byte integer as shown in the following table.
</t>
<t>
Table 2: List of Attribute IDs
</t>
<texttable>
<ttcol align="left">
ID
</ttcol>
<ttcol align="left">
Name
</ttcol>
<ttcol align="left">
Reference
</ttcol>
<c>
0
</c>
<c>
(reserved)
</c>
<c>
</c>
<c>
1
</c>
<c>
charset
</c>
<c>
RFC2045
</c>
<c>
2
</c>
<c>
version
</c>
<c>
RFC2045,RFC2046
</c>
<c>
3
</c>
<c>
boundary
</c>
<c>
RFC2045
</c>
<c>
4
</c>
<c>
type
</c>
<c>
RFC2046
</c>
<c>
5
</c>
<c>
padding
</c>
<c>
RFC2046
</c>
<c>
6
</c>
<c>
msgtype
</c>
<c>
RFC2616
</c>
<c>
7
</c>
<c>
filename
</c>
<c>
RFC2616
</c>
<c>
8
</c>
<c>
level
</c>
<c>
RFC2616
</c>
<c>
0xf000-0xffff
</c>
<c>
(reserved)
</c>
<c>
</c>
</texttable>
<t>
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.
</t>
</section>
</section>
</section>
<section title="Security Considerations" anchor="security-considerations">
<t>
Applications on CoAP servers should check the validity of parameters
before use. It may contain arbitrary string value.
</t>
</section>
<section title="IANA Considerations" anchor="iana-considerations">
<t>
This document requests a CoAP option ID assigned to
Accept-CT-Parameter option.
</t>
<t>
Attribute ID registry policy should be lined up with IANA
considerations of ()[#I-D.ietf-core-coap].
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?xml version='1.0' encoding='UTF-8'?>
<reference anchor='W3C.REC-exi-20110310'
target='http://www.w3.org/TR/2011/REC-exi-20110310'>
<front>
<title>Efficient XML Interchange (EXI) Format 1.0</title>
<author initials='T.' surname='Kamiya' fullname='Takuki Kamiya'>
<organization />
</author>
<author initials='J.' surname='Schneider' fullname='John Schneider'>
<organization />
</author>
<date month='March' day='10' year='2011' />
</front>
<seriesInfo name='World Wide Web Consortium Recommendation' value='REC-exi-20110310' />
<format type='HTML' target='http://www.w3.org/TR/2011/REC-exi-20110310' />
</reference>
<?xml version='1.0' encoding='UTF-8'?>
<reference anchor='RFC2045'>
<front>
<title abbrev='Internet Message Bodies'>Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</title>
<author initials='N.' surname='Freed' fullname='Ned Freed'>
<organization>Innosoft International, Inc.</organization>
<address>
<postal>
<street>1050 East Garvey Avenue South</street>
<city>West Covina</city>
<region>CA</region>
<code>91790</code>
<country>US</country></postal>
<phone>+1 818 919 3600</phone>
<facsimile>+1 818 919 3614</facsimile>
<email>ned@innosoft.com</email></address></author>
<author initials='N.S.' surname='Borenstein' fullname='Nathaniel S. Borenstein'>
<organization>First Virtual Holdings</organization>
<address>
<postal>
<street>25 Washington Avenue</street>
<city>Morristown</city>
<region>NJ</region>
<code>07960</code>
<country>US</country></postal>
<phone>+1 201 540 8967</phone>
<facsimile>+1 201 993 3032</facsimile>
<email>nsb@nsb.fv.com</email></address></author>
<date year='1996' month='November' />
<abstract>
<t>STD 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</t>
<t>(1) textual message bodies in character sets other than US-ASCII,</t>
<t>(2) an extensible set of different formats for non-textual message bodies,</t>
<t>(3) multi-part message bodies, and</t>
<t>(4) textual header information in character sets other than US-ASCII.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t></abstract></front>
<seriesInfo name='RFC' value='2045' />
<format type='TXT' octets='72932' target='http://www.rfc-editor.org/rfc/rfc2045.txt' />
</reference>
<?xml version='1.0' encoding='UTF-8'?>
<reference anchor='RFC2046'>
<front>
<title abbrev='Media Types'>Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</title>
<author initials='N.' surname='Freed' fullname='Ned Freed'>
<organization>Innosoft International, Inc.</organization>
<address>
<postal>
<street>1050 East Garvey Avenue South</street>
<city>West Covina</city>
<region>CA</region>
<code>91790</code>
<country>US</country></postal>
<phone>+1 818 919 3600</phone>
<facsimile>+1 818 919 3614</facsimile>
<email>ned@innosoft.com</email></address></author>
<author initials='N.' surname='Borenstein' fullname='Nathaniel S. Borenstein'>
<organization>First Virtual Holdings</organization>
<address>
<postal>
<street>25 Washington Avenue</street>
<city>Morristown</city>
<region>NJ</region>
<code>07960</code>
<country>US</country></postal>
<phone>+1 201 540 8967</phone>
<facsimile>+1 201 993 3032</facsimile>
<email>nsb@nsb.fv.com</email></address></author>
<date year='1996' month='November' />
<abstract>
<t>STD 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</t>
<t>(1) textual message bodies in character sets other than US-ASCII,</t>
<t>(2) an extensible set of different formats for non-textual message bodies,</t>
<t>(3) multi-part message bodies, and</t>
<t>(4) textual header information in character sets other than US-ASCII.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t></abstract></front>
<seriesInfo name='RFC' value='2046' />
<format type='TXT' octets='105854' target='http://www.rfc-editor.org/rfc/rfc2046.txt' />
</reference>
<?xml version='1.0' encoding='UTF-8'?>
<reference anchor='RFC2616'>
<front>
<title abbrev='HTTP/1.1'>Hypertext Transfer Protocol -- HTTP/1.1</title>
<author initials='R.' surname='Fielding' fullname='Roy T. Fielding'>
<organization abbrev='UC Irvine'>Department of Information and Computer Science</organization>
<address>
<postal>
<street>University of California, Irvine</street>
<city>Irvine</city>
<region>CA</region>
<code>92697-3425</code></postal>
<facsimile>+1(949)824-1715</facsimile>
<email>fielding@ics.uci.edu</email></address></author>
<author initials='J.' surname='Gettys' fullname='James Gettys'>
<organization abbrev='Compaq/W3C'>World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>jg@w3.org</email></address></author>
<author initials='J.' surname='Mogul' fullname='Jeffrey C. Mogul'>
<organization abbrev='Compaq'>Compaq Computer Corporation</organization>
<address>
<postal>
<street>Western Research Laboratory</street>
<street>250 University Avenue</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94305</code></postal>
<email>mogul@wrl.dec.com</email></address></author>
<author initials='H.' surname='Frystyk' fullname='Henrik Frystyk Nielsen'>
<organization abbrev='W3C/MIT'>World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>frystyk@w3.org</email></address></author>
<author initials='L.' surname='Masinter' fullname='Larry Masinter'>
<organization abbrev='Xerox'>Xerox Corporation</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94034</code></postal>
<email>masinter@parc.xerox.com</email></address></author>
<author initials='P.' surname='Leach' fullname='Paul J. Leach'>
<organization abbrev='Microsoft'>Microsoft Corporation</organization>
<address>
<postal>
<street>1 Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code></postal>
<email>paulle@microsoft.com</email></address></author>
<author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'>
<organization abbrev='W3C/MIT'>World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>timbl@w3.org</email></address></author>
<date year='1999' month='June' />
<abstract>
<t>
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.
</t>
<t>
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 .
</t></abstract></front>
<seriesInfo name='RFC' value='2616' />
<format type='TXT' octets='422317' target='http://www.rfc-editor.org/rfc/rfc2616.txt' />
<format type='PS' octets='5529857' target='http://www.rfc-editor.org/rfc/rfc2616.ps' />
<format type='PDF' octets='550558' target='http://www.rfc-editor.org/rfc/rfc2616.pdf' />
<format type='HTML' octets='636125' target='http://xml.resource.org/public/rfc/html/rfc2616.html' />
<format type='XML' octets='493420' target='http://xml.resource.org/public/rfc/xml/rfc2616.xml' />
</reference>
<?xml version='1.0' encoding='UTF-8'?>
<reference anchor='RFC6295'>
<front>
<title>RTP Payload Format for MIDI</title>
<author initials='J.' surname='Lazzaro' fullname='J. Lazzaro'>
<organization /></author>
<author initials='J.' surname='Wawrzynek' fullname='J. Wawrzynek'>
<organization /></author>
<date year='2011' month='June' />
<abstract>
<t>This 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]</t></abstract></front>
<seriesInfo name='RFC' value='6295' />
<format type='TXT' octets='409730' target='http://www.rfc-editor.org/rfc/rfc6295.txt' />
</reference>
<?xml version='1.0' encoding='UTF-8'?>
<reference anchor='I-D.ietf-core-coap'>
<front>
<title>Constrained Application Protocol (CoAP)</title>
<author initials='Z' surname='Shelby' fullname='Zach Shelby'>
<organization />
</author>
<author initials='K' surname='Hartke' fullname='Klaus Hartke'>
<organization />
</author>
<author initials='C' surname='Bormann' fullname='Carsten Bormann'>
<organization />
</author>
<date month='June' day='28' year='2013' />
<abstract><t>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.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-core-coap-18' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-core-coap-18.txt' />
</reference>
<?xml version='1.0' encoding='UTF-8'?>
<reference anchor='I-D.doi-exi-messaging-requirements'>
<front>
<title>EXI Messaging Requirements</title>
<author initials='D' surname='Doi' fullname='Yusuke Doi'>
<organization />
</author>
<date month='October' day='12' year='2012' />
<abstract><t>T
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.
</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-doi-exi-messaging-requirements' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-doi-exi-messaging-requirements-00.txt' />
</reference>
<?xml version="1.0" encoding="UTF-8"?>
<reference anchor="I-D.wilde-atom-profile">
<front>
<title>Profile Support for the Atom Syndication Format</title>
<author initials="E" surname="Wilde" fullname="Erik Wilde">
<organization/>
</author>
<date month="April" day="26" year="2013"/>
<abstract><t>The 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.</t></abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-wilde-atom-profile-01"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-wilde-atom-profile-01.txt"/>
</reference><?xml version='1.0' encoding='UTF-8'?>
<reference anchor='W3C.Finding.alternatives-discovery'
target='http://www.w3.org/2001/tag/doc/alternatives-discovery.html'>
<front>
<title>On Linking Alternative Representations To Enable Discovery And Publishing</title>
<author initials='T.' surname='Raman' fullname='T. V. Raman'>
<organization />
</author>
<date month='November' day='1' year='2006' />
</front>
<seriesInfo name='World Wide Web Consortium Finding' value='Finding-alternatives-discovery' />
<format type='HTML' target='http://www.w3.org/2001/tag/doc/alternatives-discovery.html#id2261672' />
</reference>
</references>
<!-- This document was prepared using Pandoc2rfc -->
<!-- https://github.com/miekg/pandoc2rfc -->
<section title="Consideration on Compact Encodings of Content-Type Parameter" anchor="consideration-on-compact-encodings-of-content-type-parameter">
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="ChangeLog" anchor="changelog">
<t><list style="symbols">
<t>
from draft-doi-core-parameter-option-01 to 02
<list style="symbols">
<t>
Removed content-type parameter of message content, and this
draft is now for content type parameter for Accept option
</t>
<t>
Added description on relation between resource and
representation on RESTful architecture
</t>
<t>
Added even some more use cases
</t>
</list>
</t>
<t>
from draft-doi-core-parameter-option-00 to 01
<list style="symbols">
<t>
Added more use cases
</t>
<t>
Parameter format has changed and now have clearly different
format for content-type and accept-content-type
</t>
</list>
</t>
<t>
from draft-doi-core-option-parameter-option-00 to
draft-doi-core-ct-parameter-option-00
<list style="symbols">
<t>
Effect of the option is limited to Content-Type parameter
(i.e. Content-Type and Accept option).
</t>
<t>
Name of the option has changed to 'Content-Type Parameter
Option'
</t>
<t>
Removed Accept: preference use case (CoAP already defines
accept option order as preference)
</t>
<t>
Removed Option Parameter Option 2 and 3.
</t>
<t>
Option Parameter Option is replaced with content-type
parameter option and accept content-type parameter option.
</t>
<t>
Options are now considered to be proxy-safe (is it the right
assumption?)
</t>
<t>
Some other unnecessary descriptions on option parameters
(such as option order constraint) are removed
</t>
</list>
</t>
</list></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:06:01 |