Subject: Re: [core] #257: URI references and multicast requests

From: "core issue tracker" <[email-masked]>
Date: Thu, 06 Dec 2012 08:51:00 -0000

#257: URI references and multicast requests

Comment (by [email-masked]):

 This will not work if the multicast request was sent via a proxy (instead
 of the client sending directly). (Am I correct?)
 A solution may be tied to the solution for ticket #263.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-
  [email-masked]           |  [email-masked]
     Type:  other        |      Status:  new
  technical              |   Milestone:  post-WGLC-1
 Priority:  minor        |     Version:  coap-11
Component:  coap         |  Resolution:
 Severity:  In WG Last   |
  Call                   |
 Keywords:               |
-------------------------+-------------------------------------------------

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 6 Dec 2012 10:42:45 +0100

On Dec 6, 2012, at 09:51, "core issue tracker" <[email-masked]> wrote:

> This

(reinterpreting the base URI with the responding endpoint address as authority)

> will not work if the multicast request was sent via a proxy (instead

As I said, I don't think we can solve 263 without adding machinery.
Too few people seem to be working on this specific use case -- it will be hard to ensure that any machinery we come up with is good machinery.

Your observation also is an instance of a more general problem:  A reverse-proxy that is forwarding representations with embedded URIs needs to make sure that these are valid on its client side.  This is, in general, impossible without knowledge of (and an implementation of a URI rewriter for) the specific Content-Format.

In the Web we are generally solving this by having origin servers already put in globally useful URIs.  That would work here, too.
This can be done by using full URIs with globally useful authorities, or relative URIs (generally with relative-paths) where there is a good hope that even after reverse-proxying these still work.  The latter clearly doesn't work for proxying to multicast unless the origin endpoint information is somehow passed (a Base-URI response option?); the former does.

Grüße, Carsten

---

From: "core issue tracker" <[email-masked]>
Date: Thu, 06 Dec 2012 17:38:41 -0000

Changes (by [email-masked]):

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

Comment:

 Fixed in [1108]:

 Fix #257.
 Close #263 by referring to coap-misc.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-
  [email-masked]           |  [email-masked]
     Type:  other        |      Status:  closed
  technical              |   Milestone:  post-WGLC-1
 Priority:  minor        |     Version:  coap-11
Component:  coap         |  Resolution:  fixed
 Severity:  In WG Last   |
  Call                   |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: </ticket/257#comment:3>
core <http://tools.ietf.org/core/>