Charter proposal: The activity hitherto known as "RTC-WEB at IETF"

This is the first of 3 messages going to the DISPATCH list (in the hope of keeping discussions somewhat organized). This is the draft of a charter for an IETF working group to consider the subject area of "Real time communication in the Web browser platform". This is one of a paired set of activities, the other one being a W3C activity (either within an existing WG or in a new WG) that defines APIs to this functionality. The two other messages will contain the W3C proposed charter and a kickoff for what's usually the most distracting topic in any such discussion: The name of the group. Without further ado: ------------------------------------- Version: 2 Possible Names: <This space deliberately left blank for later discussion> Body: Many implementations have been made that use a Web browser to support interactive communications directly between users including voice, video, collaboration and gaming, but until now, such applications have required the installation of nonstandard plugins and browser extensions. There is a desire to standardize such functionality, so that this type of application can be run in any compatible browser. Traditionally, the W3C has defined API and markup languages such as HTML that work in conjunction with with the IETF over the wire protocols such as HTTP to allow web browsers to display media that does not have real time interactive constraints with another human. The W3C and IETF plan to collaborate together in their traditional way to meet the evolving needs of browsers. Specifically the IETF will provide a set of on the wire protocols, including RTP, to meet the needs on interactive communications, and the W3C will define the API and markup to allow web application developers to control the on the wire protocols. This will allow application developers to write applications that run in a browser and facilitate interactive communications between users for voice and video communications, collaboration, and gaming. This working group will select and define a minimal set of protocols that will enable browsers to: * have interactive real time voice and video between users using RTP * interoperate with compatible voice and video systems that are not web based * support direct flows of non RTP application data between browsers for collaboration and gaming applications Fortunately very little development of new protocol at IETF is required for this, only selection of existing protocols and selection of minimum capabilities to ensure interoperability. The following protocols are candidates for including in the profile set: 1) RTP/ RTCP 2) a baseline audio codec for high quality interactive audio. Opus will be considered as one of the candidates 3) a baseline audio codec for PSTN interoperability. G.711 and iLBC will be considered 4) a baseline video codec. H.264 and VP8 will be considered 5) Diffserv based QoS 6) NAT traversal using ICE 7) RFC 4833 based DTMF transport 8) RFC 4574 based Label support for identifying streams purpose 9) Secure RTP and keying 10) support for IPv4, IPv6 and dual stack browsers The working group will cooperate closely with the W3C activity that specifies a semantic level API that allows the control and manipulation of all the functionality above. In addition, the API needs to communicate state information and events about what is happening in the browser that to applications running in the browser. These events and state need to include information such as: receiving RFC 4833 DTMF, RTP and RTCP statistics, state of DTLS/SRTP, and signalling state. 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, LOST, Geolocation, IM & Presence, NSIS, Resource Priority, Milestones: February 2011 Candidate "sample" documents circulated to DISPATCH March 2011 BOF at IETF Prague April 2011 WG charter approved by IESG. Chosen document sets adopted as WG documents May 2011 Functionality to include and main alternative protocols identified July 2011 IETF meeting Aug 2011 Draft with text reflecting agreement of what the protocol set should be Nov 2010 Documentation specifying mapping of protocol functionality to W3C-specified API produced Dec 2011 Protocol set specification to IESG April 2012 API mapping document to IESG

On Jan 6, 2011, at 6:53 AM, Harald Alvestrand wrote:
This is the first of 3 messages going to the DISPATCH list (in the hope of keeping discussions somewhat organized).
This is the draft of a charter for an IETF working group to consider the subject area of "Real time communication in the Web browser platform". This is one of a paired set of activities, the other one being a W3C activity (either within an existing WG or in a new WG) that defines APIs to this functionality.
The two other messages will contain the W3C proposed charter and a kickoff for what's usually the most distracting topic in any such discussion: The name of the group.
Dear Harold; Just to be clear, your intent is to have simultaneously a W3C WG and an IETF WG on this issue ? Shouldn't there be some text about coordination between these efforts ? I don't see much discussion in either charter as to which is gating, but it seems to me that the W3C work would have to be gated on the IETF work. Isn't there a danger that the W3C WG might start building on early solutions discussed in the IETF, only to have the IETF WG decide to go in a different direction ? Regards Marshall
Without further ado:
-------------------------------------
Version: 2
Possible Names: <This space deliberately left blank for later discussion>
Body:
Many implementations have been made that use a Web browser to support interactive communications directly between users including voice, video, collaboration and gaming, but until now, such applications have required the installation of nonstandard plugins and browser extensions. There is a desire to standardize such functionality, so that this type of application can be run in any compatible browser.
Traditionally, the W3C has defined API and markup languages such as HTML that work in conjunction with with the IETF over the wire protocols such as HTTP to allow web browsers to display media that does not have real time interactive constraints with another human.
The W3C and IETF plan to collaborate together in their traditional way to meet the evolving needs of browsers. Specifically the IETF will provide a set of on the wire protocols, including RTP, to meet the needs on interactive communications, and the W3C will define the API and markup to allow web application developers to control the on the wire protocols. This will allow application developers to write applications that run in a browser and facilitate interactive communications between users for voice and video communications, collaboration, and gaming.
This working group will select and define a minimal set of protocols that will enable browsers to:
* have interactive real time voice and video between users using RTP * interoperate with compatible voice and video systems that are not web based * support direct flows of non RTP application data between browsers for collaboration and gaming applications
Fortunately very little development of new protocol at IETF is required for this, only selection of existing protocols and selection of minimum capabilities to ensure interoperability. The following protocols are candidates for including in the profile set:
1) RTP/ RTCP
2) a baseline audio codec for high quality interactive audio. Opus will be considered as one of the candidates
3) a baseline audio codec for PSTN interoperability. G.711 and iLBC will be considered
4) a baseline video codec. H.264 and VP8 will be considered
5) Diffserv based QoS
6) NAT traversal using ICE
7) RFC 4833 based DTMF transport
8) RFC 4574 based Label support for identifying streams purpose
9) Secure RTP and keying
10) support for IPv4, IPv6 and dual stack browsers
The working group will cooperate closely with the W3C activity that specifies a semantic level API that allows the control and manipulation of all the functionality above. In addition, the API needs to communicate state information and events about what is happening in the browser that to applications running in the browser. These events and state need to include information such as: receiving RFC 4833 DTMF, RTP and RTCP statistics, state of DTLS/SRTP, and signalling state.
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, LOST, Geolocation, IM & Presence, NSIS, Resource Priority,
Milestones:
February 2011 Candidate "sample" documents circulated to DISPATCH
March 2011 BOF at IETF Prague
April 2011 WG charter approved by IESG. Chosen document sets adopted as WG documents
May 2011 Functionality to include and main alternative protocols identified
July 2011 IETF meeting
Aug 2011 Draft with text reflecting agreement of what the protocol set should be
Nov 2010 Documentation specifying mapping of protocol functionality to W3C-specified API produced
Dec 2011 Protocol set specification to IESG
April 2012 API mapping document to IESG
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web

On 01/06/2011 01:49 PM, Marshall Eubanks wrote:
On Jan 6, 2011, at 6:53 AM, Harald Alvestrand wrote:
This is the first of 3 messages going to the DISPATCH list (in the hope of keeping discussions somewhat organized).
This is the draft of a charter for an IETF working group to consider the subject area of "Real time communication in the Web browser platform". This is one of a paired set of activities, the other one being a W3C activity (either within an existing WG or in a new WG) that defines APIs to this functionality.
The two other messages will contain the W3C proposed charter and a kickoff for what's usually the most distracting topic in any such discussion: The name of the group. Dear Harold;
Just to be clear, your intent is to have simultaneously a W3C WG and an IETF WG on this issue ?
Shouldn't there be some text about coordination between these efforts ? I don't see much discussion in either charter as to which is gating, but it seems to me that the W3C work would have to be gated on the IETF work. Isn't there a danger that the W3C WG might start building on early solutions discussed in the IETF, only to have the IETF WG decide to go in a different direction ? If either effort fails, we don't have an usable result, so that is indeed very key. As proposed, I think the IETF work gates the W3C work.
The IETF charter says: The working group will cooperate closely with the W3C activity that specifies a semantic level API that allows the control and manipulation of all the functionality above. The W3C charter says: External Groups @@@ IETF group on related protocol The RTC APIs developed by this group will build upon the protocols and formats developed in the IETF @@@ Working Group. What more words would you suggest we put in? Finding enough people who have the time to run back and forth between them is a key activity; I for one am allocated to this effort, so I'll be running. Harald
Regards Marshall
Without further ado:
-------------------------------------
Version: 2
Possible Names: <This space deliberately left blank for later discussion>
Body:
Many implementations have been made that use a Web browser to support interactive communications directly between users including voice, video, collaboration and gaming, but until now, such applications have required the installation of nonstandard plugins and browser extensions. There is a desire to standardize such functionality, so that this type of application can be run in any compatible browser.
Traditionally, the W3C has defined API and markup languages such as HTML that work in conjunction with with the IETF over the wire protocols such as HTTP to allow web browsers to display media that does not have real time interactive constraints with another human.
The W3C and IETF plan to collaborate together in their traditional way to meet the evolving needs of browsers. Specifically the IETF will provide a set of on the wire protocols, including RTP, to meet the needs on interactive communications, and the W3C will define the API and markup to allow web application developers to control the on the wire protocols. This will allow application developers to write applications that run in a browser and facilitate interactive communications between users for voice and video communications, collaboration, and gaming.
This working group will select and define a minimal set of protocols that will enable browsers to:
* have interactive real time voice and video between users using RTP * interoperate with compatible voice and video systems that are not web based * support direct flows of non RTP application data between browsers for collaboration and gaming applications
Fortunately very little development of new protocol at IETF is required for this, only selection of existing protocols and selection of minimum capabilities to ensure interoperability. The following protocols are candidates for including in the profile set:
1) RTP/ RTCP
2) a baseline audio codec for high quality interactive audio. Opus will be considered as one of the candidates
3) a baseline audio codec for PSTN interoperability. G.711 and iLBC will be considered
4) a baseline video codec. H.264 and VP8 will be considered
5) Diffserv based QoS
6) NAT traversal using ICE
7) RFC 4833 based DTMF transport
8) RFC 4574 based Label support for identifying streams purpose
9) Secure RTP and keying
10) support for IPv4, IPv6 and dual stack browsers
The working group will cooperate closely with the W3C activity that specifies a semantic level API that allows the control and manipulation of all the functionality above. In addition, the API needs to communicate state information and events about what is happening in the browser that to applications running in the browser. These events and state need to include information such as: receiving RFC 4833 DTMF, RTP and RTCP statistics, state of DTLS/SRTP, and signalling state.
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, LOST, Geolocation, IM& Presence, NSIS, Resource Priority,
Milestones:
February 2011 Candidate "sample" documents circulated to DISPATCH
March 2011 BOF at IETF Prague
April 2011 WG charter approved by IESG. Chosen document sets adopted as WG documents
May 2011 Functionality to include and main alternative protocols identified
July 2011 IETF meeting
Aug 2011 Draft with text reflecting agreement of what the protocol set should be
Nov 2010 Documentation specifying mapping of protocol functionality to W3C-specified API produced
Dec 2011 Protocol set specification to IESG
April 2012 API mapping document to IESG
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web

