ISO/IEC 30118-6:2021

INTERNATIONAL ISO/IEC
STANDARD 30118-6
Second edition
2021-10
Information technology — Open
Connectivity Foundation (OCF)
Specification —
Part 6:
Resource to AllJoyn interface mapping
specification
Technologies de l'information — Specification de la Fondation pour la
connectivité ouverte (Fondation OCF) —
Partie 6: Spécification du mapping entre les ressources et l'interface
AllJoyn
Reference number
© ISO/IEC 2021
© ISO/IEC 2021
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
© ISO/IEC 2021 – All rights reserved

Contents Page
Foreword . vi
Introduction . vii
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 2
4 Document conventions and organization . 2
4.1 Conventions . 2
4.2 Notation . 3
5 Theory of operation . 3
5.1 Interworking approach . 3
5.2 Mapping syntax . 4
5.2.1 Introduction . 4
5.2.2 General . 4
5.2.3 Value assignment . 4
5.2.4 Property naming . 4
5.2.5 Arrays . 4
5.2.6 Default mapping . 4
5.2.7 Conditional mapping . 4
5.2.8 Loops . 5
5.2.9 Method invocation . 5
6 AllJoyn translation . 5
6.1 Operational scenarios . 5
6.2 Requirements specific to an AllJoyn bridging function . 5
6.2.1 Introduction . 5
6.2.2 Use of introspection . 5
6.2.3 Stability and loss of data . 6
6.2.4 Exposing AllJoyn producer devices to OCF clients . 6
6.2.5 Exposing OCF resources to AllJoyn consumer applications . 14
6.2.6 Security . 21
6.3 On-the-fly translation from d-bus and OCF payloads . 21
6.3.1 Introduction . 21
6.3.2 Translation without aid of introspection . 21
6.3.3 Translation with aid of introspection . 27
7 Device type mapping . 32
7.1 AllJoyn device types to OCF device types . 32
7.2 OCF device types with no AllJoyn equivalent . 32
8 Resource to interface equivalence . 33
8.1 Introduction . 33
8.2 Environment.CurrentAirQuality mapping. 34
8.3 Environment.CurrentAirQualityLevel mapping . 35
8.4 Operation.ClimateControlMode mapping . 35
8.5 Operation.FanSpeedLevel mapping . 35
8.6 Operation.HeatingZone mapping . 35
© ISO/IEC 2021 – All rights reserved iii

8.7 Operation.OnOffStatus, Operation.OnControl, and Operation.OffControl
mapping . 35
8.8 Operation.OvenCyclePhase . 35
9 Detailed mapping APIs . 35
9.1 Introduction . 35
9.2 Current air quality . 36
9.2.1 Derived model . 36
9.2.2 Property definition . 36
9.2.3 Derived model definition . 37
9.3 Current air quality level . 38
9.3.1 Derived model . 38
9.3.2 Property definition . 38
9.3.3 Derived model definition . 39
9.4 Current humidity . 40
9.4.1 Derived model . 40
9.4.2 Property definition . 40
9.4.3 Derived model definition . 41
9.5 Current temperature . 41
9.5.1 Derived model . 41
9.5.2 Property definition . 41
9.5.3 Derived model definition . 42
9.6 Target humidity . 43
9.6.1 Derived model . 43
9.6.2 Property definition . 43
9.6.3 Derived model definition . 44
9.7 Target temperature . 45
9.7.1 Derived model . 45
9.7.2 Property definition . 45
9.7.3 Derived model definition . 46
9.8 Audio volume . 47
9.8.1 Derived model . 47
9.8.2 Property definition . 47
9.8.3 Derived model definition . 48
9.9 Climate control mode . 49
9.9.1 Derived model . 49
9.9.2 Property definition . 49
9.9.3 Derived model definition . 49
9.10 Closed status . 50
9.10.1 Derived model . 50
9.10.2 Property definition . 50
9.10.3 Derived model definition . 51
9.11 Cycle control . 51
9.11.1 Derived model . 51
9.11.2 Property definition . 51
9.11.3 Derived model definition . 52
9.12 Fan speed level . 53
9.12.1 Derived model . 53
9.12.2 Property definition . 53
iv © ISO/IEC 2021 – All rights reserved

