Hi Uze: For a one-rt resource, everything would be OK.
But for a multi-rt resource, that will be confusing, as the example I take in previous mail. Or, may I conclude that. OCF allows multi-rt resource, but not define any rule about it. It still depends on the Server Application designer. I.e., for the example I take, the possible behaviors are all OK but upto Server App. And the Server vendor should provide the document (like the raml) to describe its multi-rt resource. Is it correct? BTW, I'm sorry but... where can I get OCF Core technology WG mailing list? Is it for OCF member only? Thank you. Best Regards, Annie _____ From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-bounces at lists.iotivity.org] On Behalf Of ???(Uze Choi) Sent: Thursday, September 01, 2016 12:16 PM To: iotivity-dev at lists.iotivity.org Subject: Re: [dev] Question about resource with multiple resource types When you make a request you don't need to specify the resource type. rt type specifying is valid only into oic/res/ with query param. >From IoTivity API perspective, we can specify the rt type as query param, but not possible to read it from response except payload. How to handle (reject or not) is upto Server Application logic (E.H). OCF spec. perspective. There is no rule resource server to handle the request differently according to rt type specifying as query param. as far as I know, Post request should follow the rule from each resource type, I think. You can check it thru OCF Core technology WG mailing list for correct answer. BR, Uze Choi From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-bounces at lists.iotivity.org] On Behalf Of Annie Weng Sent: Thursday, September 01, 2016 12:36 PM To: 'Dave Thaler'; iotivity-dev at lists.iotivity.org Subject: Re: [dev] Question about resource with multiple resource types Hi Dave: Thank you so much! May I ask the further behavior of 2rt's resource? If "rt" not assigned in the request, what should the server do? For example: One resource (uri: /MyResource) with 2rt [xxx.r.a xxx.r.b] Attributes of [xxx.r.a]: value=va, switch=sa Attributes of [xxx.r.b]: value=vb, mode=mb It seems that the 1st rt will be the default rt if "rt" is not assigned in the request, isn't it? Then how about the following cases? 1. GET /MyResource What will the response be?? 2. POST /MyResource payload{mode=XXX} Reject?? or apply to xxx.r.b automatically?? 3. POST /MyResource payload{value=XXX} Apply to xxx.r.a?? or apply to both?? Thank you Best Regards, Annie _____ From: Dave Thaler [mailto:dtha...@microsoft.com] Sent: Wednesday, August 31, 2016 1:44 AM To: Annie Weng; iotivity-dev at lists.iotivity.org Subject: RE: [dev] Question about resource with multiple resource types Yes. From my understanding, the main difference between one resource with 2 rt's and two resources with 1 rt each is that each resource has its own ACL. So 2 rt's on the same resource are always ACL'ed the same, whereas two resources with 1 rt each can have very different ACL's applied. From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-bounces at lists.iotivity.org] On Behalf Of Annie Weng Sent: Thursday, August 18, 2016 6:46 PM To: iotivity-dev at lists.iotivity.org Subject: [dev] Question about resource with multiple resource types Hi All: I'm confused about multiple resource types. According to the OIC draft spec 1.1.1, a resource could be "one or more" resource type. The definition of "OCResourceType" is also "link list". So, what will be the use case of multiple resource types? (I can only find one example: a device with types [oic.wk.d, oic.d.airConditioner]) Will there be such kind of usage? One resource with types [oic.r.light.brightness oic.r.switch.binary] at the same time? Or, one device with types [oic.wk.d oic.d.light oic.d.door] at the same time? If YES, what's the difference of usage between: (1) One resource: [oic.r.light.brightness oic.r.switch.binary] and (2) Two resources: [oic.r.light.brightness] and [oic.r.switch.binary] If NO, what is the rule/constraint of using multiple resource types? Thank you. Best Regards, Annie -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160901/214e8727/attachment.html>