idnits 2.17.1 draft-ietf-rtcweb-data-protocol-07.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 4, 2014) is 3583 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: 'RFCXXXX' is mentioned on line 467, but not defined ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-09) exists of draft-ietf-tsvwg-sctp-dtls-encaps-04 == Outdated reference: A later version (-13) exists of draft-ietf-rtcweb-data-channel-10 == Outdated reference: A later version (-12) exists of draft-ietf-rtcweb-security-06 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-09 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Jesup 3 Internet-Draft Mozilla 4 Intended status: Standards Track S. Loreto 5 Expires: January 5, 2015 Ericsson 6 M. Tuexen 7 Muenster Univ. of Appl. Sciences 8 July 4, 2014 10 WebRTC Data Channel Establishment Protocol 11 draft-ietf-rtcweb-data-protocol-07.txt 13 Abstract 15 The WebRTC framework specifies protocol support for direct 16 interactive rich communication using audio, video, and data between 17 two peers' web-browsers. This document specifies a simple protocol 18 for establishing symmetric Data Channels between the peers. It uses 19 a two way handshake and allows sending of user data without waiting 20 for the handshake to complete. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 5, 2015. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 60 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 4 61 5.1. DATA_CHANNEL_OPEN Message . . . . . . . . . . . . . . . . 4 62 5.2. DATA_CHANNEL_ACK Message . . . . . . . . . . . . . . . . 7 63 6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 66 8.1. SCTP Payload Protocol Identifier . . . . . . . . . . . . 9 67 8.2. New Message Type Registry . . . . . . . . . . . . . . . . 9 68 8.3. New Channel Type Registry . . . . . . . . . . . . . . . . 10 69 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 72 10.2. Informational References . . . . . . . . . . . . . . . . 12 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 75 1. Introduction 77 The Data Channel Establishment Protocol (DCEP) is designed to 78 provide, in the WebRTC Data Channel context 79 [I-D.ietf-rtcweb-data-channel], a simple in-band method to open 80 symmetric Data Channels. As discussed in 81 [I-D.ietf-rtcweb-data-channel], the protocol uses the Stream Control 82 Transmission Protocol (SCTP) [RFC4960] encapsulated in the Datagram 83 Transport Layer Security (DTLS) [RFC4347] as described in 84 [I-D.ietf-tsvwg-sctp-dtls-encaps] to benefit from their already 85 standardized transport and security features. 87 2. Conventions 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 3. Terminology 95 This document uses the following terms: 97 Association: An SCTP association. 99 Stream: A unidirectional stream of an SCTP association. It is 100 uniquely identified by an SCTP stream identifier (0-65534). Note: 101 the SCTP stream identifier 65535 is reserved due to SCTP INIT and 102 INIT-ACK chunks only allowing a maximum of 65535 Streams to be 103 negotiated (0-65534). 105 Stream Identifier: The SCTP stream identifier uniquely identifying a 106 Stream. 108 Data Channel: Two Streams with the same Stream Identifier, one in 109 each direction, which are managed together. 111 4. Protocol Overview 113 The Data Channel Establishment Protocol is a simple, low-overhead way 114 to establish bidirectional Data Channels over an SCTP association 115 with a consistent set of properties. 117 The set of consistent properties includes: 119 o reliable or unreliable message transmission. In case of 120 unreliable transmissions, the same level of unreliability is used. 122 o in-order or out-of-order message delivery. 124 o the priority of the Data Channel. 126 o an optional label for the Data Channel. 128 o an optional protocol for the Data Channel. 130 o the Streams. 132 This protocol uses a two way handshake to open a Data Channel. The 133 handshake pairs one incoming and one outgoing Stream, both having the 134 same Stream Identifier, into a single bidirectional Data Channel. 135 The side wanting to open a Data Channel selects an Stream Identifier 136 for which the corresponding incoming and outgoing Streams are unused 137 and sends a DATA_CHANNEL_OPEN message on the outgoing Stream. The 138 peer responds with a DATA_CHANNEL_ACK message on its corresponding 139 outgoing Stream. Then the Data Channel is open. Data Channel 140 Establishment Protocol messages are sent on the same Stream as the 141 user messages belonging to the Data Channel. The demultiplexing is 142 based on the SCTP payload protocol identifier (PPID), since the Data 143 Channel Establishment Protocol uses a specific PPID. 145 Note: The opening side can send user messages before the 146 DATA_CHANNEL_ACK is received. 148 To avoid glare in opening Data Channels, each side MUST use Streams 149 with either even or odd Stream Identifiers when sending a 150 DATA_CHANNEL_OPEN message. When using SCTP over DTLS 151 [I-D.ietf-tsvwg-sctp-dtls-encaps], the method used to determine which 152 side uses odd or even is based on the underlying DTLS connection 153 role: the side acting as the DTLS client MUST use Streams with even 154 Stream Identifiers, the side acting as the DTLS server MUST use 155 Streams with odd Stream Identifiers. 157 Note: There is no attempt to resolve label glare; if both sides open 158 a Data Channel labeled "x" at the same time, there will be two Data 159 Channels labeled "x" - one on an even Stream pair, one on an odd 160 pair. 162 The protocol field is to ease cross-application interoperation 163 ("federation") by identifying the user data being passed with an 164 IANA-registered string ('WebSocket Subprotocol Name Registry' defined 165 in [RFC6455]), and may be useful for homogeneous applications which 166 may create more than one type of Data Channel. Please note that 167 there is also no attempt to resolve protocol glare. 169 5. Message Formats 171 Every Data Channel Establishment Protocol message starts with a one 172 byte field called "Message Type" which indicates the type of the 173 message. The corresponding values are managed by IANA (see 174 Section 8.2). 176 5.1. DATA_CHANNEL_OPEN Message 178 This message is sent initially on the Stream used for user messages 179 using the Data Channel. 181 0 1 2 3 182 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Message Type | Channel Type | Priority | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Reliability Parameter | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Label Length | Protocol Length | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 \ / 191 | Label | 192 / \ 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 \ / 195 | Protocol | 196 / \ 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 Message Type: 1 byte (unsigned integer) 200 This field holds the IANA defined message type for the 201 DATA_CHANNEL_OPEN message. The suggested value of this field for 202 IANA is 0x03. 204 Channel Type: 1 byte (unsigned integer) 205 This field specifies the type of the Data Channel to be opened and 206 the values are managed by IANA (see Section 8.3): 208 DATA_CHANNEL_RELIABLE (0x00): The Data Channel provides a 209 reliable in-order bi-directional communication. 211 DATA_CHANNEL_RELIABLE_UNORDERED (0x80): The Data Channel provides 212 a reliable unordered bi-directional communication. 214 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT (0x01): The Data Channel 215 provides a partially-reliable in-order bi-directional 216 communication. User messages will not be retransmitted more 217 times than specified in the Reliability Parameter. 219 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED (0x81): The Data 220 Channel provides a partial reliable unordered bi-directional 221 communication. User messages will not be retransmitted more 222 times than specified in the Reliability Parameter. 224 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x02): The Data Channel 225 provides a partial reliable in-order bi-directional 226 communication. User messages might not be transmitted or 227 retransmitted after a specified life-time given in milli- 228 seconds in the Reliability Parameter. This life-time starts 229 when providing the user message to the protocol stack. 231 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED (0x82): The Data 232 Channel provides a partial reliable unordered bi-directional 233 communication. User messages might not be transmitted or 234 retransmitted after a specified life-time given in milli- 235 seconds in the Reliability Parameter. This life-time starts 236 when providing the user message to the protocol stack. 238 Priority: 2 bytes (unsigned integer) 239 The priority of the Data Channel as described in 240 [I-D.ietf-rtcweb-data-channel]. 242 Reliability Parameter: 4 bytes (unsigned integer) 243 For reliable Data Channels this field MUST be set to 0 on the 244 sending side and MUST be ignored on the receiving side. If a 245 partial reliable Data Channel with limited number of 246 retransmissions is used, this field specifies the number of 247 retransmissions. If a partial reliable Data Channel with limited 248 lifetime is used, this field specifies the maximum lifetime in 249 milliseconds. The following table summarizes this: 251 +------------------------------------------------+------------------+ 252 | Channel Type | Reliability | 253 | | Parameter | 254 +------------------------------------------------+------------------+ 255 | DATA_CHANNEL_RELIABLE | Ignored | 256 | DATA_CHANNEL_RELIABLE_UNORDERED | Ignored | 257 | DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT | Number of RTX | 258 | DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED | Number of RTX | 259 | DATA_CHANNEL_PARTIAL_RELIABLE_TIMED | Lifetime in ms | 260 | DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED | Lifetime in ms | 261 +------------------------------------------------+------------------+ 263 Label Length: 2 bytes (unsigned integer) 264 The length of the label field in bytes. 266 Protocol Length: 2 bytes (unsigned integer) 267 The length of the protocol field in bytes. 269 Label: Variable Length (sequence of characters) 270 The name of the Data Channel as a UTF-8 encoded string. This may 271 be an empty string. 273 Protocol: Variable Length (sequence of characters) 274 If this is an empty string the protocol is unspecified. If it is 275 a non-empty string, it specifies a protocol registered in the 276 'WebSocket Subprotocol Name Registry' created in [RFC6455]. This 277 string is UTF-8 encoded. 279 5.2. DATA_CHANNEL_ACK Message 281 This message is sent in response to a DATA_CHANNEL_OPEN_RESPONSE 282 message on the stream used for user messages using the Data Channel. 283 Reception of this message tells the opener that the Data Channel 284 setup handshake is complete. 286 0 1 2 3 287 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Message Type | 290 +-+-+-+-+-+-+-+-+ 292 Message Type: 1 byte (unsigned integer) 293 This field holds the IANA defined message type for the 294 DATA_CHANNEL_ACK message. The suggested value of this field for 295 IANA is 0x02. 297 6. Procedures 299 All Data Channel Establishment Protocol messages MUST be sent using 300 ordered delivery and reliable transmission. They MUST be sent on the 301 same outgoing Stream as the user messages belonging to the 302 corresponding Data Channel. Multiplexing and demultiplexing is done 303 by using the SCTP payload protocol identifier (PPID). Therefore Data 304 Channel Establishment Protocol message MUST be sent with the assigned 305 PPID for the Data Channel Establishment Protocol (see Section 8.1). 306 Other messages MUST NOT be sent using this PPID. 308 If one side wants to open a Data Channel, it chooses an Stream 309 identifier for which the corresponding incoming and outgoing Streams 310 are free. If the side is the DTLS client, it MUST choose an even 311 Stream Identifier, if the side is the DTLS server, it MUST choose an 312 odd one. It fills in the parameters of the DATA_CHANNEL_OPEN message 313 and sends it on the chosen Stream. 315 After the DATA_CHANNEL_OPEN message has been sent, the sender of the 316 DATA_CHANNEL_OPEN can start sending messages containing user data 317 without waiting for the reception of the corresponding 318 DATA_CHANNEL_ACK message. However, before the DATA_CHANNEL_ACK 319 message or any other message has been received on a Data Channel, all 320 other messages containing user data and belonging to this Data 321 Channel MUST be sent ordered, no matter whether the Data Channel is 322 ordered or not. After the DATA_CHANNEL_ACK or any other message has 323 been received on the Data Channel, messages containing user data MUST 324 be send ordered on ordered Data Channels and MUST be sent unordered 325 on unordered Data Channels. Therefore receiving a message containing 326 user data on an unused Stream indicates an error. The corresponding 327 Data Channel MUST be closed as described in 328 [I-D.ietf-rtcweb-data-channel]. 330 If a DATA_CHANNEL_OPEN message is received on an unused Stream, the 331 Stream Identifier corresponds to the role of the peer and all 332 parameters in the DATA_CHANNEL_OPEN message are valid, then a 333 corresponding DATA_CHANNEL_ACK message is sent on the Stream with the 334 same Stream Identifier as the one the DATA_CHANNEL_OPEN message was 335 received on. 337 If the DATA_CHANNEL_OPEN message doesn't satisfy the conditions 338 above, for instance if a DATA_CHANNEL_OPEN message is received on an 339 already used Stream or there are any problems with parameters within 340 the DATA_CHANNEL_OPEN message, the odd/even rule is violated or the 341 DATA_CHANNEL_OPEN message itself is not well-formed, the receiver 342 MUST close the corresponding Data Channel using the procedure 343 described in [I-D.ietf-rtcweb-data-channel] and MUST NOT send a 344 DATA_CHANNEL_ACK message in response to the received message. 345 Therefore, receiving an SCTP stream reset request for a Stream on 346 which no DATA_CHANNEL_ACK message has been received indicates to the 347 sender of the corresponding DATA_CHANNEL_OPEN message the failure of 348 the Data Channel setup procedure. After also successfully resetting 349 the corresponding outgoing Stream, which concludes the Data Channel 350 closing initiated by the peer, a new DATA_CHANNEL_OPEN message can be 351 sent on the Stream. 353 7. Security Considerations 355 The DATA_CHANNEL_OPEN messages contains two variable length fields: 356 the protocol and the label. A receiver must be prepared to receive 357 DATA_CHANNEL_OPEN messages where these field have the maximum length 358 of 65535 bytes. Error cases like the use of inconsistent lengths 359 fields, unknown parameter values or violation the odd/even rule must 360 also be handled by closing the corresponding Data Channel. An end- 361 point must also be prepared that the peer open the maximum number of 362 Data Channels. 364 This protocol does not provide privacy, integrity or authentication. 365 It needs to be used as part of a protocol suite that contains all 366 these things. Such a protocol suite is specified in 367 [I-D.ietf-tsvwg-sctp-dtls-encaps]. 369 For general considerations see [I-D.ietf-rtcweb-security] and 370 [I-D.ietf-rtcweb-security-arch]. 372 8. IANA Considerations 374 [NOTE to RFC-Editor: 376 "RFCXXXX" is to be replaced by the RFC number you assign this 377 document. 379 ] 381 IANA is asked to update the reference of an already existing SCTP 382 PPID assignment and to create two new registries for the Data Channel 383 Establishment Protocol. 385 8.1. SCTP Payload Protocol Identifier 387 This document uses one already registered SCTP Payload Protocol 388 Identifier (PPID) named "WebRTC Control". [RFC4960] creates the 389 registry "SCTP Payload Protocol Identifiers" from which this 390 identifier was assigned. IANA is requested to update the reference 391 of this assignment to point to this document and to update the name. 392 Therefore this assignment should be updated to read: 394 +-------------+-----------+-----------+ 395 | Value | SCTP PPID | Reference | 396 +-------------+-----------+-----------+ 397 | WebRTC DCEP | 50 | [RFCXXXX] | 398 +-------------+-----------+-----------+ 400 8.2. New Message Type Registry 402 IANA is requested to create a new registration table "Message Type 403 Registry" for the Data Channel Establishment Protocol (DCEP) to 404 manage the one byte "Message Type" field in DCEP messages (see 405 Section 5). 407 The assignment of new message types is done through an RFC required 408 action, as defined in [RFC5226]. Documentation of the new message 409 type MUST contain the following information: 411 1. A name for the new message type; 413 2. A detailed procedural description of the use of messages with the 414 new type within the operation of the Data Channel Establishment 415 Protocol. 417 Initially the following values need to be registered: 419 +-------------------+-----------+-----------+ 420 | Name | Type | Reference | 421 +-------------------+-----------+-----------+ 422 | Reserved | 0x00 | [RFCXXXX] | 423 | Reserved | 0x01 | [RFCXXXX] | 424 | DATA_CHANNEL_ACK | 0x02 | [RFCXXXX] | 425 | DATA_CHANNEL_OPEN | 0x03 | [RFCXXXX] | 426 | Unassigned | 0x04-0xfe | | 427 | Reserved | 0xff | [RFCXXXX] | 428 +-------------------+-----------+-----------+ 430 Please note that the values 0x00 and 0x01 are reserved to avoid 431 interoperability problems, since they have been used in earlier 432 versions of the document. The value 0xff has been reserved for 433 future extensibility. 435 8.3. New Channel Type Registry 437 IANA is requested to create a new registration table "Channel Type 438 Registry" for the Data Channel Establishment Protocol to manage the 439 one byte "Channel Type" field in DATA_CHANNEL_OPEN messages (see 440 Section 5.1). 442 The assignment of new message types is done through an RFC required 443 action, as defined in [RFC5226]. Documentation of the new Channel 444 Type MUST contain the following information: 446 1. A name for the new Channel Type; 448 2. A detailed procedural description of the user message handling 449 for Data Channels using this new Channel Type. 451 Please note that if new Channel Types support ordered and unordered 452 message delivery, the high order bit SHOULD be used to indicate 453 whether the message delivery is unordered or not. 455 Initially the following values need to be registered: 457 +------------------------------------------------+------+-----------+ 458 | Name | Type | Reference | 459 +------------------------------------------------+------+-----------+ 460 | DATA_CHANNEL_RELIABLE | 0x00 | [RFCXXXX] | 461 | DATA_CHANNEL_RELIABLE_UNORDERED | 0x80 | [RFCXXXX] | 462 | DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT | 0x01 | [RFCXXXX] | 463 | DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED | 0x81 | [RFCXXXX] | 464 | DATA_CHANNEL_PARTIAL_RELIABLE_TIMED | 0x02 | [RFCXXXX] | 465 | DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED | 0x82 | [RFCXXXX] | 466 | Reserved | 0x7f | [RFCXXXX] | 467 | Reserved | 0xff | [RFCXXXX] | 468 | Unassigned | rest | | 469 +------------------------------------------------+------+-----------+ 471 9. Acknowledgments 473 The authors wish to thank Harald Alvestrand, Adam Bergkvist, Barry 474 Dingle, Stefan Haekansson, Cullen Jennings, Paul Kyzivat, Doug 475 Leonard, Irene Ruengeler, Randall Stewart, Peter Thatcher, Martin 476 Thompson, Justin Uberti, and many others for their invaluable 477 comments. 479 10. References 481 10.1. Normative References 483 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 484 Requirement Levels", BCP 14, RFC 2119, March 1997. 486 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 487 Security", RFC 4347, April 2006. 489 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 490 4960, September 2007. 492 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 493 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 494 May 2008. 496 [I-D.ietf-tsvwg-sctp-dtls-encaps] 497 Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS 498 Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- 499 dtls-encaps-04 (work in progress), May 2014. 501 10.2. Informational References 503 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 504 6455, December 2011. 506 [I-D.ietf-rtcweb-data-channel] 507 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 508 Channels", draft-ietf-rtcweb-data-channel-10 (work in 509 progress), June 2014. 511 [I-D.ietf-rtcweb-security] 512 Rescorla, E., "Security Considerations for WebRTC", draft- 513 ietf-rtcweb-security-06 (work in progress), January 2014. 515 [I-D.ietf-rtcweb-security-arch] 516 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 517 rtcweb-security-arch-09 (work in progress), February 2014. 519 Authors' Addresses 521 Randell Jesup 522 Mozilla 523 US 525 Email: randell-ietf@jesup.org 527 Salvatore Loreto 528 Ericsson 529 Hirsalantie 11 530 Jorvas 02420 531 FI 533 Email: salvatore.loreto@ericsson.com 535 Michael Tuexen 536 Muenster University of Applied Sciences 537 Stegerwaldstrasse 39 538 Steinfurt 48565 539 DE 541 Email: tuexen@fh-muenster.de