On Jan 6, 2011, at 8:48 AM, Harald Alvestrand wrote:
On 01/06/2011 01:49 PM, Marshall Eubanks wrote:
On Jan 6, 2011, at 6:53 AM, Harald Alvestrand wrote:
This is the first of 3 messages going to the DISPATCH list (in the hope of keeping discussions somewhat organized).
This is the draft of a charter for an IETF working group to consider the subject area of "Real time communication in the Web browser platform". This is one of a paired set of activities, the other one being a W3C activity (either within an existing WG or in a new WG) that defines APIs to this functionality.
The two other messages will contain the W3C proposed charter and a kickoff for what's usually the most distracting topic in any such discussion: The name of the group.
Dear Harold;
Just to be clear, your intent is to have simultaneously a W3C WG and an IETF WG on this issue ?
Shouldn't there be some text about coordination between these efforts ? I don't see much discussion in either charter as to which is gating, but it seems to me that the W3C work would have to be gated on the IETF work. Isn't there a danger that the W3C WG might start building on early solutions discussed in the IETF, only to have the IETF WG decide to go in a different direction ?
If either effort fails, we don't have an usable result, so that is indeed very key. As proposed, I think the IETF work gates the W3C work.
The IETF charter says:
The working group will cooperate closely with the W3C activity that specifies a semantic level API that allows the control and manipulation of all the functionality above.
The W3C charter says:
External Groups
@@@ IETF group on related protocol The RTC APIs developed by this group will build upon the protocols and formats developed in the IETF @@@ Working Group.
s/Group./Group and will not be finalized until that work is published./ (Of course, to get published you have to go through the IESG, which is the real point here. I would myself be satisfied with AUTH48 as a marker for that.)
What more words would you suggest we put in?
Finding enough people who have the time to run back and forth between them is a key activity; I for one am allocated to this effort, so I'll be running.
That is going to be tough, especially as the W3C has "good standing" requirements. http://www.w3.org/2005/10/Process-20051014/groups.html#good-standing which you may lose if "the individual has missed more than one of the last three face-to-face meetings" or "the individual has missed more than one of the last three distributed meetings." So, to be in good standing with the W3C WG I would have to attend 2 out of 3 F2F meetings somewhere - are any planned ? It also says "Effective participation to Web Real-Time Communications Working Group is expected to consume one work day per week for each participant; two days per week for editors." I don't know if this is required for "good standing" but taken together this is a hit, or could be (there are a lot of "weasel words" in these two documents.) Can you provide insight as to how much of a time commitment the W3C effort will really be ? Regards Marshall P.S. A nit below.
Harald
Regards Marshall
Without further ado:
-------------------------------------
Version: 2
Possible Names: <This space deliberately left blank for later discussion>
Body:
Many implementations have been made that use a Web browser to support interactive communications directly between users including voice, video, collaboration and gaming, but until now, such applications have required the installation of nonstandard plugins and browser extensions. There is a desire to standardize such functionality, so that this type of application can be run in any compatible browser.
Traditionally, the W3C has defined API and markup languages such as HTML that work in conjunction with with the IETF over the wire protocols such as HTTP to allow web browsers to display media that does not have real time interactive constraints with another human.
The W3C and IETF plan to collaborate together in their traditional way to meet the evolving needs of browsers. Specifically the IETF will provide a set of on the wire protocols, including RTP, to meet the needs on interactive communications, and the W3C will define the API and markup to allow web application developers to control the on the wire protocols. This will allow application developers to write applications that run in a browser and facilitate interactive communications between users for voice and video communications, collaboration, and gaming.
This working group will select and define a minimal set of protocols that will enable browsers to:
* have interactive real time voice and video between users using RTP * interoperate with compatible voice and video systems that are not web based * support direct flows of non RTP application data between browsers for collaboration and gaming applications
Fortunately very little development of new protocol at IETF is required for this, only selection of existing protocols and selection of minimum capabilities to ensure interoperability. The following protocols are candidates for including in the profile set:
1) RTP/ RTCP
2) a baseline audio codec for high quality interactive audio. Opus will be considered as one of the candidates
3) a baseline audio codec for PSTN interoperability. G.711 and iLBC will be considered
4) a baseline video codec. H.264 and VP8 will be considered
5) Diffserv based QoS
6) NAT traversal using ICE
7) RFC 4833 based DTMF transport
8) RFC 4574 based Label support for identifying streams purpose
9) Secure RTP and keying
10) support for IPv4, IPv6 and dual stack browsers
The working group will cooperate closely with the W3C activity that specifies a semantic level API that allows the control and manipulation of all the functionality above. In addition, the API needs to communicate state information and events about what is happening in the browser that to applications running in the browser. These events and state need to include information such as: receiving RFC 4833 DTMF, RTP and RTCP statistics, state of DTLS/SRTP, and signalling state.
s/signalling/signaling/
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, LOST, Geolocation, IM & Presence, NSIS, Resource Priority,
Milestones:
February 2011 Candidate "sample" documents circulated to DISPATCH
March 2011 BOF at IETF Prague
April 2011 WG charter approved by IESG. Chosen document sets adopted as WG documents
May 2011 Functionality to include and main alternative protocols identified
July 2011 IETF meeting
Aug 2011 Draft with text reflecting agreement of what the protocol set should be
Nov 2010 Documentation specifying mapping of protocol functionality to W3C-specified API produced
Dec 2011 Protocol set specification to IESG
April 2012 API mapping document to IESG
_______________________________________________ RTC-Web mailing list
RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web

On Jan 6, 2011, at 4:49 , Marshall Eubanks wrote:
On Jan 6, 2011, at 6:53 AM, Harald Alvestrand wrote:
This is the first of 3 messages going to the DISPATCH list (in the hope of keeping discussions somewhat organized).
This is the draft of a charter for an IETF working group to consider the subject area of "Real time communication in the Web browser platform". This is one of a paired set of activities, the other one being a W3C activity (either within an existing WG or in a new WG) that defines APIs to this functionality.
The two other messages will contain the W3C proposed charter and a kickoff for what's usually the most distracting topic in any such discussion: The name of the group.
Dear Harold;
Just to be clear, your intent is to have simultaneously a W3C WG and an IETF WG on this issue ?
Shouldn't there be some text about coordination between these efforts ? I don't see much discussion in either charter as to which is gating, but it seems to me that the W3C work would have to be gated on the IETF work. Isn't there a danger that the W3C WG might start building on early solutions discussed in the IETF, only to have the IETF WG decide to go in a different direction ?
Hi I'm sorry if this has already been said, but I am pretty sure that the W3C's work should provide a pretty general framework into which all sorts of instantiations (protocols and implementations) can be fit. An example might be "a URL that addresses the remote end goes here" and a URL has a protocol part (before the colon) and an 'address' part (after it). Sure, the first protocol instantiated (in definition and code) should be the stuff worked on with the IETF, but the architecture should not preclude others. I am sure there will be back and forth, and it's important that the functional division into pieces, and the architectural division between 'markup' (w3c) and 'protocol' (ietf) be agreed, and that the final pieces do, in fact work together. But I think it very important that we see at least two layers of definition here: modularization, framework, and so on, which is pretty general; and specific modules that fit into that framework and make our first working system, which need to be very specific. David Singer Multimedia and Software Standards, Apple Inc.

Hi, I have some comments/questions on the proposed charter. GENERAL: -------- In my opinion it is good that the charter lists tasks that have to be solved, but I don't think the charter should specify the technical solutions. For example, rather than saying "RFC 4833 based DTMF transport" it should say "DTMF transport". Because, we haven't discussed different DTMF transport mechanisms, and I don't think we shall discuss them as part as the charter discussion. The same comment applies to NAT traversal, identification of media stream purposes etc. Similar, I don't think the charter shall list different codecs, but only say that the intention is to choose a baseline codec for audio and video. NEGOTIATION: ------------ The charter talks about baseline codecs and transport (RTP/RTCP). But, I think it shall also cover the possibility to negotiate the usage of other codecs and transports. INTEROPERABILITY: ----------------- The charter says: "interoperate with compatible voice and video systems that are not web based" And, later a baseline codec for PSTN interoperability is mentioned. But, interoperability is much more than having a codec. You will need some "gateway" that performs mapping between the web based system and the non-web based system. Is the working group supposed to define such mapping? QOS: ---- What is the thinking behind the addition of DiffServ? W3C API: -------- The charter seems to put requirements on the W3C API. In particular, it talks about "signalling state". What is that? FUTURE WORK: ------------ If we are going to list potential future work, I would like to add "connection control" to the list. Regards, Christer

Nowhere have you specified in the milestones what status the intended deliverables are. Assuming the profile is intended to be proposed standard, then presumably you need to ensure all the constituent parts are of proposed standard, or some equivalent referenceable standard in some other organisation. Opus does not yet have a RTP payload format, although I understand one is planned, no drafts exist at the moment. iLBC is defined as an experimental RFC - does it need to be upgraded to standards track or is there some other reference. VP8 has no RTP payload format defined, unless it is masquerading under some other name. Presumably you need a paragraph in the charter relating to working with other groups (in particular IETF WG) to ensure that profiled specifications exist and are brought to standards track level. regards Keith
-----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Harald Alvestrand Sent: Thursday, January 06, 2011 11:54 AM To: 'dispatch@ietf.org' Cc: rtc-web@alvestrand.no Subject: [dispatch] Charter proposal: The activity hitherto known as "RTC-WEB at IETF"
This is the first of 3 messages going to the DISPATCH list (in the hope of keeping discussions somewhat organized).
This is the draft of a charter for an IETF working group to consider the subject area of "Real time communication in the Web browser platform". This is one of a paired set of activities, the other one being a W3C activity (either within an existing WG or in a new WG) that defines APIs to this functionality.
The two other messages will contain the W3C proposed charter and a kickoff for what's usually the most distracting topic in any such discussion: The name of the group. Without further ado:
-------------------------------------
Version: 2
Possible Names: <This space deliberately left blank for later discussion>
Body:
Many implementations have been made that use a Web browser to support interactive communications directly between users including voice, video, collaboration and gaming, but until now, such applications have required the installation of nonstandard plugins and browser extensions. There is a desire to standardize such functionality, so that this type of application can be run in any compatible browser.
Traditionally, the W3C has defined API and markup languages such as HTML that work in conjunction with with the IETF over the wire protocols such as HTTP to allow web browsers to display media that does not have real time interactive constraints with another human.
The W3C and IETF plan to collaborate together in their traditional way to meet the evolving needs of browsers. Specifically the IETF will provide a set of on the wire protocols, including RTP, to meet the needs on interactive communications, and the W3C will define the API and markup to allow web application developers to control the on the wire protocols. This will allow application developers to write applications that run in a browser and facilitate interactive communications between users for voice and video communications, collaboration, and gaming.
This working group will select and define a minimal set of protocols that will enable browsers to:
* have interactive real time voice and video between users using RTP * interoperate with compatible voice and video systems that are not web based * support direct flows of non RTP application data between browsers for collaboration and gaming applications
Fortunately very little development of new protocol at IETF is required for this, only selection of existing protocols and selection of minimum capabilities to ensure interoperability. The following protocols are candidates for including in the profile set:
1) RTP/ RTCP
2) a baseline audio codec for high quality interactive audio. Opus will be considered as one of the candidates
3) a baseline audio codec for PSTN interoperability. G.711 and iLBC will be considered
4) a baseline video codec. H.264 and VP8 will be considered
5) Diffserv based QoS
6) NAT traversal using ICE
7) RFC 4833 based DTMF transport
8) RFC 4574 based Label support for identifying streams purpose
9) Secure RTP and keying
10) support for IPv4, IPv6 and dual stack browsers
The working group will cooperate closely with the W3C activity that specifies a semantic level API that allows the control and manipulation of all the functionality above. In addition, the API needs to communicate state information and events about what is happening in the browser that to applications running in the browser. These events and state need to include information such as: receiving RFC 4833 DTMF, RTP and RTCP statistics, state of DTLS/SRTP, and signalling state.
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, LOST, Geolocation, IM & Presence, NSIS, Resource Priority,
Milestones:
February 2011 Candidate "sample" documents circulated to DISPATCH
March 2011 BOF at IETF Prague
April 2011 WG charter approved by IESG. Chosen document sets adopted as WG documents
May 2011 Functionality to include and main alternative protocols identified
July 2011 IETF meeting
Aug 2011 Draft with text reflecting agreement of what the protocol set should be
Nov 2010 Documentation specifying mapping of protocol functionality to W3C-specified API produced
Dec 2011 Protocol set specification to IESG
April 2012 API mapping document to IESG
_______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch

