ISO/IEC 15067-1, Data and Control Transfer Protocol (DCTP) by w6JLcR7

VIEWS: 8 PAGES: 27

									2003-01-20, SC25/WG1/Nxxx                                              DCTP (WD3 15067-1)




                                                ISO/IEC JTC1/SC25/WG1            N1047
                                                                          Date: 2003-02-13



                              ISO/IEC JTC 1/SC 25/WG 1
                Interconnection of Information Technology Equipment
                               Home Electronic System



Title:                 Data and Control Transfer Protocol (DCTP)




Source:               US




Project:              Project: 25.01.04.02-01




Status:                This is Working Draft 3. As per the 2002-09 WG1 meeting
 resolutions, this document will be sent for CD ballot on after WG review. Please return
 comments to the project editor ("frank@farance.com") by 2003-02-12 23:00 UTC.




Requested Action:     FYI




Distribution:          ISO/IEC JTC1/SC25/WG1




                                                                                           1
2003-01-20, SC25/WG1/Nxxx                                         DCTP (WD3 15067-1)



Introduction
** TO BE SUPPLIED FOR FCD Ballot ** (Describe Development/History of Standard)




                                                                                   2
2003-01-20, SC25/WG1/Nxxx                                                                                                 DCTP (WD3 15067-1)

                                                                CONTENTS
1      Overview............................................................................................................................................. 6
    1.1 Scope ............................................................................................................................................... 6
    1.2 Purpose ............................................................................................................................................ 6
2      Normative references........................................................................................................................ 6
3      Definitions .......................................................................................................................................... 6
    3.1 binding............................................................................................................................................. 7
    3.2 encoding .......................................................................................................................................... 7
    3.3 implementation-defined behavior .................................................................................................. 7
    3.4 smallest permitted maximum ......................................................................................................... 7
    3.5 unspecified behavior ....................................................................................................................... 7
    3.6 Acronyms and abbreviations .......................................................................................................... 7
4      Conformance ..................................................................................................................................... 7
5      Functionality ...................................................................................................................................... 7
6      Conceptual Model ............................................................................................................................. 7
    6.1 Participant model ............................................................................................................................ 8
    6.2 Data model ...................................................................................................................................... 8
       6.2.1 Objects .................................................................................................................................... 8
          6.2.1.1 Atomic objects ................................................................................................................... 8
          6.2.1.2 Lists .................................................................................................................................... 8
          6.2.1.3 Hierarchical organization .................................................................................................. 8
          6.2.1.4 Types .................................................................................................................................. 9
       6.2.2 Properties ................................................................................................................................ 9
          6.2.2.1 Property lists....................................................................................................................... 9
          6.2.2.2 System and user properties ................................................................................................ 9
          6.2.2.3 Static and dynamic properties ........................................................................................... 9
          6.2.2.4 Enumerable and non-enumerable lists.............................................................................. 9
          6.2.2.5 Stored and calculated properties ....................................................................................... 9
          6.2.2.6 Memory and volatile properties ........................................................................................ 9
       6.2.3 Naming and navigation ........................................................................................................ 10
          6.2.3.1 Named and numbered indexes ........................................................................................ 10
          6.2.3.2 Hierarchical naming ........................................................................................................ 10
          6.2.3.3 Merged namespaces......................................................................................................... 10
          6.2.3.4 Naming conventions ........................................................................................................ 10
          6.2.3.5 Hard links ......................................................................................................................... 10
          6.2.3.6 Soft links .......................................................................................................................... 11
          6.2.3.7 Reference.......................................................................................................................... 11
          6.2.3.8 Naming Views ................................................................................................................. 11
       6.2.4 Views .................................................................................................................................... 11
          6.2.4.1 Functional subsets............................................................................................................ 11
       6.2.5 Files and Streams ................................................................................................................. 11
    6.3 Control Model ............................................................................................................................... 11
       6.3.1 Event ..................................................................................................................................... 12
       6.3.2 Wait....................................................................................................................................... 12
       6.3.3 Call ........................................................................................................................................ 12
       6.3.4 Parameters ............................................................................................................................ 12
    6.4 Connections................................................................................................................................... 12
    6.5 State model.................................................................................................................................... 12
                                                                                                                                                             3
2003-01-20, SC25/WG1/Nxxx                                                                                              DCTP (WD3 15067-1)

     6.5.1 Server state model ................................................................................................................ 12
     Client state model.............................................................................................................................. 14
7    Data Definition ................................................................................................................................ 15
  7.1 Data types ...................................................................................................................................... 15
  7.2 Data Model Semantics.................................................................................................................. 15
     7.2.1 Inherent structure.................................................................................................................. 15
     7.2.2 Hierarchical naming ............................................................................................................. 16
     7.2.3 Associated properties ........................................................................................................... 17
     7.2.4 Merged namespace for properties ....................................................................................... 18
     7.2.5 The _value property ............................................................................................................. 18
     7.2.6 External, logical, and internal naming conventions ........................................................... 18
     7.2.7 Keywords.............................................................................................................................. 19
8    General information on commands and messages..................................................................... 19
  8.1 Session identification .................................................................................................................... 19
     8.1.1 Session ID............................................................................................................................. 19
     8.1.2 Session 0 ............................................................................................................................... 19
  8.2 Command request and response .................................................................................................. 20
     8.2.1 Readiness for command acceptance ................................................................................... 20
     8.2.2 Return status ......................................................................................................................... 20
     8.2.3 Returning data ...................................................................................................................... 20
     8.2.4 Returning out-of-band data.................................................................................................. 20
