INTERNET-DRAFT Carsten Bormann Expires: May 1996 Universitaet Bremen Joerg Ott TU Berlin November 1995 Elements of Session Semantics draft-bormann-mmusic-semantics-00.txt Status of this memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This memo presents a set of object classes that can be used to define the local representation of the state of the conferences (sessions) that the local system is involved in (LASSO: local session state objects). In addition, some initial information is given on how to map this state to similar semantics in the ITU T.120 series of recommendations. We think these object classes might be used as a basis for defining the dynamic state variables visible in the horizontal control protocol used in a session. This memo is a submission to the IETF MMUSIC working group. Currently, this memo is in ``strawman'' stage. Comments of any kind are positively encouraged and should be addressed to the confctrl@isi.edu mailing list. 1. Introduction Conferencing systems employ session control protocols to achieve a common understanding of the state of the conference both between systems that support each participant and within each such system. So far, no proposal has been made to the MMUSIC working group that defines the set of information that makes up the dynamic state of a session in course. Bormann, Ott [Page 1] INTERNET-DRAFT Elements of Session Semantics November 1995 This memo presents an early look at LASSO, local session state objects. A tree structure built out of such objects (called a ``dictionary'' in our system) can be used as the focal point for the local interaction of applications and control agents within a participating system (a ``vertical protocol''). We also think that the object classes defined for LASSO can be used as a basis for defining the dynamic state variables visible in the horizontal control protocol that is run between control agents. 2. Notation We have chosen an exposition of the LASSO classes in a notation that is deliberately different from notations we have used in MMUSIC in the past. This is to avoid wasting any mental energy over the syntax. Each LASSO type is defined an an object class. By convention, type names are upper case. Objects of these types have attributes and subtrees: (class CLASS-NAME (attributes ...) (subtree ...)) There is no strong distinction between attributes and subtree information, but there is an expectation that in a control protocol all attributes for one object will be obtained at once, while subtrees are explicitly asked for. This notation allows some simple inheritance: (class (DERIVED BASE1 BASE2) (attributes ...) (subtree ...)) Attributes/subtrees can be required, optional or virtual (i.e., their status is defined in a derived class only). Types can be used in the context "(LIST TYPE)" (zero or more instances in an ordered list) and "(REFERENCE TYPE)" (points to other instance). Basic types are: BOOLEAN, INTEGER, STRING (human-readable), BYTE- STRING, SYMBOL (like strings, used for comparison with each other, but not particularly meant to be human-readable). 3. Useful Types This section defines some underlying types that will be used in other types. 3.1. USER A user is mainly defined by her "cname". It is expected that this is also used as the basis for the authentication process. Bormann, Ott [Page 2] INTERNET-DRAFT Elements of Session Semantics November 1995 (class USER ; "business card attributes" (attributes ; of a person (cf. RTCP) (cname STRING required) ; cabo@informatik.uni-bremen.de (name STRING required) ; Carsten Bormann (e-mail STRING optional) ; cabo@informatik.uni-bremen.de (phone (LIST STRING) optional) ; E.164: +49 421 218 70 24 (fax (LIST STRING) optional) ; E.164: +49 421 201 70 27 (location STRING optional) ; Bremen, Germany (organization STRING optional))) ; Universitaet Bremen 3.2. PROTOCOL, PROTOCOL-WITH-PARAMETERS, PARAMETER A PROTOCOL identifies a specific horizontal protocol available for talking to a specific application. A PROTOCOL-WITH-PARAMETERS adds values for parameters for the protocol (such as sampling rates, resolution, etc.). (Note that it is not quite clear where the boundary between protocols and parameters lies: is "H.261" a parameter of "RTP"? Or is "H.261/RTP" a protocol with parameters such as "CIF"/"QCIF"?) (class PROTOCOL (attributes (type SYMBOL required) ; IANA registered (id BYTE-STRING required))) ; as per type (class (PROTOCOL-WITH-PARAMETERS PROTOCOL) (attributes (parameters (LIST PARAMETER) required))) (class PARAMETER (attributes (type SYMBOL required) ; specific to protocol type (value BYTE-STRING required))) ; as per type 4. Information About the Local User and System This section defines that part of the LASSO object tree that is not immediately associated with a particular conference. 4.1. PRESENCE A presence is used as the root of the LASSO object tree. (A presence is a specific user ``logged in'' to a specific system -- this allows for the possibility that the user is logged in more than once.) It points to sets of capabilities/preferences defined by the local host and by the user, the set of running applications relevant to the conferences joined by this presence, and this set of conferences. Bormann, Ott [Page 3] INTERNET-DRAFT Elements of Session Semantics November 1995 (class PRESENCE (attributes (name STRING required) ; ID of person responsible (host STRING required) ; local host (number INTEGER required)) ; number of presence on local host (subtree (host LOCAL-HOST required) ; capabilities intrinsic to host (user LOCAL-USER required) ; capabilities specific to user (applications (LIST APPLICATION) required) ; locally running apps (conferences (LIST CONFERENCE) required))) ; current conferences 4.2. LOCAL-USER The information locally available about a user is that of the type USER, augmented by a set of applications that this user generally wants to have running, a set of preferences among applications that can handle a particular protocol, and a set of applications this user has installed separately from the per-host information (~/bin style). (class (LOCAL-USER USER) (subtree (initialize (LIST LOCAL-APPLICATION) required) ; apps always wanted (preferences (LIST PREFERENCE) required) ; proto-to-app mappings (applications (LIST APPLICATION-DESCRIPTION) required))) ; available (class PREFERENCE (attributes (protocols (LIST PROTOCOL-WITH-PARAMETERS) required) (application-list (LIST (REFERENCE APPLICATION-DESCRIPTION)) required) ; applications, most preferred first )) (class APPLICATION-DESCRIPTION (attributes (name STRING required) ; "NanoFirm Paragraph against Doors" (version STRING required) ; "3.14159" (invocation STRING required) ; pathname used for invoking (parameter-spec PARAMETER-SPEC required) ; .sd.tcl (if H.261 "-pH261") (protocols (LIST PROTOCOL) required))) ; protocols this app supports 4.3. HOST, LOCAL-HOST, INTERFACE, DEVICE Information on a host includes its hostname, a set of interfaces available for networking (details to be defined -- e.g., ISDN/H.320 vs. IP vs. both), and a set of devices that could be useful in a multimedia conference (examples are given for cameras and speakers). Bormann, Ott [Page 4] INTERNET-DRAFT Elements of Session Semantics November 1995 (class HOST (attributes (hostname STRING required)) ; /host/hostname == /.host (subtree (interfaces (LIST INTERFACE) required) ; network attachments (devices (LIST DEVICE) required))) ; hardware capabilities The information available locally on a host generally includes a set of descriptions of installed applications. (class LOCAL-HOST HOST) (subtree (applications (LIST APPLICATION-DESCRIPTION) required))) ; sw caps A host may have a number of network interfaces of various kinds. IP interfaces, in particular, have an address and can be classified as to their approximate bandwidth. (class INTERFACE (attributes (type SYMBOL virtual))) (class IP-INTERFACE (attributes (type SYMBOL "IP") (address BYTE-STRING required) (bandwidth BANDWIDTH optional))) (class BANDWIDTH (attributes (type SYMBOL virtual))) A host may have a number of devices of interest in a conference setting. Each of the possible kinds of devices has some specific attributes, of which two examples are given here. Bormann, Ott [Page 5] INTERNET-DRAFT Elements of Session Semantics November 1995 (class DEVICE (attributes (type STRING virtual) ; defined in derived class (system-handle STRING required))) ; "/dev/audio0" "host:0" etc. (class (SPEAKERS DEVICE) (attributes (type STRING "audio-out") (stereo BOOLEAN required))) (class (CAMERA DEVICE) (attributes (type STRING "video-in") (color BOOLEAN required))) 4.4. APPLICATION Information on a running application includes information on the kind of application and information on how to address this application. (class (APPLICATION APPLICATION-DESCRIPTION APPLICATION-ADDRESS)) 5. Information about Conferences 5.1. CONFERENCE Conferences are the focal point of LASSO. They have a human-readable name, an ID, various attributes, are based on a conference profile, have a defined list of members, involve resources (defined key-value relationships), can be described by global capabilities, and in particular are structured into groups of media agents (applications). (class CONFERENCE (attributes (name STRING required) (conference-id BYTE-STRING required) (me (REFERENCE MEMBER) optional) ; required when I'm in the conference (locked BOOLEAN optional) ; no additional members allowed (listed BOOLEAN optional) ; conference is being announced (security CONFERENCE-SECURITY optional)) (subtree (profile PROFILE required) (members (LIST MEMBER) required) (resources (LIST RESOURCE) required) (global-caps (LIST CAPABILITY) required) (appl-groups (LIST APPLICATION-GROUP) required))) A resource is something that can be allocated, identified by a name Bormann, Ott [Page 6] INTERNET-DRAFT Elements of Session Semantics November 1995 (or a set of other attributes). It is intended that the fact that a resource was allocated is known throughout the conference (e.g. for locking a resource). RESOURCE itself is a virtual class (which is extended per kind of usage). (class RESOURCE (attributes (type SYMBOL virtual) (key BYTE-STRING required))) The conference security attributes need to be defined. (class CONFERENCE-SECURITY (attributes (type SYMBOL virtual))) 5.2. PROFILE The conference profile is the static, reusable part of the conference state (generally defined prior to a conference). (class PROFILE (attributes (name STRING required) (conductible BOOLEAN default false) (terminates-when-empty BOOLEAN default true) (security CONFERENCE-SECURITY optional)) ; privilege lists etc. (subtree (agenda (LIST STRING) optional) (documents (LIST CONTRIBUTION) optional) (roles (LIST ROLE) required) (rules (LIST RULE) required))) Roles classify the participants of a conference. Each role is associated with a set of permissions and a set of users that can take on that role. (class ROLE (attributes (name SYMBOL required) (description STRING required) ; human-readable (permissions (LIST PERMISSION) optional) (members (LIST USER) optional))) (class PERMISSION (attributes (name SYMBOL required))) ; symbolic name for permission Bormann, Ott [Page 7] INTERNET-DRAFT Elements of Session Semantics November 1995 Rules define the way specific decisions are made. A CONDUCTOR-RULE means that the chairperson of a conference simply can make that particular decision, while a QUORUM-RULE requires a vote from the members (at least from those wielding a particular permission). (class RULE (attributes (name SYMBOL required) (voting-type SYMBOL virtual))) (class (CONDUCTOR-RULE RULE) (attributes (voting-type SYMBOL fixed "conductor"))) (class (QUORUM-RULE RULE) (attributes (voting-type SYMBOL fixed "majority") (required-permission SYMBOL optional) ; e.g. "rep" so guests can't vote (acceptance-percentage RATIONAL required))) 5.3. APPLICATION-GROUP An APPLICATION-GROUP contains information for a set of peer media agents. (class APPLICATION-GROUP (attributes (protocol PROTOCOL-WITH-PARAMETERS required) (context (LIST PARAMETER) required)) ; common application parameters (subtree (per-member (LIST APP-PER-MEMBER) required))) (class APP-PER-MEMBER (attributes (member (REFERENCE MEMBER) required) (contact APPLICATION-ADDRESS required) (caps (LIST CAPABILITY) required))) (class APPLICATION-ADDRESS (attributes (type SYMBOL virtual))) (class (INTERNET-APPLICATION-ADDRESS APPLICATION-ADDRESS) (attributes (type SYMBOL fixed "IP/PORT") (ip-address BYTE-STRING required) (port INTEGER required))) 5.4. MEMBER An object of type MEMBER represents a presence within a conference. Bormann, Ott [Page 8] INTERNET-DRAFT Elements of Session Semantics November 1995 (Note the the current definition has a major shortcoming: a presence may actually represent a set of human beings.) (class (MEMBER USER) (attributes (note STRING optional) ; "out to lunch" (cf. RTCP) (contributions (LIST CONTRIBUTION) optional) (roles (LIST SYMBOL) required)) ; conductor, guest, proponent... (subtree (host CONFERENCE-HOST required) (caps (LIST CAPABILITY) required))) (class (CAPABILITY PROTOCOL-WITH-PARAMETERS)) ; same structure, but additional types allowed... (class CONTRIBUTION ; document "brought to the meeting" (attributes (name STRING required) ; id / reference / description (uri STRING optional))) ; obtain where? (class (CONFERENCE-HOST HOST) (attributes (type (LIST SYMBOL) required))) ; end-system, mixer, translator, etc. 6. Security Considerations This memo does not define any access control that may be required on elements of the session state. This needs to be done in the context of a conference policy. 7. Authors' Addresses Carsten Bormann Joerg Ott Universitaet Bremen FB3 MZH 5180 Technische Universitaet Berlin FR 6-3 Postfach 330440 Franklinstr. 28/29 D-28334 Bremen D-10587 Berlin GERMANY GERMANY cabo@informatik.uni-bremen.de jo@cs.tu-berlin.de Appendix: T.120 Support This appendix defines a few classes that could be used to maintain T.120 specific information. This is done by defining additional derived classes that inherit from the classes defined in the main body of this document. Bormann, Ott [Page 9] INTERNET-DRAFT Elements of Session Semantics November 1995 (class (T-120-CONFERENCE CONFERENCE) (attributes (superior-name STRING optional) (superior-modifier STRING optional) (local-name STRING optional) (local-modifier STRING optional) (modifier STRING required) (domain-name STRING required))) (class (T120-TOKEN RESOURCE) (attributes (type SYMBOL fixed t120-token) (token INTEGER required))) (class (T120-CHANNEL RESOURCE) (attributes (type SYMBOL fixed t120-channel) (channel INTEGER required))) (class (T120-CONFERENCE-HOST CONFERENCE-HOST) ; additional types: terminal (= end-system?), mcu, multiport-terminal (attributes (node-id INTEGER required) ; GCC user id of this node (superior-node-id INTEGER optional) ; GCC user id of superior node (alternative-node-id INTEGER optional) (node-name STRING optional) ; "Bremen", equal to location??? (site-information STRING optional) ; useful stuff about the site (management-device BOOLEAN required) ; has mgmt function (peripheral-device BOOLEAN required))) ; subordinate to other device??? (class (T120-APPLICATION-ADDRESS APPLICATION-ADDRESS) (attributes (type SYMBOL fixed "MCS-SMC") (single-member-channel INTEGER required))) Appendix: SDP Support This appendix defines additional attributes of the session state elements based on attributes defined in the SDP protocol. [This needs to be completed.] An SDP-announced conference has additional attributes, which here are attached to a class derived from CONFERENCE. Some of these attributes may be PROFILE attributes, instead. Bormann, Ott [Page 10] INTERNET-DRAFT Elements of Session Semantics November 1995 (class (SDP-CONFERENCE CONFERENCE) (attributes (address MULTICAST-ADDRESS required) ; strictly speaking, this address is only a default for the media ; and simply should be required there (creator USER required) (version NUMBER required) (creating-host HOST required) (description STRING optional) (uri STRING optional) (time STRING optional) ; zero or more times (repeat-spec STRING optional) (bandwidth BANDWIDTH optional) (attributes (LIST PARAMETER) optional))) SDP defines the ``k='' attribute, which is a kind of CONFERENCE- SECURITY. (class (SDP-K-CONFERENCE-SECURITY CONFERENCE-SECURITY) (attributes (type SYMBOL fixed "FIXED-DES-ENCRYPTION") (key BYTE-STRING required))) The conference bandwidth is a special kind of bandwidth value. (class (CT-BANDWIDTH BANDWIDTH) (attributes (type SYMBOL fixed "CT") (value NUMBER required))) Addressing for IP multicasting generally is per-media. (class (MULTICAST-ADDRESS ADDRESS) (attributes (type SYMBOL virtual))) (class (IPV4-MULTICAST-ADDRESS ADDRESS) (attributes (type SYMBOL fixed "IP4") (ip BYTE-STRING required) (ttl NUMBER required))) (class (MULTICAST-MEDIA PROTOCOL-WITH-PARAMETERS) (attributes (address MULTICAST-ADDRESS optional) ; defaults to per-conf address (port NUMBER required))) Bormann, Ott [Page 11]