On 01/06/11 14:52, DRAGE, Keith (Keith) wrote:
Nowhere have you specified in the milestones what status the intended deliverables are. Indeed, there isn't even an explicit list of deliverables. That has to be added. My thinking goes like:
- Profile document (or documents): Proposed Standard - API mapping document: either Info or Proposed - Scenarios document (I think we need one): Informational Thoughts?
Assuming the profile is intended to be proposed standard, then presumably you need to ensure all the constituent parts are of proposed standard, or some equivalent referenceable standard in some other organisation. The term I prefer in requirements is "stable reference" - we need to know what we refer to. If we have a standards-track and a non-standards-track spec for the same thing, I do think we should most often prefer the standards-track spec, but I don't want to be dogmatic about it. Opus does not yet have a RTP payload format, although I understand one is planned, no drafts exist at the moment. Coordination item for the CODEC WG. iLBC is defined as an experimental RFC - does it need to be upgraded to standards track or is there some other reference.
VP8 has no RTP payload format defined, unless it is masquerading under some other name. I know some people have been working on this, but I don't think there is a draft yet. Presumably you need a paragraph in the charter relating to working with other groups (in particular IETF WG) to ensure that profiled specifications exist and are brought to standards track level. Yes, definitely. regards
Keith
-----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Harald Alvestrand Sent: Thursday, January 06, 2011 11:54 AM To: 'dispatch@ietf.org' Cc: rtc-web@alvestrand.no Subject: [dispatch] Charter proposal: The activity hitherto known as "RTC-WEB at IETF"
This is the first of 3 messages going to the DISPATCH list (in the hope of keeping discussions somewhat organized).
This is the draft of a charter for an IETF working group to consider the subject area of "Real time communication in the Web browser platform". This is one of a paired set of activities, the other one being a W3C activity (either within an existing WG or in a new WG) that defines APIs to this functionality.
The two other messages will contain the W3C proposed charter and a kickoff for what's usually the most distracting topic in any such discussion: The name of the group. Without further ado:
-------------------------------------
Version: 2
Possible Names: <This space deliberately left blank for later discussion>
Body:
Many implementations have been made that use a Web browser to support interactive communications directly between users including voice, video, collaboration and gaming, but until now, such applications have required the installation of nonstandard plugins and browser extensions. There is a desire to standardize such functionality, so that this type of application can be run in any compatible browser.
Traditionally, the W3C has defined API and markup languages such as HTML that work in conjunction with with the IETF over the wire protocols such as HTTP to allow web browsers to display media that does not have real time interactive constraints with another human.
The W3C and IETF plan to collaborate together in their traditional way to meet the evolving needs of browsers. Specifically the IETF will provide a set of on the wire protocols, including RTP, to meet the needs on interactive communications, and the W3C will define the API and markup to allow web application developers to control the on the wire protocols. This will allow application developers to write applications that run in a browser and facilitate interactive communications between users for voice and video communications, collaboration, and gaming.
This working group will select and define a minimal set of protocols that will enable browsers to:
* have interactive real time voice and video between users using RTP * interoperate with compatible voice and video systems that are not web based * support direct flows of non RTP application data between browsers for collaboration and gaming applications
Fortunately very little development of new protocol at IETF is required for this, only selection of existing protocols and selection of minimum capabilities to ensure interoperability. The following protocols are candidates for including in the profile set:
1) RTP/ RTCP
2) a baseline audio codec for high quality interactive audio. Opus will be considered as one of the candidates
3) a baseline audio codec for PSTN interoperability. G.711 and iLBC will be considered
4) a baseline video codec. H.264 and VP8 will be considered
5) Diffserv based QoS
6) NAT traversal using ICE
7) RFC 4833 based DTMF transport
8) RFC 4574 based Label support for identifying streams purpose
9) Secure RTP and keying
10) support for IPv4, IPv6 and dual stack browsers
The working group will cooperate closely with the W3C activity that specifies a semantic level API that allows the control and manipulation of all the functionality above. In addition, the API needs to communicate state information and events about what is happening in the browser that to applications running in the browser. These events and state need to include information such as: receiving RFC 4833 DTMF, RTP and RTCP statistics, state of DTLS/SRTP, and signalling state.
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, LOST, Geolocation, IM& Presence, NSIS, Resource Priority,
Milestones:
February 2011 Candidate "sample" documents circulated to DISPATCH
March 2011 BOF at IETF Prague
April 2011 WG charter approved by IESG. Chosen document sets adopted as WG documents
May 2011 Functionality to include and main alternative protocols identified
July 2011 IETF meeting
Aug 2011 Draft with text reflecting agreement of what the protocol set should be
Nov 2010 Documentation specifying mapping of protocol functionality to W3C-specified API produced
Dec 2011 Protocol set specification to IESG
April 2012 API mapping document to IESG
_______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch

Assuming the profile is intended to be proposed standard, then presumably you need to ensure all the constituent parts are of proposed standard, or some equivalent referenceable standard in some other organisation. The term I prefer in requirements is "stable reference" - we need to know what we refer to. If we have a standards-track and a non-standards-track spec for the same thing, I do think we should most often prefer the standards-track spec, but I don't want to be dogmatic about it.
To profile a document to me has a defined meaning, and at least one ISO have defined, i.e. it takes an existing specification or specifications and states which requirements apply. Mandatory requirements can only be mandatory in the profile. Option requirements can become mandatory in the profile. RFC 2026 seems to use the term "Applicability statement" with much the same meaning. As such, I believe the following applies (quoting from RFC 2026) but this is also my understanding for profile. An AS may not have a higher maturity level in the standards track than any standards-track TS on which the AS relies (see section 4.1). For example, a TS at Draft Standard level may be referenced by an AS at the Proposed Standard or Draft Standard level, but not by an AS at the Standard level. So a profile at proposed standard needs to call up proposed standard specifications. I certainly allow us to take equivalent level documents from other organisations. I agree this is not the most important thing to get the charter resolved, but it may result in some other IETF groups needing to do a little more work than you expect. The biggest impact would be if iLBC is chosen as that has a codec definition (and payload format) at experimental level (RFC 3951 and RFC 3952). As to why they are experimental, I don't know, but I suspect that IETF was required to produce a payload definition, and for that it needed a referencerable document for the codec definition, but did not want to get involved at that time in standards track activity for the codec itself. (Nowadays that would not be a block to producing a standards track payload type). In any case, it would seem to send the wrong message to profile something that is still formally experimental. No issue with your other responses. Keith
-----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Harald Alvestrand Sent: Thursday, January 06, 2011 5:07 PM To: DRAGE, Keith (Keith) Cc: rtc-web@alvestrand.no; 'dispatch@ietf.org' Subject: Re: [dispatch] Charter proposal: The activity hitherto known as "RTC-WEB at IETF"
On 01/06/11 14:52, DRAGE, Keith (Keith) wrote:
Nowhere have you specified in the milestones what status the intended deliverables are. Indeed, there isn't even an explicit list of deliverables. That has to be added. My thinking goes like:
- Profile document (or documents): Proposed Standard - API mapping document: either Info or Proposed - Scenarios document (I think we need one): Informational
Thoughts?
Assuming the profile is intended to be proposed standard, then presumably you need to ensure all the constituent parts are of proposed standard, or some equivalent referenceable standard in some other organisation. The term I prefer in requirements is "stable reference" - we need to know what we refer to. If we have a standards-track and a non-standards-track spec for the same thing, I do think we should most often prefer the standards-track spec, but I don't want to be dogmatic about it. Opus does not yet have a RTP payload format, although I understand one is planned, no drafts exist at the moment. Coordination item for the CODEC WG. iLBC is defined as an experimental RFC - does it need to be upgraded to standards track or is there some other reference.
VP8 has no RTP payload format defined, unless it is masquerading under some other name. I know some people have been working on this, but I don't think there is a draft yet. Presumably you need a paragraph in the charter relating to working with other groups (in particular IETF WG) to ensure that profiled specifications exist and are brought to standards track level. Yes, definitely. regards
Keith
-----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Harald Alvestrand Sent: Thursday, January 06, 2011 11:54 AM To: 'dispatch@ietf.org' Cc: rtc-web@alvestrand.no Subject: [dispatch] Charter proposal: The activity hitherto known as "RTC-WEB at IETF"
This is the first of 3 messages going to the DISPATCH list (in the hope of keeping discussions somewhat organized).
This is the draft of a charter for an IETF working group to consider the subject area of "Real time communication in the Web browser platform". This is one of a paired set of activities, the other one being a W3C activity (either within an existing WG or in a new WG) that defines APIs to this functionality.
The two other messages will contain the W3C proposed charter and a kickoff for what's usually the most distracting topic in any such discussion: The name of the group. Without further ado:
-------------------------------------
Version: 2
Possible Names: <This space deliberately left blank for later discussion>
Body:
Many implementations have been made that use a Web browser to support interactive communications directly between users including voice, video, collaboration and gaming, but until now, such applications have required the installation of nonstandard plugins and browser extensions. There is a desire to standardize such functionality, so that this type of application can be run in any compatible browser.
Traditionally, the W3C has defined API and markup languages such as HTML that work in conjunction with with the IETF over the wire protocols such as HTTP to allow web browsers to display media that does not have real time interactive constraints with another human.
The W3C and IETF plan to collaborate together in their traditional way to meet the evolving needs of browsers. Specifically the IETF will provide a set of on the wire protocols, including RTP, to meet the needs on interactive communications, and the W3C will define the API and markup to allow web application developers to control the on the wire protocols. This will allow application developers to write applications that run in a browser and facilitate interactive communications between users for voice and video communications, collaboration, and gaming.
This working group will select and define a minimal set of protocols that will enable browsers to:
* have interactive real time voice and video between users using RTP * interoperate with compatible voice and video systems that are not web based * support direct flows of non RTP application data between browsers for collaboration and gaming applications
Fortunately very little development of new protocol at IETF is required for this, only selection of existing protocols and selection of minimum capabilities to ensure interoperability. The following protocols are candidates for including in the profile set:
1) RTP/ RTCP
2) a baseline audio codec for high quality interactive audio. Opus will be considered as one of the candidates
3) a baseline audio codec for PSTN interoperability. G.711 and iLBC will be considered
4) a baseline video codec. H.264 and VP8 will be considered
5) Diffserv based QoS
6) NAT traversal using ICE
7) RFC 4833 based DTMF transport
8) RFC 4574 based Label support for identifying streams purpose
9) Secure RTP and keying
10) support for IPv4, IPv6 and dual stack browsers
The working group will cooperate closely with the W3C activity that specifies a semantic level API that allows the control and manipulation of all the functionality above. In addition, the API needs to communicate state information and events about what is happening in the browser that to applications running in the browser. These events and state need to include information such as: receiving RFC 4833 DTMF, RTP and RTCP statistics, state of DTLS/SRTP, and signalling state.
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, LOST, Geolocation, IM& Presence, NSIS, Resource Priority,
Milestones:
February 2011 Candidate "sample" documents circulated to DISPATCH
March 2011 BOF at IETF Prague
April 2011 WG charter approved by IESG. Chosen document sets adopted as WG documents
May 2011 Functionality to include and main alternative protocols identified
July 2011 IETF meeting
Aug 2011 Draft with text reflecting agreement of what the protocol set should be
Nov 2010 Documentation specifying mapping of protocol functionality to W3C-specified API produced
Dec 2011 Protocol set specification to IESG
April 2012 API mapping document to IESG
_______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch

