CoRE Working Group                                            C. Bormann
Internet-Draft                                                 K. Hartke
Intended status: Informational                   Universitaet Bremen TZI
Expires: November 6, 2011                                    May 5, 2011


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

Abstract

   This short I-D makes a number of partially interrelated proposals how
   to solve certain problems in the CoRE WG's main protocol, the
   Constrained Application Protocol (CoAP).  The current version has
   been resubmitted to keep information about these proposals available;
   the proposals are not all fleshed out at this point in time.

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 November 6, 2011.

Copyright Notice

   Copyright (c) 2011 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.



Bormann & Hartke        Expires November 6, 2011                [Page 1]


Internet-Draft                  CoAP-misc                       May 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Content Negotiation  . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Accept Option  . . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  4.06 Not Acceptable  . . . . . . . . . . . . . . . . . . .  5
   3.  Conditional Request: If-Match  . . . . . . . . . . . . . . . .  6
     3.1.  If-Match Option  . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  4.12 Precondition Failed . . . . . . . . . . . . . . . . .  6
   4.  URI Authorities with Binary Adresses . . . . . . . . . . . . .  7
   5.  User-defined Option  . . . . . . . . . . . . . . . . . . . . .  9
   6.  Payload-Length Option  . . . . . . . . . . . . . . . . . . . . 10
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
     10.2. Informative References . . . . . . . . . . . . . . . . . . 15
   Appendix A.  The Cemetery (Things we won't do) . . . . . . . . . . 16
     A.1.  Stateful URI compression . . . . . . . . . . . . . . . . . 16
   Appendix B.  Experimental Options  . . . . . . . . . . . . . . . . 18
     B.1.  Options indicating absolute time . . . . . . . . . . . . . 18
     B.2.  Representing Durations . . . . . . . . . . . . . . . . . . 19
     B.3.  Rationale  . . . . . . . . . . . . . . . . . . . . . . . . 20
     B.4.  Pseudo-Floating Point  . . . . . . . . . . . . . . . . . . 21
     B.5.  A Duration Type for CoAP . . . . . . . . . . . . . . . . . 22
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
























Bormann & Hartke        Expires November 6, 2011                [Page 2]


Internet-Draft                  CoAP-misc                       May 2011


1.  Introduction

   The CoRE WG is tasked with standardizing an Application Protocol for
   Constrained Networks/Nodes, CoAP [I-D.ietf-core-coap].  This protocol
   is intended to provide RESTful [REST] services not unlike HTTP
   [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.

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

   o  reducing implementation complexity in order to minimize code size,

   o  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,

   o  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].  The solutions proposed to
   these problems are somewhat interrelated and are therefore presented
   in one draft.

   The appendix contains the "CoAP cemetery" (possibly later to move
   into its own draft), documenting roads that the WG decided not to
   take, in order to spare readers from reinventing them in vain.

   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 {RFC2119}}.

   The term "byte" is used in its now customary sense as a synonym for
   "octet".












Bormann & Hartke        Expires November 6, 2011                [Page 3]


Internet-Draft                  CoAP-misc                       May 2011


2.  Content Negotiation

   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 [RFC2616] 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
   when included one or more times in a request, carry one or more media
   types, each of which is an acceptable media type for the client, in
   the order of preference.  If no Accept option is given, the client
   does not express a preference.

   Depending on whether the Accept Option is defined as a critical or an
   elective option, the meaning of the option is slightly different:

   Critical:  The client is not interested in a representation of the
      resource if the server is unable or unwilling to return it in one
      of the specified media types.  (For this purpose, a new response
      code, 4.06 Not Acceptable, is needed.)

   Elective:  The client prefers the representation returned by the
      server to be in one of the media types, but is willing to accept
      the response also if the server returns a representation in a
      different media type.

