Subject: [core] Max-Age question

From: Jim Schaad <[email-masked]>
Date: Tue, 26 Sep 2017 14:09:52 -0700

I am trying to figure out the correct behavior for a Pub-Sub server with
respect to the Max-Age value and I cannot find what I think of as good
guidance in RFC 7252.

If I specify a Max-Age value, then the client can assume that the response
is good for that long.
If I specify a Max-Age value of 0, then I am telling an intermediary not to
cache the value, but I am not making a statement that the value is "stale"
in some way (maybe).

If I return a value for Ma-Age of 0, should the client assume that the value
is stale and potentially ignore it?
If I return an error, not sure what error would be appropriate, this seems
to be a bad choice as intermediaries might decide to unsubscribe people from
the resource.

The question is, if a server sees a resource as stale, specifically a
pub-sub resource where it was told a Max-Age, what should the server do when
queried?

Jim

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 26 Sep 2017 23:17:09 +0200

> If I specify a Max-Age value, then the client can assume that the response

Right.  (And there is a default value for Max-Age, so you cannot not specify a value.)

> cache the value, but I am not making a statement that the value is "stale"

Right.

> is stale and potentially ignore it?

Who is I?  Max-Age 0 means “valid now, but no guarantees for the future”.
The “now” obviously includes a tolerance for transfer times (which can vary considerably).

> to be a bad choice as intermediaries might decide to unsubscribe people from

Right.

> pub-sub resource where it was told a Max-Age, what should the server do when

It may sometimes be better to have a stale value than no value at all, at least if you know the value is stale.
Unfortunately, we haven’t created a way to *transfer* such a value (but a cache can *hold* such a value and make it available as stale locally).
[A negative max-age might be appropriate here, except that CoAP’s option type system doesn’t have negative numbers so far.  Maybe a stale-for option should be added to hold the absolute...]

Grüße, Carsten

---

From: Jim Schaad <[email-masked]>
Date: Tue, 26 Sep 2017 15:17:44 -0700

> -----Original Message-----
> From: Carsten Bormann [mailto:[email-masked]]
> Sent: Tuesday, September 26, 2017 2:17 PM
> To: Jim Schaad <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [core] Max-Age question
> 
> > I am trying to figure out the correct behavior for a Pub-Sub server
> > with respect to the Max-Age value and I cannot find what I think of as
> > good guidance in RFC 7252.
> >
> > If I specify a Max-Age value, then the client can assume that the
> > response is good for that long.
> 
> > If I specify a Max-Age value of 0, then I am telling an intermediary
> > not to cache the value, but I am not making a statement that the value is
> "stale"
> > in some way (maybe).
> 
> Right.
> 
> > If I return a value for Ma-Age of 0, should the client assume that the
> > value is stale and potentially ignore it?
> 
> > If I return an error, not sure what error would be appropriate, this
> > seems to be a bad choice as intermediaries might decide to unsubscribe
> > people from the resource.
> 
> Right.
> 
> > pub-sub resource where it was told a Max-Age, what should the server
> > do when queried?
> 
> Unfortunately, we haven’t created a way to *transfer* such a value (but a
> cache can *hold* such a value and make it available as stale locally).
> [A negative max-age might be appropriate here, except that CoAP’s option
> type system doesn’t have negative numbers so far.  Maybe a stale-for option
> should be added to hold the absolute...]

This is what I was looking for as an answer - either that or an error which says "My content is stale - but here it is"

For now, I guess I will just use a Max-Age of 0.

Jim