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

[Michael Koster <[e-mail]>]

Hi Christian (and CoRE),

In the spirit of handling "empty topic" case in the application layer, as we discussed, I propose to have the publisher be responsible to publish "nothing-here-to-see" as a topic's initial value if it has no initial value in the more meaningful content format. 

(Keeping in mind that, as defined, CoAP pub/sub only handles representations, and is not strictly a proxy for resource state, therefore should not be responsible for generating default representations in any particular content format, except the required link-format in the case of create-on-publish).

The pub-sub behavior would be to reply to READ/SUBSCRIBE only when something has been published. The topic creator is thus responsible to "promptly" publish nothing-here-to-see upon topic creation. Otherwise the broker simply acks any READ/SUBSCRIBE request and waits to send a response until something is published. 

The broker might be allowed to ack and queue subscribe (observe) requests that come in before something is published. 

When a topic's max-age expires, the broker returns 4.xx; there would be no separate data lifetime. Publish operations reset the topic lifetime and could change the topic's lifetime by including max-age in the PUBLISH request.

This way, the Accept-Any option and the nothing-here-to-see content formats may be defined in separate independent drafts, and the multipart format may be used with its potential accept-subformat options.

This is how I interpreted the result of the discussion on Thursday where we decided to keep the pub/sub draft simple. WIll this work?

Best regards,

MIchael

> On Mar 8, 2019, at 5:45 AM, Christian Amsüss <[e-mail]> wrote:
> 
> (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
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core