idnits 2.17.1 draft-ietf-mmusic-scip-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-03-28) 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. ** Expected the document's filename to be given on the first page, but didn't find any ** 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 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 2 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 384 has weird spacing: '... by the calle...' == Line 753 has weird spacing: '...Subject i...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (February 22, 1996) is 10262 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) -- Missing reference section? '1' on line 801 looks like a reference -- Missing reference section? '2' on line 805 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force MMUSIC WG 3 Internet Draft Schulzrinne 4 ietf-mmusic-scip-00.txt GMD 5 February 22, 1996 6 Expires: 8/1/96 8 Simple Conference Invitation Protocol 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as ``work in progress''. 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Distribution of this document is unlimited. 30 ABSTRACT 32 The conference invitation protocol (SCIP) is an 33 application-level protocol for inviting users to 34 multimedia conferences. Network users are identified by 35 their universal communication identifier, usually their 36 electronic mail address. SCIP offers personal mobility by 37 supporting forwarding and redirection. It can reuse the 38 general email infrastructure, including DNS MX records, 39 mailing lists and aliases. The protocol combines aspects 40 of HTTP and SMTP and can re-use their security mechanism. 41 The protocol is extensible in methods and parameters and 42 is designed to allow interoperation with ITU-T T.124 43 (Generic Conference Control). Extension to VCR-control 44 are possible as well. The protocol supports both loose 45 and tight conference styles. 47 1 Introduction 49 1.1 Purpose 51 The conference invitation protocol allows users to invite other users 52 as well as automatic applications to point-to-point or multicast 53 conferences. It provides extensions 55 1.2 Requirements 57 This document uses the same words as RFC 1123 for defining the 58 significance of each particular requirement. These words are: 60 must: This word or the adjective "required" means that the item is an 61 absolute requirement of the specification. 63 should: This word or the adjective "recommended" means that there may 64 exist valid reasons in particular circumstances to ignore this 65 item, but the full implications should be understood and the 66 case carefully weighed before choosing a different course. 68 may: This word or the adjective "optional" means that this item is 69 truly optional. One implementation may choose to include the 70 item because a particular application requires it or because it 71 enhances the product, for example, another implementation may 72 omit the same item. 74 An implementation is not compliant if it fails to satisfy one or more 75 of the must requirements for the protocols it implements. An 76 implementation that satisfies all the must and all the should 77 requirements is said to be "unconditionally compliant"; one that 78 satisfies all the must requirements but not all the should 79 requirements for its protocols is said to be "conditionally 80 compliant". 82 1.3 Terminology 84 This specification uses a number of terms to refer to the roles 85 played by participants in SCIP communications. The definitions of 86 client, server and proxy are similar to those used by HTTP. 88 Calling party: The party initiating a conference invitation. Note 89 that the calling party does not have to be the same as the one 90 creating a conference. 92 Called party: The person or service that the calling party is trying 93 to invite to a conference. 95 Conference: A logical grouping of several sessions. A conference is 96 identified by a globally unique conference identifier. 98 Conference member: The union of all session members. 100 Client: An application program that establishes connections for the 101 purpose of sending requests. Clients may or may not interact 102 directly with a human user. 104 Session member: A member of a session, either an application used by 105 a human or a support tool of some kind (e.g., a video recorder). 107 Server: An application program that accepts connections in order to 108 service requests by sending back responses. A server interacts 109 with the called user agent to determine whether to accept a 110 call. 112 Session: A single media, identified by a common media identifier. In 113 a multicast setting, each session has a single multicast 114 address. 116 Proxy: An intermediary program which acts as both a server and a 117 client for the purpose of making requests on behalf of other 118 clients. Requests are serviced internally or by passing them, 119 with possible translation, on to other servers. A proxy must 120 interpret, and, if necessary, rewrite a request message before 121 forwarding it. 123 [calling] user agent: The client application which initiates a 124 request. 126 Any given program may be capable of acting both as a client and a 127 server. A typical multimedia conference controller would act as a 128 client to initiate calls or invite others to conferences and as a 129 server to accept invitations. However, since a server should be 130 reachable even if the conference controller is not running, server 131 and conference controller may well be separate. The protocol between 132 server and conference controller is a local matter, but SCIP itself 133 may be used for implementation efficiency. In that case, the 134 conference controller may well initiate a connection to the server 135 after being started by the server. The issues are somewhat similar to 136 the separation of MUA and MTA on a local host, with the added 137 difficulty that synchronous communication is needed. (TBD: move this 138 section?) 140 1.4 Overall Operation 142 The protocol can be used to either initiate a two-party multimedia 143 call, similar to a phone call, to an invidual or to invite an 144 individual to a multicast conference. Except for using unicast or 145 multicast network addresses in the media description, there is no 146 difference in protocol operation or end system behavior. Conferences 147 may take place immediately or in the future. The protocol can convey 148 information about conferences that repeat a determinate or 149 indeterminate number of times. The protocol can also "invite" a 150 recorder to a conference and thus serve as a control mechanism for 151 accessing media-on-demand services. 153 The SCIP protocol is based on HTTP and employs many of its concepts, 154 data types, and protocol operations. The protocol is designed so that 155 it could share a single server with HTTP, although that is usually 156 not desirable. 158 The called party is identified by its electronic mail (RFC 822) 159 address. It is also possible that the UCI differs from the (primary) 160 electronic mail address, but this is not recommended. The domain 161 named in the UCI should also accepts SMTP connections, but may simply 162 forward them to a regular electronic mail exchange. 164 The caller contacts the server, located according to Section 1.4.1, 165 with a call request. The request contains information about the 166 originator, subject and urgency of the call and, typically for 167 conferences, the anticipated duration. For conferences, out-of-band 168 contact information such as email addresses, phone numbers or URIs 169 may also be offered. The call request indicates the desired media, 170 together with their encoding and network parameters such as the 171 unicast or multicast address, protocol type and port number. 173 The callee may either accept the call, forward the call or reject the 174 call. When accepting a call, the called party returns a subset of the 175 media listed in the Accept field of the request, namely those media 176 it is prepared to receive. The called party must not generate any 177 media types not listed in the Accept field. If several parties are 178 being invited in parallel, a second round of negotiation may be 179 needed. For large-scale conferences, a separate, multicast-based 180 negotiation protocol may be preferable, but has not been specified. 181 When rejecting a call, the server may offer a reason or a time to 182 call back at (using the Retry-After field). 184 If the called server runs on a mail exchange host, the called user 185 will likely not be reachable on that host. Rather, that server will 186 use a local mechanism to locate the user within the local 187 environment. This local mechanism is beyond the scope of this 188 specification; examples include multicast queries, user registration 189 services or use of active badges. The server may also map a user name 190 to a temporary IP address to address the common situation of users 191 connected to the Internet by a modem. A server can operate in 192 redirect or proxy mode. In redirect mode, the server returns a status 193 code and header fields indicating a possible current location of the 194 called party. In proxy mode, the server maintains the incoming SCIP 195 connection while it establishes new client SCIP connection to the 196 intended called party. It then simply forwards the response of the 197 called to the caller. A caller should cache the current location of 198 the called party so that it can short-circuit the lookup process for 199 future calls. There is no indication of lifetime (say, via an Expires 200 header), since user behavior is unpredictable. 202 As in HTTP, the called server closes the connection. There is a 203 keep-alive mechanism that allows the client to request that the 204 server maintain the connection. This can be used for tight conference 205 control and T.120 interoperation. However, it is also possible to 206 request conference parameter changes even when the initial connection 207 was torn down after call acceptance by establishing a new connection. 209 A forwarding or name resolution may yield more than one name, for 210 example, when expanding a mailbox using SMTP EXPN. The user agent 211 should offer a choice of "reach first" or "reach all". In the "reach 212 first" case, the caller tries each UCI in turn, only the first one 213 accepts the call. In the "reach all" case, the client tries to invite 214 as many as possible. It may do this either in parallel or 215 sequentially. (It may be useful to describe UCIs, similar to the 216 HTTP/1.1 URI field, for example, to indicate, for example, several 217 departments within an organization or the language-abilities of 218 different possible parties.) Note that while a response may indicate 219 several UCIs, a single SCIP request can only act on a single UCI. 221 In a multiprocess operating system, a single server per host will 222 typically be running continuously as a priviledged process. For 223 incoming calls, the server can either determine the call disposition 224 automatically, based on some user-specified rules, or signal to the 225 user an incoming call, e.g. through an acoustic signal or a pop-up 226 window. If the called party accepts the call, the server then starts 227 the necessary conferencing applications and passes the parameters 228 conveyed by the call request to them. 230 1.4.1 Resolving Addresses 232 A client implementing the SCIP protocol should follow the following 233 steps in locating a server belonging to the callee address. For 234 brevity, the action "check if valid server" implies attempting to 235 connect to the address at the service TCP port. If the connection 236 attempt succeeds, the sequence is aborted. 238 o Strip the domain part from the addr-spec. 240 o If a location has been cached for this UCI, check if called 241 party is present there. 243 o If the domain has a DNS A record, check if valid server. 245 o If the domain has a DNS SRV resource record [1], check if 246 valid server. 248 o If the domain has a DNS MX record, check (in order of MX 249 preference) if one of the records points to a valid server. 251 Note that this procedure makes it possible to have a SCIP-only server 252 (i.e., one not acting as an MTA) by simply adding it as an MX record, 253 usually with lower priority than a true MTA. Mail delivery will 254 simply skip the SCIP-only server, just as SCIP will skip any non-SCIP 255 mail exchange hosts. 257 If the procedure above does not yield a SCIP server or if the user 258 name is not recognized by a SCIP server, a client should attempt to 259 contact the mail transfer agent for the same domain using SMTP and 260 expand the name using the SMTP EXPN and VRFY commands. If EXPN yields 261 more than one name, the client should treat this as a group call and 262 contact all list members in the manner described above. The client 263 should contact list members in parallel. A client may limit the 264 number of parallel connection attempts; a user agent acting a client 265 may request confirmation if the number of addresses exceeds a given 266 threshold. SMTP expansion can be used to offer the service of life- 267 long UCIs, without actually handling calls. 269 If all attempts to contact a SCIP server fail, a user agent may 270 attempt to send a MIME message to the address, with content type 271 message/cip 273 2 Notational Conventions and Generic Grammar 275 2.1 Augmented BNF 277 See RFC HTTP 1.1, Section 2.1. 279 2.2 Basic Rules 281 See RFC HTTP 1.1, Section 2.2. The attribute-value bag is not used. 283 phone-number = E123 / phrase "<" E123 ">" / E123 comment 284 E123 = "+" country-code (SPACE / "-") 285 1*(DIGIT / "A" / "B" / "C" / "D" / 286 "#" / "*" / "." / "-") 288 country-code = 1*3 DIGIT 289 time = rfc1123-date / hex-time 290 hex-time = *HEX ; time in seconds since 1 Jan 1900 292 3 Protocol Parameters 294 3.1 Product Tokens 296 See HTTP/1.1, Section 3.8. 298 3.2 Universal Communication Identifiers 300 SCIP defines universal communication identifiers (UCIs) as a 301 generalization of mailboxes according to RFC 822. UCIs can be used 302 for electronic mail or interactive communications. UCIs have the 303 format of RFC 822 addr-specs, possibly with some extensions. 305 TBD: Possibly affix port number (with :port) to allow user-space 306 implementations and sharing of HTTP servers? 308 A special form of UCI is an E.164 international telephone number, 309 written as a numeric string preceded by a plus-sign, followed by the 310 country code. A phone number may contain the digits 0 through 9, the 311 letters A through D, the star (ASCII 0x2A) and the pound sign (ASCII 312 0x23). A E.164 UCI may employ the ASCII period "." (ASCII 0x2E) or 313 dash "-" (ASCII 0x2D) for grouping. These are ignored when 314 processing. An application may either directly dial this telephone 315 number through a local computer-telephony interface, establish a 316 phone-call through a locally-configured LAN-telephony gateway or 317 offer the user the number for manual dialing through an appropriate 318 interface. It is the responsibility of the computer-telephony 319 interface or gateway to translate the number to a number that is 320 valid at the origination point of the telephone call, e.g., by 321 removing the country code and prefixing the remainder with any long- 322 distance access code, or dialing the appropriate international access 323 code. (Note: Implementation of the full AT modem dial commands such 324 as pauses or choosing between tone and pulse dialing is not useful, 325 since dialing conventions will differ from location to location.) 326 E.140 telephone numbers can be easily distinguished from mailboxes by 327 the presence of the leading plus sign and the absence of the at-sign. 328 (TBD: Can a mailbox start with a +?) 330 3.3 UCIs as Uniform Resource Identifiers 332 Since UCIs are meant as universal identifiers for both synchronous 333 and asynchronous communications, SCIP reuses the mailto URI scheme 334 (see Section XX, RFC 1738). It is suggested that the mailto URI be 335 extended to encompass telephone numbers as well. The user interface 336 of browsers implementing SCIP should offer the user the choice of 337 either sending electronic mail or trying to establish real-time 338 communication. 340 Since the number of parameters and the total length of a typical 341 conference description is large, it is recommended to use a http or 342 ftp or similar scheme to retrieve an object of type message/scip, 343 defined in Appendix A. It is also possible to use the "data" URI 344 scheme [2] to convey information of type message/cip 346 4 SCIP Message 348 SCIP headers may be folded as described in RFC 822. 350 5 Request 352 A request from a client to a server includes, within the first line 353 of that message, the method to be applied to the UCI, the identifier 354 of the called party, and the protocol version in use. (Note: there is 355 no need for a HTTP/0.9 backward compatible request.) 357 Request-Line = method SP UCI SP "SCIP/1.0" CRLF 359 5.1 Method 361 6 Response 363 A server returns a response message to a request. 365 Response = Status-Line 366 *(General Header / 367 Response header) 368 CRLF 369 Status-Line = SCIP-Version SP Status-code SP Reason-phrase CRLF 371 An example: 373 SCIP/1.0 302 Moved Temporarily 374 Location: secretary@westwing.whitehouse.gov 375 Location: security@eastwing.whitehouse.gov 377 7 Method Definitions 379 For T.124 compatibility, additional methods will be defined in the 380 future. 382 7.1 CALL 384 Call the user identified by the called-UCI. 386 7.2 CHANGE 388 Change parameters of the conference. 390 7.3 CLOSE 392 Close the conference. 394 8 Status Code Definitions 396 8.1 Informational (1xx) 398 Currently, no 1xx type status codes are defined for SCIP. The HTTP 399 codes 100 (Continue) and 101 (Switching Protocols) are not 400 applicable. Progress indication such as "ringing" may be useful. 402 8.2 Successful (2xx) 404 The HTTP status codes 201 (Created), 202 (Accepted), 203 (Non- 405 Authoritative Information), 204 (No Content), 205 (Reset Content), 406 206 (Partial Content) are not applicable and must not be sent in 407 response to a SCIP method. 409 8.2.1 200 OK 411 The request has succeeded. The information returned with the response 412 depends on the method used in the request: 414 CALL The call has been accepted by the called party. 416 8.3 Redirection 3xx 418 8.3.1 301 Moved Permanently 420 The user identfied by the UCI has moved permanently and any future 421 calls should be to the new UCI returned in the Location field. If a 422 user may be at several locations, several Location fields may be 423 returned, with the client then trying to contact the new locations in 424 turn or in parallel. (HTTP only allows one Location field.) 426 8.3.2 302 Moved Temporarily 428 The user identified by the UCI has moved 430 8.4 Caller Error 4xx 432 The 4xx class of status codes is intended for cases in which the 433 client (caller) seems to have erred. Status codes 400 (Bad Request), 434 401 (Unauthorized), 402 (Payment Required), 403 (Forbidden), 404 (Not 435 Found), 405 (Method Not Allowed), 406 (None Acceptable), 408 (Request 436 Timeout), 410 (Gone) have the same interpretation as for HTTP, with 437 URI replaced by UCI. 439 8.5 Callee Error 5xx 441 The 5xx class of status codes indicates that the server is incapable 442 of completing the request. The codes 500 (Internal Server Error), 501 443 (Not Implemented), 502 (Bad Gateway), 503 (Service Unavailable), 504 444 (Gateway timeout) are to be interpreted in the same way as in HTTP 445 1.1, except that URI is to be replaced by UCI. Busy conditions, i.e., 446 where the called party indicates she does not wish to receive calls, 447 or a busy signal from a telephony gateway, are indicated by status 448 code 503. If known, a Retry-After field can give an indication when 449 a new call may succeed. 451 9 Header Field Definitions 453 9.1 Accept 455 Accept = "Accept" ":" #( 456 media-range 457 [";" "ttl" "=" ttl-value] 458 [";" "addr" "=" net-address] 459 [";" "cbw" "=" bandwidth] 460 [";" "bw" "=" bandwidth] 461 [";" "key" "=" encryption-key] 462 [";" "id" "=" media-id] 463 [";" "i" "=" information] 464 [";" "tp" "=" ("rtp" / other-transport-protocol)] 465 [";" "pt" "=" payload-type] 466 [";" "dir" "=" "sendonly" / "recvonly" / 467 "hduplex" / "fduplex"] 468 ) 469 media-range = type "/" (subtype / "*") 470 type = ("audio" / "video" / "application") 471 subtype = (audio-enc ["." sr "." ch]) / video-enc / application) 472 net-address = [(host / multicast-address)] [":" port] 473 sr =