Subject: [core] Proxy vs Non-Proxy Requests (#82)

From: Brian Frank <[email-masked]>
Date: Sat, 4 Dec 2010 14:14:16 -0500

Currently the spec requires end-points to examine the Uri-Authority to
determine if they request is for itself or a request to be proxied to
another server.  There as been some discussion about if this is robust
enough as tracked by ticket #82.  Couple specific problems with current
design:

  - what should non-proxies do with Uri-Authority?  are they are they
required to check it?

  - what are the exact semantics to check if a Uri-Authority is yourself?
 local host, etc issues make this potential non-trivial

All the solutions that I can image including those suggested in ticket #82
and others:

1.  Use of the Uri-Authority option can only be used for proxy requests;
Pros is that is super simple to implement and understand.  A non-proxy
automatically rejects requests with this option.  Proxies immediately know
to forward it on if they see this option.  Cons is that it doesn't actually
allow complex features like virtual hosts (although is that really needed?)

2. Use an alternate, parallel Uri-Authority option such as
Proxy-Uri-Authority.  Requests to Uri-Authority are assumed to be for
end-point itself, requests to Proxy-Uri-Authority are assumed to be another
server.  Pros is easy for proxies to process.  But it leaves open the
question of what non-proxy should do with Uri-Authority - just ignore it?
 Check it?

3. Use additional boolean/marker option such as Request-Proxy.  This would
paired with Uri-Authority and would imply that authority is not end-point
itself.  Cons: first off requires an additional byte in message vs option 1
and 2.  Second cons is that now proxy has to check for Request-Proxy, then
do error checking to ensure Uri-Authority is also specified (assuming that a
missing Uri-Authority is an error).  Still simple, but doesn't seem quite as
elegant as option 1 or 2.

4. Use Uri-Scheme.  I've read the discussion and to be honest this makes no
sense to me.  Why would specifying the scheme as "coap" have anything to do
whether the client intended a proxy request?  I guess if we had two schemes
such as "coap" and "coap-proxy", then I can understand this design.  But it
doesn't seem as intuitive, efficient, or as robust as 1, 2, or 3.

5. Perform some bitwise shift of method codes.  This would work, but doesn't
seem intuitive or robust to me personally.

6. Potentially require proxies to be on another port so that all traffic is
completely separated. Don't know how this effects constrained IP stacks
though?  Or security?  And is it really a solution, support you have your
port configured incorrectly?

For simplicity, I would vote for option 1. If you use Uri-Authority option
its a proxy request.  If you omit it, then its intended as a request to the
end-point itself.  But maybe that is too simple in which case I would vote
for option 2.

---

From: Peter Bigot <[email-masked]>
Date: Sun, 5 Dec 2010 11:49:23 -0600

I think section 2.5.2 of CoAP-03 is pretty clear on how non-proxies should
treat Uri-Authority, except that it does indeed fail to say whether the
end-point must check it when it's present.  My assumption was "yes", just as
a node that supports only a single resource should still check whether the
Uri-Path is the expected value and not simply return that resource
regardless of the request URI.  How the end-point determines whether the
authority is itself is outside CoAP's scope, as it tends to depend on things
like DNS, availability at the CoAP level of the node's assigned addresses,
and implementation-specific configuration data.  We had discussed this in
detail perhaps six months ago, and I thought came to a reasonable compromise
that allowed those who felt the authority was unnecessary to omit it, while
those who disagreed could still make use of it.

I thought the resolution of #82 was to be a new (critical?) option, perhaps
Proxy-This, indicating that the client expected the request to be proxied.
I don't see how one gets more simple than that.

I do wish that the inclination to overload the presence or absence of
URI-related options with information not relevant to identifying the
resource would not be so tempting.  To do this complicates ones mental model
of what those options mean, and can prevent application of CoAP in
architectures and solutions not yet considered by the working group.  URIs
serve a valuable role in a variety of protocols and web technologies, and in
my opinion it's short-sighted to assume that our current understanding of
their application in constrained domains is adequate to justify restricting
how they can be used by changing what they are or mean.

Peter

On Sat, Dec 4, 2010 at 1:14 PM, Brian Frank <[email-masked]> wrote:

> 5. Perform some bitwise shift of method codes.  This would work, but
> doesn't seem intuitive or robust to me personally.
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>
>