9.12.3 Derived model definition . 54
9.13 Heating zone . 55
9.13.1 Derived model . 55
9.13.2 Property definition . 55
9.13.3 Derived model definition . 55
9.14 HVAC fan mode . 56
9.14.1 Derived model . 56
9.14.2 Property definition . 56
9.14.3 Derived model definition . 57
9.15 On/Off control . 58
9.15.1 Derived model . 58
9.15.2 Property definition . 58
9.15.3 Derived model definition . 59
9.16 On off mapping . 59
9.16.1 Derived model . 59
9.16.2 Property definition . 59
9.16.3 Derived model definition . 60
9.17 Oven cycle phase . 60
9.17.1 Derived model . 60
9.17.2 Property definition . 60
9.17.3 Derived model definition . 61
10 Resource type definitions . 62
10.1 List of resource types . 62
10.2 AllJoynObject . 62
10.2.1 Introduction . 62
10.2.2 Example URI . 62
10.2.3 Resource type . 62
10.2.4 OpenAPI 2.0 definition . 62
10.2.5 Property definition . 66
10.2.6 CRUDN behaviour . 67
10.3 SecureMode . 67
10.3.1 Introduction . 67
10.3.2 Example URI . 67
10.3.3 Resource type . 67
10.3.4 OpenAPI 2.0 definition . 67
10.3.5 Property definition . 69
10.3.6 CRUDN behaviour . 69

© ISO/IEC 2021 – All rights reserved v

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees established
by the respective organization to deal with particular fields of technical activity. ISO and IEC technical
committees collaborate in fields of mutual interest. Other international organizations, governmental and non-
governmental, in liaison with ISO and IEC, also take part in the work.
The procedures used to develop this document and those intended for its further maintenance are described in
the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types of
document should be noted (see www.iso.org/directives or www.iec.ch/members_experts/refdocs).
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights. Details of any
patent rights identified during the development of the document will be in the Introduction and/or on the ISO list
of patent declarations received (see www.iso.org/patents) or the IEC list of patent declarations received
(see patents.iec.ch).
Any trade name used in this document is information given for the convenience of users and does not constitute
an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see  www.iso.org/iso/foreword.html. In
the IEC, see www.iec.ch/understanding-standards.
This document was prepared by the Open Connectivity Foundation (OCF) (as OCF Resource to AllJoyn
Interface Mapping Specification, version 2.2.0) and drafted in accordance with its editorial rules. It was adopted,
under the JTC 1 PAS procedure, by Joint Technical Committee ISO/IEC JTC 1, Information technology.
This second edition cancels and replaces the first edition (ISO/IEC 30118-6:2018), which has been technically
revised.
The main changes compared to the previous edition are as follows:
— AllJoyn text moved from the bridging specification to this document;
— addition of clarifications throughout.
A list of all parts in the ISO/IEC 30118 series can be found on the ISO and IEC websites.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html and www.iec.ch/national-
committees.
vi © ISO/IEC 2021 – All rights reserved

