INTERNET-DRAFT                                           Carsten Bormann
Expires: May 1996                                    Universitaet Bremen
                                                               Joerg Ott
                                                               TU Berlin
                                                           November 1995

                     Elements of Session Semantics

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 (Africa), (Europe), (Pacific Rim), (US East Coast), or (US West Coast).


   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 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

   Each LASSO type is defined an an object class.  By convention, type
   names are upper case.  Objects of these types have attributes and

(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

   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

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)         ;
        (name STRING required)          ; Carsten Bormann
        (e-mail STRING optional)        ;
        (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


   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"?)

        (type SYMBOL required)          ; IANA registered
        (id BYTE-STRING required)))     ; as per type

        (parameters (LIST PARAMETER) required)))

        (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.


   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

        (name STRING required)          ; ID of person responsible
        (host STRING required)          ; local host
        (number INTEGER required))      ; number of presence on local host
        (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


   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).

        (initialize (LIST LOCAL-APPLICATION) required) ; apps always wanted
        (preferences (LIST PREFERENCE) required) ; proto-to-app mappings
        (applications (LIST APPLICATION-DESCRIPTION) required))) ; available

        (protocols (LIST PROTOCOL-WITH-PARAMETERS) required)
        (application-list (LIST (REFERENCE APPLICATION-DESCRIPTION)) required)
                                        ; applications, most preferred first

        (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


   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
        (hostname STRING required))     ; /host/hostname == /.host
        (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.

        (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.

        (type SYMBOL virtual)))

        (type SYMBOL "IP")
        (address BYTE-STRING required)
        (bandwidth BANDWIDTH optional)))

        (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
        (type STRING virtual)           ; defined in derived class
        (system-handle STRING required))) ; "/dev/audio0" "host:0" etc.

        (type STRING "audio-out")
        (stereo BOOLEAN required)))

        (type STRING "video-in")
        (color BOOLEAN required)))


   Information on a running application includes information on the kind
   of application and information on how to address this application.


5.  Information about Conferences


   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).

        (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))
        (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).

        (type SYMBOL virtual)
        (key BYTE-STRING required)))

   The conference security attributes need to be defined.

        (type SYMBOL virtual)))


   The conference profile is the static, reusable part of the conference
   state (generally defined prior to a conference).

(class PROFILE
        (name STRING required)
        (conductible BOOLEAN default false)
        (terminates-when-empty BOOLEAN default true)
        (security CONFERENCE-SECURITY optional))
                                        ; privilege lists etc.
        (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
        (name SYMBOL required)
        (description STRING required)   ; human-readable
        (permissions (LIST PERMISSION) optional)
        (members (LIST USER) optional)))

        (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
        (name SYMBOL required)
        (voting-type SYMBOL virtual)))

        (voting-type SYMBOL fixed "conductor")))

        (voting-type SYMBOL fixed "majority")
        (required-permission SYMBOL optional) ; e.g. "rep" so guests can't vote
        (acceptance-percentage RATIONAL required)))


   An APPLICATION-GROUP contains information for a set of peer media

        (protocol PROTOCOL-WITH-PARAMETERS required)
        (context (LIST PARAMETER) required))    ; common application parameters
        (per-member (LIST APP-PER-MEMBER) required)))

        (member (REFERENCE MEMBER) required)
        (contact APPLICATION-ADDRESS required)
        (caps (LIST CAPABILITY) required)))

        (type SYMBOL virtual)))

        (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)
        (note STRING optional)          ; "out to lunch" (cf. RTCP)
        (contributions (LIST CONTRIBUTION) optional)
        (roles (LIST SYMBOL) required)) ; conductor, guest, proponent...
        (host CONFERENCE-HOST required)
        (caps (LIST CAPABILITY) required)))

; same structure, but additional types allowed...

(class CONTRIBUTION                     ; document "brought to the meeting"
        (name STRING required)          ; id / reference / description
        (uri STRING optional)))         ; obtain where?

        (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

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

        (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)
        (type SYMBOL fixed t120-token)
        (token INTEGER required)))

        (type SYMBOL fixed t120-channel)
        (channel INTEGER required)))

       ; additional types: terminal (= end-system?), mcu, multiport-terminal
        (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???

        (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

        (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-

        (type SYMBOL fixed "FIXED-DES-ENCRYPTION")
        (key BYTE-STRING required)))

   The conference bandwidth is a special kind of bandwidth value.

        (type SYMBOL fixed "CT")
        (value NUMBER required)))

   Addressing for IP multicasting generally is per-media.

        (type SYMBOL virtual)))

        (type SYMBOL fixed "IP4")
        (ip BYTE-STRING required)
        (ttl NUMBER required)))

        (address MULTICAST-ADDRESS optional) ; defaults to per-conf address
        (port NUMBER required)))

Bormann, Ott                                                   [Page 11]