Hi Harald, Thanks for putting this together; some discussion in-line. On Thu, Jan 6, 2011 at 3:53 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
This is the first of 3 messages going to the DISPATCH list (in the hope of keeping discussions somewhat organized).
This is the draft of a charter for an IETF working group to consider the subject area of "Real time communication in the Web browser platform". This is one of a paired set of activities, the other one being a W3C activity (either within an existing WG or in a new WG) that defines APIs to this functionality.
The two other messages will contain the W3C proposed charter and a kickoff for what's usually the most distracting topic in any such discussion: The name of the group. Without further ado:
-------------------------------------
Version: 2
Possible Names: <This space deliberately left blank for later discussion>
Body:
Many implementations have been made that use a Web browser to support interactive communications directly between users including voice, video, collaboration and gaming, but until now, such applications have required the installation of nonstandard plugins and browser extensions. There is a desire to standardize such functionality, so that this type of application can be run in any compatible browser.
In at least some of the contexts identified above, there is a long-lived identifier associated with the individuals who will have interactive communications; that is, there is a context-specific presence architecture in addition to the implementation-specific real-time communications. Though the text below occasionally says "users", there does not seem to be any work being defined that would touch on this. I see that in the last sentence you explicitly rule it out of scope. Without this, this seems to be limited to an architecture where a mediating server provides the initial signaling path. If that is the scope, I think that should be made explicit as a design statement, not inferred from the lack of presence.
Traditionally, the W3C has defined API and markup languages such as HTML that work in conjunction with with the IETF over the wire protocols such as HTTP to allow web browsers to display media that does not have real time interactive constraints with another human.
The W3C and IETF plan to collaborate together in their traditional way to meet the evolving needs of browsers. Specifically the IETF will provide a set of on the wire protocols, including RTP, to meet the needs on interactive communications, and the W3C will define the API and markup to allow web application developers to control the on the wire protocols. This will allow application developers to write applications that run in a browser and facilitate interactive communications between users for voice and video communications, collaboration, and gaming.
This working group will select and define a minimal set of protocols that will enable browsers to:
* have interactive real time voice and video between users using RTP * interoperate with compatible voice and video systems that are not web based
* support direct flows of non RTP application data between browsers for collaboration and gaming applications
Okay "direct flows of non-RTP application data" goes beyond scope creep; to satisfy this completely, we are talking an end-point-to-end-point tunnel, which will run afoul of a lot of folks who dearly love packet inspection. I would say that it would be best to first tackle the voice/video bits and then tackle this problem. Re-charter the WG to cover this, in other words, after the first bit is done. I also note that you're using "between browsers", rather than "among browsers". Is it intended that this facility should allow for multi-party communication? Leaving aside the non-RTP issues, that would add floor control, media mixing, etc. to the task list. Again, I think it should either be explicitly in-scope or out-of-scope.
Fortunately very little development of new protocol at IETF is required for this, only selection of existing protocols and selection of minimum capabilities to ensure interoperability. The following protocols are candidates for including in the profile set:
1) RTP/ RTCP
2) a baseline audio codec for high quality interactive audio. Opus will be considered as one of the candidates
3) a baseline audio codec for PSTN interoperability. G.711 and iLBC will be considered
4) a baseline video codec. H.264 and VP8 will be considered
5) Diffserv based QoS
6) NAT traversal using ICE
The ICE spec is clear that the NAT traversal it provides does not help establish the signaling between agents. For this browser-to-browser mechanism, if we are limiting this to situations where a mediating web server provides the initial signaling path, that's okay. If there is a different model, though, we may need additional tools here.
7) RFC 4833 based DTMF transport
8) RFC 4574 based Label support for identifying streams purpose
9) Secure RTP and keying
10) support for IPv4, IPv6 and dual stack browsers
The working group will cooperate closely with the W3C activity that specifies a semantic level API that allows the control and manipulation of all the functionality above. In addition, the API needs to communicate state information and events about what is happening in the browser that to applications running in the browser.
I think the sentence above has some extra words; is the browser talking to application running in the browser? Can it be re-phrased? These events and state need to include
information such as: receiving RFC 4833 DTMF, RTP and RTCP statistics, state of DTLS/SRTP, and signalling state.
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, LOST, Geolocation, IM & Presence, NSIS, Resource Priority,
Milestones:
February 2011 Candidate "sample" documents circulated to DISPATCH
March 2011 BOF at IETF Prague
April 2011 WG charter approved by IESG. Chosen document sets adopted as WG documents
May 2011 Functionality to include and main alternative protocols identified
July 2011 IETF meeting
Aug 2011 Draft with text reflecting agreement of what the protocol set should be
Nov 2010 Documentation specifying mapping of protocol functionality to W3C-specified API produced
Dec 2011 Protocol set specification to IESG
April 2012 API mapping document to IESG
Pretty aggressive, given the number of moving parts. It's also not clear why the November 2011 doc (I assume 2010 is a typo) is done in the IETF, rather than the W3C. Or is it joint work? regards, Ted Hardie
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web

Okay "direct flows of non-RTP application data" goes beyond scope creep; to satisfy this completely, we are talking an end-point-to-end-point tunnel, which will run afoul of a lot of folks who dearly love packet inspection.
Why should the IETF and W3C abide by the folks who love deep packet inspection? I would like to see some IESG guidance here, since it is contrary to Internet and to the Web. Break of privacy, etc. To accelerate clarity here, what does Harald and people on the list think? Thanks, Henry On 1/6/11 12:43 PM, "Ted Hardie" <ted.ietf@gmail.com> wrote:
Hi Harald,
Thanks for putting this together; some discussion in-line.
On Thu, Jan 6, 2011 at 3:53 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
This is the first of 3 messages going to the DISPATCH list (in the hope of keeping discussions somewhat organized).
This is the draft of a charter for an IETF working group to consider the subject area of "Real time communication in the Web browser platform". This is one of a paired set of activities, the other one being a W3C activity (either within an existing WG or in a new WG) that defines APIs to this functionality.
The two other messages will contain the W3C proposed charter and a kickoff for what's usually the most distracting topic in any such discussion: The name of the group. Without further ado:
-------------------------------------
Version: 2
Possible Names: <This space deliberately left blank for later discussion>
Body:
Many implementations have been made that use a Web browser to support interactive communications directly between users including voice, video, collaboration and gaming, but until now, such applications have required the installation of nonstandard plugins and browser extensions. There is a desire to standardize such functionality, so that this type of application can be run in any compatible browser.
In at least some of the contexts identified above, there is a long-lived identifier associated with the individuals who will have interactive communications; that is, there is a context-specific presence architecture in addition to the implementation-specific real-time communications. Though the text below occasionally says "users", there does not seem to be any work being defined that would touch on this. I see that in the last sentence you explicitly rule it out of scope. Without this, this seems to be limited to an architecture where a mediating server provides the initial signaling path. If that is the scope, I think that should be made explicit as a design statement, not inferred from the lack of presence.
Traditionally, the W3C has defined API and markup languages such as HTML that work in conjunction with with the IETF over the wire protocols such as HTTP to allow web browsers to display media that does not have real time interactive constraints with another human.
The W3C and IETF plan to collaborate together in their traditional way to meet the evolving needs of browsers. Specifically the IETF will provide a set of on the wire protocols, including RTP, to meet the needs on interactive communications, and the W3C will define the API and markup to allow web application developers to control the on the wire protocols. This will allow application developers to write applications that run in a browser and facilitate interactive communications between users for voice and video communications, collaboration, and gaming.
This working group will select and define a minimal set of protocols that will enable browsers to:
* have interactive real time voice and video between users using RTP * interoperate with compatible voice and video systems that are not web based
* support direct flows of non RTP application data between browsers for collaboration and gaming applications
Okay "direct flows of non-RTP application data" goes beyond scope creep; to satisfy this completely, we are talking an end-point-to-end-point tunnel, which will run afoul of a lot of folks who dearly love packet inspection. I would say that it would be best to first tackle the voice/video bits and then tackle this problem. Re-charter the WG to cover this, in other words, after the first bit is done.
I also note that you're using "between browsers", rather than "among browsers". Is it intended that this facility should allow for multi-party communication? Leaving aside the non-RTP issues, that would add floor control, media mixing, etc. to the task list. Again, I think it should either be explicitly in-scope or out-of-scope.
Fortunately very little development of new protocol at IETF is required for this, only selection of existing protocols and selection of minimum capabilities to ensure interoperability. The following protocols are candidates for including in the profile set:
1) RTP/ RTCP
2) a baseline audio codec for high quality interactive audio. Opus will be considered as one of the candidates
3) a baseline audio codec for PSTN interoperability. G.711 and iLBC will be considered
4) a baseline video codec. H.264 and VP8 will be considered
5) Diffserv based QoS
6) NAT traversal using ICE
The ICE spec is clear that the NAT traversal it provides does not help establish the signaling between agents. For this browser-to-browser mechanism, if we are limiting this to situations where a mediating web server provides the initial signaling path, that's okay. If there is a different model, though, we may need additional tools here.
7) RFC 4833 based DTMF transport
8) RFC 4574 based Label support for identifying streams purpose
9) Secure RTP and keying
10) support for IPv4, IPv6 and dual stack browsers
The working group will cooperate closely with the W3C activity that specifies a semantic level API that allows the control and manipulation of all the functionality above. In addition, the API needs to communicate state information and events about what is happening in the browser that to applications running in the browser.
I think the sentence above has some extra words; is the browser talking to application running in the browser? Can it be re-phrased?
These events and state need to include
information such as: receiving RFC 4833 DTMF, RTP and RTCP statistics, state of DTLS/SRTP, and signalling state.
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, LOST, Geolocation, IM & Presence, NSIS, Resource Priority,
Milestones:
February 2011 Candidate "sample" documents circulated to DISPATCH
March 2011 BOF at IETF Prague
April 2011 WG charter approved by IESG. Chosen document sets adopted as WG documents
May 2011 Functionality to include and main alternative protocols identified
July 2011 IETF meeting
Aug 2011 Draft with text reflecting agreement of what the protocol set should be
Nov 2010 Documentation specifying mapping of protocol functionality to W3C-specified API produced
Dec 2011 Protocol set specification to IESG
April 2012 API mapping document to IESG
Pretty aggressive, given the number of moving parts. It's also not clear why the November 2011 doc (I assume 2010 is a typo) is done in the IETF, rather than the W3C. Or is it joint work?
regards,
Ted Hardie
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch

