Subject: [core] Issue of resources at non-default port in CoRE link format

From: "Dijk, Esko" <[email-masked]>
Date: Wed, 26 Sep 2012 07:52:51 +0000

Dear all,

A question about CoRE link format (RFC 6690). If a client does a GET on /.well-known/core, the server can return resources hosted in a fairly short description, e.g.:
</rd>;rt="core.rd"
(18 bytes)

But this only works if the 'rd' resource is hosted on default port 5683. If the resource is hosted at another port (e.g. in the 6LoWPAN compressed port range), the returned link format seems to become much longer e.g.:
<coap://[2001:ddb8:1234:ffff:ffff:ffff:ffff:ffff]:61616/rd>;rt="core.rd"
(72 bytes) including mostly unused information - the port here is the only new thing that matters!

There is however a shorter representation possible:
<coap://:61616/rd>;rt="core.rd"
(31 bytes) From RFC 3986, the "reg-name" expression which may constitute the hostname ("host"), can be empty. So this is valid syntax as long as the scheme/protocol (CoAP) spec allows this to be empty. For HTTP however it seems invalid, at least webbrowsers don't support it.

Questions: does CoAP allow URIs with empty hostname? Should it? If CoAP allows it, would it automatically be allowed in CoRE link format RFC 6690 ?

Even shorter would be:
<:61616/rd>;rt="core.rd"
(24 bytes) By leaving away the scheme it is indicated that it's accessed with the same scheme that was used to fetch this link-format. But an invalid URI.

regards,
Esko

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 26 Sep 2012 13:51:05 +0200

Hi Esko,

I think the usecase you are describing is likely to occur with high frequency.
Definitely worth looking at.

> <coap://:61616/rd>;rt="core.rd"

(Note that <//:61616/rd> would be equivalent in a document that was obtained from a coap:// URI.)

Unfortunately, that is an absolute URI, but would need to be interpreted as a relative reference (RFC 3986 § 4.2).
I.e., in the algorithm listed in § 5.2.2, this evaluates to true:

	defined(R.authority)

(Or, in still other words, you get to take the entire authority from the base or from the URI reference, but can't mix within.)

Brainstorming mode:
Note that we have not defined the name resolution mechanism to be used for hostnames in CoAP URIs.
We could define a special host notation as the "context host" (some handwaving required here).
Say, if that special notation we choose is ".": <//.:61616/rd>
(We could also use an empty hostname, as you suggest above and as one could read out of § 6.2.3, but that also contradicts other parts of that subsection.)
I'm not sure I like that approach, because it means existing relative URI reference resolution implementations will need to add a special case.
(At least, this could be handled in a post-processing step after doing the main resolution.)

Grüße, Carsten

---

From: Kerry Lynn <[email-masked]>
Date: Wed, 26 Sep 2012 09:40:29 -0400

Hi Esko,

This is not the question you asked, but I think that using compressed
ports for resource discovery is a bad idea.  It potentially negates the
ability to reach all servers with a single multicast, essentially placing
a well-known resource at a dynamic (and therefore non-deterministic)
port.

RFC6282 gives this guidance:

   The overloading of the 0xf0bX ports increases the risk of getting the
   wrong type of payload and misinterpreting the content compared to
   ports that reserved at IANA.  It is thus recommended that the use of
   those ports be associated with a mechanism such as a Transport Layer
   Security (TLS) [RFC5246] Message Integrity Check (MIC) that validates
   that the content is expected and checked for integrity.

Clearly DTLS is also incompatible with multicast resource discovery.

Regards, -K-

On Wed, Sep 26, 2012 at 3:52 AM, Dijk, Esko <[email-masked]> wrote:
> Dear all,
>
>
>
> A question about CoRE link format (RFC 6690). If a client does a GET on
> /.well-known/core, the server can return resources hosted in a fairly short
> description, e.g.:
>
> </rd>;rt="core.rd"
>
> (18 bytes)
>
>
>
> But this only works if the ‘rd’ resource is hosted on default port 5683. If
> the resource is hosted at another port (e.g. in the 6LoWPAN compressed port
> range), the returned link format seems to become much longer e.g.:
>
> (72 bytes) including mostly unused information – the port here is the only
> new thing that matters!
>
>
>
> (31 bytes) From RFC 3986, the “reg-name” expression which may constitute the
> hostname (“host”), can be empty. So this is valid syntax as long as the
> scheme/protocol (CoAP) spec allows this to be empty. For HTTP however it
> seems invalid, at least webbrowsers don’t support it.
>
>
>
> Questions: does CoAP allow URIs with empty hostname? Should it? If CoAP
> allows it, would it automatically be allowed in CoRE link format RFC 6690 ?
>
>
>
> Even shorter would be:
>
> <:61616/rd>;rt="core.rd"
>
> (24 bytes) By leaving away the scheme it is indicated that it’s accessed
> with the same scheme that was used to fetch this link-format. But an invalid
> URI.
>
>
>
> regards,
>
> Esko
>
>
>
>
> The information contained in this message may be confidential and legally
> protected under applicable law. The message is intended solely for the
> addressee(s). If you are not the intended recipient, you are hereby notified
> that any use, forwarding, dissemination, or reproduction of this message is
> strictly prohibited and may be unlawful. If you are not the intended
> recipient, please contact the sender by return e-mail and destroy all copies
> of the original message.
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: "Dijk, Esko" <[email-masked]>
Date: Wed, 26 Sep 2012 13:51:58 +0000

Hi Kerry,

The discovery of services is still at the default port 5683 of course, at /.well-known/core.
However the actual resources could be hosted at another endpoint on that server, e.g. port 61616.

Perhaps serving an 'rd' resource at a non-standard port is a confusing example; it could be replaced by e.g.
        </sen/1>;rt="ipso.sen"

and the same issue still holds.

Esko

-----Original Message-----
From: Kerry Lynn [mailto:[email-masked]]
Sent: Wednesday 26 September 2012 15:40
To: Dijk, Esko
Cc: [email-masked]
Subject: Re: [core] Issue of resources at non-default port in CoRE link format

Hi Esko,

Regards, -K-

On Wed, Sep 26, 2012 at 3:52 AM, Dijk, Esko <[email-masked]> wrote:
> But this only works if the 'rd' resource is hosted on default port 5683. If
> (31 bytes) From RFC 3986, the "reg-name" expression which may constitute the
> hostname ("host"), can be empty. So this is valid syntax as long as the
> seems invalid, at least webbrowsers don't support it.
>
>
>
> (24 bytes) By leaving away the scheme it is indicated that it's accessed

---

From: Matthieu Vial <[email-masked]>
Date: Fri, 28 Sep 2012 16:17:16 +0200

Hi Esko and Carsten,

Can we imagine something simpler with a kind of redirect like

Req: coap://mydevice/.well-known/core
Rsp: 2.05 Content
<coap://mydevice:61616/.well-known/core>

Then
Req: coap://mydevice:61616/.well-known/core
Rsp: 2.05 Content
</resource1>,</resource2>

Now /resource1 should be resolved as coap://mydevice:61616/resource1
Obviously the simple lookup function of RFC6690 will not suffice in that case.

Perhaps a port redirect option in the response would even be more
elegant and might work with the lookup interface.

Regards,
Matthieu