Subject: [core] htpp/coap proxy

From: peter van der Stok <[email-masked]>
Date: Wed, 30 May 2012 15:20:38 +0200

Hi Esko,

reaction to statements below:

Currently we assume that for typical use
cases the proxy is a forward proxy - i.e. CoAP clients use the
Proxy-URI field to request to an HTTP server. This still allows going
from CoAP in mesh networks to HTTP legacy services anywhere. Is there
any reason here why you ask for a reverse proxy (CoAP-to-HTTP) for
this case?

I am not aware of asking for a reverse proxy for the coap/http case. My 
only comment was: "to be filled in".
Given the purpose of the coap/http proxy, a forward proxy seems the 
best approach.

Note - HTTP-to-CoAP multicast will not be addressed anymore; as part
of the simplification of the draft.

I hope that a small paragraph discussing the possible additions remains 
included to serve as a reminder.

Many thanks,

peter

Dijk, Esko schreef op 2012-05-23 17:41:
Hello Peter,

We (authors) agree on specifying default / preferable ways of
translation. Also the use of DNS, DNS-SD and RD for URI translation
can be added, if this supports our specific use cases. (These use
cases will be included in the next update of the draft as confirmed by
Akbar earlier.) The next version will probably not have all the
details related to DNS-SD and RD yet so we aim to add that later.

Note - HTTP-to-CoAP multicast will not be addressed anymore; as part
of the simplification of the draft.

The second priority is access from coap in mesh network to http
anywhere. To be filled in……

That is now to be addressed in a separate draft (see email by Akbar
http://www.ietf.org/mail-archive/web/core/current/msg03352.html ),
also based on use cases. Currently we assume that for typical use
cases the proxy is a forward proxy - i.e. CoAP clients use the
Proxy-URI field to request to an HTTP server. This still allows going
from CoAP in mesh networks to HTTP legacy services anywhere. Is there
any reason here why you ask for a reverse proxy (CoAP-to-HTTP) for
this case?

In other words, if there's a reason or use case to not want a forward
C2H proxy, but, instead, want a reverse C2H proxy. In that case a CoAP
client can just request to coap://httpserver.example.com, not using
any Proxy-URI field in the request. Then, through some (DNS and/or
DNS-SD) configuration this request ends up with the C2H proxy, which
performs the actual http://httpserver.example.com [1] connecting to
httpserver.

Our splitting proposal so far considered only the C2H forward-proxy
case.

regards, (on behalf of all authors)

-- 
Peter van der Stok
mailto: [email-masked]
www: www.vanderstok.org
tel NL: +31(0)492474673     F: +33(0)966015248