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
----------------------------------------------------------------------------------
-------------- next part --------------
HTML ?????? ??????????????...
URL:
<http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160727/276d15d8/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/276d15d8/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/276d15d8/attachment.png>
