New proposed charter text. Please review before the BoF.
Name: Real-Time Communication in WEB-browsers (RTCWeb) There are a number of proprietary implementations that provide direct interactive rich communication using audio, video, collaboration, games, etc. between two peers' web-browsers. These are not interoperable, as they require non-standard extensions or plugins to work. There is a desire to standardize the basis for such communication so that interoperable communication can be established between any compatible browsers. The goal is to enable innovation on top of a set of basic components. One core component is to enable real-time media like audio and video, a second is to enable datagram and byte stream data transfer directly between clients. This work will be done in collaboration with the W3C. The IETF WG will produce architecture and requirements for selection and profiling of the on the wire protocols. The architecture needs to be coordinated with W3C. The IETF WG work will identity state information and events that need to be exposed in the APIs as input to W3C. The W3C will be responsible for defining APIs to ensure that application developers can control the components. The security goals and requirements will be developed by the WG. The security model needs to be coordinated with the W3C. The work will also consider where support for extensibility is needed. RTP functionalities, media formats, security algorithms are example of things that commonly needs extensions, additions or replacement, and thus some support for negotiation between clients is required. The WG will perform the following work: 1. Define the communication model in detail, including how session management is to occur within the model. 2. Define a security model that describes the security goals and how the communication model can achieve these goals. 3. Define how NAT and Firewall traversal is to occur. 4. Define which RTP functions and extensions that shall be supported in the client and their usage for real-time media, including media adaptation to ensure congestion safe usage. 5. Define what functionalities in the solution, such as media codecs, security algorithms, etc., that can be extended and how the extensibility mechanisms works. 6. Define a set of media formats that must or should be supported by a client to improve interoperability. 7. Define how non RTP datagram and byte stream data communication between the clients can be done securely and in a congestion safe way. 8. Provide W3C input for the APIs that comes from the communication model and the selected components and protocols that are part of the solution. This work will be done primarily by using already defined protocols or functionalities. If there is identification of missing protocols or functionalities, such work can be requested to be done in another working group with a suitable charter or by requests for chartering it in this WG or another WG. The following topics will be out of scope for the initial phase of the WG but could be added after a recharter: RTSP, RSVP, NSIS, Location services, IM & Presence, Resource Priority. The products of the working group will support security and keying as required by BCP 61 and be defined for IPv4, IPv6, and dual stack deployments. The Working Group will consider the possibility of defining a browser component that implements an existing session negotiation and management protocol. The working group will follow BCP 79, and adhere to the spirit of BCP 79. The working group cannot explicitly rule out the possibility of adopting encumbered technologies; however, the working group will try to avoid encumbered technologies that require royalties or other encumbrances that would prevent such technologies from being easy to use in web browsers. Milestones: Aug 2011 Architecture and Security and Threat Model sent to W3C Aug 2011 Use cases and Scenarios document sent to W3C Sept 2011 Architecture and Security and Threat Model to IESG as Informational Sept 2011 Use cases and Scenarios for RTCWeb document sent to IESG as Informational Dec 2011 RTCWeb and Media format specification(s) to IESG as PS Dec 2011 Information elements and events APIs Input to W3C Apr 2012 API to Protocol mapping document submitted to the IESG as Informational (if needed)
Ted, friends I just submitted comments to the W3C, and I am kinda duplicating them here. Here is what I said to the W3C: "Our major comment is duplicated to the IETF group; we think that a major deliverable of these two groups is the interface between them - the overall architecture in which they work. This is variously described as "APIs" and "Javascript interfaces" in the activity proposal, but it needs to be an overall architecture in which at least one specific instance (e.g. using existing codecs and protocols) can be instantiated. From the W3C point of view, that might involve markup, DOM, APIs, and even possibly CSS. The two efforts don't just need to 'run in parallel', they need to produce a joint architecture that makes their work mesh together, and also enable continuing development (e.g. new modules with enhanced behavior, behind the same APIs)." For the two groups to work together well, establishing the architecture and the points of interface is going to be important. And that architecture should, as much as possible, enable not just today's best technology (e.g. RTP, SIP) but also permit work in, and development of, improvements over time, to the greatest extent possible. Maybe this is obvious to all concerned. On Mar 17, 2011, at 9:18 , Ted Hardie wrote:
Name: Real-Time Communication in WEB-browsers (RTCWeb)
There are a number of proprietary implementations that provide direct interactive rich communication using audio, video, collaboration, games, etc. between two peers' web-browsers. These are not interoperable, as they require non-standard extensions or plugins to work. There is a desire to standardize the basis for such communication so that interoperable communication can be established between any compatible browsers. The goal is to enable innovation on top of a set of basic components. One core component is to enable real-time media like audio and video, a second is to enable datagram and byte stream data transfer directly between clients.
This work will be done in collaboration with the W3C. The IETF WG will produce architecture and requirements for selection and profiling of the on the wire protocols. The architecture needs to be coordinated with W3C. The IETF WG work will identity state information and events that need to be exposed in the APIs as input to W3C. The W3C will be responsible for defining APIs to ensure that application developers can control the components.
The security goals and requirements will be developed by the WG. The security model needs to be coordinated with the W3C. The work will also consider where support for extensibility is needed. RTP functionalities, media formats, security algorithms are example of things that commonly needs extensions, additions or replacement, and thus some support for negotiation between clients is required.
The WG will perform the following work: 1. Define the communication model in detail, including how session management is to occur within the model. 2. Define a security model that describes the security goals and how the communication model can achieve these goals. 3. Define how NAT and Firewall traversal is to occur. 4. Define which RTP functions and extensions that shall be supported in the client and their usage for real-time media, including media adaptation to ensure congestion safe usage. 5. Define what functionalities in the solution, such as media codecs, security algorithms, etc., that can be extended and how the extensibility mechanisms works. 6. Define a set of media formats that must or should be supported by a client to improve interoperability. 7. Define how non RTP datagram and byte stream data communication between the clients can be done securely and in a congestion safe way. 8. Provide W3C input for the APIs that comes from the communication model and the selected components and protocols that are part of the solution.
This work will be done primarily by using already defined protocols or functionalities. If there is identification of missing protocols or functionalities, such work can be requested to be done in another working group with a suitable charter or by requests for chartering it in this WG or another WG. The following topics will be out of scope for the initial phase of the WG but could be added after a recharter: RTSP, RSVP, NSIS, Location services, IM & Presence, Resource Priority.
The products of the working group will support security and keying as required by BCP 61 and be defined for IPv4, IPv6, and dual stack deployments. The Working Group will consider the possibility of defining a browser component that implements an existing session negotiation and management protocol. The working group will follow BCP 79, and adhere to the spirit of BCP 79. The working group cannot explicitly rule out the possibility of adopting encumbered technologies; however, the working group will try to avoid encumbered technologies that require royalties or other encumbrances that would prevent such technologies from being easy to use in web browsers.
Milestones:
Aug 2011 Architecture and Security and Threat Model sent to W3C
Aug 2011 Use cases and Scenarios document sent to W3C
Sept 2011 Architecture and Security and Threat Model to IESG as Informational
Sept 2011 Use cases and Scenarios for RTCWeb document sent to IESG as Informational
Dec 2011 RTCWeb and Media format specification(s) to IESG as PS
Dec 2011 Information elements and events APIs Input to W3C
Apr 2012 API to Protocol mapping document submitted to the IESG as Informational (if needed) _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
David Singer Multimedia and Software Standards, Apple Inc.
On Thu, 2011-03-17 at 09:18 -0700, Ted Hardie wrote:
8. Provide W3C input for the APIs that comes from the communication model and the selected components and protocols that are part of the solution.
From a W3C point, I'd like to understand what item 8 means. W3C is putting in place a working group to develop the APIs.
Will the IETF Group also work on them in order to provide input? There is certainly a need for coordination between the two groups but I'm concerned that the IETF Group would work on the APIs... Regards, Philippe
The intent of item 8 was for the IETF to provide API-related requirements to the W3C, not for API-related work to be done in IETF. For example, during the discussions on this list there has been discussion of the need to obtain IP addresses of interfaces as required by ICE, or the details of codec support required by Jingle or SDP offer/answer. -----Original Message----- From: rtc-web-bounces@alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of Philippe Le Hegaret Sent: Thursday, March 17, 2011 12:34 PM To: Ted Hardie Cc: François Daoust; rtc-web@alvestrand.no Subject: Re: [RTW] New proposed charter text. Please review before the BoF. On Thu, 2011-03-17 at 09:18 -0700, Ted Hardie wrote:
8. Provide W3C input for the APIs that comes from the communication model and the selected components and protocols that are part of the solution.
From a W3C point, I'd like to understand what item 8 means. W3C is putting in place a working group to develop the APIs.
Will the IETF Group also work on them in order to provide input? There is certainly a need for coordination between the two groups but I'm concerned that the IETF Group would work on the APIs... Regards, Philippe _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
Ted, I think there needs to be some mention of interop with existing real-time applications using IETF protocols (such as SIP, RTP). Something along the lines of: "Work should take account of browser-based applications that require to interoperate with existing applications using IETF protocols such as SIP and RTP and commonly deployed audio and video codecs. Solutions that require mediation functions to achieve interoperation might be acceptable, provided such functions are not unduly complex, expensive or detrimental to performance." John
-----Original Message----- From: rtc-web-bounces@alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of Ted Hardie Sent: 17 March 2011 16:18 To: rtc-web@alvestrand.no Subject: [RTW] New proposed charter text. Please review before the BoF.
Name: Real-Time Communication in WEB-browsers (RTCWeb)
There are a number of proprietary implementations that provide direct interactive rich communication using audio, video, collaboration, games, etc. between two peers' web-browsers. These are not interoperable, as they require non-standard extensions or plugins to work. There is a desire to standardize the basis for such communication so that interoperable communication can be established between any compatible browsers. The goal is to enable innovation on top of a set of basic components. One core component is to enable real-time media like audio and video, a second is to enable datagram and byte stream data transfer directly between clients.
This work will be done in collaboration with the W3C. The IETF WG will produce architecture and requirements for selection and profiling of the on the wire protocols. The architecture needs to be coordinated with W3C. The IETF WG work will identity state information and events that need to be exposed in the APIs as input to W3C. The W3C will be responsible for defining APIs to ensure that application developers can control the components.
The security goals and requirements will be developed by the WG. The security model needs to be coordinated with the W3C. The work will also consider where support for extensibility is needed. RTP functionalities, media formats, security algorithms are example of things that commonly needs extensions, additions or replacement, and thus some support for negotiation between clients is required.
The WG will perform the following work: 1. Define the communication model in detail, including how session management is to occur within the model. 2. Define a security model that describes the security goals and how the communication model can achieve these goals. 3. Define how NAT and Firewall traversal is to occur. 4. Define which RTP functions and extensions that shall be supported in the client and their usage for real-time media, including media adaptation to ensure congestion safe usage. 5. Define what functionalities in the solution, such as media codecs, security algorithms, etc., that can be extended and how the extensibility mechanisms works. 6. Define a set of media formats that must or should be supported by a client to improve interoperability. 7. Define how non RTP datagram and byte stream data communication between the clients can be done securely and in a congestion safe way. 8. Provide W3C input for the APIs that comes from the communication model and the selected components and protocols that are part of the solution.
This work will be done primarily by using already defined protocols or functionalities. If there is identification of missing protocols or functionalities, such work can be requested to be done in another working group with a suitable charter or by requests for chartering it in this WG or another WG. The following topics will be out of scope for the initial phase of the WG but could be added after a recharter: RTSP, RSVP, NSIS, Location services, IM & Presence, Resource Priority.
The products of the working group will support security and keying as required by BCP 61 and be defined for IPv4, IPv6, and dual stack deployments. The Working Group will consider the possibility of defining a browser component that implements an existing session negotiation and management protocol. The working group will follow BCP 79, and adhere to the spirit of BCP 79. The working group cannot explicitly rule out the possibility of adopting encumbered technologies; however, the working group will try to avoid encumbered technologies that require royalties or other encumbrances that would prevent such technologies from being easy to use in web browsers.
Milestones:
Aug 2011 Architecture and Security and Threat Model sent to W3C
Aug 2011 Use cases and Scenarios document sent to W3C
Sept 2011 Architecture and Security and Threat Model to IESG as Informational
Sept 2011 Use cases and Scenarios for RTCWeb document sent to IESG as Informational
Dec 2011 RTCWeb and Media format specification(s) to IESG as PS
Dec 2011 Information elements and events APIs Input to W3C
Apr 2012 API to Protocol mapping document submitted to the IESG as Informational (if needed) _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
Hi John, What aspects would like you to be taken into consideration? It sounds a bit like you have some requirements in mind but you do not want to write them down. Ciao Hannes
-----Original Message----- From: rtc-web-bounces@alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of ext Elwell, John Sent: Friday, March 18, 2011 2:04 PM To: Ted Hardie; rtc-web@alvestrand.no Subject: Re: [RTW] New proposed charter text. Please review before the BoF.
Ted,
I think there needs to be some mention of interop with existing real-time applications using IETF protocols (such as SIP, RTP). Something along the lines of: "Work should take account of browser-based applications that require to interoperate with existing applications using IETF protocols such as SIP and RTP and commonly deployed audio and video codecs. Solutions that require mediation functions to achieve interoperation might be acceptable, provided such functions are not unduly complex, expensive or detrimental to performance."
John
-----Original Message----- From: rtc-web-bounces@alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of Ted Hardie Sent: 17 March 2011 16:18 To: rtc-web@alvestrand.no Subject: [RTW] New proposed charter text. Please review before the BoF.
Name: Real-Time Communication in WEB-browsers (RTCWeb)
There are a number of proprietary implementations that provide direct interactive rich communication using audio, video, collaboration, games, etc. between two peers' web-browsers. These are not interoperable, as they require non-standard extensions or plugins to work. There is a desire to standardize the basis for such communication so that interoperable communication can be established between any compatible browsers. The goal is to enable innovation on top of a set of basic components. One core component is to enable real-time media like audio and video, a second is to enable datagram and byte stream data transfer directly between clients.
This work will be done in collaboration with the W3C. The IETF WG will produce architecture and requirements for selection and profiling of the on the wire protocols. The architecture needs to be coordinated with W3C. The IETF WG work will identity state information and events that need to be exposed in the APIs as input to W3C. The W3C will be responsible for defining APIs to ensure that application developers can control the components.
The security goals and requirements will be developed by the WG. The security model needs to be coordinated with the W3C. The work will also consider where support for extensibility is needed. RTP functionalities, media formats, security algorithms are example of things that commonly needs extensions, additions or replacement, and thus some support for negotiation between clients is required.
The WG will perform the following work: 1. Define the communication model in detail, including how session management is to occur within the model. 2. Define a security model that describes the security goals and how the communication model can achieve these goals. 3. Define how NAT and Firewall traversal is to occur. 4. Define which RTP functions and extensions that shall be supported in the client and their usage for real-time media, including media adaptation to ensure congestion safe usage. 5. Define what functionalities in the solution, such as media codecs, security algorithms, etc., that can be extended and how the extensibility mechanisms works. 6. Define a set of media formats that must or should be supported by a client to improve interoperability. 7. Define how non RTP datagram and byte stream data communication between the clients can be done securely and in a congestion safe way. 8. Provide W3C input for the APIs that comes from the communication model and the selected components and protocols that are part of the solution.
This work will be done primarily by using already defined protocols or functionalities. If there is identification of missing protocols or functionalities, such work can be requested to be done in another working group with a suitable charter or by requests for chartering it in this WG or another WG. The following topics will be out of scope for the initial phase of the WG but could be added after a recharter: RTSP, RSVP, NSIS, Location services, IM & Presence, Resource Priority.
The products of the working group will support security and keying as required by BCP 61 and be defined for IPv4, IPv6, and dual stack deployments. The Working Group will consider the possibility of defining a browser component that implements an existing session negotiation and management protocol. The working group will follow BCP 79, and adhere to the spirit of BCP 79. The working group cannot explicitly rule out the possibility of adopting encumbered technologies; however, the working group will try to avoid encumbered technologies that require royalties or other encumbrances that would prevent such technologies from being easy to use in web browsers.
Milestones:
Aug 2011 Architecture and Security and Threat Model sent to W3C
Aug 2011 Use cases and Scenarios document sent to W3C
Sept 2011 Architecture and Security and Threat Model to IESG as Informational
Sept 2011 Use cases and Scenarios for RTCWeb document sent to IESG as Informational
Dec 2011 RTCWeb and Media format specification(s) to IESG as PS
Dec 2011 Information elements and events APIs Input to W3C
Apr 2012 API to Protocol mapping document submitted to the IESG as Informational (if needed) _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
Hannes, I didn't write them down because I thought it would be too much for the charter. But most of the following points have been raised in the past: - Codecs - if mandatory-to-implement codecs are not what are commonly implemented on existing SIP endpoints, until such time as those endpoints are upgraded you need transcoding, which can be expensive and detrimental to performance. - RTP multiplexing - there has been some mention of a shim layer between UDP and RTP to allow multiplexing of different streams on the same port. This would require a mediation function - not as harmful as transcoding, but the impacts should at least be considered. - RTP options - mandating RTP options or payload format options that are not commonly implemented at present (such as RTP/RTCP mux). - STUN/ICE - not commonly implemented at present. - Crypto algorithms - if mandatory-to-implement algorithms do not match current practice. - Call control protocol and options, if that were to be considered in scope. The charter text leaves it open: "Define the communication model in detail, including how session management is to occur within the model.". I am not saying we can't do any of these things, but we should consider the interworking implications and decide whether they are acceptable. John
-----Original Message----- From: Tschofenig, Hannes (NSN - FI/Espoo) [mailto:hannes.tschofenig@nsn.com] Sent: 18 March 2011 12:38 To: Elwell, John; Ted Hardie; rtc-web@alvestrand.no Subject: RE: [RTW] New proposed charter text. Please review before the BoF.
Hi John,
What aspects would like you to be taken into consideration? It sounds a bit like you have some requirements in mind but you do not want to write them down.
Ciao Hannes
-----Original Message----- From: rtc-web-bounces@alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of ext Elwell, John Sent: Friday, March 18, 2011 2:04 PM To: Ted Hardie; rtc-web@alvestrand.no Subject: Re: [RTW] New proposed charter text. Please review before the BoF.
Ted,
I think there needs to be some mention of interop with existing real-time applications using IETF protocols (such as SIP, RTP). Something along the lines of: "Work should take account of browser-based applications that require to interoperate with existing applications using IETF protocols such as SIP and RTP and commonly deployed audio and video codecs. Solutions that require mediation functions to achieve interoperation might be acceptable, provided such functions are not unduly complex, expensive or detrimental to performance."
John
-----Original Message----- From: rtc-web-bounces@alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of Ted Hardie Sent: 17 March 2011 16:18 To: rtc-web@alvestrand.no Subject: [RTW] New proposed charter text. Please review before the BoF.
Name: Real-Time Communication in WEB-browsers (RTCWeb)
There are a number of proprietary implementations that provide direct interactive rich communication using audio, video, collaboration, games, etc. between two peers' web-browsers. These are not interoperable, as they require non-standard extensions or plugins to work. There is a desire to standardize the basis for such communication so that interoperable communication can be established between any compatible browsers. The goal is to enable innovation on top of a set of basic components. One core component is to enable real-time media like audio and video, a second is to enable datagram and byte stream data transfer directly between clients.
This work will be done in collaboration with the W3C. The IETF WG will produce architecture and requirements for selection and profiling of the on the wire protocols. The architecture needs to be coordinated with W3C. The IETF WG work will identity state information and events that need to be exposed in the APIs as input to W3C. The W3C will be responsible for defining APIs to ensure that application developers can control the components.
The security goals and requirements will be developed by the WG. The security model needs to be coordinated with the W3C. The work will also consider where support for extensibility is needed. RTP functionalities, media formats, security algorithms are example of things that commonly needs extensions, additions or replacement, and thus some support for negotiation between clients is required.
The WG will perform the following work: 1. Define the communication model in detail, including how session management is to occur within the model. 2. Define a security model that describes the security goals and how the communication model can achieve these goals. 3. Define how NAT and Firewall traversal is to occur. 4. Define which RTP functions and extensions that shall be supported in the client and their usage for real-time media, including media adaptation to ensure congestion safe usage. 5. Define what functionalities in the solution, such as media codecs, security algorithms, etc., that can be extended and how the extensibility mechanisms works. 6. Define a set of media formats that must or should be supported by a client to improve interoperability. 7. Define how non RTP datagram and byte stream data communication between the clients can be done securely and in a congestion safe way. 8. Provide W3C input for the APIs that comes from the communication model and the selected components and protocols that are part of the solution.
This work will be done primarily by using already defined protocols or functionalities. If there is identification of missing protocols or functionalities, such work can be requested to be done in another working group with a suitable charter or by requests for chartering it in this WG or another WG. The following topics will be out of scope for the initial phase of the WG but could be added after a recharter: RTSP, RSVP, NSIS, Location services, IM & Presence, Resource Priority.
The products of the working group will support security and keying as required by BCP 61 and be defined for IPv4, IPv6, and dual stack deployments. The Working Group will consider the possibility of defining a browser component that implements an existing session negotiation and management protocol. The working group will follow BCP 79, and adhere to the spirit of BCP 79. The working group cannot explicitly rule out the possibility of adopting encumbered technologies; however, the working group will try to avoid encumbered technologies that require royalties or other encumbrances that would prevent such technologies from being easy to use in web browsers.
Milestones:
Aug 2011 Architecture and Security and Threat Model sent to W3C
Aug 2011 Use cases and Scenarios document sent to W3C
Sept 2011 Architecture and Security and Threat Model to IESG as Informational
Sept 2011 Use cases and Scenarios for RTCWeb document sent to IESG as Informational
Dec 2011 RTCWeb and Media format specification(s) to IESG as PS
Dec 2011 Information elements and events APIs Input to W3C
Apr 2012 API to Protocol mapping document submitted to the IESG as Informational (if needed) _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
On Fri, Mar 18, 2011 at 5:04 AM, Elwell, John <john.elwell@siemens-enterprise.com> wrote:
Ted,
I think there needs to be some mention of interop with existing real-time applications using IETF protocols (such as SIP, RTP). Something along the lines of: "Work should take account of browser-based applications that require to interoperate with existing applications using IETF protocols such as SIP and RTP and commonly deployed audio and video codecs. Solutions that require mediation functions to achieve interoperation might be acceptable, provided such functions are not unduly complex, expensive or detrimental to performance."
So, my personal read is that these work items: "4. Define which RTP functions and extensions shall be supported in the client and their usage for real-time media, including media adaptation to ensure congestion safe usage. 5. Define what functionalities in the solution, such as media codecs, security algorithms, etc., can be extended and how the extensibility mechanisms works. 6. Define a set of media formats that must or should be supported by a client to improve interoperability." and this general statement which follows the work items: "This work will be done primarily by using already defined protocols or functionalities. " Those seem to cover the same ground as your "take account of". If your aim is to get to something more concrete, like "you must be able to build a browser-based SIP softphone using the tools identified by this group", I think you need to unpack that a bit more. Some of the presence aspects of that toolkit, for example, may not be identified here. To put this another way, my personal read is that we're aiming to create the toolkit needed to build real-time media applications in web contexts. Any specific application, including a SIP softphone, would be a use of the toolkit; those will be covered by something like draft-holmberg-rtcweb-ucreqs-00.txt as a use case, rather than in the charter. Again, just my personal take on this. regards, Ted Hardie
John
-----Original Message----- From: rtc-web-bounces@alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of Ted Hardie Sent: 17 March 2011 16:18 To: rtc-web@alvestrand.no Subject: [RTW] New proposed charter text. Please review before the BoF.
Name: Real-Time Communication in WEB-browsers (RTCWeb)
There are a number of proprietary implementations that provide direct interactive rich communication using audio, video, collaboration, games, etc. between two peers' web-browsers. These are not interoperable, as they require non-standard extensions or plugins to work. There is a desire to standardize the basis for such communication so that interoperable communication can be established between any compatible browsers. The goal is to enable innovation on top of a set of basic components. One core component is to enable real-time media like audio and video, a second is to enable datagram and byte stream data transfer directly between clients.
This work will be done in collaboration with the W3C. The IETF WG will produce architecture and requirements for selection and profiling of the on the wire protocols. The architecture needs to be coordinated with W3C. The IETF WG work will identity state information and events that need to be exposed in the APIs as input to W3C. The W3C will be responsible for defining APIs to ensure that application developers can control the components.
The security goals and requirements will be developed by the WG. The security model needs to be coordinated with the W3C. The work will also consider where support for extensibility is needed. RTP functionalities, media formats, security algorithms are example of things that commonly needs extensions, additions or replacement, and thus some support for negotiation between clients is required.
The WG will perform the following work: 1. Define the communication model in detail, including how session management is to occur within the model. 2. Define a security model that describes the security goals and how the communication model can achieve these goals. 3. Define how NAT and Firewall traversal is to occur. 4. Define which RTP functions and extensions that shall be supported in the client and their usage for real-time media, including media adaptation to ensure congestion safe usage. 5. Define what functionalities in the solution, such as media codecs, security algorithms, etc., that can be extended and how the extensibility mechanisms works. 6. Define a set of media formats that must or should be supported by a client to improve interoperability. 7. Define how non RTP datagram and byte stream data communication between the clients can be done securely and in a congestion safe way. 8. Provide W3C input for the APIs that comes from the communication model and the selected components and protocols that are part of the solution.
This work will be done primarily by using already defined protocols or functionalities. If there is identification of missing protocols or functionalities, such work can be requested to be done in another working group with a suitable charter or by requests for chartering it in this WG or another WG. The following topics will be out of scope for the initial phase of the WG but could be added after a recharter: RTSP, RSVP, NSIS, Location services, IM & Presence, Resource Priority.
The products of the working group will support security and keying as required by BCP 61 and be defined for IPv4, IPv6, and dual stack deployments. The Working Group will consider the possibility of defining a browser component that implements an existing session negotiation and management protocol. The working group will follow BCP 79, and adhere to the spirit of BCP 79. The working group cannot explicitly rule out the possibility of adopting encumbered technologies; however, the working group will try to avoid encumbered technologies that require royalties or other encumbrances that would prevent such technologies from being easy to use in web browsers.
Milestones:
Aug 2011 Architecture and Security and Threat Model sent to W3C
Aug 2011 Use cases and Scenarios document sent to W3C
Sept 2011 Architecture and Security and Threat Model to IESG as Informational
Sept 2011 Use cases and Scenarios for RTCWeb document sent to IESG as Informational
Dec 2011 RTCWeb and Media format specification(s) to IESG as PS
Dec 2011 Information elements and events APIs Input to W3C
Apr 2012 API to Protocol mapping document submitted to the IESG as Informational (if needed) _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
Ted, In the same way that charters tend to call out "horizontal" topics for special mention, such as security, privacy and NAT/firewall, I believe the ability to achieve interop with existing equipment should also be given a mention. Note that I stop short of demanding backwards compatibility, but instead make a somewhat more flexible proposal. Using defined protocols isn't necessarily sufficient if we pick things that are not implemented. As an extreme case, take S/MIME, for example. John
-----Original Message----- From: Ted Hardie [mailto:ted.ietf@gmail.com] Sent: 18 March 2011 17:01 To: Elwell, John Cc: rtc-web@alvestrand.no Subject: Re: [RTW] New proposed charter text. Please review before the BoF.
On Fri, Mar 18, 2011 at 5:04 AM, Elwell, John <john.elwell@siemens-enterprise.com> wrote:
Ted,
I think there needs to be some mention of interop with existing real-time applications using IETF protocols (such as SIP, RTP). Something along the lines of: "Work should take account of browser-based applications that require to interoperate with existing applications using IETF protocols such as SIP and RTP and commonly deployed audio and video codecs. Solutions that require mediation functions to achieve interoperation might be acceptable, provided such functions are not unduly complex, expensive or detrimental to performance."
So, my personal read is that these work items:
"4. Define which RTP functions and extensions shall be supported in the client and their usage for real-time media, including media adaptation to ensure congestion safe usage. 5. Define what functionalities in the solution, such as media codecs, security algorithms, etc., can be extended and how the extensibility mechanisms works. 6. Define a set of media formats that must or should be supported by a client to improve interoperability."
and this general statement which follows the work items:
"This work will be done primarily by using already defined protocols or functionalities. "
Those seem to cover the same ground as your "take account of". If your aim is to get to something more concrete, like "you must be able to build a browser-based SIP softphone using the tools identified by this group", I think you need to unpack that a bit more. Some of the presence aspects of that toolkit, for example, may not be identified here.
To put this another way, my personal read is that we're aiming to create the toolkit needed to build real-time media applications in web contexts. Any specific application, including a SIP softphone, would be a use of the toolkit; those will be covered by something like draft-holmberg-rtcweb-ucreqs-00.txt as a use case, rather than in the charter.
Again, just my personal take on this.
regards,
Ted Hardie
John
-----Original Message----- From: rtc-web-bounces@alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of Ted Hardie Sent: 17 March 2011 16:18 To: rtc-web@alvestrand.no Subject: [RTW] New proposed charter text. Please review before the BoF.
Name: Real-Time Communication in WEB-browsers (RTCWeb)
There are a number of proprietary implementations that provide direct interactive rich communication using audio, video, collaboration, games, etc. between two peers' web-browsers. These are not interoperable, as they require non-standard extensions or plugins to work. There is a desire to standardize the basis for such communication so that interoperable communication can be established between any compatible browsers. The goal is to enable innovation on top of a set of basic components. One core component is to enable real-time media like audio and video, a second is to enable datagram and byte stream data transfer directly between clients.
This work will be done in collaboration with the W3C. The IETF WG will produce architecture and requirements for selection and profiling of the on the wire protocols. The architecture needs to be coordinated with W3C. The IETF WG work will identity state information and events that need to be exposed in the APIs as input to W3C. The W3C will be responsible for defining APIs to ensure that application developers can control the components.
The security goals and requirements will be developed by the WG. The security model needs to be coordinated with the W3C. The work will also consider where support for extensibility is needed. RTP functionalities, media formats, security algorithms are example of things that commonly needs extensions, additions or replacement, and thus some support for negotiation between clients is required.
The WG will perform the following work: 1. Define the communication model in detail, including how session management is to occur within the model. 2. Define a security model that describes the security goals and how the communication model can achieve these goals. 3. Define how NAT and Firewall traversal is to occur. 4. Define which RTP functions and extensions that shall be supported in the client and their usage for real-time media, including media adaptation to ensure congestion safe usage. 5. Define what functionalities in the solution, such as media codecs, security algorithms, etc., that can be extended and how the extensibility mechanisms works. 6. Define a set of media formats that must or should be supported by a client to improve interoperability. 7. Define how non RTP datagram and byte stream data communication between the clients can be done securely and in a congestion safe way. 8. Provide W3C input for the APIs that comes from the communication model and the selected components and protocols that are part of the solution.
This work will be done primarily by using already defined protocols or functionalities. If there is identification of missing protocols or functionalities, such work can be requested to be done in another working group with a suitable charter or by requests for chartering it in this WG or another WG. The following topics will be out of scope for the initial phase of the WG but could be added after a recharter: RTSP, RSVP, NSIS, Location services, IM & Presence, Resource Priority.
The products of the working group will support security and keying as required by BCP 61 and be defined for IPv4, IPv6, and dual stack deployments. The Working Group will consider the possibility of defining a browser component that implements an existing session negotiation and management protocol. The working group will follow BCP 79, and adhere to the spirit of BCP 79. The working group cannot explicitly rule out the possibility of adopting encumbered technologies; however, the working group will try to avoid encumbered technologies that require royalties or other encumbrances that would prevent such technologies from being easy to use in web browsers.
Milestones:
Aug 2011 Architecture and Security and Threat Model sent to W3C
Aug 2011 Use cases and Scenarios document sent to W3C
Sept 2011 Architecture and Security and Threat Model to IESG as Informational
Sept 2011 Use cases and Scenarios for RTCWeb document sent to IESG as Informational
Dec 2011 RTCWeb and Media format specification(s) to IESG as PS
Dec 2011 Information elements and events APIs Input to W3C
Apr 2012 API to Protocol mapping document submitted to the IESG as Informational (if needed) _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
On Fri, Mar 18, 2011 at 10:17 AM, Elwell, John <john.elwell@siemens-enterprise.com> wrote:
Ted,
In the same way that charters tend to call out "horizontal" topics for special mention, such as security, privacy and NAT/firewall, I believe the ability to achieve interop with existing equipment should also be given a mention.
Hi John, Unsurprisingly, I am also a fan of interoperability. But I think there are multiple ways to scope interoperability. The charter currently does it by focusing on the interoperability we get at the protocol level, largely by choosing tools for this toolkit that match the tools already in place (e.g. RTP, ICE, etc.). I agree that we shouldn't select tools that are in place but unusable. I think we end up having to trust the working group on this anyway, as it will decide which tools are unusuable even if we insert a "don't pick unusable tools" section. So the basic question boils down to: do we also want to assert a need for interoperability with a specific application or set of applications in the charter? My personal take is no. Those are use cases, and important ones. But the charter is focused on building a toolkit "to enable innovation on top of a set of basic components." I have no doubt that someone will be able to build a fully backwards compatible service using these components and a gateway,. But the more important charter goal is to get the component set right to enable them to build more than that. And I think calling out that specific use case is more likely to limit our vision than to result in more clarity in picking protocols and tools. Again, just my personal opinion, regards, Ted Hardie
Note that I stop short of demanding backwards compatibility, but instead make a somewhat more flexible proposal.
Using defined protocols isn't necessarily sufficient if we pick things that are not implemented. As an extreme case, take S/MIME, for example.
John
-----Original Message----- From: Ted Hardie [mailto:ted.ietf@gmail.com] Sent: 18 March 2011 17:01 To: Elwell, John Cc: rtc-web@alvestrand.no Subject: Re: [RTW] New proposed charter text. Please review before the BoF.
On Fri, Mar 18, 2011 at 5:04 AM, Elwell, John <john.elwell@siemens-enterprise.com> wrote:
Ted,
I think there needs to be some mention of interop with existing real-time applications using IETF protocols (such as SIP, RTP). Something along the lines of: "Work should take account of browser-based applications that require to interoperate with existing applications using IETF protocols such as SIP and RTP and commonly deployed audio and video codecs. Solutions that require mediation functions to achieve interoperation might be acceptable, provided such functions are not unduly complex, expensive or detrimental to performance."
So, my personal read is that these work items:
"4. Define which RTP functions and extensions shall be supported in the client and their usage for real-time media, including media adaptation to ensure congestion safe usage. 5. Define what functionalities in the solution, such as media codecs, security algorithms, etc., can be extended and how the extensibility mechanisms works. 6. Define a set of media formats that must or should be supported by a client to improve interoperability."
and this general statement which follows the work items:
"This work will be done primarily by using already defined protocols or functionalities. "
Those seem to cover the same ground as your "take account of". If your aim is to get to something more concrete, like "you must be able to build a browser-based SIP softphone using the tools identified by this group", I think you need to unpack that a bit more. Some of the presence aspects of that toolkit, for example, may not be identified here.
To put this another way, my personal read is that we're aiming to create the toolkit needed to build real-time media applications in web contexts. Any specific application, including a SIP softphone, would be a use of the toolkit; those will be covered by something like draft-holmberg-rtcweb-ucreqs-00.txt as a use case, rather than in the charter.
Again, just my personal take on this.
regards,
Ted Hardie
John
-----Original Message----- From: rtc-web-bounces@alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of Ted Hardie Sent: 17 March 2011 16:18 To: rtc-web@alvestrand.no Subject: [RTW] New proposed charter text. Please review before the BoF.
Name: Real-Time Communication in WEB-browsers (RTCWeb)
There are a number of proprietary implementations that provide direct interactive rich communication using audio, video, collaboration, games, etc. between two peers' web-browsers. These are not interoperable, as they require non-standard extensions or plugins to work. There is a desire to standardize the basis for such communication so that interoperable communication can be established between any compatible browsers. The goal is to enable innovation on top of a set of basic components. One core component is to enable real-time media like audio and video, a second is to enable datagram and byte stream data transfer directly between clients.
This work will be done in collaboration with the W3C. The IETF WG will produce architecture and requirements for selection and profiling of the on the wire protocols. The architecture needs to be coordinated with W3C. The IETF WG work will identity state information and events that need to be exposed in the APIs as input to W3C. The W3C will be responsible for defining APIs to ensure that application developers can control the components.
The security goals and requirements will be developed by the WG. The security model needs to be coordinated with the W3C. The work will also consider where support for extensibility is needed. RTP functionalities, media formats, security algorithms are example of things that commonly needs extensions, additions or replacement, and thus some support for negotiation between clients is required.
The WG will perform the following work: 1. Define the communication model in detail, including how session management is to occur within the model. 2. Define a security model that describes the security goals and how the communication model can achieve these goals. 3. Define how NAT and Firewall traversal is to occur. 4. Define which RTP functions and extensions that shall be supported in the client and their usage for real-time media, including media adaptation to ensure congestion safe usage. 5. Define what functionalities in the solution, such as media codecs, security algorithms, etc., that can be extended and how the extensibility mechanisms works. 6. Define a set of media formats that must or should be supported by a client to improve interoperability. 7. Define how non RTP datagram and byte stream data communication between the clients can be done securely and in a congestion safe way. 8. Provide W3C input for the APIs that comes from the communication model and the selected components and protocols that are part of the solution.
This work will be done primarily by using already defined protocols or functionalities. If there is identification of missing protocols or functionalities, such work can be requested to be done in another working group with a suitable charter or by requests for chartering it in this WG or another WG. The following topics will be out of scope for the initial phase of the WG but could be added after a recharter: RTSP, RSVP, NSIS, Location services, IM & Presence, Resource Priority.
The products of the working group will support security and keying as required by BCP 61 and be defined for IPv4, IPv6, and dual stack deployments. The Working Group will consider the possibility of defining a browser component that implements an existing session negotiation and management protocol. The working group will follow BCP 79, and adhere to the spirit of BCP 79. The working group cannot explicitly rule out the possibility of adopting encumbered technologies; however, the working group will try to avoid encumbered technologies that require royalties or other encumbrances that would prevent such technologies from being easy to use in web browsers.
Milestones:
Aug 2011 Architecture and Security and Threat Model sent to W3C
Aug 2011 Use cases and Scenarios document sent to W3C
Sept 2011 Architecture and Security and Threat Model to IESG as Informational
Sept 2011 Use cases and Scenarios for RTCWeb document sent to IESG as Informational
Dec 2011 RTCWeb and Media format specification(s) to IESG as PS
Dec 2011 Information elements and events APIs Input to W3C
Apr 2012 API to Protocol mapping document submitted to the IESG as Informational (if needed) _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
Hi, Regarding interoperability (or, creating new solutions in general), there are a couple of things we need to consider. One is of course the protocols supported by the browser (e.g RTP, ICE etc). The second, which I THINK John is referring to, is to ensure that web applications (whether they are SIP based or based on something else) are able to ENABLE the browser protocols and features in a good and effective way. For that we need to ensure that the API between the browser and the web app is powerful enough. In the ucreqs document, we have tried to differentiate between those two things by having separate browser requirements and API requirements. Regards, Christer ________________________________________ From: rtc-web-bounces@alvestrand.no [rtc-web-bounces@alvestrand.no] On Behalf Of Ted Hardie [ted.ietf@gmail.com] Sent: Friday, March 18, 2011 7:38 PM To: Elwell, John Cc: rtc-web@alvestrand.no Subject: Re: [RTW] New proposed charter text. Please review before the BoF. On Fri, Mar 18, 2011 at 10:17 AM, Elwell, John <john.elwell@siemens-enterprise.com> wrote:
Ted,
In the same way that charters tend to call out "horizontal" topics for special mention, such as security, privacy and NAT/firewall, I believe the ability to achieve interop with existing equipment should also be given a mention.
Hi John, Unsurprisingly, I am also a fan of interoperability. But I think there are multiple ways to scope interoperability. The charter currently does it by focusing on the interoperability we get at the protocol level, largely by choosing tools for this toolkit that match the tools already in place (e.g. RTP, ICE, etc.). I agree that we shouldn't select tools that are in place but unusable. I think we end up having to trust the working group on this anyway, as it will decide which tools are unusuable even if we insert a "don't pick unusable tools" section. So the basic question boils down to: do we also want to assert a need for interoperability with a specific application or set of applications in the charter? My personal take is no. Those are use cases, and important ones. But the charter is focused on building a toolkit "to enable innovation on top of a set of basic components." I have no doubt that someone will be able to build a fully backwards compatible service using these components and a gateway,. But the more important charter goal is to get the component set right to enable them to build more than that. And I think calling out that specific use case is more likely to limit our vision than to result in more clarity in picking protocols and tools. Again, just my personal opinion, regards, Ted Hardie
Note that I stop short of demanding backwards compatibility, but instead make a somewhat more flexible proposal.
Using defined protocols isn't necessarily sufficient if we pick things that are not implemented. As an extreme case, take S/MIME, for example.
John
-----Original Message----- From: Ted Hardie [mailto:ted.ietf@gmail.com] Sent: 18 March 2011 17:01 To: Elwell, John Cc: rtc-web@alvestrand.no Subject: Re: [RTW] New proposed charter text. Please review before the BoF.
On Fri, Mar 18, 2011 at 5:04 AM, Elwell, John <john.elwell@siemens-enterprise.com> wrote:
Ted,
I think there needs to be some mention of interop with existing real-time applications using IETF protocols (such as SIP, RTP). Something along the lines of: "Work should take account of browser-based applications that require to interoperate with existing applications using IETF protocols such as SIP and RTP and commonly deployed audio and video codecs. Solutions that require mediation functions to achieve interoperation might be acceptable, provided such functions are not unduly complex, expensive or detrimental to performance."
So, my personal read is that these work items:
"4. Define which RTP functions and extensions shall be supported in the client and their usage for real-time media, including media adaptation to ensure congestion safe usage. 5. Define what functionalities in the solution, such as media codecs, security algorithms, etc., can be extended and how the extensibility mechanisms works. 6. Define a set of media formats that must or should be supported by a client to improve interoperability."
and this general statement which follows the work items:
"This work will be done primarily by using already defined protocols or functionalities. "
Those seem to cover the same ground as your "take account of". If your aim is to get to something more concrete, like "you must be able to build a browser-based SIP softphone using the tools identified by this group", I think you need to unpack that a bit more. Some of the presence aspects of that toolkit, for example, may not be identified here.
To put this another way, my personal read is that we're aiming to create the toolkit needed to build real-time media applications in web contexts. Any specific application, including a SIP softphone, would be a use of the toolkit; those will be covered by something like draft-holmberg-rtcweb-ucreqs-00.txt as a use case, rather than in the charter.
Again, just my personal take on this.
regards,
Ted Hardie
John
-----Original Message----- From: rtc-web-bounces@alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of Ted Hardie Sent: 17 March 2011 16:18 To: rtc-web@alvestrand.no Subject: [RTW] New proposed charter text. Please review before the BoF.
Name: Real-Time Communication in WEB-browsers (RTCWeb)
There are a number of proprietary implementations that provide direct interactive rich communication using audio, video, collaboration, games, etc. between two peers' web-browsers. These are not interoperable, as they require non-standard extensions or plugins to work. There is a desire to standardize the basis for such communication so that interoperable communication can be established between any compatible browsers. The goal is to enable innovation on top of a set of basic components. One core component is to enable real-time media like audio and video, a second is to enable datagram and byte stream data transfer directly between clients.
This work will be done in collaboration with the W3C. The IETF WG will produce architecture and requirements for selection and profiling of the on the wire protocols. The architecture needs to be coordinated with W3C. The IETF WG work will identity state information and events that need to be exposed in the APIs as input to W3C. The W3C will be responsible for defining APIs to ensure that application developers can control the components.
The security goals and requirements will be developed by the WG. The security model needs to be coordinated with the W3C. The work will also consider where support for extensibility is needed. RTP functionalities, media formats, security algorithms are example of things that commonly needs extensions, additions or replacement, and thus some support for negotiation between clients is required.
The WG will perform the following work: 1. Define the communication model in detail, including how session management is to occur within the model. 2. Define a security model that describes the security goals and how the communication model can achieve these goals. 3. Define how NAT and Firewall traversal is to occur. 4. Define which RTP functions and extensions that shall be supported in the client and their usage for real-time media, including media adaptation to ensure congestion safe usage. 5. Define what functionalities in the solution, such as media codecs, security algorithms, etc., that can be extended and how the extensibility mechanisms works. 6. Define a set of media formats that must or should be supported by a client to improve interoperability. 7. Define how non RTP datagram and byte stream data communication between the clients can be done securely and in a congestion safe way. 8. Provide W3C input for the APIs that comes from the communication model and the selected components and protocols that are part of the solution.
This work will be done primarily by using already defined protocols or functionalities. If there is identification of missing protocols or functionalities, such work can be requested to be done in another working group with a suitable charter or by requests for chartering it in this WG or another WG. The following topics will be out of scope for the initial phase of the WG but could be added after a recharter: RTSP, RSVP, NSIS, Location services, IM & Presence, Resource Priority.
The products of the working group will support security and keying as required by BCP 61 and be defined for IPv4, IPv6, and dual stack deployments. The Working Group will consider the possibility of defining a browser component that implements an existing session negotiation and management protocol. The working group will follow BCP 79, and adhere to the spirit of BCP 79. The working group cannot explicitly rule out the possibility of adopting encumbered technologies; however, the working group will try to avoid encumbered technologies that require royalties or other encumbrances that would prevent such technologies from being easy to use in web browsers.
Milestones:
Aug 2011 Architecture and Security and Threat Model sent to W3C
Aug 2011 Use cases and Scenarios document sent to W3C
Sept 2011 Architecture and Security and Threat Model to IESG as Informational
Sept 2011 Use cases and Scenarios for RTCWeb document sent to IESG as Informational
Dec 2011 RTCWeb and Media format specification(s) to IESG as PS
Dec 2011 Information elements and events APIs Input to W3C
Apr 2012 API to Protocol mapping document submitted to the IESG as Informational (if needed) _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
-----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: 19 March 2011 11:22 To: Ted Hardie; Elwell, John Cc: rtc-web@alvestrand.no Subject: RE: [RTW] New proposed charter text. Please review before the BoF.
Hi,
Regarding interoperability (or, creating new solutions in general), there are a couple of things we need to consider.
One is of course the protocols supported by the browser (e.g RTP, ICE etc).
The second, which I THINK John is referring to, is to ensure that web applications (whether they are SIP based or based on something else) are able to ENABLE the browser protocols and features in a good and effective way. For that we need to ensure that the API between the browser and the web app is powerful enough. [JRE] That might be one of the consequences - if the browser is able to use a protocol that is not interoperable with existing equipment and a protocol that is interoperable, then clearly an application wanting to interoperate would want to be able to choose the latter.
That was not the main point of my proposed addition to the charter - the main point was that the set of mandatory-to-implement protocols in the browser should include those that can interoperate in a reasonable way with existing equipment. Based on discussions to date, the most problematic is likely to be codecs, particularly video codecs, because of the cost and performance degradation when transcoding has to be done. John
In the ucreqs document, we have tried to differentiate between those two things by having separate browser requirements and API requirements.
Regards,
Christer
________________________________________ From: rtc-web-bounces@alvestrand.no [rtc-web-bounces@alvestrand.no] On Behalf Of Ted Hardie [ted.ietf@gmail.com] Sent: Friday, March 18, 2011 7:38 PM To: Elwell, John Cc: rtc-web@alvestrand.no Subject: Re: [RTW] New proposed charter text. Please review before the BoF.
On Fri, Mar 18, 2011 at 10:17 AM, Elwell, John <john.elwell@siemens-enterprise.com> wrote:
Ted,
In the same way that charters tend to call out "horizontal" topics for special mention, such as security, privacy and NAT/firewall, I believe the ability to achieve interop with existing equipment should also be given a mention.
Hi John,
Unsurprisingly, I am also a fan of interoperability. But I think there are multiple ways to scope interoperability. The charter currently does it by focusing on the interoperability we get at the protocol level, largely by choosing tools for this toolkit that match the tools already in place (e.g. RTP, ICE, etc.). I agree that we shouldn't select tools that are in place but unusable. I think we end up having to trust the working group on this anyway, as it will decide which tools are unusuable even if we insert a "don't pick unusable tools" section.
So the basic question boils down to: do we also want to assert a need for interoperability with a specific application or set of applications in the charter?
My personal take is no. Those are use cases, and important ones. But the charter is focused on building a toolkit "to enable innovation on top of a set of basic components." I have no doubt that someone will be able to build a fully backwards compatible service using these components and a gateway,. But the more important charter goal is to get the component set right to enable them to build more than that. And I think calling out that specific use case is more likely to limit our vision than to result in more clarity in picking protocols and tools.
Again, just my personal opinion,
regards,
Ted Hardie
Note that I stop short of demanding backwards compatibility, but instead make a somewhat more flexible proposal.
Using defined protocols isn't necessarily sufficient if we pick things that are not implemented. As an extreme case, take S/MIME, for example.
John
-----Original Message----- From: Ted Hardie [mailto:ted.ietf@gmail.com] Sent: 18 March 2011 17:01 To: Elwell, John Cc: rtc-web@alvestrand.no Subject: Re: [RTW] New proposed charter text. Please review before the BoF.
On Fri, Mar 18, 2011 at 5:04 AM, Elwell, John <john.elwell@siemens-enterprise.com> wrote:
Ted,
I think there needs to be some mention of interop with existing real-time applications using IETF protocols (such as SIP, RTP). Something along the lines of: "Work should take account of browser-based applications that require to interoperate with existing applications using IETF protocols such as SIP and RTP and commonly deployed audio and video codecs. Solutions that require mediation functions to achieve interoperation might be acceptable, provided such functions are not unduly complex, expensive or detrimental to performance."
So, my personal read is that these work items:
"4. Define which RTP functions and extensions shall be supported in the client and their usage for real-time media, including media adaptation to ensure congestion safe usage. 5. Define what functionalities in the solution, such as media codecs, security algorithms, etc., can be extended and how the extensibility mechanisms works. 6. Define a set of media formats that must or should be supported by a client to improve interoperability."
and this general statement which follows the work items:
"This work will be done primarily by using already defined protocols or functionalities. "
Those seem to cover the same ground as your "take account of". If your aim is to get to something more concrete, like "you must be able to build a browser-based SIP softphone using the tools identified by this group", I think you need to unpack that a bit more. Some of the presence aspects of that toolkit, for example, may not be identified here.
To put this another way, my personal read is that we're aiming to create the toolkit needed to build real-time media applications in web contexts. Any specific application, including a SIP softphone, would be a use of the toolkit; those will be covered by something like draft-holmberg-rtcweb-ucreqs-00.txt as a use case, rather than in the charter.
Again, just my personal take on this.
regards,
Ted Hardie
John
-----Original Message----- From: rtc-web-bounces@alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of Ted Hardie Sent: 17 March 2011 16:18 To: rtc-web@alvestrand.no Subject: [RTW] New proposed charter text. Please review before the BoF.
Name: Real-Time Communication in WEB-browsers (RTCWeb)
There are a number of proprietary implementations that provide direct interactive rich communication using audio, video, collaboration, games, etc. between two peers' web-browsers. These are not interoperable, as they require non-standard extensions or plugins to work. There is a desire to standardize the basis for such communication so that interoperable communication can be established between any compatible browsers. The goal is to enable innovation on top of a set of basic components. One core component is to enable real-time media like audio and video, a second is to enable datagram and byte stream data transfer directly between clients.
This work will be done in collaboration with the W3C. The IETF WG will produce architecture and requirements for selection and profiling of the on the wire protocols. The architecture needs to be coordinated with W3C. The IETF WG work will identity state information and events that need to be exposed in the APIs as input to W3C. The W3C will be responsible for defining APIs to ensure that application developers can control the components.
The security goals and requirements will be developed by the WG. The security model needs to be coordinated with the W3C. The work will also consider where support for extensibility is needed. RTP functionalities, media formats, security algorithms are example of things that commonly needs extensions, additions or replacement, and thus some support for negotiation between clients is required.
The WG will perform the following work: 1. Define the communication model in detail, including how session management is to occur within the model. 2. Define a security model that describes the security goals and how the communication model can achieve these goals. 3. Define how NAT and Firewall traversal is to occur. 4. Define which RTP functions and extensions that shall be supported in the client and their usage for real-time media, including media adaptation to ensure congestion safe usage. 5. Define what functionalities in the solution, such as media codecs, security algorithms, etc., that can be extended and how the extensibility mechanisms works. 6. Define a set of media formats that must or should be supported by a client to improve interoperability. 7. Define how non RTP datagram and byte stream data communication between the clients can be done securely and in a congestion safe way. 8. Provide W3C input for the APIs that comes from the communication model and the selected components and protocols that are part of the solution.
This work will be done primarily by using already defined protocols or functionalities. If there is identification of missing protocols or functionalities, such work can be requested to be done in another working group with a suitable charter or by requests for chartering it in this WG or another WG. The following topics will be out of scope for the initial phase of the WG but could be added after a recharter: RTSP, RSVP, NSIS, Location services, IM & Presence, Resource Priority.
The products of the working group will support security and keying as required by BCP 61 and be defined for IPv4, IPv6, and dual stack deployments. The Working Group will consider the possibility of defining a browser component that implements an existing session negotiation and management protocol. The working group will follow BCP 79, and adhere to the spirit of BCP 79. The working group cannot explicitly rule out the possibility of adopting encumbered technologies; however, the working group will try to avoid encumbered technologies that require royalties or other encumbrances that would prevent such technologies from being easy to use in web browsers.
Milestones:
Aug 2011 Architecture and Security and Threat Model sent to W3C
Aug 2011 Use cases and Scenarios document sent to W3C
Sept 2011 Architecture and Security and Threat Model to IESG as Informational
Sept 2011 Use cases and Scenarios for RTCWeb document sent to IESG as Informational
Dec 2011 RTCWeb and Media format specification(s) to IESG as PS
Dec 2011 Information elements and events APIs Input to W3C
Apr 2012 API to Protocol mapping document submitted to the IESG as Informational (if needed) _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
Hi, I think Christer's comment is really important. If the web application is going to be responsible for ensuring interoperability with SIP or anything else then the API between the browser and the web application needs to be flexible and powerful to enable this interoperability to take place. So I believe the charter needs to make it clear that the input for this API that the IETF provides to W3C will take in to account the fact that the web application has to achieve interoperability with non RTC-Web based systems of which SIP/SDP based systems are the obvious example. Regards Andy
-----Original Message----- From: rtc-web-bounces@alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of Elwell, John Sent: 21 March 2011 07:41 To: Christer Holmberg; Ted Hardie Cc: rtc-web@alvestrand.no Subject: Re: [RTW] New proposed charter text. Please review before the BoF.
-----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: 19 March 2011 11:22 To: Ted Hardie; Elwell, John Cc: rtc-web@alvestrand.no Subject: RE: [RTW] New proposed charter text. Please review before the BoF.
Hi,
Regarding interoperability (or, creating new solutions in general), there are a couple of things we need to consider.
One is of course the protocols supported by the browser (e.g RTP, ICE etc).
The second, which I THINK John is referring to, is to ensure that web applications (whether they are SIP based or based on something else) are able to ENABLE the browser protocols and features in a good and effective way. For that we need to ensure that the API between the browser and the web app is powerful enough. [JRE] That might be one of the consequences - if the browser is able to use a protocol that is not interoperable with existing equipment and a protocol that is interoperable, then clearly an application wanting to interoperate would want to be able to choose the latter.
That was not the main point of my proposed addition to the charter - the main point was that the set of mandatory-to-implement protocols in the browser should include those that can interoperate in a reasonable way with existing equipment. Based on discussions to date, the most problematic is likely to be codecs, particularly video codecs, because of the cost and performance degradation when transcoding has to be done.
John
In the ucreqs document, we have tried to differentiate between those two things by having separate browser requirements and API requirements.
Regards,
Christer
________________________________________ From: rtc-web-bounces@alvestrand.no [rtc-web-bounces@alvestrand.no] On Behalf Of Ted Hardie [ted.ietf@gmail.com] Sent: Friday, March 18, 2011 7:38 PM To: Elwell, John Cc: rtc-web@alvestrand.no Subject: Re: [RTW] New proposed charter text. Please review before the BoF.
On Fri, Mar 18, 2011 at 10:17 AM, Elwell, John <john.elwell@siemens-enterprise.com> wrote:
Ted,
In the same way that charters tend to call out "horizontal" topics for special mention, such as security, privacy and NAT/firewall, I believe the ability to achieve interop with existing equipment should also be given a mention.
Hi John,
Unsurprisingly, I am also a fan of interoperability. But I think there are multiple ways to scope interoperability. The charter currently does it by focusing on the interoperability we get at the protocol level, largely by choosing tools for this toolkit
that match
the tools already in place (e.g. RTP, ICE, etc.). I agree that we shouldn't select tools that are in place but unusable. I think we end up having to trust the working group on this anyway, as it will decide which tools are unusuable even if we insert a "don't pick unusable tools" section.
So the basic question boils down to: do we also want to assert a need for interoperability with a specific application or set of applications in the charter?
My personal take is no. Those are use cases, and important ones. But the charter is focused on building a toolkit "to enable innovation on top of a set of basic components." I have no doubt that someone will be able to build a fully backwards compatible service using these components and a gateway,. But the more important charter goal is to get the component set right to enable them to build more than that. And I think calling out that specific use case is more likely to limit our vision than to result in more clarity in picking protocols and tools.
Again, just my personal opinion,
regards,
Ted Hardie
Note that I stop short of demanding backwards compatibility, but instead make a somewhat more flexible proposal.
Using defined protocols isn't necessarily sufficient if we pick things that are not implemented. As an extreme case, take S/MIME, for example.
John
-----Original Message----- From: Ted Hardie [mailto:ted.ietf@gmail.com] Sent: 18 March 2011 17:01 To: Elwell, John Cc: rtc-web@alvestrand.no Subject: Re: [RTW] New proposed charter text. Please review before the BoF.
On Fri, Mar 18, 2011 at 5:04 AM, Elwell, John <john.elwell@siemens-enterprise.com> wrote:
Ted,
I think there needs to be some mention of interop with existing real-time applications using IETF protocols (such as SIP, RTP). Something along the lines of: "Work should take account of browser-based applications that require to interoperate with existing applications using IETF protocols such as SIP and RTP and commonly deployed audio and video codecs. Solutions that require mediation functions to achieve interoperation might be acceptable, provided such functions are not unduly complex, expensive or detrimental to performance."
So, my personal read is that these work items:
"4. Define which RTP functions and extensions shall be supported in the client and their usage for real-time media, including media adaptation to ensure congestion safe usage. 5. Define what functionalities in the solution, such as media codecs, security algorithms, etc., can be extended and how the extensibility mechanisms works. 6. Define a set of media formats that must or should be supported by a client to improve interoperability."
and this general statement which follows the work items:
"This work will be done primarily by using already defined protocols or functionalities. "
Those seem to cover the same ground as your "take account of". If your aim is to get to something more concrete, like "you must be able to build a browser-based SIP softphone using the tools identified by this group", I think you need to unpack that a bit more. Some of the presence aspects of that toolkit, for example, may not be identified here.
To put this another way, my personal read is that we're aiming to create the toolkit needed to build real-time media applications in web contexts. Any specific application, including a SIP softphone, would be a use of the toolkit; those will be covered by something like draft-holmberg-rtcweb-ucreqs-00.txt as a use case, rather than in the charter.
Again, just my personal take on this.
regards,
Ted Hardie
John
-----Original Message----- From: rtc-web-bounces@alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of Ted Hardie Sent: 17 March 2011 16:18 To: rtc-web@alvestrand.no Subject: [RTW] New proposed charter text. Please review before the BoF.
Name: Real-Time Communication in WEB-browsers (RTCWeb)
There are a number of proprietary implementations that provide direct interactive rich communication using audio, video, collaboration, games, etc. between two peers' web-browsers. These are not interoperable, as they require non-standard extensions or plugins to work. There is a desire to standardize the basis for such communication so that interoperable communication can be established between any compatible browsers. The goal is to enable innovation on top of a set of basic components. One core component is to enable real-time media like audio and video, a second is to enable datagram and byte stream data transfer directly between clients.
This work will be done in collaboration with the W3C. The IETF WG will produce architecture and requirements for selection and profiling of the on the wire protocols. The architecture needs to be coordinated with W3C. The IETF WG work will identity state information and events that need to be exposed in the APIs as input to W3C. The W3C will be responsible for defining APIs to ensure that application developers can control the components.
The security goals and requirements will be developed by the WG. The security model needs to be coordinated with the W3C. The work will also consider where support for extensibility is needed. RTP functionalities, media formats, security algorithms are example of things that commonly needs extensions, additions or replacement, and thus some support for negotiation between clients is required.
The WG will perform the following work: 1. Define the communication model in detail, including how session management is to occur within the model. 2. Define a security model that describes the security goals and how the communication model can achieve these goals. 3. Define how NAT and Firewall traversal is to occur. 4. Define which RTP functions and extensions that shall be supported in the client and their usage for real-time media, including media adaptation to ensure congestion safe usage. 5. Define what functionalities in the solution, such as media codecs, security algorithms, etc., that can be extended and how the extensibility mechanisms works. 6. Define a set of media formats that must or should be supported by a client to improve interoperability. 7. Define how non RTP datagram and byte stream data communication between the clients can be done securely and in a congestion safe way. 8. Provide W3C input for the APIs that comes from the communication model and the selected components and protocols that are part of the solution.
This work will be done primarily by using already defined protocols or functionalities. If there is identification of missing protocols or functionalities, such work can be requested to be done in another working group with a suitable charter or by requests for chartering it in this WG or another WG. The following topics will be out of scope for the initial phase of the WG but could be added after a recharter: RTSP, RSVP, NSIS, Location services, IM & Presence, Resource Priority.
The products of the working group will support security and keying as required by BCP 61 and be defined for IPv4, IPv6, and dual stack deployments. The Working Group will consider the possibility of defining a browser component that implements an existing session negotiation and management protocol. The working group will follow BCP 79, and adhere to the spirit of BCP 79. The working group cannot explicitly rule out the possibility of adopting encumbered technologies; however, the working group will try to avoid encumbered technologies that require royalties or other encumbrances that would prevent such technologies from being easy to use in web browsers.
Milestones:
Aug 2011 Architecture and Security and Threat Model sent to W3C
Aug 2011 Use cases and Scenarios document sent to W3C
Sept 2011 Architecture and Security and Threat Model to IESG as Informational
Sept 2011 Use cases and Scenarios for RTCWeb document sent to IESG as Informational
Dec 2011 RTCWeb and Media format specification(s) to IESG as PS
Dec 2011 Information elements and events APIs Input to W3C
Apr 2012 API to Protocol mapping document submitted to the IESG as Informational (if needed) _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
OK, so what I think Christer and Andy are saying is that it is not just about having the right the mandatory-to-implement protocols, codecs, etc., but also about sufficient control at the API so that appropriate ones can be selected when interoperating with existing equipment. I would agree with that. Do Christer and Andy consider my text proposal for the charter to be sufficient, or does it need changing or extending? John
-----Original Message----- From: Hutton, Andrew Sent: 21 March 2011 14:16 To: Elwell, John; Christer Holmberg; Ted Hardie Cc: rtc-web@alvestrand.no Subject: RE: [RTW] New proposed charter text. Please review before the BoF.
Hi,
I think Christer's comment is really important.
If the web application is going to be responsible for ensuring interoperability with SIP or anything else then the API between the browser and the web application needs to be flexible and powerful to enable this interoperability to take place. So I believe the charter needs to make it clear that the input for this API that the IETF provides to W3C will take in to account the fact that the web application has to achieve interoperability with non RTC-Web based systems of which SIP/SDP based systems are the obvious example.
Regards Andy
-----Original Message----- From: rtc-web-bounces@alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of Elwell, John Sent: 21 March 2011 07:41 To: Christer Holmberg; Ted Hardie Cc: rtc-web@alvestrand.no Subject: Re: [RTW] New proposed charter text. Please review before the BoF.
-----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: 19 March 2011 11:22 To: Ted Hardie; Elwell, John Cc: rtc-web@alvestrand.no Subject: RE: [RTW] New proposed charter text. Please review before the BoF.
Hi,
Regarding interoperability (or, creating new solutions in general), there are a couple of things we need to consider.
One is of course the protocols supported by the browser (e.g RTP, ICE etc).
The second, which I THINK John is referring to, is to ensure that web applications (whether they are SIP based or based on something else) are able to ENABLE the browser protocols and features in a good and effective way. For that we need to ensure that the API between the browser and the web app is powerful enough. [JRE] That might be one of the consequences - if the browser is able to use a protocol that is not interoperable with existing equipment and a protocol that is interoperable, then clearly an application wanting to interoperate would want to be able to choose the latter.
That was not the main point of my proposed addition to the charter - the main point was that the set of mandatory-to-implement protocols in the browser should include those that can interoperate in a reasonable way with existing equipment. Based on discussions to date, the most problematic is likely to be codecs, particularly video codecs, because of the cost and performance degradation when transcoding has to be done.
John
In the ucreqs document, we have tried to differentiate between those two things by having separate browser requirements and API requirements.
Regards,
Christer
________________________________________ From: rtc-web-bounces@alvestrand.no [rtc-web-bounces@alvestrand.no] On Behalf Of Ted Hardie [ted.ietf@gmail.com] Sent: Friday, March 18, 2011 7:38 PM To: Elwell, John Cc: rtc-web@alvestrand.no Subject: Re: [RTW] New proposed charter text. Please review before the BoF.
On Fri, Mar 18, 2011 at 10:17 AM, Elwell, John <john.elwell@siemens-enterprise.com> wrote:
Ted,
In the same way that charters tend to call out "horizontal" topics for special mention, such as security, privacy and NAT/firewall, I believe the ability to achieve interop with existing equipment should also be given a mention.
Hi John,
Unsurprisingly, I am also a fan of interoperability. But I think there are multiple ways to scope interoperability. The charter currently does it by focusing on the interoperability we
get at the
protocol level, largely by choosing tools for this toolkit that match the tools already in place (e.g. RTP, ICE, etc.). I agree that we shouldn't select tools that are in place but unusable. I think we end up having to trust the working group on this anyway, as it will decide which tools are unusuable even if we insert a "don't pick unusable tools" section.
So the basic question boils down to: do we also want to assert a need for interoperability with a specific application or set of applications in the charter?
My personal take is no. Those are use cases, and important ones. But the charter is focused on building a toolkit "to enable innovation on top of a set of basic components." I have no doubt that someone will be able to build a fully backwards compatible service using these components and a gateway,. But the more important charter goal is to get the component set right to enable them to build more than that. And I think calling out that specific use case is more likely to limit our vision than to result in more clarity in picking protocols and tools.
Again, just my personal opinion,
regards,
Ted Hardie
Note that I stop short of demanding backwards compatibility, but instead make a somewhat more flexible proposal.
Using defined protocols isn't necessarily sufficient if we pick things that are not implemented. As an extreme case, take S/MIME, for example.
John
-----Original Message----- From: Ted Hardie [mailto:ted.ietf@gmail.com] Sent: 18 March 2011 17:01 To: Elwell, John Cc: rtc-web@alvestrand.no Subject: Re: [RTW] New proposed charter text. Please review before the BoF.
On Fri, Mar 18, 2011 at 5:04 AM, Elwell, John <john.elwell@siemens-enterprise.com> wrote:
Ted,
I think there needs to be some mention of interop with existing real-time applications using IETF protocols (such as SIP, RTP). Something along the lines of: "Work should take account of browser-based applications that require to interoperate with existing applications using IETF protocols such as SIP and RTP and commonly deployed audio and video codecs. Solutions that require mediation functions to achieve interoperation might be acceptable, provided such functions are not unduly complex, expensive or detrimental to performance."
So, my personal read is that these work items:
"4. Define which RTP functions and extensions shall be supported in the client and their usage for real-time media, including media adaptation to ensure congestion safe usage. 5. Define what functionalities in the solution, such as media codecs, security algorithms, etc., can be extended and how the extensibility mechanisms works. 6. Define a set of media formats that must or should be supported by a client to improve interoperability."
and this general statement which follows the work items:
"This work will be done primarily by using already defined protocols or functionalities. "
Those seem to cover the same ground as your "take account of". If your aim is to get to something more concrete, like "you must be able to build a browser-based SIP softphone using the tools identified by this group", I think you need to unpack that a bit more. Some of the presence aspects of that toolkit, for example, may not be identified here.
To put this another way, my personal read is that we're aiming to create the toolkit needed to build real-time media applications in web contexts. Any specific application, including a SIP softphone, would be a use of the toolkit; those will be covered by something like draft-holmberg-rtcweb-ucreqs-00.txt as a use case, rather than in the charter.
Again, just my personal take on this.
regards,
Ted Hardie
John
> -----Original Message----- > From: rtc-web-bounces@alvestrand.no > [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of Ted Hardie > Sent: 17 March 2011 16:18 > To: rtc-web@alvestrand.no > Subject: [RTW] New proposed charter text. Please review > before the BoF. > > Name: Real-Time Communication in WEB-browsers (RTCWeb) > > There are a number of proprietary implementations that provide direct > interactive rich communication using audio, video, collaboration, > games, etc. between two peers' web-browsers. These are not > interoperable, as they require non-standard extensions or plugins to > work. There is a desire to standardize the basis for such > communication so that interoperable communication can be established > between any compatible browsers. The goal is to enable innovation on > top of a set of basic components. One core component is to enable > real-time media like audio and video, a second is to enable datagram > and byte stream data transfer directly between clients. > > This work will be done in collaboration with the W3C. The IETF WG > will produce architecture and requirements for selection and profiling > of the on the wire protocols. The architecture needs to be coordinated > with W3C. The IETF WG work will identity state information and events > that need to be exposed in the APIs as input to W3C. The W3C will be > responsible for defining APIs to ensure that application developers > can control the components. > > The security goals and requirements will be developed by the WG. The > security model needs to be coordinated with the W3C. The work will > also consider where support for extensibility is needed. RTP > functionalities, media formats, security algorithms are example of > things that commonly needs extensions, additions or replacement, and > thus some support for negotiation between clients is required. > > The WG will perform the following work: > 1. Define the communication model in detail, including how session > management is to occur within the model. > 2. Define a security model that describes the security goals and > how the communication model can achieve these goals. > 3. Define how NAT and Firewall traversal is to occur. > 4. Define which RTP functions and extensions that shall be > supported in the client and their usage for real-time media, including > media adaptation to ensure congestion safe usage. > 5. Define what functionalities in the solution, such as media > codecs, security algorithms, etc., that can be extended and how the > extensibility mechanisms works. > 6. Define a set of media formats that must or should be supported > by a client to improve interoperability. > 7. Define how non RTP datagram and byte stream data communication > between the clients can be done securely and in a congestion safe way. > 8. Provide W3C input for the APIs that comes from the > communication model and the selected components and protocols that are > part of the solution. > > > This work will be done primarily by using already defined protocols or > functionalities. If there is identification of missing protocols or > functionalities, such work can be requested to be done in another > working group with a suitable charter or by requests for chartering it > in this WG or another WG. The following topics will be out of scope > for the initial phase of the WG but could be added after a recharter: > RTSP, RSVP, NSIS, Location services, IM & Presence, Resource Priority. > > The products of the working group will support security and keying as > required by BCP 61 and be defined for IPv4, IPv6, and dual stack > deployments. The Working Group will consider the possibility of > defining a browser component that implements an existing session > negotiation and management protocol. The working group will follow BCP > 79, and adhere to the spirit of BCP 79. The working group cannot > explicitly rule out the possibility of adopting encumbered > technologies; however, the working group will try to avoid encumbered > technologies that require royalties or other encumbrances that would > prevent such technologies from being easy to use in web browsers. > > Milestones: > > Aug 2011 Architecture and Security and Threat Model sent to W3C > > Aug 2011 Use cases and Scenarios document sent to W3C > > Sept 2011 Architecture and Security and Threat Model to IESG > as Informational > > Sept 2011 Use cases and Scenarios for RTCWeb document sent to IESG as > Informational > > Dec 2011 RTCWeb and Media format specification(s) to IESG as PS > > Dec 2011 Information elements and events APIs Input to W3C > > Apr 2012 API to Protocol mapping document submitted to the IESG as > Informational (if needed) > _______________________________________________ > RTC-Web mailing list > RTC-Web@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/rtc-web >
RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
So at one point we had some text along the lines of the proposed "Solutions that require mediation functions to achieve interoperation might be acceptable, provided such functions are not unduly complex, expensive or detrimental to performance." But I think that sort of text does not turns out to be useful in a charter. It is so vague and ambiguous that it does not guide the work. So lets dig into the things that might guide the work and see what we could do in a charter. Clearly we need extensibility and ways of negotiating new things. There many points were we need extensibility but video codecs are one of them. Twelve years down the road, its highly likely that there will be new codecs in browsers beyond what we have today - who knows, perhaps they will do 3D. Clearly we need a way for an browser application to find out which codecs that browser supports then use that for negotiation. But, in as Henning nicely put it, to avoid failure of negotiation, we need some minimal set of things all browsers have. With something like crypto algorithms for SRTP, the odds are good we can easily find something that was both acceptable to browsers and was widely supported by legacy voip equipment that does SRTP. With something like narrowband audio codecs it gets harder, but it is probably possible to come to something workable for a many cases. Phone BCP did. As you point out, video in some way has the highest cost of interoperability failure, but the bad news is that unfortunately legacy voip equipment already has widespread interoperability failure on video codec choices. Probably the most prevalent codec in interactive sessions is H.263 but much of the new equipment does not support that. Even the equipment that supports H.264 AVC (ignoring SVC), there are so many variants that much of the H.264 systems have no common way of interoperating with other H.264 systems. To have widespread support for legacy video equipment, browsers would have to implement a lot of codecs and profiles. H.265 is slated to be completed before I would expect this work to be deployed in the bulk of browser. Then there is the MPEG work on codecs that proponents hope will be royalty free. Not to mention some other obvious candidates that are widely used. GIven the lack of a common video codec in existing legacy equipment, I don't see how this working group could fix that. However, I think this working group needs to pick something that ensure that equipment compliant with specifications from the proposed WG does not suffer from the same video interoperability failure as legacy equipment. On the topic of what will be the hardest point of interoperability with legacy systems, I think it will be ICE like connectivity check issues. Every proposal I have seen so far has solved the problem of authorizing where the browser can send packets RTP by some connectivity check scheme such as ICE. However, ICE is not implemented the major of legacy voip equipment and I think this will end up being the biggest factor reducing what legacy equipment can work. Someone in the working group might think of a clever way to avoid this problem but I have not herd one yet. I want the charter to clearly allows the WG to figure out the right way to map to existing SIP systems. To do this, I think the browser has to be able to report what codecs and other extensibility options it supports then allow the application to influence what gets used to allow negotiation with the far end. In my mind, the current charter, particularly point 5 and 6, provide that. With regards to backwards compatibility with legacy voip systems, it's going to be a balance with tradeoffs. We can't have a charter that says everything must support all legacy devices because the legacy device can't even talk to all other legacy devices. I want the WG to be able to make these decision and have consensus the balance right before publishing the specifications that would come out of the WG. But making theses choices is the work in this working group is largely about. The WG needs to define an architecture that allows the sort of long term extensibility that David mentioned while at the same time make sure that systems compliant with the work can done suffer from interoperability failures. From my point of view the current charter would give the WG the room to make theses choices. Cullen On Mar 21, 2011, at 8:36 AM, Elwell, John wrote:
OK, so what I think Christer and Andy are saying is that it is not just about having the right the mandatory-to-implement protocols, codecs, etc., but also about sufficient control at the API so that appropriate ones can be selected when interoperating with existing equipment. I would agree with that. Do Christer and Andy consider my text proposal for the charter to be sufficient, or does it need changing or extending?
John
-----Original Message----- From: Hutton, Andrew Sent: 21 March 2011 14:16 To: Elwell, John; Christer Holmberg; Ted Hardie Cc: rtc-web@alvestrand.no Subject: RE: [RTW] New proposed charter text. Please review before the BoF.
Hi,
I think Christer's comment is really important.
If the web application is going to be responsible for ensuring interoperability with SIP or anything else then the API between the browser and the web application needs to be flexible and powerful to enable this interoperability to take place. So I believe the charter needs to make it clear that the input for this API that the IETF provides to W3C will take in to account the fact that the web application has to achieve interoperability with non RTC-Web based systems of which SIP/SDP based systems are the obvious example.
Regards Andy
-----Original Message----- From: rtc-web-bounces@alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of Elwell, John Sent: 21 March 2011 07:41 To: Christer Holmberg; Ted Hardie Cc: rtc-web@alvestrand.no Subject: Re: [RTW] New proposed charter text. Please review before the BoF.
-----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: 19 March 2011 11:22 To: Ted Hardie; Elwell, John Cc: rtc-web@alvestrand.no Subject: RE: [RTW] New proposed charter text. Please review before the BoF.
Hi,
Regarding interoperability (or, creating new solutions in general), there are a couple of things we need to consider.
One is of course the protocols supported by the browser (e.g RTP, ICE etc).
The second, which I THINK John is referring to, is to ensure that web applications (whether they are SIP based or based on something else) are able to ENABLE the browser protocols and features in a good and effective way. For that we need to ensure that the API between the browser and the web app is powerful enough. [JRE] That might be one of the consequences - if the browser is able to use a protocol that is not interoperable with existing equipment and a protocol that is interoperable, then clearly an application wanting to interoperate would want to be able to choose the latter.
That was not the main point of my proposed addition to the charter - the main point was that the set of mandatory-to-implement protocols in the browser should include those that can interoperate in a reasonable way with existing equipment. Based on discussions to date, the most problematic is likely to be codecs, particularly video codecs, because of the cost and performance degradation when transcoding has to be done.
John
In the ucreqs document, we have tried to differentiate between those two things by having separate browser requirements and API requirements.
Regards,
Christer
________________________________________ From: rtc-web-bounces@alvestrand.no [rtc-web-bounces@alvestrand.no] On Behalf Of Ted Hardie [ted.ietf@gmail.com] Sent: Friday, March 18, 2011 7:38 PM To: Elwell, John Cc: rtc-web@alvestrand.no Subject: Re: [RTW] New proposed charter text. Please review before the BoF.
On Fri, Mar 18, 2011 at 10:17 AM, Elwell, John <john.elwell@siemens-enterprise.com> wrote:
Ted,
In the same way that charters tend to call out "horizontal" topics for special mention, such as security, privacy and NAT/firewall, I believe the ability to achieve interop with existing equipment should also be given a mention.
Hi John,
Unsurprisingly, I am also a fan of interoperability. But I think there are multiple ways to scope interoperability. The charter currently does it by focusing on the interoperability we
get at the
protocol level, largely by choosing tools for this toolkit that match the tools already in place (e.g. RTP, ICE, etc.). I agree that we shouldn't select tools that are in place but unusable. I think we end up having to trust the working group on this anyway, as it will decide which tools are unusuable even if we insert a "don't pick unusable tools" section.
So the basic question boils down to: do we also want to assert a need for interoperability with a specific application or set of applications in the charter?
My personal take is no. Those are use cases, and important ones. But the charter is focused on building a toolkit "to enable innovation on top of a set of basic components." I have no doubt that someone will be able to build a fully backwards compatible service using these components and a gateway,. But the more important charter goal is to get the component set right to enable them to build more than that. And I think calling out that specific use case is more likely to limit our vision than to result in more clarity in picking protocols and tools.
Again, just my personal opinion,
regards,
Ted Hardie
Note that I stop short of demanding backwards compatibility, but instead make a somewhat more flexible proposal.
Using defined protocols isn't necessarily sufficient if we pick things that are not implemented. As an extreme case, take S/MIME, for example.
John
-----Original Message----- From: Ted Hardie [mailto:ted.ietf@gmail.com] Sent: 18 March 2011 17:01 To: Elwell, John Cc: rtc-web@alvestrand.no Subject: Re: [RTW] New proposed charter text. Please review before the BoF.
On Fri, Mar 18, 2011 at 5:04 AM, Elwell, John <john.elwell@siemens-enterprise.com> wrote: > Ted, > > I think there needs to be some mention of interop with existing real-time applications using IETF protocols (such as SIP, RTP). Something along the lines of: > "Work should take account of browser-based applications that require to interoperate with existing applications using IETF protocols such as SIP and RTP and commonly deployed audio and video codecs. Solutions that require mediation functions to achieve interoperation might be acceptable, provided such functions are not unduly complex, expensive or detrimental to performance." >
So, my personal read is that these work items:
"4. Define which RTP functions and extensions shall be supported in the client and their usage for real-time media, including media adaptation to ensure congestion safe usage. 5. Define what functionalities in the solution, such as media codecs, security algorithms, etc., can be extended and how the extensibility mechanisms works. 6. Define a set of media formats that must or should be supported by a client to improve interoperability."
and this general statement which follows the work items:
"This work will be done primarily by using already defined protocols or functionalities. "
Those seem to cover the same ground as your "take account of". If your aim is to get to something more concrete, like "you must be able to build a browser-based SIP softphone using the tools identified by this group", I think you need to unpack that a bit more. Some of the presence aspects of that toolkit, for example, may not be identified here.
To put this another way, my personal read is that we're aiming to create the toolkit needed to build real-time media applications in web contexts. Any specific application, including a SIP softphone, would be a use of the toolkit; those will be covered by something like draft-holmberg-rtcweb-ucreqs-00.txt as a use case, rather than in the charter.
Again, just my personal take on this.
regards,
Ted Hardie
> John > >> -----Original Message----- >> From: rtc-web-bounces@alvestrand.no >> [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of Ted Hardie >> Sent: 17 March 2011 16:18 >> To: rtc-web@alvestrand.no >> Subject: [RTW] New proposed charter text. Please review >> before the BoF. >> >> Name: Real-Time Communication in WEB-browsers (RTCWeb) >> >> There are a number of proprietary implementations that provide direct >> interactive rich communication using audio, video, collaboration, >> games, etc. between two peers' web-browsers. These are not >> interoperable, as they require non-standard extensions or plugins to >> work. There is a desire to standardize the basis for such >> communication so that interoperable communication can be established >> between any compatible browsers. The goal is to enable innovation on >> top of a set of basic components. One core component is to enable >> real-time media like audio and video, a second is to enable datagram >> and byte stream data transfer directly between clients. >> >> This work will be done in collaboration with the W3C. The IETF WG >> will produce architecture and requirements for selection and profiling >> of the on the wire protocols. The architecture needs to be coordinated >> with W3C. The IETF WG work will identity state information and events >> that need to be exposed in the APIs as input to W3C. The W3C will be >> responsible for defining APIs to ensure that application developers >> can control the components. >> >> The security goals and requirements will be developed by the WG. The >> security model needs to be coordinated with the W3C. The work will >> also consider where support for extensibility is needed. RTP >> functionalities, media formats, security algorithms are example of >> things that commonly needs extensions, additions or replacement, and >> thus some support for negotiation between clients is required. >> >> The WG will perform the following work: >> 1. Define the communication model in detail, including how session >> management is to occur within the model. >> 2. Define a security model that describes the security goals and >> how the communication model can achieve these goals. >> 3. Define how NAT and Firewall traversal is to occur. >> 4. Define which RTP functions and extensions that shall be >> supported in the client and their usage for real-time media, including >> media adaptation to ensure congestion safe usage. >> 5. Define what functionalities in the solution, such as media >> codecs, security algorithms, etc., that can be extended and how the >> extensibility mechanisms works. >> 6. Define a set of media formats that must or should be supported >> by a client to improve interoperability. >> 7. Define how non RTP datagram and byte stream data communication >> between the clients can be done securely and in a congestion safe way. >> 8. Provide W3C input for the APIs that comes from the >> communication model and the selected components and protocols that are >> part of the solution. >> >> >> This work will be done primarily by using already defined protocols or >> functionalities. If there is identification of missing protocols or >> functionalities, such work can be requested to be done in another >> working group with a suitable charter or by requests for chartering it >> in this WG or another WG. The following topics will be out of scope >> for the initial phase of the WG but could be added after a recharter: >> RTSP, RSVP, NSIS, Location services, IM & Presence, Resource Priority. >> >> The products of the working group will support security and keying as >> required by BCP 61 and be defined for IPv4, IPv6, and dual stack >> deployments. The Working Group will consider the possibility of >> defining a browser component that implements an existing session >> negotiation and management protocol. The working group will follow BCP >> 79, and adhere to the spirit of BCP 79. The working group cannot >> explicitly rule out the possibility of adopting encumbered >> technologies; however, the working group will try to avoid encumbered >> technologies that require royalties or other encumbrances that would >> prevent such technologies from being easy to use in web browsers. >> >> Milestones: >> >> Aug 2011 Architecture and Security and Threat Model sent to W3C >> >> Aug 2011 Use cases and Scenarios document sent to W3C >> >> Sept 2011 Architecture and Security and Threat Model to IESG >> as Informational >> >> Sept 2011 Use cases and Scenarios for RTCWeb document sent to IESG as >> Informational >> >> Dec 2011 RTCWeb and Media format specification(s) to IESG as PS >> >> Dec 2011 Information elements and events APIs Input to W3C >> >> Apr 2012 API to Protocol mapping document submitted to the IESG as >> Informational (if needed) >> _______________________________________________ >> RTC-Web mailing list >> RTC-Web@alvestrand.no >> http://www.alvestrand.no/mailman/listinfo/rtc-web >>
RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
Cullen, I support your view that negotiation is required not only to support interoperability with current systems using different codec but also for future codecs support. I just want to bring past experience of H.323 where a mandatory video codec was defined (H.261 which was the codec used at the time) and caused a burden on developers later that had to support it even though it was not widely used just for compliance. My view is that selecting a mandatory codec is difficult but removing it from being mandatory when it becomes a burden is even more difficult. Another experience on choosing a video codec is that not only new codecs are developed but the codec itself can evolve adding higher capabilities that may require negotiation allowing the sender to send a higher quality video stream. So selecting a codec and more precisely an operation point of a codec with no good negotiation may not be a good choice. Thanks Roni Even
-----Original Message----- From: rtc-web-bounces@alvestrand.no [mailto:rtc-web- bounces@alvestrand.no] On Behalf Of Cullen Jennings Sent: Tuesday, March 22, 2011 5:16 AM To: Elwell, John Cc: Ted Hardie; Hutton, Andrew; rtc-web@alvestrand.no; Christer Holmberg Subject: Re: [RTW] New proposed charter text. Please review before the BoF.
So at one point we had some text along the lines of the proposed
"Solutions that require mediation functions to achieve interoperation might be acceptable, provided such functions are not unduly complex, expensive or detrimental to performance."
But I think that sort of text does not turns out to be useful in a charter. It is so vague and ambiguous that it does not guide the work. So lets dig into the things that might guide the work and see what we could do in a charter.
Clearly we need extensibility and ways of negotiating new things. There many points were we need extensibility but video codecs are one of them. Twelve years down the road, its highly likely that there will be new codecs in browsers beyond what we have today - who knows, perhaps they will do 3D. Clearly we need a way for an browser application to find out which codecs that browser supports then use that for negotiation. But, in as Henning nicely put it, to avoid failure of negotiation, we need some minimal set of things all browsers have.
With something like crypto algorithms for SRTP, the odds are good we can easily find something that was both acceptable to browsers and was widely supported by legacy voip equipment that does SRTP. With something like narrowband audio codecs it gets harder, but it is probably possible to come to something workable for a many cases. Phone BCP did. As you point out, video in some way has the highest cost of interoperability failure, but the bad news is that unfortunately legacy voip equipment already has widespread interoperability failure on video codec choices. Probably the most prevalent codec in interactive sessions is H.263 but much of the new equipment does not support that. Even the equipment that supports H.264 AVC (ignoring SVC), there are so many variants that much of the H.264 systems have no common way of interoperating with other H.264 systems. To have widespread support for legacy video equipment, browsers would have to implement a lot of codecs and profiles. H.26 5 is slated to be completed before I would expect this work to be deployed in the bulk of browser. Then there is the MPEG work on codecs that proponents hope will be royalty free. Not to mention some other obvious candidates that are widely used. GIven the lack of a common video codec in existing legacy equipment, I don't see how this working group could fix that. However, I think this working group needs to pick something that ensure that equipment compliant with specifications from the proposed WG does not suffer from the same video interoperability failure as legacy equipment.
On the topic of what will be the hardest point of interoperability with legacy systems, I think it will be ICE like connectivity check issues. Every proposal I have seen so far has solved the problem of authorizing where the browser can send packets RTP by some connectivity check scheme such as ICE. However, ICE is not implemented the major of legacy voip equipment and I think this will end up being the biggest factor reducing what legacy equipment can work. Someone in the working group might think of a clever way to avoid this problem but I have not herd one yet.
I want the charter to clearly allows the WG to figure out the right way to map to existing SIP systems. To do this, I think the browser has to be able to report what codecs and other extensibility options it supports then allow the application to influence what gets used to allow negotiation with the far end. In my mind, the current charter, particularly point 5 and 6, provide that.
With regards to backwards compatibility with legacy voip systems, it's going to be a balance with tradeoffs. We can't have a charter that says everything must support all legacy devices because the legacy device can't even talk to all other legacy devices. I want the WG to be able to make these decision and have consensus the balance right before publishing the specifications that would come out of the WG. But making theses choices is the work in this working group is largely about.
The WG needs to define an architecture that allows the sort of long term extensibility that David mentioned while at the same time make sure that systems compliant with the work can done suffer from interoperability failures. From my point of view the current charter would give the WG the room to make theses choices.
Cullen
On Mar 21, 2011, at 8:36 AM, Elwell, John wrote:
OK, so what I think Christer and Andy are saying is that it is not just about having the right the mandatory-to-implement protocols, codecs, etc., but also about sufficient control at the API so that appropriate ones can be selected when interoperating with existing equipment. I would agree with that. Do Christer and Andy consider my text proposal for the charter to be sufficient, or does it need changing or extending?
John
-----Original Message----- From: Hutton, Andrew Sent: 21 March 2011 14:16 To: Elwell, John; Christer Holmberg; Ted Hardie Cc: rtc-web@alvestrand.no Subject: RE: [RTW] New proposed charter text. Please review before the BoF.
Hi,
I think Christer's comment is really important.
If the web application is going to be responsible for ensuring interoperability with SIP or anything else then the API between the browser and the web application needs to be flexible and powerful to enable this interoperability to take place. So I believe the charter needs to make it clear that the input for this API that the IETF provides to W3C will take in to account the fact that the web application has to achieve interoperability with non RTC-Web based systems of which SIP/SDP based systems are the obvious example.
Regards Andy
-----Original Message----- From: rtc-web-bounces@alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of Elwell, John Sent: 21 March 2011 07:41 To: Christer Holmberg; Ted Hardie Cc: rtc-web@alvestrand.no Subject: Re: [RTW] New proposed charter text. Please review before the BoF.
-----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: 19 March 2011 11:22 To: Ted Hardie; Elwell, John Cc: rtc-web@alvestrand.no Subject: RE: [RTW] New proposed charter text. Please review before the BoF.
Hi,
Regarding interoperability (or, creating new solutions in general), there are a couple of things we need to consider.
One is of course the protocols supported by the browser (e.g RTP, ICE etc).
The second, which I THINK John is referring to, is to ensure that web applications (whether they are SIP based or based on something else) are able to ENABLE the browser protocols and features in a good and effective way. For that we need to ensure that the API between the browser and the web app is powerful enough. [JRE] That might be one of the consequences - if the browser is able to use a protocol that is not interoperable with existing equipment and a protocol that is interoperable, then clearly an application wanting to interoperate would want to be able to choose the latter.
That was not the main point of my proposed addition to the charter - the main point was that the set of mandatory-to-implement protocols in the browser should include those that can interoperate in a reasonable way with existing equipment. Based on discussions to date, the most problematic is likely to be codecs, particularly video codecs, because of the cost and performance degradation when transcoding has to be done.
John
In the ucreqs document, we have tried to differentiate between those two things by having separate browser requirements and API requirements.
Regards,
Christer
________________________________________ From: rtc-web-bounces@alvestrand.no [rtc-web-bounces@alvestrand.no] On Behalf Of Ted Hardie [ted.ietf@gmail.com] Sent: Friday, March 18, 2011 7:38 PM To: Elwell, John Cc: rtc-web@alvestrand.no Subject: Re: [RTW] New proposed charter text. Please review before the BoF.
On Fri, Mar 18, 2011 at 10:17 AM, Elwell, John <john.elwell@siemens-enterprise.com> wrote:
Ted,
In the same way that charters tend to call out "horizontal" topics for special mention, such as security, privacy and NAT/firewall, I believe the ability to achieve interop with existing equipment should also be given a mention.
Hi John,
Unsurprisingly, I am also a fan of interoperability. But I think there are multiple ways to scope interoperability. The charter currently does it by focusing on the interoperability we
get at the
protocol level, largely by choosing tools for this toolkit that match the tools already in place (e.g. RTP, ICE, etc.). I agree that we shouldn't select tools that are in place but unusable. I think we end up having to trust the working group on this anyway, as it will decide which tools are unusuable even if we insert a "don't pick unusable tools" section.
So the basic question boils down to: do we also want to assert a need for interoperability with a specific application or set of applications in the charter?
My personal take is no. Those are use cases, and important ones. But the charter is focused on building a toolkit "to enable innovation on top of a set of basic components." I have no doubt that someone will be able to build a fully backwards compatible service using these components and a gateway,. But the more important charter goal is to get the component set right to enable them to build more than that. And I think calling out that specific use case is more likely to limit our vision than to result in more clarity in picking protocols and tools.
Again, just my personal opinion,
regards,
Ted Hardie
Note that I stop short of demanding backwards compatibility, but instead make a somewhat more flexible proposal.
Using defined protocols isn't necessarily sufficient if we pick things that are not implemented. As an extreme case, take S/MIME, for example.
John
> -----Original Message----- > From: Ted Hardie [mailto:ted.ietf@gmail.com] > Sent: 18 March 2011 17:01 > To: Elwell, John > Cc: rtc-web@alvestrand.no > Subject: Re: [RTW] New proposed charter text. Please review > before the BoF. > > On Fri, Mar 18, 2011 at 5:04 AM, Elwell, John > <john.elwell@siemens-enterprise.com> wrote: >> Ted, >> >> I think there needs to be some mention of interop with > existing real-time applications using IETF protocols (such as > SIP, RTP). Something along the lines of: >> "Work should take account of browser-based applications > that require to interoperate with existing applications using > IETF protocols such as SIP and RTP and commonly deployed > audio and video codecs. Solutions that require mediation > functions to achieve interoperation might be acceptable, > provided such functions are not unduly complex, expensive or > detrimental to performance." >> > > So, my personal read is that these work items: > > "4. Define which RTP functions and extensions shall be supported > in the client and their usage for real-time media, including media > adaptation to ensure congestion safe usage. > 5. Define what functionalities in the solution, such as media > codecs, security algorithms, etc., can be extended and how the > extensibility mechanisms works. > 6. Define a set of media formats that must or should be supported > by a client to improve interoperability." > > and this general statement which follows the work items: > > "This work will be done primarily by using already defined protocols > or functionalities. " > > Those seem to cover the same ground as your "take account of". If > your aim is to get to something more concrete, like "you must be able > to build a browser-based SIP softphone using the tools identified by > this group", I think you need to unpack that a bit more. Some of the > presence aspects of that toolkit, for example, may not be identified > here. > > To put this another way, my personal read is that we're aiming to > create the toolkit needed to build real-time media applications in web > contexts. Any specific application, including a SIP softphone, would > be a use of the toolkit; those will be covered by something like > draft-holmberg-rtcweb-ucreqs-00.txt as a use case, rather than in the > charter. > > Again, just my personal take on this. > > regards, > > Ted Hardie > > >> John >> >>> -----Original Message----- >>> From: rtc-web-bounces@alvestrand.no >>> [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of Ted Hardie >>> Sent: 17 March 2011 16:18 >>> To: rtc-web@alvestrand.no >>> Subject: [RTW] New proposed charter text. Please review >>> before the BoF. >>> >>> Name: Real-Time Communication in WEB-browsers (RTCWeb) >>> >>> There are a number of proprietary implementations that > provide direct >>> interactive rich communication using audio, video, collaboration, >>> games, etc. between two peers' web-browsers. These are not >>> interoperable, as they require non-standard extensions or > plugins to >>> work. There is a desire to standardize the basis for such >>> communication so that interoperable communication can be > established >>> between any compatible browsers. The goal is to enable > innovation on >>> top of a set of basic components. One core component is to enable >>> real-time media like audio and video, a second is to > enable datagram >>> and byte stream data transfer directly between clients. >>> >>> This work will be done in collaboration with the W3C. The IETF WG >>> will produce architecture and requirements for selection > and profiling >>> of the on the wire protocols. The architecture needs to be > coordinated >>> with W3C. The IETF WG work will identity state > information and events >>> that need to be exposed in the APIs as input to W3C. The > W3C will be >>> responsible for defining APIs to ensure that application developers >>> can control the components. >>> >>> The security goals and requirements will be developed by > the WG. The >>> security model needs to be coordinated with the W3C. The work will >>> also consider where support for extensibility is needed. RTP >>> functionalities, media formats, security algorithms are example of >>> things that commonly needs extensions, additions or > replacement, and >>> thus some support for negotiation between clients is required. >>> >>> The WG will perform the following work: >>> 1. Define the communication model in detail, including > how session >>> management is to occur within the model. >>> 2. Define a security model that describes the security > goals and >>> how the communication model can achieve these goals. >>> 3. Define how NAT and Firewall traversal is to occur. >>> 4. Define which RTP functions and extensions that shall be >>> supported in the client and their usage for real-time > media, including >>> media adaptation to ensure congestion safe usage. >>> 5. Define what functionalities in the solution, such as media >>> codecs, security algorithms, etc., that can be extended and how the >>> extensibility mechanisms works. >>> 6. Define a set of media formats that must or should > be supported >>> by a client to improve interoperability. >>> 7. Define how non RTP datagram and byte stream data > communication >>> between the clients can be done securely and in a > congestion safe way. >>> 8. Provide W3C input for the APIs that comes from the >>> communication model and the selected components and > protocols that are >>> part of the solution. >>> >>> >>> This work will be done primarily by using already defined > protocols or >>> functionalities. If there is identification of missing protocols or >>> functionalities, such work can be requested to be done in another >>> working group with a suitable charter or by requests for > chartering it >>> in this WG or another WG. The following topics will be out of scope >>> for the initial phase of the WG but could be added after a > recharter: >>> RTSP, RSVP, NSIS, Location services, IM & Presence, > Resource Priority. >>> >>> The products of the working group will support security > and keying as >>> required by BCP 61 and be defined for IPv4, IPv6, and dual stack >>> deployments. The Working Group will consider the possibility of >>> defining a browser component that implements an existing session >>> negotiation and management protocol. The working group > will follow BCP >>> 79, and adhere to the spirit of BCP 79. The working group cannot >>> explicitly rule out the possibility of adopting encumbered >>> technologies; however, the working group will try to avoid > encumbered >>> technologies that require royalties or other encumbrances > that would >>> prevent such technologies from being easy to use in web browsers. >>> >>> Milestones: >>> >>> Aug 2011 Architecture and Security and Threat Model sent to W3C >>> >>> Aug 2011 Use cases and Scenarios document sent to W3C >>> >>> Sept 2011 Architecture and Security and Threat Model to IESG >>> as Informational >>> >>> Sept 2011 Use cases and Scenarios for RTCWeb document sent > to IESG as >>> Informational >>> >>> Dec 2011 RTCWeb and Media format specification(s) to IESG as PS >>> >>> Dec 2011 Information elements and events APIs Input to W3C >>> >>> Apr 2012 API to Protocol mapping document submitted to the IESG as >>> Informational (if needed) >>> _______________________________________________ >>> RTC-Web mailing list >>> RTC-Web@alvestrand.no >>> http://www.alvestrand.no/mailman/listinfo/rtc-web >>> >
RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
Hi, I noticed that the proposed charter talks about communication between two web browsers. Is the work limited to point to point communication or is multipoint also in the scope of the work Thanks Roni Even
-----Original Message----- From: rtc-web-bounces@alvestrand.no [mailto:rtc-web- bounces@alvestrand.no] On Behalf Of Ted Hardie Sent: Thursday, March 17, 2011 6:18 PM To: rtc-web@alvestrand.no Subject: [RTW] New proposed charter text. Please review before the BoF.
Name: Real-Time Communication in WEB-browsers (RTCWeb)
There are a number of proprietary implementations that provide direct interactive rich communication using audio, video, collaboration, games, etc. between two peers' web-browsers. These are not interoperable, as they require non-standard extensions or plugins to work. There is a desire to standardize the basis for such communication so that interoperable communication can be established between any compatible browsers. The goal is to enable innovation on top of a set of basic components. One core component is to enable real-time media like audio and video, a second is to enable datagram and byte stream data transfer directly between clients.
This work will be done in collaboration with the W3C. The IETF WG will produce architecture and requirements for selection and profiling of the on the wire protocols. The architecture needs to be coordinated with W3C. The IETF WG work will identity state information and events that need to be exposed in the APIs as input to W3C. The W3C will be responsible for defining APIs to ensure that application developers can control the components.
The security goals and requirements will be developed by the WG. The security model needs to be coordinated with the W3C. The work will also consider where support for extensibility is needed. RTP functionalities, media formats, security algorithms are example of things that commonly needs extensions, additions or replacement, and thus some support for negotiation between clients is required.
The WG will perform the following work: 1. Define the communication model in detail, including how session management is to occur within the model. 2. Define a security model that describes the security goals and how the communication model can achieve these goals. 3. Define how NAT and Firewall traversal is to occur. 4. Define which RTP functions and extensions that shall be supported in the client and their usage for real-time media, including media adaptation to ensure congestion safe usage. 5. Define what functionalities in the solution, such as media codecs, security algorithms, etc., that can be extended and how the extensibility mechanisms works. 6. Define a set of media formats that must or should be supported by a client to improve interoperability. 7. Define how non RTP datagram and byte stream data communication between the clients can be done securely and in a congestion safe way. 8. Provide W3C input for the APIs that comes from the communication model and the selected components and protocols that are part of the solution.
This work will be done primarily by using already defined protocols or functionalities. If there is identification of missing protocols or functionalities, such work can be requested to be done in another working group with a suitable charter or by requests for chartering it in this WG or another WG. The following topics will be out of scope for the initial phase of the WG but could be added after a recharter: RTSP, RSVP, NSIS, Location services, IM & Presence, Resource Priority.
The products of the working group will support security and keying as required by BCP 61 and be defined for IPv4, IPv6, and dual stack deployments. The Working Group will consider the possibility of defining a browser component that implements an existing session negotiation and management protocol. The working group will follow BCP 79, and adhere to the spirit of BCP 79. The working group cannot explicitly rule out the possibility of adopting encumbered technologies; however, the working group will try to avoid encumbered technologies that require royalties or other encumbrances that would prevent such technologies from being easy to use in web browsers.
Milestones:
Aug 2011 Architecture and Security and Threat Model sent to W3C
Aug 2011 Use cases and Scenarios document sent to W3C
Sept 2011 Architecture and Security and Threat Model to IESG as Informational
Sept 2011 Use cases and Scenarios for RTCWeb document sent to IESG as Informational
Dec 2011 RTCWeb and Media format specification(s) to IESG as PS
Dec 2011 Information elements and events APIs Input to W3C
Apr 2012 API to Protocol mapping document submitted to the IESG as Informational (if needed) _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
Roni Even skrev 2011-03-28 08:33:
Hi, I noticed that the proposed charter talks about communication between two web browsers. Is the work limited to point to point communication or is multipoint also in the scope of the work
Hi, In my view multi-point using a centralized node, like an RTP mixer, are clearly in scope of the work. I don't think multi-point using multicast is realistic. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------
I agree multi-point with application level multicast scales badly but in a the cases where there are only 3 or 4 parties I think it can be an effective technique (and in those cases often simpler than try to insert an RTP mixer somewhere). However, if this is done at the application layer then as far as the protocol is concerned it is a collection of point-to-point connections and does not need specific protocol support. Peter On 2011-03-28, at 9:25 AM, Magnus Westerlund wrote:
Hi,
In my view multi-point using a centralized node, like an RTP mixer, are clearly in scope of the work. I don't think multi-point using multicast is realistic.
Cheers
Magnus Westerlund
Peter Musgrave skrev 2011-03-28 09:35:
I agree multi-point with application level multicast scales badly but in a the cases where there are only 3 or 4 parties I think it can be an effective technique (and in those cases often simpler than try to insert an RTP mixer somewhere).
Yes, I agree that there are some potentials in this use case. So I am not against it, but it is going to need some considerations.
However, if this is done at the application layer then as far as the protocol is concerned it is a collection of point-to-point connections and does not need specific protocol support.
Possibly, but there are RTP features that will work better if it actually happens in a joint RTP session context. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------
Listening to the discussion this morning, I remain a little concerned that a couple of things are not clearly separated in the existing charter(s). 1) There is the framework of APIs, events, DOM, modular decomposition, module interfaces, and so on. 2) Instantiated within that framework, we need an initial (probably mandated) set of modules and capabilities. (1) is not easily changed, and represents the interface between the IETF and the W3C, and there is only one of it. It enables the work to be split into modules. (2) are instantiations of the modules, which are more easily changed, or added to, and they establish actual interoperability in this domain and with others. If we make mistakes in (1), we live with them for ever, for the most part. For example, questions of privacy and security should be covered by both, but especially (1). But questions of interop are mostly (2). Will I be able to interop with most/all legacy systems? Yes, if I am willing to supply enough modules (protocols, codecs, etc.). I don't think we can design in this order (1 then 2); the design of the architecture has to be informed by the modules we understand and know we need to instantiate. But we do need to be clear whether a goal is an architectural goal or a goal for the initial modules. David Singer Multimedia and Software Standards, Apple Inc.
Hi, I have realized that I haven't comment openly on the charter text. I am satisfied with this charter proposal. I do wished it was clearer what we should do with relay based fallback for NAT/FW traversal. Cheers Magnus Ted Hardie skrev 2011-03-17 17:18:
Name: Real-Time Communication in WEB-browsers (RTCWeb)
There are a number of proprietary implementations that provide direct interactive rich communication using audio, video, collaboration, games, etc. between two peers' web-browsers. These are not interoperable, as they require non-standard extensions or plugins to work. There is a desire to standardize the basis for such communication so that interoperable communication can be established between any compatible browsers. The goal is to enable innovation on top of a set of basic components. One core component is to enable real-time media like audio and video, a second is to enable datagram and byte stream data transfer directly between clients.
This work will be done in collaboration with the W3C. The IETF WG will produce architecture and requirements for selection and profiling of the on the wire protocols. The architecture needs to be coordinated with W3C. The IETF WG work will identity state information and events that need to be exposed in the APIs as input to W3C. The W3C will be responsible for defining APIs to ensure that application developers can control the components.
The security goals and requirements will be developed by the WG. The security model needs to be coordinated with the W3C. The work will also consider where support for extensibility is needed. RTP functionalities, media formats, security algorithms are example of things that commonly needs extensions, additions or replacement, and thus some support for negotiation between clients is required.
The WG will perform the following work: 1. Define the communication model in detail, including how session management is to occur within the model. 2. Define a security model that describes the security goals and how the communication model can achieve these goals. 3. Define how NAT and Firewall traversal is to occur. 4. Define which RTP functions and extensions that shall be supported in the client and their usage for real-time media, including media adaptation to ensure congestion safe usage. 5. Define what functionalities in the solution, such as media codecs, security algorithms, etc., that can be extended and how the extensibility mechanisms works. 6. Define a set of media formats that must or should be supported by a client to improve interoperability. 7. Define how non RTP datagram and byte stream data communication between the clients can be done securely and in a congestion safe way. 8. Provide W3C input for the APIs that comes from the communication model and the selected components and protocols that are part of the solution.
This work will be done primarily by using already defined protocols or functionalities. If there is identification of missing protocols or functionalities, such work can be requested to be done in another working group with a suitable charter or by requests for chartering it in this WG or another WG. The following topics will be out of scope for the initial phase of the WG but could be added after a recharter: RTSP, RSVP, NSIS, Location services, IM & Presence, Resource Priority.
The products of the working group will support security and keying as required by BCP 61 and be defined for IPv4, IPv6, and dual stack deployments. The Working Group will consider the possibility of defining a browser component that implements an existing session negotiation and management protocol. The working group will follow BCP 79, and adhere to the spirit of BCP 79. The working group cannot explicitly rule out the possibility of adopting encumbered technologies; however, the working group will try to avoid encumbered technologies that require royalties or other encumbrances that would prevent such technologies from being easy to use in web browsers.
Milestones:
Aug 2011 Architecture and Security and Threat Model sent to W3C
Aug 2011 Use cases and Scenarios document sent to W3C
Sept 2011 Architecture and Security and Threat Model to IESG as Informational
Sept 2011 Use cases and Scenarios for RTCWeb document sent to IESG as Informational
Dec 2011 RTCWeb and Media format specification(s) to IESG as PS
Dec 2011 Information elements and events APIs Input to W3C
Apr 2012 API to Protocol mapping document submitted to the IESG as Informational (if needed) _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
-- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------
participants (12)
-
Bernard Aboba -
Christer Holmberg -
Cullen Jennings -
David Singer -
Elwell, John -
Hutton, Andrew -
Magnus Westerlund -
Peter Musgrave -
Philippe Le Hegaret -
Roni Even -
Ted Hardie -
Tschofenig, Hannes (NSN - FI/Espoo)