idnits 2.17.1 draft-ietf-mmusic-mbus-transport-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 (2024-04-25) 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) 2024 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 a Security Considerations section. ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 27 characters in excess of 72. ** The abstract seems to contain references ([9]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 148 has weird spacing: '...em'' as a sy...' == Line 149 has weird spacing: '...onym for ``h...' == Line 150 has weird spacing: '...ves one parti...' == Line 396 has weird spacing: '...llowing relia...' == Line 397 has weird spacing: '... of the imple...' == (3 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (August 1998) is 9385 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) -- Looks like a reference, but probably isn't: 'MBUS' on line 790 ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '2') ** Obsolete normative reference: RFC 1521 (ref. '3') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) == Outdated reference: A later version (-03) exists of draft-ietf-mmusic-confarch-00 -- Possible downref: Normative reference to a draft: ref. '4' ** Obsolete normative reference: RFC 1889 (ref. '5') (Obsoleted by RFC 3550) == Outdated reference: A later version (-12) exists of draft-ietf-mmusic-sip-07 ** Obsolete normative reference: RFC 2327 (ref. '7') (Obsoleted by RFC 4566) -- No information found for draft-ietf-mmusic-mbus-semantics - is the name correct? -- Possible downref: Normative reference to a draft: ref. '9' Summary: 16 errors (**), 0 flaws (~~), 10 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT J. Ott/C. Perkins/D. Kutscher 3 Expires: February 1999 Universitaet Bremen/UCL/Universitaet Bremen 4 August 1998 6 A Message Bus for Conferencing Systems 7 draft-ietf-mmusic-mbus-transport-00.txt 9 Status of this memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Distribution of this document is unlimited. 29 Abstract 31 In a variety of scenarios, a local communication channel is desirable 32 for conference-related information exchange between co-located but 33 otherwise independent application entities, for example those taking 34 part in application sessions that belong to the same conference. 35 Such a mechanism allows for coordination of applications entities to 36 e.g. implement synchronization between media streams or realize 37 tightly coupled conferences. The local conference Message Bus (Mbus) 38 provides a means to achieve the necessary amount of coordination 39 between co-located conferencing applications for virtually any type 40 of conference. The Message Bus comprises two logically distinct 41 parts: a message transport and addressing infrastructure and a set of 42 common as well as media tool specific messages. This documents deals 43 with message addressing, transport, and security issues and defines 44 the message syntax for the Mbus. It does not define application 45 oriented semantics and procedures for using the message bus. The 46 common procedures for Mbus operation as well as the common set of 47 application/media specific messages are introduced in a companion 48 Internet draft[9]. 50 This document is intended for discussion in the Multiparty Multimedia 51 Session Control (MMUSIC) working group of the Internet Engineering 52 Task Force. Comments are solicited and should be addressed to the 53 working group's mailing list at confctrl@isi.edu and/or the authors. 55 1. Introduction 57 1.1. Background 59 In the Mbone community a model has arisen whereby a set of loosely 60 coupled tools are used to participate in a conference. A typical 61 scenario is that audio, video and shared workspace functionality is 62 provided by three separate tools (although some combined tools 63 exist). This maps well onto the underlying RTP [5] (as well as 64 other) media streams, which are also transmitted separately. Given 65 such an architecture, it is useful to be able to perform some 66 coordination of the separate media tools. For example, it may be 67 desirable to communicate playout-point information between audio and 68 video tools, in order to implement lip-synchronisation, to arbitrate 69 the use of shared resources (such as input devices), etc. 71 A refinement of this architecture relies on the presence of a number 72 of media engines which perform protocol functions as well as 73 capturing and playout of media. In addition, one (or more) 74 (separate) user interface agents exist that interact with and control 75 their media engine(s). Such an approach allows flexibility in the 76 user-interface design and implementation, but obviously requires some 77 means by which the various involved agents may communicate with one 78 another. This is particularly desirable to enable a coherent 79 response to a user's conference-related actions (such as joining or 80 leaving). 82 Although current practice in the Mbone community is to work with a 83 loosely coupled conference control model, situations arise where this 84 is not appropriate and a more tightly coupled wide-area conference 85 control protocol must be employed (e.g. for IP telephony). In such 86 cases, it is highly desirable to be able to re-use the existing tools 87 (media engines) available for loosely coupled conferences and 88 integrate them with a system component implementing the tight 89 conference control model. One appropriate means to achieve this 90 integration is a communication channel that allows a dedicated 91 conference control entity to ``remotely'' control the media engines 92 in addition to or instead of their respective user interfaces. 94 The Message Bus defined in this and a companion document provides a 95 suitable means for local communication that serves all of the above 96 purposes. 98 1.2. Purpose 100 Two components constitute the Message Bus: the (lower level) message 101 passing mechanisms and the (higher level) messages and their 102 semantics. 104 The purpose of this document is to define the characteristics of the 105 basic Mbus message passing mechanism which is common to all Mbus 106 implementations. This includes the specification of 108 o the generic Mbus message format; 110 o the addressing concept for application entities; 112 o the transport mechanisms to be employed for conveying messages 113 between (co-located) application entities; 115 o the security concept to prevent misuse of the Message Bus (as 116 taking control of another user's conferencing environment); and 118 o the details of the Mbus message syntax. 120 1.3. Terminology for requirement specifications 122 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 123 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 124 and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and 125 indicate requirement levels for compliant Mbus implementations. 127 1.4. Definition of terms 129 o Conference 131 The relationship between a set of human beings that are 132 communicating together. In this document, the term is used for 133 both tightly and loosely coupled [4] computer based conferences. 135 o Participant 137 A (typically human) being that takes part in a conference. 139 o Member 141 The system, including all software and hardware components, that 142 is used in a teleconference to represent a single participant. 144 o End system 146 A host or a set of locally interconnected hosts[1] that is used 147 _________________________ 148 [1] In this document, we use the term ``end system'' as a syn- 149 onym for ``host'' in the simplest case. We do not want to ex- 150 clude, however, that the local system that serves one participant 151 may be composed of several ``hosts'' in the Internet sense. 153 as an interface to a teleconference by a single participant. 154 The end system runs all the required conferencing software (e.g. 155 media agents, session directory, and a controlling entity). End 156 system and software together constitute a member in each of the 157 conferences a user participates in. 159 o Conference controller 161 A dedicated application running on an end system that implements 162 a horizontal conference control protocol through which it 163 interacts with conference controllers on other end systems to 164 implement (typically tight) conference control mechanisms and 165 conference policies. The conference controller constitutes the 166 electronic representation of its (human) user and her actions 167 with respect to conference(s) as a whole (rather than with 168 respect to individual media sessions). 170 o UCI 172 A universal communication identifier of a person. This may be 173 the e-mail address of an individual (or some other globally 174 unique identifier) that is part of the information to identify 175 her within a conference but can also be used to invite her via 176 the Session Initiation Protocol (SIP) [6] protocol. 178 o Presence 180 A presence corresponds to a person (identified by a UCI) being 181 ``logged in'' at an end system and available for conferencing, 182 i.e. a presence may be identified by the pair of a user's UCI 183 and the respective end system's identification (such as a host 184 name). A presence of a user may appear in many conferences (see 185 below). 187 o Appearance 189 An instantiation of a user's presence actually participating 190 (i.e. appearing) in a conference is referred to as an 191 appearance. There is a one-to-one correspondence between 192 appearances and members. 194 o Conference context 196 All state information kept about a conference at each member of 197 this conference. 199 o Application session (AS), Session 201 The set of media agents/applications that act as peers to each 202 other within a conference. For real-time data, this generally 203 will be an RTP session [5]; for other application protocols, 204 other horizontal protocols may define their own type of session 205 concept. Possible synonyms are ``application group'' or ``media 206 agent group''. 208 o Application instance, application entity, media agent 210 A program instance taking part in an application session for a 211 conference participant. There can be more than one instance of 212 the same program in one session, there can also be more than one 213 instance in different sessions. 215 2. Requirements and Concepts 217 The Mbus is supposed to operate in a variety of scenarios as outlined 218 in the introduction. From these scenarios, the following (minimum) 219 requirements are derived that have to be met by the Mbus design to 220 provide a suitable local communication infrastructure. 222 Local coordination involves a widely varying number of entities: some 223 messages may need to be destined for all local application entities, 224 such as membership information, floor control notifications, 225 dissemination conference state changes, etc. Messages may also be 226 targeted at a certain application class (e.g. all whiteboards or all 227 audio tools) or agent type (e.g. all user interfaces rather than all 228 media engines). Or there may be any (application- or message- 229 specific) subgrouping defining the intended recipients, e.g. messages 230 related to media synchronization. Finally there will be messages 231 that are directed to a single entity, for example, specific 232 configuration settings that a conference controller sends to a 233 application entity or query-response exchanges between any local 234 server and its clients. 236 The Mbus concept as presented here satisfies these different 237 communication models by defining different message transport 238 mechanisms (defined in section 3.4) and by providing a flexible 239 addressing scheme (defined in section 3.2). 241 Furthermore, Mbus messages exchanged between application entities may 242 have different reliability requirements (which are typically derived 243 from their semantics). Some messages will have a rather 244 informational character conveying ephemeral state information (which 245 is refreshed/updated periodically), such as the volume meter level of 246 an audio receiver entity to be displayed by its user interface agent. 247 Certain Mbus messages (such as queries for parameters or queries to 248 local servers) may require a response from the peer(s) thereby 249 providing an explicit acknowledgment at the semantic level on top of 250 the Mbus. Other messages will modify the application or conference 251 state and hence it is crucial that they do not get lost. The latter 252 type of message has to be delivered reliably to the recipient, 253 whereas message of the first type do not require reliability 254 mechanisms at the Mbus transport layer. For messages confirmed at the 255 application layer it is up to the discretion of the application 256 whether or not to use a reliable transport underneath. 258 In some cases, application entities will want to tailor the degree of 259 reliability to their needs, others will want to rely on the 260 underlying transport to ensure delivery of the messages -- and this 261 may be different for each Mbus message. The Mbus message passing 262 mechanism described in this paper provides a maximum of flexibility 263 by providing reliable transmission achieved through transport-layer 264 acknowledgments (in case of point-to-point communications only) as 265 well as unreliable message passing (for unicast, local multicast, and 266 local broadcast). We address this topic in section 3.2. 268 Finally, accidental or malicious disturbance of Mbus communications 269 through messages originated by applications from other users needs to 270 be prevented. Accidental reception of Mbus messages from other users 271 may occur if either two users share the same workstation for 272 conferencing or are using end systems spread across the same physical 273 network: in either case, the Mbus multicast address and the port 274 numbers may match leading to reception of the other party's Mbus 275 messages in addition to a user's own ones. Malicious disturbance may 276 happen because of applications multicasting (e.g. at a global scope) 277 or unicasting Mbus messages (which could contain a "TERMINATE 278 CONFERENCE" command). To eliminate the possibility of receiving 279 bogus Mbus messages, the Mbus protocol therefore contains message 280 digests for authentication. Furthermore, the Mbus allows for 281 encryption to ensure privacy and thus enable using the Mbus for local 282 key distribution and other functions potentially sensitive to 283 eavesdropping. This document defines the framework for configuring 284 Mbus applications with regard to security parameters in appendix C 285 (Mbus configuration). 287 3. Message Bus Specification 289 3.1. Message Format 291 A conference coordination message comprises a header and a body. The 292 header is used to indicate how and where a message should be 293 delivered, the body provides information and commands to the 294 destination entity. The following information is included in the 295 header: 297 o The MsgDigest is a Base64-encoded[3] calculated hash value of 298 the entire message (starting from the ProtocolID field) as 299 described in appendices A (Algorithms) and C (Mbus 300 configuration). 302 o A fixed ProtocolID field identifies the version of the message 303 bus protocol used. The protocol defined in this document is 304 ``mbus/1.0''. 306 o A sequence number SeqNum is contained in each message. The first 307 message sent by a source SHOULD have SeqNum equal to zero, and 308 it SHALL increment by one for each message sent by that source. 309 A single sequence is used for all message from a source, 310 irrespective of the intended recipients and the reliability mode 311 selected. SeqNums are decimal numbers in ASCII representation. 313 o The TimeStamp field is also contained in each message and SHALL 314 contain a decimal number representing the time at message 315 construction in seconds since 00:00:00, UTC, January 1, 1970. 317 o A MessageType field indicates the kind of message being sent. 318 The value ``R'' indicates that the message is to be transmitted 319 reliably and MUST be acknowledged by the recipient, ``U'' 320 indicates an unreliable message which MUST NOT be acknowledged. 322 o The SrcAddr field identifies the sender of a message. This MUST 323 be a full address, with no wildcards present. The addressing 324 scheme is described in section 3.2. 326 o The DestAddr field identifies the intended recipient(s) of the 327 message. This field MAY contain wildcards and hence address any 328 number (including zero) of application entities. The addressing 329 scheme is described in section 3.2. 331 o The AckList field comprises a list of SeqNums for which this 332 message is an acknowledgment. See section 3.3 for details. 334 The header is followed by the message body which contains one or more 335 messages to be delivered to the destination entity. The syntax for a 336 complete message is given in section ``syntax''. 338 3.2. Addressing 340 Each entity on the message bus SHOULD respond to messages sent to one 341 (or more) addresses. Addresses are quad-tuples written as: 342 (MediaType ModuleType AppName AppInstance) 343 where one or more fields MAY be wildcarded (with `*') in some cases. 344 All fields in an address are case sensitive. 346 The MediaType element identifies the type of media processed by an 347 application. Currently defined values are: 349 audio An RTP audio stream 350 video An RTP video stream 351 whiteboard A shared whiteboard 352 editor A shared text editor 353 sap A session announcement tool, using SAP 354 sip A session invitation tool, using SIP 355 h323 An ITU-T H.323 conference controller 356 rtsp An RTSP session controller 357 control A local coordination entity 359 Other values are likely to be defined at a later date. 361 The ModuleType element defines a logical part of an application. The 362 value `ui' denotes the user-interface of an application, and the 363 value `engine' defines a media/protocol engine, and `transcoder' 364 defines a media transcoder. Other values may be defined in future. 366 The AppName element identifies the application being used (e.g.: rat, 367 vic, etc.). 369 The AppInstance element is used to distinguish several instances of 370 the same application. This is a per-instance-unique identifier, which 371 is not necessarily an integer. Many Unix applications will use the 372 process-id (PID) number, although this is not a requirement. Note 373 that if an end system is spread across several hosts, the AppInstance 374 MUST NOT be the process-id, unless e.g.. the host name or its IP 375 address are included as well. The companion draft "The Message Bus: 376 Messages and Procedures"[9] defines a bootstrap procedure ensuring 377 that entities can track the abandoning and restarting of application 378 instances as long as unique AppInstance values are being used. 380 The following examples illustrate how to make use of the addresses: 382 (audio ui rat 124) The user interface of the rat application with instance-id 124 383 (workspace ui * *) The user interfaces of all workspace applications 384 (audio * * *) All audio applications 385 (* * rat *) All instances of the rat application 387 3.3. Reliability 389 While most messages are expected to be sent using unreliable 390 transport, it may be necessary to deliver some messages reliably. 391 Reliability can be selected on a per message basis by means of the 392 MessageType field. Reliable delivery is supported for messages with 393 a single recipient only; i.e., all components of the DestAddr field 394 have to be specified, without the use of wildcards.[2] 395 _________________________ 396 [2] Disallowing reliable message delivery for messages sent to 397 multiple destinations is motivated by simplicity of the implemen- 398 tation as well as the protocol. Although ACK implosions are not 399 really an issue and losses are rare, achieving reliability for 400 such messages would require full knowledge of the membership for 401 Each message is tagged with a message sequence number. If the 402 MessageType is ``R'', the sender expects an acknowledgment from the 403 recipient within a short period of time. If the acknowledgment is 404 not received within this interval, the sender SHALL retransmit the 405 message (with the same message sequence number), increase the 406 timeout, and restart the timer. Messages SHALL be retransmitted a 407 small number of times before the recipient is considered to have 408 failed. If the message is not delivered successfully, the sending 409 application is notified. In this case, it is up to this application 410 to determine the specific action(s) (if any) to be taken. 412 Reliable messages are acknowledged by adding their SeqNum to the 413 AckList field of a message sent to the originator of the reliable 414 message. Multiple acknowledgments MAY be sent in a single message. 415 It is possible to either piggy-back the AckList onto another message 416 sent to the same destination, or to send a dedicated acknowledgment 417 message, with no other commands. 419 The precise procedures are as follows: 421 Sender: 422 A sender A of a reliable message M to receiver B SHALL transmit 423 the message via multicast or via unicast, keep a copy of M, 424 initialize a retransmission counter N to '1', and start a 425 retransmission timer T (initialized to T_r). If an 426 acknowledgment is received from B, timer T MUST BE cancelled and 427 the copy of M is discarded. If T expires, the message M SHALL 428 BE retransmitted, the counter N SHALL BE incremented by one, and 429 the timer SHALL BE restarted (set to N*T_r). If N exceeds the 430 retransmission threshold N_r, the transmission is assumed to 431 have failed, further retransmission attempts MUST NOT be 432 undertaken, the copy of M SHALL BE discarded, and the sending 433 application SHALL BE notified. 435 Receiver: 436 A receiver B of a reliable message from a sender A SHALL 437 acknowledge receipt of the message within a time period T_c 531 mbus/1.0 \ 532 534 The header fields are defined in section 3.1. 536 3.5.3. Command Syntax 538 The header is followed by zero, or more, messages to be delivered to 539 the application(s) indicated by the DestAddr field. Each message 540 comprises a command followed by a list of zero, or more, parameters, 541 and is followed by a newline. 543 command ( parameter parameter ... ) 545 The command name MUST be a `symbol' as defined in the following 546 table. The parameters MAY be any data type drawn from the following 547 table: 549 +---------+--------------------+---------------------------------+ 550 |DataType | Syntax | Description | 551 +---------+--------------------+---------------------------------+ 552 |Integer | "-"[0-9]+ | | 553 |Float | "-"[0-9]+"."[0-9]+ | | 554 |String | """...""" | See below for escape characters | 555 | | | | 556 |List | (DataType DataType | | 557 | | ...) | | 558 |Symbol | [A-Za-z0-9_-.]+ | A predefined protocol value | 559 |Data | "<"data">" | Opaque Data | 560 +---------+--------------------+---------------------------------+ 562 Boolean values are encoded as an integer, with the value of zero 563 representing false, and non-zero representing true (as in the `C' 564 programming language). 566 String parameters in the payload MUST be enclosed in the double quote 567 ('') character. Within strings, the escape character is the backslash 568 (\), and the following escape sequences are defined: 570 Opaque data is represented as Base64-encoded [3] character strings 571 surrounded by "<" and ">" 573 +----------------+-----------+ 574 |Escape Sequence | Meaning | 575 +----------------+-----------+ 576 | \\ | \ | 577 | \'' | '' | 578 | \n | | 579 +----------------+-----------+ 581 3.6. Messages 583 The specific messages applications will send using the Mbus are not 584 defined in this document. Currently a companion document[9] is 585 produced defining classes of messages which are of use in certain 586 application areas. Additional documents are expected to follow. 588 4. Author's Addresses 590 l. Joerg Ott Universitaet Bremen, TZI, MZH 5180 591 Bibliothekstr. 1 D-28359 Bremen Germany voice +49 421 201-7028 fax 592 +49 421 218-7000 594 l. Colin Perkins Department of Computer 595 Science University College London Gower Street London WC1E 6BT United 596 Kingdom 597 l. Dirk Kutscher Universitaet Bremen, TZI, MZH 5160 598 Bibliothekstr. 1 D-28359 Bremen Germany voice +49 421 218-7595 fax 599 +49 421 218-7000 601 5. References 603 [1] S. Bradner, ``Key words for use in RFCs to Indicate Requirement 604 Levels'' RFC 2119, March 1997 606 [2] H. Krawczyk, M. Bellare, R. Canetti, ``HMAC: Keyed-Hashing for 607 Message Authentication'', RFC 2104, February 1997 609 [3] N. Borenstein, N. Freed ``MIME (Multipurpose Internet Mail 610 Extensions) Part One: Mechanisms for Specifying and Describing 611 the Format of Internet Message Bodies'', RFC 1521, September 612 1993 614 [4] Mark Handley, Jon Crowcroft, Carsten Bormann, ``The Internet 615 Multimedia Conferencing Architecture,'' Internet Draft draft- 616 ietf-mmusic-confarch-00.txt, Work in Progress, February 1996. 618 [5] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, ``RTP: A 619 Transport Protocol for Real-Time Applications,'' RFC 1889, 620 January 1996. 622 [6] Mark Handley, Henning Schulzrinne, Eve Schooler, Jonathan 623 Rosennberg, ``SIP: Session Initiation Protocol'', Internet Draft 624 draft-ietf-mmusic-sip-07.txt, Work in Progress, July 16, 1998 626 [7] M. Handley, V. Jacobson, ``SDP: Session Description Protocol'', 627 RFC 2327, April 1998 629 [8] D. Meyer ``Administratively Scoped IP Multicast'', RFC 2365, 630 July 1998 632 [9] J. Ott, C. Perkins, and D. Kutscher, ``The Message Bus: Messages 633 and Procedures'', Internet Draft draft-ietf-mmusic-mbus- 634 semantics-00.txt, Work in Progress, August 1998. 636 Appendix A: Algorithms 638 Message Authentication 639 Either MD5 or SHA-1 SHALL be used for message authentication 640 codes (MACs). An implementation MAY provide SHA-1, whereas MD5 641 MUST be implemented. To generate keyed hash values the algorithm 642 described in [2] MUST be applied with hash values truncated to 643 80 bits. The resulting hash values SHALL be Base64 encoded (16 644 characters). The HMAC algorithm works with both, MD5 and SHA-1. 646 HMAC values, regardless of the algorithm, MUST therefore always 647 consist of 16 Base64-encoded characters. 649 Hash keys SHALL have a length of 96 bit, that are 20 650 Base64-encoded characters. 652 Encryption 653 Either DES, 3DES (triple DES) or IDEA SHALL be used for 654 encryption. Encryption MAY be neglected for applications, e.g. 655 in situations where license regulations, export or encryption 656 laws would be offended otherwise. However, the implementation of 657 DES is RECOMMENDED as a baseline. DES implementations MUST use 658 the DES electronic codebook (ECB) mode. Chaining modes are not 659 appropriate due to (possible) unreliable message transport. For 660 algorithms requiring en/decryption data to be padded to certain 661 boundaries ASCII code 32 SHALL be used for padding characters. 662 IDEA uses 128-bit keys (24 Base64-encoded characters). DES SHALL 663 be used with 56-bit keys (12 Base64-encoded characters). 665 The mandatory subset of algorithms that MUST be provided by 666 implementation is DES and MD5. 668 See appendix C for a specification of notations for Base64-strings. 670 Appendix B: Port allocation 672 The reserved Mbus port numbers are in the range from PORTBASE to 673 PORTBASE+(n*(m+1)) (n=number of base ports, m=reasonable maximum 674 number of conferences per presence). The first n ports are reserved 675 for base ports. The set of conference specific ports starts at offset 676 n and has a cardinality of n*m. 678 Implementations SHALL use the presence-id (see below) to calculate a 679 valid offset to the set of base port numbers for a person's presence. 680 Offsets to conference specific port numbers SHALL be obtained by 681 using the conference name. The conference name is a SDP session 682 name[7] and MUST be known in advance of port allocation. 684 Base port number calculation SHALL rely on the following algorithm: 685 All UTF-8 octets of the session name are considered for building a 686 sum of their key codes. The offset to the base port number is the 687 result of the modulo division of the sum by n (number of base ports). 689 Offsets for per-conference port numbers SHALL be calculated 690 analogously: The key codes of the presence-id's characters are summed 691 up and the the offset is obtained by adding the result of modulo 692 dividing the sum by m (number of conference ports per presence). The 693 actual port number is obtained by adding the result to 694 PORTBASE+(n*(baseport offset+1)). 696 Example: 698 PORTBASE = 2000 699 nr of base ports n= 10 700 nr of conference ports m= 6 702 session name= abc 703 presence-id= a@b.org 705 baseport offset= (97+98+99) % 10 706 = 4 707 baseport = PORTBASE + 4 708 = 2004 710 conference port offset= (97+64+99+46+111+114+103) % 6 711 = 4 712 conference port= PORTBASE + (6* (baseport offset+1)) 713 + conference port offset 714 = 2034 716 Appendix C: Mbus configuration 718 An implementation MUST be configurable by the following parameters: 720 Encryption key The secret key used for message encryption. 721 Hash key The hash key used for message authentication. 722 Presence ID The UCI of the person participating in a conference. 723 Scope The Internet scope to be used for sent messages. 725 The logical structure of the specified parameters is as follows:[3] 727 hashkey ::= algo-id expiration key 728 secretkey ::= algo-id expiration key 730 presence ::= uci 732 expiration ::= digits 734 algo-id ::= ``NOENCR'' | ``DES'' | ``3DES'' | ``IDEA'' | ``HMAC-MD5-80'' | ``HMAC-SHA1-80'' 736 scope ::= ``HOSTLOCAL'' | ``LINKLOCAL'' 738 key ::= base64string 739 uci ::= alpha 741 A Base64-String consists of the characters defined in the Base64 742 char-set [3] including all eventual padding characters, i.e. the 743 length of Base64-string is always a multiple of 4. 745 _________________________ 746 [3] syntactical definitions follow below 748 Appendix D: Parameter storage 750 Two distinct facilities for parameter storage are considered: For 751 Unix-like systems a configuration file SHALL be used and for 752 Windows-95/98/NT systems a set of registry entries is defined. 754 File based parameter storage: 756 The file name for a Mbus configuration file is ``.mbus'' in the 757 user's home-directory which MAY be overridden by an environment 758 variable called MBUS. Implementations MUST ensure that this file has 759 appropriate file permissions that prevent other users to read or 760 write it. The file MUST exist before a conference is initiated. Its 761 contents SHALL be UTF-8 encoded and SHALL be structured as follows: 763 [MBUS] 764 HASHKEY= 765 ENCRYPTIONKEY= 766 PRESENCE= 767 SCOPE= 769 A key entry MUST be in this notation: 771 ``(''algo-id``,'' expiration``,''base64string``)'' 773 algo-id is one of the character strings specified above and 774 expiration is a decimal number representing the date that the key 775 invalidates at, notated in seconds counting from 00:00:00, UTC, 776 January 1, 1970. 778 The presence-id is a universal communication identifier (UCI) for a 779 conference participant. This can be a canonical email address like 780 ``dku@tzi.org''. In case the same UCI is actually used to represent 781 different presences, e.g. to express different affiliations of a 782 person or to let different person use a single-user end-system 783 concurrently, the presence-id MAY be constituted of a UCI and a 784 presence ``modifier'' like ``dku@tzi.org#0'', ``dku@tzi.org#1'' and 785 so on. Presence-ids MUST be in the US-ASCII subset of 786 ISO-10646/UTF-8. 788 An example Mbus-configuration file: 790 [MBUS] 791 HASHKEY=(HMAC-MD5-80,946080000,MTIzMTU2MTg5MTEyMQ==) 792 ENCRYPTIONKEY=(DES,946080000,MTIzMTU2MQ==) 793 PRESENCE=dku@tzi.org 794 SCOPE=HOSTLOCAL 796 Registry based parameter storage: 798 For systems lacking the concept of a user's home-directory as a place 799 for configuration files the suggested database for configuration 800 settings (e.g. the Windows9x-, Windows NT-registry) SHALL be used. 801 The hierarchy for Mbus related registry entries is as follows:[4] 803 HKEY_CURRENT_USER\Software\Mbone Applications\Mbus 805 The entries in this hierarchy section are 807 +--------------+--------+ 808 |Name | Type | 809 +--------------+--------+ 810 |HASHKEY | String | 811 |ENCRYPTIONKEY | String | 812 |PRESENCE | String | 813 |SCOPE | String | 814 +--------------+--------+ 815 The same syntax for key values as for the file based configuration 816 facility MUST be used. 818 _________________________ 819 [4] complies with vat's registry hierarchy