Opened 6 years ago

Closed 5 years ago

#204 closed protocol enhancement (fixed)

Introduce a minimal version of Pledge

Reported by: cabo@… Owned by: draft-ietf-core-observe@…
Priority: major Milestone: post-WGLC-1
Component: observe Version: observe-05
Severity: In WG Last Call Keywords:
Cc:

Description

Various proposals have been made to solve the robust observation relationships problem (#174).
174 was closed because the "80 %" were solved and a solution for the "20 %" had not yet come up.

Jeroen Hoebeke now proposed to do a similar option to Pledge (CoAP-misc section 4.3):

http://tools.ietf.org/html/draft-bormann-coap-misc-14#section-4.3

but decoupling this completely from Max-Age.
This would work as follows:

A server can indicate its promise to keep the client informed in each
message using the Pledge option (it is probably still useful to let
Pledge default to the value of Max-Age). This does not cause any
extension of Max-Age, i.e. the resource becomes uncacheable once
Max-Age runs out. A client can always perform a new explicit GET
(with or without Observe) to obtain a cacheable representation again.
An intermediary can pass on the Pledge to its clients, but will need
to respond to any explicit GET with an explicit GET upstream.

Change History (4)

comment:1 Changed 6 years ago by cabo@…

When we briefly discussed this again during the Friday meeting, the sense of the room went towards:

-- the basic mechanism (i.e., in the draft now) works for some, not all, applications
-- any potential extensions should be done in a separate draft

(The sense of the room is not a final WG decision of course, but a good indication of direction.)

If we stay with this direction, we should review the text to make sure:
-- it is clear about the way this works with non-cacheable resources
-- the way max-age is used now can be made into a default behavior for the potential future options we have started to discuss

comment:2 Changed 6 years ago by cabo@…

Cullen comments (msg03073d):

Section 4.3 Using Max-Age to indicate when server will send next
notification is just wrong. That's not what max-age means. We need separate
control of how long data is fresh, and how often the client needs to
refresh the subscription. There should be some limit, probably less than
24 hours, on max lifetime of subscription without a refresh.

->

editorially separate the concepts of max-age (cache freshness) and pledge. For now, both have the same value, but future extensions might provide options to give them different values.

comment:3 Changed 6 years ago by hartke@…

  • Milestone set to post-WGLC-1
  • Version set to observe-05

comment:4 Changed 5 years ago by hartke@…

  • Resolution set to fixed
  • Status changed from new to closed

Done in observe-09

Note: See TracTickets for help on using tickets.