In this case, what is value in content format option field? Still cbor?
BR, Uze Choi From: ?? [mailto:[email protected]] Sent: Wednesday, July 27, 2016 4:27 PM To: ???; Abhishek Sharma Cc: thiago.macieira at intel.com; iotivity-dev at lists.iotivity.org Subject: RE: RE: RE: RE: [dev] CoAP - HTTP Proxy Review Request on wire, payload can be void for GET request. and for POST, it can have different payload types. Modifications mentioned were for request and response C-APIs to have void* instead of CBOR payload to handle any kind of data ( JSON,SoAP ..etc). Regards, Ashok --------- Original Message --------- Sender : Uze Choi <uzchoi at samsung.com> S6/Principal Engineer/IoT Lab./Samsung Electronics Date : 2016-07-27 12:09 (GMT+5:30) Title : RE: RE: RE: [dev] CoAP - HTTP Proxy Review Request In this case, payload exist as like { house = ?Ashok?; status = ?dining room burn out?}, then what is the void case? Otherwise, should we create the payload with html format from the thin client? BR, Uze Choi From: ?? [mailto:[email protected]] Sent: Wednesday, July 27, 2016 3:36 PM To: ???; Abhishek Sharma Cc: thiago.macieira at intel.com; iotivity-dev at lists.iotivity.org Subject: RE: RE: RE: [dev] CoAP - HTTP Proxy Review Request Not for file uploading but in case of ThinClient wants to post data to any webserver. Use-Case: FireAlaram wants to post notification to FireStation webserver after smoke detection. Sequence @ <https://wiki.iotivity.org/coap-http_proxy> https://wiki.iotivity.org/coap-http_proxy Regards, Ashok --------- Original Message --------- Sender : Uze Choi <uzchoi at samsung.com> S6/Principal Engineer/IoT Lab./Samsung Electronics Date : 2016-07-27 11:45 (GMT+5:30) Title : RE: RE: [dev] CoAP - HTTP Proxy Review Request Request other than CBOR ? this is also file uploading case? BR, Uze Choi From: ?? [mailto:[email protected]] Sent: Wednesday, July 27, 2016 1:54 PM To: ???; Abhishek Sharma Cc: thiago.macieira at intel.com; iotivity-dev at lists.iotivity.org Subject: RE: RE: [dev] CoAP - HTTP Proxy Review Request Hi Uze, Payload is not required and RI already accept the null value as payload. ? This is not problem. -- If client wants to send request other than CBOR( for POST), Request also has to be treated as void*. Payload can be image file but it need to be treated as "void * ? this is your requirement?? -- Yes , during response from Proxy to Client. Regards, Ashok --------- Original Message --------- Sender : Uze Choi <uzchoi at samsung.com> S6/Principal Engineer/IoT Lab./Samsung Electronics Date : 2016-07-26 19:32 (GMT+5:30) Title : RE: [dev] CoAP - HTTP Proxy Review Request Hi Abhishek, Let me clearly understand your point. In case of ?Example of Request (on Thin client): URI options, Proxy-Uri option, Payload? Payload is not required and RI already accept the null value as payload. ? This is not problem. In case of ?Example of response (on Thin client): URI options, Proxy-Uri option, Payload? Payload can be image file but it need to be treated as "void * ? this is your requirement?? BR, Uze Choi From: Abhishek Sharma [mailto:[email protected]] Sent: Tuesday, July 26, 2016 10:53 PM To: ??? Cc: ??; thiago.macieira at intel.com; iotivity-dev at lists.iotivity.org Subject: RE: [dev] CoAP - HTTP Proxy Review Request One additional change will be required to support multiple content format. Currently RI api's to send request and response OCDoResource() and OCDoResponse() take "OCPayload" as input. and throughout RI, the payload is expected to be in CBOR format. But with proxy, this could be anything, image, XML, binary etc. So RI will have to be modified to treat payload for proxy cases as "void *" and do not try logging or parsing it. --------- Original Message --------- Sender : Uze Choi <uzchoi at samsung.com> S6/Principal Engineer/IoT Lab./Samsung Electronics Date : 2016-07-26 18:51 (GMT+5:30) Title : RE: RE: [dev] CoAP - HTTP Proxy Review Request I think this IoTivity API change can support your scenario. IoTivity Client - proxy-uri setting for request message - null (or empty string) setting allow for the URI-options. IoTivity Server - Entity Handler support for null (or empty string) uri Any issue for this solution? or any spec compliance issue? BR, Uze Choi From: ?? [mailto:[email protected]] Sent: Tuesday, July 26, 2016 9:49 PM To: ???; thiago.macieira at intel.com; Abhishek Sharma Cc: iotivity-dev at lists.iotivity.org Subject: Re: RE: [dev] CoAP - HTTP Proxy Review Request Hi Uze, Here is the Protocol details for the use-case you have mentioned. Payload will be based on the Content-Format mentioned in the message. we will update in wiki page soon. Regards, Ashok ------- Original Message ------- Sender : Uze Choi<uzchoi at samsung.com> S6/Principal Engineer/IoT Lab./Samsung Electronics Date : Jul 26, 2016 15:58 (GMT+05:30) Title : RE: [dev] CoAP - HTTP Proxy Review Request 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 ---------------------------------------------------------------------------------- ---------------------------------------------------------------------------------- Sr. Technical Manager, Software Architect. SRI-B, IoT Division/ IoTivity, Samsung Electronics Co., Ltd. +91-9880709710 ---------------------------------------------------------------------------------- ---------------------------------------------------------------------------------- Sr. Technical Manager, Software Architect. SRI-B, IoT Division/ IoTivity, Samsung Electronics Co., Ltd. +91-9880709710 ---------------------------------------------------------------------------------- -------------- next part -------------- HTML ?????? ??????????????... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160727/5fd1c77a/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 51858 bytes Desc: ?????? ?? ????????. URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160727/5fd1c77a/attachment.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 33527 bytes Desc: ?????? ?? ????????. URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160727/5fd1c77a/attachment.png>
