Subject: Re: [core] Call for reviews of draft-castellani-core-http-mapping

From: peter van der Stok <[email-masked]>
Date: Tue, 09 Apr 2013 10:45:56 +0200

Dear wg,

Review of draft-castellani-core-http-mapping, including coap-14 section 
10.

For me text and objective have become clearer compared to earlier 
versions.
The objective of the document to describe proxies such that proxies 
from different manufacturers can be exchanged is a valid motivation for 
the document.

My first concern is the uri naming convention and proxy definition. 
Concerning proxy definition:
I am happy with the explanation of forward, cross and reverse proxy, it 
clarifies the bit opaque text of coap-14. However, it does not help me 
much because the cullen example of 
I-D.bormann-core-cross-reverse-convention is presented as reverse proxy 
example while the text in castellani made me think it is a forward proxy 
example, because the client seems to be aware that translation takes 
place. There still seems to be a gap in my understanding from purely 
reading the texts.
Concerning naming convention:
The document does not help much in restricting the URI naming 
conventions. I would expect one of two things:
1)	Strict guidelines how to translate uris (restrict the number of 
possibilities)
2)	Provide means to define the uri translation on the proxy.
I do not see any other way of making sure that proxies of different 
manufacturers can be exchanged.

My second concern is that the document only treats http-coap 
translation. The case coap-http seems more urgent. We do not want to 
provide the small devices with a http/tcp code next to the coap/udp 
code, while these devices will need to talk to “legacy” http back-end 
servers. Suggestion: add the coap-http part.

Individual nits and suggestions.
Page 6, section 5, all 2, line 5…….explicitly indicates THAT it targets 
…… (that forgotten?)
Section 5, all 3, unicast http to multicast coap is a completely 
different document (remove the currently in the “currently out of 
scope”. Wouldn’t you discourage the unicast to multicast aspect in a 
standardized proxy?
Section 5.1 caching: add “given” to …. all request traffic to a given 
COAP server…….
Sec 5.1 Multicast; possibly the wrong reason for a valid efficiency 
argument: to connect a proxy interface to the mesh network.
Sec 5.1 TCP/UDP: I do not see the placement aspect here
Sec 5.2 Notes. Do you not need to give formulas? For example in note 8, 
the determination of max-age value
Sec 5.4 how to configure the limit and queuing/dropping behavior? The 
document should specify an interface.
Sec 5.5 and 5.6 I like the effort to specify limits of behaviors.
Sec 7. I understand that a proxy represents the typical “man in the 
middle” threat. Having it securely connected to the network before any 
access and a regular reconnection may have a positive effect.

hope this helps,

peter

Carsten Bormann schreef op 2013-03-24 23:33:
> In Orlando, we said we were trying to increase the level of attention
> on the HTTP mapping draft with a view to making it a WG document very
> soon.
> So, if you have comments on it now, please send them to the list.
> We had a few people volunteering to review the draft as a
> prerequisite to a call for WG adoption, so please do send in these
> (short or long, as you like) reviews.
> Of course WG adoption means that the WG starts considering this as a
> WG draft, not that we all already agree with every detail, but any
> concerns about scoping and general approach should be discussed now.
> 
> Grüße, Carsten
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: "Dijk, Esko" <[email-masked]>
Date: Thu, 11 Apr 2013 16:14:58 +0000

Hi Peter,

thanks for your comments. About your main concerns:
1. Proxy definition could be updated. There was already an email thread on this; where I propose to define the forward/reverse proxy in such a way that the "client awareness" does not play a role anymore. (So: only the syntax used to access the proxy determines forward or reverse.)
2. URI naming convention for reverse proxy will be added in the next version.
3. CoAP-to-HTTP conversion: this part was removed earlier based on WG feedback that our scope is too wide. I do agree that this topic is also useful. As a separate I-D perhaps?

regards,
Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of peter van der Stok
Sent: Tuesday, April 09, 2013 10:46
To: [email-masked]
Subject: Re: [core] Call for reviews of draft-castellani-core-http-mapping

Dear wg,

Review of draft-castellani-core-http-mapping, including coap-14 section 10.

For me text and objective have become clearer compared to earlier versions.
The objective of the document to describe proxies such that proxies from different manufacturers can be exchanged is a valid motivation for the document.

My first concern is the uri naming convention and proxy definition.
Concerning proxy definition:
I am happy with the explanation of forward, cross and reverse proxy, it clarifies the bit opaque text of coap-14. However, it does not help me much because the cullen example of I-D.bormann-core-cross-reverse-convention is presented as reverse proxy example while the text in castellani made me think it is a forward proxy example, because the client seems to be aware that translation takes place. There still seems to be a gap in my understanding from purely reading the texts.
Concerning naming convention:
The document does not help much in restricting the URI naming conventions. I would expect one of two things:
1)      Strict guidelines how to translate uris (restrict the number of
possibilities)
2)      Provide means to define the uri translation on the proxy.
I do not see any other way of making sure that proxies of different manufacturers can be exchanged.