9    Data transfer-related commands and messages ......................................................................... 21
     9.1.1 Get Value (GVAL) message ............................................................................................... 21
     9.1.2 Put Value (PVAL) message ................................................................................................ 22
     9.1.3 Make Object (MKOB) message.......................................................................................... 22
     9.1.4 Remove Object (RMOB) message ..................................................................................... 22
     9.1.5 Link Object (LNOB) message............................................................................................. 23
     9.1.6 List Object (LSOB) message............................................................................................... 23
10 Control transfer-related commands and messages.................................................................... 23
  10.1 Session establishment commands and messages .................................................................... 23
     10.1.1 Connect (CONN) message .................................................................................................. 23
     10.1.2 Open (OPEN) message ........................................................................................................ 23
     10.1.3 Close (CLOS) message........................................................................................................ 24
     10.1.4 Disconnect (DISC) message................................................................................................ 24
  10.2 Session parameter commands and messages .......................................................................... 24
     10.2.1 Put Session Parameter (PSES) message ............................................................................. 24
     10.2.2 Get Session Parameter (GSES) message ............................................................................ 25
     10.2.3 Put Path (PPTH) message.................................................................................................... 25
     10.2.4 Get Path (GPTH) message................................................................................................... 25
  10.3 Security commands and messages .......................................................................................... 25
     10.3.1 Request Authorization/Authentication (RQAU) message ................................................. 25
     10.3.2 Response Authorization/Authentication (RSAU) message ............................................... 25
     10.3.3 Nomad (NOMD) message................................................................................................... 26
  10.4 Control commands and messages............................................................................................ 26
     10.4.1 Event (EVNT) message ....................................................................................................... 26
     10.4.2 Wait (WAIT) message ......................................................................................................... 26
     10.4.3 CALL message..................................................................................................................... 26
11 Annex A: Document development (informative) ....................................................................... 27
                                                                                                                                                        4
2003-01-20, SC25/WG1/Nxxx                                                                                          DCTP (WD3 15067-1)

  11.1   Revision history ........................................................................................................................ 27
  11.2   Release notes for this document .............................................................................................. 27
  11.3   Resolved issues......................................................................................................................... 27
  11.4   Open issues ............................................................................................................................... 27
  11.5   Comments on this document ................................................................................................... 27




                                                                                                                                                     5
2003-01-20, SC25/WG1/Nxxx                                                       DCTP (WD3 15067-1)



1 Overview
Abstract
This protocol specification describes the connection, adaptation, synchronization, initiation, response,
messaging, and disconnection among participants communicating via the Data and Control Transfer
Protocol (DCTP). DCTP is a simplified and efficient messaging protocol for exchanging structured
data, including property or attribute information. Participants may send and receive event messages
with the data transfer.


1.1 Scope
This standard provides a common lightweight protocol for exchanging data among clients, servers,
and peers. The standard addresses data exchange at a finer granularity than other common protocols
(e.g., HTTP) and is intended to perform better in a wide range of network infrastructures, qualities of
service, distributed systems, nomadic systems, and security systems. The standard defines a protocol
and semantics that may be easily implemented in networking applications and may be easily bound to
APIs.


1.2 Purpose
Many number of protocols exist for exchanging data, such as FTP, HTTP, CORBA. However, these
protocols don't perform well (e.g., HTTP is not good for fine grain data), they don't have enough se-
mantics (e.g., FTP cannot get/put address attributes, properties, or metadata), or they are difficult to
interface to (e.g., CORBA cannot be conveniently accessed in Perl or Tcl). A lightweight protocol that
was easily implementable and addressed the needs of small systems would have wide acceptance and
integration within many applications.


2 Normative references
The following referenced documents are indispensable for the application 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 10646-1:1999, Universal Multiple-Octet Coded Character Set (UCS).
ISO/IEC 11404:1996, Language Independent Datatypes


3 Definitions
For the purposes of this International Standard, the following definitions apply. Terms explicitly de-
fined in this International Standard are not to be presumed to refer implicitly to similar terms defined


                                                                                                      6
2003-01-20, SC25/WG1/Nxxx                                                      DCTP (WD3 15067-1)

elsewhere. Terms not defined in this International Standard are to be interpreted according to ISO/IEC
2382-1.

3.1 binding
An application or mapping from one framework or specification to another.

3.2 encoding
The bit and byte format and representation of information.

3.3 implementation-defined behavior
Unspecified behavior where each implementation documents how the choice is made.

3.4 smallest permitted maximum
The smallest maximum value.
Example: The smallest permitted maximum length of field X shall be 25.

3.5 unspecified behavior
Implementation behavior for which a standard provides two or more possibilities and imposes no fur-
ther requirements on which possibility is chosen in any instance.

3.6 Acronyms and abbreviations
   LID: Language Independent Datatypes
   UCS: Universal Character Set, as defined by ISO/IEC 10646-1


4 Conformance
A conforming implementation shall support all mandatory messages. A conforming implementation
shall return error codes for messages or parameters it does not support.


5 Functionality
The DCTP protocol is a data interchange protocol. The protocol may be used in a variety of protocol
stack configurations, e.g., DCTP as a session layer protocol over TCP/IP transport and network ser-
vices; or DCTP as a direct communication via asynchronous, serial, 8-bit communications.


6 Conceptual Model
The DCTP conceptual model is divided into two parts: the data model and the control model. The
data model describes the "logical" structure of information as it is transferred. The control model de-
scribes the structure of the transactions, events, and protocol state.


                                                                                                     7
2003-01-20, SC25/WG1/Nxxx                                                        DCTP (WD3 15067-1)

