ISO / IEC JTC1/ SC25 WG1
N985
WG1 (Boston, Farance)1
Date: January 2, 2002
ISO/IEC JTC1 SC25 WG1
Interconnection of Information Technology Equipment
Home Electronic Systems
Title:
DCTP Enhancement for Interoperability ISO/IEC CD-18012-x
Source:
USA
Project:
25.01.04.02-01
Requested Action:
Consideration by WG1 at meeting to be held
January 21-25, 2002
Distribution:
P-, L-, O- Members of SC25 WG1
Note:
Document Editor: Frank Farance
Farance, Inc.
+1 212-486-4700, frank@farance.com
Title: Relevance and Application between DCTP (15067-1) and Interoperability (18012-x)
Date: 2001-12-22
From: Frank Farance
Note: This paper is in response to an action item of the 2001-06 SC25/WG1 meeting in London.
OVERVIEW
Several SC25/WG1 standards and technical reports comprise a suite of documents that specify and promote interoperability and
compatibility among components in home electronic systems. Some documents address architectural topics, some documents
address user interface and safety issues; the reference documents (15067-1 and 18012-x) address interoperability topics.
BACKGROUND INFORMATION ON 15067-1
The 15067-1, Data and Control Transfer Protocol (DCTP), concerns interoperability at, roughly, layer 5 (session layer) of an ISO
OSI protocol stack. Although devices throughout the house may use a variety of low-level command and control (C2) interfaces
and messages, the DCTP services are a common framework that may span and interoperate with proprietary systems.
The DCTP services may be summarized by: what the do, what they don't do, and their application. The following is a nonexhaustive list.
What DCTP Does
 Provides a common method for getting/putting "values" (numeric and non-numeric), e.g., the "GVAL" and "PVAL" services.
 Provides a common method for passing parameters to control operations. Note that the distinction between data and control is
just as blurred (and just as useful) as in programming languages. In other words, the use of the capabilities "object = X"
("putvalue" service on the operand "object") vs. "object.putvalue(X)" (calling the "putvalue" method of "object") is a matter of
convention (e.g., specifications) and style. These conventions (e.g., what types of values can be "put"; what methods are
available) are defined external to DCTP, i.e., they are out-of-scope for the DCTP standard.
 Provides a common framework for adding security services ("plug-ins").
 Provides various conection frameworks (connection vs. connectionless, point-to-point vs. broadcast, connected vs. roaming vs.
sometimes-connected, bus vs. ring connectivity), dependent upon the underlying communications capability.
 Provides a very very simple implementation paradigm, e.g., for low-memory embedded systems.
What DCTP Does Not Do
 Determines the lexicon. DCTP does *not* define the names of parameters or their acceptable values. For example, within the
DCTP message "PVAL LAMP ON", the DCTP standard only specifies generically that the message have the structure "PVAL
object value". The tokens "LAMP" and "ON" are part of the lexicon that is specified elsewhere -- some of it specified in
lexicon registries, and some of it as run-time information within the devices.
 Define naming of objects. DCTP does not make requirements on the names of objects (e.g., "lamp", "device001", etc.). The
naming of objects may be a feature of some other specification or a run-time feature.
 Require particular security services. DCTP does not require any particular security services, but provides a framework for
adding features (the Pluggable Authentication Modules (PAM) approach).
 Specify the transport facilities. DCTP can be run over a simple RS-232 interface and can also be used with TCP/IP, UDP/IP,
or TLS/IP beneath it.
 Specify the connection facilities. DCTP does not mandate the use of any particular configuration of connection facilities (e.g.,
connection-oriented, point-to-point, connected, bus).
 Demand proprietary systems change to DCTP. There is no need for proprietary systems to change, there is only a need for a
standards-conforming interface (like all good standards).
Applications of DCTP
 Primarily DCTP is useful for C2 (command and control) applications.
 DCTP may be used as a lower layer protocol for the ISO/IEC 20944-x Metadata Access Services (MDAS), an Application
Programming Interface (API) standard.
 A bridging protocol/services among proprietary protocols/services.
RELATIONSHIP BETWEEN DCTP AND 18012 INTEROPERABILITY
Page 1
F. Farance
The 18012 series of documents address interoperability. This multipart document is organized as follows:



Part 1: Introduction
Part 2: Taxonomy and Lexicon
Part 3: Application models
At both the 2001-01 and 2001-06 SC25/WG1 meetings, it was suggested that a Part 4 be added:

Part 4: Registration Authority
The use of a registration authority would simplify the adoption and maintenance of the 18012 series of documents. Let's assume
that Part 2 will include a lexicon (and/or taxonomy) of objects and their parameters/values.
Also mentioned in those meetings was the possible using of DCTP (protocol/services) and MDAS (API) as bindings to these
interoperability features. For example, a DCTP binding of 18012 might be of the format:
PVAL lexicon_object lexicon_value
so assauming that "LAMP" were a registered object in the 18012-2 lexicon and "OFF" and "ON" were registered values (for
causing the actions "off" and "on") for that object in the 18012-2 lexicon, then the following would be valid messages:
PVAL LAMP OFF
PVAL LAMP ON
Similarly, an MDAS API binding that used the same 18012-2 lexicon might permit the following function/ method/ subroutine
calls:
mdas_putvalue("LAMP", "OFF");
mdas_putvalue("LAMP", "ON");
Note: The examples above have been simplified for the purposes of illustration.
CONCLUSIONS
The DCTP (15067-1) services provide a set of interoperability features that closely mesh with the 18012 interoperability
documents. The DCTP provides the protocol binding features, while the 18012 documents provide the lexicon and meanings of its
objects and tokens. The 15067-1 and 18012-x documents are intended to work together.
RECOMMENDATIONS
Add a registration authority process (e.g., 18012-4) for registering objects and paramters/values in the lexicon.
Add a "DCTP Binding Standard" (e.g., 18012-5), which describes the mapping of the leixon to the underlying protocols/services.
In other words, 18012-5 would be a very tiny standard that says, roughly:



DCTP uses the format "command object parameters"
The DCTP "object" is equivalent to the lexicon "object"
The DCTP "parameters" are the lexicon object's "parameters"
Add an "MDAS API Binding Standard" (e.g., 18012-6), which describes the mapping of the leixon to the underlying API services.
In other words, 18012-6 would be a very tiny standard that says, roughly:



MDAS uses the function/method call "service(object,parameters)"
The MDAS "object" is equivalent to the lexicon "object"
The MDAS "parameters" are the lexicon object's "parameters"
Page 2
F. Farance