[core] Wild suggestion for observation

[Christian Amsüss]

Hello CoRE WG,

observation is being discussed in the context of OSCORE[1], and without
overloading that thread, I'd like to run a suggestion by you:

Can we generalize Observe a bit to cover non-safe cases?

To summarize, observe was originally specified for GET in RFC7641 and
then later allowed for FETCH in RFC8132 without really saying much,
especially about Block1 that came with that.

There have been cases where it would be neat to observe outputs of POSTs
too (AFAIR Peter had one, OSCORE would be simpler too, and there was
some other in London I don't remember).

Proposal:

* Observe can be used with all currently specified methods.
* For re-registration of interest in the restul of a non-safe operation,
the Observe value of the request is 2 ("reregister"). Servers process
a reregister just as regular registration, but can only respond if
they recognize it as a reregistration, and MUST NOT act on it again.
If they don't recognize it, they respond with 4.xx What Are You
Talking About. (There's no way to recover from that on the protocol
level; that's left to the application).
* This is well compatible with existing intermediaries, they'll just go
4.02 Bad Option when they see a client trying to observe a POST, just
as they would if they didn't do observation at all.
* Applications can use reregister on safe operations too, but really why
should they, it only trips off older proxies.

(One could consider adding an Observe:3 "deregister-nodo" here that
allows a client to stop a registration w/o risking that the operation
might be done again when sending Observe:1; frankly, I don't think I'll
ever send Observe:1 as GET / No-Response:at-all with the same token is
just as good.)

That's not really something I want to put on my agenda, but as it
popped up a few times in London and now again: Here's how I'd go about
it.

Best regards
Christian


---

Bonus content: GoldenEye's traceroute scene as expressed with this
extension:

POST /traceroute
Payload: Find the GoldenEye control center!
Observe:0

2.05 Content, Observe:10, Payload: He's not in Russia...

2.05 Content, Observe:20, Payload: He's not in Germany...

(Simonova gets impatient:)

POST /traceroute
Payload: Find the GoldenEye control center!
Observe: 2

2.05 Content, Observe:21, Payload: He's still not in Germany...

2.05 Content, Observe: 30, Payload: He's not in New York, Toronto,
Chicago, San Francisco

2.05 Content, Observe: 40, Max-Age: large, Payload: He's in Cuba.

[1]: https://github.com/core-wg/oscoap/issues/223

[Carsten Bormann]

Hmm. We normally observe resources, with the server sending a fresh representation when that has changed.

What you are proposing means observing the change of a result of a non-idempotent action that was done once if it were done again but isn’t (!?). Not sure I’m completely following.

The REST way of doing that would be to create a resource on the POST for the result, and then observe that in a separate request.
If that is too heavy, maybe it would be a better way to streamline that a bit?

Grüße, Carsten

[Christian Amsüss]

Post by Carsten Bormann
Hmm. We normally observe resources, with the server sending a fresh
representation when that has changed.

Yes, and from that PoV, what I'm suggesting is undue.

That boundary has IMO been crossed already with FETCH being observable
(several observations can run on the same resource and give different
results), so this would be the continuation of that line of thought.

Post by Carsten Bormann
What you are proposing means observing the change of a result of a
non-idempotent action that was done once if it were done again but
isn’t (!?). Not sure I’m completely following.

Not "if it was done again". As I understand resources and
representations, the response body of a POST is not a representation of
the resource POSTed to, but a representation of an anonymous,
short-lived resource(-ish thing?) that has no address and a short
lifetime but might have a representation.

An observation on that would give the client various representations of
that thing as it evolves during its short lifetime.

Post by Carsten Bormann
The REST way of doing that would be to create a resource on the POST
for the result, and then observe that in a separate request. If that
is too heavy, maybe it would be a better way to streamline that a bit?

I do agree that this is what should happen in many cases; and if the
outcome of this thread is that all cases where an observable POST would
be needed are better covered with POST->Location & observe that, it's
perfectly fine with me. (Bonus points if we can streamline that).

I don't remember why in Peter's (or was it Jim? that would have been
the thread at [1], then) case that was not a viable option.

In OSCORE, we're transporting an observation but hiding the method, so
everything becomes a meaningless POST; going via a Location would take
much of the streamlining out of it. That it's allowed for FETCH just
provided an easy way out there, so we're now sending every observation
in a FETCH (even though the OSCORE request is not fully side-effect
free, and we have to make amends due to that, but it seems to work).

But yes: Saying "If you want to Observe POST (or anything else but GET),
rather POST with a Location, GET that and DELETE it when it looks done"
can be a valid answer too (just one that won't make it into OSCORE).

Thanks for your input
Christian

[1]: https://mailarchive.ietf.org/arch/msg/core/40WH27Y0-QgbjJ5GWxjios3Xkj8

[Jim Schaad]

-----Original Message-----
Sent: Thursday, April 12, 2018 5:55 AM
Subject: Re: [core] Wild suggestion for observation

Post by Carsten Bormann
Hmm. We normally observe resources, with the server sending a fresh
representation when that has changed.

Yes, and from that PoV, what I'm suggesting is undue.
That boundary has IMO been crossed already with FETCH being observable
(several observations can run on the same resource and give different
results), so this would be the continuation of that line of thought.

Post by Carsten Bormann
What you are proposing means observing the change of a result of a
non-idempotent action that was done once if it were done again but
isn’t (!?). Not sure I’m completely following.

Not "if it was done again". As I understand resources and representations,
the response body of a POST is not a representation of the resource POSTed
to, but a representation of an anonymous, short-lived resource(-ish thing?)
that has no address and a short lifetime but might have a representation.
An observation on that would give the client various representations of that
thing as it evolves during its short lifetime.

Post by Carsten Bormann
The REST way of doing that would be to create a resource on the POST
for the result, and then observe that in a separate request. If that
is too heavy, maybe it would be a better way to streamline that a bit?

I do agree that this is what should happen in many cases; and if the outcome
of this thread is that all cases where an observable POST would be needed
are better covered with POST->Location & observe that, it's perfectly fine
with me. (Bonus points if we can streamline that).
I don't remember why in Peter's (or was it Jim? that would have been the
thread at [1], then) case that was not a viable option.

This was the way that I finally designed my problem to work. It is a bit interesting from the view of: I observe the resource and then I post to the resource. It is very likely that I would get back the same content representation twice once in the observe and once from the post. This is the same type of thing that happens in the OSCORE world where one needs to carefully think about what it means to observe a resource on the encrypted side and when and where things come back from the FETCH vs POST operation.

Jim

In OSCORE, we're transporting an observation but hiding the method, so
everything becomes a meaningless POST; going via a Location would take
much of the streamlining out of it. That it's allowed for FETCH just provided
an easy way out there, so we're now sending every observation in a FETCH
(even though the OSCORE request is not fully side-effect free, and we have
to make amends due to that, but it seems to work).
But yes: Saying "If you want to Observe POST (or anything else but GET),
rather POST with a Location, GET that and DELETE it when it looks done"
can be a valid answer too (just one that won't make it into OSCORE).
Thanks for your input
Christian
[1]: https://mailarchive.ietf.org/arch/msg/core/40WH27Y0-
QgbjJ5GWxjios3Xkj8
--
To use raw power is to make yourself infinitely vulnerable to greater powers.
-- Bene Gesserit axiom