My second concern is that the document only treats http-coap translation. The case coap-http seems more urgent. We do not want to provide the small devices with a http/tcp code next to the coap/udp code, while these devices will need to talk to “legacy” http back-end servers. Suggestion: add the coap-http part.

Individual nits and suggestions.
Page 6, section 5, all 2, line 5…….explicitly indicates THAT it targets …… (that forgotten?) Section 5, all 3, unicast http to multicast coap is a completely different document (remove the currently in the “currently out of scope”. Wouldn’t you discourage the unicast to multicast aspect in a standardized proxy?
Section 5.1 caching: add “given” to …. all request traffic to a given COAP server…….
Sec 5.1 Multicast; possibly the wrong reason for a valid efficiency
argument: to connect a proxy interface to the mesh network.
Sec 5.1 TCP/UDP: I do not see the placement aspect here Sec 5.2 Notes. Do you not need to give formulas? For example in note 8, the determination of max-age value Sec 5.4 how to configure the limit and queuing/dropping behavior? The document should specify an interface.
Sec 5.5 and 5.6 I like the effort to specify limits of behaviors.
Sec 7. I understand that a proxy represents the typical “man in the middle” threat. Having it securely connected to the network before any access and a regular reconnection may have a positive effect.

hope this helps,

peter

Carsten Bormann schreef op 2013-03-24 23:33:
> We had a few people volunteering to review the draft as a prerequisite
> to a call for WG adoption, so please do send in these (short or long,
> as you like) reviews.

________________________________
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: Klaus Hartke <[email-masked]>
Date: Thu, 11 Apr 2013 22:46:06 +0300

Esko Dijk wrote:
> I propose to define the forward/reverse proxy in such a way that the "client awareness" does not play a role anymore

Client awareness is pretty much what distinguishes a forward proxy
from a reverse proxy.

Assume a client retrieves a representation of a resource and this
representation contains a link. Then there are the following cases:

* The client uses the information in the URI to connect to a server.
The server at that address is the authoritative source for
representations of the resource identified by the URI, so it returns a
response directly.

     -> "Origin server".

* The client uses the information in the URI to connect to a server.
However, the server is _not_ the authoritative source for
representations of the resource identified by the URI. Instead, it has
been configured to obtain the representation from an unrelated third
party. Which third party it connects to can come from local
configuration or be embedded in the URI. From the perspective of the
client, the response looks and feels exactly as a response from an
origin server, though.

     -> "Reverse proxy". It is an unilateral decision of the server to
obtain the representation from a third party.

* The client does _not_ use the information in the URI. Instead, it
has been configured to connect to an unrelated third party. The client
requests this third party to obtain the representation of the resource
identified by the URI, well aware that this third party not the
authoritative source for the representation.

     -> "Forward proxy". It is an unilateral decision of the client to
request a third party to obtain the representation and not to connect
to the server specified in the URI.

The protocol between client--proxy and proxy--origin-server do not
have to be the same. For example, a client can make an HTTP request to
a reverse proxy and the reverse proxy makes a CoAP request to the
origin server.

http://coap.me/ is a good example of an HTTP/CoAP cross-protocol
reverse proxy. It embeds the information which CoAP server to connect
to in the http:// URI, and rewrites all links in representations
obtained from CoAP servers to http:// URIs, so you can use a simple
web browser to browse CoAP servers.

The protocol between client--forward-proxy is often a bit different
than between client--origin-server and client--reverse-proxy. For
example, when a client makes a CoAP request to a forward proxy, the
URI is transmitted in the Proxy-Uri Option and not in the Uri-*
Options. Similarly, when a client makes an HTTP request to a forward
proxy, the entire URI is transmitted in the request line and not in
the Host header field.

Unfortunately, in case of a HTTP/CoAP cross-protocol forward proxy, we
cannot simply put a coap:// URI in the HTTP request line. So we need a
different protocol that both the client and the forward-proxy agree on
to encode this request. One way is to let the client translate the
coap:// URI to an http:// URI in a standardized way, and the forward
proxy translates the http:// URI back to the original coap:// URI.

The line between reverse proxy and forward proxy seems to blur when we
embed coap:// URIs in http:// URIs in the reverse proxy case, and
translate coap:// URIs to http:// URIs in the forward proxy case. But
it doesn't.

- Does the client have an http:// URI and does the HTTP server make
the unilateral decision to make a CoAP request (based on an embedded
coap:// URI in the http:// URI, opaque to the client)? Reverse proxy.

- Does the client have a coap:// URI and does it make the unilateral
decision to perform an HTTP request (with the coap:// URI translated
to a http:// URI according to some standardized scheme)? Forward
proxy.

Just my 2 cents.

Klaus

---

From: "Dijk, Esko" <[email-masked]>
Date: Fri, 12 Apr 2013 07:06:51 +0000

Hi Peter,

Forgot to mention about the case CoAP-HTTP: another reason the authors did not pursue this was that a CoAP client can simply use the CoAP forward proxying functionality (i.e. a CoAP request with a Proxy-URI option or Proxy-Scheme option containing a http:// URI) to access HTTP servers.

Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of peter van der Stok
Sent: Tuesday, April 09, 2013 10:46
To: [email-masked]
Subject: Re: [core] Call for reviews of draft-castellani-core-http-mapping

Dear wg,

hope this helps,

peter

---

From: "Dijk, Esko" <[email-masked]>
Date: Fri, 12 Apr 2013 08:15:36 +0000

Hi Klaus,

> - Does the client have an http:// URI and does the HTTP server make the unilateral decision
> to make a CoAP request (based on an embedded coap:// URI in the http:// URI, opaque to the client)?
>  Reverse proxy.
>
> - Does the client have a coap:// URI and does it make the unilateral decision to perform an HTTP request
> (with the coap:// URI translated to a http:// URI according to some standardized scheme)?
> Forward proxy.

If I apply the same argumentation, I may get these 2 cases:

1) The client has a coap:// URI and makes the unilateral decision to perform an HTTP request (with the coap:// URI translated to a http:// URI according to some standardized scheme) to the proxy. Then the proxy makes the decision to get the coap:// URI out of the HTTP request and performs a CoAP request using this coap:// URI.
-> Forward proxy.

2) The client got a http:// URI from someone, doesn't know a thing about CoAP, and this URI happens to be the same http:// URI as the one in point 1) above. Then the HTTP server makes the unilateral decision to get the coap:// URI out of the HTTP request and performs a CoAP request using this coap:// URI.
-> Reverse proxy.

The point/issue here is that the proxy acting in point 1) and 2) is the same HTTP server operating in exactly the same way. And it's both a Forward and a Reverse proxy depending on what the client knows. So it's hard to define guidelines for a Reverse Proxy only, because it could unknowingly be also a Forward Proxy. Therefore I argued that the distinction in this way is not useful.
(See also the earlier thread http://www.ietf.org/mail-archive/web/core/current/msg04170.html )

Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Klaus Hartke
Sent: Thursday, April 11, 2013 21:46
To: [email-masked]
Subject: Re: [core] Call for reviews of draft-castellani-core-http-mapping

Esko Dijk wrote:
> I propose to define the forward/reverse proxy in such a way that the
> "client awareness" does not play a role anymore

Client awareness is pretty much what distinguishes a forward proxy from a reverse proxy.

Assume a client retrieves a representation of a resource and this representation contains a link. Then there are the following cases:

* The client uses the information in the URI to connect to a server.
The server at that address is the authoritative source for representations of the resource identified by the URI, so it returns a response directly.

     -> "Origin server".

* The client uses the information in the URI to connect to a server.
However, the server is _not_ the authoritative source for representations of the resource identified by the URI. Instead, it has been configured to obtain the representation from an unrelated third party. Which third party it connects to can come from local configuration or be embedded in the URI. From the perspective of the client, the response looks and feels exactly as a response from an origin server, though.

     -> "Reverse proxy". It is an unilateral decision of the server to obtain the representation from a third party.

* The client does _not_ use the information in the URI. Instead, it has been configured to connect to an unrelated third party. The client requests this third party to obtain the representation of the resource identified by the URI, well aware that this third party not the authoritative source for the representation.

     -> "Forward proxy". It is an unilateral decision of the client to request a third party to obtain the representation and not to connect to the server specified in the URI.

The protocol between client--proxy and proxy--origin-server do not have to be the same. For example, a client can make an HTTP request to a reverse proxy and the reverse proxy makes a CoAP request to the origin server.

http://coap.me/ is a good example of an HTTP/CoAP cross-protocol reverse proxy. It embeds the information which CoAP server to connect to in the http:// URI, and rewrites all links in representations obtained from CoAP servers to http:// URIs, so you can use a simple web browser to browse CoAP servers.

The protocol between client--forward-proxy is often a bit different than between client--origin-server and client--reverse-proxy. For example, when a client makes a CoAP request to a forward proxy, the URI is transmitted in the Proxy-Uri Option and not in the Uri-* Options. Similarly, when a client makes an HTTP request to a forward proxy, the entire URI is transmitted in the request line and not in the Host header field.

Unfortunately, in case of a HTTP/CoAP cross-protocol forward proxy, we cannot simply put a coap:// URI in the HTTP request line. So we need a different protocol that both the client and the forward-proxy agree on to encode this request. One way is to let the client translate the coap:// URI to an http:// URI in a standardized way, and the forward proxy translates the http:// URI back to the original coap:// URI.

The line between reverse proxy and forward proxy seems to blur when we embed coap:// URIs in http:// URIs in the reverse proxy case, and translate coap:// URIs to http:// URIs in the forward proxy case. But it doesn't.

- Does the client have an http:// URI and does the HTTP server make the unilateral decision to make a CoAP request (based on an embedded coap:// URI in the http:// URI, opaque to the client)? Reverse proxy.

- Does the client have a coap:// URI and does it make the unilateral decision to perform an HTTP request (with the coap:// URI translated to a http:// URI according to some standardized scheme)? Forward proxy.

Just my 2 cents.

Klaus

---

From: peter van der Stok <[email-masked]>
Date: Mon, 15 Apr 2013 08:51:36 +0200

Hi Esko,

So it is indeed a small change to handle the coap-http case as well and 
does not warrant a different document.

Peter

Dijk, Esko schreef op 2013-04-12 09:06:
> Hi Peter,
> 
> Forgot to mention about the case CoAP-HTTP: another reason the
> authors did not pursue this was that a CoAP client can simply use the
> CoAP forward proxying functionality (i.e. a CoAP request with a
> Proxy-URI option or Proxy-Scheme option containing a http:// URI) to
> access HTTP servers.
> 
> Esko
> 
> from different manufacturers can be exchanged is a valid motivation
> for the document.
> 
> I am happy with the explanation of forward, cross and reverse proxy,
> it clarifies the bit opaque text of coap-14. However, it does not help
> me much because the cullen example of
> I-D.bormann-core-cross-reverse-convention is presented as reverse
> proxy example while the text in castellani made me think it is a
> forward proxy example, because the client seems to be aware that
> translation takes place. There still seems to be a gap in my
> understanding from purely reading the texts.
> Page 6, section 5, all 2, line 5…….explicitly indicates THAT it
> targets …… (that forgotten?) Section 5, all 3, unicast http to
> multicast coap is a completely different document (remove the
> currently in the “currently out of scope”. Wouldn’t you discourage the
> unicast to multicast aspect in a standardized proxy?
> Sec 5.1 TCP/UDP: I do not see the placement aspect here Sec 5.2
> Notes. Do you not need to give formulas? For example in note 8, the
> determination of max-age value Sec 5.4 how to configure the limit and
> queuing/dropping behavior? The document should specify an interface.
>> prerequisite
> 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.