Subject: Re: [core] #228: Proxying of multicast requests

From: "core issue tracker" <[email-masked]>
Date: Mon, 11 Jun 2012 14:13:59 -0000

#228: Proxying of multicast requests

#choose ticket.new
  #when True
 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 :-).
  #end
  #otherwise
    #if changes_body
Changes (by zach@…):

 * owner:  draft-ietf-core-coap@… => hartke@…

    #end
    #if changes_descr
      #if not changes_body and not change.comment and change.author
Description changed by zach@…:
      #end

--
    #end
    #if change.comment

Comment:

    #end
  #end
#end

-- 
----------------------------------+--------------------------
 Reporter:  hartke@…              |       Owner:  hartke@…
     Type:  protocol enhancement  |      Status:  new
 Priority:  minor                 |   Milestone:  post-WGLC-1
Component:  coap                  |     Version:  coap-09
 Severity:  In WG Last Call       |  Resolution:
 Keywords:                        |
----------------------------------+--------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/228#comment:1>
core <http://tools.ietf.org/core/>

---

From: "core issue tracker" <[email-masked]>
Date: Fri, 22 Jun 2012 19:22:26 -0000

Changes (by hartke@…):

 * status:  new => closed
 * resolution:   => fixed

Comment:

 Done in coap-10.

-- 
----------------------------------+--------------------------
 Reporter:  hartke@…              |       Owner:  hartke@…
     Type:  protocol enhancement  |      Status:  closed
 Priority:  minor                 |   Milestone:  post-WGLC-1
Component:  coap                  |     Version:  coap-09
 Severity:  In WG Last Call       |  Resolution:  fixed
 Keywords:                        |
----------------------------------+--------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/228#comment:2>
core <http://tools.ietf.org/core/>