Subject: [core] about draft-cao-core-pd

From: Salvatore Loreto <[email-masked]>
Date: Sun, 6 Nov 2011 12:34:12 +0100

Hi there,

how a CoAP client dynamically discovers a proxy to access the HTTP 
server is an interesting question

the mechanism you proposed in the draft is to use a multicast GET 
request to /.well-known-core
with a 'rt' parameter with the value "core-pd" is interesting

about this proposal it is not clear to me why you mandate that the 
address of the proxy is carried
within the Content payload;
why is it not enough for the sensor reading the source address of the 
answer?

thinking more about the issue,
I am wondering if instead of sending a multicast GET request to 
/.well-known/core
not would be more convenient and straightforward sending directly a 
multicast HTTP GET request
and doing so discover intrinsically the IP address of the proxy?

cheers
Salvatore

-- 
Salvatore Loreto
www.sloreto.com

---

From: Zhen Cao <[email-masked]>
Date: Mon, 7 Nov 2011 09:07:44 +0800

Hi Salvatore,

Thanks for your comments.  See inline.

On Sun, Nov 6, 2011 at 7:34 PM, Salvatore Loreto
<[email-masked]> wrote:
> Hi there,
>
> how a CoAP client dynamically discovers a proxy to access the HTTP server is
> an interesting question
>
> the mechanism you proposed in the draft is to use a multicast GET request to
> /.well-known-core
> about this proposal it is not clear to me why you mandate that the address
> of the proxy is carried

We thought carrying the address in the payload could be used for
delegated case. But this should be discussed further.

> and doing so discover intrinsically the IP address of the proxy?

Are you saying that the sensor use HTTP GET ? But I think the
assumption is that the sensor is only CoAP capable, not HTTP capable.

For HTTP, I do not know if it has well known address that can be used
for discovery.

>
> cheers
> Salvatore
>
> --
> Salvatore Loreto
> www.sloreto.com
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

-- 
Best regards,
Zhen

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 7 Nov 2011 15:48:59 +0100

> assumption is that the sensor is only CoAP capable, not HTTP capable.
no I am saying that a sensor can issue a multicast CoAP GET with an HTTP URI
> For HTTP, I do not know if it has well known address that can be used
the idea I had in mind was that the CoAP/HTTP proxy would be able to listen
to this multicast CoAP GET request and translate it directly in the HTTP 
world
and then translate back the HTTP response it gets, in a CoAP response,
to the CoAP sensor

/Sal

---

From: ma yc <[email-masked]>
Date: Wed, 9 Nov 2011 19:12:41 +0800

Hi Salvatore

Thank you for your comments. Please see inline.

> no I am saying that a sensor can issue a multicast CoAP GET with an HTTP URI
It seems a little bit weird to carry http uri in CoAP GET.
Since the uri mapping has been discussed in draft-castellani-core-http-mapping,
how about just use CoAP uri and specify that homogeneous mapping is used
for such kind of GET.