Miscellaneous additions to CoAP
draft-bormann-coap-misc-05

Abstract

This short I-D makes a number of partially interrelated proposals how to solve certain problems in the CoRE WG's main protocol, CoAP.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on January 7, 2011.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1.  Introduction
2.  A Compact Accept Option
3.  URI encoding
    3.1.  Stateful URI compression
    3.2.  Support for URIs with Binary Adresses
    3.3.  Where are Uri Options Used?
4.  Block-wise transfers
    4.1.  The Block Option
5.  Option Encoding
    5.1.  A More Efficient Option Encoding
    5.2.  Critical Options
    5.3.  Errors in Options
    5.4.  Payload-Length Option
    5.5.  Making the Etag option useful
6.  IANA Considerations
7.  Security Considerations
    7.1.  Amplification Attacks
8.  Acknowledgements
9.  References
    9.1.  Normative References
    9.2.  Informative References
Appendix A.  Things we won’t do
    A.1.  An efficient stateless URI encoding
    A.2.  Media-Types with Self-Describing Length
Appendix B.  Experimental Options
    B.1.  Options indicating absolute time
Appendix C.  Rationale: Representing Durations
    C.1.  Text for section 3.2.1 of coap-01
    C.2.  Rationale
    C.3.  Pseudo-Floating Point
    C.4.  A Duration Type for CoAP
§  Authors' Addresses

1.  Introduction

The CoRE WG is tasked with standardizing an Application Protocol for Constrained Networks/Nodes, CoAP. This protocol is intended to provide RESTful [REST] (Fielding, R., “Architectural Styles and the Design of Network-based Software Architectures,” 2000.) services not unlike HTTP [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.), 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.

This objective requires restraint in a number of sometimes conflicting ways:

• reducing implementation complexity in order to minimize code size,
• 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,
• reducing requirements on the environment such as stable storage, good sources of randomness or user interaction capabilities.

This draft attempts to address a number of problems not yet adequately solved in [I‑D.ietf‑core‑coap] (Shelby, Z., Frank, B., and D. Sturek, “Constrained Application Protocol (CoAP),” June 2010.). The solutions proposed to these problems are somewhat interrelated and are therefore presented in one draft.

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 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) and indicate requirement levels for compliant CoAP implementations.

2.  A Compact Accept Option

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.

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 Figure 1 (Accept option value: A sequence of media types)). If no Accept option is given, the client does not express a preference.

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

Accept also has to be given an option type code, e.g. 6, in Table 2 of [I‑D.ietf‑core‑coap] (Shelby, Z., Frank, B., and D. Sturek, “Constrained Application Protocol (CoAP),” June 2010.). (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.)

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 [I‑D.ietf‑core‑coap] (Shelby, Z., Frank, B., and D. Sturek, “Constrained Application Protocol (CoAP),” June 2010.).

Proposal:

Add an Accept Option.

Benefits:

A Server does not need to specify one URI each for every possible media type that it wants to serve a resource under.

(See also Appendix A.2 (Media-Types with Self-Describing Length).)

3.  URI encoding

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

/.well-known/resources

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?

Several proposals have been made on the CoRE mailing list, e.g. applying the principle of base64-encoding [RFC4648] (Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” October 2006.) 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.

Appendix A.1 (An efficient stateless URI encoding) 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.

3.1.  Stateful URI compression

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.

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 Temporary Resource Identifier, TeRI for short. This could be expressed by a response option as shown in Figure 2 (Option for offering a TeRI in a response).

        0
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    duration   |    TeRI...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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.

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.

Proposal:

Add a TeRI option (e.g., number 2) that can be used in CoAP requests and responses.

Add a way to indicate a TeRI and its duration in a link-value.

Do not add any form of stateless URI encoding.

Benefits:

Much higher reduction of message size than any stateless URI encoding could achieve.

As the use of TeRIs is entirely optional, minimal complexity nodes can get by without implementing them.

3.2.  Support for URIs with Binary Adresses

As defined in [I‑D.ietf‑core‑coap] (Shelby, Z., Frank, B., and D. Sturek, “Constrained Application Protocol (CoAP),” June 2010.), the Uri option does not provide a way to distinguish an absolute-URI from an absolute-path [RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.): the leading slash is omitted from the latter. (Ticket #12.)

The proposal to fix this is to split the option into three parts: Uri-Scheme for the URI Scheme, Uri-Authority for Host/Port and Uri-Path for the absolute-path.

A further problem with that version is that the authority part can be very bulky if it encodes an IPv6 address in ASCII.

Proposal:

Provide an option Uri-Authority-Binary that can be an even number of bytes between 2 and 18 except 12 or 14.

• If the number of bytes is 2, the destination IP address of the packet transporting the CoAP message is implied.
• If the number of bytes is 4 or 6, the first four bytes of the option value are an IPv4 address in binary.
• 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.
• If the number of bytes is 16 or 18, the first 16 bytes are an IPv6 address.
• If two more bytes remain, this is a port number (as always in network byte order).

The resulting authority is (conceptually translated into ASCII and) used in place of an Uri-Authority option. Examples:

3.3.  Where are Uri Options Used?

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.

In a delayed Confirmable message that contains an asynchronous response to a GET, the URI is included again (“echoed back”).

In addition to the context provided by including the URI again in delayed responses, we propose adding a Token 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.

4.  Block-wise transfers

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.

This section proposes options to enable block-wise 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.)

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 szx (size exponent); the actual block size is then 1 << (szx + 4).