Introduction
This document, and all the other parts associated with this document, were developed in response to
worldwide demand for smart home focused Internet of Things (IoT) devices, such as appliances, door
locks, security cameras, sensors, and actuators; these to be modelled and securely controlled, locally
and remotely, over an IP network.
While some inter-device communication existed, no universal language had been developed for the
IoT. Device makers instead had to choose between disparate frameworks, limiting their market share,
or developing across multiple ecosystems, increasing their costs. The burden then falls on end users
to determine whether the products they want are compatible with the ecosystem they bought into, or
find ways to integrate their devices into their network, and try to solve interoperability issues on their
own.
In addition to the smart home, IoT deployments in commercial environments are hampered by a lack
of security. This issue can be avoided by having a secure IoT communication framework, which this
standard solves.
The goal of these documents is then to connect the next 25 billion devices for the IoT, providing secure
and reliable device discovery and connectivity across multiple OSs and platforms. There are multiple
proposals and forums driving different approaches, but no single solution addresses the majority of
key requirements. This document and the associated parts enable industry consolidation around a
common, secure, interoperable approach.
ISO/IEC 30118 consists of eighteen parts, under the general title Information technology — Open
Connectivity Foundation (OCF) Specification. The parts fall into logical groupings as described herein:
– Core framework
– Part 1: Core Specification
– Part 2: Security Specification
– Part 13: Onboarding Tool Specification
– Bridging framework and bridges
– Part 3: Bridging Specification
– Part 6: Resource to Alljoyn Interface Mapping Specification
– Part 8: OCF Resource to oneM2M Resource Mapping Specification
– Part 14: OCF Resource to BLE Mapping Specification
– Part 15: OCF Resource to EnOcean Mapping Specification
– Part 16: OCF Resource to UPlus Mapping Specification
– Part 17: OCF Resource to Zigbee Cluster Mapping Specification
– Part 18: OCF Resource to Z-Wave Mapping Specification
– Resource and Device models
– Part 4: Resource Type Specification
– Part 5: Device Specification
© ISO/IEC 2021 – All rights reserved vii

– Core framework extensions
– Part 7: Wi-Fi Easy Setup Specification
– Part 9: Core Optional Specification
– OCF Cloud
– Part 10: Cloud API for Cloud Services Specification
– Part 11: Device to Cloud Services Specification
– Part 12: Cloud Security Specification

viii © ISO/IEC 2021 – All rights reserved

INTERNATIONAL STANDARD ISO/IEC 30118-6:2021(E)

Information technology — Open Connectivity
Foundation (OCF) —
Part 6:
Resource to AllJoyn interface mapping specification
1 Scope
This document provides detailed mapping information to provide equivalency between AllJoyn defined
Interfaces and OCF defined Resources.
This document provides mapping for Device Types (AllJoyn to/from OCF), identifies equivalent OCF
Resources for both mandatory and optional AllJoyn interfaces and for each interface defines the
detailed Property by Property mapping using OCF defined extensions to JSON schema to
programmatically define the mappings.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 30118-1 Information technology -- Open Connectivity Foundation (OCF) Specification -- Part 1:
Core specification
https://www.iso.org/standard/53238.html
Latest version available at: https://openconnectivity.org/specs/OCF_Core_Specification.pdf
ISO/IEC 30118-2 Information technology -- Open Connectivity Foundation (OCF) Specification -- Part 2:
Security specification
https://www.iso.org/standard/74239.html
Latest version available at: https://openconnectivity.org/specs/OCF_Security_Specification.pdf
ISO/IEC 30118-4 Information technology -- Open Connectivity Foundation (OCF) Specification -- Part 4:
Resource type specification
https://www.iso.org/standard/74241.html
Latest version available at:
https://openconnectivity.org/specs/OCF_Resource_Type_Specification.pdf
ISO/IEC 30118-5 Information technology – Open Connectivity Foundation (OCF) Specification – Part 5:
Smart home device specification
https://www.iso.org/standard/74242.html
Latest version available at: https://openconnectivity.org/specs/OCF_Device_Specification.pdf
JSON Hyper-Schema, JSON Hyper-Schema: A Vocabulary for Hypermedia Annotation of JSON,
October 2016
http://json-schema.org/latest/json-schema-hypermedia.html
© ISO/IEC 2021 – All rights reserved 1

