Opened 10 years ago
Closed 9 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 10 years ago by cabo@…
comment:2 Changed 10 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 10 years ago by hartke@…
- Milestone set to post-WGLC-1
- Version set to observe-05
comment:4 Changed 9 years ago by hartke@…
- Resolution set to fixed
- Status changed from new to closed
Done in observe-09
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