6.1 Participant model
The senders and receivers of DCTP messages are called "participants". DCTP permits client-server,
peer-to-peer, publish-subscribe, multicast, and broadcast modes of participation. The underlying
communication system determines which modes of participation are supported.


6.2 Data model
The DCTP data model refers to the construction or deconstruction of data on the sending and receiv-
ing ends. When data is retrieved or stored, a data model is implied for the purposes of transmission,
i.e., the data model does not define the implementation of the sender or receiver. The following con-
cepts characterize the data model.

6.2.1 Objects
A unit or collection of data is called an "object" (not to be confused with "objects" of "object-oriented"
analysis, design, and programming). Objects may be structured data, characterized by known (agreed
upon) naming and datatyping. Objects may be semi-structured data, characterized by partial
knowledge or specification of naming and datatyping. Objects be unstructured data, characterized by
lack of knowledge and specification of naming and datatyping.

6.2.1.1 Atomic objects

An object may be an "atomic object" if the object has values which are intrinsically indivisible, e.g., a
basic type such as integer, real, character. Examples: 17, -1.7E8, 0D19980831235959, "hello
world". Non-atomic objects are called


6.2.1.2 Lists

A list is a collection of objects. Each member of the list is called an "element". The elements may be
ordered or unordered, named or unnamed, typed or untyped. A list may be nested, i.e., an element of
a list may be a list itself. Example: The list { A: 17 B: { 18 19 20 } C: 0D19980831232359
} contains three named elements A, B, and C. The first element (A) is an atomic object of type integer.
The second element (B) is a list of three unnamed elements. The third element (C) is an atomic object
of type date-time. The difference between a list and a C structure is: a C structure is ordered, named,
and typed.

6.2.1.3 Hierarchical organization

The nesting implies a hierarchical organization only from the perspective of data access, not from data
implementation. For example, a multi-dimensional array may use the same access method as a nested
list. As an analogy, when comparing the C two-dimensional array char x[10][20] to the nested list
char *y[10], both types are accessed by the same hierarchical method: x[a][b] and y[a][b], yet
the internal structure is different.



                                                                                                        8
2003-01-20, SC25/WG1/Nxxx                                                         DCTP (WD3 15067-1)

6.2.1.4 Types

Objects may be typed. A conforming system shall support the ISO/IEC Language Independent
Datatype (LID) Standard for the naming and specification of datatypes. LID includes basic types
(e.g., boolean, integer, real, date-time, string), type parameters (e.g., precision), and type operators
(e.g., lists, records, sets).

6.2.2 Properties
Properties can be associated with objects. Properties are attributes of the object.

6.2.2.1 Property lists

Each object may have an associated property list. A property list is an ordered, named list of objects.
Example: The object { 1 2 3 } might have the property list { color: red price: 123 }.

6.2.2.2 System and user properties

Some properties are created by the system, e.g., _type, _shape, _last_modified. Some properties
are created by the user (or application), e.g., color, price. Namespace conventions (e.g., a leading
underscore for system properties) help avoid collisions between user and system properties.

6.2.2.3 Static and dynamic properties

Static properties exist for the duration of the object (unless explicitly removed) and may be listed, e.g.,
_type, color. Dynamic properties may not be enumerable and may not exist for the duration of the
object.

6.2.2.4 Enumerable and non-enumerable lists

A list, including property lists, may be enumerable or non-enumerable. For lists that are enumerable,
all list elements shall be listed via the LIST message. For lists that are non-enumerable, some or all
list elements may not be listed via the LIST message.

6.2.2.5 Stored and calculated properties

Some properties have explicit storage associated with the object, e.g., color and (possibly) _type.
Some properties may be implicit or calculated and have no storage, e.g., _type and _shape.

6.2.2.6 Memory and volatile properties

Some properties behave the like "memory", i.e., "reading" the property more than once always returns
the same value, and "writing" the same value more than once has the same affect as writing it once.
Example: The properties color and price are "memory" properties because they remain the same.
The property _last_modified is volatile because the value may change; the property us-
age_payment is volatile because setting its value more than once (e.g., paying a usable fee of 0.50
USD more than once) would have a different effect than setting the value only once.

                                                                                                         9
2003-01-20, SC25/WG1/Nxxx                                                           DCTP (WD3 15067-1)

6.2.3 Naming and navigation
Non-atomic objects imply more than one element. Naming methods facilitate navigation of structured
data in objects.

6.2.3.1 Named and numbered indexes

Elements in ordered lists may be accessed by number, e.g., the element numbered 2 of the list { 15
16 17 } is 17. Named elements in lists may be accessed by name, e.g., the element number C of the
list { A: 15 16 C: 17 } is 17. Named elements of ordered lists may be access by name or name,
e.g., the third element of { A: 15 16 C: 17 } may be accessed by the name C or the number 2.

6.2.3.2 Hierarchical naming

Names are hierarchical because the objects they navigate have hierarchical naming. Example: the
names C/Z, C/2, 2/Z, and 2/2 all name the element 17 in the object { A: 10 B: 11 C: { X: 15
Y: 16 Z: 17 } }.


6.2.3.3 Merged namespaces

The object, property, link, control, etc., namespaces are merged with the object namespace to simplify
the number of methods of access, e.g., no need for separate "getvalue" and "getlink" messages.

Examples: The property Y of the object X is accessed via the name X/.Y. For the soft link of L that
points to D: (1) getting the value L "chases" the link and returns the value of D, (2) getting the value L/
refers to the link itself, i.e., the reference to D, not the value of D, (3) getting the value L/. chases the
link and retrieves D.

6.2.3.4 Naming conventions

