Regarding second argue point, do you mean HTTP communication in ThinDevice--G/W or G/W--WebServer? If G/W--WebServer, HTTPS part is not strictly required. Otherwise, channel only requires coap security. I cannot understand what is the discussion point.
BR, Uze Choi -----Original Message----- From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Thiago Macieira Sent: Wednesday, July 27, 2016 12:56 AM To: ashok.channa at samsung.com Cc: iotivity-dev at lists.iotivity.org Subject: Re: [dev] CoAP - HTTP Proxy Review Request Em ter?a-feira, 26 de julho de 2016, ?s 04:09:28 PDT, ?? escreveu: > >You're describing a hybrid of two things. Let me explain how I see it: > >1) a pure CoAP-HTTP proxy, as defined by RFC 7252 section 10.1 This > >takes Proxy-Uri and/or Proxy-Scheme headers, but this functionality > >is not an OCF service, is not restricted to CBOR, does not follow the > >OCF > >>payload structure, and does not translate. It should be provided on > >>a > >separate port number and an OCF resource should be listed in /oic/res > >that gives >information on how to connect to the proxy. > > > >2) an OCF resource that fetches remote resources and responds This is > >a regular OCF resource, listed in /oic/res, that responds to OCF- > >defined CRUDN requests and replies, obeys OCF security requirements > >including encryption and ACL matching. The payloads in requests and > >replies are formatted according to the OCF specification, using CBOR. > > > >In the previous emails, I got really confused about whether you're > >referring to #1 or #2. You talk about parts of #1 and parts of #2, > >which in my mind doesn't make sense and is just confusing me. > > > >Please clarify what you mean by describing the packet flow. What does > >a > >>client send, what does the proxy reply with? > > It is a combination of both like IoTivity. We are using CoAP standards > and exposing our resource model to achieve a better functionality. If > you compare with IoTivity, it does the same. Internally we use CoAP > and use our OCF defined resource model. This feature is not different to that. I disagree with your premise. We're using CoAP standards without modification for transport. OCF's innovation is the resources that it provides on top of CoAP. Aside from that, it's regular CoAP and this point is proven by the fact that a generic CoAP client like Copper can query an OCF device and get meaningful replies. Since I disagree with your premise, I can't accept it as a justification for what you're doing. Moreover, I really think you're doing something very confusing. Either you have "a resource that fetches content from elsewhere" or you have a pure CoAP proxy. I don't see it possible to have something half- way. > >> Not acceptable. HTTPS is not optional. Therefore, the first release > >>must have it.>> I will review the code when you have support for > >>HTTPS. Not before. > > Why not acceptable, I did not understand. It?s based on the delivery > schedule and progressive approach. currently many webservers not > required https to fetch data, why we need to push this as mandatory. I > don?t think HTTPS is mandatory to push the source. Because security is not optional. Therefore, HTTPS is mandatory. And as I said before: many web services *do* offer HTTPS, even if not requiring it. OCF devices should be developed to use HTTPS whenever possible, not just when required. I don't know what schedule you're talking about. The code was first uploaded on April 4, without following the development process for a large feature. This thread started on July 15. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