On Thu, Jan 6, 2011 at 11:18 AM, Henry Sinnreich <henry.sinnreich@gmail.com> wrote:
Okay "direct flows of non-RTP application data" goes beyond scope creep; to satisfy this completely, we are talking an end-point-to-end-point tunnel, which will run afoul of a lot of folks who dearly love packet inspection.
Why should the IETF and W3C abide by the folks who love deep packet inspection? I would like to see some IESG guidance here, since it is contrary to Internet and to the Web. Break of privacy, etc.
To accelerate clarity here, what does Harald and people on the list think?
Thanks, Henry
Hi Henry, I'm not a huge fan of packet inspection. But "any application data" is clearly well beyond the audio/video use case that motivated this work in the first place. I expect that it would make firewall traversal significantly harder unless it lost privacy; that trade-off would make the voice/video privacy *worse*. It also will make the communication among browsers in a multi-party mode move from known issues (media mixing and floor control) to something closer to that of an overlay network. That's not impossible (setting up an overlay when you have a rendezvous server, basically moves it from mediating the signaling path to being an enrollment server), but is also not simple. Is it really needed for job one here? regards, Ted
On 1/6/11 12:43 PM, "Ted Hardie" <ted.ietf@gmail.com> wrote:
Hi Harald,
Thanks for putting this together; some discussion in-line.
On Thu, Jan 6, 2011 at 3:53 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
This is the first of 3 messages going to the DISPATCH list (in the hope of keeping discussions somewhat organized).
This is the draft of a charter for an IETF working group to consider the subject area of "Real time communication in the Web browser platform". This is one of a paired set of activities, the other one being a W3C activity (either within an existing WG or in a new WG) that defines APIs to this functionality.
The two other messages will contain the W3C proposed charter and a kickoff for what's usually the most distracting topic in any such discussion: The name of the group. Without further ado:
-------------------------------------
Version: 2
Possible Names: <This space deliberately left blank for later discussion>
Body:
Many implementations have been made that use a Web browser to support interactive communications directly between users including voice, video, collaboration and gaming, but until now, such applications have required the installation of nonstandard plugins and browser extensions. There is a desire to standardize such functionality, so that this type of application can be run in any compatible browser.
In at least some of the contexts identified above, there is a long-lived identifier associated with the individuals who will have interactive communications; that is, there is a context-specific presence architecture in addition to the implementation-specific real-time communications. Though the text below occasionally says "users", there does not seem to be any work being defined that would touch on this. I see that in the last sentence you explicitly rule it out of scope. Without this, this seems to be limited to an architecture where a mediating server provides the initial signaling path. If that is the scope, I think that should be made explicit as a design statement, not inferred from the lack of presence.
Traditionally, the W3C has defined API and markup languages such as HTML that work in conjunction with with the IETF over the wire protocols such as HTTP to allow web browsers to display media that does not have real time interactive constraints with another human.
The W3C and IETF plan to collaborate together in their traditional way to meet the evolving needs of browsers. Specifically the IETF will provide a set of on the wire protocols, including RTP, to meet the needs on interactive communications, and the W3C will define the API and markup to allow web application developers to control the on the wire protocols. This will allow application developers to write applications that run in a browser and facilitate interactive communications between users for voice and video communications, collaboration, and gaming.
This working group will select and define a minimal set of protocols that will enable browsers to:
* have interactive real time voice and video between users using RTP * interoperate with compatible voice and video systems that are not web based
* support direct flows of non RTP application data between browsers for collaboration and gaming applications
Okay "direct flows of non-RTP application data" goes beyond scope creep; to satisfy this completely, we are talking an end-point-to-end-point tunnel, which will run afoul of a lot of folks who dearly love packet inspection. I would say that it would be best to first tackle the voice/video bits and then tackle this problem. Re-charter the WG to cover this, in other words, after the first bit is done.
I also note that you're using "between browsers", rather than "among browsers". Is it intended that this facility should allow for multi-party communication? Leaving aside the non-RTP issues, that would add floor control, media mixing, etc. to the task list. Again, I think it should either be explicitly in-scope or out-of-scope.
Fortunately very little development of new protocol at IETF is required for this, only selection of existing protocols and selection of minimum capabilities to ensure interoperability. The following protocols are candidates for including in the profile set:
1) RTP/ RTCP
2) a baseline audio codec for high quality interactive audio. Opus will be considered as one of the candidates
3) a baseline audio codec for PSTN interoperability. G.711 and iLBC will be considered
4) a baseline video codec. H.264 and VP8 will be considered
5) Diffserv based QoS
6) NAT traversal using ICE
The ICE spec is clear that the NAT traversal it provides does not help establish the signaling between agents. For this browser-to-browser mechanism, if we are limiting this to situations where a mediating web server provides the initial signaling path, that's okay. If there is a different model, though, we may need additional tools here.
7) RFC 4833 based DTMF transport
8) RFC 4574 based Label support for identifying streams purpose
9) Secure RTP and keying
10) support for IPv4, IPv6 and dual stack browsers
The working group will cooperate closely with the W3C activity that specifies a semantic level API that allows the control and manipulation of all the functionality above. In addition, the API needs to communicate state information and events about what is happening in the browser that to applications running in the browser.
I think the sentence above has some extra words; is the browser talking to application running in the browser? Can it be re-phrased?
These events and state need to include
information such as: receiving RFC 4833 DTMF, RTP and RTCP statistics, state of DTLS/SRTP, and signalling state.
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, LOST, Geolocation, IM & Presence, NSIS, Resource Priority,
Milestones:
February 2011 Candidate "sample" documents circulated to DISPATCH
March 2011 BOF at IETF Prague
April 2011 WG charter approved by IESG. Chosen document sets adopted as WG documents
May 2011 Functionality to include and main alternative protocols identified
July 2011 IETF meeting
Aug 2011 Draft with text reflecting agreement of what the protocol set should be
Nov 2010 Documentation specifying mapping of protocol functionality to W3C-specified API produced
Dec 2011 Protocol set specification to IESG
April 2012 API mapping document to IESG
Pretty aggressive, given the number of moving parts. It's also not clear why the November 2011 doc (I assume 2010 is a typo) is done in the IETF, rather than the W3C. Or is it joint work?
regards,
Ted Hardie
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch

On Jan 6, 2011, at 2:18 PM, Henry Sinnreich wrote:
Okay "direct flows of non-RTP application data" goes beyond scope creep; to satisfy this completely, we are talking an end-point-to-end-point tunnel, which will run afoul of a lot of folks who dearly love packet inspection.
Why should the IETF and W3C abide by the folks who love deep packet inspection? I would like to see some IESG guidance here, since it is contrary to Internet and to the Web. Break of privacy, etc.
To accelerate clarity here, what does Harald and people on the list think?
As far as I know, there have never had any DPI concerns raised in AMT, which is a tunneling protocol (which might BTW have useful pieces if tunneling is needed here). http://tools.ietf.org/html/draft-ietf-mboned-auto-multicast-10 Regards Marshall
Thanks, Henry
On 1/6/11 12:43 PM, "Ted Hardie" <ted.ietf@gmail.com> wrote:
Hi Harald,
Thanks for putting this together; some discussion in-line.
On Thu, Jan 6, 2011 at 3:53 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
This is the first of 3 messages going to the DISPATCH list (in the hope of keeping discussions somewhat organized).
This is the draft of a charter for an IETF working group to consider the subject area of "Real time communication in the Web browser platform". This is one of a paired set of activities, the other one being a W3C activity (either within an existing WG or in a new WG) that defines APIs to this functionality.
The two other messages will contain the W3C proposed charter and a kickoff for what's usually the most distracting topic in any such discussion: The name of the group. Without further ado:
-------------------------------------
Version: 2
Possible Names: <This space deliberately left blank for later discussion>
Body:
Many implementations have been made that use a Web browser to support interactive communications directly between users including voice, video, collaboration and gaming, but until now, such applications have required the installation of nonstandard plugins and browser extensions. There is a desire to standardize such functionality, so that this type of application can be run in any compatible browser.
In at least some of the contexts identified above, there is a long-lived identifier associated with the individuals who will have interactive communications; that is, there is a context-specific presence architecture in addition to the implementation-specific real-time communications. Though the text below occasionally says "users", there does not seem to be any work being defined that would touch on this. I see that in the last sentence you explicitly rule it out of scope. Without this, this seems to be limited to an architecture where a mediating server provides the initial signaling path. If that is the scope, I think that should be made explicit as a design statement, not inferred from the lack of presence.
Traditionally, the W3C has defined API and markup languages such as HTML that work in conjunction with with the IETF over the wire protocols such as HTTP to allow web browsers to display media that does not have real time interactive constraints with another human.
The W3C and IETF plan to collaborate together in their traditional way to meet the evolving needs of browsers. Specifically the IETF will provide a set of on the wire protocols, including RTP, to meet the needs on interactive communications, and the W3C will define the API and markup to allow web application developers to control the on the wire protocols. This will allow application developers to write applications that run in a browser and facilitate interactive communications between users for voice and video communications, collaboration, and gaming.
This working group will select and define a minimal set of protocols that will enable browsers to:
* have interactive real time voice and video between users using RTP * interoperate with compatible voice and video systems that are not web based
* support direct flows of non RTP application data between browsers for collaboration and gaming applications
Okay "direct flows of non-RTP application data" goes beyond scope creep; to satisfy this completely, we are talking an end-point-to-end-point tunnel, which will run afoul of a lot of folks who dearly love packet inspection. I would say that it would be best to first tackle the voice/video bits and then tackle this problem. Re-charter the WG to cover this, in other words, after the first bit is done.
I also note that you're using "between browsers", rather than "among browsers". Is it intended that this facility should allow for multi-party communication? Leaving aside the non-RTP issues, that would add floor control, media mixing, etc. to the task list. Again, I think it should either be explicitly in-scope or out-of-scope.
Fortunately very little development of new protocol at IETF is required for this, only selection of existing protocols and selection of minimum capabilities to ensure interoperability. The following protocols are candidates for including in the profile set:
1) RTP/ RTCP
2) a baseline audio codec for high quality interactive audio. Opus will be considered as one of the candidates
3) a baseline audio codec for PSTN interoperability. G.711 and iLBC will be considered
4) a baseline video codec. H.264 and VP8 will be considered
5) Diffserv based QoS
6) NAT traversal using ICE
The ICE spec is clear that the NAT traversal it provides does not help establish the signaling between agents. For this browser-to-browser mechanism, if we are limiting this to situations where a mediating web server provides the initial signaling path, that's okay. If there is a different model, though, we may need additional tools here.
7) RFC 4833 based DTMF transport
8) RFC 4574 based Label support for identifying streams purpose
9) Secure RTP and keying
10) support for IPv4, IPv6 and dual stack browsers
The working group will cooperate closely with the W3C activity that specifies a semantic level API that allows the control and manipulation of all the functionality above. In addition, the API needs to communicate state information and events about what is happening in the browser that to applications running in the browser.
I think the sentence above has some extra words; is the browser talking to application running in the browser? Can it be re-phrased?
These events and state need to include
information such as: receiving RFC 4833 DTMF, RTP and RTCP statistics, state of DTLS/SRTP, and signalling state.
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, LOST, Geolocation, IM & Presence, NSIS, Resource Priority,
Milestones:
February 2011 Candidate "sample" documents circulated to DISPATCH
March 2011 BOF at IETF Prague
April 2011 WG charter approved by IESG. Chosen document sets adopted as WG documents
May 2011 Functionality to include and main alternative protocols identified
July 2011 IETF meeting
Aug 2011 Draft with text reflecting agreement of what the protocol set should be
Nov 2010 Documentation specifying mapping of protocol functionality to W3C-specified API produced
Dec 2011 Protocol set specification to IESG
April 2012 API mapping document to IESG
Pretty aggressive, given the number of moving parts. It's also not clear why the November 2011 doc (I assume 2010 is a typo) is done in the IETF, rather than the W3C. Or is it joint work?
regards,
Ted Hardie
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web