2.1.  Accept Option

      +-----+----------+---------------+--------+--------+---------+
      | No. | C/E      | Name          | Format | Length | Default |
      +-----+----------+---------------+--------+--------+---------+
      | TBD | Critical | Accept.Only   | uint   | 0-2 B  | (none)  |
      |     |          |               |        |        |         |
      | TBD | Elective | Accept.Prefer | uint   | 0-2 B  | (none)  |
      +-----+----------+---------------+--------+--------+---------+








Bormann & Hartke        Expires November 6, 2011                [Page 4]


Internet-Draft                  CoAP-misc                       May 2011


   TODO:  Decide which of these options we need, or whether both should
      be available.

2.2.  4.06 Not Acceptable

   Like HTTP 406 "Not Acceptable", but with a human-readable diagnostic
   message instead of a representation containing a list of available
   representation characteristics and location(s).











































Bormann & Hartke        Expires November 6, 2011                [Page 5]


Internet-Draft                  CoAP-misc                       May 2011


3.  Conditional Request: If-Match

   The If-Match Option MAY be used to make a request conditional on the
   current existence or value of an ETag for one or more representations
   of the target resource.  If-Match is generally useful for resource
   update requests, such as PUT requests, as a means for protecting
   against accidental overwrites when multiple clients are acting in
   parallel on the same resource (i.e., the "lost update" problem).

   The value of an If-Match option is either an ETag or the empty
   string.  An empty string places the precondition on the existence of
   any current representation for the target resource.

   The If-Match Option can occur multiple times.  If any of the ETags
   given as an option value match the ETag of the selected
   representation for the target resource, or if an If-Match Option with
   an empty string as option value is given and any current
   representation exists for the target resource, then the server MAY
   perform the request method as if the If-Match Option was not present.

   If none of the ETags match and, if an empty string is given, no
   current representation exists at all, the server MUST NOT perform the
   requested method.  Instead, the server MUST respond with the 4.12
   (Precondition Failed) response code.

   If the request would, without the If-Match Options, result in
   anything other than a 2.xx or 4.12 response code, then any If-Match
   Options MUST be ignored.

3.1.  If-Match Option

         +-----+----------+----------+--------+--------+---------+
         | No. | C/E      | Name     | Format | Length | Default |
         +-----+----------+----------+--------+--------+---------+
         | TBD | Critical | If-Match | opaque | 0-8 B  | (none)  |
         +-----+----------+----------+--------+--------+---------+

   If-Match Options are critical.

   The If-Match Option is repeatable.

3.2.  4.12 Precondition Failed

   Like HTTP 412 (Precondition Failed).







Bormann & Hartke        Expires November 6, 2011                [Page 6]


Internet-Draft                  CoAP-misc                       May 2011


4.  URI Authorities with Binary Adresses

   One problem with the way URI authorities are represented in the URI
   syntax 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.

   o  If the number of bytes is 2, the destination IP address of the
      packet transporting the CoAP message is implied.

   o  If the number of bytes is 4 or 6, the first four bytes of the
      option value are an IPv4 address in binary.

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

   o  If the number of bytes is 16 or 18, the first 16 bytes are an IPv6
      address.

   o  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, or inserted into a Proxy-
   Uri. Examples:

   +-------------+------------------+---------+------------------------+
   | Proxy-Uri   | Uri-Authority-Bi | Uri-Pat | URI                    |
   |             | nary             | h       |                        |
   +-------------+------------------+---------+------------------------+
   | (none)      | (none)           | (none)  | "/"                    |
   |             |                  |         |                        |
   | (none)      | (none)           | 'temp'  | "/temp"                |
   |             |                  |         |                        |
   | (none)      | 2 bytes: 61616   | 'temp'  | "coap://[DA]:61616/tem |
   |             |                  |         | p"                     |
   |             |                  |         |                        |
   | (none)      | 16 bytes:        | temp    | "coap://[2000::1]/temp |
   |             | 2000::1          |         | "                      |
   |             |                  |         |                        |
   | 'http://'   | 10 bytes:        | (none)  | "http://[DA::123:45]:6 |
   |             | ::123:45 + 616   |         | 16"                    |
   |             |                  |         |                        |




Bormann & Hartke        Expires November 6, 2011                [Page 7]


