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

From: Carsten Bormann <[email-masked]>
Date: Sun, 24 Mar 2013 23:33:29 +0100

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

---

From: Floris Van den Abeele <[email-masked]>
Date: Tue, 26 Mar 2013 15:52:33 +0100

In section 2 the definitions of reverse and forward proxies are not that 
clear to me. The text tries to clarify:

    Reverse and Forward proxies are technically very similar, with main
    differences being that the former appears to a client as an origin
    server while the latter does not, and that clients may be unaware
    they are communicating with a proxy.

In my mind, a typical reverse cross protocol proxy (RXPP hereafter) 
exposes the following 'interface' http://www.proxy.com/foo/bar, which it 
internally translates to coap://<sensor>/resA. The RXPP might serve 
resources from multiple resources, but the HTTP client is unaware of 
this (RXPP appears as origin server).

My problem lies with a cross protocol proxy (XPP) with the following 
interface 
http://www.proxy.com/.wellknown/core-translate/1.2.3.4_4567/foo/bar?a=3 
(which is translated to coap://1.2.3.4:4567/foo/bar?a=3). This is also 
said to be an example of a reverse proxy (right?). However, in this case 
the HTTP client is aware that the XPP isn't the origin server, the 
actual origin server is mentioned in the request, so I would say it 
resembles a forward XPP. Reading section 10.2 of the core coap spec 
seems to confirm this (one difference is that the coap scheme is omitted 
in the 2nd example, but it is implied anyway).

Can the authors (or someone else) give clear examples of forward and 
reverse http/coap cross protocol proxies?
Once I better understand the distinction, I hope to do a more thorough 
review of the draft.

Greets,
Floris

Op zo 24 mrt 2013 23:33:29 CET, Carsten Bormann schreef:
>
> 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.
> 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: Carsten Bormann <[email-masked]>
Date: Tue, 26 Mar 2013 16:12:29 +0100

On Mar 26, 2013, at 15:52, Floris Van den Abeele <[email-masked]> wrote:

> Can the authors (or someone else) give clear examples of forward and reverse http/coap cross protocol proxies?

core-coap-14 defines:

   Forward-Proxy
      A "forward-proxy" is an endpoint selected by a client, usually via
      local configuration rules, to perform requests on behalf of the
      client, doing any necessary translations.  Some translations are
      minimal, such as for proxy requests for "coap" URIs, whereas other
      requests might require translation to and from entirely different
      application-layer protocols.

   Reverse-Proxy
      A "reverse-proxy" is an endpoint that stands in for one or more
      other server(s) and satisfies requests on behalf of these, doing
      any necessary translations.  Unlike a forward-proxy, the client
      may not be aware that it is communicating with a reverse-proxy; a
      reverse-proxy receives requests as if it was the origin server for
      the target resource.

... and goes on (5.7):

   In an overall architecture for a Constrained RESTful Environment,
   proxies can serve quite different purposes.  Proxies can be
   explicitly selected by clients, a role that we term "forward-proxy".
   Proxies can also be inserted to stand in for origin servers, a role
   that we term "reverse-proxy".  Orthogonal to this distinction, a
   proxy can map from a CoAP request to a CoAP request (CoAP-to-CoAP
   proxy) or translate from or to a different protocol ("cross-proxy").
   Full definitions of these terms are provided in Section 1.2.

   Notes:  The terminology in this specification has been selected to be
      culturally compatible with the terminology used in the wider Web
      application environments, without necessarily matching it in every
      detail (which may not even be relevant to Constrained RESTful
      Environments).  Not too much semantics should be ascribed to the
      components of the terms (such as "forward", "reverse", or
      "cross").

      HTTP proxies, besides acting as HTTP proxies, often offer a
      transport protocol proxying function ("CONNECT") to enable end-to-
      end transport layer security through the proxy.  No such function
      is defined for CoAP-to-CoAP proxies in this specification, as
      forwarding of UDP packets is unlikely to be of much value in
      Constrained RESTful environments.  See also Section 10.2.7 for the
      cross-proxy case.

So the point is that a client always knows when it is using a Forward-Proxy, i.e., it has explicitly chosen to talk to it as opposed to the origin server.  We have the options Proxy-Uri and Proxy-Scheme that enable to express this choice explicitly:

5.7.2.  Forward-Proxies

   CoAP distinguishes between requests made (as if) to an origin server
   and a request made through a forward-proxy.  CoAP requests to a
   forward-proxy are made as normal Confirmable or Non-confirmable
   requests to the forward-proxy endpoint, but specify the request URI
   in a different way: The request URI in a proxy request is specified
   as a string in the Proxy-Uri Option (see Section 5.10.2), while the
   request URI in a request to an origin server is split into the Uri-
   Host, Uri-Port, Uri-Path and Uri-Query Options (see Section 5.10.1);
   alternatively the URI in a proxy request can be assembled from a
   Proxy-Scheme option and the split options mentioned.

There is no way in a URI to specify the use of a forward-proxy.
Which forward-proxy is used is decided by the client based on local information (which may include information gleaned from the URI, of course).  The URI continues to looks

For a reverse-proxy, the client might be thinking it is talking to the actual origin server:
The URI directly points to the reverse-proxy, but instead of serving its resource directly, the reverse-proxy defers to an origin server (or another reverse proxy!).

5.7.3.  Reverse-Proxies

   Reverse-proxies do not make use of the Proxy-Uri or Proxy-Scheme
   options, but need to determine the destination (next hop) of a
   request from information in the request and information in their
   configuration.  E.g., a reverse-proxy might offer various resources
   the existence of which it has learned through resource discovery as
   if they were its own resources.  The reverse-proxy is free to build a
   namespace for the URIs that identify these resources.  A reverse-
   proxy may also build a namespace that gives the client more control
   over where the request goes, e.g. by embedding host identifiers and
   port numbers into the URI path of the resources offered.

draft-castellani-core-http-mapping-07.txt also alludes to the fact that there may be "transparent" (intercepting) entities intervening on the path to the origin server and acting a bit like reverse-proxies, except that the network provider has chosen to interpose them as opposed to the client.

Of course, all these types can be combined on a path to an origin server: A client can use a forward-proxy to talk to a reverse-proxy, with any number of additional reverse-proxies (and "transparent" (intercepting) proxies) on the way to the origin server.

Maybe draft-castellani-core-http-mapping-07.txt doesn't really need to define the terms forward-proxy and reverse-proxy, but can reference them from the core coap spec.  "transparent"/intercepting proxies are not discussed in core-coap, though.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 26 Mar 2013 16:18:51 +0100

On Mar 26, 2013, at 16:12, Carsten Bormann <[email-masked]> wrote:

> The URI continues to looks

(Apple Mail crashing again and interrupting my thought process.

I was trying to say:)

The URI continues to look as if the client was directly talking to the origin server.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 26 Mar 2013 16:30:25 +0100

On Mar 26, 2013, at 15:52, Floris Van den Abeele <[email-masked]> wrote:

> My problem lies with a cross protocol proxy (XPP) with the following interface http://www.proxy.com/.wellknown/core-translate/1.2.3.4_4567/foo/bar?a=3 (which is translated to coap://1.2.3.4:4567/foo/bar?a=3). This is also said to be an example of a reverse proxy (right?). However, in this case the HTTP client is aware that the XPP isn't the origin server,

Actually, it may not be -- this URI may have been supplied by a server to the client, and clients aren't supposed to be snooping into the structure of URI path anyway.

> the actual origin server is mentioned in the request, so I would say it resembles a forward XPP. Reading section 10.2 of the core coap spec seems to confirm this (one difference is that the coap scheme is omitted in the 2nd example, but it is implied anyway).

Defining a convention for how a reverse cross-proxy builds the URIs under which it offers the resources of an origin server might look like allowing a client to use the reverse cross-proxy as if it were a forward-proxy.  And that may actually be a benefit of such a convention, because it is hard to carry forward-proxy configuration information through client APIs (and, even more, through sequences of prepended proxies).  But I would expect these reverse proxies to make their URIs available through a resource directory, so there may never be a need for a client to compute a URI.  The convention would then just help in understanding what is going on, and in sending diagnostic requests to a reverse cross-proxy.

Grüße, Carsten

---

From: "Rahman, Akbar" <[email-masked]>
Date: Tue, 26 Mar 2013 13:25:53 -0400

Hi Carsten,

With respect to your comment:

Yes, the definition for forward-proxy can be referenced to the coap-14 I-D.  However, the reverse-proxy definition in coap-14 does not explicitly discuss HTTP-CoAP translation (which is the key point of this I-D and the reason that we thought it was worthwhile to explicitly define reverse-proxy in this way in this I-D).  Do you agree with this logic?

Best Regards,

Akbar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: Tuesday, March 26, 2013 11:12 AM
To: Floris Van den Abeele
Cc: core WG
Subject: Re: [core] Call for reviews of draft-castellani-core-http-mapping

core-coap-14 defines:

   Forward-Proxy

   Reverse-Proxy

... and goes on (5.7):

5.7.2.  Forward-Proxies

5.7.3.  Reverse-Proxies

Grüße, Carsten

---

From: "Dijk, Esko" <[email-masked]>
Date: Wed, 27 Mar 2013 08:26:15 +0000

Hi all,

In my view it would be best to base ourselves on the coap-14 definitions. These already mention that translations between protocols can be done, so that should be ok for our HTTP-CoAP translation purpose. But I agree with Akbar we still should have some text in draft-castellani-core-http-mapping that shows what the general definitions mean when applied to HTTP-to-CoAP request translation.

However, there was some discussion among the authors of draft-castellani-core-http-mapping about one part of the coap-14 definition:
 "Unlike a forward-proxy, the client may not be aware that it is communicating with a reverse-proxy;"

This was considered too vague. The client's "awareness" is not something where we can technically distinguish forward/reverse proxies. The second part of the sentence is more useful:
 " a  reverse-proxy receives requests as if it was the origin server for the target resource".
This is also what the longer definition in draft-castellani-core-http-mapping tries to say. And [I-D.ietf-httpbis-p1-messaging] also defines the distinction in this manner. Floris, I hope this makes the distinction clear? In a next version we could refer to the coap-14 definitions and add some text that applies these in the specific HTTP-CoAP translation context.

So the authors value a clear technical distinction between forward and reverse proxy without having to debate on "awareness" and whether the client can or will do URI structure interpretation.

regards,
Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rahman, Akbar
Sent: Tuesday, March 26, 2013 18:26
To: Carsten Bormann
Cc: core WG
Subject: Re: [core] Call for reviews of draft-castellani-core-http-mapping

Hi Carsten,

Best Regards,

Akbar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: Tuesday, March 26, 2013 11:12 AM
To: Floris Van den Abeele
Cc: core WG
Subject: Re: [core] Call for reviews of draft-castellani-core-http-mapping

core-coap-14 defines:

   Forward-Proxy

   Reverse-Proxy

... and goes on (5.7):

5.7.2.  Forward-Proxies

5.7.3.  Reverse-Proxies

Grüße, Carsten

________________________________
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: Wed, 27 Mar 2013 15:36:41 +0000

[Kerry wrote:]
> I'm not clear on how the term "awareness" is applied, but it seems that selecting a forward
> proxy is typically a configuration setting on the client.  Perhaps configuration is a distinction
> that can be made between the forward and reverse proxy types?  "Awareness" may also
> indicate that a known cross-proxy sits between the client and the data; in this case the client
> specifies the path to the proxy as well as the origin server?

Hi Kerry,

using configuration (in general) as the distinguishing factor has some issues. I see now that coap-14 also uses this distinction in page 7 "Forward-Proxy" definition, so the issue is there as well.

For example, a client may be configured to access a proxy using HTTP syntax for origin servers. Then the HTTP-to-CoAP proxy can not "see" from a request whether the client is configured to do this, or if the client just got a URL from someone and the client isn't configured to do anything special, it is just requesting the URL. So, the proxy can't detect whether it should be a forward proxy or a reverse proxy. So this collapses both definitions into one: the proxy is both at the same time!

Any distinction should rather be a clear technical difference in the proxy itself. (And this is how coap-14 "Reverse-Proxy" page 7 and httpbis-p1-messaging currently define it.)
Thus the proposal in context of HTTP-CoAP mapping: if a proxy accepts HTTP requests in the HTTP syntax for origin servers (i.e. as an origin server), then we call it reverse proxy.
If a proxy accepts HTTP requests in the HTTP proxy syntax, then we call it forward proxy. (Described in section 10.2 of coap-14)
If it accepts both, then it is both a reverse and forward proxy combined in one device.

regards,
Esko

From: [email-masked] [mailto:[email-masked]] On Behalf Of Kerry Lynn
Sent: Wednesday, March 27, 2013 16:23
To: Dijk, Esko
Subject: Re: [core] Call for reviews of draft-castellani-core-http-mapping

On Wed, Mar 27, 2013 at 4:26 AM, Dijk, Esko <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

So the authors value a clear technical distinction between forward and reverse proxy without having to debate on "awareness" and whether the client can or will do URI structure interpretation.
I'm not clear on how the term "awareness" is applied, but it seems that selecting a forward
proxy is typically a configuration setting on the client.  Perhaps configuration is a distinction
that can be made between the forward and reverse proxy types?  "Awareness" may also
indicate that a known cross-proxy sits between the client and the data; in this case the client
specifies the path to the proxy as well as the origin server?

-K-
regards,
Esko

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Rahman, Akbar
Sent: Tuesday, March 26, 2013 18:26
To: Carsten Bormann
Cc: core WG
Subject: Re: [core] Call for reviews of draft-castellani-core-http-mapping

Hi Carsten,

Best Regards,

Akbar

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Carsten Bormann
Sent: Tuesday, March 26, 2013 11:12 AM
To: Floris Van den Abeele
Cc: core WG
Subject: Re: [core] Call for reviews of draft-castellani-core-http-mapping

core-coap-14 defines:

   Forward-Proxy

   Reverse-Proxy

... and goes on (5.7):

5.7.2.  Forward-Proxies

5.7.3.  Reverse-Proxies

Grüße, Carsten

[email-masked]<mailto:[email-masked]>
[email-masked]<mailto:[email-masked]>

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