On 01/06/11 20:18, Henry Sinnreich wrote:
Okay "direct flows of non-RTP application data" goes beyond scope creep; to satisfy this completely, we are talking an end-point-to-end-point tunnel, which will run afoul of a lot of folks who dearly love packet inspection. Why should the IETF and W3C abide by the folks who love deep packet inspection? I would like to see some IESG guidance here, since it is contrary to Internet and to the Web. Break of privacy, etc.
To accelerate clarity here, what does Harald and people on the list think? My personal opinion:
At the workshop, several use cases were identified where stuff that is not audio or video needed to be communicated from one browser to another quickly enough that relaying via backend web server(s) is problematic - the canonical poster child is the movement of bullets in a first-person shooter game, but there are other cases; I think Lisa mentioned that in Second Life, the placement of audio sources in the stereo field needs to be communicated reasonably synchronously with the sound itself. I am hesitant to rule point-to-point traffic that isn't audio or video out of scope, given the discussion at the workshop; certainly, given the RAVEN RFC (RFC 2804), I do not want to rule it out of scope because it's hard to write packet inspection state machines that can tell what's going on here. Harald

On Thu, Jan 6, 2011 at 12:54 PM, Harald Alvestrand <harald@alvestrand.no>wrote:
On 01/06/11 20:18, Henry Sinnreich wrote:
Okay "direct flows of non-RTP application data" goes beyond scope creep;
to satisfy this completely, we are talking an end-point-to-end-point tunnel, which will run afoul of a lot of folks who dearly love packet inspection.
Why should the IETF and W3C abide by the folks who love deep packet inspection? I would like to see some IESG guidance here, since it is contrary to Internet and to the Web. Break of privacy, etc.
To accelerate clarity here, what does Harald and people on the list think?
My personal opinion:
At the workshop, several use cases were identified where stuff that is not audio or video needed to be communicated from one browser to another quickly enough that relaying via backend web server(s) is problematic - the canonical poster child is the movement of bullets in a first-person shooter game, but there are other cases; I think Lisa mentioned that in Second Life, the placement of audio sources in the stereo field needs to be communicated reasonably synchronously with the sound itself.
I am hesitant to rule point-to-point traffic that isn't audio or video out of scope, given the discussion at the workshop; certainly, given the RAVEN RFC (RFC 2804), I do not want to rule it out of scope because it's hard to write packet inspection state machines that can tell what's going on here.
Right. The thinking was that since we need to do a fair amount of work to allow audio and video to be exchanged safely and reliably peer-to-peer, we should allow web applications (with some limits) to use this transport mechanism for exchanging their own application data. The plan also is to be able to leverage DTLS to allow the creation of secure transports, which will have additional implications for DPI.
Harald
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web

On Thu, Jan 6, 2011 at 1:25 PM, Justin Uberti <juberti@google.com> wrote:
Right. The thinking was that since we need to do a fair amount of work to allow audio and video to be exchanged safely and reliably peer-to-peer, we should allow web applications (with some limits) to use this transport mechanism for exchanging their own application data.
From a practical perspective, once you say "application data", the ability to limit this seems to approach zero pretty quickly. Even ignoring the network-based firewall, doesn't this now require me to have a browser-based firewall, to express my policies for what traffic I permit over this?
The plan also is to be able to leverage DTLS to allow the creation of secure transports, which will have additional implications for DPI.
Agreed. More importantly, I think that reinforces the idea that this is not a simple add-on to audio/video functionality. As I argued in draft-hardie-mdtls-session, you are really creating a multi-flow session layer. I personally think that's a fine thing, but it is not an adjunct to a charter-it's the top-line bullet item in my view. regards, Ted PS. As an aside, both Jake and I have since left Panasonic and the project mentioned in the draft cited above. I do not believe that the sponsor lab will release the code created for it at this time so the discussion I had with some folks on that in Beijing will likely need to take other paths.
Harald
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web

On Thu, Jan 6, 2011 at 2:00 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
On Thu, Jan 6, 2011 at 1:25 PM, Justin Uberti <juberti@google.com> wrote:
Right. The thinking was that since we need to do a fair amount of work to allow audio and video to be exchanged safely and reliably peer-to-peer, we should allow web applications (with some limits) to use this transport mechanism for exchanging their own application data.
From a practical perspective, once you say "application data", the ability to limit this seems to approach zero pretty quickly. Even ignoring the network-based firewall, doesn't this now require me to have a browser-based firewall, to express my policies for what traffic I permit over this?
The connection is limited by the browser same-origin policy, so the application can only connect to places blessed by the application server, similar to XmlHttpRequest. We don't worry about apps making XmlHttpRequest over TLS, where there is little ability to control the data, and I think we should try to think of these transports the same way.
The plan also is to be able to leverage DTLS to allow the creation of secure transports, which will have additional implications for DPI.
Agreed. More importantly, I think that reinforces the idea that this is not a simple add-on to audio/video functionality. As I argued in draft-hardie-mdtls-session, you are really creating a multi-flow session layer. I personally think that's a fine thing, but it is not an adjunct to a charter-it's the top-line bullet item in my view.
regards,
Ted
PS. As an aside, both Jake and I have since left Panasonic and the project mentioned in the draft cited above. I do not believe that the sponsor lab will release the code created for it at this time so the discussion I had with some folks on that in Beijing will likely need to take other paths.
Harald
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web

On Thu, Jan 6, 2011 at 2:32 PM, Justin Uberti <juberti@google.com> wrote:
The connection is limited by the browser same-origin policy, so the application can only connect to places blessed by the application server, similar to XmlHttpRequest. We don't worry about apps making XmlHttpRequest over TLS, where there is little ability to control the data, and I think we should try to think of these transports the same way.
First, I'm not sure that everyone has the same view "of not worry" here. Second, I'm really not sure that the threat model is the same. If I have an open pipe between any two peers which can carry any traffic which fits over DTLS, the situation is a bit different from that where https is running through to a server. And the chances that someone terminates and re-originates the TLS flow seems to me to go up in some common cases if it has this characteristic. But I think the charter comment for now is that this is a major chunk of work, and that it has considerations outside those for audio and video. To me, that means it needs to be called out (either in its own documents or in a re-charter), so that it doesn't gate the base functionality. Please remember as well that just because the initiating use case for this protocol work is browser based there is no reason to presume that it will stay browser based for all time. Even in this framework a browser-initiated DTLS flow could be handed off to another "helper" app. Again, I think this is potentially a lot of work. That doesn't mean I think it is bad work; I think it means it has to be scoped appropriately. regards, Ted
The plan also is to be able to leverage DTLS to allow the creation of secure transports, which will have additional implications for DPI.
Agreed. More importantly, I think that reinforces the idea that this is not a simple add-on to audio/video functionality. As I argued in draft-hardie-mdtls-session, you are really creating a multi-flow session layer. I personally think that's a fine thing, but it is not an adjunct to a charter-it's the top-line bullet item in my view.
regards,
Ted
PS. As an aside, both Jake and I have since left Panasonic and the project mentioned in the draft cited above. I do not believe that the sponsor lab will release the code created for it at this time so the discussion I had with some folks on that in Beijing will likely need to take other paths.
Harald
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web

On 01/06/11 19:43, Ted Hardie wrote:
Hi Harald,
Thanks for putting this together; some discussion in-line.
On Thu, Jan 6, 2011 at 3:53 AM, Harald Alvestrand<harald@alvestrand.no> wrote:
This is the first of 3 messages going to the DISPATCH list (in the hope of keeping discussions somewhat organized).
This is the draft of a charter for an IETF working group to consider the subject area of "Real time communication in the Web browser platform". This is one of a paired set of activities, the other one being a W3C activity (either within an existing WG or in a new WG) that defines APIs to this functionality.
The two other messages will contain the W3C proposed charter and a kickoff for what's usually the most distracting topic in any such discussion: The name of the group. Without further ado:
-------------------------------------
Version: 2
Possible Names: <This space deliberately left blank for later discussion>
Body:
Many implementations have been made that use a Web browser to support interactive communications directly between users including voice, video, collaboration and gaming, but until now, such applications have required the installation of nonstandard plugins and browser extensions. There is a desire to standardize such functionality, so that this type of application can be run in any compatible browser.
In at least some of the contexts identified above, there is a long-lived identifier associated with the individuals who will have interactive communications; that is, there is a context-specific presence architecture in addition to the implementation-specific real-time communications. Though the text below occasionally says "users", there does not seem to be any work being defined that would touch on this. I see that in the last sentence you explicitly rule it out of scope. Without this, this seems to be limited to an architecture where a mediating server provides the initial signaling path. If that is the scope, I think that should be made explicit as a design statement, not inferred from the lack of presence. I think what you mean is that at this level, we're not taking a position on what an "user" is, or whether the concept of "user" even has meaning for the application (think chatroulette for one example of an application where there are no long-lived user identifiers).
I would certainly agree that this is a reasonable restriction of our work, and would welcome suggested text on how to write that into the charter.
Traditionally, the W3C has defined API and markup languages such as HTML that work in conjunction with with the IETF over the wire protocols such as HTTP to allow web browsers to display media that does not have real time interactive constraints with another human.
The W3C and IETF plan to collaborate together in their traditional way to meet the evolving needs of browsers. Specifically the IETF will provide a set of on the wire protocols, including RTP, to meet the needs on interactive communications, and the W3C will define the API and markup to allow web application developers to control the on the wire protocols. This will allow application developers to write applications that run in a browser and facilitate interactive communications between users for voice and video communications, collaboration, and gaming.
This working group will select and define a minimal set of protocols that will enable browsers to:
* have interactive real time voice and video between users using RTP * interoperate with compatible voice and video systems that are not web based * support direct flows of non RTP application data between browsers for collaboration and gaming applications
Okay "direct flows of non-RTP application data" goes beyond scope creep; to satisfy this completely, we are talking an end-point-to-end-point tunnel, which will run afoul of a lot of folks who dearly love packet inspection. I would say that it would be best to first tackle the voice/video bits and then tackle this problem. Re-charter the WG to cover this, in other words, after the first bit is done.
I also note that you're using "between browsers", rather than "among browsers". Is it intended that this facility should allow for multi-party communication? Leaving aside the non-RTP issues, that would add floor control, media mixing, etc. to the task list. Again, I think it should either be explicitly in-scope or out-of-scope. I did not intend "between" to indicate that there were only two parties, but think that we're building point-to-point communications, not N-to-N.
In one interpretation of the distinction .... I think we're standardizing point-to-point communications at this time, since all the proven-viable multipoint communication applications have been built out of point-to-point links rather than using underlying multipoint technologies like multicast. In another interpretation ... I think we should limit ourselves to providing a toolbox. I think floor control (except for possibly providing the signalling channels floor control needs) is out of scope; MAITAI may be a better place to discuss media mixing.
Fortunately very little development of new protocol at IETF is required for this, only selection of existing protocols and selection of minimum capabilities to ensure interoperability. The following protocols are candidates for including in the profile set:
1) RTP/ RTCP
2) a baseline audio codec for high quality interactive audio. Opus will be considered as one of the candidates
3) a baseline audio codec for PSTN interoperability. G.711 and iLBC will be considered
4) a baseline video codec. H.264 and VP8 will be considered
5) Diffserv based QoS
6) NAT traversal using ICE
The ICE spec is clear that the NAT traversal it provides does not help establish the signaling between agents. For this browser-to-browser mechanism, if we are limiting this to situations where a mediating web server provides the initial signaling path, that's okay. If there is a different model, though, we may need additional tools here. If we can make the mediating-web-server model work, I think we have success; if we can't make it work, we have a failure. So obviously that's my first priority. What text changes do you think are needed?
7) RFC 4833 based DTMF transport
8) RFC 4574 based Label support for identifying streams purpose
9) Secure RTP and keying
10) support for IPv4, IPv6 and dual stack browsers
The working group will cooperate closely with the W3C activity that specifies a semantic level API that allows the control and manipulation of all the functionality above. In addition, the API needs to communicate state information and events about what is happening in the browser that to applications running in the browser. I think the sentence above has some extra words; is the browser talking to application running in the browser? Can it be re-phrased? I think there's an extra "that" - when an event happens at the communications interface, this event needs to be propagated over the API to the Javascript that is running in a Web page - that Web page is what I've been thinking of as "the application". (There are other moves around that want to run "web pages" in other contexts than a currently open tab in a broswer, but for the moment, "a tab in a browser", or even "a set of tabs in a browser" is a reasonable synonym for "application", I think). These events and state need to include information such as: receiving RFC 4833 DTMF, RTP and RTCP statistics, state of DTLS/SRTP, and signalling state.
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, LOST, Geolocation, IM& Presence, NSIS, Resource Priority,
Milestones:
February 2011 Candidate "sample" documents circulated to DISPATCH
March 2011 BOF at IETF Prague
April 2011 WG charter approved by IESG. Chosen document sets adopted as WG documents
May 2011 Functionality to include and main alternative protocols identified
July 2011 IETF meeting
Aug 2011 Draft with text reflecting agreement of what the protocol set should be
Nov 2010 Documentation specifying mapping of protocol functionality to W3C-specified API produced
Dec 2011 Protocol set specification to IESG
April 2012 API mapping document to IESG
Pretty aggressive, given the number of moving parts. It's also not clear why the November 2011 doc (I assume 2010 is a typo) is done in the IETF, rather than the W3C. Or is it joint work? More or less done this way at random. I think of this as joint work; documents may move between the organizations as we progress, but I'm not sure how the W3C document model works yet.

