[core] Observe updates, and call for proxy implementations (picking from 'Sketch of "Keep it simple"' thread)

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

Hello CoRE,

during IETF104, I'd like to discuss the possibility of small changes to
obsevation, which would mean an update to RFC7641.

Topics that have accumulated:

* Block1 and Observe.

  RFC8132 introduces the FETCH method which allows both observation and
  having a Block1'd request payload, but does not state those's
  interactions.

  AFAIR we've worked out how they'd work in practice on this list
  (roughly "as long as 2.31 is returned, the server won't accept the
  observation, but will on the last Block1"), but that should be written
  down at some point.

  That might be an opportunity to formally allow observation for all
  operations, provided I assume correctly that limiting Block1
  interaction was an important reason to not have POST+Observe.

  OSCORE worked around this by switching to FETCH for observations.

* Pinning of response content formats.

  The restriction that notifications need to carry the same
  Content-Format hinders the use of the Accept-Any variety of content
  negotiation in pubsub. (See proposal and impact ananlys^Wthoughts in
  quoted part below from the other thread).

  To me that restriction looks pretty arbitrary (though I see why it
  sounded good at the outset); I'm looking forward to discussion on its
  backgrounds.

* Pinning of all request options except ETag.

  This is a similar case as the pinning of response content formats.

  OSCORE worked its way around this by claiming that the inner options
  are the relevant ones, even though a proxy would have a hard time to
  know that. ("For OSCORE messages, this matching is to be done to the
  options in the decrypted message"). It was argued that a proxy can't
  really "be mad at" the client for doing it, for the client may simply
  have forgotten that the old observation was there, and is just
  requesting a new one with a most innocent look on its face.


My impression is that this can be a light update, especially if the
Block1/Observe part stays in there as "From the previous documents, it
(kind of implicitly but we better spell it out here) follows that".

That discussion would profit a lot from knowning which proxies are out
there and how they behave with respect to the open points; I'll start:

* aiocoap: The proxy implementation shipped with the library is lenient
  w/rt pinning. Block1+Observe is implemented as above (but not covered
  by the test suite yet).

Best regards
Christian


Proposal from [1]:
> Update to RFC7641
> =================
> 
> The requirement that subsequent notifications carry the same
> Content-Format option as the original response is lifted.
> 
> Impact
> ------
> 
> Changes to the returned media type can either happen when
> 
> * Accept-Any-Of was sent in the request -- in which case both server and
>   client know the updated rules, or
> * no Accept header was sent -- in which case the server whose
>   representation changes to require a new content format has no clear
>   way of indicating that under RFC7641 (ending with 4.06 Not Acceptable
>   would be close but isn't the expected response to a repeated request);
>   if the server changes the content format in a notification to an
>   unaware client, the client would catch it as a bad response (probably
>   similar to a response with a Content-Format not matching the sent
>   Accept). The client might consider the observation over while the
>   server does not, and will terminate the observation with a RST on the
>   next notification (or close the connection in TCP).
> 
> Impact on proxies: A proxy that enforces the previous rule on
> Content-Format staying constant would close observations (probably with
> something like 5.02 Bad Gateway), and the client would need to
> re-establish. No proxy implementations are known that implement that
> behavior. [ But I know only one so this would definitely need to be
> confirmed on the mailing list ].
> 
> [ I don't think that this has any actual interactions with the caching
> model, as the caching considerations are independent of the content
> format. ]

[1]: https://mailarchive.ietf.org/arch/msg/core/81SjKzfMJtSx6x8sc2P_RNq-M30

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom