Opened 10 years ago

Closed 10 years ago

#228 closed protocol enhancement (fixed)

Proxying of multicast requests

Reported by: hartke@… Owned by: hartke@…
Priority: minor Milestone: post-WGLC-1
Component: coap Version: coap-09
Severity: In WG Last Call Keywords:
Cc:

Description

Esko Dijk notes (msg03065):

In Section 5.7 (Proxying) the possibility of a multicast request in the Proxy-Uri is not explicitly considered.

Should we mention this possibility? (If yes, do we need to update/adapt our caching text to include the multicast case?)

->

Create a multicast section, between section 9 and 10 with the existing content of section 4.5 and the following additional rules:

  • When a new Proxy-Uri multicast request comes in, the proxy always makes a new request to the multicast group (since there may be new group members that joined meanwhile or ones that did not get the previous request). It MAY update the cache with the received responses. Then it sends all responses (both cached-still-fresh and 'new') back to the original client.
  • A response received in reply to a GET request to a multicast group MAY be used to satisfy a subsequent request on the related unicast request URI. [Only for the AllCoapServers? multicast group?]

The unicast request URI is obtained by replacing the authority part of the request URI with the transport layer source address of the response message. [Overridden by a Content-Location option?]

  • A cache MAY revalidate a response by making a GET request on the related unicast request URI.
  • A GET request to a multicast group MUST NOT contain an ETag option.

Carsten Bormann notes (msg03272):

One thing we are missing to make this more useful is a way to suppress responses the client already has. For unicast, we do some of this with ETags, but these are in a namespace made up by each server, so they don't mean anything for a multicast group as a whole. For multicast, we'd have to list pairs of authorities and ETags. Obviously, these lists can become big quickly.

->

Add a note that this spec does not yet define a suppression mechanism ("left for further study" would be the CCITT term :-).

Change History (2)

comment:1 Changed 10 years ago by zach@…

  • Owner changed from draft-ietf-core-coap@… to hartke@…

comment:2 Changed 10 years ago by hartke@…

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

Done in coap-10.

Note: See TracTickets for help on using tickets.