Regarding your comment : "most of the changes to the CA layer that make it work with HTTP become superfluous and should not be applied." -> CA layer affect thinDevice-G/W side not for G/W-WebServer(HTTP/HTTPS).
We can release the HTTPS code for G/W-WebServer incrementally. At least, HTTPS does not affect the thinDevice-G/W path implementation. BR, Uze Choi -----Original Message----- From: Thiago Macieira [mailto:thiago.macie...@intel.com] Sent: Friday, July 29, 2016 1:19 AM To: ???(Uze Choi) Cc: ashok.channa at samsung.com; iotivity-dev at lists.iotivity.org Subject: Re: [dev] CoAP - HTTP Proxy Review Request On quinta-feira, 28 de julho de 2016 10:24:21 PDT ???(Uze Choi) wrote: > Then, I think this is not mandatory, because this path is out of the > OCF security scope. Correct, it's out of OCF security. IoTivity security rules still apply, though. I'm saying that IoTivtiy should not accept the code that implements HTTP only. IoTivity should require that its contributor implement HTTPS before the code gets accepted. I've given my argument for this time and again. But I'm going to repeat them: * there are a lot of services out there that are HTTPS-only. For the proxy feature to be really useful, we need HTTPS. * for services that allow both HTTP and HTTPS, the choice should be HTTPS. That means we should steer our users to using HTTPS as much as possible. * there will be a change in the architecture due to the use of an external library, which I want to see before I review the code. * due to the use of that library implementing the TCP socket, most of the changes to the CA layer that make it work with HTTP become superfluous and should not be applied. I don't want to see review code that will be undone. * a well-known third-party library will implement the HTTP socket better than our hand-written and hacked CoAP+TCP code. Any one of the arguments above is sufficient for me to say that the lack of HTTPS support, with a well-known and well-trusted third-party library, is automatic -1 on the feature. All five combined should make it a -5... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center