Several naming convention are used to increase interoperability and reduce integration cost. The user
(application) uses external names. The system (implementation) uses internal names. External names
are mapped to/from logical names. A logical name is a sequence of pathname separators and path-
name segments. Each pathname segment consists of words separated by word separators. Logical
names are mapped to/from internal names.
Example: The external naming conventions use MIME names, while the internal names use C lan-
guage conventions. The external MIME name Abc-Def-Ghi/3/Jkl-Mno is mapped to the logical
pathname: the first path segment is the words Abc, Def, and Ghi; the second path segment is the word
3; the third path segment is the words Jkl Mno. The logical name is mapped to the internal C lan-
guage name Abc_Def_Ghi[3].Jkl_Mno or, possibly, Abc_Def_Ghi[3]->Jkl_Mno.

6.2.3.5 Hard links

An object may be accessed by more than one name. A hard link is a first class reference to an object.
An object exists until all its hard links have been removed, then the object is destroyed.


                                                                                                          10
2003-01-20, SC25/WG1/Nxxx                                                            DCTP (WD3 15067-1)

6.2.3.6 Soft links

An alternate name may be created for an object. A soft link is a second class name: the link may still
exist after the target object is destroyed. Soft links are implicitly "chased" (automatically "derefer-
enced").

Example: If the soft link L points to D, then (1) getting the value L "chases" the link and returns the
value of D, (2) getting the value L/ refers to the link itself, i.e., the reference to D, not the value of D,
(3) getting the value L/. chases the link and retrieves D.

6.2.3.7 Reference

A name or pointer to an object. A reference is a second class name: the link may still exists after the
target object is destroyed. References must be explicitly "chased" (or "dereferenced"). Example: If
the reference L points to D, then (1) getting the value L refers to the link itself, i.e., the reference to D,
not the value of D, (2) getting the value L/ refers to the link itself, just like L, (3) getting the value L/.
chases the link and retrieves D.

6.2.3.8 Naming Views

A view represents a subset of structure data. A simple view might be a subtree of structure data. A
complex view may be an SQL select query to describe to subset.

6.2.4 Views
Views describe subsets of information within the repository. A view may be used to address the fol-
lowing needs.

6.2.4.1 Functional subsets

A view may be created to located and isolated certain information, such as "create the view V for ob-
ject X, that contains subset Y".

6.2.5 Files and Streams
Files and streams are large objects that may be retrieved in portions, e.g., a record at a time. A file
object shall support sequential and random (i.e., non-sequential) access. A stream object shall support
sequential access.


6.3 Control Model
The control refers to the methods of causing actions among the parties communicating via DCTP.
The following concepts characterize the DCTP control model.




                                                                                                           11
2003-01-20, SC25/WG1/Nxxx                                                           DCTP (WD3 15067-1)

6.3.1 Event
Assuming prior arrangement and appropriate authorization, each DCTP participant may send events.
For the sender, an event is a one-way message with no expected response. In programming lan-
guages, an event is analogous to a "go to". For the receiver, an incoming event is processed by an
event handler. The semantics of event handling is outside the scope of DCTP, i.e., DCTP provides the
framework and "tunnel" for sending and receiving events.

6.3.2 Wait
Assuming prior arrangement and appropriate authorization, a DCTP participant can ask another par-
ticipant to wait for an event, e.g., node A asks node B to wait for event E. In operating system kernel
technology, this is equivalent to "sleeping on an event".

6.3.3 Call
Assuming prior arrangement and appropriate authorization, a DCTP participant can send a "call" mes-
sage, similar to a "remote procedure call". A "call" is equivalent to (1) sending data (input parameters)
from caller to callee, (2) sending a "start" event to the "callee", (3) posting a "wait" on the callee's "fin-
ish" event, (4) receiving data (output parameters) from callee to caller. The advantage of "call" over
combined "event" and "wait" is that "call" handles the storage of temporary information in the "event"
and "wait" services.

6.3.4 Parameters
The "event", "wait", and "call" messages may pass parameters. Parameters are passed in a list along
with the target event. For example, a hypothetical function named ls is called with two function
properties (options to the command), and three parameters (the third parameter has properties, too): {
call ls .listing-type: long .dir-expand: no a b c .listing-encoding: iso-646
}.


6.4 Connections
A DCTP connection is created when a DCTP client successfully completes a connection command
(CONN) to a DCTP server. A DCTP participant is one end of communication regardless of role
(e.g., client or server). Some implementations may support Once a DCTP connection is established,
parameters may be negotiated and DCTP sessions may be created for data and control transfer. A
DCTP session is an connection established between one or more DCTP participants..


6.5 State model
A DCTP participant may act in the role of client or server.

6.5.1 Server state model
A DCTP server behaves according to the following state model.
                                                                                                           12
2003-01-20, SC25/WG1/Nxxx                                                 DCTP (WD3 15067-1)


            end
                       wait for    successful    wait for dropped knockdown
            start
                       connect      connect     command connection connection

                         event             command     command
                       received             received   completed
                                      event
                                    complete
                        event                    process
                       handler                  command      disconnect
                                                             command

Figure 1.   State model for DCTP server.


The following are the states for the DCTP server.

   Start: The state model begins in this state.

   Wait For Connect (state): The DCTP server is waiting for a connect.

       Successful Connect (event): Starts up the connection. Changes to Wait For Command
        (state).

   Wait For Command (state): The DCTP server is waiting for a command.

       Command Received (event): Begins the processing of a command. Changes to Process
        Command (state).

       Event Received (event): Begins the event handling. Changes to Event Handler (state).

       Dropped Connection (event): The connection was dropped. Changes to Knockdown
        Connection (state).

   Process Command (state): Processes a command, consumes and produces data, returns
    command status.

       Command Completed (event): The command has completed. Changes to Wait For
        Command (state).

       Disconnect Command (event): The Disconnect command was executed. Changes to
        Knockdown Connection (state).

   Event Handler (state): Processes an unsolicited event (e.g., security requests) and returns
    event status.

       Event Complete (event): The Event completed. Changes to Wait For Connect (state).

                                                                                               13
2003-01-20, SC25/WG1/Nxxx                                                    DCTP (WD3 15067-1)

   Knockdown Connection (state): Closes the connection. Changes to End (state)

   End: The state model exits.

6.5.2 Client state model
A DCTP client behaves according to the following state model.

            end                       failed connect
                        initiate    successful   wait for  dropped knockdown
            start
                       connect       connect    cmd ready connection connection

                         event             command        command
                       received              sent           return
                                      event
                                    complete
                        event                       command
                       handler                       process     process
                                                                disconnect

Figure 2.   State model for DCTP client.


The following are the states for the DCTP client.

   Start: The state model begins in this state.

   Initiate Connect (state): The DCTP client initiates a connection the server.

       Successful Connect (event): Starts up the connection. Changes to Wait For Cmd Ready
        (state).

       Failed Connect (event): Connection failure. Changes to Knockdown Connection (state).

   Wait For Cmd Ready (state): The DCTP client is waiting for the DCTP server to indicate
    that it is ready for a command.

       Command Sent (event): Sends the command to process. Changes to Command Process
        (state).

       Event Received (event): Begins the event handling. Changes to Event Handler (state).

       Dropped Connection (event): The connection was dropped. Changes to Knockdown
        Connection (state).

   Command Process (state): Requests the processing of a command, produces and consumes
    data, receives the command status upon command completion.


                                                                                               14
2003-01-20, SC25/WG1/Nxxx                                                DCTP (WD3 15067-1)

       Command Return (event): The command has completed. Changes to Wait For Cmd
        Ready (state).

       Process Disconnect (event): Sends the Disconnect command. Changes to Knockdown
        Connection (state).

   Event Handler (state): Processes an unsolicited event (e.g., security requests) and returns
    event status.

       Event Complete (event): The Event completed. Changes to Wait For Cmd Ready
        (state).

   Knockdown Connection (state): Closes the connection. Changes to End (state)

   End: The state model exits.


7 Data Definition

7.1 Data types
The DCTP data types are based on Language Independent Datatypes (ISO/IEC 11404).


7.2 Data Model Semantics
The following is the data model semantics.

7.2.1 Inherent structure
Objects may contain "structured" data.
Example:
        struct device_info
        {
           int id;
           char name[100];
           float value;
           time_t end_time;
        };
A C structure might be represented conceptually as:
          Label       Type            Value
        +-----------+-------------------+----------------+
        | id        | integer           | 11223344       |
        +-----------+-------------------+----------------+
        | name      | charactrstring    | ppqqrrss       |
        +-----------+-------------------+----------------+
        | value     | real              | 98.6           |
        +-----------+-------------------+----------------+
        | end_time | time(second,10,0) | 19980102030405 |
                                                                                             15
2003-01-20, SC25/WG1/Nxxx                                                       DCTP (WD3 15067-1)

       +-----------+-------------------+----------------+

The same conceptual structure might be used for XML:
       <device_info>
         <id>11223344</id>
         <name>ppqqrrss</name>
         <value>98.6</value>
         <end_time>19980102T030405</end_time>
       </device_info>
Semi-structured data uses the same structure except that some label and type information is missing.

7.2.2 Hierarchical naming
Data is organized via a hierarchical naming system.
Example:
       struct
       {
         int id;
         struct
         {
                     char   last[40];
                     char   first[30];
                     char   middle[30];
                     char   title[10];
            } name;
            float grade;
            time_t datetime;
       };

The nested C structure may be represented conceptually as:
         Label       Value
       +-----------+----------------+
       | id        | 11223344       |
       +-----------+----------------+
       | name      |last | Doe      |
       +-----------+----------------+
       | name      |first | John    |
       +-----------+----------------+
       | name      |middle| Q.      |
       +-----------+----------------+
       | name      |title | Dr.     |
       +-----------+----------------+
       | value     | 98          |
       +-----------+----------------+
       | end_time | 19980102030405 |
       +-----------+----------------+

The most important feature is the hierarchical label. Using C syntax as an example, id, name.last,
name.first, name.middle, name.title, grade, datetime.

Note that the naming (labeling) is the key feature, not the implementation of the structure, so the fol-
lowing is access in DCTP via the same labels:
  Label       Value
+-----------+----------------+

                                                                                                       16
2003-01-20, SC25/WG1/Nxxx                                                        DCTP (WD3 15067-1)

| id        | 11223344        |
+-----------+----------------+
| name      |      *----------|-------+
+-----------+----------------+        |
| value     | 98.6            |       |
+-----------+----------------+        |
| end_time | 19980102030405 |         |
+-----------+----------------+        |
                                      V
                                                     Name        Value
                                          +-----------+-------------+
                                          | last      | Doe         |
                                          +-----------+-------------+
                                          | first     | John        |
                                          +-----------+-------------+
                                          | middle    | Q.          |
                                          +-----------+-------------+
                                          | title     | Dr.         |
                                          +-----------+-------------+

The above conceptual data structures could be represented by UNIX filesystems (e.g., id,
name/last, name/first, name/middle, name/title, grade, datetime) or by Windows Registry
(e.g., id, name\last, name\first, name\middle, name\title, grade, datetime).

7.2.3 Associated properties
Objects can have properties associated with them. Properties are, conceptually, list of name-value
pairs. Properties may be system-defined (e.g., pointer address) or user-defined (e.g., security), static
(e.g., type) or dynamic (e.g., last modified time), require storage (e.g., security) or calculated on de-
mand (e.g., length).
  Label         Value
+-------------+----------------+
| id          | 11223344       |
+-------------+----------------+ Property List
| name        | John Doe       |-------+
+-------------+----------------+        |
| birthyear   | 1998           |        |
+-------------+----------------+        |
| currenttime | 19980102030405 |        |
+-------------+----------------+        |
                                        V
                                  Label       Value
                                +-----------+-------------+
                                | address   | 0x12345678 |
                                +-----------+-------------+
                                | security | read-write |
                                +-----------+-------------+
                                | type      | string      |
                                +-----------+-------------+
                                | modified | 19980103     |
                                +-----------+-------------+
                                | length    | ???         |
                                +-----------+-------------+




                                                                                                      17
2003-01-20, SC25/WG1/Nxxx                                                        DCTP (WD3 15067-1)

7.2.4 Merged namespace for properties
The namespace of properties are merged with the namespace of objects to simplify access to infor-
mation. In other words, only a "get value" is needed rather than requiring both "get value" and "get
property value" operations. Assuming name conventions of / as a pathname separator and . as a
property introduction, the _type property of the object name would be accessed via name/._type.

7.2.5 The _value property
The _value property of an object is identical to the value of the object, e.g., reading or writing the
value of "object" is identical to reading or writing the value of the property _value associated with the
object, i.e., getting object is the same getting object/._value.

7.2.6 External, logical, and internal naming conventions
The naming conventions may vary. Conceptually, the "external name" is the name used in infor-
mation interchange, e.g., the name used in the "get" name. The "external name" is mapped to the
"logical name". A "logical name" is comprised of a list of path name segments, each segment is a list
of "words". The "logical name" is mapped to the "internal name" within the implementation of the
structured data.
Examples of external names with varying external name conventions:
        Abc-Def/Ghi-Jkl/Mno-Pqr-Stu/123/456                 # MIME
        abc_def.ghi_jkl.mno_pgr_stu[123][456]               # C language
        AbcDef\GhiJkl\MnoPqrStu\123\456                     # Windows Registry
        ((abc def) (ghi jkl) (mno pqr stu) 123              456) # LISP

The above external names map into the following "logical name":
        path segment     #1:
                word     #1:   abc
                word     #2:   def
        path segment     #2:
                word     #1:   ghi
                word     #2:   jkl
        path segment     #3:
                word     #1:   mno
                word     #2:   pqr
                word     #3:   stu
        path segment     #4:
                word     #1:   123
        path segment     #5:
                word     #1:   56

The above logical name might map into any of the following "internal names"
        Abc-Def/Ghi-Jkl/Mno-Pqr-Stu/123/456                         #   MIME
        abc_def.ghi_jkl.mno_pgr_stu[123][456]                       #   C language
        AbcDef\GhiJkl\MnoPqrStu\123\456                             #   Windows Registry
        ((abc def) (ghi jkl) (mno pqr stu) 123 456)                 #   LISP
The external naming conventions are independent of and automatically mapped to the internal naming
conventions, e.g., a MIME naming convention might be used externally but a C language convention
is used internally.

                                                                                                      18
2003-01-20, SC25/WG1/Nxxx                                                        DCTP (WD3 15067-1)

Note: The above naming conventions are only examples. The naming conventions are defined via
parametric specification.

7.2.7 Keywords
Keywords are identifiers in the property namespace indicated by the prefix "_". Keywords have spe-
cial meaning, as defined below.
   _typeas: Returns the value converted to a specific type. For example, the identifier
    "switch/._typeas/integer" might return a light switch's value as an integer.
   _value: The "value" property.
   _prop: A list of properties.
   _type: The type of the object.
   _label: The label-only portion of the object.
Note: If the naming conventions use "." (period) as the character to introduce a property (i.e., a pre-
fix), then the name of the keywords would begin with "._", e.g., "._type".


8 General information on commands and messages
This Clause concerns general information about commands and messages within DCTP.


8.1 Session identification
A session is necessary to exchange data and control. A session is created by the OPEN command and
destroyed by the CLOS command.

8.1.1 Session ID
A session is created for each successful OPEN command. A session ID is associated with each ses-
sion. The most recently OPENd or used session is considered the current session. By default, all
commands except the CONN and DISC commands, refer to the current session. Optionally, the
command may be prefixed by a session ID that changes the current session to be that session ID.
Examples:
       11 GETV W               #   get   value   W   in   session   ID   11
       GETV X                  #   get   value   X   in   session   ID   11 (now 11 is default)
       12 GETV Y               #   get   value   Y   in   session   ID   12
       GETV Z                  #   get   value   Z   in   session   ID   12 (now 12 is default)

8.1.2 Session 0
A session 0 (zero) refers to the connection itself. No data nor control shall be exchanged on session 0.
Connection parameters be sent (PSES) or retrieved (GSES) by using session ID 0.

Examples:
       0 GSES *                # gets a parameters for the connection
                                                                                                     19
2003-01-20, SC25/WG1/Nxxx                                                        DCTP (WD3 15067-1)

8.2 Command request and response
Each command operates according the following sequence: the request (the command to process), and
the response (the result of the command).

8.2.1 Readiness for command acceptance
A client waits for the OKSV message to indicate that the server is ready to receive a command. The
format of the message is:
       ssss<htsp>OKSV<htsp>[code[<htsp>subcode[<htsp>message]]]

Where <htsp> indicates exactly one character that shall be either space (0020) or horizontal tab
(0009). Code and subcode values have implementation-defined meanings.
Examples:
       11 OKSV                            # ready for command in session 11

8.2.2 Return status
Each command returns a success or failure status. The format of the result is:
       ssss<htsp>STAT<htsp>code[<htsp>subcode[<htsp>message]]

Where <htsp> indicates exactly one character that shall be either space (0020) or horizontal tab
(0009). A code of value 0 indicates success. Other values have implementation-defined meanings.

Examples:
       11 STAT 0                 # successful status return
       12 STAT 0 0 success       # another kind of successful status return
       13 STAT 13 0 cannot access object         # failure indication

8.2.3 Returning data
A command may return data. The format is:
       ssss<htsp>DATA<htsp>data

Where <htsp> indicates exactly one character that shall be either space (0020) or horizontal tab
(0009). A command may return more than one data message.
Examples:
       11   DATA <abc>def</abc>            # a single-line response
       12   DATA <abc>     # a multi-line response
       12   DATA   def
       12   DATA </abc>

8.2.4 Returning out-of-band data
A command may return out-of-band data. The format of the result is:
       ssss<htsp>OOBD<htsp>code<htsp><htsp>data




                                                                                                 20
2003-01-20, SC25/WG1/Nxxx                                                       DCTP (WD3 15067-1)

Where <htsp> indicates exactly one character that shall be either space (0020) or horizontal tab
(0009). A code of value EROR indicates error message information. Other values have implementa-
tion-defined meanings.
Examples:
        11 OOBD EROR "xyx": cannot open object                 # a sample error message

Note: Out-of-band data, e.g., error messages, may be intermixed with data.


9 Data transfer-related commands and messages
The following data messages are supported. These messages are sent from "client" participant to the
"server" participant; the "server" then responds back to the "client". Data interchange participants may
play various roles, such as "client", "server", or both.

9.1.1 Get Value (GVAL) message
Synopsis:
        [session_id] GVAL [options] label
Gets a value, including all its properties.
Options:
   --dataonly: Gets the data without any labeling information.
   --notype: Don't return typing information.
   --noprop: Don't return property information.
   --nolabel: Don't return label information.
   --nilnoexist: Return NIL for a value for objects names that do not exist..
For example, the following might get some information:
        GVAL device_param_01/begin_valid_datetime

The result of the GVAL message is the value of the referenced object.

An XML coding might be:
        <datetime>
            <_value>19980102T000000</_value>
            <_accessmode>0777</_accessmode>
        </datatime>

A DNVP coding might be:

            datetime._value: 0D19980102000000
            datetime._access_mode: 0777


Note the access_mode is actually a property associated with the data (think of properties associated
with file systems).
The choice of coding would be via options early negotiation in the protocol.

                                                                                                     21
2003-01-20, SC25/WG1/Nxxx                                                 DCTP (WD3 15067-1)

9.1.2 Put Value (PVAL) message
Synopsis:
       [session_id] PUTV [options] label value
Puts a value, i.e., the companion service to the GVAL message above.

Options:
   --serial_list: For multi-valued objects, values are presented in serial order rather than
    matching value labels to object names.
   --createondemand: If name objects do not exist, create objects with NIL values prior to
    putting the value.
   --append: Append to object.
Examples:
       PUTV --createondemand: new_value "a new value"
       PUTV --append my_record \
       <a>
            <b>John Doe</b>
            <c>+1 212 555 1212</c>
            <d>john@doe.org</d>
            <e>http://doe.org/~john</e>
            <f>19980102T000000</f>
       </a>

The second example adds a record to the end of "my_record".

9.1.3 Make Object (MKOB) message
Synopsis:
       [session_id] MKOB [options] label value
Creates an object called label with the value value.

Options:
   --existok: If named object already exists, remove the object prior to creating the object.
   --type=typename: Create the object with the type typename.

9.1.4 Remove Object (RMOB) message
Synopsis:
       [session_id] RMOB [options] label
Removes label from the namespace.

Options:
   --noexistok: If named object does not exist, report no error.
   --linkonly: Remove link only, not target object.




                                                                                                 22
2003-01-20, SC25/WG1/Nxxx                                                     DCTP (WD3 15067-1)

9.1.5 Link Object (LNOB) message
Synopsis:
         [session_id] LNOB [options] old_label new_label
Create a link between two objects. The new_label name is linked to the old_label object.

Options:
   --hardlink: Linking must be accomplished by internal reference. Note: Not all imple-
    mentations support this feature.
   --softlink: Linking must be accomplished by automatic deference. Note: Not all imple-
    mentations support this feature.

9.1.6 List Object (LSOB) message
Synopsis:
         [session_id] LSOB [options] label_list ...
Lists objects in label_list.

Options:
   --recursive: List all objects and sub-objects.
   --properties=p1,p2,...: List only properties that match p1, p2, ....


10 Control transfer-related commands and messages

10.1Session establishment commands and messages
The following messages start up and shut down DCTP sessions.

10.1.1         Connect (CONN) message
Synopsis:
         CONN [options] label

Gets a handle (creates a session) to label, but does not request access. Assuming sockets are used
for transport, the CONN message is usually the first message sent after the socket connection has been
established.

10.1.2         Open (OPEN) message
Synopsis:
         [session_id] OPEN [options] [label]
Opens a (child) session. The default open mode is determined by the server participant.
Options:
                                                                                                   23
2003-01-20, SC25/WG1/Nxxx                                                     DCTP (WD3 15067-1)

   --mode=modetype: The type of open mode. The open mode may be "read-only" (or
    "ro"), "read-write" (or "rw"), "read-seq" ("rs"), "write-only" (or "wo"), "write-
    seq" (or "ws"), "append" (or "a"), or "inherit" (or ""). The read sequential access op-
    tion may be followed by the sub-option "ordering=xxx" where "xxx" may be
    "breadth", "depth", "alphasort", or "datesort".
   --dup=session: Creates a new session that is a duplicate of another.
Example: A typical sequence might be:
         CONN   user_prefs
         OPEN   --mode=read-only     //   open with read-only
         PSES   naming internet      //   set naming conventions
         PSES   coding xml           //   set coding conventions
         PPTH   language             //   change path to "language"
         GVAL   spoken               //   get value for object "spoken"
         GVAL   age-level            //   get value for object "age-level"

This would (1) set the naming conventions to internet style, (2) set the coding to XML style, (3) re-
solve the name of the client's preferences (handle to data, but not yet opens -- think "name to i-node
translation" in UNIX, or DNS resolution in IP), (4) request read-only access, (5) change the view to
preferences about "language", (6) get the spoken preferences (e.g., en-US), (7) get the age-level
preferences (e.g., 11 -- sixth grade).

10.1.3          Close (CLOS) message
Synopsis:
         [session_id] CLOS [options]
Closes the current session but does not remove the handle.
No standard options are defined.

10.1.4          Disconnect (DISC) message
Synopsis:
         DISC

Knocks down the connection.


10.2Session parameter commands and messages
The following messages control the parameters of the session.

10.2.1          Put Session Parameter (PSES) message
Synopsis:
         [session_id] PSES [options] label value
Assigns the session parameter to label to value.

Note: The session parameters may be associated with the handle and not any opened session.
                                                                                                   24
2003-01-20, SC25/WG1/Nxxx                                                   DCTP (WD3 15067-1)

No standard options are defined.

10.2.2         Get Session Parameter (GSES) message
Synopsis:
         [session_id] GSES [options] label
Retrieves the session parameter to label.

Note: The session parameters may be associated with the handle and not any opened session.
No standard options are defined.

10.2.3         Put Path (PPTH) message
Synopsis:
         [session_id] PPTH [options] label
Change the current path to label. Note: This message works like the cd command in FTP.

No standard options are defined.

10.2.4         Get Path (GPTH) message
Synopsis:
         [session_id] GPTH [options]
Gets the current path. Note: This message works like the pwd command in FTP.

No standard options are defined.


10.3Security commands and messages
The following messages define access to security features.

10.3.1         Request Authorization/Authentication (RQAU) message
Synopsis:
         [session_id] RQAU type param1 param2 ...
Requests authorization or authentication of type type from the other partner. The following authen-
tication types supported "password", "certificate", "challenge".

Note: This message is a peer-to-peer messaging scheme.

10.3.2         Response Authorization/Authentication (RSAU) message
Synopsis:
         [session_id] RSAU type param1 param2 ...
                                                                                                25
2003-01-20, SC25/WG1/Nxxx                                              DCTP (WD3 15067-1)

Response to authorization or authentication of type type. See RQAU.

Note: This message is a peer-to-peer messaging scheme.

10.3.3         Nomad (NOMD) message
Synopsis:
         [session_id] NOMD my-id your-id timeout
Requests nomadic session.

An implementation may ignore this request by responding with ERROR: xxx xxxxx Unavailable.
Note: This message is a peer-to-peer messaging scheme.


10.4Control commands and messages
The following control exchange messages.

10.4.1         Event (EVNT) message
Synopsis:
         [session_id] EVNT [option] target param1 param2 ...
Sends the message param1 param2 ... to target.
No standard options are defined.

10.4.2         Wait (WAIT) message
Synopsis:
         [session_id] WAIT [options] target param1 param2 ...
Waits for target event. When the event occurs, the handler handler is called with parameters
param1 ....

Options:
   --handler=service: Handler service to be called when wait completes.

10.4.3         CALL message
Synopsis:
         [session_id] CALL [options] target param1 param2 ...
Calls target with parameters param1 param2 ....
Options:
   --exception_handler=service: The exception handler service to be called upon er-
    rors.
                                                                                          26
2003-01-20, SC25/WG1/Nxxx                                                       DCTP (WD3 15067-1)


11 Annex A: Document development (informative)
This annex is informative and not normative.
This section concerns the development of this document. The past (revision history, resolved issues),
present (release notes, comment returns), and future (open issues) releases of this document are identi-
fied here.


11.1Revision history
   Working Draft 1, 2001-06-04, the first draft -- substantially complete.
   Working Draft 2, 2001-12-22, the second draft -- incorporates comments from WG1.
   Working Draft 3, 2003-01-20, the current draft -- preliminary review before CD ballot.

11.2Release notes for this document
The following notes apply to this release of this Standard:
   This document needs to be transformed to the ISO document template.

11.3Resolved issues
The following issues have been resolved:
   The formal ballot comments have been resolved, as described in SC25/WG1/N1018.

11.4Open issues
The following issues are outstanding:
   The various coding and encoding techniques (XML, ASN.1, UTF-8, etc.) need to be refer-
    enced.
   Need examples of security interchange.
   Conversion to ISO/IEC format.

11.5Comments on this document
All comments are appreciated. Please return all comments on this release of this document by
Wednesday, 2003-02-13 23:00 UTC. The Project Editor may be contacted at any one of the follow-
ing:
Telephone: +1 212 486 4700
Fax: +1 212 759 1605
E-mail: frank@farance.com

Frank Farance
Farance Inc.
Island Box 256
New York, NY, 10044-0205, USA

                                                                                                     27

								
To top