- RTC-Web - example.com

New proposed charter text. Please review before the BoF.
by Ted Hardie 29 Mar '11

29 Mar '11

Name: Real-Time Communication in WEB-browsers (RTCWeb) There are a number of proprietary implementations that provide direct interactive rich communication using audio, video, collaboration, games, etc. between two peers' web-browsers. These are not interoperable, as they require non-standard extensions or plugins to work. There is a desire to standardize the basis for such communication so that interoperable communication can be established between any compatible browsers. The goal is to enable innovation on top of a set of basic components. One core component is to enable real-time media like audio and video, a second is to enable datagram and byte stream data transfer directly between clients. This work will be done in collaboration with the W3C. The IETF WG will produce architecture and requirements for selection and profiling of the on the wire protocols. The architecture needs to be coordinated with W3C. The IETF WG work will identity state information and events that need to be exposed in the APIs as input to W3C. The W3C will be responsible for defining APIs to ensure that application developers can control the components. The security goals and requirements will be developed by the WG. The security model needs to be coordinated with the W3C. The work will also consider where support for extensibility is needed. RTP functionalities, media formats, security algorithms are example of things that commonly needs extensions, additions or replacement, and thus some support for negotiation between clients is required. The WG will perform the following work: 1. Define the communication model in detail, including how session management is to occur within the model. 2. Define a security model that describes the security goals and how the communication model can achieve these goals. 3. Define how NAT and Firewall traversal is to occur. 4. Define which RTP functions and extensions that shall be supported in the client and their usage for real-time media, including media adaptation to ensure congestion safe usage. 5. Define what functionalities in the solution, such as media codecs, security algorithms, etc., that can be extended and how the extensibility mechanisms works. 6. Define a set of media formats that must or should be supported by a client to improve interoperability. 7. Define how non RTP datagram and byte stream data communication between the clients can be done securely and in a congestion safe way. 8. Provide W3C input for the APIs that comes from the communication model and the selected components and protocols that are part of the solution. This work will be done primarily by using already defined protocols or functionalities. If there is identification of missing protocols or functionalities, such work can be requested to be done in another working group with a suitable charter or by requests for chartering it in this WG or another WG. The following topics will be out of scope for the initial phase of the WG but could be added after a recharter: RTSP, RSVP, NSIS, Location services, IM & Presence, Resource Priority. The products of the working group will support security and keying as required by BCP 61 and be defined for IPv4, IPv6, and dual stack deployments. The Working Group will consider the possibility of defining a browser component that implements an existing session negotiation and management protocol. The working group will follow BCP 79, and adhere to the spirit of BCP 79. The working group cannot explicitly rule out the possibility of adopting encumbered technologies; however, the working group will try to avoid encumbered technologies that require royalties or other encumbrances that would prevent such technologies from being easy to use in web browsers. Milestones: Aug 2011 Architecture and Security and Threat Model sent to W3C Aug 2011 Use cases and Scenarios document sent to W3C Sept 2011 Architecture and Security and Threat Model to IESG as Informational Sept 2011 Use cases and Scenarios for RTCWeb document sent to IESG as Informational Dec 2011 RTCWeb and Media format specification(s) to IESG as PS Dec 2011 Information elements and events APIs Input to W3C Apr 2012 API to Protocol mapping document submitted to the IESG as Informational (if needed)

12 21

Non-IETF work: Coming up with a high level API spec
by Harald Alvestrand 24 Mar '11

24 Mar '11

Despite the fact that it's getting very close to our BOF session, other things are happening.... I've been working with some other people on getting together a specification for a very-high-level Javascript API for media control. This is intended as an "easy to use" API for those who do not wish to put detailed control in Javascript, and allows to build applications without getting into signalling protocols - those can be handled at server side if needed, or by other libraries if needed / possible. It's roughly at the same level as the just published WHATWG PeerConnection API or the now-gone ConnectionPeer API, and many functions are identical, but there are some differences. The spec is here: https://docs.google.com/a/google.com/document/pub?id=1_lFKBgjNMVy98TMZT0kZ6… It does not specify a format for sending data, since I believe we do not have consensus on even the design constraints for this - there are also other parts that are not fully fleshed out. Feedback welcome. If people want edit permission, so that they can enter comments directly into the document, pass me your google account info. Harald

1 1

BOF agenda, latest version
by Harald Alvestrand 23 Mar '11

23 Mar '11

I've uploaded a new version of the BOF agenda to the IETF toolserver: http://www.ietf.org/proceedings/80/agenda/rtcweb.txt It is also pasted below. All who need to use slides: Please have them ready by Sunday, so that the BOF chairs and attendees can review them before the meeting! RTCWEB, March 29, 2011 0900-1130 (Real Time Communication on the World Wide Web) Chairs: Harald Alvestrand, Ted Hardie Mailing list: rtcweb(a)alvestrand.no Reading list: draft-alvestrand-dispatch-rtcweb-datagram-01 draft-alvestrand-dispatch-rtcweb-protocols-01 draft-marjou-dispatch-rtcweb-sip-rtp-interwk-reqs-00 draft-rosenberg-rtcweb-framework-00 draft-holmberg-rtcweb-ucreqs-01 draft-perkins-rtcweb-rtp-usage-00 draft-jennings-rtcweb-api-00 Charter: http://rtc-web.alvestrand.com/ietf-activity This BoF proposes the creation of a group which will identify or produce the technology required to provide interactive communications between two or more web applications. While existing methods for accomplishing this are available, they are not interoperable, largely because they use different plug-in platforms as substrates. The set of components identified by this group will enable interopable communications among browsers and web application frameworks in which they are implemented. Enabling real-time audio and video streams is the primary target. A secondary target is enabling byte stream data transfer, so as to enable gaming, collaboration, and similar web applications to send data directly to peers. This work is intended to closely collaborate with a related effort at the W3C: http://www.w3.org/2010/12/webrtc-charter. Agenda: Stage-setting: 09:00 Agenda bashing, blue sheets, scribe selection, and note well 09:05 Brief introduction of the problem space and scope limitations 09:15 Summary of proposed IETF deliverables and relationship to W3C work on APIs and related issues Technology discussion: 09:45 Requirements and scenarios 10:00 Frameworks 10:20 Security work in web applications, browsers, and gateways 10:35 Negotiation methods and criteria for mandatory to implement capabilities Charter review: 10:50 Clarifying questions on charter text 11:05 Discussion of scope, deliverables, and timelines 11:20 Call for volunteers for specific work items 11:25 Charter hum 11:30 Adjourn

