OIC Core Resource Enforcement Scheme
Problem Statement
The “OIC Core Specification Project A V0.9” specifies “OIC Core Resources.” Some of these are
mentioned as mandatory by OIC Implementations (please see list below). This means IoTivity must
implement an enforcement scheme to enforce applications to populate these “Core Resource’s” and
their respective mandatory properties.
OIC Mandatory Core Resources:



‘/oic/res’ (AKA “Default Resource”)
‘/oic/p’ (AKA “Platform Resource”)
‘/oic/d’ (AKA “Device Resource”)
Please take note about our current implementation and wrote expectations of the stack. All of the
properties listed for the Default Resource are already populated and maintained by the stack. Many of
the properties listed for the Device Resource are already populated and maintained by the stack. The
Platform Resource has no listed properties which are maintained by the stack. Only the mandatory
properties that are not populated and maintained by the stack will need to be enforced.
Please refer to page 2 to see list of the mandatory items that must be enforced by the scope of this
document.
© 2015 Intel Corporation. All rights
Reserved.
1
Scope
The following resources and their listed mandatory properties fall within scope of this document. The
following bulleted items are what need to be enforced by the IoTivity stack as well as the resource’s
themselves.
Default Resource – ‘/oic/res’
All properties of the “Default Resource” are populated and maintained by the stack. This resource will
not be enforced, as it is assumed the IoTivity stack is spec compliant with-respect-to this resource.
Device Resource – ‘/oic/d’
The following mandatory properties for the “Device Resource” are the only properties which will be
enforced by the scope of this document as all other properties are populated and maintained by the stack:

(Device) Name
Platform Resource – ‘/oic/p’
The following mandatory properties for the “Platform Resource” are the only properties which will be
enforced by the scope of this document as all other properties are optionally populated and maintained
by the application layer:


Platform ID
Manufacturer Name
© 2015 Intel Corporation. All rights
Reserved.
2
Proposals for Enforcement Schemes
Proposals
Two proposals are offered in this document.
 Proposal 1
 Proposal 2
Proposal 1 & Proposal 2 Overlap
Because there is overlap between the two proposals, the redundant pieces are shown here. Summaries
for Proposal 1 & Proposal 2 enforcement schemes are on the following pages.
In Microsoft Word’s “Read Mode” click the image below to zoom.
© 2015 Intel Corporation. All rights
Reserved.
3
Proposal 1
Proposal 1 defines a partial pre-initialization enforcement scheme. A new “CoreResources” struct is
declared for this implementation which encapsulates both the DeviceInfo struct and PlatformInfo Struct
defined in the “Proposal 1 & Proposal 2 Overlap” section above. Before initialization, the application
layer must populate all mandatory struct parameters. This struct is then passed in to the OCInit() API, as
shown below. If any of the parameters are not valid, initialization returns with
OC_STACK_CORE_RESOURCES_NOT_POPULATED. To see further implementation details, please see
appendix A.
In Microsoft Word’s “Read Mode” click the image below to zoom.
© 2015 Intel Corporation. All rights
Reserved.
4
Proposal 2
Proposal 2 defines a fully pre-initialization enforcement scheme. If the application layer attempts to
initialize the stack (ie. make a call to OCInit()) without first calling both OCSetDeviceInfo() &
OCSetPlatformInfo first, the stack will simply return with
OC_STACK_CORE_RESOURCES_NOT_POPULATED. To see further implementation details, please see
appendix B.
In Microsoft Word’s “Read Mode” click the image below to zoom.
© 2015 Intel Corporation. All rights
Reserved.
5
Discussison
Proposal 1 would require changing the OCInit() API. Some find this intrusive to already pre-existing
applications. However, all pre-existing applications will need to be revisited anyway. Once we become
spec compliant within scope of this document, the pre-existing applications will need to be revisited
because they will NEED to populate the Platform Resource’s properties and the Device Resource’s
properties before OCInit() will return successfully.
Proposal 2 would allow us to continue work without changing any public API’s (only adding public API’s;
ie. OCSetPlatformInfo() & OCSetDeviceInfo()). However, this has a downside that we’re introducing preinitialization mandatory API calls before the end user may call OCInit(). Many would think OCInit()
should “just work” without calling other APIs first.
For both proposal 1 & 2, all application layer consumers will need to be reworked to consume this new
Enforcement Scheme. Both proposals are intrusive, in that they will ‘break’ pre-existing apps until fixed.
Proposal 2 appears to be the best contender in this case as we won’t be developing on OCInit()’s public
facing signature. This will ensure we’re not encroaching on any other contributor’s current POR. (ie. IPV6
implementation, etc.)
© 2015 Intel Corporation. All rights
Reserved.
6
Appendix A
Proposal 1’s Implementation Details
In Microsoft Word’s “Read Mode” click the image below to zoom.
© 2015 Intel Corporation. All rights
Reserved.
7
Appendix B – Part 1
Proposal 2’s Implementation Details
In Microsoft Word’s “Read Mode” click the image below to zoom.
© 2015 Intel Corporation. All rights
Reserved.
8
Appendix B – Part 2.1
Proposal 2’s Implementation Details
In Microsoft Word’s “Read Mode” click the image below to zoom.
© 2015 Intel Corporation. All rights
Reserved.
9
Appendix B – Part 2.2
In Microsoft Word’s “Read Mode” click the image below to zoom.
© 2015 Intel Corporation. All rights
Reserved.
10
Appendix B – Part 2.3
In Microsoft Word’s “Read Mode” click the image below to zoom.
© 2015 Intel Corporation. All rights
Reserved.
11
Appendix B – Part 2.4
In Microsoft Word’s “Read Mode” click the image below to zoom.
© 2015 Intel Corporation. All rights
Reserved.
12