idnits 2.17.1 draft-suzuki-rtcweb-jingle-web-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 28, 2012) is 4412 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6120' is defined on line 586, but no explicit reference was found in the text == Unused Reference: 'RFC6121' is defined on line 589, but no explicit reference was found in the text == Unused Reference: 'XEP-0166' is defined on line 593, but no explicit reference was found in the text == Unused Reference: 'XEP-0167' is defined on line 598, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rtcweb-use-cases-and-requirements' is defined on line 610, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-02 == Outdated reference: A later version (-16) exists of draft-ietf-rtcweb-use-cases-and-requirements-05 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Yoshihiro Suzuki 3 Internet-Draft D3 Communications 4 Intended Status: Informational Nobuo Ogashiwa 5 Expires: July 31, 2012 Maebashi Kyoai Gakuen College 6 February 28, 2012 8 Real-Time Web Communication by using XMPP Jingle 9 draft-suzuki-rtcweb-jingle-web-00 11 Abstract 13 XMPP Jingle specification defines an XMPP protocol extension for 14 managing peer-to-peer media sessions between two users. And XMPP 15 Jingle can manage multi contents simultaneously in one Jingle 16 stream, but in the XMPP world there is no common way to layout 17 variable multi contents on each display. In this document, a 18 solution to this issue is provided by using Web browser's layout 19 function. 21 This document describes a new concept to realize one of solutions 22 of RTCWeb. Of course, "Web Browser" is used for Web application's 23 frontend for real-time communication, and XMPP Jingle specification 24 (XEP-166) is used as signaling protocol. And a simple mapping 25 manner between jingle contents and HTML graphical elements enables 26 to unite Web browser's layout function and Jingle's media content 27 management function to realize RTCWeb functions. 29 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with 32 the provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six 40 months and may be updated, replaced, or obsoleted by other 41 documents at any time. It is inappropriate to use Internet-Drafts 42 as reference material or to cite them other than as "work in 43 progress." 45 Suzuki, et al. Expires July 31, 2012 [Page 1] 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/ietf/1id-abstracts.txt. 49 The list of Internet-Draft Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html. 52 This Internet-Draft will expire on July 31, 2012. 54 Copyright Notice 56 Copyright (c) 2012 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with 64 respect to this document. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Architecture and Functional Model. . . . . . . . . . . . . . . 4 70 3. Procedures of Real-Time Communication. . . . . . . . . . . . . 5 71 3.1 Procedures of Initialization and Negotiation . . . . . . . . 5 72 3.2 Mapping between Contents in Jingle and HTML/DOM Elements . . 5 73 3.3 Procedures of Jingle Stream Connection . . . . . . . . . . . 6 74 3.4 Procedures of Adding or Deleting contents. . . . . . . . . . 6 75 3.5 Procedures of Termination. . . . . . . . . . . . . . . . . . 6 76 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 78 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 79 6.1 Normative References . . . . . . . . . . . . . . . . . . . 6 80 6.2 Informative References . . . . . . . . . . . . . . . . . . 7 82 1. Introduction 84 XMPP can signal various information between users' clients, and 85 signaling infromation can be easily written by using XML 86 syntax. So, XMPP has now over 300 extended specifications as XEP 87 series specifications in XSF (XMPP Standards Foundation) without 88 core protocols written as RFC 6120: XMPP CORE, RFC 6121: XMPP IM 89 and so on. 91 Suzuki, et al. Expires July 31, 2012 [Page 2] 92 In the XMPP world, many extensions are about how to treat various 93 signaling informations only. In IM (Instant Messaging) service 94 which is very typical service of XMPP, text messages are sent and 95 received as in-band data, or piggy-backed in signaling message like 96 as SMS of cell phone services. 98 In Jingle Specification (XEP-0166) and Jingle related 99 specifications, it's possible for each client to negotiate stream's 100 specifications as out of band media paths by using a set of Jingle 101 signaling procedures. When each client can succeed negotiation, it 102 sets up media path as a Jingle stream directly between 2 clients, 103 and then it can directly send and receive any numbers of media 104 contents in one Jingle stream directly without a help of XMPP 105 server. 107 As above description, Jingle specifications define to manage multi 108 contents stream between 2 clients, but in these specifications it's 109 not written about a common way to layout and render various 110 contents on each display . Until now it is a implement matter in 111 the XMPP world. In order to layout and render changeable number of 112 contents, it will be defined how to layout and render the contents 113 at the time when number of contents are changed. So, in this 114 proposal, Web browser is introduced to realize a flexible frontend 115 real-time communication services. And this proposal would be one of 116 solutions to realize RTCWeb. 118 2. Architecture and functional model 120 In this document, Browser model is basically same as RTCWeb 121 overview document [I-D.ietf-rtcweb-overview] as follows. But there 122 are small changes to simplify to use XMPP, signaling path is 123 changed to XMPP signaling, and RTC media path is changed to XMPP 124 Jingle media path. And "Browser RTC function" is changed to 125 "Browser Jingle function" in order to clarify to use XMPP features. 127 Suzuki, et al. Expires July 31, 2012 [Page 3] 128 +-----------+------------+ On-the-wire 129 | | | Protocols 130 | Web | XMPP |---------> 131 | Server | Server | XMPP Federation 132 | | | Protocol 133 +-----------+------------+ (Jingle Signaling 134 ^ Path) 135 | 136 | 137 | HTTP/XMPP 138 | 139 | 140 | 141 +----------------------------+ 142 | JavaScript/HTML/CSS | 143 +----------------------------+ 144 Other ^ ^RTC 145 APIs | |APIs 146 +---|-----------------|------+ 147 | | | | 148 | +---------+| 149 | | Browser || On-the-wire 150 | Browser | Jingle || Protocols 151 | | Function|-----------> 152 | | || Jingle 153 | | || Media Path 154 | +---------+| 155 +---------------------|------+ 156 | 157 V 158 Native OS Services 160 Figure 1: Browser Model by Using XMPP 162 Suzuki, et al. Expires July 31, 2012 [Page 4] 163 And Overview of the system is basically same as RTCWeb Overview 164 document [I-D.ietf-rtcweb-overview] as follows. Like as Figure 1, 165 there are small changes to clarify to use XMPP features. In the 166 XMPP specifications, "federation protocol" is defined to signal 167 between the peering servers. 169 + -----+------+ +------+------+ 170 | | | | | | 171 | Web | XMPP | Signaling | Web | XMPP | 172 | | |-------------| | | 173 |Server|Server| path |Server|Server| 174 | | | | | | 175 + -----+------+ +------+------+ 176 / \ 177 / \ 178 / \ HTTP/XMPP 179 / \ 180 / \ 181 / HTTP/XMPP \ 182 / \ 183 +-----------+ +-----------+ 184 |JS/HTML/CSS| |JS/HTML/CSS| 185 +-----------+ +-----------+ 186 +-----------+ +-----------+ 187 | | | | 188 | | | | 189 | Browser | ------------------------- | Browser | 190 | | Jingle media Path | | 191 | | | | 192 +-----------+ +-----------+ 194 Figure 2: Browser RTC Trapezoid by Using XMPP 196 Suzuki, et al. Expires July 31, 2012 [Page 5] 197 3. Procedures of Real-Time Communication 199 Basic procedure is almost same as Jingle specification, but there 200 are some different points in order to introduce Web browser as 201 real-time communication service frontend. XMPP's signaling is done 202 by presence, message and IQ stanza. "Stanza is a basic set of XML 203 statements in XMPP signaling. In this proposal, in order to map 204 contents in a Jingle stream to HTML/DOM elements, we add some xml 205 elements or attributes in Jingle signaling IQ stanzas. In the 206 following section, it is showed how to use our proposed protocol 207 extensions. In Jingle specifications, caller is called as "Jingle 208 Initiator" and callee is called as "Jingle Responder". In figure 3, 209 it shows simplified session flow of XMPP Jingle, and horizontal 210 arrow is one IQ stanza with Jingle action type name. Doubled 211 horizontal arrow is used to show out-band direct media path between 212 caller and callee. Of course, usual IQ stanzas (single horizontal 213 arrow) are transferred by the help of XMPP servers belong the 214 signaling path. (In XMPP world, it may be available for each clients 215 to connect its own server, server-server signaling protocol is 216 called federation protocol.) 218 Caller (Initiator) Callee (Responder) 219 | | 220 | session-initiate | 221 |---------------------------->| 222 | ack | 223 |<----------------------------| 224 | session-accept | 225 |<----------------------------| 226 | ack | 227 |---------------------------->| 228 | [optional further | 229 | negotiation] | 230 |<--------------------------->| 231 | Real-Time Call (RTP) | 232 |<===========================>| 233 | session-terminate | 234 |<----------------------------| 235 | ack | 236 |---------------------------->| 237 | | 239 Figure 3: simplified session flow 241 Suzuki, et al. Expires July 31, 2012 [Page 6] 242 3.1. Procedures of Initialization and Negotiation 244 In the RTCWeb model, user gets initial HTML contents from Web 245 server as a Web application, and this HTML contents must have 246 JavaScript statements to set up signaling session between his 247 client and a XMPP server. So HTML statements is loaded, Web browser 248 kicks this JavaScript event handler (maybe "onLoaded" event 249 handler), and JavaScript statements set up a XMPP signaling session 250 at first. 252 As next step, user would choose peer user to make a real-time 253 communication call. Maybe it will be done by the event that user 254 select a gui part on a some kind of address book. When this event 255 is occurred, JavaScript statements starts to manage negotiation of 256 stream specification. Some default contents in a Jingle stream will 257 be proposed from caller (Jingle initiator) to callee (Jingle 258 Responder) by using Jingle "session-initiate" IQ-stanza with some 259 candidates of content specifications. One content specification 260 have basically 2 XML elements, one is a media information and 261 another one is a transport information. A "description" XML element 262 have media information with media type and some candidates of codec 263 specifications, and a "tranport" XML element have transport type 264 information and some candidates of IP address and port set. Caller 265 and Callee make negotiation by using some more IQ-stanzas, and when 266 negotiation is finally succeeded, callee (Jingle responder) send 267 session-accept IQ-stanza, at this time, caller's initial candidate 268 specifications are filtered to one acceptable content specification 269 for both caller and callee. 271 In this proposal, session-initiate and session-accept IQ-stanza 272 should have one more information, it's layout information of 273 contents in a Jingle stream on the each clients' Web browser 274 window. This layout information is used to map between a content in 275 a Jingle stream and a HTML/DOM element. This is a very important 276 point of this proposal. So, this proposal can manage and layout any 277 number of contents in a Jingle stream and a Web browser. Following 278 Example IQ-stanza has layout information with usual Jingle 279 "session-initiate" XML elements as "" tag. 281 Suzuki, et al. Expires July 31, 2012 [Page 7] 282 Example 1. Example of IQ-stanza from caller (session-initiate) 284 288 291 292 293 294 295 296 297 298 299 300 301 302 307 308 309 310 311 313 3.2. Mapping between contents in Jingle and HTML/DOM elements 315 As mentioned above, in our proposal layout tag in session-initiate 316 IQ stanza is very important. In Example. 1, layout information has 317 only one attribute "URL". For simple html can be written in the 318 manner of XML syntax, but usual Web applications' HTML statements 319 and related CSS and JavaScript statements are not conformed XML 320 syntax, so these are described as URL simply. Web browser's Jingle 321 function part hands over this URL information to Core of Web 322 brwoser and Web browser loads new page of URL which describes 323 layout information of initial default contents set in HTML syntax 324 manner. 326 Suzuki, et al. Expires July 31, 2012 [Page 8] 327 In this proposal, We proposed 2 way to map a content in a Jingle 328 stream to a element of HTML/DOM. One is the way to use common id in 329 both a new "id" attribute of "" tag and "id" information 330 in HTML/DOM element. In this way "id" must be unique in one 331 real-time session, and make the same value as both a new "id" 332 attribute of "" tag and "id" information in HTML/DOM 333 element. This idea introduce a new "id" attribute in tag 334 in Jingle signaling information. From the view of Web application 335 or Ajax programmer, identical objects in HTML, 336 CSS, JavaScript statements must have the same value of "id" 337 attribute, this approach is extension of this rule to apply the 338 content of a Jingle stream. So, This is natural extension for Ajax 339 programmers, but it is needed to add new attribute in Jingle 340 specification. 342 Example 2. Mapping by "id" value 344 --- Jingle stream specification --- 345 346 347 ^^^^^^^^^^^^^^^^^ 348 349 350 351 352 353 354 355 356 357 ----------------------------------- 359 --- HTML layout specification --- 360 361 362
367
369 370 371 --------------------------------- 373 Suzuki, et al. Expires July 31, 2012 [Page 9] 374 Another way to map a content in a Jingle stream to a element of 375 HTML/DOM is to use a set of ip address and port number written in 376 "" tag information of a "" description, and 377 in a HTML/DOM element this set of ip address and port number is 378 described as src attribute of media tag. For the video or image 379 content, This approach is very natural for protocol designer, 380 because there is no change in existing specifications to map a 381 Jingle content to a HTML/CSS/JavaScript elements. But, Web browser 382 with Jingle Functions must keep mapping information between 383 information of Jingle stream specification and 384 identical object in HTML/CSS/JavaScript statements. 386 Example 3. Mapping by a set of ip address and port number 388 --- Jingle stream specification --- 389 390 391 392 393 394 395 396 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 397 398 399 400 401 ----------------------------------- 403 --- HTML layout specification --- 404 405 406
410
413 414 415 --------------------------------- 417 In this proposal, contents in a Jingle stream is related to a 418 identical object of HTML/CSS/JavaScript , and a Jingle stream is 419 related to layout description by using whole HTML/CSS 420 statements. In Jingle specification, it is needed to add 421 "" information, when Jingle specification is described or 422 changed in Jingle signaling messages. So when a set of contents or 423 a Jingle stream specification is changed, HTML/CSS statements must 424 change to update mapping information. (Maybe user's Web Browser 425 should upload new HTML/CSS/JavaScript set to Web Server, until new 426 Jingle signaling message will be sent to peer's Web browser. And 427 when HTML/CSS statements is updated, Web browser must load new page 428 which include updated layout information. 430 Of Course, in this proposal, without Jingle signaling message, each 431 Web browser can change position of contents or scale of contents by 432 using Ajax manner or apply new CSS statements only to adapt user's 433 own request on one side. 435 3.3. Procedures of Jingle stream connection 437 In section 4.1, both caller (Jingle initiator) and callee 438 (Jingle responder) agreed contents' specifications in a Jingle 439 stream and contents' layout information. Jingle specification 440 defines how to connect between the Jingle clients, but does not 441 define how to layout on the screen. So, the JavaScript program 442 which is done the negotiation and connection of Jingle stream, then 443 connects each content in a Jingle stream to HTML/DOM element by 444 using mapping information which is described above. HTML rendering 445 engine starts HTML/DOM rendering, and at same time CSS mechanism 446 can relocate and rescale HTML/DOM elements. The previous section's 447 and this section's procedures are automatically done by user's 448 event which user made by pressing a gui parts on some address book 449 interfaces. Of course if callee is not online, or lacks abilities 450 to treat contents in a Jingle stream, or some error occurred in the 451 procedures, caller's call will be failed. Details of error 452 condition in the Jingle protocol are well defined in Jingle 453 specifications (XEP-166 and some more). Maybe, JavaScript API will 454 be well defined to make a realtime communication call in order to 455 use various signaling protocol by W3C WebRTC WG. 457 3.4. Procedures of adding or deleting contents 459 In Jingle specifications, adding or deleting contents in a Jingle 460 stream are well defined, so in this proposal the important thing is 461 to keep mapping information between the contents in a Jingle 462 stream and HTML/DOM elements in HTML statements or a DOM tree. The 463 following figure shows overall session status in a Jingle session. 465 o 466 | 467 | session-initiate 468 | 469 | +---------->--------------+ 470 |/ | 471 PENDING o-----------------------+ | 472 | | content-accept, | | 473 | | content-add, | | 474 | | content-modify, | | 475 | | content-reject, | | 476 | | content-remove, | | 477 | | description-info, | | 478 \|/ | session-info, | | 479 | | transport-accept, | | 480 | | transport-info, | | 481 | | transport-reject, | | 482 | | transport-replace | | 483 | +--------------------+ | 484 | | 485 | session-accept \|/ 486 | | 487 ACTIVE o-----------------------+ | 488 | | content-accept, | | 489 | | content-add, | | 490 | | content-modify, | | 491 | | content-reject, | | 492 | | content-remove, | | 493 | | description-info, | | 494 \|/ | session-info, | | 495 | | transport-accept, | | 496 | | transport-info, | | 497 | | transport-reject, | | 498 | | transport-replace | | 499 | +--------------------+ | 500 | | 501 +------------->--------------+ 502 | 503 | session-terminate 504 | 505 o ENDED 507 Figure 4: overall session status 509 Following example is showed to adding one content to a jingle 510 stream. If user requests to add more contents in a Jingle stream, 511 more contents specification must be added to adapt a user's 512 request. When a set of contents or a Jingle stream specification is 513 changed, mapping information or information must be 514 updated. 516 Example 4. Example of IQ-stanza (content-add) 518 523 526 sid='a73sjjvkla37jfea'> 527 528 529 530 531 532 533 534 535 536 537 538 539 128 540 541 542 543 544 545 547 3.5. Procedures of Termination 549 Web browser on both side can terminate realtime communication call 550 by using usual Jingle signaling manner, but there is one different 551 thing. It is needed to set HTML/CSS/JavaScript statements to update 552 Web browser window to show that realtime communication call is 553 terminated. Example 5 is one of session-terminate signaling message. 555 Example 5. Example of IQ-stanza (session-terminate) 557 561 565 566 567 I'm outta here! 568 569 570 571 573 4. Security Considerations 575 This document has no requirement for a change to the security 576 models within associated protocols. 578 5. IANA Considerations 580 T.B.D. 582 6. References 584 6.1. Normative References 586 [RFC6120] P. Saint-Andre, "Extensible Messaging and Presence 587 Protocol (XMPP): Core", March 2011. 589 [RFC6121] P. Saint-Andre, "Extensible Messaging and Presence 590 Protocol (XMPP): Instant Messaging and Presence, 591 March 2011. 593 [XEP-0166] Scott Ludwig et al, "Jingle", December 2011. 595 Available at 596 http://xmpp.org/extensions/xep-0166.html 598 [XEP-0167] Scott Ludwig et al, "Jingle RTP Sessions" December 599 2009. 601 Available at 602 http://xmpp.org/extensions/xep-0167.html 604 [I-D.ietf-rtcweb-overview] 605 H. Alvestrand, "Overview: Real Time Protocols for 606 Brower-based Applications", 607 draft-ietf-rtcweb-overview-02 (work in progress), 608 September 2011. 610 [I-D.ietf-rtcweb-use-cases-and-requirements] 611 C. Holmberg et al,"Web Real-Time Communication 612 Use-cases and Requirements", 613 draft-ietf-rtcweb-use-cases-and-requirements-05 (work in 614 progress), September 2011. 616 [webrtc-api] 617 Adam Bergkvist et al, "WebRTC 1.0: Real-time 618 Communication Between Browsers", February 2012 620 Available at 621 http://www.w3.org/TR/webrtc/ 623 6.2. Informative references 625 Authors' Addresses 627 Yoshihiro Suzuki 628 D3 Communications 629 1-18-31 Tamagawa-Gakuen 630 Machida City, Tokyo 631 Japan 194-0041 632 Email: hiro.suzuki@d3communications.jp 634 Nobuo Ogashiwa 635 Maebashi Kyoai Gakuen College 636 1154-4 Koyahara-machi 637 Maebashi City, Gunma Pref 638 JAPAN 379-2192 639 EMail: ogashiwa@c.kyoai.ac.jp 640 URI: http://www.kyoai.ac.jp/