idnits 2.17.1 draft-garcia-mmusic-sdp-collaboration-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 997. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1008. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1015. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1021. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (February 18, 2008) is 5906 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) ** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4572 (Obsoleted by RFC 8122) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 3023 (Obsoleted by RFC 7303) -- Obsolete informational reference (is this intentional?): RFC 4288 (Obsoleted by RFC 6838) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) == Outdated reference: A later version (-11) exists of draft-ietf-mmusic-file-transfer-mech-06 Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC Working Group M. Garcia-Martin 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Standards Track J. Ott 5 Expires: August 21, 2008 Helsinki University of Technology 6 February 18, 2008 8 Session Description Protocol (SDP) Extensions and Conventions for 9 Collaboration Applications 10 draft-garcia-mmusic-sdp-collaboration-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 21, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 The Session Description Protocol (SDP) is typically used in 44 conjunction with the Session Initiation Protocol (SIP) for 45 establishing multimedia sessions on the Internet. Typically these 46 sessions include audio, video or messaging streams. Rich 47 collaboration applications can complete these multimedia sessions, 48 including view sharing with remote manipulation, co-web browsing, and 49 file transfer.This document discusses rich collaboration between two 50 endpoints and provides conventions and extension to SDP to enable 51 these applications. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. View Sharing with Remote Manipulation Media Transport 58 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Overview of the Remote Frame Buffer (RFB) protocol . . . . 4 60 3.2. Overview of T.120 . . . . . . . . . . . . . . . . . . . . 5 61 4. Collaboration applications . . . . . . . . . . . . . . . . . . 7 62 4.1. SDP Extensions for View Sharing with Remote 63 Manipulation Applications . . . . . . . . . . . . . . . . 7 64 4.1.1. View Sharing with Remote Manipulation with RFB . . . . 7 65 4.1.2. View Sharing with Remote Manipulation with T.120 . . . 8 66 4.2. Co-Web Browsing . . . . . . . . . . . . . . . . . . . . . 10 67 4.2.1. Example of a Co-Web Browsing document . . . . . . . . 12 68 4.3. File Transfer . . . . . . . . . . . . . . . . . . . . . . 12 69 4.4. Further Sharing Applications . . . . . . . . . . . . . . . 13 70 5. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 14 71 5.1. SDP extensions . . . . . . . . . . . . . . . . . . . . . . 14 72 5.2. Co-Web browsing XML schema . . . . . . . . . . . . . . . . 14 73 5.2.1. XML Schema . . . . . . . . . . . . . . . . . . . . . . 15 74 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 77 8.1. Registration of new SDP attributes . . . . . . . . . . . . 16 78 8.1.1. Registration of the t120apps attribute . . . . . . . . 16 79 8.1.2. Registration of the confname attribute . . . . . . . . 16 80 8.2. Registration of new SDP 'proto' values . . . . . . . . . . 17 81 8.3. MIME type registration . . . . . . . . . . . . . . . . . . 17 82 8.4. URN Sub-Namespace Registration . . . . . . . . . . . . . . 18 83 8.5. XML Schema Registration . . . . . . . . . . . . . . . . . 18 84 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 86 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 87 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 89 Intellectual Property and Copyright Statements . . . . . . . . . . 23 91 1. Introduction 93 The Session Initiation Protocol (SIP) [RFC3261] is used for 94 establishing and tearing down multimedia sessions in the Internet. 95 Typically a SIP INVITE request carries an Session Description 96 Protocol (SDP) [RFC4566] offer that describes the set of media 97 streams that the caller wants to establish. The SDP offer gets 98 answered with an SDP answer, as per procedures of the SDP offer/ 99 answer model [RFC3264], and the multimedia session is eventually 100 established. A session, according to RFC 4566, is a set of 101 multimedia senders and receives and the data streams flowing from 102 senders to receivers. 104 Media descriptions in SDP are signaled in the "m=" line. Each "m=" 105 line contains a media type. SDP currently defines "audio", "video", 106 "text", "application", and "message" media types. While establishing 107 a session that contains audio, video, text, or message is straight 108 forward, there are certain media streams that cannot be established 109 without further specification. This memo tries to fill this gap. 111 Let us take a look at some use cases. Alice has already setup a 112 multimedia session with Bob and they are exchanging audio and video. 113 Then Alice requests Bob to help her setting up her computer. This is 114 sometimes called "remote assistance". In practice, the use case can 115 be implemented with a view sharing with remote manipulation protocol. 116 It is not the scope of this memo to define a new view sharing with 117 remote manipulation protocol, but instead, to re-use the rendezvous 118 capabilities that SIP and SDP provide for setting up such media 119 stream. Then Alice sends a re-INVITE request to Bob where she adds 120 the description for a view sharing with remote manipulation protocol 121 in the SDP. Once Bob accepts the session, an view sharing with 122 remote manipulation application is launched at both endpoints. They 123 exchange data over a given protocol. Then, Bob can assist Alice in 124 setting up her computer. 126 In another scenario, Alice has established a multimedia session with 127 Bob. That session includes audio and video media streams. Alice 128 would like to browse a few web pages together, essentially, share 129 with Bob the addresses of the web pages that she is visiting. This 130 is sometimes referred to as co-web browsing. 132 Another common feature in rich collaboration includes the transfer of 133 file. The file can include, for example, a screen shot, an image 134 file, a document, etc. 136 NOTE: We are looking at a few examples of sharing content between 137 two users. The list of examples and use cases might not be 138 comprehensive enough at this stage. We need to find other 139 relevant formats. 141 The rest of this document is organized as follows: Section 3 provides 142 an introduction to view sharing with remote manipulation media 143 transport protocols. Section 4 provides the procedures to describe 144 collaboration applications in SDP. Section 5 contains the format 145 syntax. 147 2. Terminology 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in BCP 14, RFC 2119 152 [RFC2119] and indicate requirement levels for compliant 153 implementations. 155 3. View Sharing with Remote Manipulation Media Transport Protocols 157 Many of the collaboration activities require some sort of view 158 sharing with remote manipulation media protocol that is able to 159 provide the required functionality. The approach taken by this memo 160 is to re-use existing view sharing with remote manipulation media 161 protocols whenever possible. On doing so, the scope is mostly 162 reduced to specify the conventions for describing view sharing with 163 remote manipulation protocols for the different use cases. 165 This section provides an overview of two set of protocols for which 166 we provide descriptions in SDP later. These are the Remote Frame 167 Buffer (RFB) protocol and ITU-T recommendation T.120 [ITU.T120.2007]. 169 3.1. Overview of the Remote Frame Buffer (RFB) protocol 171 The Remote Frame Buffer (RFB) protocol [RFB] is a simple protocol for 172 remote access to graphical user interfaces. RFB is used by Virtual 173 Network Computing (VNC) applications and their successors. It works 174 at the frame-buffer level, which roughly corresponds to the rendered 175 screen image, which means that it can be applied to a variety of 176 graphical systems. Remote Frame Buffer applications exist for many 177 platforms, and can often be freely re-distributed. 179 The protocol operates with the classical client-server architecture. 180 The application that runs on the machine where the user sits 181 (containing the display, keyboard and pointer) is called the client. 182 The application that runs on the machine where the framebuffer is 183 located (which is running the windowing system and applications that 184 the user is remotely controlling) is called the server. The client 185 accesses the remote graphical user interface and provides input 186 events (keyboard, mouse), and the server provides the screen results. 188 RFB display protocol is based on a single primitive "put a rectangle 189 of pixel data at a given x,7 position". The protocol allows 190 different encodings for the pixel data, providing a large degree of 191 flexibility in how to trade off various parameters, such as network 192 bandwidth, client drawing speed and server processing speed. 194 A sequence of rectangles makes a framebuffer update, which represents 195 a change from one valid framebuffer state to another. A sequence of 196 framebuffer updates gives the user a perception similar to video. 198 The input side of the protocol is based on a standard workstation 199 model of a keyboard an multi-button pointing device. Input events 200 are simply sent to the server b the client whenever the user presses 201 a key o pointer button, or whenever the pointing device is moved. 202 These input events can also be synthesised from other non-standard 203 input/output devices, for example, a pen-base handwriting device. 205 RFB includes a client server negotiation process that leads on the 206 agreement of the format and encoding of the pixel data. Pixel format 207 refers to the representation of individual colours by pixel values. 208 The most common pixel formats are 24-bit or 16-bit "true colour", 209 where 8-bit pixel format is typically used in scenarios with low 210 bandwidth connectivity. 212 Encoding refers to how a rectangle of pixel data is sent on the wire. 213 Every rectangle of pixel data is prefixed by a header giving the X,Y 214 position of the rectangle on the screen, the width and height of the 215 rectangle, and en encoding type which specifies the encoding of the 216 pixel data. The data itself then follows using the specific 217 encoding, for example, Raw, CopyRect, RRE, Hextile, and ZRLE. 219 RFB typically runs over TCP [RFC0793]. Once a TCP connection is 220 establish, the client-server initialization takes place, followed by 221 an authentication and authorization. Then the actual transfer of 222 framebuffer updates can take place. 224 The protocol is extensible. New encoding, new pseudo-encoding, and 225 new security types can be added when need arises. 227 3.2. Overview of T.120 229 T.120 [ITU.T120.2007] defines multipoint conferencing protocols and 230 services for data applications including whiteboard (T.126 231 [ITU.T126.2007]), file transfer (T.127 [ITU.T127.2007]), application 232 sharing (T.128 [ITU.T128.1998]), and text conversation (T.134 234 [ITU.T134.1998], T.140 [ITU.T135.2007]), among others. 236 In T.120, communication takes place in a hierarchical structure of 237 T.120 entities interconnected by T.120 connections. In the simplest 238 case, this may be just two entities interconnected via a T.120 239 connection, in a slightly more sophisticated one a single conference 240 bridge (MCU) may be used to interconnect more than two entities. 241 Each point-to-point T.120 connection uses TCP as underlying transport 242 and TPKT (RFC 1006 [RFC1006]) framing on top. Up to four TCP 243 connections may be established between any two T.120 entities to 244 provide independent flow control for different transmission 245 priorities. 247 The lowest layer above the point-to-point transport is the Multipoint 248 Communication Service (MCS) (T.122 [ITU.T122.1998] and T.125 249 [ITU.T125.1998]). The MCS defines a connection setup procedure that 250 allows to associate different transport connections with the same MCS 251 Domain and to organize the MCS "providers" in a tree structure during 252 connection setup. In the resulting tree, the MCS provides a 253 multiplex for application data (using up to 64K channels) and simple 254 means for synchronizations (tokens). 256 On top of MCS, the Generic Conference Control (GCC) [ITU.T124.2007] 257 is responsible for controlling the connection setup and their 258 association with a conference. Furthermore, GCC manages conference 259 resources, provides capability exchange, allows for floor control, 260 and provides some kind of a conference-wide registry. In GCC, 261 conferences are identified by means of an octet string that is mapped 262 to the MCS Domain identifier. GCC allows to create and destroy 263 conferences as well as to inquire for, join, and leave existing ones. 265 T.120 data applications make use of the MCS communication platform to 266 exchange information and of the GCC services to learn about each 267 others existence and to find each other. In particular, GCC's 268 capability exchange mechanism is used to discover commonly available 269 applications and their respective features (with many tiny details 270 being negotiable). 272 This memo is concerned with the definition of media stream 273 descriptions in SDP that allows two nodes to learn about their 274 respective T.120 capabilities and enable them to set up a single 275 T.120 connection. Whether a single or more TCP connections are used 276 and how those are associated if entirely left up to the respective 277 T.120 entities, as is most of the T.120-specific capability exchange. 279 4. Collaboration applications 281 4.1. SDP Extensions for View Sharing with Remote Manipulation 282 Applications 284 According to SDP [RFC4566], the media descriptions line is defined as 285 follows: 287 m= ... 289 Protocols used for view sharing with remote manipulation MUST use the 290 media type "application" in the "m=" line. Several protocols for 291 view sharing with remote manipulation are available today. We 292 provide the means to describe the Remote Frame Buffer (RFB) protocol 293 [RFB] and ITU-T T.120 [ITU.T120.2007] series of recommendations, in 294 particular, application sharing as defined by ITU-T T.128 295 [ITU.T128.1998] recommendation. Other protocols can be added at a 296 later time when need arises. 298 Both RFB and T.120 typically run over TCP [RFC0793], so, for the 299 purpose of describing an RFB or T.120 session in SDP, it is required 300 to use the TCP-based media transport extensions for SDP specified in 301 RFC 4145 [RFC4145] for negotiating which endpoint establishes the TCP 302 connection. Both protocols can also use TLS [RFC4346] as a secure 303 transport protocol. 305 4.1.1. View Sharing with Remote Manipulation with RFB 307 An application that wants to describe a session where RFB is the 308 protocol creates an SDP offer that contains a media description line 309 "m=". The media type is set to "application". The port number is 310 set to the client or server port number with the considerations 311 indicated in RFC 4145 [RFC4145]. The MUST be set to the 312 transport protocol mnemonic (e.g., "TCP") followed by a slash "/" and 313 the mnemonic "RFB". The defined values in the protocol field are 314 "TCP/RFB" for and "TCP/TLS/RFB" for TLS [RFC4346] over TCP. Since 315 RFB contains built-in negotiation mechanisms for the different 316 encodings, there is no need to signal a media format description, but 317 for compatibility issues, the SDP offerer MUST include an asterisk 318 sign "*" as a media format description at the end of the "m=" line. 319 If TCP or other connection-oriented transport is used, the SDP 320 offerer MUST add a 'setup' and 'connection' attributes as per 321 procedures of RFC 4145 [RFC4145]. 323 4.1.1.1. Example of RFB descriptions in SDP 325 The following is an example of an SDP offer for the RFB protocol: 327 v=0 328 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 329 s= 330 c=IN IP4 host.atlanta.example.com 331 t=0 0 332 m=application 42034 TCP/RFB * 333 a=setup:active 334 a=connection:new 336 Figure 1: Example of an SDP offer for setting up an RFB media stream 338 An example of an SDP answer to the above offer is: 340 v=0 341 o=bob 2890844527 2890844527 IN IP4 host.biloxy.example.com 342 s= 343 c=IN IP4 host.biloxy.example.com 344 t=0 0 345 m=application 5900 TCP/RFB * 346 a=setup:passive 347 a=connection:new 349 Figure 2: Example of an SDP answer for setting up an RFB media stream 351 4.1.2. View Sharing with Remote Manipulation with T.120 353 An application that wants to describe a session with T.120 as the 354 protocol for view sharing with remote manipulation creates an SDP 355 offer that contains a media description line "m=". The media type is 356 set to "application". The port number is set to the client or server 357 port number with the considerations indicated in RFC 4145 [RFC4145]. 358 The MUST be set to the transport protocol mnemonic (e.g., 359 "TCP"), followed by a slash "/" and the mnemonic "T120". The defined 360 protocol field values are "TCP/T120" for TCP transport and "TCP/TLS/ 361 T120" for TLS [RFC4346] over TCP. 363 4.1.2.1. T.120-specific Attributes 365 T.120 connections established within the context of an SDP offer/ 366 answer exchange may need to be associated with a SIP dialog or a SIP 367 conference. Therefore, the media-level 'confname' attribute is 368 introduced. The content of the 'confname' attribute MUST be copied 369 to the ConferenceName field used by the GCC entity. For a simple SIP 370 dialog, the 'confname' attribute SHOULD be created with the 371 concatenation of the SIP From tag, the To tag, the value of the 372 Call-ID header field. For a SIP dialog in a conference, the 373 'confname' attribute SHOULD contain the focus URI. Whenever a 374 character cannot be written according to the syntax of the 'confname' 375 attribute, that character should be percent encoded. 377 T.120 defines a number of applications. To determine from the offer/ 378 answer exchange whether or not at least the target application(s) are 379 available at a peer, the optional "t120apps" attribute is introduced. 380 If present, this attribute SHOULD contain a list of T.120 application 381 protocols supported by the respective peer. The following 382 application protocols are defined: 384 "t126": it indicates whiteboard sharing according to ITU-T T.126 385 [ITU.T126.2007]. 386 "t127": it indicates file transfer according to ITU-T T.127 387 [ITU.T127.2007]. 388 "t128": it indicates view sharing and remote manipulation 389 according to ITU-T T.128 [ITU.T128.1998]. 390 "t134": it indicates text conversation according to ITU-T T.134 391 [ITU.T134.1998]. 392 "t136": it indicates remote device control according to ITU-T 393 T.136 [ITU.T136.1999]. 394 "t137": it indicates virtual room management according to ITU-T 395 T.137 [ITU.T137.2000]. 397 The fine-grained negotiation of capabilities within these application 398 protocols is left up to the GCC operation after setup of a T.120 399 connection. 401 4.1.2.2. Example of T.120 descriptions in SDP 403 In the following example, an SDP offerer wants to set up an view 404 sharing with remote manipulation stream. 406 v=0 407 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 408 s= 409 c=IN IP4 host.atlanta.example.com 410 t=0 0 411 m=application 23093 TCP/T120 * 412 a=setup:active 413 a=connection:new 414 a=confname:623847692,789234789,78687afded278bd@example.com 415 a=t120apps:t128 417 Figure 3: Example of an SDP offer for setting up a T.120 media stream 419 4.1.2.3. SDP Offer/Answer Operation with T.120 421 An SDP offerer wishing to set up a T.120 session MUST include an m= 422 line according to Section 4.1 and include an appropriate c= line. 423 The offerer MUST apply the procedures of RFC 4145 [RFC4145] for 424 managing connection oriented protocols. The offerer MUST provide the 425 'confname' attribute as specified in Section 4.1.2.1 and SHOULD 426 include the list of supported T.120 application protocols in a 427 't120apps' attribute. 429 An SDP answerer that receives an SDP offer for setting up a T.120 430 session MUST first examine that it supports T.120 protocol indicated 431 in the 't120apps' attribute. If it does not support T.120 or does 432 not wish to use T.120 in the present communication relationship, it 433 MUST refuse the offered media stream by applying the procedures 434 specified in RFC 3264 [RFC3264] Section 6. If the answerer supports 435 T.120, it MUST validate the "confname" attribute. If no matching SIP 436 dialog or focus URI can be found, the media stream offer SHOULD be 437 refused by applying the procedures specified in RFC 3264 [RFC3264] 438 Section 6. If a matching conference is found and the "t120apps" 439 attribute is not present, the answerer MAY decide whether to accept 440 the session and proceed with the transport connection setup as per 441 RFC 4145 [RFC4145] or whether to refuse the media section. If the 442 "t120apps" attribute is present, the answerer MUST examine its 443 contents and match the applications listed by the offerer against its 444 own capabilities. If the intersection of capabilities is empty, the 445 answerer SHOULD refuse the media stream. If the intersection is not 446 empty, the answerer SHOULD return the intersecting capabilities (in 447 the order provided by the offerer) and then proceed with the 448 transport connection setup as per RFC 4145 [RFC4145]. 450 After successful establishment of a TCP connection as per RFC 4145 451 [RFC4145], the respective entities MUST proceed with the T.120 452 connection setup as defined in ITU-T T.123 [ITU.T123.2007], ITU-T 453 T.124 [ITU.T124.2007], and ITU-T T.125 [ITU.T125.1998]. 455 4.2. Co-Web Browsing 457 Co-web browsing allows endpoints in a multimedia session to visit the 458 same web pages in nearly real-time. Co-web browsing could be 459 implemented by sharing the web application, e.g., Alice could share 460 her web browser or entire screen with Bob. However, this has some 461 disadvantages. For example, since Bob is not running locally his web 462 browser, he cannot save bookmarks, acquire cookies, record history of 463 visited pages, etc. Bob might not be familiar with the exact web 464 browser that Alice is using to surf the net, the size of the font 465 might not be appropriate for Bob, or the color scheme that Alice is 466 using. In some cases a better option might be more efficient and 467 convenient to just share the URL of the page that both either Alice 468 or Bob are visiting, so that each endpoint becomes responsible for 469 independently of each other downloading the content, and for 470 rendering the web page in their respective web browser. This has 471 advantages, such as the possibility of Alice and Bob to render the 472 content in the capabilities of their browsers and according to the 473 user preferences (size of font, colors) and also according to the 474 capabilities of their devices (size of screen, number of colors of 475 the screen, bandwidth, etc.). It also allows Alice and Bob to 476 operate in their respective web browsers, such as record history, 477 save bookmarks, acquire cookies, etc. 479 We acknowledge the fact that there is no guarantee that the same 480 content is rendered equally in both web browsers. We merely try to 481 achieve an automatic mechanism that simulates the fact that a user 482 reads out or spells a URL, or copies the URL in a text messaging 483 windows, sends it to the remote user, which also copies the URL and 484 pastes it in their browser. If exact pixel-by-pixel copy of the 485 display is needed, users should use the view sharing with remote 486 manipulation feature described in Section 4.1. 488 To implement this use case we need to be able to signal the co-web 489 browsing application in SDP. Additionally, we need a mechanism to 490 transfer URLs in real-time between the two endpoints. This memo 491 proposes to reuse Message Session Relay Protocol (MSRP) [RFC4975]. 492 MSRP SEND messages can carry an XML document that includes the HTTP 493 URL of the web page that Alice is visiting. Whenever Alice or Bob 494 load a new web page, an MSRP SEND request conveys the URL to the 495 remote endpoint. The co-web browsing application instructs then the 496 web browser to load the received URL. 498 The co-web browsing application requires a protocol for transferring 499 real-time messages that contain the URL that one of the endpoints is 500 loading in the web browser. We use the Message Session Relay 501 Protocol (MSRP) [RFC4975] as the real-time text message transport 502 protocol. We define a new MIME body, using Extensible Data Format 503 (XML), for wrapping the URL together with a time-stamp that indicates 504 when the web XML document was created. 506 Since text messaging media streams established with MSRP can be 507 already described in MSRP, this document does not introduce 508 extensions to SDP to signal them. 510 This document introduces a new Co-Web Browsing XML document that 511 encodes the URL linked to the web page rendered in a participant's 512 web browser. Co-Web Browsing is an XML document 513 [W3C.REC-xml-20060816] that MUST be well-formed and SHOULD be valid. 514 Co-Web Browsing documents MUST be based on XML 1.0 and MUST be 515 encoded using UTF-8 [RFC3628]. This specification makes use of XML 516 namespaces for identifying Co-Web Browsing documents. The namespace 517 URI for elements defined by this specification is a URN [RFC2141], 518 using the namespace identifier 'ietf' defined by RFC 2648 [RFC2648] 519 and extended by RFC 3688 [RFC3688]. This URN is: 521 urn:ietf:params:xml:ns:co-web-browsing 523 Co-web browsing XML documents have an associated MIME content type of 524 "application/co-web-browsing+xml". When a Co-web browsing XML 525 document is included in an MSRP SEND message, the Content-Type header 526 of the MSRP SEND request MUST be set to "application/ 527 co-web-browsing+xml". 529 A Co-Web Browser document begins with the root element tag . It has two children elements. A element 531 contains the time and date when the content was acquired. The 532 recipient of the Co-web browsing document can use the 533 element for correlation purposes, such as avoiding to download 534 existing content that has not changed. For example, if the recipient 535 has already downloaded the content, it can use a conditional HTTP 536 request using the value in the in the If-Modified-Since 537 and If-Unmodified-Since HTTP headers. 539 Last, a element contains the URL of the content as seen from 540 the sender. 542 Implementations according to the co-web browsing feature described in 543 this memo MUST comply with the XML schema included in Section 5.2.1. 545 4.2.1. Example of a Co-Web Browsing document 547 The following is an example of a Co-Web Browsing document. 549 550 551 2008-01-27T16:49:29Z 552 http://wwww.example.com/index.html 553 555 Figure 4: Example of a Co-Web Browsing document 557 4.3. File Transfer 559 The file transfer feature allows a user to offer a file to the remote 560 user. The file is parametrized by its name, size, creation and 561 modification dates, etc. The file offer can also include a small 562 preview icon, for example, in case the file is an image or video 563 file. If the remote user accepts, then the file transfer operation 564 takes place, typically using MSRP as the real-time transport 565 protocol. The file transfer feature can be used, for example, to 566 transfer screen shots that one user takes in his computer, or 567 documents that the user wants to share with their correspondent. 569 File transfer is described in the memo SDP offer/answer to enable 570 file transfer [I-D.ietf-mmusic-file-transfer-mech]. No further 571 considerations are needed in this document. 573 Additionally, the T.120 group of specifications provides a file 574 transfer capability: T.127 [ITU.T127.2007]. T.127 file transfer 575 operations can be described in SDP as per procedures for T.120 576 applications. 578 4.4. Further Sharing Applications 580 The two application sharing approaches discussed above offer 581 identical views to a single application or the entire remote desktop 582 and hence are sensible for remote maintenance activities. However, 583 they are inherently limited by offering only a single cursor, single 584 undo history, etc. If collaboration inside a single document shall 585 take place beyond this limited experience (e.g., allowing users to 586 independently manipulate different parts of a document at the same 587 time), the applications themselves must support sharing. Traditional 588 examples have been the Mbone tools whiteboard (wb) and network text 589 editor (nte) used with multicasting in the 1990s and the emacs 590 support for multiple windows into a single buffer ("make-frame-on- 591 display"). Also, presentation tools have offered "remote 592 presentation" mechanisms in the past. Recent shared applications 593 have been web-based, using a server as rendezvous point. 595 Note: In the following, we only give examples we are well aware of. 596 The authors seek further input to expand this section and give proper 597 coverage of other open tools. 599 Shared whiteboards have probably been among the most popular sharing 600 applications. While a lot of research has gone into shared 601 whiteboard applications particularly in the 1990s, not many open 602 (standardized) solutions exist. ITU-T T.126 offers sophisticated 603 image sharing, annotation, and pointing facilities and specifies a -- 604 quite complex -- standardized protocol which requires the entire 605 T.120 protocol suite underneath. T.126 is covered as per the above 606 definition. 608 Web-based shared editors and similar tools (which run over HTTP) can 609 use the mechanisms of co-web browsing described in the previous 610 section. 612 Note: The use of web-based sharing applications raises an issue 613 concerning the notion of a session in the context of a dialog. SDP 614 usually uses m= lines to describe sessions and can hence open and 615 close them as part of the offer/answer signaling. Conveying a URI of 616 a shared editing application in an MSRP session, to a certain extent, 617 also initiates a session in its own right which may be considered 618 independent of a particular call. 620 5. Formal syntax 622 5.1. SDP extensions 624 We define a number of new SDP [RFC4566] attributes that provide the 625 required information to describe the transfer of a file with MSRP. 626 These are all media level only attributes in SDP. The following is 627 the formal ABNF syntax [RFC5234] of these new attributes. It is 628 built above the SDP [RFC4566] grammar. 630 attribute = t120apps / confname 631 ;attribute is defined in RFC 4566 633 t120apps = "t120apps:" t120appid *(SP t120appid) 634 t120appid = "t126" / "t127" / "t128" / "t134" / 635 "t136" / "t137" / token 636 confname = "confname:" token ; token defined in RFC 4566 638 Figure 5: Syntax of the SDP extension 640 5.2. Co-Web browsing XML schema 642 Section 5.2.1 contains the XML schema of Co-web browsing XML 643 documents. Implementations of such XML document MUST be compliant 644 with that XML schema. 646 5.2.1. XML Schema 648 649 655 656 657 658 XML Schema Definition for Co-Web Browsing 659 660 662 665 666 667 669 670 671 672 674 Figure 6: XML schema of Co-Web Browsing 676 6. Examples 678 TBD. 680 7. Security Considerations 682 This document defines additional attributes for SDP and conventions 683 for using these with the offer/answer mechanism. The security 684 considerations of SDP [RFC4566] and the offer/answer model [RFC3264] 685 apply as do those for setting up TCP and TLS connections with SDP 686 (RFC 4572 [RFC4572] and RFC 4145 [RFC4145]. 688 Running (additional) application protocols inside a SIP dialog 689 creates additonal targets for attack or potential leaks of private 690 information. The security of the application part of the session 691 depends on the security of the application protocols being used. 693 They may not only reveal information about the applications 694 themselves, but may additionally leak information about other 695 sessions inside the dialog and about the peers involved. Hence, it 696 is suggested to use TLS protection for the application protocols if 697 possible or turn on application-specific protocol mechanisms if 698 available. 700 Furthermore, application sharing systems grant access to at least 701 some parts (if not all) of the local environment (read-only, read/ 702 write). Co-web-browsing and whiteboard sessions may also do so to a 703 limited extent. Therefore, security mechanisms (such as TLS) should 704 be applied to application protocols and each peer should ensure that 705 the respective connection truly originates and terminates at the 706 intended remote party. 708 8. IANA Considerations 710 This document instructs IANA to register a number of SDP attributes 711 according to the following: 713 8.1. Registration of new SDP attributes 715 This memo provides instructions to IANA to register a number of media 716 level only attributes in the Session Description Protocol Parameters 717 registry [1]. The registration data, according to RFC 4566 [RFC4566] 718 follows. 720 Note to the RFC Editor: replace "RFC XXXX" with the RFC number of 721 this specification. 723 8.1.1. Registration of the t120apps attribute 725 Contact: Miguel Garcia 726 Phone: +358 71400 4000 727 Attribute name: t120apps 728 Long-form attribute name: T.120 Applications 729 Type of attribute: media level only 730 This attribute is subject to the charset attribute 731 Description: This attribute list the available T.120 applications. 732 Specification: RFC XXXX 734 8.1.2. Registration of the confname attribute 736 Contact: Miguel Garcia 737 Phone: +358 71400 4000 738 Attribute name: confname 739 Long-form attribute name: Conference Name 740 Type of attribute: media level only 741 This attribute is subject to the charset attribute 742 Description: This attribute contains the conference name 743 identifier 744 Specification: RFC XXXX 746 8.2. Registration of new SDP 'proto' values 748 This memo defines the new SDP protocol field values "TCP/RFB", "TCP/ 749 TLS/RFB", "TCP/T120", and "TCP/TLS/T120", which should be registered 750 in the sdp-parameters registry under "proto". 752 8.3. MIME type registration 754 This specification requests IANA to register a new MIME type 755 "application/co-web-browsing+xml" according to the procedures of RFC 756 4288 [RFC4288] and the guidelines in RFC 3023 [RFC3023]. 758 MIME media type name: application 760 MIME subtype name: co-web-browsing+xml 762 Mandatory parameters: none 764 Optional parameters: Same as charset parameter application/xml as 765 specified in RFC 3023 [RFC3023]. 767 Encoding considerations: Same as encoding considerations of 768 application/xml as specified in RFC 3023 [RFC3023]. 770 Security considerations: See Section 10 of RFC 3023 [RFC3023]. 772 Interoperability considerations: none 774 Published specification: RFC XXXX 776 Additional Information: 778 Magic Number: none 779 File Extension: none 780 Macintosh file type code: "TEXT" 782 Personal and email address for further information: Miguel Garcia, 783 miguel.garcia@nsn.com 785 Intended usage: not common, restricted to sharing applications 786 Author/Change controller: The IETF. 788 8.4. URN Sub-Namespace Registration 790 This specification registers a new new XML namespace, as per the 791 guidelines in RFC 3688 [RFC3688]. 793 URI: urn:ietf:params:xml:ns:co-web-browsing 795 Registrant contact: IETF. 797 XML: 798 BEGIN 799 800 802 803 804 806 Co-web browsing namespace 807 808 809