4.1.  The Block Option

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 size bytes starting at blocknr << (szx + 4). 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.

        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 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

(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.)

The block option is used in one of three roles:

• 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).
• 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).
• 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).

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

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.

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.

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

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

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.

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

Proposal:

Add a Block option (e.g., number 8) that can be used for block-wise transfers.

Benefits:

Transfers larger than can be accommodated in constrained-network link-layer packets can be performed in smaller blocks.

No hard-to-manage conversation state is created at the adaptation layer or IP layer for fragmentation.

The transfer of each block is acknowledged, enabling retransmission if required.

Both sides have a say in the block size that actually will be used.

TBD:

Give examples with detailed message flows for a block-wise GET, PUT and POST.

5.  Option Encoding

The option encoding in [I‑D.ietf‑core‑coap] (Shelby, Z., Frank, B., and D. Sturek, “Constrained Application Protocol (CoAP),” June 2010.) 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.

5.1.  A More Efficient Option Encoding

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

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.

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.

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 (Figure 4 (Option delta/length representation with small range)).

      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          |
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

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 Section 5.2 (Critical Options) 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:

• delta = 2 (option 2, body)
• delta = 12 (option 14 = no-op, no body)
• delta = 13 (option 27, body)

In the unlikely case that only option 40 is needed, the sequence would be:

• delta = 14 (option 14 = no-op, no body)
• delta = 14 (option 28 = no-op, bo body)
• delta = 12 (option 40, body)

5.2.  Critical Options

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 elective. However, some new options may be critical, 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.)

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

Implementing this proposal requires some renumbering of options from [I‑D.ietf‑core‑coap] (Shelby, Z., Frank, B., and D. Sturek, “Constrained Application Protocol (CoAP),” June 2010.).

Note that most options that are designated as critical are not 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.

5.3.  Errors in Options

When a message contains a critical option that is not understood by the receiver, we say that decoding fails.

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

If the decoding of a message fails, the processing depends on the message type:

• NCN messages and RST messages with decode failures are always silently ignored.
• 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,
• 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.)

5.4.  Payload-Length Option

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.

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 payload-length bytes is then actually one or more additional messages.)

5.5.  Making the Etag option useful

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.

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.

Problem:

The Etag option is not useful without an equivalent of If-None-Match.

Proposal:

Make Etags useful by defining a new Option I-Have: 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.

6.  IANA Considerations

This draft adds the following option numbers to Table 2 of [I‑D.ietf‑core‑coap] (Shelby, Z., Frank, B., and D. Sturek, “Constrained Application Protocol (CoAP),” June 2010.):

With the new option encoding and the proposal for differentiating critical from elective options, the total list becomes:

(The upper limit of n 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).

(Subscription-related options are discussed in [I‑D.hartke‑coap‑observe] (Hartke, K. and C. Bormann, “Observing Resources in CoAP,” June 2010.), so the following option from [I‑D.ietf‑core‑coap] (Shelby, Z., Frank, B., and D. Sturek, “Constrained Application Protocol (CoAP),” June 2010.) is not further discussed here:)

7.  Security Considerations

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

7.1.  Amplification Attacks

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

8.  Acknowledgements

This work was partially funded by the Klaus Tschira Foundation.

Of course, much of the content of this draft is the result of discussions with the [I‑D.ietf‑core‑coap] (Shelby, Z., Frank, B., and D. Sturek, “Constrained Application Protocol (CoAP),” June 2010.) authors. Tokens were suggested by Gilman Tolle.

9.  References

9.1. Normative References

9.2. Informative References

Appendix A.  Things we won’t do

This annex documents roads that the WG decided not to take, in order to spare readers from reinventing them in vain.

A.1.  An efficient stateless URI encoding

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 [RFC1951] (Deutsch, P., “DEFLATE Compressed Data Format Specification version 1.3,” May 1996.)) rather ineffective.

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.

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:

%.aeinorst

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 [RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.); 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 [RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.).

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 Figure 5 (A nibble-based URI encoding).

  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
+---+---+---+---+---+---+---+---+---+---+---+---+

An example encoding for /.well-known/resources (where the initial slash is left out, as proposed for abs-path URIs) is given in Figure 6 (Nibble-based URI encoding: 21 -> 15 bytes). 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.)

     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

