One document matched: draft-bormann-coap-misc-05.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<!-- Fix: This -nn, date below -->
<rfc ipr="trust200902" docName="draft-bormann-coap-misc-05"
category="info" >
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes" ?>
<front>
<title abbrev="CoAP-misc">
Miscellaneous additions to CoAP
</title>
<author initials="C" surname="Bormann" fullname="Carsten Bormann">
<organization>Universität Bremen TZI</organization>
<address>
<postal>
<street>Postfach 330440</street>
<city>Bremen</city>
<code>D-28359</code>
<country>Germany</country>
</postal>
<phone>+49-421-218-63921</phone>
<facsimile>+49-421-218-7000</facsimile>
<email>cabo@tzi.org</email>
</address>
</author>
<author initials="K" surname="Hartke" fullname="Klaus Hartke">
<organization>Universität Bremen TZI</organization>
<address>
<postal>
<street>Postfach 330440</street>
<city>Bremen</city>
<code>D-28359</code>
<country>Germany</country>
</postal>
<phone>+49-421-218-63905</phone>
<facsimile>+49-421-218-7000</facsimile>
<email>hartke@tzi.org</email>
</address>
</author>
<date year="2010" month="July" day="06"/>
<area>General</area>
<workgroup>CoRE Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>
This short I-D makes a number of partially interrelated
proposals how to solve certain problems in the CoRE WG's main
protocol, CoAP.
</t>
</abstract>
</front>
<middle>
<section anchor="problems" title="Introduction">
<t>The CoRE WG is tasked with standardizing an
Application Protocol for Constrained Networks/Nodes, CoAP.
This protocol is intended to provide RESTful <xref target="REST"/> services not
unlike HTTP <xref target="RFC2616"/>,
while reducing the complexity of implementation as well as the size of
packets exchanged in order to make these services useful in a highly
constrained network of themselves highly constrained nodes.</t>
<t>This objective requires restraint in a number of sometimes conflicting ways:</t>
<t><list style='symbols'>
<t>reducing implementation complexity in order to minimize code size,</t>
<t>reducing message sizes in order to minimize the number of fragments
needed for each message (in turn to maximize the probability of
delivery of the message), the amount of transmission power needed
and the loading of the limited-bandwidth channel,</t>
<t>reducing requirements on the environment such as stable storage,
good sources of randomness or user interaction capabilities.</t>
</list></t>
<t>This draft attempts to address a number of problems not yet adequately
solved in <xref target="I-D.ietf-core-coap"/>. The solutions proposed to these
problems are somewhat interrelated and are therefore presented in one
draft.</t>
<t>In this document, the key words “MUST”, “MUST NOT”, “REQUIRED”,
“SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”,
and “OPTIONAL” are to be interpreted as described in BCP 14
<xref target="RFC2119"/> and indicate requirement levels for compliant CoAP
implementations.</t>
</section>
<section anchor="accept" title="A Compact Accept Option">
<t>A resource may be available in a number of representations.
Without some information from the client, a server has no easy way to
decide which of these would be best served.
HTTP has an Accept: request header that a client can use to indicate
the media types supported, allowing the server to decide. This header
is somewhat unpopular as, for a web browser, there are too many media
types to choose from, so — even with wildcards — there is no
meaningful information to put there. (This has changed a bit for AJAX
calls, which may indeed have a specific media type preference.)
It is unlikely that machine-to-machine communication would have the
same problem.</t>
<t>A similar function to the HTTP Accept: header could be added to CoAP
as an option in a much simpler way. The CoAP Accept option would
simple carry a value that is a sequence of octets, each of which is an
acceptable media type for the client, in the order of preference (see
<xref target="acceptheader"/>). If no Accept option is given, the client does not
express a preference.</t>
<figure anchor="acceptheader" title="Accept option value: A sequence of media types"><artwork><![CDATA[
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| mediatype |
+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mediatype1 | mediatype2 | etc.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<t>Accept also has to be given an option type code, e.g. 6, in Table 2 of
<xref target="I-D.ietf-core-coap"/>. (Alternatively, as Accept appears to be
mutually exclusive with Content-Type, the same option number as
Content-Type could be used. For both to have the same structure, the
Content-Type option could also be repeated for every Acceptable media
type.)</t>
<t>The other addition that would be required is an error code that
mirrors HTTP’s “415 Unsupported Media Type”. This is indeed already
listed as CoAP Code 35 in Table 3 of <xref target="I-D.ietf-core-coap"/>.</t>
<t><list style='hanging'>
<t hangText='Proposal:'>
Add an Accept Option.</t>
<t hangText='Benefits:'>
A Server does not need to specify one URI each for every possible
media type that it wants to serve a resource under.</t>
</list></t>
<t>(See also <xref target="self-describing"/>.)</t>
</section>
<section anchor="uri-encoding" title="URI encoding">
<t>In HTTP-based systems, URIs can reach significant lengths.
While CoAP-based systems may be able to sidestep the most egregious
excesses (mostly by simply applying REST principles), a URI such as</t>
<t><list style='empty'>
<t>/.well-known/resources</t>
</list></t>
<t>can use up one third of the available payload in a CoAP message
transported in a single 6LoWPAN packet.
Is there a way to encode these URIs in a more efficient way?</t>
<t>Several proposals have been made on the CoRE mailing list, e.g. applying
the principle of base64-encoding <xref target="RFC4648"/> in reverse and using only
6 bits per character. However, due to rounding errors and occasional
characters that are not in the 64-character subset chosen to be efficiently
encodable, the actual gains are limited. Similarly, using 7 bits per
character (assuming URIs contain only ASCII characters) only gives a
best-case gain of 12.5 %, and that only in the case the URI is a multiple
of 8 characters long. On the other hand, the complexity (and danger
of subtle interoperability problems) is not entirely trivial.</t>
<t><xref target="stateless"/> defines a potential URI encoding that is slightly more
efficient than the abovementioned ones. However, even that was
rejected by the WG for its unconvincing cost-benefit ratio, which then
went on to discuss Henning Schulzrinne’s proposal to add state.</t>
<section anchor="stateful" title="Stateful URI compression">
<t>Is the approximately 25 % average saving achievable with Huffman-based
URI compression schemes worth the complexity?
Probably not, because much higher average savings can be achieved by
introducing state.</t>
<t>Henning Schulzrinne has proposed for a server to be able to supply a
shortened URI once a resource has been requested using the full-length
URI.
Let’s call such a shortened referent a <spanx style='emph'>Temporary Resource
Identifier</spanx>, <spanx style='emph'>TeRI</spanx> for short.
This could be expressed by a response option as shown in <xref target="teri-offer"/>.</t>
<figure anchor="teri-offer" title="Option for offering a TeRI in a response"><artwork><![CDATA[
0
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| duration | TeRI...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<t>The TeRI offer option indicates that the server promises to offer this
resources under the TeRI given for at least the time given as the duration.
Another TeRI offer can be made later to extend the duration.</t>
<t>Once a TeRI for a URI is known (and still within its lifetime), the
client can supply a TeRI instead of a URI in its requests.
The same option format as an offer could be used to allow the client
to indicate how long it believes the TeRI will still be valid (so that
the server can decide when to update the lifetime duration).
TeRIs in requests could be distinguished from URIs e.g. by using a
different option number.</t>
<t><list style='hanging'>
<t hangText='Proposal:'>
Add a TeRI option (e.g., number 2) that can be used in CoAP requests
and responses.</t>
<t>Add a way to indicate a TeRI and its duration in a link-value.</t>
<t>Do not add any form of stateless URI encoding.</t>
<t hangText='Benefits:'>
Much higher reduction of message size than any stateless URI encoding
could achieve.</t>
<t>As the use of TeRIs is entirely optional, minimal complexity nodes
can get by without implementing them.</t>
</list></t>
</section>
<section anchor="support-for-uris-with-binary-adresses" title="Support for URIs with Binary Adresses">
<t>As defined in <xref target="I-D.ietf-core-coap"/>, the Uri option does not provide
a way to distinguish an <spanx style='verb'>absolute-URI</spanx> from an <spanx style='verb'>absolute-path</spanx>
<xref target="RFC3986"/>: the leading slash is omitted from the latter. (Ticket
#12.)</t>
<t>The proposal to fix this is to split the option into three parts:
<spanx style='verb'>Uri-Scheme</spanx> for the URI Scheme, <spanx style='verb'>Uri-Authority</spanx> for Host/Port and
<spanx style='verb'>Uri-Path</spanx> for the absolute-path.</t>
<t>A further problem with that version is that the authority part can be
very bulky if it encodes an IPv6 address in ASCII.</t>
<t><list style='hanging'>
<t hangText='Proposal:'>
Provide an option <spanx style='verb'>Uri-Authority-Binary</spanx> that can be an even number of
bytes between 2 and 18 except 12 or 14.</t>
</list></t>
<t><list style='symbols'>
<t>If the number of bytes is 2, the destination IP address
of the packet transporting the CoAP message is implied.</t>
<t>If the number of bytes is 4 or 6, the first four bytes of the option
value are an IPv4 address in binary.</t>
<t>If the number of bytes is 8 or 10, the first eight bytes are the
lower 64 bits of an IPv6 address; the upper eight bytes are implied
from the destination address of the packet transporting the CoAP message.</t>
<t>If the number of bytes is 16 or 18, the first 16
bytes are an IPv6 address.</t>
<t>If two more bytes remain, this is a port
number (as always in network byte order).</t>
</list></t>
<t>The resulting authority is (conceptually translated into ASCII and)
used in place of an Uri-Authority option.
Examples:</t>
<texttable>
<ttcol align='left'>Uri- Scheme</ttcol>
<ttcol align='left'>Uri-Authority-Binary</ttcol>
<ttcol align='left'>Uri-Path</ttcol>
<ttcol align='left'>URI</ttcol>
<c>(none)</c>
<c>(none)</c>
<c>(none)</c>
<c>”/”</c>
<c>(none)</c>
<c>(none)</c>
<c>‘temp’</c>
<c>“/temp”</c>
<c>(none)</c>
<c>2 bytes: 61616</c>
<c>‘temp’</c>
<c>“coap://[DA]:61616/temp”</c>
<c>‘http’</c>
<c>10 bytes: ::123:45 + 616</c>
<c>(none)</c>
<c>“http://[DA::123:45]:616”</c>
<c>(none)</c>
<c>16 bytes: 2000::1</c>
<c>temp</c>
<c>“coap://[2000::1]/temp”</c>
<c>‘http’</c>
<c>18 bytes: 2000::1 + 616</c>
<c>temp</c>
<c>“http://[2000::1]:616/temp”</c>
</texttable>
</section>
<section anchor="where-are-uri-options-used" title="Where are Uri Options Used?">
<t>A URI, represented by an appropriate set of Uri options (one or more
of Uri-Scheme, Uri-Authority, Uri-Path, unless the default absolute-path
of “/” applies) should be present in every GET, PUT, POST, or DELETE
message, unless replaced by a TeRI. The receiver of an ACK can figure
out which URI the message pertains to by comparing transaction IDs.</t>
<t>In a delayed Confirmable message that contains an asynchronous
response to a GET, the URI is included again (“echoed back”).</t>
<t>In addition to the context provided by including the URI again in
delayed responses, we propose adding a <spanx style='verb'>Token</spanx> option, which can be
included in GET, PUT, POST, DELETE messages, and is echoed back in
exactly those cases where the URI is echoed back. The Token allows a
recipient of an asynchronous message to relate back to an earlier
request and thus can be used as the long-term equivalent of what TID
is for a single transaction.
The Token option value is a sequence of bytes, which is opaque to the
server. The option is critical.</t>
</section>
</section>
<section anchor="block-wise-transfers" title="Block-wise transfers">
<t>Not all resource representations will fit into a single link layer
packet of a constrained network. Using fragmentation (either at the
adaptation layer or at the IP layer) to enable the transport of larger
representations is possible up to the maximum size of a UDP datagram,
but the fragmentation/reassembly process loads the lower layers
with conversation state that is better managed in the application
layer.</t>
<t>This section proposes options to enable <spanx style='emph'>block-wise</spanx> access to
resource representations. The overriding objective is to avoid
creating conversation state at the server for block-wise GET requests.
(It is impossible to fully avoid creating conversation state for
POST/PUT, if the creation/replacement of resources is to be atomic;
where that property is not needed, there is no need to create server
conversation state in this case, either.) Also, implementation of
these options is intended to be optional. (The details of which parts
of the behavior need to be mandatory to enable that optionality still
are TBD, see below.)</t>
<t>The size of the blocks should not be fixed by the protocol. On the
other hand, implementation should be as simple as possible. We
therefore propose a small range of power-of-two block sizes, from 2^4
(16) to 2^11 (2048) bytes. One of these eight values can be encoded
in three bits (0 for 2^4 to 7 for 2^11 bytes), the <spanx style='verb'>szx</spanx> (size
exponent); the actual block size is then <spanx style='verb'>1 << (szx + 4)</spanx>.</t>
<section anchor="block-option" title="The Block Option">
<t>When a representation is larger than can be comfortably transferred in
a single UDP datagram, the Block option can be used to indicate a
block-wise transfer. Block is a 1-, 2- or 3-byte integer, the four least
significant bits of which indicate the size and whether the current
block-wise transfer is the last block being transferred (M or “more”
bit). The value divided by sixteen is the number of the block
currently being transferred, starting from zero, i.e., the current
transfer is about the <spanx style='verb'>size</spanx> bytes starting at <spanx style='verb'>blocknr << (szx +
4)</spanx>. The default value of
the Block option is zero, indicating that the current block is the first
(block number 0) and only (M bit not set) block of the transfer;
however, there is no explicit size implied by this default value.</t>
<figure anchor="block" title="Block option"><artwork><![CDATA[
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|blocknr|M| szx |
+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| block nr |M| szx |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| block nr |M| szx |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<t>(Note that the option with the last 4 bits masked out, shifted to the
left by the value of szx, gives the byte position of the block. The
author is not too sure whether that particularly is a feature.)</t>
<t>The block option is used in one of three roles:</t>
<t><list style='symbols'>
<t>In the request for a GET, it gives the block number requested and
suggests a block size (block number 0) or echoes the block size of
previous blocks received (block numbers other than 0).</t>
<t>In the response for a GET or in the request for a PUT or POST, it
describes what block number is contained in the payload, and whether
further blocks are part of that body (M bit). If the M bit is set,
the size of the payload body in bytes MUST indeed be the power of
two given by the block size. All blocks for a transaction MUST use
the same block size, except for the last block (M bit not set).</t>
<t>In the response for a PUT or POST, it indicates what block number is
being acknowledged. In this case, the M bit is set to indicate that
this response does not carry the final response to the request; this
can occur when the M bit was set in the request and the server
implements PUT/POST atomically (only with the receptin of the last
block).</t>
</list></t>
<t>In all cases, the block number logically extends the transaction ID,
i.e. the same transaction ID can be used for all exchanges for a
block-wise transfer. (For GET, and for PUT/POST where atomic
semantics are not needed, the requester is free to use different
transactions IDs for each block if desired.)</t>
<t>When a GET is answered with a response carrying a Block option with
the M bit set, the requestor may retrieve additional blocks by sending
requests with a Block option giving the block number desired. In such
a Block option, the M bit MUST be sent as zero and ignored on
reception.</t>
<t>To influence the block size used in response to a GET request, the
requestor uses the Block option, giving the desired size, a block
number of zero and an M bit of zero. A server SHOULD use the block
size indicated or a smaller size. Any further block-wise requests for
blocks beyond the first one MUST indicate the block size used in the
response for the first one.</t>
<t>If the Block option is used by the requestor, all GET requests in a
single transaction MUST use the same size. The server SHOULD use the
block size indicated in the request option, but the requestor MUST
take note of the actual block size used in the response; the server
MUST ensure that it uses the same block size for all responses in a
transaction (except for the last one with the M bit not set). [TBD:
decide whether the Block option can only be used in a response if a
Block option was in the request. Such a minimal block option could be
of length zero, i.e., would occupy just one byte for the type/length
information, but is a bit redundant, so it would
be nice to leave this requirement out, but then every GET requestor has the
burden of having to cope with receiving Block options.]</t>
<t>Block-wise transfers SHOULD be used in conjunction with the Etag option,
unless the representation being exchanged is entirely static (not
changing over time at all, such as in a schema describing a device).
When reassembling the representation from the blocks being exchanged,
the reassembler MUST compare Etag options. If the Etag options do not
match in a GET transfer, the requestor has the option of attempting to
retrieve fresh values for the blocks it retrieved first. To minimize
the resulting inefficiency, the server MAY cache the current value of
a representation for an ongoing transaction, but there is no
requirement for the server to establish any state. The server may
offer a TeRI with the initial block to reduce the size of further
block-wise GET requests; this TeRI MAY be short-lived and specific to
the version of the representation being retrieved (which would in
effect freeze the representation of the resource specifically for the
purposes of this block-wise transfer).</t>
<t>In a PUT or POST transfer, the block option refers to the body in the
request, i.e., there is no way to perform a block-wise retrieval of
the body of the response. Servers that do need to supply large bodies
in response to PUT/POST SHOULD therefore be employing redirects,
possibly offering a TeRI.</t>
<t>In a PUT or POST transfer that is intended to be implemented in an
atomic fashion at the server, the actual creation/replacement takes
place at the time a block with the M bit unset is received. If not
all previous blocks are available at the server at this time, the
transfer fails and error code 4__ (TBD) MUST be returned. The error
code 4__ can also be returned at any time by a server that does not
currently have the resources to store blocks for a block-wise PUT or
POST transfer that it would intend to implement in an atomic fashion.
[TBD: a way for a server to derive the equivalent of an Etag for the
request body, so that when these do not match in a PUT or POST
transfer, the reassembler MUST discard older blocks. For now, the
transaction ID will have to suffice.]</t>
<t><list style='hanging'>
<t hangText='Proposal:'>
Add a Block option (e.g., number 8) that can be used for block-wise transfers.</t>
<t hangText='Benefits:'>
Transfers larger than can be accommodated in constrained-network
link-layer packets can be performed in smaller blocks.</t>
<t>No hard-to-manage conversation state is created at the adaptation
layer or IP layer for fragmentation.</t>
<t>The transfer of each block is acknowledged, enabling retransmission
if required.</t>
<t>Both sides have a say in the block size that actually will be used.</t>
<t hangText='TBD:'>
Give examples with detailed message flows for a block-wise GET, PUT
and POST.</t>
</list></t>
</section>
</section>
<section anchor="option-encoding" title="Option Encoding">
<t>The option encoding in <xref target="I-D.ietf-core-coap"/> is neither particularly
flexible nor particularly efficient. One important, easily overlooked
disadvantage of the encoding is the large number of ways in which the
same information can be encoded. This unneeded variability causes
problems in interoperability and increases both coding and testing
efforts required.</t>
<section anchor="a-more-efficient-option-encoding" title="A More Efficient Option Encoding">
<t>The basic idea of the proposed encoding is to reduce the number of
ways the same information can be encoded as far as possible (but not
further). This both simplifies decoding (e.g., an implementation that
only ever uses short URIs never has to implement long options, because
these can only be used with long lengths) and interoperability testing
(there is only one way to say a specific thing, so there aren’t
multiple ways that need testing).</t>
<t>One of the undesired variations in packets is the ordering of the
options. In this draft, we therefore mandate a total ordering of
options, ordered by the option number.</t>
<t>As an interesting consequence, the option numbers can now be expressed
in delta coding, in turn requiring fewer bits to encode the option
number. This frees a number of bits for the length, making the
likelihood of actually needing the two-byte form of the option header
much smaller.</t>
<t>To further reduce variation, the length of the value (as always, not
including the option header) is now encoded in such a way that there
is only one way to express a given length: The short form (one-byte
option tag) can express length values from 0 to 14, and the long form
is used for values of 15 to 15+255=270, inclusively
(<xref target="delta-options15"/>).</t>
<figure anchor="delta-options15" title="Option delta/length representation with small range"><artwork><![CDATA[
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| option delta | length | for 0..14
+---+---+---+---+---+---+---+---+
for 15..270:
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| option delta | 1 1 1 1 | length - 15 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
]]></artwork></figure>
<t>The small option delta of 0..15 in this encoding limits the difference
in option value between two adjacent options (or the value of the
option number of the first option). While realistic sequences of
options rarely will have a problem here, option numbers 14, 28,
… are reserved for no-op options with no body (implementations will
automatically ignore these with zero additional code; see <xref target="critical"/>
why the reserved values are not 15, 30, …). Note that the resulting
delta that reaches the interim nop option may have any number, e.g.,
for including option 2 and 27 in one message, the sequence would be:</t>
<t><list style='symbols'>
<t>delta = 2 (option 2, body)</t>
<t>delta = 12 (option 14 = no-op, no body)</t>
<t>delta = 13 (option 27, body)</t>
</list></t>
<t>In the unlikely case that only option 40 is needed, the sequence would
be:</t>
<t><list style='symbols'>
<t>delta = 14 (option 14 = no-op, no body)</t>
<t>delta = 14 (option 28 = no-op, bo body)</t>
<t>delta = 12 (option 40, body)</t>
</list></t>
</section>
<section anchor="critical" title="Critical Options">
<t>CoAP is designed to enable the definition of additional options by
later extensions. Typically, new options are designed in such a way
that they can simply be ignored if not understood, i.e. new options
are <spanx style='emph'>elective</spanx>. However, some new options may be <spanx style='emph'>critical</spanx>, i.e., there
is no good way to process the message if the option is not understood.
(Actually, half of the options currently on the table are critical in nature.)</t>
<t>In the option encoding proposed, odd-numbered options indicate a
critical option; even-numbered options indicate elective options.
(Note that, again, the even/odd distinction is on the option number
resulting from the decoding, not the delta value actually embedded in
the packet.)</t>
<t>Implementing this proposal requires some renumbering of options from
<xref target="I-D.ietf-core-coap"/>.</t>
<t>Note that most options that are designated as critical are <spanx style='emph'>not</spanx> meant
to be mandatory to implement. “Critical” just means if such an option
is encountered in an incoming message, there is no meaningful way to
process the message unless it is indeed implemented.</t>
</section>
<section anchor="errors-in-options" title="Errors in Options">
<t>When a message contains a critical option that is not understood by
the receiver, we say that <spanx style='emph'>decoding fails</spanx>.</t>
<t>When a message contains an option that is defined for a specific
length of value (e.g., Max-Age, which is only defined for length 1),
this is treated like an unknown option. For a critical option, this
causes the decoding to fail. For an elective option, this is not an
error, the option with the unsupported structure is just ignored.
(In both cases, the intention is to allow extension of the option by
different syntax in a later revision of the protocol.)</t>
<t>If the decoding of a message fails, the processing depends on the
message type:</t>
<t><list style='symbols'>
<t>NCN messages and RST messages with decode failures are always
silently ignored.</t>
<t>CON messages with decode failures lead to an RST with error code 400
(Bad Request). The payload of the RST SHOULD be a copy of the
option bytes that caused decoding to fail. However, nodes with
minimal capabilities may choose to restrict their error processing
to a minimum,</t>
<t>ACK messages that fail to decode are hard to process. The
requesting node MAY repeat the request with fewer options in order
to receive a simpler answer; if that is not possible, the decoding
failure should be treated like a client error. Conversely, nodes
SHOULD not send critical options in ACK messages unless the CON
message eliciting the ACK contained options that justify this.
(There may be exceptions, e.g., a node is always allowed to send a
Block option with a large resource representation. A requestor that
does not understand Block may never be able to receive that resource
representation properly, so it is appropriate to treat the situation
as a client error.)</t>
</list></t>
</section>
<section anchor="payload-length-option" title="Payload-Length Option">
<t>Not all transport mappings may provide an unambiguous length of the
CoAP message. For UDP, it may also be desirable to pack more than one
CoAP message into one UDP payload (aggregation); in that case, for all
but the last message there needs to be a way to delimit the payload of
that message.</t>
<t>We propose a new option, the Payload-Length option. If this option is
present, the value of this option is an unsigned integer giving the
length of the payload of the message (note that this integer can be
zero for a zero-length payload, which can in turn be represented by a
zero-length option value).
(In the UDP aggregation case, what would have been in the payload of this
message after <spanx style='verb'>payload-length</spanx> bytes is then actually one or more
additional messages.)</t>
</section>
<section anchor="making-the-etag-option-useful" title="Making the Etag option useful">
<t><list style='hanging'>
<t hangText='Problem:'>
The Etag option only allows for up to four bytes in one Etag. If
Etags are computed with a random distribution (e.g., by hashing the
resource representation), the birthday paradox makes a collision
surprisingly likely already for 1e4 variants in circulation.</t>
<t hangText='Proposal:'>
Allow longer Etags (i.e., don’t specify a specific upper limit).
The default Apache Etag has about 8..12 Bytes of information in it
(file ID = inode number, size, timestamp; which interestingly is
mostly redundant with information available in Content-Length and
Last-Modified). If a tighter upper limit is desired, 8 Bytes should
suffice for all practical purposes, but makes two-way gatewaying
with HTTP more complex.</t>
<t hangText='Problem:'>
The Etag option is not useful without an equivalent of <spanx style='verb'>If-None-Match</spanx>.</t>
<t hangText='Proposal:'>
Make Etags useful by defining a new Option <spanx style='verb'>I-Have</spanx>: The I-Have
Option carries a variable length octet sequence that specifies the
Etag of a resource representation that is being cached by a
client. A client that has one or more representations previously
obtained from the resource can indicate to the server that it has
cached these representations, such that the server may omit the
representation when the state of the resource does not change from a
cached representation or changes to one of the other cached
representation. The I-Have Option may occur zero or more times.
(This can be used to represent a “If-None-Match” HTTP option with
one or more Etags. Note that CoAP always uses what would be called
a strong validator in HTTP.) As it appears I-Have and Etag are
mutually exclusive, I-Have can use the option number of Etag.</t>
</list></t>
</section>
</section>
<section anchor="iana-considerations" title="IANA Considerations">
<t>This draft adds the following option numbers to Table 2 of
<xref target="I-D.ietf-core-coap"/>:</t>
<texttable>
<ttcol align='right'>Type</ttcol>
<ttcol align='left'>C/E</ttcol>
<ttcol align='left'>Name</ttcol>
<ttcol align='left'>Data type</ttcol>
<ttcol align='left'>Length</ttcol>
<ttcol align='left'>Rules</ttcol>
<c>2</c>
<c>E</c>
<c>TeRI</c>
<c>Duration + Sequence of Bytes</c>
<c>2-n B</c>
<c> </c>
<c>7</c>
<c>E</c>
<c>Accept</c>
<c>Sequence of bytes</c>
<c>1-n B</c>
<c> </c>
<c>8</c>
<c>C</c>
<c>Block</c>
<c>Unsigned Integer</c>
<c>1-3 B</c>
<c> </c>
<c>11</c>
<c>C</c>
<c>Token</c>
<c>Sequence of Bytes</c>
<c>1-n B</c>
<c> </c>
</texttable>
<t>With the new option encoding and the proposal for differentiating
critical from elective options, the total list becomes:</t>
<texttable>
<ttcol align='right'>Type</ttcol>
<ttcol align='left'>C/E</ttcol>
<ttcol align='left'>Name</ttcol>
<ttcol align='left'>Data type</ttcol>
<ttcol align='left'>Length</ttcol>
<ttcol align='left'>Default</ttcol>
<c>0</c>
<c>E</c>
<c>TeRI</c>
<c>Duration + Sequence of Bytes</c>
<c>2-n B</c>
<c>(none)</c>
<c>1</c>
<c>C</c>
<c>Content-type</c>
<c>Unsigned Integer</c>
<c>1* B</c>
<c>0 (text/plain)</c>
<c>2</c>
<c>E</c>
<c>Max-age</c>
<c>Duration</c>
<c>1 B</c>
<c>0</c>
<c>3</c>
<c>C</c>
<c>Uri-Scheme</c>
<c>String</c>
<c>1-n B</c>
<c>‘coap’</c>
<c>4</c>
<c>E</c>
<c>Etag</c>
<c>Sequence of Bytes</c>
<c>1-4* B</c>
<c>(none)</c>
<c>5</c>
<c>C</c>
<c>Uri-Authority</c>
<c>String</c>
<c>1-n B</c>
<c>’’</c>
<c>6</c>
<c>E</c>
<c>Accept</c>
<c>Sequence of Bytes</c>
<c>1-n B</c>
<c>any</c>
<c>7</c>
<c>C</c>
<c>Uri-Authority-Binary</c>
<c>Sequence of Bytes</c>
<c>1-n B</c>
<c>(use Uri-Authority)</c>
<c>8</c>
<c>E</c>
<c>Date</c>
<c>Unsigned Integer (<xref target="absolute"/>)</c>
<c>4-6 B</c>
<c>(none)</c>
<c>9</c>
<c>C</c>
<c>Uri-Path</c>
<c>String</c>
<c>1-n B</c>
<c>’’</c>
<c>11</c>
<c>C</c>
<c>Token</c>
<c>Sequence of Bytes</c>
<c>1-n B</c>
<c>(none)</c>
<c>13</c>
<c>C</c>
<c>Block</c>
<c>Unsigned Integer</c>
<c>1-3 B</c>
<c>0 (see <xref target="block-option"/>)</c>
<c>14..</c>
<c>E</c>
<c>Nop</c>
<c>None</c>
<c>0 B</c>
<c>(‘’)</c>
<c>15</c>
<c>C</c>
<c>Payload-length</c>
<c>Unsigned Integer</c>
<c>0-2 B</c>
<c>(none)</c>
</texttable>
<t>(The upper limit of <spanx style='verb'>n</spanx> indicates that the size is limited only by the
options encoding. * indicates that this document proposes to change
the limit.)
Odd option numbers indicate critical options, even option numbers
indicate elective options.
Option numbers 14, 28, 42, … (any number divisible by 14) are
reserved (they are elective and therefore ignored by all implementations).</t>
<t>(Subscription-related options are discussed in
<xref target="I-D.hartke-coap-observe"/>, so the following option from
<xref target="I-D.ietf-core-coap"/> is not further discussed here:)</t>
<texttable>
<ttcol align='right'>Type</ttcol>
<ttcol align='left'>C/E</ttcol>
<ttcol align='left'>Name</ttcol>
<ttcol align='left'>Data type</ttcol>
<ttcol align='left'>Length</ttcol>
<ttcol align='left'>Rules</ttcol>
<c>6</c>
<c>E</c>
<c>Subscription-lifetime</c>
<c>Duration</c>
<c>1 B</c>
<c>With SUBSCRIBE or its response</c>
</texttable>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>TBD.
(Weigh the security implications of application layer block-wise
transfer against those of adaptation-layer or IP-layer fragmentation.
Discuss the implications of TeRIs.
Also: Discuss nodes without clocks.)</t>
<section anchor="amplification-attacks" title="Amplification Attacks">
<t>TBD.
(This section discusses how CoAP nodes could become implicated in DoS
attacks by using the amplifying properties of the protocol, as well as
mitigations for this threat.)</t>
</section>
</section>
<section anchor="acknowledgements" title="Acknowledgements">
<t>This work was partially funded by the Klaus Tschira Foundation.</t>
<t>Of course, much of the content of this draft is the result of
discussions with the <xref target="I-D.ietf-core-coap"/> authors.
Tokens were suggested by Gilman Tolle.</t>
</section>
</middle>
<back>
<references title='Normative References'>
<reference anchor='RFC2119'>
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
<list>
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
</t></list></t>
<t>
Note that the force of these words is modified by the requirement
level of the document in which they are used.
</t></abstract></front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='http://www.rfc-editor.org/rfc/rfc2119.txt' />
<format type='HTML' octets='17491' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5777' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>
<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>
<reference anchor='RFC3986'>
<front>
<title abbrev='URI Generic Syntax'>Uniform Resource Identifier (URI): Generic Syntax</title>
<author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'>
<organization abbrev='W3C/MIT'>World Wide Web Consortium</organization>
<address>
<postal>
<street>Massachusetts Institute of Technology</street>
<street>77 Massachusetts Avenue</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>USA</country></postal>
<phone>+1-617-253-5702</phone>
<facsimile>+1-617-258-5999</facsimile>
<email>timbl@w3.org</email>
<uri>http://www.w3.org/People/Berners-Lee/</uri></address></author>
<author initials='R.' surname='Fielding' fullname='Roy T. Fielding'>
<organization abbrev='Day Software'>Day Software</organization>
<address>
<postal>
<street>5251 California Ave., Suite 110</street>
<city>Irvine</city>
<region>CA</region>
<code>92617</code>
<country>USA</country></postal>
<phone>+1-949-679-2960</phone>
<facsimile>+1-949-679-2972</facsimile>
<email>fielding@gbiv.com</email>
<uri>http://roy.gbiv.com/</uri></address></author>
<author initials='L.' surname='Masinter' fullname='Larry Masinter'>
<organization abbrev='Adobe Systems'>Adobe Systems Incorporated</organization>
<address>
<postal>
<street>345 Park Ave</street>
<city>San Jose</city>
<region>CA</region>
<code>95110</code>
<country>USA</country></postal>
<phone>+1-408-536-3024</phone>
<email>LMM@acm.org</email>
<uri>http://larry.masinter.net/</uri></address></author>
<date year='2005' month='January' />
<area>Applications</area>
<keyword>uniform resource identifier</keyword>
<keyword>URI</keyword>
<keyword>URL</keyword>
<keyword>URN</keyword>
<keyword>WWW</keyword>
<keyword>resource</keyword>
<abstract>
<t>
A Uniform Resource Identifier (URI) is a compact sequence of characters
that identifies an abstract or physical resource. This specification
defines the generic URI syntax and a process for resolving URI references
that might be in relative form, along with guidelines and security
considerations for the use of URIs on the Internet.
The URI syntax defines a grammar that is a superset of all valid URIs,
allowing an implementation to parse the common components of a URI
reference without knowing the scheme-specific requirements of every
possible identifier. This specification does not define a generative
grammar for URIs; that task is performed by the individual
specifications of each URI scheme.
</t></abstract></front>
<seriesInfo name='STD' value='66' />
<seriesInfo name='RFC' value='3986' />
<format type='TXT' octets='141811' target='http://www.rfc-editor.org/rfc/rfc3986.txt' />
<format type='HTML' octets='213584' target='http://xml.resource.org/public/rfc/html/rfc3986.html' />
<format type='XML' octets='163534' target='http://xml.resource.org/public/rfc/xml/rfc3986.xml' />
</reference>
<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='B' surname='Frank' fullname='Brian Frank'>
<organization />
</author>
<author initials='D' surname='Sturek' fullname='Don Sturek'>
<organization />
</author>
<date month='June' day='7' year='2010' />
<abstract><t>This document specifies the Constrained Application Protocol (CoAP), a specialized transfer protocol for use with constrained networks and nodes for machine-to-machine applications such as smart energy and building automation. These constrained nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while networks such as 6LoWPAN often have high packet error rates and typical throughput of 10s of kbit/s. CoAP provides request/reply and subscribe/notify interaction models between application end-points, supports built-in resource discovery, and includes key web concepts such as URIs and RESTful methods. CoAP easily translates to 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-00' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-core-coap-00.txt' />
</reference>
<reference anchor='I-D.hartke-coap-observe'>
<front>
<title>Observing Resources in CoAP</title>
<author initials='K' surname='Hartke' fullname='Klaus Hartke'>
<organization />
</author>
<author initials='C' surname='Bormann' fullname='Carsten Bormann'>
<organization />
</author>
<date month='June' day='22' year='2010' />
<abstract><t>The state of a resource can change over time. We want to give clients of the CoRE WG CoAP protocol the ability to observe this change. This short I-D provides an example design for such an addition to CoAP, in order to be able to discuss the design alternatives in specific terms.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-hartke-coap-observe-00' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-hartke-coap-observe-00.txt' />
</reference>
<reference anchor='I-D.ietf-httpbis-p1-messaging'>
<front>
<title>HTTP/1.1, part 1: URIs, Connections, and Message Parsing</title>
<author initials='R' surname='Fielding' fullname='Roy Fielding'>
<organization />
</author>
<author initials='J' surname='Gettys' fullname='Jim Gettys'>
<organization />
</author>
<author initials='J' surname='Mogul' fullname='Jeffrey Mogul'>
<organization />
</author>
<author initials='H' surname='Nielsen' fullname='Henrik Nielsen'>
<organization />
</author>
<author initials='L' surname='Masinter' fullname='Larry Masinter'>
<organization />
</author>
<author initials='P' surname='Leach' fullname='Paul Leach'>
<organization />
</author>
<author initials='T' surname='Berners-Lee' fullname='Tim Berners-Lee'>
<organization />
</author>
<author initials='J' surname='Reschke' fullname='Julian Reschke'>
<organization />
</author>
<date month='March' day='8' year='2010' />
<abstract><t>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 1 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides an overview of HTTP and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-httpbis-p1-messaging-09' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-httpbis-p1-messaging-09.txt' />
</reference>
<reference anchor='I-D.ietf-httpbis-p4-conditional'>
<front>
<title>HTTP/1.1, part 4: Conditional Requests</title>
<author initials='R' surname='Fielding' fullname='Roy Fielding'>
<organization />
</author>
<author initials='J' surname='Gettys' fullname='Jim Gettys'>
<organization />
</author>
<author initials='J' surname='Mogul' fullname='Jeffrey Mogul'>
<organization />
</author>
<author initials='H' surname='Nielsen' fullname='Henrik Nielsen'>
<organization />
</author>
<author initials='L' surname='Masinter' fullname='Larry Masinter'>
<organization />
</author>
<author initials='P' surname='Leach' fullname='Paul Leach'>
<organization />
</author>
<author initials='T' surname='Berners-Lee' fullname='Tim Berners-Lee'>
<organization />
</author>
<author initials='J' surname='Reschke' fullname='Julian Reschke'>
<organization />
</author>
<date month='March' day='8' year='2010' />
<abstract><t>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-httpbis-p4-conditional-09' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-httpbis-p4-conditional-09.txt' />
</reference>
<reference anchor='I-D.ietf-httpbis-p6-cache'>
<front>
<title>HTTP/1.1, part 6: Caching</title>
<author initials='R' surname='Fielding' fullname='Roy Fielding'>
<organization />
</author>
<author initials='J' surname='Gettys' fullname='Jim Gettys'>
<organization />
</author>
<author initials='J' surname='Mogul' fullname='Jeffrey Mogul'>
<organization />
</author>
<author initials='H' surname='Nielsen' fullname='Henrik Nielsen'>
<organization />
</author>
<author initials='L' surname='Masinter' fullname='Larry Masinter'>
<organization />
</author>
<author initials='P' surname='Leach' fullname='Paul Leach'>
<organization />
</author>
<author initials='T' surname='Berners-Lee' fullname='Tim Berners-Lee'>
<organization />
</author>
<author initials='J' surname='Reschke' fullname='Julian Reschke'>
<organization />
</author>
<date month='March' day='8' year='2010' />
<abstract><t>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document is Part 6 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-httpbis-p6-cache-09' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-httpbis-p6-cache-09.txt' />
</reference>
</references>
<references title='Informative References'>
<reference anchor="REST">
<front>
<title>Architectural Styles and the Design of Network-based Software Architectures</title>
<author fullname="Roy Fielding" initials="R" surname="Fielding">
<organization>University of California, Irvine</organization>
</author>
<date year="2000" />
</front>
</reference>
<reference anchor='RFC4648'>
<front>
<title>The Base16, Base32, and Base64 Data Encodings</title>
<author initials='S.' surname='Josefsson' fullname='S. Josefsson'>
<organization /></author>
<date year='2006' month='October' />
<abstract>
<t>This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='4648' />
<format type='TXT' octets='35491' target='http://www.rfc-editor.org/rfc/rfc4648.txt' />
</reference>
<reference anchor='RFC1951'>
<front>
<title>DEFLATE Compressed Data Format Specification version 1.3</title>
<author initials='P.' surname='Deutsch' fullname='L. Peter Deutsch'>
<organization>Aladdin Enterprises</organization>
<address>
<postal>
<street>203 Santa Margarita Ave.</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country></postal>
<phone>+1 415 322 0103</phone>
<facsimile>+1 415 322 1734</facsimile>
<email>ghost@aladdin.com</email></address></author>
<date year='1996' month='May' />
<abstract>
<t>This specification defines a lossless compressed data format that compresses data using a combination of the LZ77 algorithm and Huffman coding, with efficiency comparable to the best currently available general-purpose compression methods. The data can be produced or consumed, even for an arbitrarily long sequentially presented input data stream, using only an a priori bounded amount of intermediate storage. The format can be implemented readily in a manner not covered by patents.</t></abstract></front>
<seriesInfo name='RFC' value='1951' />
<format type='TXT' octets='36944' target='http://www.rfc-editor.org/rfc/rfc1951.txt' />
<format type='PS' octets='57408' target='http://www.rfc-editor.org/rfc/rfc1951.ps' />
<format type='PDF' octets='56620' target='http://www.rfc-editor.org/rfc/rfc1951.pdf' />
</reference>
</references>
<section anchor="things-we-wont-do" title="Things we won’t do">
<t>This annex documents roads that the WG decided not to take, in order
to spare readers from reinventing them in vain.</t>
<section anchor="stateless" title="An efficient stateless URI encoding">
<t>There is very little redundancy by repetition in a typical URI,
rendering popular compression methods such as LZ77 (as implemented in
in the widely used DEFLATE algorithm <xref target="RFC1951"/>) rather ineffective.</t>
<t>For the short, non-repetitive data structures that URIs tend to be, efficient
stateless compression is pretty much confined to Huffman (or, for even
more complexity, arithmetic) coding. The complexity can be reduced
significantly by moving to n-ary Huffman coding, i.e., optimizing not
to the bit level, but to a larger level of granularity. Informal
experiments by the author show that a 16ary Huffman coding is close to
optimal for reasonable URI lengths. In other words, basing the
encoding on nibbles (4-bit half-bytes) is both nearly optimal and
relatively inexpensive to implement.</t>
<t>The actual letter frequencies that will occur in CoAP URIs are hard to
predict. As a stopgap, the author has analyzed an HTTP-based URI
corpus and found the following characters to occur with high
frequency:</t>
<t><list style='empty'>
<t>%.aeinorst</t>
</list></t>
<t>In the encoding proposed, each of these ten highly-compressed
characters is represented by a
single 4-bit nibble. As the % character is used for hexadecimal encoding in
URIs, two additional nibbles are used to provide the numeric value of
the two hexadecimal
numbers following the % character (the original URI will only be
properly reconstituted if these
are upper-case as they should be according to section 2.1 of the URI
specification <xref target="RFC3986"/>; the encoder can choose to send all three
characters in dual-nibble format if that matters). An encoder could also map non-ASCII
characters to this three-nibble form, even though they are not allowed
in URIs. This gives compatibility with the %-encoding required by
<xref target="RFC3986"/>.</t>
<t>All other characters are represented by both of their nibbles. The
resulting sequence of nibbles is reconstituted into a sequence of
bytes in most-significant-nibble-first order. Any unused nibble in
the last byte of an encoding is set to 0. (Upon decoding, this
padding can be readily distinguished from another % combination as
this would require another byte after the last byte.) The encoding is
summarized in <xref target="nibbles"/>.</t>
<figure anchor="nibbles" title="A nibble-based URI encoding"><artwork><![CDATA[
0 1
0 1 2 3 4 5 6 7 8 9 0 1
+---+---+---+---+
| 1, 8-F | .aeinorst
+---+---+---+---+ 189ABCDEF
+---+---+---+---+---+---+---+---+
| 2-7 | 0-F | other ASCII
+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+---+---+---+---+
| 0 | 0-F | 0-F | %HH
+---+---+---+---+---+---+---+---+---+---+---+---+
]]></artwork></figure>
<t>An example encoding for <spanx style='verb'>/.well-known/resources</spanx> (where the initial
slash is left out, as proposed for abs-path URIs) is given in
<xref target="nibble-example"/>. While the more than 28 % savings in this example
may seem just an accident, the HTTP-based corpus indeed
shows an average savings of about 21.8 %, i.e. the sum of the lengths
of the encoded version of all URIs in the corpus is about 78.2 % of
the sum of the length of all URIs. (The savings should be noticeably
higher with a more RESTful selection of URIs than was available for
this experiment.)</t>
<figure anchor="nibble-example" title="Nibble-based URI encoding: 21 -> 15 bytes"><artwork><![CDATA[
0 1 2
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
/ . w e l l - k n o w n / r e s o u r c e s
2e 77 65 6c 6c 2d 6b 6e 6f 77 6e 2f 72 65 73 6f 75 72 63 65 73
->
1 77 9 6c 6c 2d 6b b c 77 b 2f d 9 e c 75 d 63 9 e
= 17 79 6c 6c 2d 6b bc 77 b2 fd 9e c7 5d 63 9e
]]></artwork></figure>
</section>
<section anchor="self-describing" title="Media-Types with Self-Describing Length">
<t><list style='hanging'>
<t hangText='Open Issues:'>
For coap-00, the Accept option proposed would have needed a way to handle two-byte media
types (easiest if these can be made self-describing, at the cost of
about 3 bits in the sub-type field; <xref target="mediatypes"/>).</t>
</list></t>
<t>An self-describing representation for long mediatypes could look like this:</t>
<figure anchor="mediatypes" title="A self-describing media type representation"><artwork><![CDATA[
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| top | sub | (1-byte: unchanged)
+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 000 | top | sub | (2-byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<t>Instead, we assume for now that CoAP-01 will switch to a single-byte
media type encoding.</t>
</section>
</section>
<section anchor="experimental-options" title="Experimental Options">
<t>This annex documents proposals that need significant additional
discussion before they can become part of (or go back to) the main
CoAP specification. They are not dead, but might die if there turns
out to be no good way to solve the problem.</t>
<section anchor="absolute" title="Options indicating absolute time">
<t>HTTP has a number of headers that may indicate absolute time:</t>
<t><list style='symbols'>
<t><spanx style='verb'>Date</spanx>, defined in Section 14.18 in <xref target="RFC2616"/> (Section 9.3 in
<xref target="I-D.ietf-httpbis-p1-messaging"/>), giving the absolute time
a response was generated;</t>
<t><spanx style='verb'>Last-Modified</spanx>, defined in Section 14.29 in <xref target="RFC2616"/>, (Section
6.6 in <xref target="I-D.ietf-httpbis-p4-conditional"/>, giving the absolute time of
when the origin server believes the resource representation was last
modified;</t>
<t><spanx style='verb'>If-Modified-Since</spanx>, defined in Section 14.25 in <xref target="RFC2616"/>,
<spanx style='verb'>If-Unmodified-Since</spanx>, defined in Section 14.28 in <xref target="RFC2616"/>, and
<spanx style='verb'>If-Range</spanx>, defined in Section 14.27 in <xref target="RFC2616"/> can be used to
supply absolute time to gate a conditional request;</t>
<t><spanx style='verb'>Expires</spanx>, defined in Section 14.21 in <xref target="RFC2616"/> (Section 3.3 in
<xref target="I-D.ietf-httpbis-p6-cache"/>), giving the absolute time
after which a response is considered stale.</t>
<t>The more obscure headers <spanx style='verb'>Retry-After</spanx>, defined in Section 14.37 in
<xref target="RFC2616"/>, and <spanx style='verb'>Warning</spanx>, defined in section 14.46 in <xref target="RFC2616"/>,
also may employ absolute time.</t>
</list></t>
<t><xref target="I-D.ietf-core-coap"/> defines a single <spanx style='verb'>Date</spanx> option, which however
“indicates the creation time and date of a given resource
representation”, i.e., is closer to a “Last-Modified” HTTP header.
HTTP’s caching rules <xref target="I-D.ietf-httpbis-p6-cache"/> make use of both <spanx style='verb'>Date</spanx>
and <spanx style='verb'>Last-Modified</spanx>, combined with <spanx style='verb'>Expires</spanx>.
The specific semantics required for CoAP needs further consideration.</t>
<t>In addition to the definition of the semantics, an encoding for
absolute times needs to be specified.</t>
<t>In UNIX-related systems, it is customary to indicate absolute time as
an integer number of seconds, after midnight UTC, January 1, 1970.
Unless negative numbers are employed, this time format cannot
represent time values prior to January 1, 1970, which probably is not
required for the uses ob absolute time in CoAP.</t>
<t>If a 32-bit integer is used and allowance is made for a sign-bit in a
local implementation, the latest UTC time value that can be
represented by the resulting 31 bit integer value is 03:14:07 on
January 19, 2038. If the 32-bit integer is used as an unsigned value,
the last date is 2106-02-07, 06:28:15.</t>
<t>The reach can be extended by:
- moving the epoch forward, e.g. by 40 years (= 1262304000 seconds) to
2010-01-01. This makes it impossible to represent Last-Modified
times in that past (such as could be gatewayed in from HTTP).
- extending the number of bits, e.g. by one more byte, either always
or as one of two formats, keeping the 32-bit variant as well.</t>
<t>Also, the resolution can be extended by expressing time in
milliseconds etc., requiring even more bits (e.g., a 48-bit unsigned
integer of milliseconds would last well after year 9999.)</t>
<t>For experiments, an experimental <spanx style='verb'>Date</spanx> option is defined with the
semantics of HTTP’s <spanx style='verb'>Last-Modified</spanx>. It can carry an unsigned integer
of 32, 40, or 48 bits; 32- and 40-bit integers indicate the absolute
time in seconds since 1970-01-01 00:00 UTC, while 48-bit integers
indicate the absolute time in milliseconds since 1970-01-01 00:00 UTC.</t>
<t>However, that option is not really that useful until there is a
<spanx style='verb'>If-Modified-Since</spanx> option as well.</t>
</section>
</section>
<section anchor="duration" title="Rationale: Representing Durations">
<section anchor="text-for-section-321-of-coap-01" title="Text for section 3.2.1 of coap-01">
<t>Various message types used in CoAP need the representation of
<spanx style='strong'>durations</spanx>, i.e. of the length of a timespan.
In SI units, these are measured in seconds.
CoAP durations represent integer numbers of seconds, but instead of
representing these numbers as integers, a more compact single-byte
pseudo-floating-point (pseudo-FP) representation is used (<xref target="pseudofp"/>).</t>
<figure anchor="pseudofp" title="Duration in (8,4) pseudo-FP representation"><artwork><![CDATA[
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 0... value |
+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+
| 1... mantissa | exponent |
+---+---+---+---+---+---+---+---+
]]></artwork></figure>
<t>If the high bit is clear, the entire n-bit value (including the high
bit) is the decoded value. If the high bit is set, the mantissa
(including the high bit, with the exponent field cleared out but still
present) is shifted left by the exponent to yield the decoded value.</t>
<t>The (n,e)-pseudo-FP format can be decoded with a single line of code
(plus a couple of constant definitions), as demonstrated in
<xref target="pseudofp-decode"/>.</t>
<figure anchor="pseudofp-decode" title="Decoding an (8,4) pseudo-FP value"><artwork><![CDATA[
#define N 8
#define E 4
#define HIBIT (1 << (N - 1))
#define EMASK ((1 << E) - 1)
#define MMASK ((1 << N) - 1 - EMASK)
#define DECODE_8_4(r) (r < HIBIT ? r : (r & MMASK) << (r & EMASK))
]]></artwork></figure>
<t>Note that a pseudo-FP encoder needs to consider rounding; different
applications of durations may favor rounding up or rounding down the
value encoded in the message.</t>
<t>The highest pseudo-FP value, represented by an all-ones byte (0xFF), is
reserved to indicate an indefinite duration. The next lower value
(0xEF) is thus the highest representable value and is decoded as
7340032 seconds, a little more than 12 weeks.</t>
</section>
<section anchor="rationale" title="Rationale">
<t>Where CPU power and memory is abundant, a duration can almost always
be adequately represented by a non-negative floating-point number
representing that number of seconds.
Historically, many APIs have also used an integer representation,
which limits both the resolution (e.g., if the integer represents the
duration in seconds) and often the range (integer machine types
have range limits that may become relevant).
UNIX’s <spanx style='verb'>time_t</spanx> (which is used for both absolute time and durations)
originally was a signed 32-bit value of seconds, but
was later complemented by an additional integer to add microsecond
(<spanx style='verb'>struct timeval</spanx>) and then later nanosecond (<spanx style='verb'>struct timespec</spanx>)
resolution.</t>
<t>Three decisions need to be made for each application of the concept of
duration:</t>
<t><list style='symbols'>
<t>the <spanx style='strong'>resolution</spanx>. What rounding error is acceptable?</t>
<t>the <spanx style='strong'>range</spanx>. What is the maximum duration that needs to be represented?</t>
<t>the <spanx style='strong'>number of bits</spanx> that can be expended.</t>
</list></t>
<t>Obviously, these decisions are interrelated. Typically, a large range
needs a large number of bits, unless resolution is traded. For most
applications, the actual requirement for resolution are limited for
longer durations, but can be more acute for shorter durations.</t>
</section>
<section anchor="pseudo-fp" title="Pseudo-Floating Point">
<t>Constrained systems typically avoid the use of floating-point (FP)
values, as</t>
<t><list style='symbols'>
<t>simple CPUs often don’t have support for floating-point datatypes</t>
<t>software floating-point libraries are expensive in code size and slow.</t>
</list></t>
<t>In addition, floating-point datatypes used to be a significant element
of market differentiation in CPU design; it has taken the industry a
long time to agree on a standard floating point representation.</t>
<t>These issues have led to protocols that try to constrain themselves to
integer representation even where the ability of a floating point
representation to trade range for resolution would be beneficial.</t>
<t>The idea of introducing <spanx style='emph'>pseudo-FP</spanx> is to obtain the increased range
provided by embedding an exponent, without necessarily getting stuck with hardware
datatypes or inefficient software floating-point libraries.</t>
<t>For the purposes of this draft, we define an (n,e)-pseudo-FP as a
fixed-length value of n bits, e of which may be used for an exponent.
<xref target="pseudofp"/> illustrates an (8,4)-pseudo-FP value.</t>
<t>If the high bit is clear, the entire n-bit value (including the high
bit) is the decoded value. If the high bit is set, the mantissa
(including the high bit, but with the exponent field cleared out) is
shifted left by the exponent to yield the decoded value.</t>
<t>The (n,e)-pseudo-FP format can be decoded with a single line of code
(plus a couple of constant definition), as demonstrated in
<xref target="pseudofp-decode"/>.</t>
<t>Only non-negative numbers can be represented by this format.
It is designed to provide full integer resolution for values
from 0 to 2^(n-1)-1, i.e., 0 to 127 in the (8,4) case, and a mantissa
of n-e bits from 2^(n-1) to (2^n-2^e)*2^(2^e-1), i.e., 128 to
7864320 in the (8,4) case. By choosing e carefully, resolution can be
traded against range.</t>
<t>Note that a pseudo-FP encoder needs to consider rounding; different
applications of durations may favor rounding up or rounding down the
value encoded in the message. This requires a little more than a
single line of code (which is left as an exercise to the reader, as
the most efficient expression depends on hardware details).</t>
</section>
<section anchor="duration-type" title="A Duration Type for CoAP">
<t>CoAP needs durations in a number of places. In
<xref target="I-D.ietf-core-coap"/>, durations occur in the option
<spanx style='verb'>Subscription-lifetime</spanx> as well as in the option <spanx style='verb'>Max-age</spanx>.
(Note that the option <spanx style='verb'>Date</spanx> is not a duration, but a point in time.)
Other durations of this kind may be added later.</t>
<t>Most durations relevant to CoAP are best expressed with a minimum
resolution of one second. More detailed resolutions are unlikely to
provide much benefit.</t>
<t>The range of lifetimes and caching ages are probably best kept below
the order of magnitude of months.
An (8,4)-pseudo-FP has the maximum value of 7864320, which is about 91
days; this appears to be adequate for a subscription lifetime and
probably even for a maximum cache age. <xref target="duration-values"/> shows the
values that can be expressed.
(If a larger range for the latter is indeed desired, an
(8,5)-pseudo-FP could be used; this would last 15 milleniums, at the
cost of having only 3 bits of accuracy for values larger than 127
seconds.)</t>
<t><list style='hanging'>
<t hangText='Proposal:'>
A single duration type is used throughout CoAP, based on an
(8,4)-pseudo-FP giving a duration in seconds.</t>
<t hangText='Benefits:'>
Implementations can use a single piece of code for managing all
CoAP-related durations.</t>
<t>In addition, length information never needs to be managed for
durations that are embedded in other data structures: All durations
are expressed by a single byte.</t>
</list></t>
<t>It might be worthwhile to reserve one duration value, e.g. 0xFF, for
an indefinite duration.</t>
<figure anchor="duration-values"><artwork><![CDATA[
Duration Seconds Encoded
----------- ---------- -------
00:00:00 0x00000000 0x00
00:00:01 0x00000001 0x01
00:00:02 0x00000002 0x02
00:00:03 0x00000003 0x03
00:00:04 0x00000004 0x04
00:00:05 0x00000005 0x05
00:00:06 0x00000006 0x06
00:00:07 0x00000007 0x07
00:00:08 0x00000008 0x08
00:00:09 0x00000009 0x09
00:00:10 0x0000000a 0x0a
00:00:11 0x0000000b 0x0b
00:00:12 0x0000000c 0x0c
00:00:13 0x0000000d 0x0d
00:00:14 0x0000000e 0x0e
00:00:15 0x0000000f 0x0f
00:00:16 0x00000010 0x10
00:00:17 0x00000011 0x11
00:00:18 0x00000012 0x12
00:00:19 0x00000013 0x13
00:00:20 0x00000014 0x14
00:00:21 0x00000015 0x15
00:00:22 0x00000016 0x16
00:00:23 0x00000017 0x17
00:00:24 0x00000018 0x18
00:00:25 0x00000019 0x19
00:00:26 0x0000001a 0x1a
00:00:27 0x0000001b 0x1b
00:00:28 0x0000001c 0x1c
00:00:29 0x0000001d 0x1d
00:00:30 0x0000001e 0x1e
00:00:31 0x0000001f 0x1f
00:00:32 0x00000020 0x20
00:00:33 0x00000021 0x21
00:00:34 0x00000022 0x22
00:00:35 0x00000023 0x23
00:00:36 0x00000024 0x24
00:00:37 0x00000025 0x25
00:00:38 0x00000026 0x26
00:00:39 0x00000027 0x27
00:00:40 0x00000028 0x28
00:00:41 0x00000029 0x29
00:00:42 0x0000002a 0x2a
00:00:43 0x0000002b 0x2b
00:00:44 0x0000002c 0x2c
00:00:45 0x0000002d 0x2d
00:00:46 0x0000002e 0x2e
00:00:47 0x0000002f 0x2f
00:00:48 0x00000030 0x30
00:00:49 0x00000031 0x31
00:00:50 0x00000032 0x32
00:00:51 0x00000033 0x33
00:00:52 0x00000034 0x34
00:00:53 0x00000035 0x35
00:00:54 0x00000036 0x36
00:00:55 0x00000037 0x37
00:00:56 0x00000038 0x38
00:00:57 0x00000039 0x39
00:00:58 0x0000003a 0x3a
00:00:59 0x0000003b 0x3b
00:01:00 0x0000003c 0x3c
00:01:01 0x0000003d 0x3d
00:01:02 0x0000003e 0x3e
00:01:03 0x0000003f 0x3f
00:01:04 0x00000040 0x40
00:01:05 0x00000041 0x41
00:01:06 0x00000042 0x42
00:01:07 0x00000043 0x43
00:01:08 0x00000044 0x44
00:01:09 0x00000045 0x45
00:01:10 0x00000046 0x46
00:01:11 0x00000047 0x47
00:01:12 0x00000048 0x48
00:01:13 0x00000049 0x49
00:01:14 0x0000004a 0x4a
00:01:15 0x0000004b 0x4b
00:01:16 0x0000004c 0x4c
00:01:17 0x0000004d 0x4d
00:01:18 0x0000004e 0x4e
00:01:19 0x0000004f 0x4f
00:01:20 0x00000050 0x50
00:01:21 0x00000051 0x51
00:01:22 0x00000052 0x52
00:01:23 0x00000053 0x53
00:01:24 0x00000054 0x54
00:01:25 0x00000055 0x55
00:01:26 0x00000056 0x56
00:01:27 0x00000057 0x57
00:01:28 0x00000058 0x58
00:01:29 0x00000059 0x59
00:01:30 0x0000005a 0x5a
00:01:31 0x0000005b 0x5b
00:01:32 0x0000005c 0x5c
00:01:33 0x0000005d 0x5d
00:01:34 0x0000005e 0x5e
00:01:35 0x0000005f 0x5f
00:01:36 0x00000060 0x60
00:01:37 0x00000061 0x61
00:01:38 0x00000062 0x62
00:01:39 0x00000063 0x63
00:01:40 0x00000064 0x64
00:01:41 0x00000065 0x65
00:01:42 0x00000066 0x66
00:01:43 0x00000067 0x67
00:01:44 0x00000068 0x68
00:01:45 0x00000069 0x69
00:01:46 0x0000006a 0x6a
00:01:47 0x0000006b 0x6b
00:01:48 0x0000006c 0x6c
00:01:49 0x0000006d 0x6d
00:01:50 0x0000006e 0x6e
00:01:51 0x0000006f 0x6f
00:01:52 0x00000070 0x70
00:01:53 0x00000071 0x71
00:01:54 0x00000072 0x72
00:01:55 0x00000073 0x73
00:01:56 0x00000074 0x74
00:01:57 0x00000075 0x75
00:01:58 0x00000076 0x76
00:01:59 0x00000077 0x77
00:02:00 0x00000078 0x78
00:02:01 0x00000079 0x79
00:02:02 0x0000007a 0x7a
00:02:03 0x0000007b 0x7b
00:02:04 0x0000007c 0x7c
00:02:05 0x0000007d 0x7d
00:02:06 0x0000007e 0x7e
00:02:07 0x0000007f 0x7f
00:02:08 0x00000080 0x80
00:02:24 0x00000090 0x90
00:02:40 0x000000a0 0xa0
00:02:56 0x000000b0 0xb0
00:03:12 0x000000c0 0xc0
00:03:28 0x000000d0 0xd0
00:03:44 0x000000e0 0xe0
00:04:00 0x000000f0 0xf0
00:04:16 0x00000100 0x81
00:04:48 0x00000120 0x91
00:05:20 0x00000140 0xa1
00:05:52 0x00000160 0xb1
00:06:24 0x00000180 0xc1
00:06:56 0x000001a0 0xd1
00:07:28 0x000001c0 0xe1
00:08:00 0x000001e0 0xf1
00:08:32 0x00000200 0x82
00:09:36 0x00000240 0x92
00:10:40 0x00000280 0xa2
00:11:44 0x000002c0 0xb2
00:12:48 0x00000300 0xc2
00:13:52 0x00000340 0xd2
00:14:56 0x00000380 0xe2
00:16:00 0x000003c0 0xf2
00:17:04 0x00000400 0x83
00:19:12 0x00000480 0x93
00:21:20 0x00000500 0xa3
00:23:28 0x00000580 0xb3
00:25:36 0x00000600 0xc3
00:27:44 0x00000680 0xd3
00:29:52 0x00000700 0xe3
00:32:00 0x00000780 0xf3
00:34:08 0x00000800 0x84
00:38:24 0x00000900 0x94
00:42:40 0x00000a00 0xa4
00:46:56 0x00000b00 0xb4
00:51:12 0x00000c00 0xc4
00:55:28 0x00000d00 0xd4
00:59:44 0x00000e00 0xe4
01:04:00 0x00000f00 0xf4
01:08:16 0x00001000 0x85
01:16:48 0x00001200 0x95
01:25:20 0x00001400 0xa5
01:33:52 0x00001600 0xb5
01:42:24 0x00001800 0xc5
01:50:56 0x00001a00 0xd5
01:59:28 0x00001c00 0xe5
02:08:00 0x00001e00 0xf5
02:16:32 0x00002000 0x86
02:33:36 0x00002400 0x96
02:50:40 0x00002800 0xa6
03:07:44 0x00002c00 0xb6
03:24:48 0x00003000 0xc6
03:41:52 0x00003400 0xd6
03:58:56 0x00003800 0xe6
04:16:00 0x00003c00 0xf6
04:33:04 0x00004000 0x87
05:07:12 0x00004800 0x97
05:41:20 0x00005000 0xa7
06:15:28 0x00005800 0xb7
06:49:36 0x00006000 0xc7
07:23:44 0x00006800 0xd7
07:57:52 0x00007000 0xe7
08:32:00 0x00007800 0xf7
09:06:08 0x00008000 0x88
10:14:24 0x00009000 0x98
11:22:40 0x0000a000 0xa8
12:30:56 0x0000b000 0xb8
13:39:12 0x0000c000 0xc8
14:47:28 0x0000d000 0xd8
15:55:44 0x0000e000 0xe8
17:04:00 0x0000f000 0xf8
18:12:16 0x00010000 0x89
20:28:48 0x00012000 0x99
22:45:20 0x00014000 0xa9
1d 01:01:52 0x00016000 0xb9
1d 03:18:24 0x00018000 0xc9
1d 05:34:56 0x0001a000 0xd9
1d 07:51:28 0x0001c000 0xe9
1d 10:08:00 0x0001e000 0xf9
1d 12:24:32 0x00020000 0x8a
1d 16:57:36 0x00024000 0x9a
1d 21:30:40 0x00028000 0xaa
2d 02:03:44 0x0002c000 0xba
2d 06:36:48 0x00030000 0xca
2d 11:09:52 0x00034000 0xda
2d 15:42:56 0x00038000 0xea
2d 20:16:00 0x0003c000 0xfa
3d 00:49:04 0x00040000 0x8b
3d 09:55:12 0x00048000 0x9b
3d 19:01:20 0x00050000 0xab
4d 04:07:28 0x00058000 0xbb
4d 13:13:36 0x00060000 0xcb
4d 22:19:44 0x00068000 0xdb
5d 07:25:52 0x00070000 0xeb
5d 16:32:00 0x00078000 0xfb
6d 01:38:08 0x00080000 0x8c
6d 19:50:24 0x00090000 0x9c
7d 14:02:40 0x000a0000 0xac
8d 08:14:56 0x000b0000 0xbc
9d 02:27:12 0x000c0000 0xcc
9d 20:39:28 0x000d0000 0xdc
10d 14:51:44 0x000e0000 0xec
11d 09:04:00 0x000f0000 0xfc
12d 03:16:16 0x00100000 0x8d
13d 15:40:48 0x00120000 0x9d
15d 04:05:20 0x00140000 0xad
16d 16:29:52 0x00160000 0xbd
18d 04:54:24 0x00180000 0xcd
19d 17:18:56 0x001a0000 0xdd
21d 05:43:28 0x001c0000 0xed
22d 18:08:00 0x001e0000 0xfd
24d 06:32:32 0x00200000 0x8e
27d 07:21:36 0x00240000 0x9e
30d 08:10:40 0x00280000 0xae
33d 08:59:44 0x002c0000 0xbe
36d 09:48:48 0x00300000 0xce
39d 10:37:52 0x00340000 0xde
42d 11:26:56 0x00380000 0xee
45d 12:16:00 0x003c0000 0xfe
48d 13:05:04 0x00400000 0x8f
54d 14:43:12 0x00480000 0x9f
60d 16:21:20 0x00500000 0xaf
66d 17:59:28 0x00580000 0xbf
72d 19:37:36 0x00600000 0xcf
78d 21:15:44 0x00680000 0xdf
84d 22:53:52 0x00700000 0xef
91d 00:32:00 0x00780000 0xff (reserved)
]]></artwork></figure>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:03:50 |