On Thu, 24 May 2018 at 20:44, Michael Richardson <mcr+i...@sandelman.ca> wrote:
> > Mališa Vučinić <malis...@gmail.com> 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. Sure it is, every attempt was made to have JP just a regular CoAP proxy with no application code. I claim that the current text is fully compliant with RFC7252 proxy and also takes into consideration processing rules of OSCORE-aware proxy. 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. It seems we have misunderstandings on this :-) > > >> 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. Sure we do, we use Proxy-Scheme in order to keep OSCORE-aware proxy processing to a minimum. See the section on the mappings of join protocol messages to CoAP. > > > 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 [ > ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ > >
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
