1. 2002-01-24SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc. 1 Presentation to SC25/WG1 On Interoperability (18012-2) and DCTP (Command/Control Services/Protocols) Presentation By Frank Farance, Farance Inc. +1 212 486 4700, frank@farance.com

2. 2002-01-24SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc. 2 Background Information on 15067-1 Data and Control Transfer Protocol (DCTP) Based on work by Simon Garrett and other contributions Concerns interoperability (roughly layer 5) ISO OSI stack is not implied, e.g., RS-232 transport is possible

3. 2002-01-24SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc. 3 What DCTP Does Common method for get/put values –Both numeric and non-numeric values Common method for passing params/control Common framework for security (“plug-ins”) Various connection frameworks –connection vs. connectionless –point-to-point vs. broadcast –connected vs. roaming vs. sometimes-connected –bus vs. ring vs. point-to-point connectivity –depends upon underlying communications Very simple implementation paradigm –Supports low-memory, embedded systems –Data and control paradigms

4. 2002-01-24SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc. 4 What DCTP Does Not Do DCTP does not determine lexicon, e.g., –Names of parameters –Acceptable values DCTP does not define naming of objects DCTP does not require specific security services DCTP does not specify transport facilities DCTP does not mandate proprietary systems change — gateways/virtualization is possible

5. 2002-01-24SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc. 5 Applications of DCTP Command and control (C2) for appliances/devices –Set/retrieve values –May be used for smart/dumb devices Bridging protocol/services among proprietary protocols/services DCTP can be “lower” level protocol support for higher APIs

6. 2002-01-24SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc. 6 How the Pieces Fit Together Device/ Ctrl #1 Device/ Ctrl #2 Process: 18012-4 Coding: 18012-2 (lexicon) Conforms To “Registry” Command/ Control e.g.,15067-1 DCTP Process: Determines what is entered in registry Registry: Valid code sets; extension mechanism Command/Control Protocol: Protocol binding of 18012-1, using 18012-2 codesets (lexicon), as maintained by 18012-4 process Applications: Claim conformance to: 18012-2, 15067-1 Creates/ Administers Consensus- Building Process Registry (table)

7. 2002-01-24SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc. 7 Relationship to 18012 Interoperability Current 18012 status: –Part 1: Introduction –Part 2: Taxonomy and Lexicon –Part 3: Application Models At both 2001-01 and 2001-06 SC25/WG1, it was suggested that Part 4 be added: –Part 4: Registration Authority –Simplifies adoption and maintenance of 18012 series of documents

8. 2002-01-24SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc. 8 Example DCTP Binding of 18012 Generically, the binding might look like: – PVAL lexicon_object lexicon_value Assuming registered in 18012-2 lexicon: – “LAMP” is a registered object – “OFF” and “ON” are registered values causing actions “off” and “on” Sample messages: – PVAL LAMP OFF – PVAL LAMP ON MDAS (ISO/IEC 20944-*) binding: – mdas_putvalue(“LAMP”,“OFF”) – mdas_putvalue(“LAMP”,“ON”)

9. 2002-01-24SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc. 9 Methodology: Work Flow And Progressive Deliverables Requirements Functionality Conceptual Model Semantics Bindings: APIs Bindings: Codings Bindings: Protocols Encodings: Data Formats Encodings: Calling Conventions Encodings: Various Communication Layers The Steps of Building Successful Information Technology Standards/Specifications “The work flow/steps promote (1) consensus-building, and (2) long-term stability, interpretation, maintenance of the standard/specification.” “Consensus-building is incremental.” “Interpretation/maintenance is stabilized: each level is dependent on higher levels.” “Interpretation Examples: - Ambiguities in bindings are resolved by interpreting the semantics; - Ambiguities in semantics are resolved by interpreting the conceptual model.”