Namespace for Co-web browsing XML Documents

810

urn:ietf:params:xml:ns:co-web-browsing

811

See 812 RFC4825

813 814 815 END 817 8.5. XML Schema Registration 819 This section registers a new XML schema per the procedures in RFC 820 3688 [RFC3688]. 822 URI: urn:ietf:params:xml:schema:co-web-browsing 824 Registrant Contact: IETF 826 XML Schema: The XML for this schema can be found as the sole content 827 of Section 5.2.1. 829 9. Acknowledgements 831 10. References 832 10.1. Normative References 834 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 835 Requirement Levels", BCP 14, RFC 2119, March 1997. 837 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 839 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 840 with Session Description Protocol (SDP)", RFC 3264, 841 June 2002. 843 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 844 January 2004. 846 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 847 the Session Description Protocol (SDP)", RFC 4145, 848 September 2005. 850 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 851 Description Protocol", RFC 4566, July 2006. 853 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 854 Transport Layer Security (TLS) Protocol in the Session 855 Description Protocol (SDP)", RFC 4572, July 2006. 857 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 858 Specifications: ABNF", STD 68, RFC 5234, January 2008. 860 [W3C.REC-xml-20060816] 861 Maler, E., Paoli, J., Bray, T., Sperberg-McQueen, C., and 862 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth 863 Edition)", World Wide Web Consortium Recommendation REC- 864 xml-20060816, August 2006, 865 . 867 10.2. Informative References 869 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 870 RFC 793, September 1981. 872 [RFC1006] Rose, M. and D. Cass, "ISO transport services on top of 873 the TCP: Version 3", STD 35, RFC 1006, May 1987. 875 [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 876 August 1999. 878 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 879 Types", RFC 3023, January 2001. 881 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 882 A., Peterson, J., Sparks, R., Handley, M., and E. 883 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 884 June 2002. 886 [RFC3628] Pinkas, D., Pope, N., and J. Ross, "Policy Requirements 887 for Time-Stamping Authorities (TSAs)", RFC 3628, 888 November 2003. 890 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 891 Registration Procedures", BCP 13, RFC 4288, December 2005. 893 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 894 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 896 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 897 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 899 [I-D.ietf-mmusic-file-transfer-mech] 900 Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S., 901 and P. Kyzivat, "A Session Description Protocol (SDP) 902 Offer/Answer Mechanism to Enable File Transfer", 903 draft-ietf-mmusic-file-transfer-mech-06 (work in 904 progress), December 2007. 906 [RFB] Richardson, T., "The Remote Frame Buffer Protocol version 907 3.8", June 2007, 908 . 910 [ITU.T120.2007] 911 ITU-T, "Data Protocols for Multimedia Conferencing", ITU- 912 T Recommendation T.120, January 2007. 914 [ITU.T122.1998] 915 ITU-T, "Multipoint communication service protocol 916 specification - Service definition", ITU-T Recommendation 917 T.122, February 1998. 919 [ITU.T123.2007] 920 ITU-T, "Network-specific data protocol stacks for 921 multimedia conferencing", ITU-T Recommendation T.123, 922 January 2007. 924 [ITU.T124.2007] 925 ITU-T, "Generic Conference Control", ITU-T Recommendation 926 T.124, January 2007. 928 [ITU.T125.1998] 929 ITU-T, "Multipoint communication service protocol 930 specification", ITU-T Recommendation T.125, August 2007. 932 [ITU.T126.2007] 933 ITU-T, "Multipoint still image and annotation protocol", 934 ITU-T Recommendation T.126, August 2007. 936 [ITU.T127.2007] 937 ITU-T, "Multipoint binary file transfer protocol", ITU- 938 T Recommendation T.128, August 2007. 940 [ITU.T128.1998] 941 ITU-T, "Multipoint Application Sharing", ITU- 942 T Recommendation T.128, February 1998. 944 [ITU.T134.1998] 945 ITU-T, "Text chat application entity", ITU- 946 T Recommendation T.134, February 1998. 948 [ITU.T135.2007] 949 ITU-T, "User-to-reservation system transactions within 950 T.120 conferences", ITU-T Recommendation T.135, 951 August 1998. 953 [ITU.T136.1999] 954 ITU-T, "Remote device control application protocol", ITU- 955 T Recommendation T.136, May 1999. 957 [ITU.T137.2000] 958 ITU-T, "Virtual meeting room management for multimedia 959 conferencing audio-visual control", ITU-T Recommendation 960 T.137, February 2000. 962 URIs 964 [1] 966 Authors' Addresses 968 Miguel A. Garcia-Martin 969 Nokia Siemens Networks 970 P.O.Box 6 971 Nokia Siemens Networks, FIN 02022 972 Finland 974 Email: miguel.garcia@nsn.com 975 Joerg Ott 976 Helsinki University of Technology 977 Otakaari 5 A 978 Espoo, FIN 02150 979 Finland 981 Email: jo@netlab.hut.fi 983 Full Copyright Statement 985 Copyright (C) The IETF Trust (2008). 987 This document is subject to the rights, licenses and restrictions 988 contained in BCP 78, and except as set forth therein, the authors 989 retain all their rights. 991 This document and the information contained herein are provided on an 992 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 993 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 994 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 995 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 996 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 997 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 999 Intellectual Property 1001 The IETF takes no position regarding the validity or scope of any 1002 Intellectual Property Rights or other rights that might be claimed to 1003 pertain to the implementation or use of the technology described in 1004 this document or the extent to which any license under such rights 1005 might or might not be available; nor does it represent that it has 1006 made any independent effort to identify any such rights. Information 1007 on the procedures with respect to rights in RFC documents can be 1008 found in BCP 78 and BCP 79. 1010 Copies of IPR disclosures made to the IETF Secretariat and any 1011 assurances of licenses to be made available, or the result of an 1012 attempt made to obtain a general license or permission for the use of 1013 such proprietary rights by implementers or users of this 1014 specification can be obtained from the IETF on-line IPR repository at 1015 http://www.ietf.org/ipr. 1017 The IETF invites any interested party to bring to its attention any 1018 copyrights, patents or patent applications, or other proprietary 1019 rights that may cover technology that may be required to implement 1020 this standard. Please address the information to the IETF at 1021 ietf-ipr@ietf.org. 1023 Acknowledgment 1025 Funding for the RFC Editor function is provided by the IETF 1026 Administrative Support Activity (IASA).