RFC Editor Model (Version 3)
draft-iab-rfcefdp-rfced-model-13
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2022-06-28
|
13 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2022-06-20
|
13 | (System) | RFC Editor state changed to AUTH48 |
2022-06-06
|
13 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2022-04-08
|
13 | (System) | IANA Action state changed to No IANA Actions from In Progress |
2022-04-07
|
13 | (System) | RFC Editor state changed to EDIT |
2022-04-07
|
13 | (System) | IANA Action state changed to In Progress |
2022-04-07
|
13 | Cindy Morgan | IAB state changed to Sent to the RFC Editor from Community Review |
2022-04-07
|
13 | Cindy Morgan | Sent request for publication to the RFC Editor |
2022-04-07
|
13 | Cindy Morgan | Changed consensus to Yes from Unknown |
2022-03-17
|
13 | Cindy Morgan | New version available: draft-iab-rfcefdp-rfced-model-13.txt |
2022-03-17
|
13 | (System) | Secretariat manually posting. Approvals already received |
2022-03-17
|
13 | Cindy Morgan | Uploaded new revision |
2022-03-04
|
12 | Peter Saint-Andre | New version available: draft-iab-rfcefdp-rfced-model-12.txt |
2022-03-04
|
12 | (System) | New version approved |
2022-03-04
|
12 | (System) | Request for posting confirmation emailed to previous authors: Peter Saint-Andre |
2022-03-04
|
12 | Peter Saint-Andre | Uploaded new revision |
2022-03-03
|
11 | Luc André Burdet | Closed request for Last Call review by RTGDIR with state 'Team Will not Review Version': Duplicate request |
2022-03-03
|
11 | Ines Robles | Assignment of request for Last Call review by IOTDIR to Daniel Migault was marked no-response |
2022-02-25
|
11 | Sheng Jiang | 4. Server-side Requirements 4.1. Request A GET request with an Observe Option set to 'register' (0) requests the server not only to return … 4. Server-side Requirements 4.1. Request A GET request with an Observe Option set to 'register' (0) requests the server not only to return a current representation of the target resource, but also to add the client to the list of observers of that resource. Upon success, the server returns a current representation of the resource and MUST notify the client of subsequent changes to the state as long as the client is on the list of observers. The entry in the list of observers is keyed by the client endpoint and the token specified by the client in the request. If an entry with a matching endpoint/token pair is already present in the list (which, for example, happens when the client wishes to reinforce its interest in a resource), the server MUST NOT add a new entry but MUST replace or update the existing one. A server that is unable or unwilling to add a new entry to the list of observers of a resource MAY silently ignore the registration request and process the GET request as usual. The resulting response MUST NOT include an Observe Option, the absence of which signals to the client that it will not be notified of changes to the resource and, e.g., needs to poll the resource for its state instead. If the Observe Option in a request is set to any other value than 'register' (0), then the server MUST remove any entry with with a matching endpoint/token pair from the list of observers and process the GET request as usual. The resulting response MUST NOT include an Observe Option. 4.2. Notifications A client is notified of changes to the resource state by additional responses sent by the server in reply to the GET request. Each such notification response (including the initial response) MUST echo the token specified by the client in the GET request. If there are multiple entries in the list of observers, the order in which the clients are notified is not defined; the server is free to use any method to determine the order. A notification SHOULD have a 2.05 (Content) or 2.03 (Valid) response code. However, in the event that the state of a resource changes in a way that would cause a normal GET request at that time to return a non-2.xx response (for example, when the resource is deleted), the server SHOULD notify the client by sending a notification with an appropriate response code (such as 4.04 Not Found) and MUST remove the associated entry from the list of observers of the resource. Hartke Expires January 1, 2015 [Page 12] Internet-Draft Observing Resources in CoAP June 2014 The Content-Format specified in a 2.xx notification MUST be the same as the one used in the initial response to the GET request. If the server is unable to continue sending notifications in this format, it SHOULD send a notification with a 4.06 (Not Acceptable) response code and MUST remove the associated entry from the list of observers of the resource. A 2.xx notification MUST include an Observe Option with a sequence number as specified in Section 4.4 below; a non-2.xx notification MUST NOT include an Observe Option. 4.3. Caching As notifications are just additional responses sent by the server in reply to a GET request, they are subject to caching as defined in Section 5.6 of RFC 7252 [RFC7252]. 4.3.1. Freshness After returning the initial response, the server MUST try to keep the returned representation current, i.e., it MUST keep the resource state observed by the client as closely in sync with the actual resource state as possible. Since becoming out of sync at times cannot be avoided, the server MUST indicate for each representation an age up to which it is acceptable that the observed state and the actual state are inconsistent. This age is application-dependent and MUST be specified in notifications using the Max-Age Option. When the resource does not change and the client has a current representation, the server does not need to send a notification. However, if the client does not receive a notification, the client cannot tell if the observed state and the actual state are still in sync. Thus, when the the age of the latest notification becomes greater than its indicated Max-Age, the client no longer has a usable representation of the resource state. The server MAY wish to prevent that by sending a new notification with the unchanged representation and a new Max-Age just before the Max-Age indicated earlier expires. 4.3.2. Validation A client can include a set of entity-tags in its request using the ETag Option. When a observed resource changes its state and the origin server is about to send a 2.05 (Content) notification, then, whenever that notification has an entity-tag in the set of entity- tags specified by the client, the server MAY send a 2.03 (Valid) response with an appropriate ETag Option instead. Hartke Expires January 1, 2015 [Page 13] Internet-Draft Observing Resources in CoAP June 2014 4.4. Reordering Because messages can get reordered, the client needs a way to determine if a notification arrived later than a newer notification. For this purpose, the server MUST set the value of the Observe Option of each notification it sends to the 24 least-significant bits of a strictly increasing sequence number. The sequence number MAY start at any value and MUST NOT increase so fast that it increases by more than 2^23 within less than 256 seconds. The sequence number selected for a notification MUST be greater than that of any preceding notification sent to the same client with the same token for the same resource. The value of the Observe Option MUST be current at the time of transmission; if a notification is retransmitted, the server MUST update the value of the option to the sequence number that is current at that time before retransmission. Implementation Note: A simple implementation that satisfies the requirements is to obtain a timestamp from a local clock. The sequence number then is the timestamp in ticks, where 1 tick = (256 seconds)/(2^23) = 30.52 microseconds. It is not necessary that the clock reflects the current time/date. Another valid implementation is to store a 24-bit unsigned integer variable per resource and increment this variable each time the resource undergoes a change of state (provided that the resource changes its state less than 2^23 times in the first 256 seconds after every state change). This removes the need to update the value of the Observe Option on retransmission when the resource state did not change. Design Note: The choice of a 24-bit option value and a time span of 256 seconds theoretically allows for a notification rate of up to 65536 notifications per second. Constrained nodes often have rather imprecise clocks, though, and inaccuracies of the client and server side may cancel out or add in effect. Therefore, the maximum notification rate is reduced to 32768 notifications per second. This is still well beyond the highest known design objective of around 1 kHz (most CoAP applications will be several orders of magnitude below that), but allows total clock inaccuracies of up to -50/+100 %. 4.5. Transmission A notification can be sent in a confirmable or a non-confirmable message. The message type used is typically application-dependent and MAY be determined by the server for each notification individually. Hartke Expires January 1, 2015 [Page 14] Internet-Draft Observing Resources in CoAP June 2014 For example, for resources that change in a somewhat predictable or regular fashion, notifications can be sent in non-confirmable messages; for resources that change infrequently, notifications can be sent in confirmable messages. The server can combine these two approaches depending on the frequency of state changes and the importance of individual notifications. A server MAY choose to skip sending a notification if it knows that it will send another notification soon, for example, when the state of a resource is changing frequently. It also MAY choose to send more than one notification for the same resource state. However, above all, the server MUST ensure that a client in the list of observers of a resource eventually observes the latest state if the resource does not undergo a new change in state. For example, when state changes occur in bursts, the server can skip some notifications, send the notifications in non-confirmable messages, and make sure that the client observes the latest state change by repeating the last notification in a confirmable message when the burst is over. The client's acknowledgement of a confirmable notification signals that the client is interested in receiving further notifications. If a client rejects a confirmable or non-confirmable notification with a Reset message, or if the last attempt to retransmit a confirmable notification times out, then the client is considered no longer interested and the server MUST remove the associated entry from the list of observers. Implementation Note: To properly process a Reset message that rejects a non-confirmable notification, a server needs to remember the message IDs of the non-confirmable notifications it sends. This may be challenging for a server with constrained resources. However, since Reset messages are transmitted unreliably, the client must be prepared that its Reset messages aren't received by the server. A server thus can always pretend that a Reset message rejecting a non-confirmable notification was lost. If a server does this, it could accelerate cancellation by sending the following notifications to that client in confirmable messages. A server that transmits notifications mostly in non-confirmable messages MUST send a notification in a confirmable message instead of a non-confirmable message at least every 24 hours. This prevents a client that went away or is no longer interested from remaining in the list of observers indefinitely. Hartke Expires January 1, 2015 [Page 15] Internet-Draft Observing Resources in CoAP June 2014 4.5.1. Congestion Control Basic congestion control for CoAP is provided by the exponential back-off mechanism in Section 4.2 of RFC 7252 [RFC7252] and the limitations in Section 4.7 of RFC 7252 [RFC7252]. However, CoAP places the responsibility of congestion control for simple request/ response interactions only on the clients: rate limiting request transmission implicitly controls the transmission of the responses. When a single request yields a potentially infinite number of notifications, additional responsibility needs to be placed on the server. In order not to cause congestion, servers MUST strictly limit the number of simultaneous outstanding notifications/responses that they transmit to a given client to NSTART (1 by default; see Section 4.7 of RFC 7252 [RFC7252]). An outstanding notification/response is either a confirmable message for which an acknowledgement has not yet been received and whose last retransmission attempt has not yet timed out, or a non-confirmable message for which the waiting time that results from the following rate limiting rules has not yet elapsed. The server SHOULD NOT send more than one non-confirmable notification per round-trip time (RTT) to a client on average. If the server cannot maintain an RTT estimate for a client, it SHOULD NOT send more than one non-confirmable notification every 3 seconds, and SHOULD use an even less aggressive rate when possible (see also Section 3.1.2 of RFC 5405 [RFC5405]). Further congestion control optimizations and considerations are expected in the future with advanced CoAP congestion control mechanisms. 4.5.2. Advanced Transmission The state of an observed resource may change while the number of the number of simultaneous outstanding notifications/responses to a client on the list of observers is greater than or equal to NSTART. In this case, the server cannot notify the client of the new resource state immediately but has to wait for an outstanding notification/ response to complete first. If there exists an outstanding notification/response that the server transmits to the client and that pertains to the changed resource, then it is desirable for the server to stop working towards getting the representation of the old resource state to the client, and to start transmitting the current representation to the client instead, so the resource state observed by the client stays closer in sync with the actual state at the server. Hartke Expires January 1, 2015 [Page 16] Internet-Draft Observing Resources in CoAP June 2014 For this purpose, the server MAY optimize the transmission process by aborting the transmission of the old notification (but not before the current transmission attempt completed) and starting a new transmission for the new notification (but with the retransmission timer and counter of the aborted transmission retained). In more detail, a server MAY supersede an outstanding transmission that pertains to an observation as follows: 1. Wait for the current (re-)transmission attempt to be acknowledged, rejected or to time out (confirmable transmission); or wait for the waiting time to elapse or the transmission to be rejected (non-confirmable transmission). 2. If the transmission is rejected or it was the last attempt to retransmit a notification, remove the associated entry from the list of observers of the observed resource. 3. If the entry is still in the list of observers, start to transmit a new notification with a representation of the current resource state. Should the resource have changed its state more than once in the meantime, the notifications for the intermediate states are silently skipped. 4. The new notification is transmitted with a new Message ID and the following transmission parameters: If the previous (re-)transmission attempt timed out, retain its transmission parameters, increment the retransmission counter and double the timeout; otherwise, initialize the transmission parameters as usual (see Section 4.2 of RFC 7252 [RFC7252]). It is possible that the server later receives an acknowledgement for a confirmable notification that it superseded this way. Even though this does not signal consistency, it is valuable in that it signals the client's further interest in the resource. The server therefore should avoid inadvertently removing the associated entry from the list of observers. 5. Intermediaries A client may be interested in a resource in the namespace of a server that is reached through a chain of one or more CoAP intermediaries. In this case, the client registers its interest with the first intermediary towards the server, acting as if it was communicating with the server itself, as specified in Section 3. It is the task of this intermediary to provide the client with a current representation of the target resource and to keep the representation updated upon changes to the resource state, as specified in Section 4. Hartke Expires January 1, 2015 [Page 17] Internet-Draft Observing Resources in CoAP June 2014 To perform this task, the intermediary SHOULD make use of the protocol specified in this document, taking the role of the client and registering its own interest in the target resource with the next hop towards the server. If the response returned by the next hop doesn't include an Observe Option, the intermediary MAY resort to polling the next hop or MAY itself return a response without an Observe Option. The communication between each pair of hops is independent; each hop in the server role MUST determine individually how many notifications to send, of which message type, and so on. Each hop MUST generate its own values for the Observe Option in notifications, and MUST set the value of the Max-Age Option according to the age of the local current representation. If two or more clients have registered their interest in a resource with an intermediary, the intermediary MUST register itself only once with the next hop and fan out the notifications it receives to all registered clients. This relieves the next hop from sending the same notifications multiple times and thus enables scalability. An intermediary is not required to act on behalf of a client to observe a resource; an intermediary MAY observe a resource, for example, just to keep its own cache up to date. See Appendix A.2 for examples. 6. Web Linking A web link [RFC5988] to a resource accessible over CoAP (for example, in a link-format document [RFC6690]) MAY include the target attribute "obs". The "obs" attribute, when present, is a hint indicating that the destination of a link is useful for observation and thus, for example, should have a suitable graphical representation in a user interface. Note that this is only a hint; it is not a promise that the Observe Option can actually be used to perform the observation. A client may need to resort to polling the resource if the Observe Option is not returned in the response to the GET request. A value MUST NOT be given for the "obs" attribute; any present value MUST be ignored by parsers. The "obs" attribute MUST NOT appear more than once in a given link-value; occurrences after the first MUST be ignored by parsers. Request for Last Call review by INTDIR Completed: Ready. Reviewer: Sheng Jiang. Sent review to list. |
2022-02-25
|
11 | Martin Dürst | Request for Last Call review by I18NDIR Completed: Almost Ready. Reviewer: Martin Dürst. Sent review to list. |
2022-02-24
|
11 | Stig Venaas | Request for Last Call review by RTGDIR Completed: Has Nits. Reviewer: Stig Venaas. Sent review to list. |
2022-02-24
|
11 | Mehmet Ersue | Closed request for Last Call review by YANGDOCTORS with state 'Overtaken by Events': Review done by Dan Romascanu. See mail in YANGDoctors maillist: https://mailarchive.ietf.org/arch/msg/yang-doctors/F5ZYRjEk9_z4PzlsHdVb8tnjtC0/ |
2022-02-23
|
11 | Russ Mundy | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Russ Mundy. Sent review to list. |
2022-02-22
|
11 | Dan Romascanu | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Dan Romascanu. Sent review to list. |
2022-02-21
|
11 | Thomas Fossati | Request for Last Call review by ARTART Completed: Ready. Reviewer: Thomas Fossati. Sent review to list. |
2022-02-21
|
11 | Wesley Eddy | Request for Last Call review by TSVART Completed: Ready with Issues. Reviewer: Wesley Eddy. Sent review to list. |
2022-02-17
|
11 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Dan Romascanu |
2022-02-17
|
11 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Dan Romascanu |
2022-02-12
|
11 | Pete Resnick | Request for Last Call review by I18NDIR is assigned to Martin Dürst |
2022-02-12
|
11 | Pete Resnick | Request for Last Call review by I18NDIR is assigned to Martin Dürst |
2022-02-11
|
11 | Christer Holmberg | Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Christer Holmberg. Sent review to list. |
2022-02-10
|
11 | Jean Mahoney | Request for Last Call review by GENART is assigned to Christer Holmberg |
2022-02-10
|
11 | Jean Mahoney | Request for Last Call review by GENART is assigned to Christer Holmberg |
2022-02-10
|
11 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Russ Mundy |
2022-02-10
|
11 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Russ Mundy |
2022-02-10
|
11 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Wesley Eddy |
2022-02-10
|
11 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Wesley Eddy |
2022-02-09
|
11 | Carlos Jesús Bernardos | Request for Last Call review by INTDIR is assigned to Sheng Jiang |
2022-02-09
|
11 | Carlos Jesús Bernardos | Request for Last Call review by INTDIR is assigned to Sheng Jiang |
2022-02-09
|
11 | Éric Vyncke | Assignment of request for Last Call review by INTDIR to Éric Vyncke was rejected |
2022-02-09
|
11 | Carlos Jesús Bernardos | Request for Last Call review by INTDIR is assigned to Éric Vyncke |
2022-02-09
|
11 | Carlos Jesús Bernardos | Request for Last Call review by INTDIR is assigned to Éric Vyncke |
2022-02-09
|
11 | Ines Robles | Request for Last Call review by IOTDIR is assigned to Daniel Migault |
2022-02-09
|
11 | Ines Robles | Request for Last Call review by IOTDIR is assigned to Daniel Migault |
2022-02-09
|
11 | Ines Robles | Assignment of request for Last Call review by IOTDIR to Eliot Lear was rejected |
2022-02-09
|
11 | Barry Leiba | Request for Last Call review by ARTART is assigned to Thomas Fossati |
2022-02-09
|
11 | Barry Leiba | Request for Last Call review by ARTART is assigned to Thomas Fossati |
2022-02-09
|
11 | Ines Robles | Request for Last Call review by IOTDIR is assigned to Eliot Lear |
2022-02-09
|
11 | Ines Robles | Request for Last Call review by IOTDIR is assigned to Eliot Lear |
2022-02-09
|
11 | Mirja Kühlewind | Requested Last Call review by I18NDIR |
2022-02-09
|
11 | Mirja Kühlewind | Requested Last Call review by ARTART |
2022-02-09
|
11 | Mirja Kühlewind | Requested Last Call review by YANGDOCTORS |
2022-02-09
|
11 | Mirja Kühlewind | Requested Last Call review by TSVART |
2022-02-09
|
11 | Mirja Kühlewind | Requested Last Call review by RTGDIR |
2022-02-09
|
11 | Mirja Kühlewind | Requested Last Call review by OPSDIR |
2022-02-09
|
11 | Mirja Kühlewind | Requested Last Call review by IOTDIR |
2022-02-09
|
11 | Mirja Kühlewind | Requested Last Call review by INTDIR |
2022-02-09
|
11 | Mirja Kühlewind | Requested Last Call review by GENART |
2022-02-09
|
11 | Mirja Kühlewind | Requested Last Call review by SECDIR |
2022-02-07
|
11 | Luc André Burdet | Request for Last Call review by RTGDIR is assigned to Stig Venaas |
2022-02-07
|
11 | Luc André Burdet | Request for Last Call review by RTGDIR is assigned to Stig Venaas |
2022-02-07
|
11 | Luc André Burdet | Requested Last Call review by RTGDIR |
2022-02-07
|
11 | Cindy Morgan | IAB state changed to Community Review |
2022-02-07
|
11 | Cindy Morgan | Intended Status changed to Informational from None |
2022-02-01
|
11 | Peter Saint-Andre | New version available: draft-iab-rfcefdp-rfced-model-11.txt |
2022-02-01
|
11 | (System) | New version accepted (logged-in submitter: Peter Saint-Andre) |
2022-02-01
|
11 | Peter Saint-Andre | Uploaded new revision |
2022-01-13
|
10 | Peter Saint-Andre | New version available: draft-iab-rfcefdp-rfced-model-10.txt |
2022-01-13
|
10 | (System) | New version accepted (logged-in submitter: Peter Saint-Andre) |
2022-01-13
|
10 | Peter Saint-Andre | Uploaded new revision |
2022-01-13
|
09 | Peter Saint-Andre | New version available: draft-iab-rfcefdp-rfced-model-09.txt |
2022-01-13
|
09 | (System) | New version accepted (logged-in submitter: Peter Saint-Andre) |
2022-01-13
|
09 | Peter Saint-Andre | Uploaded new revision |
2022-01-07
|
08 | Peter Saint-Andre | New version available: draft-iab-rfcefdp-rfced-model-08.txt |
2022-01-07
|
08 | (System) | New version accepted (logged-in submitter: Peter Saint-Andre) |
2022-01-07
|
08 | Peter Saint-Andre | Uploaded new revision |
2021-12-13
|
07 | Peter Saint-Andre | New version available: draft-iab-rfcefdp-rfced-model-07.txt |
2021-12-13
|
07 | (System) | New version accepted (logged-in submitter: Peter Saint-Andre) |
2021-12-13
|
07 | Peter Saint-Andre | Uploaded new revision |
2021-11-18
|
06 | Peter Saint-Andre | New version available: draft-iab-rfcefdp-rfced-model-06.txt |
2021-11-18
|
06 | (System) | New version accepted (logged-in submitter: Peter Saint-Andre) |
2021-11-18
|
06 | Peter Saint-Andre | Uploaded new revision |
2021-11-06
|
05 | Eliot Lear | Added to session: IETF-112: rfcefdp Wed-1430 |
2021-10-21
|
05 | Peter Saint-Andre | New version available: draft-iab-rfcefdp-rfced-model-05.txt |
2021-10-21
|
05 | (System) | New version accepted (logged-in submitter: Peter Saint-Andre) |
2021-10-21
|
05 | Peter Saint-Andre | Uploaded new revision |
2021-10-11
|
04 | Peter Saint-Andre | New version available: draft-iab-rfcefdp-rfced-model-04.txt |
2021-10-11
|
04 | (System) | New version accepted (logged-in submitter: Peter Saint-Andre) |
2021-10-11
|
04 | Peter Saint-Andre | Uploaded new revision |
2021-09-21
|
03 | Peter Saint-Andre | New version available: draft-iab-rfcefdp-rfced-model-03.txt |
2021-09-21
|
03 | (System) | New version accepted (logged-in submitter: Peter Saint-Andre) |
2021-09-21
|
03 | Peter Saint-Andre | Uploaded new revision |
2021-09-14
|
02 | Peter Saint-Andre | New version available: draft-iab-rfcefdp-rfced-model-02.txt |
2021-09-14
|
02 | (System) | New version accepted (logged-in submitter: Peter Saint-Andre) |
2021-09-14
|
02 | Peter Saint-Andre | Uploaded new revision |
2021-08-25
|
01 | Peter Saint-Andre | New version available: draft-iab-rfcefdp-rfced-model-01.txt |
2021-08-25
|
01 | (System) | New version accepted (logged-in submitter: Peter Saint-Andre) |
2021-08-25
|
01 | Peter Saint-Andre | Uploaded new revision |
2021-08-24
|
00 | Eliot Lear | Added to session: interim-2021-rfcefdp-06 |
2021-07-29
|
00 | Eliot Lear | Added to session: IETF-111: rfcefdp Thu-1500 |
2021-07-10
|
00 | Mirja Kühlewind | This document now replaces draft-saintandre-rfced-model instead of None |
2021-07-10
|
00 | Peter Saint-Andre | New version available: draft-iab-rfcefdp-rfced-model-00.txt |
2021-07-10
|
00 | (System) | WG -00 approved |
2021-07-09
|
00 | Peter Saint-Andre | Set submitter to "Peter Saint-Andre ", replaces to draft-saintandre-rfced-model and sent approval email to group chairs: iab-chairs@ietf.org |
2021-07-09
|
00 | Peter Saint-Andre | Uploaded new revision |