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