Hi Harald, Some replies in-line. On Fri, Jan 7, 2011 at 5:30 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
On 01/06/11 19:43, Ted Hardie wrote:
Hi Harald,
Thanks for putting this together; some discussion in-line.
On Thu, Jan 6, 2011 at 3:53 AM, Harald Alvestrand<harald@alvestrand.no> wrote:
This is the first of 3 messages going to the DISPATCH list (in the hope of keeping discussions somewhat organized).
This is the draft of a charter for an IETF working group to consider the subject area of "Real time communication in the Web browser platform". This is one of a paired set of activities, the other one being a W3C activity (either within an existing WG or in a new WG) that defines APIs to this functionality.
The two other messages will contain the W3C proposed charter and a kickoff for what's usually the most distracting topic in any such discussion: The name of the group. Without further ado:
-------------------------------------
Version: 2
Possible Names: <This space deliberately left blank for later discussion>
Body:
Many implementations have been made that use a Web browser to support interactive communications directly between users including voice, video, collaboration and gaming, but until now, such applications have required the installation of nonstandard plugins and browser extensions. There is a desire to standardize such functionality, so that this type of application can be run in any compatible browser.
In at least some of the contexts identified above, there is a long-lived identifier associated with the individuals who will have interactive communications; that is, there is a context-specific presence architecture in addition to the implementation-specific real-time communications. Though the text below occasionally says "users", there does not seem to be any work being defined that would touch on this. I see that in the last sentence you explicitly rule it out of scope. Without this, this seems to be limited to an architecture where a mediating server provides the initial signaling path. If that is the scope, I think that should be made explicit as a design statement, not inferred from the lack of presence.
I think what you mean is that at this level, we're not taking a position on what an "user" is, or whether the concept of "user" even has meaning for the application (think chatroulette for one example of an application where there are no long-lived user identifiers).
I would certainly agree that this is a reasonable restriction of our work, and would welcome suggested text on how to write that into the charter.
How about: Many implementations have been made that use a Web browser to support direct, interactive communications, including voice, video, collaboration, and gaming. In these implementations, the web server acts as the signaling path between these applications, using locally significant identifiers to set up the association. Up till now, such applications have typically required the installation of plugins or non-standard browser extensions. There is a desire to standardize this functionality, so that this type of application can be run in any compatible browser.
Traditionally, the W3C has defined API and markup languages such as HTML that work in conjunction with with the IETF over the wire protocols such as HTTP to allow web browsers to display media that does not have real time interactive constraints with another human.
The W3C and IETF plan to collaborate together in their traditional way to meet the evolving needs of browsers. Specifically the IETF will provide a set of on the wire protocols, including RTP, to meet the needs on interactive communications, and the W3C will define the API and markup to allow web application developers to control the on the wire protocols. This will allow application developers to write applications that run in a browser and facilitate interactive communications between users for voice and video communications, collaboration, and gaming.
This working group will select and define a minimal set of protocols that will enable browsers to:
* have interactive real time voice and video between users using RTP * interoperate with compatible voice and video systems that are not web based * support direct flows of non RTP application data between browsers for collaboration and gaming applications
Okay "direct flows of non-RTP application data" goes beyond scope creep; to satisfy this completely, we are talking an end-point-to-end-point tunnel, which will run afoul of a lot of folks who dearly love packet inspection. I would say that it would be best to first tackle the voice/video bits and then tackle this problem. Re-charter the WG to cover this, in other words, after the first bit is done.
I also note that you're using "between browsers", rather than "among browsers". Is it intended that this facility should allow for multi-party communication? Leaving aside the non-RTP issues, that would add floor control, media mixing, etc. to the task list. Again, I think it should either be explicitly in-scope or out-of-scope.
I did not intend "between" to indicate that there were only two parties, but think that we're building point-to-point communications, not N-to-N.
In one interpretation of the distinction .... I think we're standardizing point-to-point communications at this time, since all the proven-viable multipoint communication applications have been built out of point-to-point links rather than using underlying multipoint technologies like multicast.
In another interpretation ... I think we should limit ourselves to providing a toolbox. I think floor control (except for possibly providing the signalling channels floor control needs) is out of scope; MAITAI may be a better place to discuss media mixing.
So, maybe this would be clearer if I asked it in a different way. Are you thinking of something like websockets run between two peers? Or are you thinking of layered tunnel model?
Fortunately very little development of new protocol at IETF is required for this, only selection of existing protocols and selection of minimum capabilities to ensure interoperability. The following protocols are candidates for including in the profile set:
1) RTP/ RTCP
2) a baseline audio codec for high quality interactive audio. Opus will be considered as one of the candidates
3) a baseline audio codec for PSTN interoperability. G.711 and iLBC will be considered
4) a baseline video codec. H.264 and VP8 will be considered
5) Diffserv based QoS
6) NAT traversal using ICE
The ICE spec is clear that the NAT traversal it provides does not help establish the signaling between agents. For this browser-to-browser mechanism, if we are limiting this to situations where a mediating web server provides the initial signaling path, that's okay. If there is a different model, though, we may need additional tools here.
If we can make the mediating-web-server model work, I think we have success; if we can't make it work, we have a failure. So obviously that's my first priority. What text changes do you think are needed?
If the text I suggested above clarifying that this is mediating-web-server works for you, I don't think additionally text is needed here.
7) RFC 4833 based DTMF transport
8) RFC 4574 based Label support for identifying streams purpose
9) Secure RTP and keying
10) support for IPv4, IPv6 and dual stack browsers
The working group will cooperate closely with the W3C activity that specifies a semantic level API that allows the control and manipulation of all the functionality above. In addition, the API needs to communicate state information and events about what is happening in the browser that to applications running in the browser.
I think the sentence above has some extra words; is the browser talking to application running in the browser? Can it be re-phrased?
I think there's an extra "that" - when an event happens at the communications interface, this event needs to be propagated over the API to the Javascript that is running in a Web page - that Web page is what I've been thinking of as "the application". (There are other moves around that want to run "web pages" in other contexts than a currently open tab in a broswer, but for the moment, "a tab in a browser", or even "a set of tabs in a browser" is a reasonable synonym for "application", I think).
These events and state need to include
information such as: receiving RFC 4833 DTMF, RTP and RTCP statistics, state of DTLS/SRTP, and signalling state.
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, LOST, Geolocation, IM& Presence, NSIS, Resource Priority,
Milestones:
February 2011 Candidate "sample" documents circulated to DISPATCH
March 2011 BOF at IETF Prague
April 2011 WG charter approved by IESG. Chosen document sets adopted as WG documents
May 2011 Functionality to include and main alternative protocols identified
July 2011 IETF meeting
Aug 2011 Draft with text reflecting agreement of what the protocol set should be
Nov 2010 Documentation specifying mapping of protocol functionality to W3C-specified API produced
Dec 2011 Protocol set specification to IESG
April 2012 API mapping document to IESG
Pretty aggressive, given the number of moving parts. It's also not clear why the November 2011 doc (I assume 2010 is a typo) is done in the IETF, rather than the W3C. Or is it joint work?
More or less done this way at random. I think of this as joint work; documents may move between the organizations as we progress, but I'm not sure how the W3C document model works yet.
I think that we need to be a bit more careful on the dependencies, as it has not been my experience that joint work has resulted in a congruent set of people working on them in the two organizations. Can we make the deliverable for the November 2011 doc the release of a draft, with a note it is intended as a substrate to the W3C work? That would make the W3C work have a dependency on this draft delivery. regards, Ted Hardie

