> Why should we reject if it is included? The Registrar-Proxy would typically not accept any CoAP forward-proxy request, that is, any request containing the Proxy-Uri or Proxy-Scheme Option. Instead it would return 5.05 (Proxying Not Supported) error as defined already by 7252 Section 5.7.2.
It doesn't operate as a forward-proxy because we have defined it as a reverse-proxy (at least, we have done that per the latest discussion emails.) In practice a CoAP endpoint of course could operate as both forward and reverse proxy, but I don't think we have to say anything about such a situation. (RFC 7252 should cover any remaining cases and what to do in case the same CoAP endpoint is used for multiple purposes.) Esko -----Original Message----- From: Michael Richardson <[email protected]> Sent: Monday, October 31, 2022 15:30 To: Toerless Eckert <[email protected]> Cc: Esko Dijk <[email protected]>; [email protected]; [email protected] Subject: Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP Toerless Eckert <[email protected]> wrote: > Can we make sure that the text does explain why the field is not > inclueded, and explain that the packet MUST be rejected if it was > included ? Why should we reject if it is included? > Seems like: > Field is not included and would cause rejection of the packet if it was > present, because it is inappropriate for the initiator to choose the > next hop after the proxy not only because the Pledge would not know it, > but because it is also not appropriate for security purposes for the > Pledge to choose it. > Do i correctly understand this ? I don't think it's about the initiator choosing the next proxy. _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