10. 2002-01-24SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc. 10 A Framework for Harmonized/Consistent... Bindings: Codings, APIs, Protocols Encodings: Calling Conventions, Data Formats, Communication Layers Topic-Specific Informative Wording Topic-Specific Normative Wording Cross-Topic Codings: XML Cross-Topic APIs Informative Wording Cross-Topic APIs: Normative Wording Java, JavaScript, C/C++, Perl, Tcl, VB Various Standards Cross-Topic Protocols e.g.: Session Layers Various Standards Requirements Functionality Conceptual Model Semantics Bindings: CodingsBindings: Protocols Encodings: Various Communication Layers Encodings: Data Formats Bindings: APIs Encodings: Calling Conventions

11. 2002-01-24SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc. 11 Relatively Dynamic Relatively Static Long-Term vs. Short-Term Specs Strategy for Keeping Pace With Technology Topic-Specific Informative Wording Topic-Specific Normative Wording Cross-Topic Codings: XML Cross-Topic APIs Informative Wording Cross-Topic APIs: Normative Wording Java, JavaScript, C/C++, Perl, Tcl, VB Various Standards Cross-Topic Protocols e.g.: Session Layers Various Standards Requirements Functionality Conceptual Model Semantics Bindings: CodingsBindings: Protocols Encodings: Various Communication Layers Encodings: Data Formats Bindings: APIs Encodings: Calling Conventions

12. 2002-01-24SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc. 12 Interoperability (18012-1) Represents Higher Levels Topic-Specific Informative Wording Topic-Specific Normative Wording Cross-Topic Codings: XML Cross-Topic APIs Informative Wording Cross-Topic APIs: Normative Wording Java, JavaScript, C/C++, Perl, Tcl, VB Various Standards Cross-Topic Protocols e.g.: Session Layers Various Standards Requirements Functionality Conceptual Model Semantics Bindings: CodingsBindings: Protocols Encodings: Various Communication Layers Encodings: Data Formats Bindings: APIs Encodings: Calling Conventions

13. 2002-01-24SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc. 13 Data and Control Transfer Protocol (DCTP, ISO/IEC 15067-1) Is “Protocol-Like” Topic-Specific Informative Wording Topic-Specific Normative Wording Cross-Topic Codings: XML Cross-Topic APIs Informative Wording Cross-Topic APIs: Normative Wording Java, JavaScript, C/C++, Perl, Tcl, VB Various Standards Cross-Topic Protocols e.g.: Session Layers Various Standards Requirements Functionality Conceptual Model Semantics Bindings: CodingsBindings: Protocols Encodings: Various Communication Layers Encodings: Data Formats Bindings: APIs Encodings: Calling Conventions

14. 2002-01-24SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc. 14 Metadata Access Service (ISO/IEC 20944) Is “API-Like” Topic-Specific Informative Wording Topic-Specific Normative Wording Cross-Topic Codings: XML Cross-Topic APIs Informative Wording Cross-Topic APIs: Normative Wording Java, JavaScript, C/C++, Perl, Tcl, VB Various Standards Cross-Topic Protocols e.g.: Session Layers Various Standards Requirements Functionality Conceptual Model Semantics Bindings: CodingsBindings: Protocols Encodings: Various Communication Layers Encodings: Data Formats Bindings: APIs Encodings: Calling Conventions

15. 2002-01-24SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc. 15 APIs, Codings, Protocols — All Three Should Be Considered Semantics Bindings: APIs Bindings: Codings Bindings: Protocols - Std APIs may be implemented via std or proprietary Protocols - Std Protocols may be accessed by std or proprietary APIs - Both std APIs/Protocols improve wide area interoperability - Std APIs may use std or proprietary Codings - Std Codings may be used by std or proprietary APIs - Both std APIs/Codings improve portable apps/data - Std Protocols may use std or proprietary Codings - Std Codings may be exchanged via std or proprietary Protocols - Both std Protocols/Codings improve system interoperability Harmonized standard APIs, Codings, and Protocols promote: - Application portability - Data portability - Multi-vendor, “open” solutions - Wide area, end-to-end interoperability Prioritizing The Development Of Standards for Codings, APIs, and Protocols

