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

From: "Dijk, Esko" <[email-masked]>
Date: Mon, 1 Oct 2012 08:41:25 +0000

Hi Matthieu,

indeed such a 2-step approach works fine as a solution and is already one of the examples in RFC 6690. The "ct=40" part in the request indicates to the client that it should/could check out the link-format description at port 61616 further.

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

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

But if most CoAP discovery/client implementers don't implement such link following (since it's not normative behavior to do so), there will potentially be no single, interoperable means of service/resource discovery.
The CoAP spec COULD provide some guidelines here on top of RFC 6690 to achieve such interoperability.

Esko

-----Original Message-----
From: Matthieu Vial [mailto:[email-masked]]
Sent: Friday 28 September 2012 16:17
To: Carsten Bormann
Cc: Dijk, Esko; [email-masked]
Subject: Re: [core] Issue of resources at non-default port in CoRE link format

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

________________________________
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: "Dijk, Esko" <[email-masked]>
Date: Mon, 1 Oct 2012 09:28:01 +0000

(Brainstorming mode continued:)

Or we define something like a 'port hint' which gives an indication that the resource is hosted (or, also hosted) at the indicated port:
</rd>;rt="core.rd";p=61616

Equal length to the absolute URI form:
<//:61616/rd>;rt="core.rd"

Another interpretation of 'p' could be 'preferred alternative port for the authority'.

Esko

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

Hi Esko,

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

So, 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: Zach Shelby <[email-masked]>
Date: Mon, 1 Oct 2012 13:27:30 +0300

> Another interpretation of 'p' could be 'preferred alternative port for the authority'.

That certainly avoids the need to mess with the URI processing rules. 

We should also consider the meaning of the already existing RFC5988 "anchor" parameter. This parameter overrides the default context of the "hosts" relation type. However, it is not clear if this can be used to partially override the default context (e.g. just the port). As it is defined as a URI, it should probably have the same processing rules as with the target, so I would assume that mixing the default context (the host) and the anchor (just the port) is not allowed.

Zach

> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297