[core] Sketch of "Keep it simple" / "Never reified union types"

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

(interim follow-up)
Reply-To: 

Hello CoRE,

following up on the last interim, I've sketched up what I understood the
keep-it-simple solution to the pubsum problem of allowing empty topics
could look like.

Most of the text below deals with how proxies would handle it, the
actual client and server behaviors should be indeed simple and
straightforward.

Best regards
Christian


The Accept-Any-Of option
========================

A new option Accept-Any-Of is defined. It is critical (I don't fully see
why but follow Accept here), safe-to-foward and part of the cache key.
Its format is uint up to 2 long (indicating content types), it is Class
E in OSCORE, usable in requests only, and repeatable

(Repeatability is the only aspect in which it differs from Accept in
terms of option properties).

Its values indicate a list of acceptable representations in order of
decreasing preference. A server MUST answer with the first format it can
represent the requested state in, or 4.06 (Not Acceptable) if it could
answer successfully but the response would not match any of the option
values.

Proxy behavior
--------------

A proxy MAY serve a cached representation to a request with a different
sequence of Accept-Any-Of options, provided the second request has an
Accept value of the cached representation, or all the content formats
that precede the available content format in the second request's
Accept-Any-Of options also preceded the available representation in an
earlier (fresh) request's list.

When a request that carries Accept-Any-Of is answered 4.06 (or with any
but the first format requested by Accept-Any-Of), a proxy SHOULD [ we
can't have a MUST here w/o making it non-safe-to-forward, but I think
it's sufficient ] invalidate all known representations in any of the
requested formats (or the formats preceeding the returned one,
respectively).


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. ]


Usage in pubsub
===============

Topics that were created but do not have any publication are represented
in the application/nothing-here-to-see (or application/null? either TBD)
type.

The PUBLISH operation would probably not need to accept
nothing-here-to-see, at leat create-on-publish can't do that as there is
no type to set on the topic with such an initial publication.

Requests to the topic with an Accept option of the topic's type will
return 4.06 Not Acceptable both in observations (subscription) and plain
get requests (read). The subscribe (and possibly read) operation
therefore will not use the Accept header, but Accept-Any-Of with
nothing-here-to-see and the topic's designate type, in that sequence.
Thus, a proxy may serve a nothing-here-to-see as long as it is fresh (as
it always could), but it sees a notification carrying the actual type,
that evicts the nothing-here-to-see from its cache.  (Conversely, if a
topic goes to nothing-here-to-see, that will not clear out any
cached-but-still-fresh value from the cache. As long as publishers are
not allowed to explicitly send nothing-here-to-see, this will not
happen, because topics only enter nothing-here-to-see when their content
expires, at which time all its caches expire as well. The broker might
not even send the nothing-here-to-see in a notification [ ? ].)


-- 
This may seem a bit weird, but that's okay, because it is weird.
  -- perldata(1) about perl variables