Observing Resources in CoAP
draft-ietf-core-observe-14

Internet-Draft         Observing Resources in CoAP             June 2014

Appendix B.  Changelog

   [Note to RFC Editor: Please remove this section before publication.]

   Changes from ietf-13 to ietf-14:

   o  Updated references.

   Changes from ietf-12 to ietf-13:

   o  Extended the Observe Option in requests to not only add but also
      remove an entry in the list of observers, depending on the option
      value.

      Note:  The value of the Observe Option in a registration request
         may now be any sequence of bytes that encodes the unsigned
         integer 0, i.e., 0x'', 0x'00', 0x'00 00' or 0x'00 00 00'.

   o  Removed the 7.31 Code for cancellation.

   Changes from ietf-11 to ietf-12:

   o  Introduced the 7.31 Code to request the cancellation of a pending
      request.

   o  Made the algorithm for superseding an outstanding transmission
      OPTIONAL.

   o  Clarified that the entry in the list of observers is removed if
      the client fails to acknowledge a confirmable notification before
      the last retransmission attempt times out (#350).

   o  Simplified the text on cancellation (#352) and the handling of
      Reset messages (#353).

   Changes from ietf-10 to ietf-11:

   o  Pointed out that client and server clocks may differ in their
      realization of the SI second, and added robustness to the existing
      reordering scheme by reducing the maximum notification rate to
      32768 notifications per second (#341).

   Changes from ietf-09 to ietf-10:

   o  Required consistent sequence numbers across requests (#333).

   o  Clarified that a server needs to update the entry in the list of
      observers instead of adding a new entry if the endpoint/token pair

Hartke                   Expires January 1, 2015               [Page 27]
Internet-Draft         Observing Resources in CoAP             June 2014

      is already present.

   o  Allowed that a client uses a token that is currently in use to
      ensure that it's still in the list of observers.  This is possible
      because sequence numbers are now consistent across requests and
      servers won't add a new entry for the same token.

   o  Improved text on the transmission of non-confirmable notifications
      to match Section 3.1.2 of RFC 5405 more closely.

   o  Updated examples to use UCUM units.

   o  Moved Appendix B into the introduction.

   Changes from ietf-08 to ietf-09:

   o  Removed the side effects of requests on existing observations.
      This includes removing that

      *  the client can use a GET request to cancel an observation;

      *  the server updates the entry in the list of observers instead
         of adding a new entry if the client is already present (#258,
         #281).

   o  Clarified that a resource (and hence an observation relationship)
      is identified by the request options that are part of the Cache-
      Key (#258).

   o  Clarified that a non-2.xx notification MUST NOT include an Observe
      Option.

   o  Moved block-wise transfer of notifications to [I-D.ietf-core-
      block].

   Changes from ietf-07 to ietf-08:

   o  Expanded text on transmitting a notification while a previous
      transmission is pending (#242).

   o  Changed reordering detection to use a fixed time span of 128
      seconds instead of EXCHANGE_LIFETIME (#276).

   o  Removed the use of the freshness model to determine if the client
      is still on the list of observers.  This includes removing that

      *  the client assumes that it has been removed from the list of
         observers when Max-Age ends;

Hartke                   Expires January 1, 2015               [Page 28]
Internet-Draft         Observing Resources in CoAP             June 2014

      *  the server sets the Max-Age Option of a notification to a value
         that indicates when the server will send the next notification;

      *  the server uses a number of retransmit attempts such that
         removing a client from the list of observers before Max-Age
         ends is avoided (#235);

      *  the server may remove the client from all lists of observers
         when the transmission of a confirmable notification ultimately
         times out.

   o  Changed that an unrecognized critical option in a request must
      actually have no effect on the state of any observation
      relationship to any resource, as the option could lead to a
      different target resource.

   o  Clarified that client implementations must be prepared to receive
      each notification equally as a confirmable or a non-confirmable
      message, regardless of the message type of the request and of any
      previous notification.

   o  Added a requirement for sending a confirmable notification at
      least every 24 hours before continuing with non-confirmable
      notifications (#221).

   o  Added congestion control considerations from [I-D.bormann-core-
      congestion-control-02].

   o  Recommended that the client waits for a randomized time after the
      freshness of the latest notification expired before re-
      registering.  This prevents that multiple clients observing a
      resource perform a GET request at the same time when the need to
      re-register arises.

   o  Changed reordering detection from 'MAY' to 'SHOULD', as the goal
      of the protocol (to keep the observed state as closely in sync
      with the actual state as possible) is not optional.

   o  Fixed the length of the Observe Option (3 bytes) in the table in
      Section 2.

   o  Replaced the 'x' in the No-Cache-Key column in the table in
      Section 2 with a '-', as the Observe Option doesn't have the No-
      Cache-Key flag set, even though it is not part of the cache key.

   o  Updated examples.

   Changes from ietf-06 to ietf-07:

Hartke                   Expires January 1, 2015               [Page 29]
Internet-Draft         Observing Resources in CoAP             June 2014

   o  Moved to 24-bit sequence numbers to allow for up to 15000
      notifications per second per client and resource (#217).

   o  Re-numbered option number to use Unsafe/Safe and Cache-Key
      compliant numbers (#241).

   o  Clarified how to react to a Reset message that is sent in reply to
      a non-confirmable notification (#225).

   o  Clarified the semantics of the "obs" link target attribute (#236).

   Changes from ietf-05 to ietf-06:

   o  Improved abstract and introduction to say that the protocol is
      about best effort and eventual consistency (#219).

   o  Clarified that the value of the Observe Option in a request must
      have zero length.

   o  Added requirement that the sequence number must be updated each
      time a server retransmits a notification.

   o  Clarified that a server must remove a client from the list of
      observers when it receives a GET request with an unrecognized
      critical option.

   o  Updated the text to use the endpoint concept from [I-D.ietf-core-
      coap] (#224).

   o  Improved the reordering text (#223).

   Changes from ietf-04 to ietf-05:

   o  Recommended that a client does not re-register while a new
      notification from the server is still likely to arrive.  This is
      to avoid that the request of the client and the last notification
      after max-age cross over each other (#174).

   o  Relaxed requirements when sending a Reset message in reply to non-
      confirmable notifications.

   o  Added an implementation note about careless GET requests (#184).

   o  Updated examples.

   Changes from ietf-03 to ietf-04:

Hartke                   Expires January 1, 2015               [Page 30]
Internet-Draft         Observing Resources in CoAP             June 2014

   o  Removed the "Max-OFE" Option.

   o  Allowed a Reset message in reply to non-confirmable notifications.

   o  Added a section on cancellation.

   o  Updated examples.

   Changes from ietf-02 to ietf-03:

   o  Separated client-side and server-side requirements.

   o  Fixed uncertainty if client is still on the list of observers by
      introducing a liveliness model based on Max-Age and a new option
      called "Max-OFE" (#174).

   o  Simplified the text on message reordering (#129).

   o  Clarified requirements for intermediaries.

   o  Clarified the combination of blockwise transfers with
      notifications (#172).

   o  Updated examples to show how the state observed by the client
      becomes eventually consistent with the actual state on the server.

   o  Added examples for parameterization of observable resource.

   Changes from ietf-01 to ietf-02:

   o  Removed the requirement of periodic refreshing (#126).

   o  The new "Observe" Option replaces the "Lifetime" Option.

   o  Introduced a new mechanism to detect message reordering.

   o  Changed 2.00 (OK) notifications to 2.05 (Content) notifications.

   Changes from ietf-00 to ietf-01:

   o  Changed terminology from "subscriptions" to "observation
      relationships" (#33).

   o  Changed the name of the option to "Lifetime".

   o  Clarified establishment of observation relationships.

Hartke                   Expires January 1, 2015               [Page 31]
Internet-Draft         Observing Resources in CoAP             June 2014

   o  Clarified that an observation is only identified by the URI of the
      observed resource and the identity of the client (#66).

   o  Clarified rules for establishing observation relationships (#68).

   o  Clarified conditions under which an observation relationship is
      terminated.

   o  Added explanation on how clients can terminate an observation
      relationship before the lifetime ends (#34).

   o  Clarified that the overriding objective for notifications is
      eventual consistency of the actual and the observed state (#67).

   o  Specified how a server needs to deal with clients not
      acknowledging confirmable messages carrying notifications (#69).

   o  Added a mechanism to detect message reordering (#35).

   o  Added an explanation of how notifications can be cached,
      supporting both the freshness and the validation model (#39, #64).

   o  Clarified that non-GET requests do not affect observation
      relationships, and that GET requests without "Lifetime" Option
      affecting relationships is by design (#65).

   o  Described interaction with blockwise transfers (#36).

   o  Added Resource Discovery section (#99).

   o  Added IANA Considerations.

   o  Added Security Considerations (#40).

   o  Added examples (#38).

Author's Address

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

   Phone: +49-421-218-63905
   EMail: hartke@tzi.org

Hartke                   Expires January 1, 2015               [Page 32]