Derived Models for Interoperability between IoT Ecosystems, Stevens & Merriam, March 2016
https://www.iab.org/wp-content/IAB-uploads/2016/03/OCF-Derived-Models-for-Interoperability-
Between-IoT-Ecosystems_v2-examples.pdf
IETF RFC 4122, A Universally Unique Identifier (UUID) URN Namespace, July 2005
https://www.rfc-editor.org/info/rfc4122
IETF RF 4648, The Base16, Base32 and Base64 Data Encodings, October 2006
https://www.rfc-editor.org/info/rfc4648
IETF RFC 6973, Privacy Considerations for Internet Protocols, July 2013
https://www.rfc-editor.org/info/rfc6973
IETF RFC 7159, The JavaScript Object Notation (JSON) Data Interchange Format, March 2014
https://www.rfc-editor.org/info/rfc7159
AllJoyn Common Data Model Interface Definitions
https://wiki.alljoyn.org/cdm
AllJoyn About Interface Specification, About Feature Interface Definitions, Version 14.12
https://allseenalliance.org/framework/documentation/learn/core/about-announcement/interface
AllJoyn Configuration Interface Specification, Configuration Interface Definition, Version 14.12
https://allseenalliance.org/framework/documentation/learn/core/configuration/interface
D-Bus Specification, D-Bus Specification
https://dbus.freedesktop.org/doc/dbus-specification.html
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 30118-1 and the
following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
– ISO Online browsing platform: available at https://www.iso.org/obp
– IEC Electropedia: available at http://www.electropedia.org/
4 Document conventions and organization
4.1 Conventions
In this document a number of terms, conditions, mechanisms, sequences, parameters, events, states,
or similar terms are printed with the first letter of each word in uppercase and the rest lowercase (e.g.,
Network Architecture). Any lowercase uses of these words have the normal technical English meaning.
In this document, to be consistent with the IETF usages for RESTful operations, the RESTful operation
words CRUDN, CREATE, RETRIVE, UPDATE, DELETE, and NOTIFY will have all letters capitalized.
Any lowercase uses of these words have the normal technical English meaning.
2 © ISO/IEC 2021 – All rights reserved

4.2 Notation
In this document, features are described as required, recommended, allowed or DEPRECATED as
follows:
Required (or shall or mandatory).
These basic features shall be implemented to comply with the Mapping Specification. The phrases
"shall not", and "PROHIBITED" indicate behaviour that is prohibited, i.e. that if performed means
the implementation is not in compliance.
Recommended (or should).
These features add functionality supported by the Mapping Specification and should be
implemented. Recommended features take advantage of the capabilities the Mapping Specification,
usually without imposing major increase of complexity. Notice that for compliance testing, if a
recommended feature is implemented, it shall meet the specified requirements to be in compliance
with these guidelines. Some recommended features could become requirements in the future. The
phrase "should not" indicates behaviour that is permitted but not recommended.
Allowed (or allowed).
These features are neither required nor recommended by the Mapping Specification, but if the
feature is implemented, it shall meet the specified requirements to be in compliance with these
guidelines.
Conditionally allowed (CA)
The definition or behaviour depends on a condition. If the specified condition is met, then the
definition or behaviour is allowed, otherwise it is not allowed.
Conditionally required (CR)
The definition or behaviour depends on a condition. If the specified condition is met, then the
definition or behaviour is required. Otherwise the definition or behaviour is allowed as default
unless specifically defined as not allowed.
DEPRECATED
Although these features are still described in this document, they should not be implemented except
for backward compatibility. The occurrence of a deprecated feature during operation of an
implementation compliant with the current document has no effect on the implementation’s
operation and does not produce any error conditions. Backward compatibility may require that a
feature is implemented and functions as specified but it shall never be used by implementations
compliant with this document.
Strings that are to be taken literally are enclosed in "double quotes".
Words that are emphasized are printed in italic.
5 Theory of operation
5.1 Interworking approach
The interworking between AllJoyn defined interfaces and OCF defined Resource Types is modelled
using the derived model syntax described in Derived Models for Interoperability between IoT
Ecosystems. Determination of the minimum set of AllJoyn interfaces for which equivalency is required
within the OCF data model was done by listing the set of interfaces required for each of the device
© ISO/IEC 2021 – All rights reserved 3

