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 "