Harald, With one exception, this draft charter does not mention signalling (SIP/SDP), and I assume it is intended to be out of scope, although that is not explicitly stated. The one exception is "8) RFC 4574 based Label support for identifying streams purpose". This is an SDP attribute. How would this be used if SDP is indeed out of scope? If SDP is in scope, we certainly need more text describing its relevance. John
-----Original Message----- From: rtc-web-bounces@alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of Harald Alvestrand Sent: 06 January 2011 11:54 To: 'dispatch@ietf.org' Cc: rtc-web@alvestrand.no Subject: [RTW] Charter proposal: The activity hitherto known as "RTC-WEB at IETF"
This is the first of 3 messages going to the DISPATCH list (in the hope of keeping discussions somewhat organized).
This is the draft of a charter for an IETF working group to consider the subject area of "Real time communication in the Web browser platform". This is one of a paired set of activities, the other one being a W3C activity (either within an existing WG or in a new WG) that defines APIs to this functionality.
The two other messages will contain the W3C proposed charter and a kickoff for what's usually the most distracting topic in any such discussion: The name of the group. Without further ado:
-------------------------------------
Version: 2
Possible Names: <This space deliberately left blank for later discussion>
Body:
Many implementations have been made that use a Web browser to support interactive communications directly between users including voice, video, collaboration and gaming, but until now, such applications have required the installation of nonstandard plugins and browser extensions. There is a desire to standardize such functionality, so that this type of application can be run in any compatible browser.
Traditionally, the W3C has defined API and markup languages such as HTML that work in conjunction with with the IETF over the wire protocols such as HTTP to allow web browsers to display media that does not have real time interactive constraints with another human.
The W3C and IETF plan to collaborate together in their traditional way to meet the evolving needs of browsers. Specifically the IETF will provide a set of on the wire protocols, including RTP, to meet the needs on interactive communications, and the W3C will define the API and markup to allow web application developers to control the on the wire protocols. This will allow application developers to write applications that run in a browser and facilitate interactive communications between users for voice and video communications, collaboration, and gaming.
This working group will select and define a minimal set of protocols that will enable browsers to:
* have interactive real time voice and video between users using RTP * interoperate with compatible voice and video systems that are not web based * support direct flows of non RTP application data between browsers for collaboration and gaming applications
Fortunately very little development of new protocol at IETF is required for this, only selection of existing protocols and selection of minimum capabilities to ensure interoperability. The following protocols are candidates for including in the profile set:
1) RTP/ RTCP
2) a baseline audio codec for high quality interactive audio. Opus will be considered as one of the candidates
3) a baseline audio codec for PSTN interoperability. G.711 and iLBC will be considered
4) a baseline video codec. H.264 and VP8 will be considered
5) Diffserv based QoS
6) NAT traversal using ICE
7) RFC 4833 based DTMF transport
8) RFC 4574 based Label support for identifying streams purpose
9) Secure RTP and keying
10) support for IPv4, IPv6 and dual stack browsers
The working group will cooperate closely with the W3C activity that specifies a semantic level API that allows the control and manipulation of all the functionality above. In addition, the API needs to communicate state information and events about what is happening in the browser that to applications running in the browser. These events and state need to include information such as: receiving RFC 4833 DTMF, RTP and RTCP statistics, state of DTLS/SRTP, and signalling state.
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, LOST, Geolocation, IM & Presence, NSIS, Resource Priority,
Milestones:
February 2011 Candidate "sample" documents circulated to DISPATCH
March 2011 BOF at IETF Prague
April 2011 WG charter approved by IESG. Chosen document sets adopted as WG documents
May 2011 Functionality to include and main alternative protocols identified
July 2011 IETF meeting
Aug 2011 Draft with text reflecting agreement of what the protocol set should be
Nov 2010 Documentation specifying mapping of protocol functionality to W3C-specified API produced
Dec 2011 Protocol set specification to IESG
April 2012 API mapping document to IESG
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web

On 01/07/11 10:38, Elwell, John wrote:
Harald,
With one exception, this draft charter does not mention signalling (SIP/SDP), and I assume it is intended to be out of scope, although that is not explicitly stated.
The one exception is "8) RFC 4574 based Label support for identifying streams purpose". This is an SDP attribute. How would this be used if SDP is indeed out of scope? If SDP is in scope, we certainly need more text describing its relevance. There isn't much text in 4574 - the main point of the RFC seems to be that it's possible to create labels for streams before creating the stream. Those labels could be independent of the signalling mechanism.
The trend I see now is that most APIs and protocols people define (for instance Jabber/XMPP, JSON-based descriptions) have some kind of mapping to SDP, so SDP-as-a-format may not be so important (I heartily dislike multiple things about the specific format), but SDP-as-a-semantic becomes more important over time, and can't be ignored. Harald

-----Original Message----- From: Harald Alvestrand [mailto:harald@alvestrand.no] Sent: 08 January 2011 14:03 To: Elwell, John Cc: 'dispatch@ietf.org'; rtc-web@alvestrand.no Subject: Re: [RTW] Charter proposal: The activity hitherto known as "RTC-WEB at IETF"
On 01/07/11 10:38, Elwell, John wrote:
Harald,
With one exception, this draft charter does not mention signalling (SIP/SDP), and I assume it is intended to be out of scope, although that is not explicitly stated.
The one exception is "8) RFC 4574 based Label support for identifying streams purpose". This is an SDP attribute. How would this be used if SDP is indeed out of scope? If SDP is in scope, we certainly need more text describing its relevance. There isn't much text in 4574 - the main point of the RFC seems to be that it's possible to create labels for streams before creating the stream. Those labels could be independent of the signalling mechanism.
The trend I see now is that most APIs and protocols people define (for instance Jabber/XMPP, JSON-based descriptions) have some kind of mapping to SDP, so SDP-as-a-format may not be so important (I heartily dislike multiple things about the specific format), but SDP-as-a-semantic becomes more important over time, and can't be ignored. [JRE] RFC 4574 is little more than an SDP syntax (for conveying an application-specific label). As such, if we don't use the SDP syntax, I don't see how RFC 4574 can apply at all. The problem we need to solve, if I understand correctly, is for the application to instruct the browser what source and sink to use for a given medium. For audio, this means telling the browser which microphone and which speaker to use. For video, this means telling the browser which camera to use and where on the display to render received video. I don't see the relevance of RFC 4574 for achieving this.
John
Harald

Hi, I agree with John. The 'label' RFC is essentially syntax. It seems to me this source/sink issue has some things in common with the work in CLUE (formerly maitai) in the sense that it too has to face the issue of linking devices with streams... It may be that they need a common protocol mechanism... Regards, Peter Musgrave On 2011-01-10, at 2:20 AM, Elwell, John wrote:
-----Original Message----- From: Harald Alvestrand [mailto:harald@alvestrand.no] Sent: 08 January 2011 14:03 To: Elwell, John Cc: 'dispatch@ietf.org'; rtc-web@alvestrand.no Subject: Re: [RTW] Charter proposal: The activity hitherto known as "RTC-WEB at IETF"
On 01/07/11 10:38, Elwell, John wrote:
Harald,
With one exception, this draft charter does not mention signalling (SIP/SDP), and I assume it is intended to be out of scope, although that is not explicitly stated.
The one exception is "8) RFC 4574 based Label support for identifying streams purpose". This is an SDP attribute. How would this be used if SDP is indeed out of scope? If SDP is in scope, we certainly need more text describing its relevance. There isn't much text in 4574 - the main point of the RFC seems to be that it's possible to create labels for streams before creating the stream. Those labels could be independent of the signalling mechanism.
The trend I see now is that most APIs and protocols people define (for instance Jabber/XMPP, JSON-based descriptions) have some kind of mapping to SDP, so SDP-as-a-format may not be so important (I heartily dislike multiple things about the specific format), but SDP-as-a-semantic becomes more important over time, and can't be ignored. [JRE] RFC 4574 is little more than an SDP syntax (for conveying an application-specific label). As such, if we don't use the SDP syntax, I don't see how RFC 4574 can apply at all. The problem we need to solve, if I understand correctly, is for the application to instruct the browser what source and sink to use for a given medium. For audio, this means telling the browser which microphone and which speaker to use. For video, this means telling the browser which camera to use and where on the display to render received video. I don't see the relevance of RFC 4574 for achieving this.
John
Harald
_______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch

I think this is an interesting and important activity, but I want to point out a few points of concern with the current proposal. Although the charter indicates that there will be a "selection", it fails to identify the criteria for this selection process. It is easy to see that this can lead to a shouting match. The only indication of a criterion for the codecs is:
* interoperate with compatible voice and video systems that are not web based
which, btw, you already re-interpreted to mean "brower-to-browser" in a later email. I would therefore recommend that, if a single baseline codec is to be selected, the criteria are stated in the charter. If the criteria are to be defined later by the group, then that should be stated in the charter, with at least some indication of what the group wants to accomplish here. Nit: Codecs are not protocols (cf. "The following protocols..."). Regards. Alex On Jan 6, 2011, at 1:53 PM, Harald Alvestrand wrote:
This is the first of 3 messages going to the DISPATCH list (in the hope of keeping discussions somewhat organized).
This is the draft of a charter for an IETF working group to consider the subject area of "Real time communication in the Web browser platform". This is one of a paired set of activities, the other one being a W3C activity (either within an existing WG or in a new WG) that defines APIs to this functionality.
The two other messages will contain the W3C proposed charter and a kickoff for what's usually the most distracting topic in any such discussion: The name of the group. Without further ado:
-------------------------------------
Version: 2
Possible Names: <This space deliberately left blank for later discussion>
Body:
Many implementations have been made that use a Web browser to support interactive communications directly between users including voice, video, collaboration and gaming, but until now, such applications have required the installation of nonstandard plugins and browser extensions. There is a desire to standardize such functionality, so that this type of application can be run in any compatible browser.
Traditionally, the W3C has defined API and markup languages such as HTML that work in conjunction with with the IETF over the wire protocols such as HTTP to allow web browsers to display media that does not have real time interactive constraints with another human.
The W3C and IETF plan to collaborate together in their traditional way to meet the evolving needs of browsers. Specifically the IETF will provide a set of on the wire protocols, including RTP, to meet the needs on interactive communications, and the W3C will define the API and markup to allow web application developers to control the on the wire protocols. This will allow application developers to write applications that run in a browser and facilitate interactive communications between users for voice and video communications, collaboration, and gaming.
This working group will select and define a minimal set of protocols that will enable browsers to:
* have interactive real time voice and video between users using RTP * interoperate with compatible voice and video systems that are not web based * support direct flows of non RTP application data between browsers for collaboration and gaming applications
Fortunately very little development of new protocol at IETF is required for this, only selection of existing protocols and selection of minimum capabilities to ensure interoperability. The following protocols are candidates for including in the profile set:
1) RTP/ RTCP
2) a baseline audio codec for high quality interactive audio. Opus will be considered as one of the candidates
3) a baseline audio codec for PSTN interoperability. G.711 and iLBC will be considered
4) a baseline video codec. H.264 and VP8 will be considered
5) Diffserv based QoS
6) NAT traversal using ICE
7) RFC 4833 based DTMF transport
8) RFC 4574 based Label support for identifying streams purpose
9) Secure RTP and keying
10) support for IPv4, IPv6 and dual stack browsers
The working group will cooperate closely with the W3C activity that specifies a semantic level API that allows the control and manipulation of all the functionality above. In addition, the API needs to communicate state information and events about what is happening in the browser that to applications running in the browser. These events and state need to include information such as: receiving RFC 4833 DTMF, RTP and RTCP statistics, state of DTLS/SRTP, and signalling state.
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, LOST, Geolocation, IM & Presence, NSIS, Resource Priority,
Milestones:
February 2011 Candidate "sample" documents circulated to DISPATCH
March 2011 BOF at IETF Prague
April 2011 WG charter approved by IESG. Chosen document sets adopted as WG documents
May 2011 Functionality to include and main alternative protocols identified
July 2011 IETF meeting
Aug 2011 Draft with text reflecting agreement of what the protocol set should be
Nov 2010 Documentation specifying mapping of protocol functionality to W3C-specified API produced
Dec 2011 Protocol set specification to IESG
April 2012 API mapping document to IESG
_______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch
participants (11)
-
Alex Eleftheriadis
-
Christer Holmberg
-
David Singer
-
DRAGE, Keith (Keith)
-
Elwell, John
-
Harald Alvestrand
-
Henry Sinnreich
-
Justin Uberti
-
Marshall Eubanks
-
Peter Musgrave
-
Ted Hardie