Internet-Draft                  CoAP-misc                       May 2011


   | 'http:///te | 18 bytes:        | (none)  | "http://[2000::1]:616/ |
   | mp'         | 2000::1 + 616    |         | temp"                  |
   +-------------+------------------+---------+------------------------+
















































Bormann & Hartke        Expires November 6, 2011                [Page 8]


Internet-Draft                  CoAP-misc                       May 2011


5.  User-defined Option

   To enable experimentation and community-specific options, option
   number 14 (the first NOP option) can also be used as a user-defined
   option.  For this application, the option value has one or more
   bytes, the semantics of which are defined by prior agreement between
   the communicating partners.

   It is RECOMMENDED to start the option value with a unique identifier,
   e.g., the SDNV [RFC5050] of the enterprise number of the organisation
   defining the option, possibly followed by additional discriminating
   bits or bytes.

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |1 0 0 0 0 0 0 1|0 1 1 1 0 0 1 1| private opt-id|   value...    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       \___SDNV of enterprise number___/

          Figure 1: Example option value for user-defined option

   User-defined Options are elective.

   The User-defined Option is repeatable.

   Potential options:

        +-----+----------+------+-------------+---------+---------+
        | No. | C/E      | Name | Format      | Length  | Default |
        +-----+----------+------+-------------+---------+---------+
        | 14  | Elective | User | (see below) | 1-270 B | (empty) |
        +-----+----------+------+-------------+---------+---------+




















Bormann & Hartke        Expires November 6, 2011                [Page 9]


Internet-Draft                  CoAP-misc                       May 2011


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

   This can be solved using 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.)



































Bormann & Hartke        Expires November 6, 2011               [Page 10]


Internet-Draft                  CoAP-misc                       May 2011


7.  IANA Considerations

   This draft adds option numbers to Table 2 of [I-D.ietf-core-coap],
   resulting in:

   TBD.













































Bormann & Hartke        Expires November 6, 2011               [Page 11]


Internet-Draft                  CoAP-misc                       May 2011


8.  Security Considerations

   TBD.
















































Bormann & Hartke        Expires November 6, 2011               [Page 12]


Internet-Draft                  CoAP-misc                       May 2011


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













































Bormann & Hartke        Expires November 6, 2011               [Page 13]


Internet-Draft                  CoAP-misc                       May 2011


10.  References

