OIC Core Resource Enforcement SchemeProblem StatementThe “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

ScopeThe 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 SchemesProposalsTwo proposals are offered in this document.

Proposal 1 Proposal 2

Proposal 1 & Proposal 2 OverlapBecause 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 1Proposal 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 2Proposal 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

DiscussisonProposal 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 pre-initialization 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 AProposal 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 1Proposal 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.1Proposal 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.2In Microsoft Word’s “Read Mode” click the image below to zoom.

© 2015 Intel Corporation. All rights Reserved.10

Appendix B – Part 2.3In Microsoft Word’s “Read Mode” click the image below to zoom.

© 2015 Intel Corporation. All rights Reserved.11

Appendix B – Part 2.4In Microsoft Word’s “Read Mode” click the image below to zoom.

© 2015 Intel Corporation. All rights Reserved.12