1 0

Relationship of the proposed W3C RTC group with WHATWG
by Rich Tibbett 23 Mar '11

23 Mar '11

Hi, There is currently a whole lot of ongoing work in the WHATWG around real-time web communications [whatwg-spec#rtc] [html-tracker]. What is the relationship between the proposed W3C activity [w3c-rtc-charter] and the work currently being done in the WHATWG? While there is an obvious need for IETF activity on underlying protocols, codecs and formats I'm unsure as to how a W3C RTC group is going to effectively manage any overlaps here. Any clarifications would be helpful. - Rich [whatwg-spec#rtc] http://www.whatwg.org/specs/web-apps/current-work/complete/video-conferenci… [html-tracker] http://html5.org/tools/web-apps-tracker [w3c-rtc-charter] http://www.w3.org/2010/12/webrtc-charter.html

3 3

Draft new: draft-holmberg-rtcweb-ucreqs-00 (Web Real-Time Communication Use-cases and Requirements)
by Christer Holmberg 23 Mar '11

23 Mar '11

Hi browser lovers, We've submitted a use-case/requirement draft, draft-holmberg-rtcweb-ucreqs-00.txt, that we think could be used as a base when those discussions start. The document describes some use-cases, and based on those proposes browser requirement, and application-browser API requirements. It focues on media related issue. Ie issues related to privacy, signalling between the browser and web server etc, are currenly not considered. Best regards, Christer

13 39

New draft on WebRTC API draft-jennings-rtcweb-api
by Cullen Jennings 22 Mar '11

22 Mar '11

I wrote up the start of a draft on requirements and a sketch of an API proposal. It is at http://tools.ietf.org/html/draft-jennings-rtcweb-api-00 I view this as very early but starts to list some of the issues and an evolving sketch of how the API might look. Cullen

4 5

New HTML5 API proposed for peer-to-peer communication
by Harald Alvestrand 22 Mar '11

22 Mar '11

Note: Ian Hickson has just published a new proposal for a peer-to-peer connection API, as part of his editing the HTML5 specification. The spec can be found around this URL: http://www.whatwg.org/specs/web-apps/current-work/#peerconnection-ice-agent Harald

1 0

NOTE WELL - notification
by Harald Alvestrand 17 Mar '11

17 Mar '11

For the avoidance of doubt: At the moment, this is the mailing list for a scheduled IETF BOF, and falls under IETF rules. In particular: Note Well Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: * The IETF plenary session * The IESG, or any member thereof on behalf of the IESG * Any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices * Any IETF working group or portion thereof * The IAB or any member thereof on behalf of the IAB * The RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules ofRFC 5378 <http://www.ietf.org/rfc/rfc5378.txt>andRFC 3979 <http://www.ietf.org/rfc/rfc3979.txt>(updated byRFC 4879 <http://www.ietf.org/rfc/rfc4879.txt>). Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consultRFC 5378 <http://www.ietf.org/rfc/rfc5378.txt>andRFC 3979 <http://www.ietf.org/rfc/rfc3979.txt>for details. A participant in any IETF activity is deemed to accept all IETF rules of process, as documented in Best Current Practices RFCs and IESG Statements. A participant in any IETF activity acknowledges that written, audio and video records of meetings may be made and may be available to the public.

1 0

Re: [RTW] New proposed charter text. Please review before the BoF.
by Ted Hardie 17 Mar '11

17 Mar '11

2011/3/17 Philippe Le Hegaret <plh(a)w3.org>: > On Thu, 2011-03-17 at 09:18 -0700, Ted Hardie wrote: >> 8. Provide W3C input for the APIs that comes from the >> communication model and the selected components and protocols that are >> part of the solution. > > >From a W3C point, I'd like to understand what item 8 means. W3C is > putting in place a working group to develop the APIs. > > Will the IETF Group also work on them in order to provide input? > > There is certainly a need for coordination between the two groups but > I'm concerned that the IETF Group would work on the APIs... > > Regards, > > Philippe Probably poor wording on my part; the intent here was to say that the IETF would provide W3C with information on the communication models and underlying protocols so that they could develop the APIs with this data in hand. As many have noted, coordination of the work is critical to getting a working system, and we've tried different ways of putting that in the charter. But I think that it's a general feeling that just needs capturing well. regards, Ted Hardie

1 0

DISPATCH Ad-HOC meetings on RTCWeb at IETF 80
by Cullen Jennings 15 Mar '11

15 Mar '11

The dispatch WG will an ad-hoc meeting to discuss the technical contents of drafts related to the proposed RTCWeb WG. Tentative time: RTCWeb's is Friday 1415-1515 in the Grand Ballroom Send Agenda requests for time to Mary and I. Thanks, Mary & Cullen

1 0