On quinta-feira, 28 de julho de 2016 06:32:31 PDT ?? wrote: > >>Because the implementation may not want to run the proxy on the same port > >>as the main OCF resources, for security reasons or for >>implementation > >>details. The information in either the /oic/res reply or the proxy's own > >>resource should include that information. I'm not >>asking you to design > >>the implementation like that. But I am asking that you make it possible > >>for another implementation to do that. > > Proxy virtual uri follows same functionality as any other virtual resources > its security mechanisms. if we deviate , we are creating replica of process > without having any additional benefits.
There are additional benefits. But remember that you said it's not the OCF protocol, it's following the CoAP protocol if the Proxy-Uri header field is set. If that is the case, what security concerns are applied? Is there an ACL? Is it required to use DTLS, or can the unsecured multicast port also reply to proxy? > >>Feel free to design a reply format that has less overhead. But make sure > >>that an implementation that chooses not to use the same port >> number or > >>IP address is still possible. > As CA is multi-threaded and udp server does not hold any connection , I > think it does not require any new server only to receive proxy requests. You're thinking in IoTivty terms only. I'm asking you to think of the spec. When you design the resource types and the replies, you have to think of other implementations besides IoTivity. They may not want to use the same port, for any reason. So please design the properties such that they will work for those other implementations. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