A.2.  Media-Types with Self-Describing Length

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; Figure 7 (A self-describing media type representation)).

An self-describing representation for long mediatypes could look like this:

        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)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Instead, we assume for now that CoAP-01 will switch to a single-byte media type encoding.

Appendix B.  Experimental Options

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.

B.1.  Options indicating absolute time

HTTP has a number of headers that may indicate absolute time:

• Date, defined in Section 14.18 in [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) (Section 9.3 in [I‑D.ietf‑httpbis‑p1‑messaging] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., and J. Reschke, “HTTP/1.1, part 1: URIs, Connections, and Message Parsing,” March 2010.)), giving the absolute time a response was generated;
• Last-Modified, defined in Section 14.29 in [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.), (Section 6.6 in [I‑D.ietf‑httpbis‑p4‑conditional] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., and J. Reschke, “HTTP/1.1, part 4: Conditional Requests,” March 2010.), giving the absolute time of when the origin server believes the resource representation was last modified;
• If-Modified-Since, defined in Section 14.25 in [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.), If-Unmodified-Since, defined in Section 14.28 in [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.), and If-Range, defined in Section 14.27 in [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) can be used to supply absolute time to gate a conditional request;
• Expires, defined in Section 14.21 in [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) (Section 3.3 in [I‑D.ietf‑httpbis‑p6‑cache] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., and J. Reschke, “HTTP/1.1, part 6: Caching,” March 2010.)), giving the absolute time after which a response is considered stale.
• The more obscure headers Retry-After, defined in Section 14.37 in [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.), and Warning, defined in section 14.46 in [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.), also may employ absolute time.

[I‑D.ietf‑core‑coap] (Shelby, Z., Frank, B., and D. Sturek, “Constrained Application Protocol (CoAP),” June 2010.) defines a single Date 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 [I‑D.ietf‑httpbis‑p6‑cache] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., and J. Reschke, “HTTP/1.1, part 6: Caching,” March 2010.) make use of both Date and Last-Modified, combined with Expires. The specific semantics required for CoAP needs further consideration.

In addition to the definition of the semantics, an encoding for absolute times needs to be specified.

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.

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.

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.

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

For experiments, an experimental Date option is defined with the semantics of HTTP’s Last-Modified. 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.

However, that option is not really that useful until there is a If-Modified-Since option as well.

Appendix C.  Rationale: Representing Durations

C.1.  Text for section 3.2.1 of coap-01

Various message types used in CoAP need the representation of durations, 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 (Figure 8 (Duration in (8,4) pseudo-FP representation)).

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
| 0...          value           |
+---+---+---+---+---+---+---+---+

+---+---+---+---+---+---+---+---+
| 1... mantissa |    exponent   |
+---+---+---+---+---+---+---+---+

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.

The (n,e)-pseudo-FP format can be decoded with a single line of code (plus a couple of constant definitions), as demonstrated in Figure 9 (Decoding an (8,4) pseudo-FP value).

#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))

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.

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.

C.2.  Rationale

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 time_t (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 (struct timeval) and then later nanosecond (struct timespec) resolution.

Three decisions need to be made for each application of the concept of duration:

• the resolution. What rounding error is acceptable?
• the range. What is the maximum duration that needs to be represented?
• the number of bits that can be expended.

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.

C.3.  Pseudo-Floating Point

Constrained systems typically avoid the use of floating-point (FP) values, as

• simple CPUs often don’t have support for floating-point datatypes
• software floating-point libraries are expensive in code size and slow.

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.

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.

The idea of introducing pseudo-FP is to obtain the increased range provided by embedding an exponent, without necessarily getting stuck with hardware datatypes or inefficient software floating-point libraries.

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. Figure 8 (Duration in (8,4) pseudo-FP representation) illustrates an (8,4)-pseudo-FP value.

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.

The (n,e)-pseudo-FP format can be decoded with a single line of code (plus a couple of constant definition), as demonstrated in Figure 9 (Decoding an (8,4) pseudo-FP value).

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.

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

C.4.  A Duration Type for CoAP

CoAP needs durations in a number of places. In [I‑D.ietf‑core‑coap] (Shelby, Z., Frank, B., and D. Sturek, “Constrained Application Protocol (CoAP),” June 2010.), durations occur in the option Subscription-lifetime as well as in the option Max-age. (Note that the option Date is not a duration, but a point in time.) Other durations of this kind may be added later.

Most durations relevant to CoAP are best expressed with a minimum resolution of one second. More detailed resolutions are unlikely to provide much benefit.

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. Figure 10 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.)

Proposal:

A single duration type is used throughout CoAP, based on an (8,4)-pseudo-FP giving a duration in seconds.

Benefits:

Implementations can use a single piece of code for managing all CoAP-related durations.

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.

It might be worthwhile to reserve one duration value, e.g. 0xFF, for an indefinite duration.

    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)

Authors' Addresses