types defined by the CDM Project inside of AllJoyn. Where the AllJoyn interface supports methods
then an actuation design pattern is applied.
5.2 Mapping syntax
5.2.1 Introduction
Within the defined syntax for derived modelling used by this document there are two blocks that define
the actual Property-Property equivalence or mapping. These blocks are identified by the keywords "x-
to-ocf" and "x-from-ocf". Derived Models for Interoperability between IoT Ecosystems does not define
a rigid syntax for these blocks; they are free form string arrays that contain pseudo-coded mapping logic.
Within this document we apply the rules defined in clause 5.2 to these blocks to ensure consistency
and re-usability and extensibility of the mapping logic that is defined.
5.2.2 General
All statements are terminated with a carriage return.
5.2.3 Value assignment
The equals sign (=) is used to assign one value to another. The assignee is on the left of the operator;
the value being assigned on the right.
5.2.4 Property naming
All Property names are identical to the name used by the original model; for example, from the OCF
Temperature Resource the Property name "temperature" is used whereas when referred to the derived
ecosystem then the semantically equivalent Property name is used.
When the same name is used by both OCF and the derived ecosystem for semantically equivalent
values then the name of the OCF defined Property is prepended by the ecosystem designator "ocf" to
avoid ambiguity (e.g. "ocf.step").
5.2.5 Arrays
An array element is indicated by the use of square brackets "[]" with the index of the element contained
therein, e.g. range[1]. All arrays start at an index of 0. If an entire array is being referenced then no
index is included, e.g. selectablehumiditylevels[].
5.2.6 Default mapping
There are cases where the specified mapping is not possible as one or more of the Properties being
mapped is optional in the source model. In all such instances a default mapping is provided. The
default map is indicated by the prepending of an "otherwise:" modifier to the assignment. (e.g.
"otherwise: step = 1").
5.2.7 Conditional mapping
When a mapping is dependent on the meeting of other conditions then the syntax:
if "condition", "mapping".
Is applied.
E.g. if step >0, ocf.step = step.
4 © ISO/IEC 2021 – All rights reserved

5.2.8 Loops
When a mapping can be represented by a repeated loop governed by some condition then the syntax:
for "initialize", "condition", "increment": "mapping"
Where:
"initialize" is an initial local loop control variable setting.
"condition" is the loop controller, the loop repeats until the condition evaluates to "false".
"increment" allows for update of the control variable, if omitted an increment of "1" is assumed.
Is applied.
E.g. for x=0, x < sizeof(supportedmodes): ocf.supportedmodes[x] = modearray[supportedmodes[x]]
5.2.9 Method invocation
The invocation of a method or remote procedure call (RPC) from the derived ecosystem as part of the
mapping from an OCF Resource is indicated by the use if a double colon "::" delimiter between the
applicable resource, service, interface or other construct identifier and the method or RPC name. The
method name always includes trailing parentheses which would include any parameters should they
be passed.
For example, when dealing with the switchon() method from AllJoyn this gives a complete method
invocation as: operation.oncontrol::switchon().
6 AllJoyn translation
6.1 Operational scenarios
The overall goals are to:
1) make Bridged Servers appear to OCF clients as if they were native OCF servers, and
2) make OCF servers appear to Bridged Clients as if they were native non-OCF servers.
6.2 Requirements specific to an AllJoyn bridging function
6.2.1 Introduction
The Bridge Platform shall be an AllJoyn Router Node. (This is a requirement so that users can expect
that a certified Bridge will be able to talk to any AllJoyn device, without the user having to buy some
other device.)
The requirements in clause 6.2 apply when using algorithmic translation, and by default apply to deep
translation unless the relevant clause for such deep translation specifies otherwise.
6.2.2 Use of introspection
Whenever possible, the translation code should make use of metadata available that indicates what
the sender and recipient of the message in question are expecting. For example, devices that are
AllJoyn Certified are required to carry the introspection data for each object and interface they expose.
When the metadata is available, Bridging Functions should convert the incoming payload to exactly
© ISO/IEC 2021 – All rights reserved 5

