The Session Description Protocol (SDP) WebSocket Connection URI Attribute
draft-ietf-bfcpbis-sdp-ws-uri-09

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
Cc: draft-ietf-bfcpbis-sdp-ws-uri@ietf.org, "Charles Eckel" <eckelcu@cisco.com>, bfcpbis-chairs@ietf.org, bfcpbis@ietf.org, alissa@cooperw.in, eckelcu@cisco.com, "The IESG" <iesg@ietf.org>, rfc-editor@rfc-editor.org
Subject: Protocol Action: 'Session Description Protocol (SDP) WebSocket Connection URI Attribute' to Proposed Standard (draft-ietf-bfcpbis-sdp-ws-uri-09.txt)

The IESG has approved the following document:
- 'Session Description Protocol (SDP) WebSocket Connection URI
Attribute'
  (draft-ietf-bfcpbis-sdp-ws-uri-09.txt) as Proposed Standard

This document is the product of the Binary Floor Control Protocol Bis 
Working Group.

The IESG contact persons are Alexey Melnikov, Ben Campbell and Alissa
Cooper.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-sdp-ws-uri/

Ballot Text

Technical Summary:
The WebSocket [RFC6455] protocol enables two-way message exchange between clients and servers on top of a persistent TCP connection, optionally secured with Transport Layer Security (TLS) [RFC5246].  The WebSocket protocol was designed for, and is typically used in, web-based applications. This document specifies extensions to Session Description Protocol (SDP) for application protocols using WebSocket as a transport.

Working Group Summary:
This document was created as a result of agreement within the working group that the new SDP ws-uri attribute that was initially defined within [draft-ietf-bfcpbis-bfcp-websocket] was not BFCP specific and should therefore be defined within a separate draft. There were no competing documents and the draft was immediately adopted as a working group document based on content pulled out of [draft-ietf-bfcpbis-bfcp-websocket]. The draft proceeded without much contention. Reviews were mainly editorial in nature and dealt with the organization of the content and striking the right balance of information between the two drafts such that each stood on its own without unnecessary duplication.  Working group last call resulted on only one substantial review, which clarified when within the SDP offer/answer the new attribute is to be included and how to deal with offerless INVITEs.

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

The authors are aware of two server-side implementations and one client-side — none of them is open source. There are also partial client and server implementations that exercise what is covered in this draft. Other companies indicated plans to implement this in their WebRTC gateway.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?
Charles Eckel <eckelcu@cisco.com> is the document shepherd.
Alissa Cooper <alissa@cooperw.in> is the responsible Area Director.

RFC Editor Note