Subject: [core] draft-ietf-core-http-mapping-08

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 27 Mar 2016 21:31:42 +0200

I had the chance to review the draft-ietf-core-http-mapping-08 and the
document looks good to me from a technical point of view. Impressive
amount of work.

I had one question about the assumptions made about the client. The
client embeds the CoAP URI (Target CoAP URI) into the HTTP URI (HC Proxy
URI). In order to make this transformation it first needs to know it. Of
course, you can assume that the client got manually configured but is
this realistic?

What are the options for a client to learn the Target CoAP URI?

Ciao
Hannes

PS: I wonder whether the document title should be changed from
'Guidelines for HTTP-CoAP Mapping Implementations' to 'Implementation
Guidelines for HTTP-CoAP Reverse Proxies'

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Mon, 28 Mar 2016 13:05:56 +0000

Hi Hannes, thanks very much for the review.

On 27/03/2016 20:31, "core on behalf of Hannes Tschofenig"
<[email-masked] on behalf of [email-masked]> wrote:
>URI). In order to make this transformation it first needs to know it.

I'm assuming 'to know it' refers to the CoAP URI, right?

>Of course, you can assume that the client got manually configured but is
>this realistic?

Consider the following two scenarios:

1. Legacy HTTP application.  This guy needs to talk to a CoAP resource and
it hasn't got a CoAP stack. It is realistic to assume that it has been
pre-configured with the HC Proxy URI that maps to the CoAP resource (e.g.
an actuator of some sort).

2. Mobile app.  This thing is hosted in a device that can roam from the
home net to the public Internet.  As such, it's realistic to assume that
it's got plenty of chances to discover the CoAP URI of interest while
attached to the home net (either via link-format or RD based discovery)
and, later on, use the (discovered or statically configured) URI mapping
convention to access the target CoAP resource via the public Internet.

Cheers, t

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 28 Mar 2016 16:52:48 +0200

Hi Thomas,

> I'm assuming 'to know it' refers to the CoAP URI, right?

Yes.
> convention to access the target CoAP resource via the public Internet.

Do we have any insight into whether anyone (e.g., Nokia -- formerly
Alcatel-Lucent) is deploy this technology in such a way?

Are we guessing here how things could work or are we capturing some
deployment experience? I will ask our folks but would be very surprised
if they do it in that way.

I believe (and I have to verify it) that we just do the mapping between
HTTP and CoAP internally to the RD-alike function (more precisely within
the LWM2M server).

Ciao
Hannes

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Mon, 28 Mar 2016 15:51:05 +0000

Hi Hannes,

>if they do it in that way.

Mine is just guesswork on our use cases #1 and #3
(https://tools.ietf.org/html/draft-ietf-core-http-mapping-08#section-4).
I'll check with the relevant Nokia/ALU people shortly.  Also, my
co-editors might want to chime in here :-)

>HTTP and CoAP internally to the RD-alike function (more precisely within

Great, could you expand a bit on this, please?  I guess it'd be good to
capture this aspect in the document.  In particular, we had a small
sub-sub-section in -07 about RD based discovery
(https://tools.ietf.org/html/draft-ietf-core-http-mapping-07#section-5.4.1)
 which we removed because it seemed slightly off topic and thus
potentially confusing.  Is it what you are talking about, or something
else?

Cheers, t

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Mon, 28 Mar 2016 18:39:00 +0000

Hi Hannes, let me unwind the stack to your original question:

>>>> What are the options for a client to learn the Target CoAP URI?

I've just spoken with the Nokia/ALU product people.  Their response is
that their preference would be to leave these discovery aspects to the
implementation.  (This is Nokia/ALU's point of view: Akbar and/or Sal
might have different opinions).

Cheers, t