Subject: [core] Proxy versus Gateway

From: Peter Bigot <[email-masked]>
Date: Sat, 23 Oct 2010 05:55:32 -0500

I and others have been somewhat confused by the CoAP terms "proxy" and
"cache", which unless clarified actually mix several concepts.  I found
enlightenment in section 5.2.3 of Fielding's
dissertation<http://www.ics.uci.edu/%7Efielding/pubs/dissertation/rest_arch_style.htm#sec_5_2_3>
:

Intermediary components act as both a client and a server in order to
forward, with possible translation, requests and responses. A proxy
component is an intermediary selected by a client to provide interface
encapsulation of other services, data translation, performance enhancement,
or security protection. A gateway (a.k.a., reverse proxy) component is an
intermediary imposed by the network or origin server to provide an interface
encapsulation of other services, for data translation, performance
enhancement, or security enforcement. Note that the difference between a
proxy and a gateway is that a client determines when it will use a proxy.

I had been misled because the non-technical use of the term "proxy" is
appropriate for several key roles in a CoAP system, including that entity
which serves as the intermediary for sleeping nodes.  The correct term for
this function is "gateway", as most clients need not be aware that they are
acting through an intermediary.

CoAP's use of the term "proxy" is inconsistent with these definitions:

5.3.  Proxying   A proxy is defined as a CoAP end-point which services
cached requests
   on behalf of other CoAP end-points.  Any node in a CoAP network may
   act as a proxy, although in general the node between the constrained
   network and the Internet at large SHOULD always support proxy
   functionality.

This is misleading because it focuses solely on caching, leaving aside the
other reasons why a proxy might be necessary.   As an example, many
constrained nodes  will not support DNS, and therefore cannot translate an
ASCII authority found within a URI to a network address.   Similarly,
constrained devices are unlikely to have the computational resources
necessary to support public key cryptography.   It would be better to say
that a proxy is an intermediary explicitly selected by the client as its
agent when dealing with any transaction it is unable to perform directly.

This is an important but currently implicit role in a CoAP system.  As with
the traditional use of proxy in web browsers (back before desktops became
full participants in the Internet), a CoAP client should need only one proxy
to which it can delegate all CoAP transactions it can't do itself.
Configuration of this proxy for a particular node is an administrative
function outside the scope of CoAP as an on-wire protocol.  (If multiple
proxies were expected at a client, there would have to be some way of
selecting which proxy to use for which operation, an unnecessary
complication that could easily be supported by delegation.)  CoAP need
merely provide a mechanism by which the full information required to
delegate the transaction can be conveyed, which it does.

I encourage use of the term "gateway" when referring to an entity that
supports sleeping nodes, coordinates group activities, or performs any other
role that might be hidden behind the authority part of a URI.

Caching in turn is a function that may be paired with a proxy or with a
gateway, but is not inherently coupled to either one.

If it's not too late to make so major a change in terminology and concept, I
would encourage a rewrite of section 5 to make clear that proxies,
gateways, and caches are independent functions.  I would contribute text for
this if the editors would find that helpful.

Peter