Opened 10 years ago

Closed 10 years ago

#257 closed other technical (fixed)

URI references and multicast requests

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

Description

Klaus Hartke notes:

Section 8

When a client performs a Multicast GET and receives one or more resource representations that contain URI references, it is not clear what the Retrieval URI is (see <http://tools.ietf.org/html/rfc3986#section-5.1.3>).

  • Is it the request URI with the multicast address?
  • Is it the related unicast request URI? How does the client learn the host name of the node?

Proposal:

For the purposes of defaulting a base URI, construct a unicast retrieval URI by replacing the multicast address by a literal built from the IP address taken from the response endpoint address.

Change History (3)

comment:1 Changed 10 years ago by esko.dijk@…

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.

comment:2 Changed 10 years ago by cabo@…

Message received by email on Thu, 06 Dec 2012 09:43:03 +0000, inserted by email2trac:

On Dec 6, 2012, at 09:51, "core issue tracker"
<trac+core@grenache.tools.ietf.org> 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
> of the client sending directly). (Am I correct?)
> A solution may be tied to the solution for ticket #263.

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

comment:3 Changed 10 years ago by cabo@…

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

Fixed in [1108]:

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

Note: See TracTickets for help on using tickets.