the format expected by the recipient and should use information when translating replies to form a
more useful message.
For example, for an AllJoyn specific Bridging Function, the expected interaction list is presented in
Table 1.
Table 1 – AllJoyn Bridging Function Interaction List
Message Type Sender Receiver Metadata
Request AllJoyn 16.10 OCF 1.0 Available
Request OCF 1.0 AllJoyn 16.10 Available
Response AllJoyn 16.10 OCF 1.0 Available
Response OCF 1.0 AllJoyn 16.10 Available
6.2.3 Stability and loss of data
Round-tripping through the translation process specified in this document is not expected to reproduce
the same original message. The process is, however, designed not to lose data or precision in
messages, though it should be noted that both OCF and AllJoyn payload formats allow for future
extensions not considered in this document.
However, a third round of translation should produce the same identical message as was previously
produced, provided the same information is available. That is, in the chain shown in Figure 1, payloads
2 and 4 as well as 3 and 5 should be identical.
Payload 1:
Payload 2 Payload 3 Payload 4 Payload 5
Original
Figure 1 – Payload Chain
6.2.4 Exposing AllJoyn producer devices to OCF clients
6.2.4.1 Virtual OCF devices and resources
As specified in ISO/IEC 30118-2 the value of the "di" property of OCF Devices (including VODs) shall
be established as part of Onboarding of that VOD.
Each AllJoyn object shall be mapped to one or more Virtual OCF Resources. If all AllJoyn interfaces
can be translated to resource types on the same resource, there should be a single Virtual OCF
Resource, and the path component of the URI of the Virtual OCF Resource shall be the AllJoyn object
path, where each "_h" in the AllJoyn object path is transformed to "-" (hyphen), each "_d" in the AllJoyn
object path is transformed to "." (dot), each "_t" in the AllJoyn object path is transformed to "~" (tilde),
and each "_u" in the AllJoyn object path is transformed to "_" (underscore). Otherwise, a Resource
with that path shall exist with a Resource Type of ["oic.wk.col", "oic.r.alljoynobject"] which is a
Collection of links, where "oic.r.alljoynobject" is defined in clause 10.2 and the items in the collection
are the Resources with the translated Resource Types.
6 © ISO/IEC 2021 – All rights reserved

