Re: [core] Observe updates, and call for proxy implementations

[Christian Amsüss <[e-mail]>]

One more update here based on continued discussion and to clear out
misunderstandings.

> > * Pinning of response content formats.
> 
> Seemed to be a straightforward idea at the time that wasn't throught
> through in combination with what we know now (how could it).
> 
> Next step: Write update text, decide whether to spool it with any other
> document or do a single-page update document that removes the restriction.
> State that no proxies are known to enforce it.

Note that this proposal is not about changing what happens when an
Accept is sent (response is bound to be same format). It only opens up
observation to more elaborate negotiation patterns, and removes an
unanswered question about permissible error states.

The proposed Accept-Any option[1] (that builds on this but is not itself
the topic here) should not be used for "send full client supported list"
applications, the draft could be way more specific here.

It's also worth pointing out that this topic has only become pressing
due to the way pubsub handles observations. If nontraditional responses
become a part of pubsub, the issue may become a more theoretical one.

[1]: https://tools.ietf.org/html/draft-amsuess-core-accept-any-00

> > * Pinning of all request options except ETag.
> 
> This one is not that simple, but in no hurry to solve.
> 
> Adding ETags has the (maybe unique) property that a response that the
> meaning of responses is not modified; if any request reaffirming
> messages get mixed up, worst to happen is a 2.01 rather than a 2.03.
> 
> It might be a good idea to steer this into deprecating ETag updates.
> Might also be worth looking into in combination with nontraditional
> responses.
> 
> Next steps: Further discussion, but no hurry either.

ETag updates are currently allowed and do have their use, but they also
come with considerations to be taken (like the client needing to be
prepared to still receive old messages, even for the updated request to
get lost if something switches round badly). We could write some
implementation guidance that describes the problems, and for some impls
it will be easier to just cancel / use a new token. It might be a good
idea to give implementation guidance with particular focus on OSCORE as
well (and think about OSCORE aware proxies in the course of that).

Using an active token (one that was not cancelled) and changing
something other than ETag is not conforming to the protocol, and the
server or proxy could do all kinds of things. A token is in use until a
response arrives on the token that has no Observe option.


Kind regards
Christian

-- 
Most people would leave. Not us. We're Vikings. We have stubbornness issues.
  -- Hiccup, son of Stoic