idnits 2.17.1 draft-ietf-bfcpbis-sdp-ws-uri-06.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 (October 19, 2016) is 2746 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) == Outdated reference: A later version (-15) exists of draft-ietf-bfcpbis-bfcp-websocket-10 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-14 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BFCPBIS Working Group Ram. Ravindranath 3 Internet-Draft G. Salgueiro 4 Intended status: Standards Track Cisco 5 Expires: April 22, 2017 October 19, 2016 7 Session Description Protocol (SDP) WebSocket Connection URI Attribute 8 draft-ietf-bfcpbis-sdp-ws-uri-06 10 Abstract 12 The WebSocket protocol enables bidirectional real-time communication 13 between clients and servers in web-based applications. This document 14 specifies extensions to Session Description Protocol (SDP) for 15 application protocols using WebSocket as a transport. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on April 22, 2017. 34 Copyright Notice 36 Copyright (c) 2016 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 3 54 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3.2. ws-uri SDP Attribute . . . . . . . . . . . . . . . . . . 3 56 3.3. wss-uri SDP Attribute . . . . . . . . . . . . . . . . . . 4 57 3.4. ws-uri and wss-uri Multiplexing Considerations . . . . . 4 58 4. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 5 59 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4.2. Generating the Initial Offer . . . . . . . . . . . . . . 5 61 4.3. Generating the Answer . . . . . . . . . . . . . . . . . . 6 62 4.4. Offerer Processing of the Answer . . . . . . . . . . . . 7 63 4.5. Modifying the Session . . . . . . . . . . . . . . . . . . 7 64 4.6. Offerless INVITE Scenarios . . . . . . . . . . . . . . . 7 65 5. Procedures at WebSocket Client . . . . . . . . . . . . . . . 7 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 68 7.1. Registration of the 'ws-uri' SDP Media Attribute . . . . 8 69 7.2. Registration of the 'wss-uri' SDP Media Attribute . . . . 9 70 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 73 9.2. Informative References . . . . . . . . . . . . . . . . . 10 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 76 1. Introduction 78 The WebSocket protocol [RFC6455] enables bidirectional message 79 exchange between clients and servers on top of a persistent TCP 80 connection (optionally secured with Transport Layer Security (TLS) 81 [RFC5246]). The initial protocol handshake makes use of Hypertext 82 Transfer Protocol (HTTP) [RFC7230] semantics, allowing the WebSocket 83 protocol to reuse existing HTTP infrastructure. 85 Modern web browsers include a WebSocket client stack compliant with 86 the WebSocket API [WS-API] as specified by the W3C. It is expected 87 that other client applications (e.g., those running on personal 88 computers, mobile devices, etc.) will also make a WebSocket client 89 stack available. Several specifications have been written that 90 define how different applications can use a WebSocket subprotocol as 91 a reliable transport mechanism. 93 For example, [RFC7118] defines WebSocket subprotocol as a reliable 94 transport mechanism between Session Initiation Protocol 95 (SIP)[RFC3261] entities to enable use of SIP in web-oriented 96 deployments. Additionally, [I-D.pd-dispatch-msrp-websocket] defines 97 a new WebSocket sub-protocol as a reliable transport mechanism 98 between Message Session Relay Protocol (MSRP) clients and relays. 99 [RFC7395] defines a WebSocket subprotocol for the Extensible 100 Messaging and Presence Protocol (XMPP). Similarly, 101 [I-D.ietf-bfcpbis-bfcp-websocket] defines a WebSocket sub-protocol as 102 a reliable transport mechanism between Binary Floor Control Protocol 103 (BFCP) [I-D.ietf-bfcpbis-rfc4582bis] entities to enable usage of BFCP 104 in new scenarios. 106 As defined in Section 3 of [RFC2818], when using Secure WebSockets 107 the Canonical Name (CNAME) of the Secure Sockets Layer (SSL) 108 [RFC6101] certificate MUST match the WebSocket connection URI host. 109 In most cases it is not viable for certificates signed by well known 110 authorities. Thus, there is a need to indicate the connection URI 111 for the WebSocket Client. For applications that use Session 112 Description Protocol (SDP) [RFC4566] to negotiate, the connection URI 113 can be indicated by means of an SDP attribute. This specification 114 defines new SDP attributes to indicate the connection URI for the 115 WebSocket client. Applications that use SDP for negotiation and 116 WebSocket as a transport protocol can use this specification to 117 advertise the WebSocket client connection URI. 119 2. Terminology 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 123 "OPTIONAL" in this document are to be interpreted as described in 124 [RFC2119]. 126 3. SDP Considerations 128 3.1. General 130 Applications that use the SDP Offer/Answer mechanism [RFC3264] for 131 negotiating media and also use WebSocket as a transport protocol MAY 132 indicate the connection URI for the WebSocket Client via a new SDP a= 133 media-level attribute defined in Section 3.2. 135 Applications that use SDP for negotiation and also use secure 136 WebSocket as a transport protocol TLS MAY indicate the connection URI 137 for the WebSocket Client via a new SDP a= media-level attribute 138 defined in Section 3.3. 140 3.2. ws-uri SDP Attribute 142 This section defines a new SDP media-level attribute, 'ws-uri' which 143 can appear in any of the media sections. 145 Example: 147 a=ws-uri:ws://example.com/chat 149 Where "ws://example.com/chat" is the ws-URI defined in Section 3 of 150 [RFC6455]. 152 When the 'ws-uri' attribute is present in the media section of the 153 SDP, the IP address in 'c= ' line SHALL be ignored and the full URI 154 SHALL be used instead to open the WebSocket connection. The clients 155 MUST ensure that they use the URI to open the webSocket connection 156 and ignore the IP address in 'c=' line and port in m= line. 158 3.3. wss-uri SDP Attribute 160 This section defines a new SDP media-level attribute, 'wss-uri' which 161 can appear in any of the media sections. 163 Example: 165 a=wss-uri:wss://example.com/chat 167 Here "wss://example.com/chat" is the wss-URI defined in Section 3 of 168 [RFC6455]. 170 When the 'wss-uri' attribute is present in the media section of the 171 SDP, the IP address in 'c= ' line SHALL be ignored and the full URI 172 SHALL be used instead to open the WebSocket connection. The clients 173 MUST ensure that they use the URI to open the webSocket connection 174 and ignore the IP address in 'c=' line and port in m= line. 176 3.4. ws-uri and wss-uri Multiplexing Considerations 178 Multiplexing characteristics of SDP attributes are described in 179 [I-D.ietf-mmusic-sdp-mux-attributes]. Various SDP attribute 180 multiplexing categories are introduced there. 182 o The multiplexing category of the "a=ws-uri:" attribute is CAUTION. 184 o The multiplexing category of the "a=wss-uri:" attribute is 185 CAUTION. 187 There are no multiplexing rules specified for the ws-uri and wss-uri 188 SDP media-level attributes. Additionally, the specification of 189 multiplexing rules for the ws-uri and wss-uri attributes is outside 190 the scope of this document. 192 While it is technically possible to bundle WebSocket, there are a 193 variety of reasons that make it impractical and it is thus considered 194 unlikely to be used in practice. Therefore, the ws-uri and wss-uri 195 SDP media-level attributes defined in Section 3.2 and Section 3.3 for 196 using WebSocket as a transport protocol are not likely to be used 197 with SDP bundle and are consequently categorized as CAUTION for 198 multiplexing. 200 If future extensions define how to bundle WebSocket then multiplexing 201 rules for the "a=ws-uri:" and "a=wss-uri:" attributes need to be 202 defined as well, for instance in an extension of this SDP based 203 WebSocket negotiation specification. 205 4. SDP Offer/Answer Procedures 207 4.1. General 209 An endpoint (i.e., both the offerer and the answerer) that wishes to 210 negotiate WebSocket as transport protocol MUST indicate that it 211 wishes to use WebSocket or secure WebSocket in the "proto" field of 212 the "m=" line. Furthermore, the server side, which could be either 213 the offerer or answerer, MUST add an "a=ws-uri" or "a=wss-uri" 214 attribute in the media section depending on whether it wishes to use 215 WebSocket or secure WebSocket. This new attribute MUST follow the 216 syntax defined in Section 3. The procedures in this section apply to 217 an "m=" line associated with any media stream that uses WebSocket or 218 secure WebSocket as transport. 220 4.2. Generating the Initial Offer 222 An SDP offerer in order to negotiate WebSocket as a transport MUST 223 indicate the same in the "proto" field of the "m=" line. For 224 example, to negotiate BFCP-over-WebSocket the "proto" value in the 225 "m=" line MUST be TCP/WSS/BFCP if WebSocket is over TLS, else it MUST 226 be TCP/WS/BFCP. 228 The offerer SHOULD assign the SDP "setup" attribute with a value of 229 "active" (the offerer will be the initiator of the outgoing TCP 230 connection), unless the offerer insists on being a receiver of an 231 incoming connection, in which case the offerer SHOULD use a value of 232 "passive". The offerer MUST NOT assign an SDP "setup" attribute with 233 a "holdconn" value. 235 The following is an example of an "m=" line for a BFCP connection: 237 Offer (browser): 238 m=application 9 TCP/WSS/BFCP * 239 a=setup:active 240 a=connection:new 241 a=floorctrl:c-only 242 m=audio 55000 RTP/AVP 0 243 m=video 55002 RTP/AVP 31 245 In the above example, the client is intending to setup the TLS /TCP 246 connection and hence the port is set to a value of 9, which is the 247 discard port. 249 4.3. Generating the Answer 251 If the answerer accepts the offered WebSocket transport connection, 252 in the associated SDP answer, the answerer MUST assign an SDP "setup" 253 attribute with a value of either "active" or "passive", according to 254 the procedures in [RFC4145]. The answerer MUST NOT assign an SDP 255 "setup" attribute with a value of "holdconn". 257 If the answerer assigns an SDP "setup" attribute with a value of 258 "active", the answerer MUST initiate the WebSocket connection 259 handshake by acting as client on the negotiated media stream, towards 260 the IP address and port of the offerer using the procedures described 261 in [RFC6455]. The answer MUST have an "a=ws-uri" or "a=wss-uri" 262 attribute depending on whether the application uses WebSocket or 263 secureWebSocket. This attribute MUST follow the syntax defined in 264 Section 3. For BFCP application, the "proto" value in the "m=" line 265 MUST be TCP/WSS/BFCP if WebSocket is run on TLS, else it MUST be 266 TCP/WS/BFCP. 268 The following example shows a case where the server responds with a 269 BFCP media stream over a WebSocket connection running TLS. It shows 270 an answer "m=" line for the BFCP connection. In this example since 271 WebSockets is running over TLS, the server answers back with "a=wss- 272 uri" attribute in the media section of SDP indicating the connection 273 URI: 275 Answer (server): 276 m=application 50000 TCP/WSS/BFCP * 277 a=setup:passive 278 a=connection:new 279 a=wss-uri:wss://bfcp-ws.example.com?token=3170449312 280 a=floorctrl:s-only 281 a=confid:4321 282 a=userid:1234 283 a=floorid:1 m-stream:10 284 a=floorid:2 m-stream:11 285 m=audio 50002 RTP/AVP 0 286 a=label:10 287 m=video 50004 RTP/AVP 31 288 a=label:11 290 4.4. Offerer Processing of the Answer 292 When the offerer receives an SDP answer, if the offerer ends up being 293 active it MUST follow the procedures in Section 5. 295 4.5. Modifying the Session 297 Once an offer/answer exchange has been completed, either endpoint MAY 298 send a new offer in order to modify the session. The endpoints can 299 reuse the existing WebSocket connection by adding 300 "a=connection:existing" attribute in the media section of SDP 301 following the rules mentioned in [RFC4145] if the ws-uri values and 302 the transport parameters indicated by each endpoint are unchanged. 303 Otherwise, following the rules for the initial offer/answer exchange, 304 the endpoints can negotiate and create a new WebSocket connection on 305 top of TLS/TCP or TCP. 307 4.6. Offerless INVITE Scenarios 309 In some scenarios an endpoint (e.g., a browser) originating the call 310 (UAC) can send an offerless INVITE to the server. The server will 311 generate an offer in response to the INVITE. In such cases the 312 server MUST send an offer with setup attribute as "passive" so as to 313 accept incoming connection and MUST include "a=wss-uri" or "a=ws-uri" 314 attribute in the media section depending on whether the server wishes 315 to use WebSocket or secure WebSocket. The SDP offer sent by the 316 server will look like the example in Section 4.3. 318 5. Procedures at WebSocket Client 320 The webSocket client MUST always initiate the outgoing TCP connection 321 and hence the SDP a=setup attribute MUST be always "active" for the 322 WebSocket client in its SDP offer/answer. In the below example, the 323 WebSocket client is the offerer and hence assigns "setup" attribute 324 with a value of "active". 326 The WebSocket server is a server on Internet and hence MUST always 327 assign SDP "setup" attribute with a value of "passive". This also 328 avoids the need to use ICE between WebSocket Client and WebSocket 329 Server as the connection model here would be a typical client to 330 server web connection. 332 Once the offer/answer is complete the client MUST initiate the 333 WebSocket connection handshake by sending a GET message on the 334 negotiated media stream, towards the IP address and port of the 335 answerer, as per the procedures described in [RFC6455]. If there are 336 multiple records returned for the connection URI in the "a=wss-uri" 337 or "a=ws-uri" then the clients MAY use procedures in Section 4 of 338 [RFC6555] to attempt the connection towards the server. When no port 339 is passed in the "a=wss-uri" or "a=ws-uri" attribute, the default 340 ports (80 or 443) is used. 342 6. Security Considerations 344 An attacker may attempt to add, modify, or remove 'a=ws-uri' or 345 'a=wss-uri' attribute from a session description. This could result 346 in an application behaving undesirably. Consequently, it is strongly 347 RECOMMENDED that integrity protection be applied to the SDP session 348 descriptions. For session descriptions carried in SIP [RFC3261], S/ 349 MIME is the natural choice to provide such end-to-end integrity 350 protection. 352 It is also RECOMMENDED that the application signaling traffic being 353 transported over a WebSocket communication session be protected by 354 using a secure WebSocket connection (using TLS [RFC5246] over TCP). 356 The WebSocket clients have to initiate the TCP connection to the 357 WebSocket server identified by the FQDN in a=ws/a=wss-uri. Further 358 as with any other web connection, the clients will verify the servers 359 certificate. The WebSocket client MUST follow the procedures in 360 [RFC7525] while setting up TLS connection with webSocket server. 362 7. IANA Considerations 364 7.1. Registration of the 'ws-uri' SDP Media Attribute 366 NOTE to RFC Editor: Please replace "XXXX" with the number of this 367 RFC. 369 This document defines a new SDP media-level attribute "ws-uri" in 370 Section 3.2 and requests that IANA to register the following SDP att- 371 field under the Session Description Protocol (SDP) Parameters 372 registry as follows: 374 +---------------------+---------------------------------------------+ 375 | Attribute name: | ws-uri | 376 | Long-form attribute | Websocket Connection URI | 377 | name: | | 378 | Type of attribute: | media | 379 | Mux category: | CAUTION | 380 | Charset Dependent: | No | 381 | Purpose: | The 'ws-uri' attribute is intended to be | 382 | | used as a connection URI for opening the | 383 | | WebSocket connection. | 384 | Appropriate values: | A ws-URI as defined in [RFC6455] | 385 | Contact name: | Gonzalo Salgueiro | 386 | Contact e-mail: | gsalguei@cisco.com | 387 | Reference: | RFCXXXX | 388 +---------------------+---------------------------------------------+ 390 7.2. Registration of the 'wss-uri' SDP Media Attribute 392 NOTE to RFC Editor: Please replace "XXXX" with the number of this 393 RFC. 395 This document defines a new SDP media-level attribute "wss-uri" in 396 Section 3.3 and requests that IANA to register the following SDP att- 397 field under the Session Description Protocol (SDP) Parameters 398 registry as follows: 400 +---------------------+---------------------------------------------+ 401 | Attribute name: | wss-uri | 402 | Long-form attribute | Websocket Connection URI over Secure | 403 | name: | Transport | 404 | Type of attribute: | media | 405 | Mux category: | CAUTION | 406 | Charset Dependent: | No | 407 | Purpose: | The 'wss-uri' attribute is intended to be | 408 | | used as a connection URI for opening the | 409 | | WebSocket connection over a secure | 410 | | transport. | 411 | Appropriate values: | A wss-URI as defined in [RFC6455] | 412 | Contact name: | Gonzalo Salgueiro | 413 | Contact e-mail: | gsalguei@cisco.com | 414 | Reference: | RFCXXXX | 415 +---------------------+---------------------------------------------+ 417 8. Acknowledgements 419 Thanks to Christer Holmberg for raising the need for a BFCP- 420 independent SDP attribute for WebSocket Connection URI. 422 The authors wish to acknowledge Paul Kyzivat, Suhas Nandakumar, 423 Christer Holmberg, Charles Eckel and Dan Wing for their invaluable 424 suggestions and review comments. 426 9. References 428 9.1. Normative References 430 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 431 Requirement Levels", BCP 14, RFC 2119, 432 DOI 10.17487/RFC2119, March 1997, 433 . 435 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 436 the Session Description Protocol (SDP)", RFC 4145, 437 DOI 10.17487/RFC4145, September 2005, 438 . 440 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 441 RFC 6455, DOI 10.17487/RFC6455, December 2011, 442 . 444 9.2. Informative References 446 [I-D.ietf-bfcpbis-bfcp-websocket] 447 Pascual, V., Roman, A., Cazeaux, S., Salgueiro, G., R, R., 448 and S. Murillo, "The WebSocket Protocol as a Transport for 449 the Binary Floor Control Protocol (BFCP)", draft-ietf- 450 bfcpbis-bfcp-websocket-10 (work in progress), June 2016. 452 [I-D.ietf-bfcpbis-rfc4582bis] 453 Camarillo, G., Drage, K., Kristensen, T., Ott, J., and C. 454 Eckel, "The Binary Floor Control Protocol (BFCP)", draft- 455 ietf-bfcpbis-rfc4582bis-16 (work in progress), November 456 2015. 458 [I-D.ietf-mmusic-sdp-mux-attributes] 459 Nandakumar, S., "A Framework for SDP Attributes when 460 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-14 461 (work in progress), September 2016. 463 [I-D.pd-dispatch-msrp-websocket] 464 Dunkley, P., Llewellyn, G., Pascual, V., Salgueiro, G., 465 and R. R, "The WebSocket Protocol as a Transport for the 466 Message Session Relay Protocol (MSRP)", draft-pd-dispatch- 467 msrp-websocket-15 (work in progress), August 2016. 469 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 470 DOI 10.17487/RFC2818, May 2000, 471 . 473 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 474 A., Peterson, J., Sparks, R., Handley, M., and E. 475 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 476 DOI 10.17487/RFC3261, June 2002, 477 . 479 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 480 with Session Description Protocol (SDP)", RFC 3264, 481 DOI 10.17487/RFC3264, June 2002, 482 . 484 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 485 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 486 July 2006, . 488 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 489 (TLS) Protocol Version 1.2", RFC 5246, 490 DOI 10.17487/RFC5246, August 2008, 491 . 493 [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure 494 Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, 495 DOI 10.17487/RFC6101, August 2011, 496 . 498 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 499 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 500 2012, . 502 [RFC7118] Baz Castillo, I., Millan Villegas, J., and V. Pascual, 503 "The WebSocket Protocol as a Transport for the Session 504 Initiation Protocol (SIP)", RFC 7118, 505 DOI 10.17487/RFC7118, January 2014, 506 . 508 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 509 Protocol (HTTP/1.1): Message Syntax and Routing", 510 RFC 7230, DOI 10.17487/RFC7230, June 2014, 511 . 513 [RFC7395] Stout, L., Ed., Moffitt, J., and E. Cestari, "An 514 Extensible Messaging and Presence Protocol (XMPP) 515 Subprotocol for WebSocket", RFC 7395, 516 DOI 10.17487/RFC7395, October 2014, 517 . 519 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 520 "Recommendations for Secure Use of Transport Layer 521 Security (TLS) and Datagram Transport Layer Security 522 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 523 2015, . 525 [WS-API] W3C and I. Hickson, Ed., "The WebSocket API", May 2012. 527 Authors' Addresses 529 Ram Mohan Ravindranath 530 Cisco Systems, Inc. 531 Cessna Business Park, 532 Kadabeesanahalli Village, Varthur Hobli, 533 Sarjapur-Marathahalli Outer Ring Road 534 Bangalore, Karnataka 560103 535 India 537 Email: rmohanr@cisco.com 539 Gonzalo Salgueiro 540 Cisco Systems, Inc. 541 7200-12 Kit Creek Road 542 Research Triangle Park, NC 27709 543 US 545 Email: gsalguei@cisco.com