Mališa Vučinić <[email protected]> wrote: > @Michael, @Christian
> I am re-reading RFC7252, Section 5.7.2:
okay, but I'm not claiming that the Join Proxy is a CoAP Proxy by the rules
given in 7252. It started as just a circuit proxy (i.e. algorithm gateway), but
we wanted it to be stateless, so we (ab)used some CoAP things to do that.
I never intended it go into the contents of the packet, interpret CoAP in any
way.
>> Unless a proxy is configured to forward the proxy request to another
proxy,
>> it MUST translate the request as follows: the scheme of the request URI
>> defines the outgoing protocol and its details (e.g., CoAP is used over
UDP
>> for the "coap" scheme and over DTLS for the "coaps" scheme.) For a
>> CoAP-to-CoAP proxy, the origin server's IP address and port are
determined
>> by the authority component of the request URI, and the request URI is
>> decoded and split into the Uri-Host, Uri- Port, Uri-Path and Uri-Query
>> Options. This consumes the Proxy-Uri or Proxy-Scheme option, which is
>> therefore not forwarded to the origin server.
We don't use Proxy-URI or Proxy-Scheme.
> It seems to be OK, and doesn't prevent much of the CoAP proxy
functionality
> for other purposes. I am waiting for the confirmation from Christian of
> there is any other RFC7272 pitfall with this before doing the changes in
> the draft.
> I kind of liked the 6tisch.arpa "thing", but no argument with ~13-byte
> savings :-).
I don't think we need it.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