10.1.  Normative References

   [I-D.ietf-core-coap]
              Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
              "Constrained Application Protocol (CoAP)",
              draft-ietf-core-coap-06 (work in progress), May 2011.

   [I-D.ietf-core-observe]
              Hartke, K. and Z. Shelby, "Observing Resources in CoAP",
              draft-ietf-core-observe-02 (work in progress), March 2011.

   [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", draft-ietf-httpbis-p1-messaging-14 (work in
              progress), April 2011.

   [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",
              draft-ietf-httpbis-p4-conditional-14 (work in progress),
              April 2011.

   [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",
              draft-ietf-httpbis-p6-cache-14 (work in progress),
              April 2011.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.







Bormann & Hartke        Expires November 6, 2011               [Page 14]


Internet-Draft                  CoAP-misc                       May 2011


10.2.  Informative References

   [REST]     Fielding, R., "Architectural Styles and the Design of
              Network-based Software Architectures", 2000.

   [RFC5050]  Scott, K. and S. Burleigh, "Bundle Protocol
              Specification", RFC 5050, November 2007.












































Bormann & Hartke        Expires November 6, 2011               [Page 15]


Internet-Draft                  CoAP-misc                       May 2011


Appendix A.  The Cemetery (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.  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.

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

            Figure 2: Option for offering a TeRI in a response

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






Bormann & Hartke        Expires November 6, 2011               [Page 16]


Internet-Draft                  CoAP-misc                       May 2011


   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.

   Drawbacks:  Adds considerable state and complexity to the protocol.

      It turns out that real CoAP URIs are short enough that TeRIs are
      not needed.

      (Discuss the security implications of TeRIs.)







































Bormann & Hartke        Expires November 6, 2011               [Page 17]


Internet-Draft                  CoAP-misc                       May 2011


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:

   o  "Date", defined in Section 14.18 in [RFC2616] (Section 9.3 in
      [I-D.ietf-httpbis-p1-messaging]), giving the absolute time a
      response was generated;

   o  "Last-Modified", defined in Section 14.29 in [RFC2616], (Section
      6.6 in [I-D.ietf-httpbis-p4-conditional], giving the absolute time
      of when the origin server believes the resource representation was
      last modified;

   o  "If-Modified-Since", defined in Section 14.25 in [RFC2616],
      "If-Unmodified-Since", defined in Section 14.28 in [RFC2616], and
      "If-Range", defined in Section 14.27 in [RFC2616] can be used to
      supply absolute time to gate a conditional request;

   o  "Expires", defined in Section 14.21 in [RFC2616] (Section 3.3 in
      [I-D.ietf-httpbis-p6-cache]), giving the absolute time after which
      a response is considered stale.

   o  The more obscure headers "Retry-After", defined in Section 14.37
      in [RFC2616], and "Warning", defined in section 14.46 in
      [RFC2616], also may employ absolute time.

   [I-D.ietf-core-coap] 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] 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.



Bormann & Hartke        Expires November 6, 2011               [Page 18]


Internet-Draft                  CoAP-misc                       May 2011


   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.

   (Also: Discuss nodes without clocks.)

B.2.  Representing Durations

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

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

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





Bormann & Hartke        Expires November 6, 2011               [Page 19]


Internet-Draft                  CoAP-misc                       May 2011


           Figure 3: Duration in (8,4) pseudo-FP representation

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

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


                Figure 4: Decoding an (8,4) pseudo-FP value

   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.

B.3.  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:




Bormann & Hartke        Expires November 6, 2011               [Page 20]


Internet-Draft                  CoAP-misc                       May 2011


   o  the *resolution*.  What rounding error is acceptable?

   o  the *range*.  What is the maximum duration that needs to be
      represented?

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

B.4.  Pseudo-Floating Point

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

   o  simple CPUs often don't have support for floating-point datatypes

   o  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 3 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 4.




Bormann & Hartke        Expires November 6, 2011               [Page 21]


Internet-Draft                  CoAP-misc                       May 2011


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

B.5.  A Duration Type for CoAP

   CoAP needs durations in a number of places.  In [I-D.ietf-core-coap],
   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 5 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



Bormann & Hartke        Expires November 6, 2011               [Page 22]


Internet-Draft                  CoAP-misc                       May 2011


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



Bormann & Hartke        Expires November 6, 2011               [Page 23]


Internet-Draft                  CoAP-misc                       May 2011


          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



Bormann & Hartke        Expires November 6, 2011               [Page 24]


Internet-Draft                  CoAP-misc                       May 2011


          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



Bormann & Hartke        Expires November 6, 2011               [Page 25]


Internet-Draft                  CoAP-misc                       May 2011


          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



Bormann & Hartke        Expires November 6, 2011               [Page 26]


Internet-Draft                  CoAP-misc                       May 2011


          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



Bormann & Hartke        Expires November 6, 2011               [Page 27]


Internet-Draft                  CoAP-misc                       May 2011


      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)

                                 Figure 5
































Bormann & Hartke        Expires November 6, 2011               [Page 28]


Internet-Draft                  CoAP-misc                       May 2011


Authors' Addresses

   Carsten Bormann
   Universitaet Bremen TZI
   Postfach 330440
   Bremen  D-28359
   Germany

   Phone: +49-421-218-63921
   Fax:   +49-421-218-7000
   Email: cabo@tzi.org


   Klaus Hartke
   Universitaet Bremen TZI
   Postfach 330440
   Bremen  D-28359
   Germany

   Phone: +49-421-218-63905
   Fax:   +49-421-218-7000
   Email: hartke@tzi.org





























Bormann & Hartke        Expires November 6, 2011               [Page 29]