The value of the "piid" property of "/oic/d" for each VOD shall be the value of the OCF-defined AllJoyn
field "org.openconnectivity.piid" in the AllJoyn About Announce signal, if that field exists, else it shall
be calculated by the Bridging Function as follows:
– If the AllJoyn device supports security, the value of the "piid" property value shall be the peer GUID.
– If the AllJoyn device does not support security but the device is being bridged anyway (see 10.2),
the "piid" property value shall be derived from the DeviceId and AppId properties (in the About
data), by concatenating the DeviceId value (not including any null termination) and the AppId bytes
and using the result as the "name" to be used in the algorithm specified in IETF RFC 4122 clause
4.3, with SHA-1 as the hash algorithm, and 8f0e4e90-79e5-11e6-bdf4-0800200c9a66 as the name
space ID. (This is to address the problem of being able to de-duplicate AllJoyn devices exposed
via separate OCF Bridge Devices.)
A Bridging Function implementation is encouraged to listen for AllJoyn About Announce signals
matching any AllJoyn interface name. It can maintain a cache of information it received from these
signals, and use the cache to quickly handle "/oic/res" queries from OCF Clients (without having to
wait for Announce signals while handling the queries).
A Bridging Function implementation is encouraged to listen for other signals (including
EmitsChangedSignal of properties) only when there is a client subscribed to a corresponding resource
on a Virtual AllJoyn Device.
There are multiple types of AllJoyn interfaces, which shall be handled as follows.
1) If the AllJoyn interface is in a well-defined set (defined in 6.2.4.2) of interfaces where standard
forms exist on both the AllJoyn and OCF sides, the Bridging Function shall either:
a) follow the requirements for translating that interface specially, or
b) not translate the AllJoyn interface.
2) If the AllJoyn interface is not in the well-defined set, the Bridging Function shall either:
a) not translate the AllJoyn interface, or
b) algorithmically map the AllJoyn interface as specified in 6.3 to custom/vendor-defined Resource
Types by converting the AllJoyn interface name to OCF resource type name(s).
An AllJoyn interface name shall be converted to a Device Type or a set of one or more OCF Resource
Types as follows:
3) If the AllJoyn interface has any members, append a suffix "." where is
described in this clause.
4) For each upper-case letter present in the entire string, replace it with a hyphen followed by the
lower-case version of that letter (e.g., convert "A" to "-a").
5) If an underscore appears followed by a (lower-case) letter or a hyphen, for each such occurrence,
replace the underscore with two hyphens (e.g., convert "_a" to "--a", "_-a" to "---a").
6) For each underscore remaining, replace it with a hyphen (e.g., convert "_1" to "-1").
7) Prepend the "x." prefix.
Some examples are shown in Table 2. The first three are normal AllJoyn names converted to unusual
OCF names. The last three are unusual AllJoyn names converted (perhaps back) to normal OCF names.
("xn--" is a normal domain name prefix for the Punycode-encoded form of an Internationalized Domain
Name, and hence can appear in a normal vendor-specific OCF name.)
© ISO/IEC 2021 – All rights reserved 7

Table 2 – AllJoyn to OCF Name Examples
From AllJoyn name To OCF name
example.Widget x.example.-widget
example.my__widget x.example.my----widget
example.My_Widget x.example.-my---widget
xn_p1ai.example x.xn--p1ai.example
xn__90ae.example x.xn--90ae.example
example.myName_1 x.example.my-name-1
Each AllJoyn interface that has members and is using algorithmic mapping shall be mapped to one or
more Resource Types as follows:
– AllJoyn Properties with the same EmitsChangedSignal value are mapped to the same Resource
Type where the value of the label is the value of EmitsChangedSignal. AllJoyn
Properties with EmitsChangedSignal values of "const" or "false", are mapped to Resources that
are not Observable, whereas AllJoyn Properties with EmitsChangedSignal values of "true" or
"invalidates" result in Resources that are Observable. The Version property in an AllJoyn interface
is always considered to have an EmitsChangedSignal value of "const", even if not specified in
introspection XML. The name of each property on the Resource Type shall be
".", where each "_d" in the is
transformed to "." (dot), and each "_h" in the is transformed to "-" (hyphen).
– Resource Types mapping AllJoyn Properties with access "readwrite" shall support the "oic.if.rw"
OCF Interface. Resource Types mapping AllJoyn Properties with access "read" shall support the
"oic.if.r" OCF Interface. Resource Types supporting both the "oic.if.rw" and "oic.if.r" OCF Interfaces
shall choose "oic.if.r" as the default Interface.
– Each AllJoyn Method is mapped to a separate Resource Type, where the value of the
label is the AllJoyn Method name. The Resource Type shall support the "oic.if.rw" OCF Interface.
Each argument of the AllJoyn Method shall be mapped to a separate Property on the Resource
Type, where the name of that Property is prefixed with "arg<#>", where <#> is the
0-indexed position of the argument in the AllJoyn introspection xml, in order to help get uniqueness
across all Resource Types on the same Resource. Therefore, when the AllJoyn argument name is
not specified, the name of that property is "arg<#>", where <#> is the 0-indexed
position of the argument in the AllJoyn introspection XML. In addition, that Resource Type has an
extra "validity" property that indicates whether the rest of the properties have valid
values. When the values are sent as part of an UPDATE response, the validity property is true, and
any other properties have valid values. In a RETRIEVE (GET or equivalent in the relevant transport
binding) response, the validity property i
...