idnits 2.17.00 (12 Aug 2021) /tmp/idnits28056/draft-bormann-mmusic-semantics-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2022-05-14) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 22 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 423 has weird spacing: '...emen.de jo@...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 1995) is 9677 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Carsten Bormann 3 Expires: May 1996 Universitaet Bremen 4 Joerg Ott 5 TU Berlin 6 November 1995 8 Elements of Session Semantics 9 draft-bormann-mmusic-semantics-00.txt 11 Status of this memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Abstract 31 This memo presents a set of object classes that can be used to define 32 the local representation of the state of the conferences (sessions) 33 that the local system is involved in (LASSO: local session state 34 objects). In addition, some initial information is given on how to 35 map this state to similar semantics in the ITU T.120 series of 36 recommendations. We think these object classes might be used as a 37 basis for defining the dynamic state variables visible in the 38 horizontal control protocol used in a session. 40 This memo is a submission to the IETF MMUSIC working group. 41 Currently, this memo is in ``strawman'' stage. Comments of any kind 42 are positively encouraged and should be addressed to the 43 confctrl@isi.edu mailing list. 45 1. Introduction 47 Conferencing systems employ session control protocols to achieve a 48 common understanding of the state of the conference both between 49 systems that support each participant and within each such system. 50 So far, no proposal has been made to the MMUSIC working group that 51 defines the set of information that makes up the dynamic state of a 52 session in course. 54 This memo presents an early look at LASSO, local session state 55 objects. A tree structure built out of such objects (called a 56 ``dictionary'' in our system) can be used as the focal point for the 57 local interaction of applications and control agents within a 58 participating system (a ``vertical protocol''). We also think that 59 the object classes defined for LASSO can be used as a basis for 60 defining the dynamic state variables visible in the horizontal 61 control protocol that is run between control agents. 63 2. Notation 65 We have chosen an exposition of the LASSO classes in a notation that 66 is deliberately different from notations we have used in MMUSIC in 67 the past. This is to avoid wasting any mental energy over the 68 syntax. 70 Each LASSO type is defined an an object class. By convention, type 71 names are upper case. Objects of these types have attributes and 72 subtrees: 74 (class CLASS-NAME (attributes ...) (subtree ...)) 76 There is no strong distinction between attributes and subtree 77 information, but there is an expectation that in a control protocol 78 all attributes for one object will be obtained at once, while 79 subtrees are explicitly asked for. 81 This notation allows some simple inheritance: 83 (class (DERIVED BASE1 BASE2) (attributes ...) (subtree ...)) 85 Attributes/subtrees can be required, optional or virtual (i.e., their 86 status is defined in a derived class only). 88 Types can be used in the context "(LIST TYPE)" (zero or more 89 instances in an ordered list) and "(REFERENCE TYPE)" (points to other 90 instance). 92 Basic types are: BOOLEAN, INTEGER, STRING (human-readable), BYTE- 93 STRING, SYMBOL (like strings, used for comparison with each other, 94 but not particularly meant to be human-readable). 96 3. Useful Types 98 This section defines some underlying types that will be used in other 99 types. 101 3.1. USER 103 A user is mainly defined by her "cname". It is expected that this is 104 also used as the basis for the authentication process. 106 (class USER ; "business card attributes" 107 (attributes ; of a person (cf. RTCP) 108 (cname STRING required) ; cabo@informatik.uni-bremen.de 109 (name STRING required) ; Carsten Bormann 110 (e-mail STRING optional) ; cabo@informatik.uni-bremen.de 111 (phone (LIST STRING) optional) ; E.164: +49 421 218 70 24 112 (fax (LIST STRING) optional) ; E.164: +49 421 201 70 27 113 (location STRING optional) ; Bremen, Germany 114 (organization STRING optional))) ; Universitaet Bremen 116 3.2. PROTOCOL, PROTOCOL-WITH-PARAMETERS, PARAMETER 118 A PROTOCOL identifies a specific horizontal protocol available for 119 talking to a specific application. A PROTOCOL-WITH-PARAMETERS adds 120 values for parameters for the protocol (such as sampling rates, 121 resolution, etc.). (Note that it is not quite clear where the 122 boundary between protocols and parameters lies: is "H.261" a 123 parameter of "RTP"? Or is "H.261/RTP" a protocol with parameters 124 such as "CIF"/"QCIF"?) 126 (class PROTOCOL 127 (attributes 128 (type SYMBOL required) ; IANA registered 129 (id BYTE-STRING required))) ; as per type 131 (class (PROTOCOL-WITH-PARAMETERS PROTOCOL) 132 (attributes 133 (parameters (LIST PARAMETER) required))) 135 (class PARAMETER 136 (attributes 137 (type SYMBOL required) ; specific to protocol type 138 (value BYTE-STRING required))) ; as per type 140 4. Information About the Local User and System 142 This section defines that part of the LASSO object tree that is not 143 immediately associated with a particular conference. 145 4.1. PRESENCE 147 A presence is used as the root of the LASSO object tree. (A presence 148 is a specific user ``logged in'' to a specific system -- this allows 149 for the possibility that the user is logged in more than once.) It 150 points to sets of capabilities/preferences defined by the local host 151 and by the user, the set of running applications relevant to the 152 conferences joined by this presence, and this set of conferences. 154 (class PRESENCE 155 (attributes 156 (name STRING required) ; ID of person responsible 157 (host STRING required) ; local host 158 (number INTEGER required)) ; number of presence on local host 159 (subtree 160 (host LOCAL-HOST required) ; capabilities intrinsic to host 161 (user LOCAL-USER required) ; capabilities specific to user 162 (applications (LIST APPLICATION) required) ; locally running apps 163 (conferences (LIST CONFERENCE) required))) ; current conferences 165 4.2. LOCAL-USER 167 The information locally available about a user is that of the type 168 USER, augmented by a set of applications that this user generally 169 wants to have running, a set of preferences among applications that 170 can handle a particular protocol, and a set of applications this user 171 has installed separately from the per-host information (~/bin style). 173 (class (LOCAL-USER USER) 174 (subtree 175 (initialize (LIST LOCAL-APPLICATION) required) ; apps always wanted 176 (preferences (LIST PREFERENCE) required) ; proto-to-app mappings 177 (applications (LIST APPLICATION-DESCRIPTION) required))) ; available 179 (class PREFERENCE 180 (attributes 181 (protocols (LIST PROTOCOL-WITH-PARAMETERS) required) 182 (application-list (LIST (REFERENCE APPLICATION-DESCRIPTION)) required) 183 ; applications, most preferred first 184 )) 186 (class APPLICATION-DESCRIPTION 187 (attributes 188 (name STRING required) ; "NanoFirm Paragraph against Doors" 189 (version STRING required) ; "3.14159" 190 (invocation STRING required) ; pathname used for invoking 191 (parameter-spec PARAMETER-SPEC required) ; .sd.tcl (if H.261 "-pH261") 192 (protocols (LIST PROTOCOL) required))) ; protocols this app supports 194 4.3. HOST, LOCAL-HOST, INTERFACE, DEVICE 196 Information on a host includes its hostname, a set of interfaces 197 available for networking (details to be defined -- e.g., ISDN/H.320 198 vs. IP vs. both), and a set of devices that could be useful in a 199 multimedia conference (examples are given for cameras and speakers). 201 (class HOST 202 (attributes 203 (hostname STRING required)) ; /host/hostname == /.host 204 (subtree 205 (interfaces (LIST INTERFACE) required) ; network attachments 206 (devices (LIST DEVICE) required))) ; hardware capabilities 208 The information available locally on a host generally includes a set 209 of descriptions of installed applications. 211 (class LOCAL-HOST HOST) 212 (subtree 213 (applications (LIST APPLICATION-DESCRIPTION) required))) ; sw caps 215 A host may have a number of network interfaces of various kinds. IP 216 interfaces, in particular, have an address and can be classified as 217 to their approximate bandwidth. 219 (class INTERFACE 220 (attributes 221 (type SYMBOL virtual))) 223 (class IP-INTERFACE 224 (attributes 225 (type SYMBOL "IP") 226 (address BYTE-STRING required) 227 (bandwidth BANDWIDTH optional))) 229 (class BANDWIDTH 230 (attributes 231 (type SYMBOL virtual))) 233 A host may have a number of devices of interest in a conference 234 setting. Each of the possible kinds of devices has some specific 235 attributes, of which two examples are given here. 237 (class DEVICE 238 (attributes 239 (type STRING virtual) ; defined in derived class 240 (system-handle STRING required))) ; "/dev/audio0" "host:0" etc. 242 (class (SPEAKERS DEVICE) 243 (attributes 244 (type STRING "audio-out") 245 (stereo BOOLEAN required))) 247 (class (CAMERA DEVICE) 248 (attributes 249 (type STRING "video-in") 250 (color BOOLEAN required))) 252 4.4. APPLICATION 254 Information on a running application includes information on the kind 255 of application and information on how to address this application. 257 (class (APPLICATION APPLICATION-DESCRIPTION APPLICATION-ADDRESS)) 259 5. Information about Conferences 261 5.1. CONFERENCE 263 Conferences are the focal point of LASSO. They have a human-readable 264 name, an ID, various attributes, are based on a conference profile, 265 have a defined list of members, involve resources (defined key-value 266 relationships), can be described by global capabilities, and in 267 particular are structured into groups of media agents (applications). 269 (class CONFERENCE 270 (attributes 271 (name STRING required) 272 (conference-id BYTE-STRING required) 273 (me (REFERENCE MEMBER) optional) ; required when I'm in the conference 274 (locked BOOLEAN optional) ; no additional members allowed 275 (listed BOOLEAN optional) ; conference is being announced 276 (security CONFERENCE-SECURITY optional)) 277 (subtree 278 (profile PROFILE required) 279 (members (LIST MEMBER) required) 280 (resources (LIST RESOURCE) required) 281 (global-caps (LIST CAPABILITY) required) 282 (appl-groups (LIST APPLICATION-GROUP) required))) 284 A resource is something that can be allocated, identified by a name 285 (or a set of other attributes). It is intended that the fact that a 286 resource was allocated is known throughout the conference (e.g. for 287 locking a resource). RESOURCE itself is a virtual class (which is 288 extended per kind of usage). 290 (class RESOURCE 291 (attributes 292 (type SYMBOL virtual) 293 (key BYTE-STRING required))) 295 The conference security attributes need to be defined. 297 (class CONFERENCE-SECURITY 298 (attributes 299 (type SYMBOL virtual))) 301 5.2. PROFILE 303 The conference profile is the static, reusable part of the conference 304 state (generally defined prior to a conference). 306 (class PROFILE 307 (attributes 308 (name STRING required) 309 (conductible BOOLEAN default false) 310 (terminates-when-empty BOOLEAN default true) 311 (security CONFERENCE-SECURITY optional)) 312 ; privilege lists etc. 313 (subtree 314 (agenda (LIST STRING) optional) 315 (documents (LIST CONTRIBUTION) optional) 316 (roles (LIST ROLE) required) 317 (rules (LIST RULE) required))) 319 Roles classify the participants of a conference. Each role is 320 associated with a set of permissions and a set of users that can take 321 on that role. 323 (class ROLE 324 (attributes 325 (name SYMBOL required) 326 (description STRING required) ; human-readable 327 (permissions (LIST PERMISSION) optional) 328 (members (LIST USER) optional))) 330 (class PERMISSION 331 (attributes 332 (name SYMBOL required))) ; symbolic name for permission 334 Rules define the way specific decisions are made. A CONDUCTOR-RULE 335 means that the chairperson of a conference simply can make that 336 particular decision, while a QUORUM-RULE requires a vote from the 337 members (at least from those wielding a particular permission). 339 (class RULE 340 (attributes 341 (name SYMBOL required) 342 (voting-type SYMBOL virtual))) 344 (class (CONDUCTOR-RULE RULE) 345 (attributes 346 (voting-type SYMBOL fixed "conductor"))) 348 (class (QUORUM-RULE RULE) 349 (attributes 350 (voting-type SYMBOL fixed "majority") 351 (required-permission SYMBOL optional) ; e.g. "rep" so guests can't vote 352 (acceptance-percentage RATIONAL required))) 354 5.3. APPLICATION-GROUP 356 An APPLICATION-GROUP contains information for a set of peer media 357 agents. 359 (class APPLICATION-GROUP 360 (attributes 361 (protocol PROTOCOL-WITH-PARAMETERS required) 362 (context (LIST PARAMETER) required)) ; common application parameters 363 (subtree 364 (per-member (LIST APP-PER-MEMBER) required))) 366 (class APP-PER-MEMBER 367 (attributes 368 (member (REFERENCE MEMBER) required) 369 (contact APPLICATION-ADDRESS required) 370 (caps (LIST CAPABILITY) required))) 372 (class APPLICATION-ADDRESS 373 (attributes 374 (type SYMBOL virtual))) 376 (class (INTERNET-APPLICATION-ADDRESS APPLICATION-ADDRESS) 377 (attributes 378 (type SYMBOL fixed "IP/PORT") 379 (ip-address BYTE-STRING required) 380 (port INTEGER required))) 382 5.4. MEMBER 384 An object of type MEMBER represents a presence within a conference. 386 (Note the the current definition has a major shortcoming: a presence 387 may actually represent a set of human beings.) 389 (class (MEMBER USER) 390 (attributes 391 (note STRING optional) ; "out to lunch" (cf. RTCP) 392 (contributions (LIST CONTRIBUTION) optional) 393 (roles (LIST SYMBOL) required)) ; conductor, guest, proponent... 394 (subtree 395 (host CONFERENCE-HOST required) 396 (caps (LIST CAPABILITY) required))) 398 (class (CAPABILITY PROTOCOL-WITH-PARAMETERS)) 399 ; same structure, but additional types allowed... 401 (class CONTRIBUTION ; document "brought to the meeting" 402 (attributes 403 (name STRING required) ; id / reference / description 404 (uri STRING optional))) ; obtain where? 406 (class (CONFERENCE-HOST HOST) 407 (attributes 408 (type (LIST SYMBOL) required))) ; end-system, mixer, translator, etc. 410 6. Security Considerations 412 This memo does not define any access control that may be required on 413 elements of the session state. This needs to be done in the context 414 of a conference policy. 416 7. Authors' Addresses 418 Carsten Bormann Joerg Ott 419 Universitaet Bremen FB3 MZH 5180 Technische Universitaet Berlin FR 6-3 420 Postfach 330440 Franklinstr. 28/29 421 D-28334 Bremen D-10587 Berlin 422 GERMANY GERMANY 423 cabo@informatik.uni-bremen.de jo@cs.tu-berlin.de 425 Appendix: T.120 Support 427 This appendix defines a few classes that could be used to maintain 428 T.120 specific information. This is done by defining additional 429 derived classes that inherit from the classes defined in the main 430 body of this document. 432 (class (T-120-CONFERENCE CONFERENCE) 433 (attributes 434 (superior-name STRING optional) 435 (superior-modifier STRING optional) 436 (local-name STRING optional) 437 (local-modifier STRING optional) 438 (modifier STRING required) 439 (domain-name STRING required))) 441 (class (T120-TOKEN RESOURCE) 442 (attributes 443 (type SYMBOL fixed t120-token) 444 (token INTEGER required))) 446 (class (T120-CHANNEL RESOURCE) 447 (attributes 448 (type SYMBOL fixed t120-channel) 449 (channel INTEGER required))) 451 (class (T120-CONFERENCE-HOST CONFERENCE-HOST) 452 ; additional types: terminal (= end-system?), mcu, multiport-terminal 453 (attributes 454 (node-id INTEGER required) ; GCC user id of this node 455 (superior-node-id INTEGER optional) ; GCC user id of superior node 456 (alternative-node-id INTEGER optional) 457 (node-name STRING optional) ; "Bremen", equal to location??? 458 (site-information STRING optional) ; useful stuff about the site 459 (management-device BOOLEAN required) ; has mgmt function 460 (peripheral-device BOOLEAN required))) ; subordinate to other device??? 462 (class (T120-APPLICATION-ADDRESS APPLICATION-ADDRESS) 463 (attributes 464 (type SYMBOL fixed "MCS-SMC") 465 (single-member-channel INTEGER required))) 467 Appendix: SDP Support 469 This appendix defines additional attributes of the session state 470 elements based on attributes defined in the SDP protocol. [This 471 needs to be completed.] 473 An SDP-announced conference has additional attributes, which here are 474 attached to a class derived from CONFERENCE. Some of these 475 attributes may be PROFILE attributes, instead. 477 (class (SDP-CONFERENCE CONFERENCE) 478 (attributes 479 (address MULTICAST-ADDRESS required) 480 ; strictly speaking, this address is only a default for the media 481 ; and simply should be required there 482 (creator USER required) 483 (version NUMBER required) 484 (creating-host HOST required) 485 (description STRING optional) 486 (uri STRING optional) 487 (time STRING optional) ; zero or more times 488 (repeat-spec STRING optional) 489 (bandwidth BANDWIDTH optional) 490 (attributes (LIST PARAMETER) optional))) 492 SDP defines the ``k='' attribute, which is a kind of CONFERENCE- 493 SECURITY. 495 (class (SDP-K-CONFERENCE-SECURITY CONFERENCE-SECURITY) 496 (attributes 497 (type SYMBOL fixed "FIXED-DES-ENCRYPTION") 498 (key BYTE-STRING required))) 500 The conference bandwidth is a special kind of bandwidth value. 502 (class (CT-BANDWIDTH BANDWIDTH) 503 (attributes 504 (type SYMBOL fixed "CT") 505 (value NUMBER required))) 507 Addressing for IP multicasting generally is per-media. 509 (class (MULTICAST-ADDRESS ADDRESS) 510 (attributes 511 (type SYMBOL virtual))) 513 (class (IPV4-MULTICAST-ADDRESS ADDRESS) 514 (attributes 515 (type SYMBOL fixed "IP4") 516 (ip BYTE-STRING required) 517 (ttl NUMBER required))) 519 (class (MULTICAST-MEDIA PROTOCOL-WITH-PARAMETERS) 520 (attributes 521 (address MULTICAST-ADDRESS optional) ; defaults to per-conf address 522 (port NUMBER required)))