16. 2002-01-24SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc. 16 Building Standards In Several Steps Maintenance Development Review Amendments: 2-3 years Revisions: 4-5 years Consensus Building User/Vendor/ Institutional/ Industry “Extensions” “Extensions” Become Input To Next Revision Of Standard Industry-Relevant, Widely-Adopted “Extensions” The “Standard”

17. 2002-01-24SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc. 17 Metadata Access Service (MDAS, ISO/IEC 20944-x) Requirements –Make inquiries into repositories to determine metadata –Use metadata for further interoperability of repositories –Help facilitate metadata/data interchange among repositories –Harmonize with semi-structure data access –Harmonize with lexicon query service, terminology services

18. 2002-01-24SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc. 18 Metadata Access Service (MDAS, ISO/IEC 20944-x) Functionality –Interacts directly with repositories –Get (and put) metadata/data –Specialized query features to handle: Search by type Search by identifier Search by label Search by property (attribute)

19. 2002-01-24SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc. 19 Metadata Access Service (MDAS, ISO/IEC 20944-x) Semantics Summary –Currently being refined, based on SDA API, LQS, DCTP, etc. –Work being harmonized with ISO 15067-1 (DCTP being incorporated) RESOLVE : connect to repository OPEN : begin access to repository SET : set protocol parameters QUERY : query protocol parameters GIVEAUTH, NEEDAUTH : authentication/authorization NOMAD : nomadic (disconnected) access CV : change view (directory) GETVAL : get info from repository PUTVAL : put info to repository LIST : retrieve names in repository EVENT : client and server event processing CLOSE : end access to repository UNRESOLVE : disconnect from repository

20. 2002-01-24SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc. 20 DCTP (15067-1) Messages Summary CONN (connect): Connection to “repository” –Can be ignored for simple controllers OPEN (open): Establish session –Can support multiple sessions –Simple controllers need only support single session RQAU : Request authentication/authorization –Security request RSAU : Respond authentication/authorization –Security response CLOS (close): Close session –Simple controllers can ignore DISC (disconnect): Disconnect from “repository” –Simple controllers can ignore

21. 2002-01-24SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc. 21 DCTP (15067-1) Messages Summary GSES : Get session parameters –Can be very simplistic PSES : Put session parameters –Can support multiple sessions –Simple controllers need only support single session GVAL : Get value (retrieve, variety of types) –Simple to implement for simple controllers PVAL : Put value (store, variety of types) –Simple to implement for simple controllers

22. 2002-01-24SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc. 22 DCTP (15067-1) Messages Summary LSOB : List “objects” –Easy to implement MKOB : New (make “object”) –Simple controllers can ignore RMOB : Destroy (remove “object”) –Simple controllers can ignore NOMD : Nomadic connection setup –Simple controllers can ignore GPTH : Get current path/view –Simple response for simple controllers PPTH : Put current path/view –Simple controllers can ignore

23. 2002-01-24SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc. 23 Sample Messages OPEN GVAL xyz PVAL xyz 123 PVAL abc “off”

24. 2002-01-24SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc. 24 Integration With HomeGate Used inside the residential gateway Can be used to bridge subnets for command and control Can be used an an intermediate language Should be a standard, not a technical report Definitely normative wording: implementations will want to claim conformance

25. 2002-01-24SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc. 25 Integration With HomeGate Not required in a residential gateway because systems can choose to conform (or not) to ISO/IEC 15067-1 Components can use proprietary bridging mechanism, if desired DCTP allows vendors to build “half-bridges” among subnets, which reduces integration complexity to N, not N*N Implementations already in C, C++, Perl, Java — all are small code size

26. 2002-01-24SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc. 26 Status of 15067-1 Document Draft 1, dated 2001-06-04 Draft 2, dated 2001-12-22 –Minor wording polishing/improvements –Fixing inconsistencies with 11404 datatyping –Add wording to explain enum lists and prop lists –Rename “name” to “label” in the metadata –Fill in some of the holes Draft 3, target 2002-05 (in time for 2002-06 mtg) –Establish editing/review committee (telecons) –Finish “to be supplied” items