Opened 10 years ago

Closed 9 years ago

#281 closed protocol defect (fixed)

Safe-to-forward options

Reported by: hartke@… Owned by: draft-ietf-core-observe@…
Priority: minor Milestone: post-WGLC-1
Component: observe Version: observe-07
Severity: In WG Last Call Keywords:
Cc:

Description

A GET request with an Observe Option to an intermediary can contain options that the intermediary doesn't recognise.

Up to coap-11, this wasn't a problem, because these options were rejected/removed, so the request to the origin server didn't contain them.

Since coap-12, options can be "safe to forward". An intermediary can include these in a request to the server even if it doesn't recognised them.

This is a problem, because each of the options could affect the observation relationship between intermediary and server in a way that makes the notifications unsuitable for sharing between clients with different unrecognised options in their requests.

Since the intermediary doesn't recognise the options, it can also not tell if the request will lead to a new observation relationship or override an existing one.

Change History (2)

comment:1 Changed 10 years ago by cabo@…

Message received by email on Thu, 07 Feb 2013 07:25:19 +0000, inserted by email2trac:

On Feb 7, 2013, at 07:39, Bert Greevenbosch <Bert.Greevenbosch@huawei.com>
wrote:

> But more in general, what should aggregating reverse-proxies do with
> safe-to-forward options? They may make sense only for individual responses,
> so maybe aggregating reverse-proxies shouldn't forward any unknown options,
> even when they are "safe to forward".

I think that an "aggregating reverse-proxy" is necessarily even more
coupled*) to the origin server(s) than reverse proxies already are. First of
all, we don't even have an application-independent way of aggregating
responses; if we develop one, we should think about a way to aggregate
response options as well.

One of the points of marking a request option safe-to-forward is being able
to rely on that option making it unharmed to an origin server. If you want a
proxy to be allowed to swallow them anyway, then you need the consent of the
origin servers. (You may be able to get that for the more coupled case of
reverse-proxies.)

Grüße, Carsten

*) http://en.wikipedia.org/wiki/Coupling_(computer_programming)

comment:2 Changed 9 years ago by hartke@…

  • Resolution set to fixed
  • Status changed from new to closed

Done in observe-09

Note: See TracTickets for help on using tickets.