Hi Ashok,
Regarding this topic or argument, there are lots of progress until now, so not easy to understand by reading mail. Can I ask something fundamental/Please share the protocol detail for following use case? Use case: Thin Client ? gateway(proxy) ? HTTP server (Weather.com) Example of Request (from Thin client): URI options, Proxy-Uri option, Payload Example of response (from Thin client): URI options, Proxy-Uri option, Payload Example of Request (from G/W): URI options, Proxy-Uri option, Payload Example of response (from G/W): URI options, Proxy-Uri option, Payload BR, Uze Choi From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of ?? Sent: Tuesday, July 26, 2016 1:09 PM To: thiago.macieira at intel.com; Abhishek Sharma Cc: iotivity-dev at lists.iotivity.org Subject: Re: [dev] CoAP - HTTP Proxy Review Request >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. >> 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. Regards, Ashok ------- Original Message ------- Sender : Thiago Macieira<thiago.macieira at intel.com> Date : Jul 26, 2016 00:04 (GMT+05:30) Title : Re: [dev] CoAP - HTTP Proxy Review Request On segunda-feira, 25 de julho de 2016 09:26:21 PDT Abhishek Sharma wrote: > > I don't think we should do that. I propose to do it like I said and simply > > insert the foreign payload as a Byte Text property inside the CBOR > > payload. > > That looks more like a workaround where clients would have to extract say a > XML payload from a cbor payload. That is unnecessary overhead and > duplicates thing that are already taken care by communication protocol for > ex: "Accept", "Content-type" type headers. The point is that you don't know what the format is and shouldn't try to interpret. If translation is an optional feature, then you need to figure out a way to transmit the untranslated data. > > Supporting other content types/formats means you're doing a generic proxy, > > which you yourself excluded. > > I am not sure what you mean here by "a generic proxy". We are adding a > CoAP-HTTP proxy for IoTivity which is CoAP spec compliant. And also we are > adding extra content-type support based on requirements you specified. but > I am not ready to reinvent the wheel and add duplicate parameters in > payload. 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? > > Ok, so do it now. HTTPS is not optional. > > As I pointed out earlier, your concern that "you will have to review entire > codebase twice" is not valid as only a single file will change. A > subsequent patch will add support for https, but not in the first proxy > release. 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. > > Because you said you're not going to follow them. You said it's an OCF > > resource, accepting CBOR payloads and returning CBOR payloads. Then we > > should use OCF CRUDN to initiate the requests and obtain responses, with > > payloads formatted according to OCF rules. That means we don't need to > > use Proxy-URI headers because that's not part of the OCF protocol. > > I never said that we are not going to follow spec. As it currently stand, a > virtual resource for proxy is added to aid in discovery of proxy by > IoTivity clients (since spec does not mandate discovery procedure). Once > discovered, all communications are done as mandated in specifications. > Receiving only CBOR payload does not make it an OCF service. Ok, so you're describing scenario #1 above. Then you need to describe the security features of this proxy. Will it be accessible unencrypted, encrypted (DTLS) or both? How will it apply ACLs? How does one configure ACLs for it? How will the end-to-end payload encryption affect this, if at all? If it won't, please explain if the proxy can be accessed via an OCF intermediary and, if it is possible, how that will work . -- 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 ---------------------------------------------------------------------------------- Sr. Technical Manager, Software Architect. SRI-B, IoT Division/ IoTivity, Samsung Electronics Co., Ltd. +91-9880709710 ---------------------------------------------------------------------------------- <http://v70ext.samsung.net/mail/ext/v1/external/status/update?userid=ashok.channa&do=bWFpbElEPTIwMTYwNzI2MDQwOTI4ZXBjbXMycDU3YTQ4YzNlMTJmODE3YTJkYmI3YzcwZWUzMGJiZjFlZiZyZWNpcGllbnRBZGRyZXNzPWlvdGl2aXR5LWRldkBsaXN0cy5pb3Rpdml0eS5vcmc_> -------------- next part -------------- HTML ?????? ??????????????... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160726/7ca966e1/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 33527 bytes Desc: ?????? ?? ????????. URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160726/7ca966e1/attachment.png>
