Opened 10 years ago

Closed 9 years ago

#258 closed other technical (fixed)

Be explicit about the "observe key"

Reported by: cabo@… 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

Matthias Kovatsch notes (msg03748b):

Section 5

Because a client (or an intermediary in the client role) can only be once in the list of observers of a resource at a server (or an intermediary in the server role) -- it is useless to observe the same resource multiple times -- an intermediary MUST observe a resource only once, even if there are multiple clients for which it observes the resource.

What about different content-types/accept options? An intermediary must be able to serve them if they are supported by the origin server. But if they cannot be converted, the intermediary can only use observing for one content-type.

Maybe the observe list entry should also be dependent on the content-type?

Proposal:

1) Explicitly define which options go into the key that separates one observation relationship from another; include the URI and Accept. (What else?)

2) It will be hard to "merge" observation relationships on the server that lead to the same content-format (e.g., overlapping Accept options); this will require some client (proxy) action upon receiving the first response. (We do promise that the Content-Format will not change.) Add this as an implementation note.

Change History (1)

comment:1 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.